UNIVERSIDAD NACIONAL DEL

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


Taller de Integracin de Sistemas de
Informacin
TEMA: Feature driven development
INTEGRANTES:
Mamani Sucasaire Christian Jordy 102113




PUNO PER
2014


METODOLOGIA FEATURE DRIVEN DEVELOPMENT


1. DEFINICION.

Es una metodologa gil diseado 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 aos 90. Esta
metodologa se enfoca principalmente en iteraciones cortas que permite entregas
tangibles del producto en corto periodo de tiempo que como mximo son de dos
semanas.
Las iteraciones se deciden en base a features (de ah el nombre del proceso) o
funcionalidades, que son pequeas 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 slo las
fases de diseo y construccin.
No requiere un modelo especfico de proceso y se complementa con otras
metodologas. Enfatiza cuestiones de calidad y define claramente entregas
tangibles y formas de evaluacin del progreso.


2. CARACTERISTICAS.

- No hace nfasis en la obtencin de los requerimientos sino en cmo se realiza
las fases de diseo y construccin.
- Se preocupa por la calidad, por lo que incluye un monitoreo constante.
- El mtodo es cooperativo, ya que aconseja que el cliente y los desarrolladores
trabajen en equipo.
- Es un mtodo 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 mtodo propone establecer pequeas etapas de
cierre, en las que tanto el cliente como los desarrolladores pueden hacer una
evaluacin continua del producto. Es decir, se obtienen resultados peridicos
- 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 segn va avanzando el proyecto, limitndose las primeras a un
proceso de refinamiento, las cinco fases son:
- Desarrollo de un modelo general.
- Construccin de la lista de funcionalidades.
- Planeacin por funcionalidad.
- Disear 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 visin del dominio, del
contexto y de los requerimientos funcionales del software.
A continuacin, dicho dominio se divide en partes o reas que sern
estudiadas detalladamente. Consiste en dividir el dominio global en otros
dominios ms pequeos llamados reas (divide y vencers).
Despus, los desarrolladores son los encargados de construir los diagramas
de clases por cada una de las reas.

b. Construccin 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 divisin para abordar problemas ms
pequeos, se divide en subconjuntos segn la dependencia de las
funcionalidades. Los subconjuntos resultantes son nuevamente revisados por
el cliente y por los responsables para su aprobacin.






c. Planeacin por funcionalidad.

Se ordena los subconjuntos de funcionalidades del paso anterior en funcin de
su prioridad y dependencia, y son entregados a los programadores jefes.

d. Diseo en base a las funcionalidades.

Se selecciona el primer subconjunto de funcionalidades y se procede a
elaborar el diseo haciendo uso de diagramas de secuencia detallado y
actualizando los diagramas de clases.

e. Implementar en base a las funcionalidades.

En base al diseo 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 das a un par de semanas), e incluye
revisin de diseos, generacin de cdigos, pruebas unitarias, integracin y
revisin del cdigo.

4. ROLES Y RESPONSABILIDADES.

El mtodo FDD define tres categoras de roles: roles claves, roles de soporte y
roles adicionales.

a. Roles claves.
Gerente del proyecto: Es el lder de, proyecto. Se encarga de la
administracin, direccin y financiamiento del proyecto.
Arquitecto jefe: Responsable del diseo 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 diseo del proyecto y selecciona las prximas 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 diseo,
codificacin, pruebas y documentacin.
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
programacin o tecnologa.
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.
Tcnico de documentacin: Son los responsables de elaborar
documentacin para los usuarios finales del sistema.


5. COMPARACION.

Podramos pensar que no es posible comparar los distintos mtodos de desarrollo,
y que todo depende de nuestros gustos personales, pero puesto que todos los
procesos se centran en la produccin de software y que el proceso se
implementara para aumentar la calidad del software producido y la eficiencia de
los desarrolladores, es deseable una comparacin, pero no en su conjunto, sino
segn los medios que emplea y sus resultados.

RUP, XP y FDD tienen pocas similitudes entre s, aunque XP YFDD poseen
algunas ms al ser ambos ligeros, orientado al cliente y de iteraciones cortas y
rpidas.

a. Tamao de los equipos.

FDD y XP se implementan mayor para proyectos cortos y equipos ms
pequeos, siendo quizs FDD ms escalable que xp.

b. Obtencin de requisitos.

RUP y XP crean como base UseCases y UserStories, FDD por el contrario no
define explcitamente esa parte del proyecto sobre la adquisicin 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 ms
documentacin que XP (donde apenas existe cdigo fuente) pero menos que
RUP (que intenta documentar todo)

d. Relacin con el cliente.

La aseguracin de la calidad en XP y FDD no se basa en formalismos en la
documentacin, si no en controles propios y una comunicacin fluida con el
cliente. Tanto XP como en FDD, el cliente recibe despus de cada iteracin un
pedazo funcional del programa.

e. Desarrollo.

Todos ellos se basan en un proceso iterativo. Esto permite acercarse poco a
poco a la solucin sin entrar demasiado rpido en detalles, aunque las
iteraciones de XP y FDD tienen por lo general una duracin menor que en
RUP.

f. Conocimiento sobre la arquitectura.

En FDD se usan las sesiones de trabajo conjuntas en fase de diseo para
conseguir una arquitectura sencilla y sin errores y las revisiones de cdigos
guiadas por algn programador con ms experiencia.