• Author / Uploaded
• Christian Jordy Mamani Sucasaire

• Categories
• Software
• Ingeniería de software
• Ingeniería Informática
• Tecnología
• Áreas de informática

Citation preview

UNIVERSIDAD NACIONAL DEL ALTIPLANO- PUNO FACULTAD DE INGENIERIA MACANICA, ELECTRONICA Y SISTEMAS ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

Taller de Integración de Sistemas de Información TEMA: “Feature driven development” INTEGRANTES:  Mamani Sucasaire Christian Jordy

PUNO – PERÚ 2014

102113

METODOLOGIA FEATURE DRIVEN DEVELOPMENT

1. DEFINICION. Es una metodología ágil diseñado para el desarrollo de software, basada en la calidad y el monitoreo constante del proyecto. Fue desarrollado por Jeff De Luca y Peter Coad a mediados de los años 90. Esta metodología se enfoca principalmente en iteraciones cortas que permite entregas tangibles del producto en corto periodo de tiempo que como máximo son de dos semanas. Las iteraciones se deciden en base a features (de ahí el nombre del proceso) o funcionalidades, que son pequeñas partes del software con significado para el cliente. Así, construir el sistema de ventas es algo que requiere mucho tiempo, y construir el sistema de persistencia no tiene significado para el cliente. A diferencia de otros procesos ágiles no cubre todo el ciclo de vida sino sólo las fases de diseño y construcción. No requiere un modelo específico de proceso y se complementa con otras metodologías. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluación del progreso.

2. CARACTERISTICAS. -

-

No hace énfasis en la obtención de los requerimientos sino en cómo se realiza las fases de diseño y construcción. Se preocupa por la calidad, por lo que incluye un monitoreo constante. El método es cooperativo, ya que aconseja que el cliente y los desarrolladores trabajen en equipo. Es un método que nos ayuda a evitar desviaciones sustanciales sobre lo presupuestado, ayuda a contrarrestar fallos en el software y a evitar entregas un producto inferior a lo pactado. Esto se consigue porque el método propone establecer pequeñas etapas de cierre, en las que tanto el cliente como los desarrolladores pueden hacer una evaluación continua del producto. Es decir, se obtienen resultados periódicos Y es adaptivo. Es decir, es posible realizar cambios de último momento sin que la etapa de desarrollo se vea sustancialmente afectada.

3. PROCESOS. El FDD tiene cinco procesos. Las primeras 3 fases ocupan gran parte del tiempo en las primeras iteraciones, siendo las dos últimas las que absorben la mayor parte del tiempo según va avanzando el proyecto, limitándose las primeras a un proceso de refinamiento, las cinco fases son: - Desarrollo de un modelo general. - Construcción de la lista de funcionalidades. - Planeación por funcionalidad. - Diseñar en base a las funcionalidades. - Implementar en base a las funcionalidades.

a. Desarrollo de un modelo global. En esta fase inicial, los participantes ya tienen una visión del dominio, del contexto y de los requerimientos funcionales del software. A continuación, dicho dominio se divide en partes o áreas que serán estudiadas detalladamente. Consiste en dividir el dominio global en otros dominios más pequeños llamados áreas (divide y vencerás). Después, los desarrolladores son los encargados de construir los diagramas de clases por cada una de las áreas.

b. Construcción de una lista de funcionalidades. Los desarrolladores elaboran una lista de funcionalidades del sistema global y es evaluada por el cliente. Dicha lista, recurriendo nuevamente a la división para abordar problemas más pequeños, se divide en subconjuntos según la dependencia de las funcionalidades. Los subconjuntos resultantes son nuevamente revisados por el cliente y por los responsables para su aprobación.

c. Planeación por funcionalidad. Se ordena los subconjuntos de funcionalidades del paso anterior en función de su prioridad y dependencia, y son entregados a los programadores jefes.

d. Diseño en base a las funcionalidades. Se selecciona el primer subconjunto de funcionalidades y se procede a elaborar el diseño haciendo uso de diagramas de secuencia detallado y actualizando los diagramas de clases.

e. Implementar en base a las funcionalidades. En base al diseño de la fase anterior, se procede a construir las funcionalidades mediante un proceso iterativo. Como ya se ha dicho, las iteraciones deben ser cortar (de unos 3-4 días a un par de semanas), e incluye revisión de diseños, generación de códigos, pruebas unitarias, integración y revisión del código.

4. ROLES Y RESPONSABILIDADES. El método FDD define tres categorías de roles: roles claves, roles de soporte y roles adicionales. a. Roles claves.  Gerente del proyecto: Es el líder de, proyecto. Se encarga de la administración, dirección y financiamiento del proyecto.  Arquitecto jefe: Responsable del diseño global del sistema.  Director de desarrollo: Puede ser un rol combinado con el de gerente del proyecto. Se encarga diariamente de las actividades de desarrollo. Resuelve problemas de conflictos dentro del equipo y problemas referentes a recursos.  Programador jefe: Es el responsable de analizar requerimientos, participa en el diseño del proyecto y selecciona las próximas funcionalidades a desarrollar.  Propietarios de clases: Es el responsable de desarrollar las clases que le fueron asignada. Trabajan guiados por el programador jefe en el diseño, codificación, pruebas y documentación.  Experto de dominio: Poseen el conocimiento de los requerimientos del sistema. Son los que trasladan a los desarrolladores dicho conocimiento, y puede ser un usuario, un cliente, un analista….cualquiera que sepa perfectamente que es lo que tiene que hacer el sistema.

b. Roles de soporte. 

 

Gerente de entrega: Controla el avance del proyecto. Reporta resultados al gerente de proyecto y al cliente donde se aprecia el porcentaje de avance de cada funcionalidad. “Guru” de lenguaje: Experto especialista en un tipo de lenguaje de programación o tecnología. Herramientita: Es el encargado de administrar y mantener los servidores, conexiones, comunicaciones, etc.

c. Roles adicionales.  

Tester: Es el encargado de ir probando las funcionalidades del sistema y verificar que éstas cumplan con los requerimientos del cliente. Técnico de documentación: Son los responsables de elaborar documentación para los usuarios finales del sistema.

5. COMPARACION. Podríamos pensar que no es posible comparar los distintos métodos de desarrollo, y que todo depende de nuestros gustos personales, pero puesto que todos los procesos se centran en la producción de software y que el proceso se implementara para aumentar la calidad del software producido y la eficiencia de los desarrolladores, es deseable una comparación, pero no en su conjunto, sino según los medios que emplea y sus resultados. RUP, XP y FDD tienen pocas similitudes entre sí, aunque XP YFDD poseen algunas más al ser ambos ligeros, orientado al cliente y de iteraciones cortas y rápidas. a. Tamaño de los equipos. FDD y XP se implementan mayor para proyectos cortos y equipos más pequeños, siendo quizás FDD más escalable que xp. b. Obtención de requisitos. RUP y XP crean como base UseCases y UserStories, FDD por el contrario no define explícitamente esa parte del proyecto sobre la adquisición de requisitos, y solo define proceder a partir del momento en que se ya se han recogido dicho requisito.

c. Carga de trabajo. FDD es un proceso intermedio, en el sentido de que generan más documentación que XP (donde apenas existe código fuente) pero menos que RUP (que intenta documentar todo) d.

Relación con el cliente. 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. Tanto XP como en FDD, el cliente recibe después de cada iteración un pedazo funcional del programa.

e. Desarrollo. Todos ellos se basan en un proceso iterativo. Esto permite acercarse poco a poco a la solución sin entrar demasiado rápido en detalles, aunque las iteraciones de XP y FDD tienen por lo general una duración menor que en RUP. f.

Conocimiento sobre la arquitectura. En FDD se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una arquitectura sencilla y sin errores y las revisiones de códigos guiadas por algún programador con más experiencia.