Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Universidad
Nacional
de Trujillo
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
ESCUELA INFORMATICA
TEMA:
DOCENTE:
VIII
Trujillo Per
2015
RESUMEN
Contenido
LA FILOSOFA DE FDD..................................................................................... 5
EL PROCESO................................................................................................... 6
PROCESOS DEL FDD....................................................................................... 9
1.
2.
3.
Plan by Feature:.................................................................................. 13
4.
Design by Feature:.............................................................................. 16
5.
ROLES Y RESPONSABILIDADES.....................................................................20
CONCLUSIONES............................................................................................ 22
REFERENCIAS BIBLIOGRAFICAS....................................................................23
LA FILOSOFA DE FDD
A pesar de los muchos avances en el desarrollo de software, no es
muy comn para los proyectos de los ltimos aos el uso de functiondriven process. No obstante, muchos proyectos de software exceden
el presupuesto, fallan con el programa y entregan menos de lo
deseado. Como si fuera poco, el crecimiento de la tecnologa hace
que los proyectos ms modernos sean poco exitosos ya que los
cambios tecnolgicos se realizan con tanta rapidez que es imposible
poder planificar a largo plazo.
Lo normal para los proyectos con iteraciones cortas (fast-cycle-time
projects) es un feature-driven iterative process, comenzando por los
requerimientos y el modelado, siguiendo por el diseo y construccin
en base a incrementos. En este trabajo formalizaremos el proceso
llamado Feature-Driven Development (FDD).
Esta metodologa propone tener etapas de cierre cada dos semanas,
lo cual implica que los desarrolladores tendrn nuevas actividades
que realizar en dicho perodo de tiempo. Esto hace que la motivacin
del equipo se mantenga durante todo el proyecto debido a que se ven
los resultados peridicamente.
A los gerentes les fascina tener resultados a la vista cada cierto
perodo de tiempo ya que reducen el riesgo del proyecto por tener
entregas peridicas y tangibles. Con FDD, se obtienen porcentajes
reales del proceso, lo cual ayuda a demostrar al cliente donde se
encuentra el proyecto.
A los clientes tambin les gusta esta idea ya que pueden tener planes
con entregas y resultados frecuentes. Adems, los clientes saben
cun lejos est el proyecto de su finalizacin.
Con FDD se pretende dejar satisfechos a los desarrolladores, gerentes
y clientes sin afectar al proyecto.
EL PROCESO
Dicho proceso consiste de cinco fases secuenciales durante las
cuales el diseo y la construccin del sistema se llevan a cabo.
3- Plan by Feature
En esta etapa se incluye la creacin de un plan de alto nivel, en el
cual la lista de requerimientos es ordenada en base a la prioridad y
a la dependencia entre cada requerimiento. Adems, las clases
identificadas en la primera etapa son asignadas a cada
programador.
4 y 5- Design and Build by Feature
Un conjunto de requerimientos es seleccionado de la lista de
requerimientos.
El diseo y construccin de la funcionalidad es un proceso iterativo
durante el cual los requerimientos seleccionados son producidos.
Una iteracin puede llevar desde unos pocos das a un mximo de
dos semanas. Este proceso iterativo incluye tareas como inspeccin
del diseo, codificacin, testing unitario, integracin e inspeccin
del cdigo. Luego que la iteracin llega a su fin se realiza un main
build de la funcionalidad en el cual se integra la funcionalidad.
Dicho main build se realiza mientras la siguiente iteracin
comienza.
La siguiente imagen detal a como se desar ol an las iteraciones 4 y
5.
Grupo de
Requerimien
tos
Diseo
Inspecci
n del
diseo
Codificaci
n
Unidad
Inspecci
de
n del Integraci
n
cdigoPrueba
Entrada:
El cliente est listo con la construccin del sistema. Adems
posee una lista de requerimientos especificada de alguna
forma.
Tareas
Nombre de la
tarea
Descripcin
Responsable
s
Requerida /
Opcional
Formacin del
model team
Project
Manager
Requerida
Domain
Walkthrough
Estudios de la
documentacin
expertos
del
dominio
y
desarrolladores.
Un experto del dominio realiza un
pequeo
tutorial
del
rea
modelada.
Modeling
Team
Requerida
Modeling
Team
Opcional
Chief
Arquitect
Chief
Programmers
Requerida
Modeling
Team /
pequeos
grupos.
Requerida
Chief
Arquitect
Modeling
Team
Requerida
Chief
Requerida
El
equipo
investiga
los
documentos
disponibles
incluyendo si es modelo de
componentes,
requerimientos
funcionales, user guides, etc.
Desarrollo del
modelo en
reas
Desarrollo del
Modelo Global
Arquitect
Chief
Programmers
Verificacin:
Se realizan evaluaciones sobre el equipo para clarificar el
Salida:
Al final de la etapa, el equipo debe obtener los siguientes
resultados, sujetos a revisiones y a la aprobacin del Developer
Manager y el Chief Arquitect:
Diagrama de clases del sistema
Feature list informal
Registros de las alternativas ms importantes sobre el
modelo
Entrada:
Diagrama global del sistema y feature
anterior.
Tareas
Nombre de la
tarea
Descripcin
Responsable
s
Requerida /
Opcional
Formacin del
Feature List
Team
Project
Manager
Development
manager
Requerida
Feature List
team
Requerida
Feature List
team
Requerida
Feature List
team
Requerida
Identificacin
de feaures.
Formacin del
Feature Set
Priorizacin de
las features
Divisin de las
features
complejas
Salida:
Para el xito de eta etapa el feature-list Team debe tener
completa cada
feature
del sistema, agrupada en features
sets and mayor feature sets.
3. Plan by Feature:
Resumen:
La tercera actividad, planificar por features, toma como input la
lista priorizada de la fase anterior y establece los tiempos las futuras
iteraciones. En esta actividad participan el lder del proyecto, el lder
de desarrollo y el programador jefe. A medida que se realiza la
Entrada:
La feature list (lista de funciones) de la etapa anterior.
Tareas:
Nombre de la
tarea
Descripcin
Responsables
Requerida/Opcional
Formacin del
Planing Team
Project Manager
Requerida
Planning Team
Requerida
Planning Team
Requerida
Planning Team
Requerida
Orden de
realizacin
de la Mayor
Feature Set y de
las feature
lists.
Asignacin de las
clases a los Class
Owners
Asignacin de las
Mayor Feature
Sets y
features a los
Chief
Programmers
Verificacin:
Se realiza una verificacin del plan tomando en cuenta la opinin de todos los
miembros posibles del equipo.
Salida:
El Planning Team debe producir un plan de desarrollo, sujeto a la revisin y aprobacin
del Development Manager y del Chief Architect. Se debe entregar:
4. Design by Feature:
Resumen:
El Chief Programmer toma la prxima feature a ser diseada,
identifica las clases involucradas y contacta los Class Owner
correspondientes. Luego el equipo, trabaja en la realizacin del
diagrama de secuencia correspondiente. El Class Owner hace una
descripcin de la clase y sus mtodos.
Disear por features y construir por feature, estn relacionadas
con aparte productiva del proceso en que se construye la aplicacin
de manera incremental. Empezando por el diseo que toma los
features correspondientes a la iteracin, el equipo de programadores
liderado por el programador jefe identifica las clases, atributos y
mtodos que realizan la funcionalidad requerida .Mediante la
utilizacin de diagramas de secuencia de UML, se verifica que el
diseo pueda ser implementado. Se realiza tambin una inspeccin
del diseo en los casos en que la complejidad de la funcionalidad lo
requiera.
Entrada:
Como entrada se necesitan los documentos desarrollados fase
anterior.
Tareas:
Nombre de la
tarea
Descripcin
Responsables
Requerida/Opcio
nal
Formacin del
DBS
Team
El Chief Programmer
identifica las clases
involucradas en el diseo
de la feature. Luego
contacta a los Class
Owners correspondientes
y tambin a los expertos
del dominio, si es
Chief
Programmer
Requerida
Domain
Walkthrough
Construccin de
un
diagrama de
secuencia
Descripcin de
clases y mtodos
Inspeccin del
diseo
Feature Team,
Expertos del
dominio
Opcional
Feature Team
Requerida
Clas Owner
Requerida
Feature Team
Requerida
Entrada:
Tareas.
Descripcin
Responsable
s
Requerida/
Opcional
Verificacin:
Se realizan tareas de inspeccin y verificacin del cdigo.
ROLES Y
RESPONSABILIDADES
El FDD clasifica sus roles en las siguientes tres categoras:
Key roles
Project manager
CONCLUSIONES
1. FDD es un proceso que ayuda al equipo a producir
resultados peridicos y tangibles.
2. Esta metodologa utiliza pequeos bloques que contienen
la funcionalidad del sistema, llamados features.
3. Organiza los bloques que estn relacionados entre s, en
una lista llamada feature set.
4. Hace nfasis en la obtencin de resultados cada dos
semanas.
5. Incluye estrategias de planificacin que hacen que las
features puedan desarrollarse en dichos lapsos.
REFERENCIAS
BIBLIOGRAFICAS
1. Articulo: www.info.vtt.fi/pdf/, Pekka Abrahamsson, Outi Salo & Jussi
Ronkainen(2005), Agile software development methods.
Review and analysis.
2. www.featuredrivendevelopmente.com
3. Peter Coad, Eric Lefebvre Jeff De Luca(1999). JAVA
Modelling in Color with UML. Enterprise Components and
process. www.oi.com