FACULTAD DE INGENIERA

ESCUELA PROFESIONAL DE INGENIERA DE SISTEMAS

TEMA : METODOLOGIAS GILES

ASIGNATURA : INGENIERA DE SOFTWARE II

DOCENTE TUTOR : MG. ING. HEBER GMEZ HURTADO

CICLO : VI

INTEGRANTES :

IDROGO CAVERO ARTURO PAL

PIURA PER
2017
 Featured Driven Development (FDD)

Introduccin.

La iniciativa de Desarrollo Dirigida por Rasgos es un tipo de metodologa

gil que rige su arquitectura por las funcionalidades del programa a
implementar. Como cualquier otra metodologa de esta corriente,
quiere romper con la nocin de planea el trabajo y trabaja el plan, y
sigue un progreso ms adaptativo y dinmico. No enfatiza los
requerimientos y la generacin de documentacin previa, si no que se
centra en realizar las fases de diseo y construccin. Sin embargo se
preocupa mucho de la calidad del producto, ya que insiste en el
monitoreo constante.

De su historia podemos remarcar que fue desarrollado por Peter Coad,

Eric Lefebvre y Jeff DeLuca, siendo este ltimo en que lo llev a cabo
por primera vez en un caso real de misin crtica. Se le encomend la
tarea de rescatar un proyecto que haba durado dos aos desde su
inicio. Pero ste todava no posea ni una sola lnea de cdigo, teniendo
ya 3500 pginas de documentacin. El rescate fue un xito. Sin
embargo no comenz a utilizarse de manera considerablemente asidua
hasta finales de los 90, para implementar grandes aplicaciones
bancarias.
Caractersticas.

Como algunas otras metodologas giles, se basa en un proceso

iterativo, pero en este caso es parcial, como ya describiremos en el
apartado de Fases. Sin embargo, como hemos dicho, la principal
propiedad del FDD es la orientacin de su arquitectura dirigida los
rasgos o funcionalidades del programa a producir. As nos centraremos
en definir este concepto de feature para aclarar por extensin cmo
trabaja la metodologa.

En FDD, las funcionalidades son lo que en Extreme Programing eran las

historias de usuario, son el eje de trabajo. Se escriben utilizando el
lenguaje del dominio, de manera especfica, sin cabida a
ambigedades y usando una estructura similar a: <accin> [un|el]
<resultado> [de|a|para|por|] <objeto> [con|para|de]
<parmetros>. El <objeto> identifica la clase en el modelo de dominio,
el agente que realiza la operacin, la <accin>; que es el mtodo o la
funcin encapsulada en dicha clase y que tiene como valor de salida el
<resultado>.

Cada una de las funcionalidades equivale a un requisito estipulado

previamente por el patrocinador del producto. Tiene siempre un
significado empresarial y describe algn valor de negocio.
Normalmente tambin es posible expresarlos como secuencia, cuando
existan requisitos para la disponibilidad de unos respecto de otros (el
documento que se genera en este caso, como veremos en los
artefactos es el Diagrama Secuencial UML).

El paradigma de programacin que se suele usar en esta clase de

metodologas es el FOP (Feature-Oriented Programming), o
Programacin orientada a rasgos. Este enfoque para sintetizar
productos software convierte los programas en una pila de capas, de
las cuales, cada una aporta una funcionalidad nueva al conjunto de
capas que envuelve. Siempre se trabaja aadiendo nuevo cdigo a un
programa ya existente, para que finalmente el resultado sea una
composicin de transformaciones con la superposicin de capas. Las
capas son lo que se pas a denominar features o funcionalidades,
para dar nombre al paradigma.
Fases.

Una de las principales peculiaridades de este mtodo de desarrollo de

sistemas software gil, con respecto al resto de sus anlogos, es que no
requiere la presencia del cliente todo lo asiduamente que se suele
demandar a lo largo de sus etapas. El peso de estas recae casi
ntegramente en los desarrolladores.

Las fases iniciales del progreso son secuenciales y nicas en el ciclo de

vida. La primera de todas ellas, cuando comienza el desarrollo, es la
realizacin de un modelo global. Aqu, los expertos del dominio, tienen
en cuenta el contexto y los requerimientos del sistema para, aportando
su visin, modelar el dominio dividindolo en las diferentes clases. Estas
reas seccionales se analizan detalladamente por separado
construyendo un diagrama de objetos para cada una.

A continuacin, los desarrolladores elaboran una lista de

funcionalidades (con la estructura que hemos explicado en el apartado
de caractersticas) que en conjunto engloban la funcionalidad total del
sistema. Se puede subdividir la lista en conjuntos dependiendo de la
semejanza y la dependencia entre funcionalidades. Esta lista
posteriormente se revisa por el cliente y por los encargados de
validacin. Una vez se posee la lista repasada y confirmada, se
comienza a desarrollar la planificacin por funcionalidad. En esta etapa
ya se ordenan en un diagrama, jerrquicamente los conjuntos de rasgos
segn su prioridad en el desarrollo, y se asignan a su vez a los
programadores jefes.

Una vez llegado a este punto, como algunas otras metodologas giles,
se basa en un proceso iterativo. Aunque a diferencia del resto, cada
iteracin solo engloba las dos fases finales, y no todas ellas. Estas fases
son el diseo y la construccin. En ellas, en cada iteracin, se
selecciona un subconjunto de rasgos a realizar de la lista y se despliega
primero diseando y revisando el diseo. Posteriormente se implementa
la funcionalidad y se realizan pruebas unitarias dentro de la
construccin (no hay una fase especifica y definida para las pruebas,
como ocurre en la mayora de metodologas). Para finalizar integrando
el cdigo e inspeccionndolo. As una y otra vez, en iteraciones que
pueden durar desde unos pocos das hasta un mximo de dos semanas.
 Fases de FDD

Roles.

Una de las principales crticas que propinan a este tipo de metodologa

es la excesiva jerarquizacin dentro de sus roles. Algunos consideran
que para conservar su carcter gil ste debera de ser ms liviana o
sencilla. An as, las responsabilidades que recaen sobre los
desarrolladores se pueden clasificar en tres grandes grupos segn su
peso en el supuesto organigrama empresarial de desarrollo.

El primer grupo lo forman los roles clave que como su nombre indica son
indispensables para el progreso del sistema. En este grupo se encuentra
el administrador de proyecto, que es quien siempre tiene la ltima
palabra en visin, cronograma y seleccin del personal. De la parte ms
tcnica est encargado el arquitecto jefe, que controla el diseo global
y la implementacin de las diferentes funcionalidades desde el nivel
ms alto. Quien se preocupa de que todas se desarrollen
correctamente es el manager de desarrollo, encargndose de los
conflictos en el equipo y de resolver problemas referentes a los recursos.

A un nivel ms bajo, pero en el mismo grupo, se encuentra el

programador jefe, quien analiza los requerimientos y tras acabar el
diseo, selecciona los rasgos que se desarrollarn en cada iteracin.
ste est al mando de los propietarios de clase, a quienes les asigna
rasgos propios para que se responsabilicen de su implementacin, y
participen en la decisin de incluirlos o no en la siguiente iteracin. Y por
ltimo, para completar los roles clave se tiene el experto de dominio,
que puede personificarse en el cliente, el patrocinador o un analista de
negocio. Su tarea es controlar los requerimientos y su correcta cobertura
en el desarrollo.
Para complementar a estos cargos, tambin son necesarios los llamados
roles de soporte. Aqu se encuentra el administrador de entrega, que es
quien se rene con el programador jefe para revisar sus reportes y
transmitrselos al manager de desarrollo. Controla en general el avance
y se lo comunica al cliente semanalmente. Por otro lado se tiene al gur
del lenguaje, que es quien conoce a la perfeccin la tecnologa de
codificacin que se est utilizando, y est a disposicin de los
desarrolladores para aclarar cualquier cuestin referente a ella.

En este grupo tambin existe el rol de manager de dominio, es quien

organiza y lidera al grupo de expertos de dominio, y resuelva sus
diferencias a la hora de concretar los requerimientos del sistema.
Adems, otro rol de soporte es el ingeniero de construccin, que se
encarga de preparar, mantener e impulsar el proceso de construccin
a la vez que controla las versiones resultado de cada iteracin y publica
la documentacin relevante. Tambin se cuenta con el rol del
herramentista para la creacin de herramientas de soporte especficas
y la gestin tanto de bases de datos como de las webs. Por ltimo el
administrador del sistema es quien controla el ambiente de trabajo y
empaqueta el producto para cada entrega.

Para finalizar, el ltimo grupo es el de roles adicionales. En l se

encuentran los verificadores (personas que pueden llegar a ser
independientes del equipo del proyecto, que testean el sistema para
comprobar que cumple los requisitos del cliente), los encargados del
despliegue (son quienes adaptan la documentacin previa a la
requerida por el nuevo sistema a desarrollar y contribuyen a su
lanzamiento) y los escritores de documentos tcnicos (que preparan la
documentacin relevante para los usuarios).
Artefactos.
A lo largo del proceso, el primero y principal documento que se genera
es en el que se definen todas las funcionalidades de la aplicacin, el
Modelo de Dominio. ste se elabora utilizando la tcnica llamada
Unifieid Modeling Languaje (UML), como diagrama de clases, aunque
posteriormente fue mejorado por Peter Coad dando lugar al Domain
Neutral Component (DNC) y arquetipos de clase. A continuacin
observamos un ejemplo que modela el dominio de un hotel y las
conferencias que se realizan en l, en formato DNC.

DNC

Como hemos dicho, cada modelo funcionalidades se puede traducir al

instante en el artefacto llamado Diagrama Secuencial UML. En el caso
del ejemplo anterior, la conversin sera la siguiente:
Conclusin

Concluimos definiendo al FDD como una metodologa de desarrollo gil

destinada a proyectos cortos y de reducido personal, pero muy
escalable por otra parte. A diferencia de otras, no define explcitamente
una fase para la obtencin de requisitos ni para la realizacin de
pruebas. Sin embargo, al dividir el proyecto en unidades pequeas
(rasgos), esta metodologa es la ms adecuada para realizar un
seguimiento y una monitorizacin del progreso.

Respecto a la carga de trabajo que recae sobre los desarrolladores,

FDD podemos decir que es un proceso intermedio, basndonos en
genera ms documentacin que algunas metodologas giles, pero no
tanta como otras, y es en la fase de diseo, con sesiones de trabajo
conjuntas donde se decide la estructura de la arquitectura. En cuanto a
la relacin con el cliente, esta es fluida y sin excesivos formalismos,
basada en controles propios y una comunicacin constante.

Como puntos flacos de este tipo de desarrollo software observamos la

necesidad de poseer expertos en el equipo de trabajo que marquen
desde el principio el camino a seguir, con el modelo global. Adems,
como ya hemos comentado, existe demasiada jerarquizacin entre los
roles. Estos hechos pueden restarle fluidez al desarrollo. Pero sus
principales puntos fuertes son que disminuye en gran medida el riesgo
de los proyectos, con la constante monitorizacin de su calidad (sencilla
gracias a la divisin en rasgos) y las peridicas entregas tangibles
(gracias a la estructura iterativa de sus fases), y que adems es muy
adaptativo y permite cambios de ltimo momento.