Prctica 3 Metodologas giles AESM

Javier Soler Cano Toms Alema Baeza Laura Fuentes Boj

ndice

DSDM (Dynamic System Development Method) ........................................................ Pgina 3

FDD (Feature Driven Development) ........................................................................... Pgina 10

AUP (Agile Unified Process) ........................................................................................ Pgina 17

Conclusiones .............................................................................................................. Pgina 25

Tabla Comparativa ..................................................................................................... Anexo I

#MultiAESM

Dynamic Systems Development Methods (DSDM)

Se trata de un proceso de desarrollo gil, que se caracteriza por que hace participe en todo momento al usuario, es decir, el usuario est presente en todo el desarrollo. Se trata de un proceso iterativo y creciente, por lo que los requerimientos que se necesitan en l pueden ir variando en cada iteracin, esto proporcionara un sistema que rena las necesidades del cliente. DSDM fue desarrollado en Reino Unido en los aos 90, a lo largo de su historia se han creado diferentes versiones, actualmente la versin que se est utilizando de DSDM es la 4.2 que fue desarrollada en abril de 2006.

Principios
El proceso de DSDM esta basado en 9 principios fundamentales, son esenciales para cualquier implementacin de DSDM, se deben cumplir los 9 principios, ya que si no se cumplen pueden aumentar los riesgos del proyecto. 1. La participacin activa del usuario es la clave principal del DSDM. Gracias a la participacin del usuario en el proyecto se reducen los errores en cuanto a la percepcin que el usuario tiene sobre el producto, por lo que los costes de error se reducen. Por otro lado se recomienda trabajar con un grupo pequeo de usuarios elegidos cuidadosamente, tambin se pretende que las reuniones con los usuarios sean continuas por si aparecen nuevos requisitos. 2. El equipo del proyecto tiene que tener el poder de decisin. Para que el avance en el proyecto sea ms rpido, el equipo tiene que poder tomar decisiones importantes sin tener la necesidad de contactar con niveles superiores para la aprobacin de recursos, ya que solicitar la autorizacin de los recursos supone un retraso significativo del proyecto.

#MultiAESM

3. Entrega Frecuente de Productos Al entregar de forma frecuente los resultados se aseguran que los errores se detectan de forma fcil y se solucionan de manera efectiva. Esto se aplica tanto al producto, como a la documentacin (artefactos) y a los requisitos. 4. Sistema que satisface las necesidades de negocio Se deben realizar entregas que satisfagan las funcionalidades que son ms importantes en el sistema, hay que centrarse en las necesidades que resultan ms importantes, esto permitir que las revisiones que se realicen del proyecto comiencen desde el punto ms importante del proyecto y vaya disminuyendo el nivel de importancia conforme vamos realizando diversas revisiones. 5. El desarrollo es iterativo e incremental Para que el proyecto sea mas manejable es necesario descomponerlo en proyectos ms pequeos y con menos caractersticas, cada nueva versin (iteracin) aadir nuevas caractersticas hasta completar el conjunto de requisitos. 6. Todos los cambios realizados en el proceso son reversibles. Este punto es bastante importante, ya que el usuario puede haber cometido algn error al especificar la funcionalidad de una parte del proyecto, gracias a este principio se podr rehacer la funcionalidad si fuese preciso. 7. Alcance de alto nivel Los requisitos de mayor nivel han de ser pactadas y aceptadas entre las diferentes partes que participan en el proyecto, estos acuerdos deben realizarse antes de que de comienzo el proyecto. 8. Las pruebas son realizadas durante todo el ciclo de vida del proyecto. Las pruebas no solamente se realizan entre iteraciones sino que tambin se realizan en las diferentes entregas que realicemos del producto. Gracias a esto se logran detectar ms pronto los errores por lo que se disminuye el coste de correccin.

#MultiAESM

9. Colaboracin y Cooperativa La comunicacin y cooperacin entre las partes del proyecto es indispensable para obtener un producto eficiente y eficaz. Aparte de los principios anteriores, DSDM se apoya en otra serie de principios denominados supuestos (Assumptions), destacamos los siguientes: Ningn sistema es construido a la perfeccin en el primer intento, se rige siguiendo la filosofa del Principio del Pareto, que dice que el 80% de los objetivos de una solucin se puede desarrollar con el 20% de esfuerzo. La entrega del proyecto debe ser a tiempo, respetando los presupuestos y con buena calidad. DSDM solo requiere que cada paso del desarrollo se complete lo suficiente como para que empiece el siguiente paso, se empezara un nuevo paso siempre y cuando no se entorpezca con el anterior. DSDM puede ser usado en proyectos que no han sido desarrollados siguiendo esta metodologa.

Ventajas e Inconvenientes
Las principales ventajas de esta metodologa se encuentran reflejadas en los nueve principios del DSDM, a continuacin los nombramos de forma resumida Implicacin activa del usuario, esto implica que se reduzcan los costes ya que el usuario estar pendiente de todas las actualizaciones del sistema. El equipo tiene el poder de tomar las decisiones importantes Entrega peridica de productos, hace que el proyecto se desarrolle de forma ms rpida y efectiva. Intenta cumplir las metas y objetivos del negocio. Se trata de una metodologa iterativa e incremental, por lo que el diseo inicial mejora constantemente. Todos los cambios son reversibles. Asegura que los requisitos mas importantes se cumplas. Se realizan pruebas a lo largo de todo el ciclo de vida. Garantiza que todos los objetivos son atendidos.

#MultiAESM

La principal desventaja que encontramos es que se trata de una metodologa costosa de implementar, y tambin se necesita que tanto los desarrolladores como los usuarios tengan la experiencia necesaria para poder desarrollar el proyecto, por lo tanto no se puede adecuar para pequeas organizaciones o para proyectos puntuales.

Fases
A continuacin estudiaremos las diferentes fases de las que esta compuesta la metodologa de DSDM, esta compuesta por tres fases que se realizan de forma secuencial. Pre-proyecto En esta fase se definen las caractersticas fundamentales que tendr el proyecto, como, quienes son los departamentos y personas implicadas, los compromisos de las partes, quienes financiarn el proyecto, etc. Ciclo de vida del proyecto Esta fase esta formada por 5 etapas diferenciadas. Estudio de la viabilidad: en esta fase se abordaran los posibles costes y la viabilidad tcnica del sistema para resolver problemas de negocio, tambin se estudiaran los posibles riesgos del proyecto.

Estudio de negocio: El estudio de negocio trata de realizar un anlisis mas en profundidad de los procesos que se van a informatizar, en este apartado la implicacin del usuario es importante. En esta fase se obtiene un modelo de procesos donde se identifican quienes son los usuarios clave en cada uno de dichos procesos, un esquema de requisitos ordenados por prioridad, la arquitectura del sistema (Artefactos).

Iteracin del Modelo Funcional: trata de perfeccionar los aspectos que se han destacado en el Estudio de Negocio, esta formado por diferentes fases. Identificacin del prototipo funcional: Define las funcionalidades del prototipo y elabora un modelo funcional de dicho prototipo. Definicin del calendario: Se acuerda el plan de trabajo. #MultiAESM

Obtencin del prototipo funcional. Revisin del prototipo funcional.

Iteracin del diseo y el desarrollo: en esta fase el sistema esta diseado en un nivel lo suficientemente algo como para entregarlo al usuario. Formado por diversas fases Identificacin del prototipo de diseo Definicin del calendario Crear el prototipo de diseo Revisin del prototipo de diseo

Implementacin: es la transicin de entorno de desarrollo a entorno operacional, podemos destacar diversas fases. Aprobacin del usuario Formacin Implementacin Revisin de negocio

Post-proyecto El objetivo de esta fase es que el sistema siga siendo til para posteriores necesidades de los usuarios, es decir esta fase tratara tanto el mantenimiento como la actualizacin del sistema.

Tcnicas
Existen muchas tcnicas basadas en DSDM, como, MoSCoW, Prototipos, Exmenes, Talleres, TimeBoxing, etc. TimeBoxing Se utiliza para apoyar los objetivos principales del DSDM para realizar el desarrollo de un sistema a tiempo, dentro del presupuesto y con la calidad deseada. Est pensado para tareas largas, que no son prioritarias pero conviene realizarlas lo antes posible.

#MultiAESM

El TimeBoxing pretende dividir el proyecto en partes, cada una de ellas con un presupuesto y una fecha de entrega fija. Consiste en dedicar un tiempo limitado a una tarea y dedicarse al 100% durante el tiempo propuesto.

MoSCoW Representa una forma de priorizar los temas, hay que tatar de priorizar las necesidades (requisitos).Esta formado por una serie de principios que son. Must (Debe): todas las funcionalidades de este grupo deben estar implementadas, si estas caractersticas no se implementan el sistema no funcionaria. Should (Debera): las funcionalidades de este grupo son importantes para el sistema pero se pueden omitir si suponen un retraso en la entrega del sistema. Could (Podra): las funcionalidades de este grupo mejoran el sistema. Want (Quieres): las funcionalidades de este grupo solo sirven para un grupo limitado de usuarios y su valor suele ser bastante bajo.

Taller Es una tcnica esencial utilizada para tomar decisiones de forma rpida, efectiva y eficiente. Los talleres son una herramienta til para promover cambio y rpida aceptacin en una organizacin.

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 mas poder tiene ala 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.

#MultiAESM

Asesor del usuario: puede cualquier usuario que representa un punto de vista importante y aporta conocimiento diario del proyecto. Gerente del Proyecto: Persona 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 diferentes pruebas del sistema. Scribe(Escriba): recopila informacin sobre los requisitos.

Herramientas que desarrollan DSDM

A la hora de buscar software que desarrolle metodologas DSDM no hemos encontrado demasiadas aplicaciones que la desarrollen, principalmente encontramos una denominada SpiraPlan que desarrolla mas metodologas aparte de la DSDM. SpiraPlan: Se trata de una herramienta que proporciona un sistema completo para la administracin de proyectos basados en metodologas agiles, soporta diversas tecnologas como Extreme Program(XP), SCRUM, Agile Unified Process, Spiral y DSDM. Esta herramienta permite tener un control del desarrollo del proyecto y sus avances hasta que el proyecto es finalizado. Es uno de los software mas flexibles y agiles a la hora de la planificacin de sistemas.

#MultiAESM

Feature Driven Development (FDD)

Feature Driven Development (Desarrollo basado en las funcionalidades) es una metodologa gil usada para el desarrollo de software, no hace hincapi en la obtencin de requisitos, sino en el modo en que se realizarn las fases de diseo y construccin, su objetivo es la calidad. Es una metodologa iterativa, con iteraciones cortas, cuyo resultado es un software funcional que tanto el cliente como la direccin de la empresa, pueden monitorizar su desarrollo.

Caractersticas
Dispone de etapas de cierre cada dos semanas. Se obtienen resultados peridicos y tangibles, por lo que disminuye el riesgo, gracias al constante monitoreo de su calidad, por parte del cliente y directivos. No cubre todo el ciclo de vida, slo las fases de diseo y construccin. Se complementa con otras metodologas. Rpidas adaptaciones a cambios en los requisitos y necesidades. Cada fase posee un hito de entrada y un hito de salida (Artefactos). Pensado para proyectos y equipos pequeos, aunque es escalable. Al dividir las tareas en unidades ms pequeas, es bastante fcil hacer un seguimiento de la evolucin del proyecto. Esta metodologa se basa en una comunicacin fluida con el cliente.

Inconvenientes
Necesidad de tener en el equipo miembros con experiencia que guen al resto. En un equipo pequeo se deben repartir 31 roles y generar ms 100 artefactos.

10

#MultiAESM

Roles
Debemos saber que un miembro del equipo puede tener ms de un rol a cargo y de la misma forma, un nico rol puede ser compartido por varios miembros del equipo.

Roles clave

Director de proyecto (Project Manager) Lder administrativo y financiero del proyecto. Protege al equipo de situaciones externas.

Arquitecto jefe (Chief Architect) Se encarga del diseo global del sistema.

Director de desarrollo (Development Manager) Actividades de desarrollo. Resuelve conflictos en el equipo. Resuelve conflictos referentes a recursos.

Programador jefe (Chief Programmer) Anlisis de requisitos. Disea el proyecto. Selecciona funcionalidades a desarrollar en cada iteracin.

Propietario de clases (Class Owner) Responsable del desarrollo de sus clases (asignadas prev.)

Experto de dominio (Domain Expert) Puede ser un cliente, patrocinador, analista o una mezcla. Poseen conocimientos acerca del sistema (Requerimientos). Transmite los conocimientos a los desarrolladores.

11

#MultiAESM

Roles de soporte

Director de dominio (Domain Manager) Lidera a los expertos de dominio. Resuelve conflictos entre los expertos de dominio.

Director de entrega (Domain Release) Controla el avance a travs del programador jefe. Enva resultados al cliente y al director del proyecto.

Herramentista (Toolsmith) Construccin de herramientas especficas para el desarrollo. Conversin de datos y pruebas. Puede hacer BBDD o WEB destinados al proyecto.

Administrador del sistema (System Administrator) Configura y repara servidores, hosts del equipo, red, etc.

Gur del lenguaje (Language Lawyer) Conoce a la perfeccin el lenguaje o la tecnologa. Muy importante si se trabaja con una nueva tecnologa.

Ingeniero de construccin (Build Engineer) Responsable de preparar, mantener el proceso de construccin. Mantenimiento de las versiones y documentacin.

Roles adicionales

Tester Puede ser independiente al equipo del proyecto.

Escritor de documentos tcnicos (Technical Document Writer) Prepara la documentacin del proyecto y manuales.

12

#MultiAESM

Fases
La metodologa se compone de cinco fases secuenciales centradas en el diseo y la construccin del software, las tres primeras fases se hacen al comienzo del proyecto.

Desarrollo de modelo de negocio: Con el inicio del desarrollo, los expertos de dominio estn al tanto de la visin, el contexto y los requerimientos del sistema a construir. Durante esta fase se realizan evaluaciones para asegurar el entendimiento de los aspectos del dominio en el equipo, su alcance y su funcionalidad, una vez modelado se realizan controles sobre el modelo resultante.

Hito de entrada: El cliente est preparado para comenzar con la construccin del sistema, tiene claro de alguna forma funcionalidades a especificar.

Hito de salida: Diagrama de clases. Lista preliminar de funcionalidades. Documentacin de alternativas importantes.

Construir listado de funcionalidades1: Los desarrolladores elaborarn una lista de funcionalidades2 que debe cumplir el sistema y que posteriormente ser evaluada por el cliente para dar su aprobacin.

Tras la identificacin de todas las funcionalidades y haber generado la lista, sta se subdividir dependiendo de la afinidad, la dependencia y su importancia en el desarrollo que exista entre cada una de las funcionalidades, como el uso de un mismo recurso por un conjunto de funcionalidades, por ltimo se deber ordenar la lista en funcin de la prioridad que tenga cada funcionalidad. En caso de que haya funcionalidades complejas, stas se subdividirn en otras ms pequeas.

1 2

Estas funcionalidades son pequeos tems tiles a los ojos del cliente. Las funcionalidades que requieran ms de diez das, se descompondrn en otras ms pequeas.

13

#MultiAESM

Hito de entrada: Para comenzar con esta etapa deberemos contar con el diagrama de clases y la lista preliminar de funcionalidades, ambos son artefactos creados en la etapa anterior.

Hito de salida: El equipo encargado de la construccin de la lista debe haber estudiado y analizado cada funcionalidad del sistema, y haberlas agrupado en distintas sublistas. Lista de funcionalidades.

Planificacin de cada funcionalidad: Llegados a esta fase, el equipo de planificacin establecer el orden y la secuencia en el que se desarrollar cada funcionalidad. Se asignar las clases a los class owner y las funcionalidades ms importantes a los programadores jefes.

Hito de entrada: Para comenzar con esta etapa deberemos contar con la lista de funcionalidades, artefacto creado en la etapa anterior.

Hito de salida: Cronograma completo. Cada funcionalidad con su programador y fechas de inicio y fin. Cada clase con su class owner.

Diseo de cada funcionalidad (DBF): Se seleccionan las sublistas de las funcionalidades agrupadas por afinidad y dependencia, y se construye un diagrama de secuencia dnde aparece la relacin entre las funcionalidades y cmo se van a desarrollar. Tambin deben quedar especificados clases y mtodos.

14

#MultiAESM

Hito de entrada: Para comenzar con esta etapa deberemos contar con los artefactos creados en la etapa anterior. Hito de salida: Diagrama de secuencia detallado. Diagrama de clases actualizado. Descripcin de clases y mtodos. Notas consideradas importantes para el diseo.

Construccin de cada funcionalidad (BBF): Iterativamente se procede hasta producir las funcionalidades identificadas anteriormente, dichas iteraciones se componen de inspeccin del diseo, codificacin, pruebas, integracin e inspeccin del cdigo.

Hito de entrada: Para comenzar con esta etapa deberemos contar con los artefactos creados en la etapa anterior. Hito de salida: Implementacin e inspeccin de mtodos. Pruebas unitarias de cada mtodo. Repaso de las clases. Construccin principal del sistema. Pruebas de integracin

Herramientas de soporte
MOSKITT: Es una herramienta libre que da soporte a metodologas de desarrollo, fue promovido y liderado por la Generalitat Valenciana, su mayor objetivo es intentar crear la ilusin de sencillez. Segn las necesidades, puede considerarse: Herramienta para anlisis, diseo e implementacin del software. Editor de Modelos de Procesos (Modelo de negocio) Editor de Esquemas de BBDD Relacionales Editor de Modelos de Sistemas Software (Diagramas, clases ) Modelado de Interfaces de Usuario Proporciona soporte a etapas de desarrollo. Tareas personalizadas para los participantes. (Roles) #MultiAESM

15

Agile Unifed Process (AUP)

El AUP es una versin simplificada del Rational Unified Process (RUP). En l se describe un mtodo sencillo, fcil de entender para el desarrollo de software de aplicaciones empresariales utilizando tcnicas giles, y conceptos que permanecen fieles a RUP. El AUP aplica tcnicas giles incluyendo el Desarrollo Dirigido por Pruebas (TDD), Modelado gil, gestin de cambios gil, y refactorizacin de Base de Datos para mejorar la productividad. La agilidad no es un concepto de todo o nada, sino una entidad que puede tener distintos grados de agilidad. Una entidad puede estar latente o inactiva, en cuyo caso no responde necesariamente a su entorno. Los orgenes de la agilidad se puede encontrar la filosofa de la guerra, as como la teora de la complejidad y los negocios y la manufactura y se expresa utilizando tres patrones esenciales: Individuos e interacciones: Sobre procesos y herramientas Trabajo de software: En una amplia documentacin Colaboracin con el cliente: Sobre negociacin de contratos Responder al cambio: Sobre seguir un plan

Principios
El personal sabe lo que estn haciendo, las personas no van a leer documentacin de procesos detalladamente, pero tambin quieren alguna gua de alto nivel y/o capacitaciones de vez en cuando. Este producto proporciona vnculos a muchos de los detalles.

Simplicidad, todo se describe brevemente utilizando un puado de pginas.

Agilidad, el AUP se ajusta a los valores y principios de la Alianza Agile.

Enfocar las actividades de alto nivel, se centra en las actividades que realmente cuentan, no es cada cosa posible que podra pasarle en un proyecto.

16

#MultiAESM

Independencia de herramientas, se pueden usar las herramientas que quiera, pero se sugiere que se utilicen las ms adecuadas para el trabajo que a menudo son herramientas simples o de cdigo abierto.

Adaptar el producto para satisfacer las propias necesidades, el producto es de fcil ajuste a travs de cualquier herramienta de edicin de HTML.

Ciclo de vida
El AUP define las metas y objetivos, se colabora para lograr resultados. Una colaboracin puede ser un trabajo individual o interactuacin con los dems.

Las metas son similares a las fases hasta donde se utilizan como puertas que involucran a las partes interesadas y los usuarios.

El enfoque de iniciar (concepcin) es establecer la visin del producto, el proyecto de plan de trabajo, los negocios y la justificacin de tecnologa, e identificar los riesgos y oportunidades. Puede haber uno o ms objetivos que deben lograrse para alcanzar este objetivo.

Las partes interesadas se centran en el problema, solucin y limitaciones. Los usuarios se centran en sus necesidades y caractersticas de los productos de alto nivel.

Las partes interesadas y los usuarios se centran en el establecimiento de la justificacin de negocio para el producto y proyecto.

Los usuarios y el equipo de desarrollo de software se centran en el establecimiento de la justificacin de la tecnologa para el producto y proyecto.

El equipo (equipo de desarrollo, partes interesadas y usuarios) se centran en priorizar los riesgos y oportunidades.

El equipo se centra en relacionar las caractersticas del producto para ejecutar (innovacin), las metas y objetivos en el plan de trabajo del proyecto.

El equipo establece el desarrollo de la infraestructura.

17

#MultiAESM

FASES
Inicio El objetivo principal de la fase de iniciacin es archivar el consenso de los interesados del proyecto en relacin a los objetivos del proyecto. Las principales actividades de esta fase incluyen: Definir el alcance del proyecto Esto incluye la definicin, a un alto nivel, de qu es lo que har el sistema. Es igual de importante definir qu es lo que el sistema no va a hacer. Aqu se establecen los lmites desde donde el equipo operar. Esto suele tomar forma de lista de caractersticas de alto nivel y/o punto de casos de uso. Estimacin de costos y calendario En un nivel alto, el calendario y coste del proyecto son estimaciones. Las estimaciones generales son realizadas en iteraciones de fases posteriores, en la fase de elaboracin. Como en todas las planificaciones, las tareas que se implementarn ms adelante deben definirse y detallarse con precisin. Definicin de riesgos Aqu se definen los riesgos del proyecto, es una parte importante. La lista de riesgos cambiar en cuanto se identifiquen, eviten y/o materialicen y se eliminen los mismos.

18

#MultiAESM

El control de riesgos, como los riesgos de mas alta prioridad, manejan la programacin de las iteraciones. Determinar la factibilidad del proyecto El proyecto debe tener sentido desde la perspectiva tcnica, operacional y del negocio, es decir si el proyecto no es capaz de ser creado, implementado, y tener sentido econmico debe cancelarse. Preparar el entorno del proyecto Reservar reas de trabajo para el equipo, solicitar el personal, obtener software y hardware que ser requerido. Ajustar el AUP para completar las necesidades del equipo. Para salir de esta etapa de iniciacin el equipo debe completar el hito, y se procede a la siguiente fase, de otra forma se cancelar. Disciplinas en esta fase:
Disciplina Actividades Principales Modelado Implementacin Pruebas Despliegue Administracin de la Configuracin Administracin del Proyecto Inicial, modelado de requerimientos de alto nivel Inicial, modelado de la arquitectura de alto nivel Prototipado tcnico Prototipado de interfaces de usuario Plan de pruebas inicial Revisin inicial de producto del proyecto Revisin inicial de modelos Identificar la ventana potencial de liberacin Iniciar el plan de despliegue de alto nivel Establecer la configuracin del entorno Colocar todos los productos bajo el Control de la Configuracin. Inicia la creacin del equipo. Crear relaciones con los interesados del proyecto. Determinar la factibilidad del proyecto. Determinar un cronograma de alto nivel para el proyecto. Desarrollar un plan de iteraciones para las siguientes iteraciones.

19

#MultiAESM

 Entorno

Administre el riesgo. Obtenga el apoyo y financiamiento de los interesados. Cerrar la fase Establecer el entorno de trabajo Identificar la categora del proyecto

Elaboracin El objetivo principal de esta fase es probar la arquitectura del sistema a desarrollar. Hay que asegurar que el equipo puede desarrollar un sistema que satisfaga los requisitos, para ello se debe desarrollar prototipo de la arquitectura. Es importante sealar que los requisitos no se especifican por completo en este punto, se detallan lo suficiente como para entender los riesgos de la arquitectura y se comprenda los alcances de los requerimientos para que la planificacin posterior se pueda llevar a cabo. Durante la elaboracin el equipo prepara la fase de construccin, los planes de comunicacin y la colaboracin se finalizan en esta fase. Para terminar esta fase, el quipo debe pasar el hito, los principales puntos de este hito son si el equipo ha demostrado tener un prototipo de trabajo que muestra una estrategia viable para construir el sistema y que los interesados estn dispuestos a seguir financiando el proyecto, si el equipo pasa esta etapa, se procede a la siguiente fase: construccin. Las disciplinas durante esta fase son:

Disciplina

Actividades Principales Identificar los riesgos tcnicos Modelado de la Arquitectura Prototipo de Interfaces de Usuario Probar la arquitectura Validar la arquitectura

Modelado

Implementacin Pruebas

20

#MultiAESM

Evolucionar su modelo de pruebas Actualizar su plan de desarrollo Poner todos los productos bajo la Control de Administracin de la Configuracin (CM control)

Despliegue Administracin de la Configuracin

Administracin del Proyecto Entorno

Construir el equipo Proteja el equipo Obtenga los recursos Maneje el riego Actualice su plan de proyecto Cierre la fase Evolucione el entorno de trabajo Ajuste los materiales de procesos

Construccin El objetivo de esta fase consiste en desarrollar el sistema hasta el punto que est listo para la pre-produccin de pruebas. En etapas anteriores, la mayora de los requisitos han sido identificados y la arquitectura del sistema establecida. Comprender y priorizar los requerimientos, modelado que ataca una solucin y luego, la codificacin y pruebas del software. Si es necesario, las primeras versiones se desarrollan ya sea interna o externamente para obtener los comentarios de los usuarios. Para salir de esta fase se debe completar el hito, que es que el sistema esta preparado para entrar en la pre-produccin de su entorno de prueba y las pruebas de aceptacin. Si se pasa esta etapa procedemos a fase de transicin. Las disciplinas para esta fase son:

21

#MultiAESM

Disciplina

Actividades Principales Abordaje del Anlisis del Modelado Diseo por modelado de lluvia de ideas Documente Primeras pruebas Crear constantemente Evolucin de la lgica de dominio Evolucionar las interfaces de usuario Evolucionar el esquema de datos Desarrollo de interfaces de activos legados Generar el script de conversin de datos Pruebas de software Evolucionar su modelo de pruebas Desplegar el script de instalacin Desplegar Notas publicadas Desplegar documentacin inicial Actualizar su plan Desplegar el sistema en un ambiente de pre-produccin Poner todos los productos bajo el Control CMontrol Administre el equipo del proyecto Manejo del riesgo Actualizar su plan de proyecto Cerrar esta fase Apoyar al equipo Evolucionar el entorno de trabajo Establecer el ambiente de capacitacin

Modelado

Implementacin

Pruebas

Despliegue

Administracin de la Configuracin

Administracin del Proyecto

Entorno

22

#MultiAESM

Transicin Durante esta fase se enfoca en liberar el sistema a produccin. Deben hacerse pruebas extensivas a lo largo de la fase, incluyendo las pruebas beta. Una buena afinacin del proyecto tiene lugar aqu, incluyendo el retrabajo dirigido a los defectos significantes. El tiempo y esfuerzo necesarios en la Transicin vara de un proyecto a otro. Sistemas internos son generalmente mas simples de desplegar que los externos. Los proyectos de alta viabilidad pueden requerir pruebas beta extensivas por grupos pequeos antes de librarse a mas gente. Para finalizar esta fase, el equipo debe pasar el hito de liberacin del producto. El principal problema es si el sistema puede desplegarse de forma segura y eficiente en produccin, si el equipo pasa este hito el proyecto pasa a produccin. Si fracasa en alguna de las reas anteriores o aqu puede cancelarse o ser redirigido. Las disciplinas durante esta fase son:

Disciplina

Actividades Principales Modelado por Lluvia de Ideas Finalice la documentacin general del sistema. Corrija defectos Valide el sistema Valide la documentacin Finalice su modelo de pruebas Finalice el paquete de entrega o liberacin. Finalice la documentacin Anuncie el despliegue o liberacin. Capacite el personal Libere el sistema en produccin. Poner todos los productos bajo el CM Control.

Modelado

Implementacin

Pruebas

Despliegue

Administracin de la Configuracin

23

#MultiAESM

 Administracin del Proyecto Entorno

Administre el equipo de proyecto Cerrar esta fase Inicie el prximo ciclo del proyecto Establezca las operaciones y / o el ambiente de soporte Recupere las licencias del software

Disciplinas
Modelado, la meta de esta disciplina es entender el negocio de la organizacin, el dominio del problema que el proyecto aborda e identificar una solucin viable para abordar el dominio del problema. Implementacin, la meta de esta disciplina es transformar su modelo en un cdigo ejecutable y realizar una prueba de nivel bsico en una unidad particular de prueba. Pruebas, la meta es ejecutar una evaluacin de los objetivos para asegurar la calidad. Esto incluye encontrar defectos, validar que el sistema funciona como fue diseado y verificar que los requerimientos estn completos. Despliegue, la meta es planificar la entrega del sistema y ejecutar el plan para que el sistema est disponible para los usuarios finales. Administracin de la configuracin, la meta es administrar el acceso a los entregables o productos del proyecto. Esto incluye no solo es rastreo de versiones del producto en el tiempo, sino que tambin incluye controlar y administrar los cambios que ocurran. Administracin del proyecto, la meta es dirigir las actividades que se llevan a cabo en el proyecto. Esto incluye administracin del riesgo, la direccin de personas, y coordinar con los sistemas y personas fuera del alcance del proyecto para que ste termine a tiempo y dentro del presupuesto. Ambiente, la meta es apoyar el resto de los esfuerzos para garantizar que, el proceso adecuado, la orientacin, herramientas estn disponibles para el equipo segn sea necesario.

24

#MultiAESM

Conclusiones

DSDM La metodologa de DSDM se aplica de manera mas efectiva en un grupo de mediano de personas entre 5 y 7, es recomendable que tanto los usuarios como los desarrolladores tengan un nivel de experiencia elevado para poder llevar a cabo los diversos apartados del proyecto. Esta metodologa tambin utiliza un enfoque iterativo e incremental. Uno de los puntos fuertes que tiene DSDM es que se harn entregas peridicas de los resultados obtenidos hasta cierto momento, por lo que se podrn corregir los errores de manera ms fcil. DSDM se caracteriza porque las tareas de mayor complicacin se desarrollan en los primeros pasos del proyecto, dejando para el final las que menos tiempo y menos valor de negocio tengan. Hay que destacar que la comunicacin entre los usuarios y los desarrolladores del proyecto es continua, por lo que se pueden ir actualizando los requerimientos conforme el usuario quiera FDD Feature Driven Development es una metodologa escalable aunque pensada para proyectos pequeos, los participantes se repartirn los roles ms importantes, es recomendable que el equipo est compuesto por personal con experiencia y puedan guiar el desarrollo del proyecto. Cada dos semanas deben haberse obtenido resultados tangibles y funcionales, cada tarea se subdivide en tareas cortas, inferiores a diez das, y son asignadas a personal del equipo, a un jefe de programacin y a class owner con fechas de inicio y de final. Es una metodologa basada en una lista de caractersticas obtenidas en la segunda fase, es una metodologa simple y rpida, el mayor inconveniente es si el equipo de desarrollo es pequeo, ya que se han de repartir ciertos roles bsicos y obtener los artefactos correspondientes.

25

#MultiAESM

AUP Despus de realizar una investigacin acerca de la metodologa gil AUP, se concluye que es una transformacin de la metodologa RUP a una nueva forma simplificada del mismo.

Es interesante ver la evolucin de una metodologa tradicional en una metodologa gil. Esta metodologa (AUP) tiene como objetivo aplicar la filosofa de tcnicas giles para aprovechar as esas ventajas. Podemos concluir que gracias a estas metodologas giles se abre un nuevo cambio importante en la gestin de los proyectos.

Tabla Comparativa

Despus de realizar la tabla comparativa se han determinado unas caractersticas comunes, y hemos podido ver las diferencias que existen entre las tres metodologas, DSDM, FDD, AUP. Alcance: DSDM Y FDD son recomendables para proyectos pequeos, aunque en el caso de FDD hablamos de una metodologa escalable, por lo que no importa si es grande o pequeo, AUP no se determina.

Cliente: El cliente participa de manera continua y asidua en las metodologas FDD y DSDM, monitorea en cualquier momento la evolucin del software y se le realizan entregas peridicas tangibles y funcionales, sin embargo en AUP el cliente aparece nicamente en las fases iniciales y vuelve a aparecer en la ltima fase con la entrega e instalacin del software, no se realizan entregas previas.

Cobertura: AUP y FDD se centra nicamente en el diseo y la construccin del software, mientras que DSDM cubre todo el ciclo de vida del software.

Tareas: En las tres metodologas se le da prioridad a ciertas tareas, consideradas las ms importantes, adems de ello, en FDD cada tarea se asigna a un miembro del equipo y se producen subdivisiones de las tareas en caso de que sea necesario.

Roles: En AUP no existen roles mientras que en FDD y DSDM existen ciertos roles imprescindibles, otros opcionales y otros de soporte.

26

#MultiAESM

Metodologas: Las tres metodologas se complementan con otras metodologas, ya sea porque heredan algunas de sus funcionalidades o utilizan algunas de sus caractersticas o principios, etc.

Riesgos: En DSDM y AUP existe una previsin de riesgos importantes a la hora de hacer estimaciones, mientras que FDD el cliente participa de forma permanente por lo que puede encaminar el proyecto hacia su prototipo deseado.

27

#MultiAESM

Bibliografa

http://www.slideshare.net/mayjoyce89/dynamic-system-development-method http://www.slideshare.net/Cris20/dsdm-6711620 http://es.wikipedia.org/wiki/M%C3%A9todo_de_desarrollo_de_sistemas_din%C3%A1micos http://audiemangt.blogspot.com/2010/05/metodologia-agil-dynamic-system.html http://dsdm-chile.blogspot.com/2008/08/sdm-mtodo-de-desarrollo-de-sistemas.html http://www.slideshare.net/juliosurrey/t1-u3-herramientas-para-la-planificacion-de-proyectos http://jummp.wordpress.com/2011/04/15/desarrollo-de-software-metodo-de-desarrollo-desistemas-dinamicos-dsdm-iii/ http://www.ambysoft.com/unifiedprocess/agileUP.html es.wikipedia.org/wiki/Agile_Unified_Process http://www.methodsandtools.com/archive/archive.php?id=21 http://pisis.unalmed.edu.co/cursos/material/3004582/1/PresentacionFDD.ppt

28

#MultiAESM