Está en la página 1de 21

Prctica 3 Otras metodologas giles

Ksenia Belova Alejandro Martn Mlaga Kevin Garca Guilabert

16/02/2012

ndice

DSDM (Mtodo de desarrollo de sistemas dinmicos) o o o o o Introduccin Principios DSDM Etapas del proceso DSDM Roles y Responsabilidades en DSDM Artefactos

3 3 3 4 5 6 7 7 7 10 11 12 12 13 14 15 16 17 17 18 19 20 21

AUP (Proceso unificado gil) o o o o Introduccin Fases Roles Entregables

FDD (Desarrollo basado en las funcionalidades) o o o o Caractersticas Roles Artefactos Practicas

Ventajas y Desventajas Tablas comparativas o o o Tabla de artefactos Tabla de practicas Tabla de roles

Herramientas y Refinamientos Bibliografa

Mtodo de desarrollo de sistemas dinmicos Introduccin


El DSDM (Mtodo de desarrollo de sistemas dinmicos) promueve una serie de caractersticas y criterios para el desarrollo gil de software, apoyando un desarrollo iterativo y creciente, que sea apto para posibles cambios y ajustes segn requiere el proyecto. Forma parte de la alianza gil. La alianza gil es un marco de trabajo conceptual de la ingeniara de software que apoya las iteraciones en el desarrollo del ciclo de vida de un proyecto. Dentro de esta alianza se encuentran distintos mtodos como XP, AUP, DSDM

Principios DSDM
Existen 9 puntos que forman los pilares en el desarrollo mediante DSDM 1. Tanto el cliente como el desarrollador debe estar involucrados en el proyecto, juntos deben poder tomar las decisiones de una forma acertada y precisa. 2. El equipo debe poder tomar decisiones sin la necesidad de estar pidiendo la aprobacin de los superiores, de esta forma no se paraliza el proyecto. 3. El mtodo DSDM se basa en la entrega frecuente de productos. Entregando el producto de una forma continua segn se vaya produciendo permite corregir errores y verificar que todo esta siendo realizado segn lo establecido. 4. El principal objetivo en DSDM es entregar un producto que sin ser perfecto contenga todas las funcionalidades criticas establecidas en el proyecto. Mas adelante se mejoraran y aadirn otras funciones. 5. El desarrollo es iterativo e incremental. 6. Nada es fijo, todo puede cambiar durante la evolucin del proyecto. 7. El alcance de alto nivel y los requerimientos deberan ser base-lined antes de que comience el proyecto. 8. Durante el ciclo de vida del proyecto, se realizaran evitar que un coste extra en mantenimiento y arreglos del sistema. 9. Es necesario que todas las partes del proyecto cooperen en el desarrollo de este.

Otros principios en los que tambin se apoya el DSDM son: Ningn sistema es construido a la perfeccin en el primer intento. El proyecto debe ser entregado respetando el acuerdo establecido, tiempo calidad y presupuesto. Cada paso debe completarse lo suficiente como para continuar con el siguiente. DSDM se puede usar tanto en nuevos proyectos, como en mejoras de uno ya existente. La Evaluacin de riesgos debiera centrarse en entregar funcin de negocio, no en el proceso de construccin. La gestin recompensa la entrega de productos ms que la consecucin de tareas. La Estimacin debera estar basada en la funcionalidad del negocio en lugar de lneas de cdigo.

Etapas del proceso DSDM


Pre-proyecto, esta etapa se realiza antes de que el proyecto comience de una forma oficial. Se da forma al proyecto y se toma la decisin de comenzarlo. Es una etapa que no esta estrictamente definida, pero puede existir. Estudio de viabilidad, en esta etapa es donde el equipo de trabajo se hace preguntas sobre si es posible realizar el proyecto con unos recursos y tiempo limitado. Es una fase que se realiza rpidamente ya que DSDM es el mejor mtodo cuando existe poco tiempo para llevara acabo el proyecto. Estudio de negocio, se estudiando los aspectos comerciales del negocio. Por ejemplo dudas como si es un buen negocio, quienes son las partes que participan en el y cual puede ser el mejor plan de trabajo. Iteracin de modelado funcional, esta formado por 4 sub-etapas. Identificar el prototipo funcional, determinar las funcionalidades que debe contener. Acuerdo de fechas, establecer como y cuando debe estar listo el prototipo Hacer prototipo funcional, crear un prototipo funcional con las caractersticas establecidas anteriormente. Revisar prototipos, comprobar que cumple toda la funcionalidad, se puede realizar por el usuario final o a travs de documentacin.

En esta etapa se devuelve un prototipo funcional. Iteracin de diseo y desarrollo, compuesta por 4 sub-etapas. Identificacin de los prototipos, con ayuda de los prototipos creados identificar los requisitos funcionales y no funcionales. Estos resultados se tendrn en cuenta en la siguiente iteracin. Acuerdo de fechas, establecer como y cuando debe estar listo el prototipo 4

Crear prototipos de diseo, en esta etapa se disea un prototipo que podr ser entregado al usuario final y debe poder ser usado a diario o para propsitos de prueba. Revisin del prototipo del diseo, se comprueba que cumpla todo lo acordado, debe ser probado.

Implementacin, compuesta por 4 sub-etapas. Aprobacin y directrices de los usuarios, los usuarios finales prueba el producto y dan su aprobacin o no. Formacin de los usuarios. Implementacin, probar el producto en la ubicacin final. Revisin del negocio, estudiar los resultados finales ya probados en la empresa.

Post-desarrollo, futuras mejoras una vez entregado el proyecto.

Roles y Responsabilidades en DSDM


Entorno de desarrollador: Patrocinador Ejecutivo, es el encargado de asegurar que los resultados de las negociaciones sean adecuados. Debe resolver los problemas entre el desarrollo y la gestin. Principalmente se encarga de tratar las cuestiones financieras. Visionarios, revisa el plan de tareas, resuelve problemas entre los equipos de desarrollo y de gestin. Aprueba los cambios desde el punto de vista empresarial. Coordinador tcnico, se asegura de que todas las directrices, normas, procesos y herramientas se aplican en todas las partes. Informa a todos los equipos de los

posibles problemas tcnicos, de las decisiones y suposiciones. Trabaja junto a los equipos para asegurar que el software se ajustado a lo pedido. Jefe de equipo, trabaja en un solo lugar o bien gestin o bien en desarrollo. Esta conectado con los jefes de los distintos equipos para informar sobre los avances de su equipo y evitar posibles problemas. Asesor del usuario, comparte conocimientos y habilidades con los clientes y equipos de trabajo. Facilitador, encargado de acortar las diferencias culturales, de realizar talleres para mejorar el aprendizaje y estar pendiente de que todo se aprenda.

Entorno del cliente: Desarrollador embajador, representa a la organizacin. Representantes de apoyo y mantenimiento. Coordinador de pruebas, coordina las pruebas para evitar realizar varias veces las mismas, si se da el caso de que estas se realicen en distintas zonas. Se asegura de que los productos cumplan los requisitos.

Artefactos
Un artefacto es un producto tangible resultante del proceso de desarrollo de software. Algunos artefactos como los casos de uso, diagrama de clases u otros modelos UML ayudan a la descripcin de la funcin, la arquitectura o el diseo del software. Otros se enfocan en el proceso de desarrollo en s mismo, como planes de proyecto, casos de negocios o enfoque de riesgos. El cdigo fuente compilado para el testeo se suele considerar un artefacto, ya que el ejecutable es necesario para el plan de testeo.

Algunos ejemplos: Modelo de casos de uso: Describe los requisitos funcionales y los no funcionales relacionados. Especificaciones suplementarias: Describe otros requisitos. Modelo de Implementaci: Cdigo fuente, ejecutables, bases de datos, otros. Modelo de Diseo: Diagramas descriptivos del diseo lgico, sin referencias al modo de implementacin. Comprende los diagramas de clase del software, diagramas de interaccin, diagrama de paquetes y otros. Documento de Arquitectura: Escribe la correlacin entre los componentes de software y los requerimientos. Es un resumen de las ideas principales del diseo.

El proceso unificado gil Introduccin


El proceso unificado gil es un refinamiento del proceso unificado utilizando las caractersticas de la mas metodologas agiles. Funciona aplicando una serie de disciplinas en cada una de las partes caractersticas del proceso unificado: Inicio, Elaboracin, Construccin, Transicin.

Fases
En la fase de inicio definiremos el alcance del proyecto estimando costes y el calendario, definiendo los distintos riesgos. Determinaremos la factibilidad del proyecto y prepararemos el entorno del proyecto. La meta de la fase de inicio es identificar el alcance inicial del proyecto, generando una arquitectura inicial del sistema y obtener un presupuesto para la aceptacin de los involucrados. El hito marcado es conseguir el Ciclo de Vida que se basa en llegar a un acuerdo con los contratistas, definir unos requisitos iniciales. En la fase de elaboracin es probar la arquitectura del sistema a desarrollar. El punto es asegurar que el equipo puede desarrollar un sistema que satisfaga los requisitos, y la mejor manera de hacerlo que es la construccin de extremo a extremo del esqueleto de trabajo del sistema conocido como "prototipo de la arquitectura". Esto es en realidad un concepto pobre porque mucha gente piensa en deshacerse de los prototipos. En cambio, su significado es software funcional de alto nivel, el cual incluye varias casos de uso de alto riegos (a partir de un punto de vista tcnico) para demostrar que el sistema es tcnicamente factible. Durante la Elaboracin, el equipo tambin se est preparando para la Fase de Construccin. Como el equipo gana una mano en la arquitectura del sistema, ellos comienzan con la creacin del ambiente propicio para la Construccin mediante la compra de hardware, software y herramientas. Las personas son dirigidas desde la perspectiva de la Administracin del Proyecto; los recursos son solicitados o contratados. Los planes de comunicacin y la colaboracin se finalizan (especialmente importantes si el equipo debe estar fsicamente separado). La meta de esta fase es probar la arquitectura del sistema. El hito marcado es la consecucin de la arquitectura del Ciclo de Vida que se basa en estabilizar la visin y la arquitectura del proyecto. El objetivo de la fase de Construccin consiste en desarrollar el sistema hasta el punto en que est listo para la pre-produccin de pruebas. En las etapas anteriores, la mayora de los requisitos han sido identificados y la arquitectura del sistema se ha establecido. El nfasis es priorizar y comprender los requerimientos, modelado que ataca una solucin y, a luego, la codificacin y las pruebas del software. Si es necesario, las primeras versiones del sistema se desarrollan, ya sea interna o externamente, para obtener los comentarios de los usuarios. La meta de esta fase es construir un software funcional sobre una base regular e incremental. El hito marcado es conseguir la capacidad operacional inicial que se basa en conseguir la estabilidad del sistema e involucrar a todas las partes en el desarrollo del producto aceptando los riesgos.

La fase de Transicin se enfoca en liberar el sistema a produccin. Deben hacerse pruebas extensivas a lo largo de esta fase, incluyendo las pruebas beta. Una buena afinacin del proyecto tiene lugar aqu incluyendo el trabajo dirigido a los defectos significantes (su usuario puede escoger aceptar la existencia de algunos defectos conocidos en la versin actual). Las metas de esta fase son validar y desplegar es sistema en su ambiente de produccin. El hito de esta fase es la liberacin del producto que se basa en la aceptacin del resultado, y ver la adecuacin del pre proyecto al trabajo final. Las disciplinas utilizadas son: Modelado: entender el problema que genera y buscar las posibles soluciones. Implementacin: transformar el modelo en un cdigo ejecutable. Pruebas: realizar pruebas sobre el cdigo anteriormente realizado. Despliegue: plan para la entrega del sistema y para ejecutar el plan Administracin de la Configuracin: administrar el acceso a los artefactos del proyecto. Administracin de Proyecto: dirige las actividades que se realizan dentro del proyecto. Ambiente: apoyar el resto del esfuerzo, garantizando que el proceso de orientacin es adecuado, y las herramientas estn disponibles segn sea necesario.

Modelado en las distintas fases Inicio: modelado de los requerimientos a alto nivel y modelado de la arquitectura a alto nivel. Elaboracin: identifica los riesgos tcnicos, produce prototipos de interfaces de usuario y un modelado de la arquitectura. Construccin: aborda el anlisis del modelado, disea por medio de una lluvia de ideas y documenta. Transicin: finaliza la documentacin general del sistema. Implementacin en las distintas fases Inicio: efecta un prototipito tcnico y un prototipito de interfaces de usuario. Elaboracin: prueba la arquitectura del sistema. Construccin: efecta las primeras pruebas efectuando una evolucin de la lgica del dominio, las interfaces de usuario y el esquema de datos. Desarrolla interfaces de activos legados y genera el script de conversin de datos. Transicin: corrige los defectos.

Pruebas en las distintas fases Inicio: efecta el plan de pruebas iniciales y revisin inicial del proyecto y de los modelos. Elaboracin: valida la arquitectura y evoluciona su modelo de pruebas. Construccin: efecta pruebas de software y evoluciona su modelo de pruebas. Transicin: valida el sistema y la documentacin, finaliza su modelo de pruebas. Despliegue en las distintas fases Inicio: identifica la ventana potencial de liberacin, inicia el plan de despliegue de alto nivel. Elaboracin: actualiza su plan de desarrollo. Construccin: despliega el script de instalacin, las notas publicadas y la documentacin inicial. Actualiza el plan y despliega el sistema en un ambiente de pre-produccin. Transicin: finaliza la documentacin y el paquete de entrega. Anuncia el despliegue y capacita al personal. Finalmente libare el sistema de produccin. Administracin de la Configuracin en las distintas fases Inicio: establece la configuracin del entorno y coloca todos los productos bajo el control de la configuracin. Elaboracin: poner todos los productos bajo el control de administracin de la configuracin. Construccin: poner todos los productos bajo el CM control. Transicin: poner todos los productos bajo el CM control. Administracin del Proyecto en las distintas fases Inicio: inicia la creacin del equipo, crea las relaciones con los interesados del proyecto y determina la factibilidad del proyecto, un cronograma de alto nivel y un plan de iteraciones. Administra el riesgo y obtiene el apoyo y financiamiento de los interesados. Elaboracin: construye y protege el equipo, obtiene los recursos, maneja el riesgo y actualiza su plan de proyecto. Construccin: administra el equipo del proyecto, manejando el riesgo y actualiza su plan de proyecto. Transicin: administra el cierre del proyecto, cierra esta fase e inicia el prximo ciclo del proyecto.

Ambiente en las distintas fases Inicio: establece el entorno de trabajo e identifica la categora del proyecto. Elaboracin: evoluciona el entorno del trabajo y ajusta los materiales a los procesos. Construccin: apoya al equipo, evoluciona el entorno de trabajo y establece el ambiente de capacitacin. Transicin: establece las operaciones y / o el ambiente de soporte. Recupera las licencias del software.

Roles del AUP


Los distintos roles pueden ser asumidos por varias personas y Una persona puede tomar varios roles. Los distintos roles a interpretar en la metodologa son:
DBA gil: es el encargado del diseo de la base de datos. Modelador gil: es aquel que crea y desarrolla los modelos de manera colaborativa y evolutiva. Administrador de la configuracin: proporciona la infraestructura y crea el medio ambiente para el equipo de desarrollo. Implementador: es el responsable de poner en disposicin el sistema en los ambientes de preproduccin y produccin. Desarrollador: es aquel que escribe cdigo, realiza pruebas y construye el software. Especialista del proceso: desarrolla, adapta y apoya el material de los procesos de la organizacin. Administrador 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. Examinador: evala los productos resultantes del proyecto, inclusive el trabajo en progreso resultante de cada iteracin. Involucrado: es 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, en fin todo aquel que se vea afectado de una u otra forma con el proyecto. Documentador tcnico: es el responsable de producir documentacin para los involucrados, tal como: materiales de capacitacin, documentacin de operaciones, documentacin de

mantenimiento, y documentacin de usuario. Administrador de pruebas: es el responsable del xito de las pruebas, las planifica y testea su calidad. Equipo de pruebas: ejecutan las pruebas y las documentan. Especialista en herramientas: es el responsable de seleccionar, adquirir, configurar y brindar mantenimiento al equipo requerido.

10

Cualquiera: cualquier otra persona en un rol distinto.

Entregables mnimos en el AUP


Sistema: es el software de trabajo, el hardware y la documentacin para ser liberada a produccin. Cdigo fuente: el cdigo de programa para su sistema. Suite de pruebas de regresin: una coleccin de casos de prueba, y el cdigo para correrlas en un orden adecuado. El suite de pruebas de regresin incluir un gran rango de pruebas, tomando en cuenta pruebas de aceptacin, unidades de pruebas, pruebas de sistema y muchas otras. Scripts de instalacin: cdigo para instalar su sistema en un ambiente de preproduccin. Documentacin del sistema: la documentacin liberada como una parte del sistema para ayudar al usuario a trabajar con l. Notas: deben resumir las buenas cosas a saber acerca de las versiones actuales que se estn construyendo. Modelado de requerimientos: describe los requisitos que su sistema debe cumplir. Modelo de diseo: describe el diseo del sistema.

11

Desarrollo basado en las funcionalidades Caractersticas


Es un mtodo iterativo y adaptativo. Se centra ms en las fases de construccin y diseo. Est pensado para los proyectos con poco tiempo de realizacin. Ayuda a prevenir el exceso en el presupuesto o fallas en el programa. Se requiere definir los procesos de una manera simple y seguir un orden lgico para facilitar el trabajo y aumentar la calidad. ste mtodo est formado por ciclos cortos basados en las funcionalidades, pequeas partes significativas del software para el cliente. Los resultados obtenidos son tangibles y se presentan peridicamente. Esta metodologa gil est compuesta por los siguientes procesos: Primero. Desarrollar un modelo global, se construye un modelo de desarrollo respetando la visin, los requerimientos y el contexto que debe tener el sistema. Elaborando diagramas de los paquetes con las clases esenciales y sus responsabilidades. Tambin se aporta un documento con los objetivos definidos del proyecto, ms la arquitectura de las opciones de modelado. Segundo. Construir una lista de rasgos, se desarrolla una lista que resume las funcionalidades que posteriormente ser evaluada por el cliente. Se agrupan estructuradamente para llevar a cabo el trabajo de desarrollo. Tercero. Planear por rasgo, se establecen los tiempos para cada iteracin. El lder del proyecto junto con el lder de desarrollo planifican los hitos de finalizacin de las iteraciones construidos por conjuntos de funcionalidades. Los programadores jefes ordenan las funciones conforme a su prioridad y dependencia. Cuarto. Disear por rasgo, se selecciona un conjunto y se implementa mediante un proceso iterativo decidiendo qu funcionalidad se va a realizar en cada iteracin. Se disean las clases, atributos y mtodos incluyendo codificacin e integracin de cdigo. Quinto. Construir por rasgo, es la ltima etapa que consiste en la construccin total de la aplicacin de manera incremental. Cada programador implementa los mtodos de las clases que se le asignan extendiendo las clases base de prueba para construir las pruebas unitarias e inspeccionar el cdigo.

12

Las fases de FDD

Roles
Los roles de FDD se dividen en tres tipos. Roles claves: Administrador del proyecto, el que se ocupa de la asignacin del personal y la ltima revisin. Arquitecto jefe, realiza el diseo global del sistema y ejecuta todas las etapas. Manager de desarrollo, su funcin consiste en evitar conflictos entre los miembros del equipo y resolver problemas de recursos. Programador jefe, participa en el anlisis de requisitos y selecciona rasgos para la siguiente iteracin. Propietarios de clases, los sbditos del programador jefe, sus tareas son el diseo, la codificacin, pruebas y documentacin. Experto de dominio, cliente, usuario o analista de negocios, poseen el conocimiento de los requisitos del sistema y lo pasan a los desarrolladores para asegurar la entrega completada.

Roles de soporte: Administrador de entrega, supervisa el proceso revisando los reportes del programador jefe e informa al manager del proyecto. Abogado de lenguaje, conoce el lenguaje y la tecnologa perfectamente. Ingeniero de construccin, responsable de preparar y mantener el proceso de construccin.

13

Herramientista, construye herramientas ad hoc, mantiene las bases de datos. Administrador del sistema, controla el ambiente de trabajo, configura, administra y repara los servidores y equipos de desarrollo.

Roles adicionales: Verificadores, comprueban que el sistema creado cumple todos los requerimientos del cliente. Encargados del despliegue, convierten la informacin existente requerida por el nuevo sistema, tambin participan en el lanzamiento de los nuevos productos. Escritores tcnicos, preparan la documentacin para los usuarios.

La implementacin de cada proceso se realiza en grupo, por cada uno de ellos hay un responsable que tendr la ltima palabra en caso de no llegar a un acuerdo. Todos forman parte del proyecto los inexpertos aprenden de las discusiones de los ms involucrados. Las funcionalidades se reparten entre distintos subgrupos del equipo y se procede a la implementacin. Los propietarios de las clases son los nicos quienes las crean por tanto pueden cambiarlas. Debido a esto, en cada equipo deben estar todos los dominantes de las clases, adems de un programador en varios grupos implementando distintas funciones. Posteriormente, se preparan y se ejecutan las pruebas, se revisa el cdigo e integracin de las partes compuestas del software. Se definen mtricas para seguir el proceso de desarrollo de la aplicacin, con el fin de conocer el estado actual de desarrollo, realizar mejores estimaciones en proyectos futuros.

Artefactos
La FDD se estructura definiendo unas funciones features de corto alcance, que representan la funcionalidad que debe contener el sistema. Existe una jerarqua de las mismas que consta de feature set que agrupa un conjunto de features relacionadas con aspectos en comn de negocio. Finalmente, el major feature set es el nivel ms alto de agrupacin de los conjuntos de funciones que contribuyen a proveer valor al cliente en relacin a un subdominio dentro del dominio completo de la aplicacin. Tiene los siguientes formatos: Para features: <accin> el <resultado> <de | para | sobre | por> un <objeto> Para feature sets: <accin><-endo> un <objeto> Para major feature sets: administracin de <accin>

14

Algunos artefactos caractersticos del mtodo FDD son: - Planificacin del proyecto. Es un documento que contiene la informacin de gestin, es realizado por el lder del proyecto. Se aaden cronogramas explicativas que definen las tareas del proyecto. Se inicia con la primera fase y se va actualizando hasta el fin del proyecto. - El repositorio del proyecto. Cubre la disciplina de Administracin de la Configuracin, se almacenan todas las versiones de los archivos y directorios del proyecto para poder modificarlas posteriormente y generar ramas de desarrollo paralelo. El programador jefe es el responsable de la creacin y mantenimiento del repositorio. - Nota de entrega. Es un documento donde se especifica toda la informacin sobre el proyecto acabado que se entregar al cliente. Se incluyen el nmero de la versin, los cambios efectuados y las posibles mejoras.

Prcticas
En la prctica este mtodo se aplica a los proyectos largos de un tiempo de desarrollo corto. La duracin de cada iteracin abarca dos semanas de forma incremental. Se requiere una reunin semanal entre el lder del proyecto y los programadores jefe. Se permite explorar y explicar el dominio del problema. Se desarrolla el progreso a travs de una lista de funcionalidades. Cada clase tiene una persona responsable de la consistencia, integridad conceptual y rendimiento de la clase. El equipo de caractersticas. El equipo de caractersticas se forman de una manera dinmica. Los inspectores detectan los defectos. Sobre los builds, construcciones se van agregando las nuevas caractersticas. La administracin de configuracin a travs del tiempo de la ltima versin de cada parte de cdigo completada. El progreso se reporta basndose en el trabajo completo.

15

Ventajas y Desventajas
Ventajas AUP Hace mas liviana a la metodologia rup debido a que usa elementos de metodologias giles. Esta diseada para grandes grupos de trabajo.

Ventajas y Desventajas DSDM Ventajas: La calidad del producto es mejorada gracias a la ayuda de los usuarios a lo largo del ciclo de vida del proyecto y la naturaleza iterativa del desarrollo. DSDM asegura desarrollos rpidos y funcionales. Reduce los costos de proyectos a travs de las ventajas mencionadas anteriormente. Permite realizar cambios de forma fcil. Permite la reutilizacin de aplicacin a travs de los mdulos existentes.

Desventajas: Se necesita una alta participacin de los usuarios en elmdesarrollo, para evitar que los desarrolladores asuman criterios que no son ciertos. No es una metodologa de desarrollo comn. El proceso es un tanto difcil de comprender.

Ventajas y Desventajas FDD Ventajas El objetivo es la entrega concreta, desarrollo de software en repetidas ocasiones, en el momento oportuno. Provee estrategias de planteamiento para el lder del proyecto. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario comn que fomente que los desarrolladores tengan un dilogo fluido con los clientes, desarrollando entre ambos un modelo comn del negocio.

Desventajas Demasiado jerrquico, demanda un programador jefe quien manda sobre los propietarios de clases quienes dirigen los equipos de rasgos. Necesita un equipo de miembros con experiencia que definan los pasos a seguir a lo largo del proyecto. Pocos detalles sobre las pruebas.

16

Tabla de Comparativas

Tabla comparativa de artefactos

Artefactos / Metodologa Caso del negocio Documento de arquitectura del Software Especificaciones suplementarias Modelo de anlisis Modelo de casos de uso Modelo de diseo Modelo de implementacin Plan de gestin de riesgo Plan de implantacin Plan de iteracin Plan de pruebas Planificacin del proyecto Producto Visin del sistema

AUP x x x x x x x x x

FDD

DSDM x x x

x x

x x x x x x x x x x

17

Tabla comparativa de practicas

Practica / Metodologa Adaptar el proceso de desarrollo Alto nivel de Abstraccin Fomento del aprendizaje de experiencias Centrarse en la arquitectura Interaccin continua con el cliente Enfoque continuo en la calidad Colaboracin entre equipo Demostracin de los resultados Modelar el software Enfoque en los riesgos Permanecer gil y esperar cambios Dirigido por casos de uso Para pequeos grupos Para grandes grupos

AUP x x x x x x x x x x x x

FDD x

DSDM x x

x x x x x x x

x x

18

Tabla comparativa de Roles

Roles / Metodologa Analista de calidad Analista de productos Arquitecto Desarrollador Involucrados Lder en proyecto Probador Otros roles

AUP x x x x x x x x

FDD

DSDM x

x x

x x x

x x x

x x x

19

Herramientas y Refinamientos
UMT - (UML Model Transformation Tool) - Herramienta para la trasformacin de modelos y la generacin de cdigo basada en especificaciones UML/XMI . VisualWADE, una herramienta desarrollada por el grupo de Ingeniera Web de la Universidad de Alicante. VisualWADE permite el diseo y generacin automtica de aplicaciones web siguiendo una aproximacin MDD. Combina diagramas de dominio UML con nuevos modelos para representar la interaccin con el usuario sobre un entorno hipermedia. El cdigo intermedio generado es XML. En la versin actual, se proporciona un compilador de modelos que produce entregables en PHP a partir del cdigo intermedio XML. Kermeta, es un lenguaje especfico de dominio que cuenta con un entorno de trabajo integrado en Eclipse. Por ser un lenguaje de metamodelado, Kermeta brinda soporte a la especificacin de lenguajes especficos de dominio, capacidades para la simulacin y prototipado de modelos y metamodelos, y la transformacin de modelos. Rational Method Composer, es una plataforma para la gestin de procesos que se usa para gestionar, por ejemplo, rup. La herramienta no es gratuita pero la versin de prueba permite generar el sitio web con toda la informacin disponible del rup en sus versiones classic, mdium y small, adems incluye guas, plantillas, ejemplos, etc. Que te ayudan a realizar un seguimiento del rup. Eclipse process framework, es el equivalente libre del rational method composer, siendo muy similares incluso sus interfaces. Incluye como refinamiento del proceso unificado el openup.

20

Bibliografa:
http://www.google.es http://es.wikipedia.org http://es.kioskea.net http://www.navegapolis.net http://es.scribd.com/doc/62931905/48/Figura-13-Ciclo-de-desarrollo-de-DSDM http://es.scribd.com/doc/61648265/dsdm http://www.slideshare.net/kiberley/merinde-altec http://metagiles.alumnos.exa.unicen.edu.ar/Home/programa http://www.slideshare.net/Cris20/metodologia-dsdm http://cgi.una.ac.cr/AUP/index.html http://es.scribd.com/doc/41616347/Libro-Analisis-Disenio1 http://www.slideshare.net/kiberley/merinde-altec http://seccperu.org/files/Metodologias%20Agiles.pdf http://pisis.unalmed.edu.co/cursos/material/3004582/1/PresentacionFDD.ppt http://www.willydev.net/descargas/Articulos/General/cualxpfddrup.PDF http://materias.fi.uba.ar/7500/schenone-tesisdegradoingenieriainformatica.pdf http://www.ecured.cu/index.php/Metodolog%C3%ADa_FDD

21

También podría gustarte