Práctica 3 - AESMcooking

Anlisis y Especificacin de Sistemas Multimedia

Prctica 3:Otras metodologas giles

Carles Escriv Cant Rubn Dur Esquembre Antonio Mudarra Martnez Jorge Lilao Chinchilla #AESMcooking

Prctica 3 Otras metodologas giles AESMcooking - UA

ndice1. DSDM (Dynamic systems development method) ................................................................. 3 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 2. Introduccin .................................................................................................................. 3 Principios ....................................................................................................................... 3 Asunciones .................................................................................................................... 4 Roles .............................................................................................................................. 4 Fases y sus respectivos artefactos ................................................................................ 5 Conclusiones.................................................................................................................. 7 Referencias utilizadas .................................................................................................... 7

Crystal Clear .......................................................................................................................... 8 2.1. 2.2. Introduccin .................................................................................................................. 8 El cdigo gentico ......................................................................................................... 8

2.2.1. Modelo de juegos cooperativos .................................................................................. 8 2.2.2. Prioridades .................................................................................................................. 8 2.2.3. Propiedades................................................................................................................. 9 2.2.4. Principios ..................................................................................................................... 9 2.2.5. Estrategias ................................................................................................................... 9 2.2.6. Tcnicas ..................................................................................................................... 10 2.3. 2.4. 3. Artefactos .................................................................................................................... 10 Referencias utilizadas .................................................................................................. 11

FDD: Feature Driven Development ..................................................................................... 12 3.1. 3.2. Introduccin ................................................................................................................ 12 Caractersticas ............................................................................................................. 12 Desarrollar un modelo general (global). ............................................................. 12 Crear una lista de funcionalidades. ..................................................................... 12 Desarrollar un plan por funcionalidad. ............................................................... 12 Disear por funcionalidad y Construir por funcionalidad. .................................. 12

3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.3. 3.4. 3.5. 3.6. 4.

Roles ............................................................................................................................ 13 Artefactos .................................................................................................................... 13 Prcticas ...................................................................................................................... 14 Referencias utilizadas .................................................................................................. 14

AUP (Agile Unified Process)................................................................................................. 15 4.1. 4.2. Introduccin ............................................................................................................... 15 Las disciplinas ............................................................................................................ 15

1


4.3.

Las fases...................................................................................................................... 16 Inicio .................................................................................................................... 16 Elaboracin .......................................................................................................... 16 Construccin........................................................................................................ 16 Transicin ............................................................................................................ 16

4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.4. 4.5. 4.6.

Entrega de versiones ................................................................................................. 16 Roles ........................................................................................................................... 17 Artefactos ................................................................................................................... 18 Entregables mnimos ........................................................................................... 18 Entregables de Negocio....................................................................................... 18 Otros artefactos del Proyecto ............................................................................. 19

4.6.1. 4.6.2. 4.6.3. 4.7. 5.

Referencias ................................................................................................................. 19

Comparacin de metodologas ........................................................................................... 20 5.1. 5.2. 5.3. Comparativa ............................................................................................................... 20 Ventajas y desventajas de cada metodologa .......................................................... 20 Conclusiones .............................................................................................................. 21

2


1. DSDM (Dynamic method)1.1. Introduccin

systems

development

Considerada como la primera metodologa gil, es de naturaleza iterativa e incremental. Est orientada a combatir los principios de la crisis del software, permitiendo la construccin de sistemas introduciendo restricciones de tiempo, presentando prototipos incrementales dentro de un ambiente de proyecto controlado. Mtodo que provee un framework para el desarrollo gil cumpliendo con las caractersticas de la metodologa gil: implicacin constante del usuario. desarrollo iterativo e incremental. desarrollo de sistema ajustado a tiempos y presupuesto.

En MDSD los proyectos son limitados en tiempo y recursos, por lo que se fomenta la utilizacin del Desarrollo Rpido de Aplicaciones, y en algunos casos integra contenidos de otros mtodos giles como Programacin extrema (XP).

1.2.

Principios

Existen 9 principios en los que se basa esta metodologa y que delimitan la naturaleza de la misma: 1. Involucrar al cliente; tanto el cliente como los desarrolladores comparten entorno de trabajo y toman decisiones en comn. 2. Toma de decisiones importantes por parte del equipo del proyecto, sin tener que esperar aprobacin de niveles superiores en jerarqua. 3. Orientado a la iteracin, se considera que entregar algo bueno pronto es mejor que algo perfecto tarde. Esto nos da la oportunidad de probar el producto, lo que permite la revisin del producto desde etapas muy tempranas, gracias a lo cual se pueden asumir nuevas mejoras que se aproximen a las expectativas del usuario. 4. La entrega del sistema ha de satisfacer las funcionalidades crticas del usuario. No es necesario abarcar todas las necesidades, sino nicamente las ms importantes, el resto se pueden desarrollar funcionalidades accesorias a posteriori. 5. Desarrollo iterativo e incremental basado en las revisiones y la retroalimentacin de los usuarios. 6. Cualquier cambio es reversible, lo que es muy importante debido a que puede existir malos entendidos, o el usuario puede equivocarse al especificar una funcionalidad o la forma de operar de la misma. 7. Los objetivos y requisitos de alto nivel han de ser pactados, antes del inicio del proyecto por todos aquellos que participan en el mismo.

3


8. Las pruebas se realizan durante todo el proyecto, lo que nos permite una tempranea deteccin de errores. 9. La comunicacin y cooperacin entre las partes del proyecto ha de ser constante.

1.3.

Asunciones

Adems de los anteriores principios hay que asumir otros denominados asunciones: Ningn sistema se construye a la perfeccin en un solo intento. Segn el principio de Pareto (regla 80/20), el 80% de los objetivos se pueden lograr con el 20% del esfuerzo necesario para lograr la totalidad. El sistema perfecto es una utopa e intentar conseguirlo demasiado pronto puede poner en riesgo el sistema de informacin. El objetivo es conseguir proyectos de calidad en los plazos marcados ya justados al presupuesto indicado, siempre y cuando el usuario este satisfecho. En MDSD para que se inicie una fase no es necesario que la anterior est completa y con cada nueva iteracin, el sistema se mejora incrementalmente. La evaluacin de riesgos no se centra en el proceso de construccin sino en entregar funcin de negocio. Se pueden realizar varias iteraciones simultneamente siempre que no se entorpezcan ente ellas. Esta metodologa es aplicable tanto a desarrollos iniciados desde cero como a ampliaciones de otros proyectos que no hayan sido creados con esta metodologa. La clave es definir adecuadamente los incrementos.

1.4.

Roles

A lo largo de la metodologa de DSDM podemos encontrar diversos tipos de roles, nosotros destacamos los siguientes Productor Ejecutivo: es uno de los roles que ms poder tiene a la hora de la toma de decisiones. El Visionario: tiene la responsabilidad de dar inicio al proyecto y de asegurarse que los requisitos principales aparezcan desde el principio en el proyecto. Usuario Embajador: aporta los datos de la comunidad de usuarios en el proyecto. Asesor del usuario: puede ser cualquier usuario que representa un punto de vista importante y aporta el conocimiento diario del proyecto. Gerente del Proyecto: puede ser cualquier persona de la comunidad de usuarios o al personal de TI que gestiona el proyecto en general. Coordinador Tcnico: responsable del diseo de la arquitectura del sistema. Lder del equipo: se asegura de que el equipo funciona de manera efectiva. Desarrollador: interpreta los requisitos del sistema. Tester: realiza las diferentes pruebas del sistema. Redactor: responsable de recoger y registrar los requerimientos, acuerdos y decisiones tomadas en cada tarea.

4


1.5.

Fases y sus respectivos artefactos

Esta metodologa consta de las siguientes fases que se realizan de forma secuencial: Pre-proyecto, que define: el alcance global, los departamentos y personas implicadas, los compromisos de las distintas partes y quien o quienes financian el proyecto.

Ciclo de vida, compuesto por 5 fases: 1. Estudio de viabilidad: Estudio de adecuacin de la metodologa al proyecto e identificacin de riesgos. De esta fase obtendremos: informe de viabilidad, prototipo de viabilidad, y el plan general del proyecto, que abarca el plan de desarrollo y el registro de riesgos.

5


2. Estudio de Negocio: Anlisis en profundidad del proceso de negocio a informatizar. Resulta fundamental para esta fase, la participacin del usuario, tanto que si esta no se consigue habra que replantearse seguir el proyecto utilizando esta metodologa. De esta fase obtenemos: modelo de procesos identificando los usuarios clave en cada uno de ellos, catalogo de requisitos priorizado, arquitectura del sistema, plan de prototipo.

3. Iteracin del modelo funcional (dividido en 4 fases): Identificacin del prototipo funcional -> se definen funcionalidades a cubrir y se elabora modelo funcional. Definicin de calendario -> se acuerda plan de trabajo Obtencin de prototipo Revisin de prototipo funcional -> se determina grado de aceptacin mediante pruebas realizadas por el usuario, muy importante el feedback para que las iteraciones se aproximen al mximo a las necesidades el usuario. 4. Iteracin del diseo y la construccin (se divide en 4 fases): Identificacin del prototipo de diseo -> se determinan requisitos funcionales y no funcionales. Definicin de calendario -> se acuerda plan de trabajo Construccin de prototipo de diseo -> ser utilizable por los usuarios. Revisin de prototipo de diseo.

5. Implementacin(se divide en 4 fases): Aprobacin del usuario -> El usuario da el visto buenos a producto. Formacin -> formar a usuarios finales. Implementacin -> instalar producto en oficinas del cliente. Revisin de negocio -> confirmar la adecuacin del sistema a las necesidades del usuario y a los objetivos establecidos en el proyecto.

Si se detecta o falla algn aspecto funcional relevante se vuelve a la fase de Estudio de Negocio, si este no es relevante se vuelve a la fase Iteracin del modelo funcional y si es un aspecto tcnico se vuelve a Iteracin del diseo y la construccin. Post-proyecto: Su objetivo es que el sistema siga siendo til al usuario, por lo que comprendera el mantenimiento.

6


1.6.

Conclusiones

La constante comunicacin entre proveedores y cliente durante el proceso de desarrollo es primordial, ya que en esta se basa el xito del sistema, que no es otro que la satisfaccin del cliente con el producto final. Por esta razn, esta metodologa permite al usuario aportar al proceso nuevos requerimientos durante el desarrollo del proyecto, antes de que el producto este concluido, con el consiguiente ahorro de tiempo y dinero en la realizacin de modificaciones. La utilizacin de prototipos permite la pronta deteccin, por parte de los desarrolladores, de los defectos del sistema. El estudio de viabilidad de la aplicacin de esta metodologa, aumenta la confiabilidad del cliente ante el proceso de desarrollo que se va a llevar a cabo.

1.7.

Referencias utilizadas

http://es.wikipedia.org/wiki/M%C3%A9todo_de_desarrollo_de_sistemas_din%C3%A1micos http://www.dsdm.org http://www.navegapolis.net/content/view/361/59/ http://jummp.wordpress.com/2011/04/13/desarrollo-de-software-metodo-de-desarrollo-desistemas-dinamicos-dsdm-i/ http://www.lcc.uma.es/~av/MDD-MDA/

7


2. Crystal Clear2.1. Introduccin

Crystal Clear en principio no es una metodologa, sino mas bien una familia de metodologas con un cdigo gentico comn. Podemos desarrollar distintas metodologas para distintos tipos de proyectos. El nombre viene dado por la caracterizacin de los proyectos segn dos dimensiones, tamao y complejidad parecida a los minerales (color y pureza).

2.2.

El cdigo gentico

2.2.1. Modelo de juegos cooperativos Este modelo ve al desarrollo de software como una serie de partidos que consisten en inventar y comunicar. Cada partido es diferente y tiene como objetivo entregar software y prepararse para el siguiente juego. Esto permite al equipo trabajar concentrado y en forma efectiva con un objetivo claro cada vez. 2.2.2. Prioridades Establece un conjunto de prioridades y principios que sirven de gua para la toma de decisiones. Eficiencia en el desarrollo: para hacer que los proyectos sean econmicamente rentables. Seguridad: en lo que se entrega. Habitabilidad: hacer que todos los miembros del equipo adopten y sigan las convenciones de trabajo establecidas por el equipo mismo.

8


2.2.3. Propiedades Frecuencia en las entregas: entregar al usuario funcionalidad "usable" con una frecuencia (en cosa de semanas). Comunicacin: toma como uno de sus pilares a la comunicacin. Crecimiento reflexivo: es necesario que el equipo lleve a cabo reuniones peridicas de reflexin que permitan crecer y hacernos ms eficientes. Seguridad personal: lograr que cada miembro del equipo pueda sentirse cmodo con el trabajo y el entorno. Concentracin: las entregas frecuentes permiten que cada desarrollador puede enfocar de a un problema por vez evitando dispersiones. Fcil acceso a usuarios clave: tratar de hacer que el usuario sea una parte ms del equipo es fundamental para ir depurando errores de manera temprana. Entorno tcnico con: i - Testing automatizado.

2.2.4. Principios El grado de detalle necesario en documentar requerimientos, diseo, planeamiento, etc., vara segn el proyecto. Es imposible eliminar toda documentacin pero puede ser reducida logrando un modo de comunicacin ms accesible con los dems miembros del equipo. El equipo ajusta constantemente su forma de trabajo para lograr que cada personalidad encaje con los otros miembros, con el entorno y las particularidades de cada asignacin. 2.2.5. Estrategias Exploracin de 360. Verifica una muestra de valor de negocios del proyecto, los requerimientos, el modelo de dominio, la tecnologa, el plan del proyecto y el proceso. Victoria temprana. Es mejor buscar pequeos triunfos que aspirar a una gran victoria tarda. Esqueleto ambulante. Es una transaccin que debe ser simple pero completa. Re arquitectura incremental. No es aconsejable interrumpir el desarrollo para corregir la arquitectura, es mejor que la arquitectura evolucione en etapas y se modifique. Todas describen una forma de tomar ventaja del desarrollo incremental para establecer valor desde el principio.

9


2.2.6. Tcnicas Igual que con las estrategias, hay una lista de tcnicas propuestas por Crystal Clear, de las cuales se pueden ir tomando las ms convenientes segn el momento en que se encuentra el proceso de desarrollo del proyecto. Las reuniones diarias acompaan el seguimiento y mantienen el foco en el prximo paso a seguir, y tambin permiten la discusin productiva de lneas a seguir. Estn introducidas por las metodologas Scrum. Las reuniones de reflexin peridicas son fundamentales para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar qu cosas dan resultado y cules no o de empezar a trabajar.

2.3.

Artefactos

Los artefactos ms importantes segn los roles que designa la metodologa, sin tomar en cuenta el desarrollo de software, en la metodologa Crystal Clear son los siguientes: El Patrocinador es responsable de producir un nico tem: Declaracin de la misin con prioridades Comerciales (Trade-off).

El Equipo es responsable de producir dos cosas: La Estructura del Equipo y Acuerdos. Los Resultados de Taller de Reflexin.

El coordinador, con la ayuda del equipo, es responsable de producir: Mapa del Proyecto. El Plan de publicacin. El Estado del Proyecto. La Lista de Riesgos. Plan de Iteracin. Vista del Programa.

El experto en negocio y el usuario experto juntos son responsables de producir: La lista de metas de los Actores. Los Casos de uso Archivo de Requerimiento. Modelo de Roles de usuarios.

El Diseador Principal es responsable de producir la: La Descripcin de la Arquitectura

10


El Diseador-Programador, incluido el diseador principal, son responsables de: Bosquejo de Pantallas. Modelo de Dominio. Diseo de bosquejos. Cdigo Fuente. Pruebas. Sistema Empaquetado.

El probador es responsable de producir: Reporte de errores en tiempo real.

El escritor es responsable de producir: El texto de ayuda al usuario. Manual de Usuario. Manual de Entrenamiento.

2.4.


www.cs.umss.edu.bo/doc/material/mat.../Metodologia%20Crystal.doc

repositorio.espe.edu.ec/bitstream/21000/556/1/T-ESPE-021804.pdf

11


3. FDD: Feature Driven Development3.1. Introduccin

Feature Driven Development (FDD) como casi todas las metodologas giles que estamos viendo a lo largo del curso es un modelo de desarrollo iterativo, especialmente orientado a obtener funcionalidades tangibles al terminar cada iteracin, es decir, tiene por objetivo el conseguir software funcional tras cada iteracin para as estar mas ntimamente relacionado con el cliente que va viendo y testeando el producto durante todo el ciclo de desarrollo. El desarrollo dirigido a las funcionalidades, que as sera su traduccin aproximada al castellano, se basa en cinco pasos, o actividades, secuenciales y especficas, a saber, Develop Overall Model, Build a Feature List, Plan by Feature, Design by Feature, Build By Feature o lo que sera lo mismo: Desarrollar un modelo general (global), crear una lista de funcionalidades, desarrollar un plan por funcionalidad, disear por funcionalidad y por ltimo construir por funcionalidad.

3.2.

Caractersticas

Primeramente hay que dejar claro que las tres primeras actividades se desarrollan inicialmente y de manera normal, pero las dos ltimas sern las que desarrollemos de manera iterativa hasta acabar el proyecto. Ahora extenderemos un poco ms las diferentes actividades con una breve descripcin de cada una de ellas. 3.2.1. Desarrollar un modelo general (global). Cuando comienza el desarrollo, los expertos del dominio ya tienen claros los requerimientos del sistema a construir. En este punto se subdivide el proyecto en reas que son estudiadas, los desarrolladores construyen un diagrama de clases por cada rea a desarrollar. 3.2.2. Crear una lista de funcionalidades. Ahora y teniendo claras las necesidades globales se crea una lista con todas las funcionalidades separadas, las cuales en conjunto forman el software en s, la lista es elaborada por los desarrolladores y es evaluada por el cliente. En este punto el cliente aprueba o descarta las funcionalidades. 3.2.3. Desarrollar un plan por funcionalidad. Aqu se ordenan las funcionalidades por prioridad, dificultad y dependencia. Se asignan los diferentes jefes para cada una de ellas. 3.2.4. Disear por funcionalidad y Construir por funcionalidad. Por orden de prioridad seleccionamos un nmero de funcionalidades de la lista y se comienzan a disear y posteriormente a construir dicha funcionalidad de manera iterativa. Estas iteraciones tienen un margen de tiempo ya estipulado. El proceso en s no es solo diseo y programacin, incluye pruebas unitarias, inspeccin del cdigo, codificacin, etc...

12


En la imagen anterior se puede ver un ejemplo grfico del funcionamiento de esta metodologa, se puede ver claramente como las tres primeras actividades son planteadas y llevadas a cabo y entonces comenzamos las actividades restantes de manera iterativa hasta finalizar el proyecto.

3.3.

Roles

Si bien hay una gran cantidad de roles a interpretar por todos los miembros del equipo, se pueden diferenciar claramente en tres grandes grupos, roles clave, roles de soporte y roles adicionales. El equipo de trabajo est muy jerarquizado, para no extendernos demasiado, vamos a ver los principales roles. Director del Proyecto: es a todas luces el lder del proyecto, y es quien tiene la ltima palabra en lo relacionado con la administracin y financiacin. Es adems la cabeza visible del grupo. Arquitecto Jefe: es el encargado de realizar el diseo general o global y supervisor de todas las etapas. Director de Desarrollo: es el encargado de llevar el da a da en el desarrollo del proyecto, coordina todo lo referente a ello y se encarga de los problemas referentes a recursos. Programador Jefe: es quien analiza los requerimientos. Disea el proyecto. Selecciona las funcionalidades a desarrollar de la ltima fase del Feature Driven Development. Propietarios de Clases: son responsables del desarrollo de las clases que se le asignaron como propias que trabajan bajo la gua del programador jefe en diseo, codificacin, prueba y documentacin. Expertos de dominio: puede ser un usuario, un cliente, analista o una mezcla. Poseen el conocimiento de los requerimientos del sistema. Pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.

3.4.

Artefactos

Artefactos propiamente dichos no es algo que se genere en este modelo o por lo menos se minimizan al mximo. Ya que su objetivo real es la obtencin de tems funcionales para su uso y prueba por los usuarios, o sea, se basa ms en las funcionalidades que en la documentacin. Aun as siempre hay una serie de documentos que se generan y que podramos considerar artefactos segn en que contexto. Como por ejemplo el plan de proyecto, que es un

13


documento generado por el lder de proyecto con toda la informacin de gestin, o la lista de riesgos se utiliza para capturar los riesgos ms relevantes que se presentan en el proyecto.

3.5.

Prcticas

Uno de los motivos por los que nos puede resultar especialmente atractivo Feature Driven Development es el hecho que est construido alrededor de una serie de prcticas que si bien desde otras metodologas de desarrollo se apoyan, es en FDD en donde se exigen. El dominio del modelado de objetos, proporciona una base estable para sumar funcionalidades y caractersticas de manera sencilla. El desarrollo por funciones, esto se refiere al problema de tener funciones demasiado grandes, lo bueno del mtodo es que se ven reducidas en funciones ms pequeas y manejables para poder ser desarrolladas dentro de las iteraciones. Clases individuales, con esto se refiere al hecho de que los propietarios de clases son los encargados de disear y desarrollar sus propias clases, aumentando as la eficiencia gracias al conocimiento que se tiene sobre la clase y mtodos propios. Inspecciones Regulares, que se llevan a cabo para mantener controlado el desarrollo y asegurar una calidad aceptable y requerida por los usuarios. Gestin de la Configuracin, esta prctica ayuda a separar el cdigo de las funcionalidades completas hasta la fecha as como llevar un control de versiones e historial de cambios. Versiones Estables, el propio mtodo en si requiere que tras cada iteracin surjan varias funcionalidades, que no dejan de ser versiones usables y estables de caractersticas del programa ayudando as en la correccin de errores.

La visibilidad de los avances y resultados, debido a que los tiempos de las iteraciones son relativamente cortos los avances quedan patentes enseguida ayudando en las posibles correcciones.

3.6.


http://www.willydev.net/descargas/Articulos/General/cualxpfddrup.PDF http://en.wikipedia.org/wiki/Feature-driven_development http://www.agilemodeling.com/essays/fdd.htm http://materias.fi.uba.ar/7500/schenone-tesisdegradoingenieriainformatica.pdf http://www.ecured.cu/index.php/Metodolog%C3%ADa_FDD http://seccperu.org/files/Metodologias%20Agiles.pdf

14


4. AUP (Agile Unified Process)4.1. Introduccin

El Proceso Unificado gil es una variante ms sencilla del RUP que aplica tcnicas giles incluyendo Desarrollo Dirigido por Pruebas (TDD), Modelado gil, Gestin de Cambios gil, y Refactorizacin de Base de Datos para mejorar la productividad. La filosofa del AUP: El personal sabe lo que est haciendo. Aunque no estn obligados a leer en detalle el proceso de documentacin existen unas referencias para los que estn interesados. Simplicidad. Todo se describe de forma concisa con un puado de pginas. Agilidad. El AUP se ajusta a los valores y principios del desarrollo gil de software y de la Agile Alliance. Prioridad en actividades de alto valor. La atencin se centra en las actividades que realmente cuentan. Independencia de herramientas. Se puede usar cualquier conjunto de herramientas con la AUP. Lo recomendable es usar las herramientas adecuadas para cada trabajo que suelen ser herramientas simples y fciles de usar.

4.2.

Las disciplinas

En comparacin con las disciplinas del RUP que son 9, el AUP tiene solamente 7 de las cules algunas son combinaciones de dos disciplinas del RUP. 1. Modelado: Entender el negocio de la organizacin, el problema de dominio que se abordan en el proyecto, y determinar una solucin viable para resolver el problema de dominio. 2. Implementacin: Transformar el modelo en cdigo ejecutable y realizar un nivel bsico de pruebas individuales. 3. Pruebas: Realizar una evaluacin objetiva para garantizar la calidad. Esto incluye la bsqueda de defectos, validar que el sistema funciona tal como est establecido, y verificar que se cumplan los requisitos. 4. Despliegue: Realizar un plan para la presentacin del sistema y ejecutarlo para hacer que el sistema se encuentre a disposicin de los usuarios finales. 5. Gestin de Configuracin: Realizar la gestin de acceso a artefactos del proyecto. Esto incluye no slo el seguimiento de las versiones del artefacto en el tiempo, sino tambin el control y la gestin de cambios para ellos. 6. Gestin del Proyecto: Dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestin de los riesgos, la direccin de personas (la asignacin de tareas, el seguimiento de los progresos, etc), y coordinar con las personas para garantizar que se entrega a tiempo y dentro del presupuesto. 7. Entorno: Garantizar la orientacin (normas y diectrices) y que las herramientas (hardware, software, etc) estn disponibles para el equipo segn cuando lo necesiten.

15


4.3.

Las fases

4.3.1. Inicio Metas: Identificar el alcance inicial de proyecto, una arquitectura inicial del sistema y obtener un presupuesto inicial del proyecto y una aceptacin de los involucrados. Hitos: Objetivos de Ciclo de Vida (Lifecycle Objectives, LCO). 4.3.2. Elaboracin Metas: Probar arquitectura del sistema. Hitos: Arquitectura del Ciclo de Vida (Lifecycle Architecture, LCA). 4.3.3. Construccin Metas: Construir un software funcional sobre una base regular e incremental, las cuales cumplan con las prioridades ms importantes para los involucrados o usuarios del proyecto. Hitos: Capacidad Operacional Inicial (Initial Operating Capacity, IOC). 4.3.4. Transicin Metas: Validar y desplegar el sistema en su ambiente de la produccin. Hitos: Liberacin del Producto (Product Release, PR).

4.4.

Entrega de versiones

16


En lugar de entregar todo el software a la vez, se produce por partes. Los equipos de desarrollo que aplican AUP suelen ofrecer versiones al final de cada iteracin. A menudo la primera liberacin lleva ms tiempo que las versiones posteriores ya que se desarrolla la mayor parte de la arquitectura. Por ejemplo, la primera entrega puede hacerse en doce meses, la segunda en nueve y el resto cada seis meses.

4.5.

Roles

DBA gil: Un administrador de bases de datos (DBA) que trabaja de manera colaborativa con los integrantes del equipo del proyecto para disear, probar y brindar soporte a los diferentes esquemas de datos. Participa en Implementacin. Modelador gil: Crea y desarrolla modelos, ya sean dibujos, tarjetas, o archivos complejos realizados con herramientas CASE, de manera colaborativa y evolutiva. Participa en Modelado e Implementacin. Administrador de la configuracin: Proporciona la infraestructura y crea el entorno para el equipo de desarrollo. Participa en Gestin de Configuracin. Implementador: Dispone el sistema en los entornos de pre-produccin y produccin. Participa en Desarrollo. Desarrollador: Escribe cdigo, realiza pruebas y construye el software. Participa en Modelado, Implementacin y Despliegue. Especialista del proceso: Desarrolla, adapta y apoya el material de los procesos de la organizacin (descripcin de procesos, plantillas, guas, ejemplos, entre otros). Participa en Entorno. Administracin del proyecto: Administra los miembros de los equipos de trabajo, crea relaciones con los involucrados, coordina las interacciones con los involucrados, planea, administra y dispone recursos, enmarca prioridades y mantiene el equipo enfocado. Participa en Modelado, Pruebas, Despliegue y Gestin del Proyecto. Examinador: Evala los productos del proyecto, inclusive "el trabajo en progreso", suministrando retroalimentacin al equipo de trabajo. Participa en Pruebas. Involucrado: Cualquiera que sea usuario directo, usuario indirecto, administrador de usuarios, administrador, miembro de equipo de operacin o soporte, desarrolladores que trabajan en otros sistemas que se integran o interactan con el sistema implementado. Todo aquel que se vea afectado de una u otra forma con el proyecto. Participa en Modelado, Implementacin, Pruebas, Despliegue y Gestin del Proyecto. Documentador tcnico: Es responsable de producir documentacin para los involucrados, tal como materiales de capacitacin, documentacin de operaciones, documentacin de mantenimiento y documentacin de usuario. Participa en Despliegue. Administrador de pruebas: Es el responsable del xito de las pruebas, incluye planificar la administracin, y promover las pruebas y las actividades de calidad. Participa en Pruebas.

17


Equipo de pruebas: Responsables de ejecutar las pruebas y documentar los resultados que proyecten. Participa en Pruebas. Especialista en herramientas: Selecciona, adquiere, configura y ofrece mantenimiento al equipo requerido. Participa en Entorno.

4.6.

Artefactos

El AUP distingue entre: Entregable que se debe producir como un artefacto permanente de trabajo del sistema. Otros artefactos de trabajo del proyecto que probablemente se descartarn porque no se necesita mantenerlos en el tiempo. Artefactos de trabajo de la organizacin que son mantenidos dentro del servicio tcnico y compartido a travs de proyectos.

4.6.1. Entregables mnimos El mnimo de entregables para un AUP en orden prioritario son: Sistema. Cdigo fuente. Scripts de Instalacin. Documentacin del Sistema. Notas. Modelado de requerimientos. Modelo de Diseo.

4.6.2. Entregables de Negocio Equipos de la empresa (por ejemplo, los arquitectos, administradores de bases de datos,) proporcionan el seguimiento de artefactos para ayudar a orientar y facilitar los esfuerzos del proyecto: Modelo de la Arquitectura de Negocio. Orientacin del Desarrollo de Negocio. Orientacin de la Empresa. Estado de la Misin de la Organizacin. Visin de la Empresa. Guas de Recursos Humanos. Guas de Modelado. Arquitectura de Referencia. Guas de Usabilidad.

18


4.6.3. Otros artefactos del Proyecto Pruebas de Aceptacin Oportunidades de Automatizacin Presupuesto Modelado de Procesos de Negocio Especificaciones de las Reglas de Negocio Reporte de Defectos Modelado de Despliegue Modelado de Dominio Estimacin Modelado de Objetos Operaciones de Documentacin Evaluacin de la Organizacin Modelado de la Organizacin Modelo de Datos Fsico (PDM) Glosario del Proyecto Descripcin General del Proyecto Plan del Proyecto Recursos del Proyecto Cronograma del Proyecto Prueba del Concepto Prototipo Lista de Riesgos Modelado de Amenazas de Seguridad Documentacin de Soporte Documento de la Descripcin General del Sistema Requerimientos Tcnicos Pruebas de Modelado Estrategia de Pruebas Herramientas utilizadas Materiales de Capacitacin Casos de Uso Modelado de Casos de Uso Documentacin de Usuario Modelo de Interface de Usuario

4.7.

Referencias

http://cgi.una.ac.cr/AUP/ http://www.ambysoft.com/unifiedprocess/agileUP.html http://es.wikipedia.org http://en.wikipedia.org

19


5. Comparacin de metodologas5.1.

Comparativa

Las metodologas giles estn centradas en diferentes fases del ciclo de vida de desarrollo del software. Algunas se enfocan a las fases de pruebas como puede ser FDD, otras al inicio y especificacin de requisitos como AUP, solo una cubre todas las fases, DSDM y la mayora contemplan el ncleo de las fases del ciclo de vida (Diseo, codificacin y pruebas). Con respecto a las reas estudiadas, algunas metodologas estn ms enfocadas a presentar diferentes prcticas como es el caso de FDD, otras a la gestin de proyectos, como AUP, Crystal e incluso DSDM. Algunas metodologas son excesivamente abstractas, o esa es la impresin que nos deja el caso de Crystal y DSDM, que no establece ninguna prctica concreta o artefacto a realizar, si que puede exigir algunos artefactos, pero nunca establece como los quiere o como hacerlos. Por separado no parecen factible utilizarlas como metodologas nicas para un proyecto, necesitan alguna otra que las complemente o la adopcin de prcticas y procesos aislados complementarios. Crystal a pesar de cubrir muy pocas fases del ciclo de vida, exige la existencia y creacin de artefactos en otras fases, como es la fase de especificacin. Crystal requiere de un documento de especificacin, preferiblemente que siga la tcnica de especificacin mediante casos de uso, pero no la incluye en la descripcin de ninguna sus metodologas. La nica metodologa con un proceso prescriptivo es Crystal, esto es debido a que la seleccin del tipo de metodologa se hace en funcin del tamao del proyecto, el grado de criticidad y la prioridad del mismo. Una vez escogida la metodologa se deben seguir las reglas especificadas. A pesar de esta situacin, Crystal no condiciona en exceso un proyecto del software, si realmente es adecuado para aplicar mtodos giles, ya que es perfectamente compatible con otros mtodos giles que ofrecen una gua ms concreta, como puede ser FDD.

5.2.

Ventajas y desventajas de cada metodologaVentajas Todos los cambios durante el desarrollo son reversibles. Los requerimientos estn especificados a un alto nivel. El testing es integrado a travs del ciclo de vida. Por centrarse en la criticidad ayuda en la definicin y control Desventajas - Dificultad media computacional. - Los equipos deben tener el poder de tomar decisiones.

Metodologa DSDM Crystal -

- Muy pesado. - No es una metodologa rgida y,

20


FDD

AUP

del sistema. por tanto, deja la posibilidad de - Existe gran comunicacin entre agregar o suprimir fases o los miembros del equipo. tcnicas que puedan afectar el - Propone una gran cantidad de desarrollo del proyecto. tcnicas y estrategias. - No se establecen leyes para el desarrollo. - Flexibilidad: a mayor necesidad - Necesidad de contar con de cdigo, mayor organizacin. miembros experimentados en - Primero se recogen los requisitos el equipo. y despus se escoge cmo se va a - Ms restrictivo en la proceder. implementacin. - Mnima documentacin - Posible dependencia de los necesaria. miembros con cargos ms altos. - El personal sabe lo que est - Muy pesado en relacin a otras haciendo. metodologas. - Simplicidad. - Al ser tan simple, muchos los - Agilidad. descartan por falta de detalles - Se centra en actividades de alto para los desarrolladores. valor de negocio.

5.3.

Conclusiones

Las metodologas giles no contemplan todo el ciclo de vida tal y como lo hemos visto tradicionalmente, si queremos seguir todas y cada una de las fases de este necesitamos utilizar otras metodologas (RUP) o complementarlas, combinndolas entre ellas. El estado actual de las metodologas giles es activo y ganando cada vez ms adeptos. Las metodologas que hemos seleccionado no podan sino indicarnos esto, ya que fue uno de los criterios de seleccin de las mismas. Las metodologas giles pueden presentar guas muy concretas, con tcnicas muy especficas, como es el caso de FDD y DSDM, o por el contrario mostrar guas abstractas, mtodos que nos guan para realizar el mismo trabajo de una manera ms eficiente (Crystal). Los roles que presentan las diferentes metodologas giles no difieren en exceso, presentan siempre a un representante del cliente, normalmente responsable de verificar el cumplimiento de los requisitos, un experto en la metodologa para guiar al equipo, un gestor del proyecto y el equipo de desarrolladores (con mayor o menor detalle).

21

Documents

Práctica 3 - AESMcooking