La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

FDD: Feature Driven Development Desarrollo Basado en Funcionalidades Sarah Gutiérrez Hernán Zapata Juan Pablo Arias Cristian Zambrano.

Presentaciones similares


Presentación del tema: "FDD: Feature Driven Development Desarrollo Basado en Funcionalidades Sarah Gutiérrez Hernán Zapata Juan Pablo Arias Cristian Zambrano."— Transcripción de la presentación:

1 FDD: Feature Driven Development Desarrollo Basado en Funcionalidades Sarah Gutiérrez Hernán Zapata Juan Pablo Arias Cristian Zambrano

2 FDD Es un proceso ágil para el desarrollo de sistemas. Es un proceso ágil para el desarrollo de sistemas. Fue diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Fue diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción. No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción. Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto. Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.

3 FDD Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado. Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado. Propone tener etapas de cierre cada dos semanas. Propone tener etapas de cierre cada dos semanas. Se obtienen resultado periódicos y tangibles. Se obtienen resultado periódicos y tangibles.

4 FDD Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitoriar. Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitoriar. Define claramente entregas tangibles y formas de evaluación del progreso del proyecto. Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.

5 Proceso El proceso consiste de cinco pasos secuénciales durante los cuales se diseña y se construye el sistema: El proceso consiste de cinco pasos secuénciales durante los cuales se diseña y se construye el sistema: Desarrollo de un modelo global. Desarrollo de un modelo global. Construcción de una lista de funcionalidades. Construcción de una lista de funcionalidades. Planeación por funcionalidad. Planeación por funcionalidad. Diseño por funcionalidad. Diseño por funcionalidad. Construcción por funcionalidad. Construcción por funcionalidad.

6 Proceso

7 Descripción del Proceso(1) Desarrollo de un modelo global: Desarrollo de un modelo global: Cuando comienza el desarrollo, los expertos del dominio están al tanto de la visión, el contexto y los requerimientos del sistema a construir. Cuando comienza el desarrollo, los expertos del dominio están al tanto de la visión, el contexto y los requerimientos del sistema a construir. Se divide el dominio global en áreas que son analizadas detalladamente. Se divide el dominio global en áreas que son analizadas detalladamente. Los desarrolladores construyen un diagrama de clases o de objetos por cada área. Los desarrolladores construyen un diagrama de clases o de objetos por cada área. Se construye un modelo global del sistema. Se construye un modelo global del sistema.

8 Descripción del Proceso(2) Construcción de una lista de funcionalidades: Construcción de una lista de funcionalidades: Una funcionalidad es un ítem útil a los ojos del cliente. Una funcionalidad es un ítem útil a los ojos del cliente. Se elabora una lista de funcionalidades que resuma la funcionalidad general del sistema. Se elabora una lista de funcionalidades que resuma la funcionalidad general del sistema. La lista es elaborada por los desarrolladores y es evaluada por el cliente. La lista es elaborada por los desarrolladores y es evaluada por el cliente. Se divide la lista en subconjuntos según la afinidad y la dependencia de las funcionalidades. Se divide la lista en subconjuntos según la afinidad y la dependencia de las funcionalidades. La lista es finalmente revisada por los usuarios y los responsables para su validación y aprobación. La lista es finalmente revisada por los usuarios y los responsables para su validación y aprobación.

9 Planeación por funcionalidad: Planeación por funcionalidad: En este punto se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes. En este punto se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes. Descripción del Proceso(3)

10 Descripción del Proceso(4) Diseño por funcionalidades y Construcción por funcionalidades: Diseño por funcionalidades y Construcción por funcionalidades: Se selecciona un conjunto de funcionalidades de la lista. Se selecciona un conjunto de funcionalidades de la lista. Se procede a diseñar y construir la funcionalidad mediante un proceso iterativo. Se procede a diseñar y construir la funcionalidad mediante un proceso iterativo. Una iteración puede tomar de unos pocos días a un máximo de dos semanas. El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código. Una iteración puede tomar de unos pocos días a un máximo de dos semanas. El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código. Miremos una representación gráfica del proceso iterativo que involuclan estas dos últimas fases: Miremos una representación gráfica del proceso iterativo que involuclan estas dos últimas fases:

11

12

13

14 Roles y Responsabilidades

15 Categorías Key Roles / Roles claves Key Roles / Roles claves Supporting Roles / Roles de soporte Supporting Roles / Roles de soporte Additional Roles / Roles adicionales Additional Roles / Roles adicionales

16 Key Roles / Roles claves Project Manager / Director del Proyecto: Project Manager / Director del Proyecto: * Lider administrativo y financiero del proyecto. * Protege al equipo de situaciones externas. Chief Architect / Arquitecto jefe: Chief Architect / Arquitecto jefe: * Diseño global del sistema. * Ejecución de todas las etapas. Development Manager / Director de desarrollo Development Manager / Director de desarrollo * Lleva diariamente las actividades de desarrollo.

17 * Resuelve conflictos en el equipo. * Resuelve problemas referentes a recursos. Chief Programmer / Programador Jefe Chief Programmer / Programador Jefe * Analiza los requerimientos. * Diseña el proyecto. * Selecciona las funcionalidades a desarrollar de la ultima fase del FDD. Class Owner / Propietario de clases Class Owner / Propietario de clases * Responsable del desarrollo de las clases que se le asignaron como propias. * Participa en la decisión de que clase será incluida en la lista de funcionalidades de la próxima iteración.

18 Expertos de dominio Expertos de dominio * Puede ser un usuario, un cliente, analista o una mezcla de estos. * Poseen el conocimiento de los requerimientos del sistema. * Pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.

19 Supporting roles / Roles de soporte Domain Manager Domain Manager * Lidera al grupo de expertos del dominio. * Resuelve sus diferencias de opinión concernientes a los requerimientos del sistema. Release Manager Release Manager * Controla el avance del proceso mediante la revisión de los reportes del Chief Programmer. * Reporta resultados obtenidos semanalmente al gerente, al cliente donde incluye el porcentaje de avance de cada feature.

20 Language Lawyer / Guru del Lenguaje Language Lawyer / Guru del Lenguaje * Responsable de poseer un vasto conocimiento en, por ejemplo, un lenguaje específico de programación o tecnología. * Es muy importante cuando se trabaja una nueva tecnología. Build Engineer / Ingeniero de construcción Build Engineer / Ingeniero de construcción * Responsable de preparar, mantener y correr el proceso de construcción. * Realiza el mantenimiento de las versiones y la publicación de la documentación.

21 Toolsmith / Herramentista Toolsmith / Herramentista * Rol para la construcción de herramientas específicas para el desarrollo, conversión de datos y testeo. * Puede trabajar en la preparación y mantenimiento tanto de bases de datos o sitios web destinados al proyecto. System Administrator / Administrador del sistema System Administrator / Administrador del sistema * Configura, administra y repara los servidores, estaciones de trabajo y equipos de desarrollo y testeo utilizados por el equipo.

22 Tester Tester * Verifica que el sistema recién creado cumpla con los requerimientos del cliente. * Puede llegar a ser una persona independiente del equipo del proyecto. Deployer Deployer * Es el encargado de convertir la información existente requerida por el nuevo sistema. * Participa en el lanzamiento de los nuevos productos. Technical Writer / Escritores de documentos tecnicos Technical Writer / Escritores de documentos tecnicos * Prepara la documentación para los usuarios, que pueden formar parte o no del equipo del proyecto. Additional roles / Roles adicionales

23 Comparación Puesto que todos los procesos se centran en la producción de software es deseable una comparación, no en su conjunto, sino según los medios que emplean y sus resultados. Realizamos una comparación entre FDD, RUP y XP.

24 Tamaño de los equipos : Tamaño de los equipos : RUP esta pensado para proyectos y equipos grandes, en cuanto a tamaño y duración. FDD y XP se implementan mejor para proyectos cortos y equipos más pequeños, siendo quizás FDD más escalable que XP. Obtención de requisitos: RUP y XP crean como base UseCases y UserStories, por lo contrario FDD no define explícitamente esa parte del proyecto sobre la adquisición de requisitos. Obtención de requisitos: RUP y XP crean como base UseCases y UserStories, por lo contrario FDD no define explícitamente esa parte del proyecto sobre la adquisición de requisitos. Evaluación del estado del proyecto: FDD es posiblemente el proceso más adecuado para definir métricas que definan el estado del proyecto, puesto que al dividirlos en unidades pequeñas es bastante sencillo hacer un seguimiento de las mismas. Evaluación del estado del proyecto: FDD es posiblemente el proceso más adecuado para definir métricas que definan el estado del proyecto, puesto que al dividirlos en unidades pequeñas es bastante sencillo hacer un seguimiento de las mismas.

25 XP también define esos componentes pequeños. RUP por su parte, es tan grande y complejo en este sentido como en el resto, por lo que manejar el volumen de información que puede generar requiere mucho tiempo. XP también define esos componentes pequeños. RUP por su parte, es tan grande y complejo en este sentido como en el resto, por lo que manejar el volumen de información que puede generar requiere mucho tiempo. Carga de trabajo : XP es un proceso ligero, esto es, que los creadores del proceso han tenido cuidado de no poner demasiadas tareas organizativas sobre los desarrolladores. RUP es un proceso pesado, basado mucho en la documentación, en la que no son deseables todos esos cambios volátiles. FDD es por su parte un proceso intermedio, en el sentido de que genera más documentación que XP pero menos que RUP. Carga de trabajo : XP es un proceso ligero, esto es, que los creadores del proceso han tenido cuidado de no poner demasiadas tareas organizativas sobre los desarrolladores. RUP es un proceso pesado, basado mucho en la documentación, en la que no son deseables todos esos cambios volátiles. FDD es por su parte un proceso intermedio, en el sentido de que genera más documentación que XP pero menos que RUP.

26 Relación con el cliente:Con RUP se presentarán al cliente los artefactos del final de una fase, en contrapartida, la aseguración de la calidad en XP y FDD no se basa en formalismos en la documentación, si no en controles propios y una comunicación fluida con el cliente. Relación con el cliente:Con RUP se presentarán al cliente los artefactos del final de una fase, en contrapartida, la aseguración de la calidad en XP y FDD no se basa en formalismos en la documentación, si no en controles propios y una comunicación fluida con el cliente. Conocimiento sobre la arquitectura: En RUP se intentará reducir la complejidad del software a producir a través de una planificación intensiva. En XP se conseguirá a través de la programación a pares que ya en la creación del código se puedan evitar errores y malos diseños. En FDD sin embargo se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una arquitectura sencilla y sin errores Conocimiento sobre la arquitectura: En RUP se intentará reducir la complejidad del software a producir a través de una planificación intensiva. En XP se conseguirá a través de la programación a pares que ya en la creación del código se puedan evitar errores y malos diseños. En FDD sin embargo se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una arquitectura sencilla y sin errores

27 Puntos flacos: Puntos flacos: 1. FDD presenta su talón de Aquiles en la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el principio, con la elaboración del modelo global, puesto que no es tan ágil como podría serlo XP. 2. Para el desarrollo de software por medio de equipos pequeños (hasta unas diez personas) es RUP definitivamente muy grande y practicamente inalcanzable. Se deben repartir 31 roles y generar más de 100 artefactos distintos. 3. XP es un proceso muy orientado a la implementación. Lo que es muy poco deseable en XP es el hecho de evitar cualquier tipo de documentación fuera del código fuente (UML juega un papel prácticamente nulo, por ejemplo).

28 Conclusiones FDD, es una metodología de desarrollo ágil, que disminuye el riesgo de los proyectos, pues gracias a sus entregas tangibles y a el constante monitoreo de su calidad, se asegura el firme avance del mismo. FDD, es una metodología de desarrollo ágil, que disminuye el riesgo de los proyectos, pues gracias a sus entregas tangibles y a el constante monitoreo de su calidad, se asegura el firme avance del mismo. FDD, permite dejar satisfechos a los desarrolladores, gerentes y clientes sin afectar el proyecto. Esto gracias a un buen manejo de las actividades, a la disminución del riesgo del proyecto y al aseguramiento de la calidad del mismo, respectivamente. FDD, permite dejar satisfechos a los desarrolladores, gerentes y clientes sin afectar el proyecto. Esto gracias a un buen manejo de las actividades, a la disminución del riesgo del proyecto y al aseguramiento de la calidad del mismo, respectivamente.

29 En conclusión FDD: En conclusión FDD: Ayuda al equipo a producir resultados periódicos y tangibles. Ayuda al equipo a producir resultados periódicos y tangibles. Esta metodología utiliza pequeños bloques llamados features, los cuales contienen la funcionalidad del sistema. Esta metodología utiliza pequeños bloques llamados features, los cuales contienen la funcionalidad del sistema. Organiza los bloques que están relacionados entre sí, en una lista llamada feature set. Organiza los bloques que están relacionados entre sí, en una lista llamada feature set. Hace énfasis en la obtención de resultados cada dos semanas. Hace énfasis en la obtención de resultados cada dos semanas. Asegura en gran parte la calidad del software entregado. Asegura en gran parte la calidad del software entregado. Es adaptativo, pues permite realizar cambios de último momento debido a nuevos requerimientos y a las necesidades del negocio. Es adaptativo, pues permite realizar cambios de último momento debido a nuevos requerimientos y a las necesidades del negocio.


Descargar ppt "FDD: Feature Driven Development Desarrollo Basado en Funcionalidades Sarah Gutiérrez Hernán Zapata Juan Pablo Arias Cristian Zambrano."

Presentaciones similares


Anuncios Google