CARACTERSTICAS

Es un proceso gil para el desarrollo de sistemas .

Fue diseado por Peter Coad, Eric Lefebvre y Jeff DeLuca.

No hace nfasis en la obtencin de los requerimientos sino en como se realizan las fases de diseo y construccin.

Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.

CARACTERSTICAS
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.

Se obtienen resultado peridicos y tangibles.

Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la direccin de la empresa pueden ver y monitorear.

Define claramente entregas tangibles y formas de evaluacin del progreso del proyecto.

El enfoque DIC define cinco actividades de colaboracin dentro del marco de trabajo (en el DIC esta se llaman procesos) como se muestra en la figura.

Desarrollar un modelo general

Elaborar una lista de caracterstic a

Plan por caracterstic as

Diseo por caracterstic as

Construcci n por caracterstic as

(Ms forma que contenido)

Una lista de caracterstic as agrupadas en conjuntos y reas de contenido.

Un plan de desarrollo Propietario de clase Propietario del conjunto de caracterstic as

Un paquete de diseo (secuencias)

Funcin cliente-valor completada

Descripcin del Proceso(1)

Desarrollo de un modelo global
Cuando comienza el desarrollo, los expertos del dominio estn al tanto de la visin, el contexto y los requerimientos del sistema a construir.

Se divide el dominio global en reas que son analizadas detalladamente.

Los desarrolladores construyen un diagrama de clases o de objetos por cada rea.

Se construye un modelo global del sistema.

Descripcin del Proceso(2)

Una funcionalidad es un tem til a los ojos del cliente. 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. Se divide la lista en subconjuntos segn la afinidad y la dependencia de las funcionalidades. La lista es finalmente revisada por los usuarios y los responsables para su validacin y aprobacin.

Construccin de una lista de funcionalidades:

Descripcin del Proceso(3)

En este punto se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes.

Planeacin por funcionalidad

Descripcin del Proceso(4)

Diseo por funcionalidades y Construccin por funcionalidades

Se selecciona un conjunto de funcionalidades de la lista.

Se procede a disear y construir la funcionalidad mediante un proceso iterativo.

Una iteracin puede tomar de unos pocos das a un mximo de dos semanas. El proceso iterativo incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo.

Roles y Responsabilidades
Categoras Key Roles / Roles claves Supporting Roles / Roles de soporte Additional Roles / Roles adicionales

Key Roles / Roles claves

Project Manager / Director del Proyecto:
* Lider administrativo y financiero del proyecto.
* Protege al equipo de situaciones externas.

Chief Architect / Arquitecto jefe:

* Diseo global del sistema. * Ejecucin de todas las etapas.

Development Manager / Director de desarrollo

* Lleva diariamente las actividades de desarrollo.

* Resuelve conflictos en el equipo. * Resuelve problemas referentes a recursos.

Chief Programmer / Programador Jefe

* Analiza los requerimientos.
* Disea el proyecto. * Selecciona las funcionalidades a desarrollar de la ultima fase del FDD.

Class Owner / Propietario de clases

* Responsable del desarrollo de las clases que se le asignaron como propias. * Participa en la decisin de que clase ser incluida en la lista de funcionalidades de la prxima iteracin.

 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.

Supporting roles / Roles de soporte

Domain Manager
* Lidera al grupo de expertos del dominio. * Resuelve sus diferencias de opinin concernientes a los requerimientos del sistema.

Release Manager
* Controla el avance del proceso mediante la revisin de los reportes del Chief Programmer. * Reporta resultados obtenidos semanalmente al gerente, al cliente donde incluye el porcentaje de avance de cada feature.

 Language Lawyer / Guru del Lenguaje

* Responsable de poseer un vasto conocimiento en, por ejemplo, un lenguaje especfico de programacin o tecnologa. * Es muy importante cuando se trabaja una nueva tecnologa.

Build Engineer / Ingeniero de construccin

* Responsable de preparar, mantener y correr el proceso de construccin. * Realiza el mantenimiento de las versiones y la publicacin de la documentacin.

 Toolsmith / Herramentista
* Rol para la construccin de herramientas especficas para el desarrollo, conversin de datos y testeo. * Puede trabajar en la preparacin y mantenimiento tanto de bases de datos o sitios web destinados al proyecto.

System Administrator / Administrador del sistema

* Configura, administra y repara los servidores, estaciones de trabajo y equipos de desarrollo y testeo utilizados por el equipo.

Additional roles / Roles adicionales

Tester
* Verifica que el sistema recin creado cumpla con los requerimientos del cliente. * Puede llegar a ser una persona independiente del equipo del proyecto.

Deployer
* Es el encargado de convertir la informacin existente requerida por el nuevo sistema. * Participa en el lanzamiento de los nuevos productos.

Technical Writer / Escritores de documentos tecnicos

* Prepara la documentacin para los usuarios, que pueden formar parte o no del equipo del proyecto.

Ejemplo de FDD
Software para una Entidad Financiera

Planteamiento General del Problema

Una entidad Financiera requiere un sistema para el manejo de las cuentas, los clientes y de las transacciones de estos, las cuales usualmente se hacen personalmente en alguna de las sucursales del banco, no obstante algunas de ellas como por ejemplo las consultas de saldo, o las consignaciones de una cuenta a otra se pueden realizar a travs de la pgina Web de la entidad, la cual debe estar habilitada para los clientes.

Desarrollo de un modelo global

Partimos del hecho de conocer completamente la visin, el contexto y los requerimientos del sistema a desarrollar
Visin:
Manejo de las transacciones y de su interaccin con la base de datos de las cuentas de los clientes y el sistema de contabilidad.

Contexto:
Elaboraremos un diagrama de contexto que ilustre el marco del sistema.

Personal del banco

Clientes

Sistema de manejo de transacciones

Sistema de contabilidad del banco

Base de datos de cuentas

Desarrollo del modelo global

Requerimientos: El sistema debe permitir la realizacin de transacciones (consulta de saldo, consignaciones de una cuenta a otra) a travs de la pgina Web de la entidad. La base de datos actual es muy estable, por lo cual el sistema debe trabajar con ella. El sistema de contabilidad tambin debe permanecer, tal como esta en la actualidad, ya que es muy eficiente. El sistema debe ser seguro, es decir, debe detectar posibles fraudes a travs de la red, mediante accesos indebidos.

Desarrollo del modelo global

Lo ms importante, el sistema debe almacenar correctamente los cambios en la base de datos de las cuentas producto de las transacciones, actualizando tanto la base de datos como el sistema de contabilidad al momento de su realizacin. Las interfaces de usuario para el personal del banco, deben ser clara y permitir la realizacin de las labores tpicas:
Pagos Consignaciones Retiros Consulta del estado de cuenta .

Cliente -Identificacion : Double = 0.0 +ObtenerDatos() : void

-Realizador -Operacion * 1

Transaccin +Tipo : String = null

* +() -End1 * * -End3 -End4

Cuenta -Numero : Integer = 0 +ObtenerSaldo() : Integer

SistemaContabilidad

-End2

Elaboracin de una lista de funcionalidades

Es lo que a el banco le interesa que el sistema realice. Pgina Web. Actualizacin de la base de datos. Actualizacin del sistema de contabilidad Buenas interfaces de usuario (pagos, retiros, depsitos, consultas de saldo, actualizacin de datos). Sistema de seguridad del sistema. Manejo adecuado de las transacciones y consulta en interaccin con la base de datos y el sistema de contabilidad.

 Ahora, agrupamos las funcionalidades segn su afinidad y dependencia, as:

1.) Pgina Web dinmica e interactiva, en comunicacin con la base de datos y el sistema de contabilidad. 2.) Sistema de consultas y transacciones y la correspondiente actualizacin de la base de datos y del sistema de contabilidad. 3.) Interfaces de usuario, para todas las consultas y las transacciones y su correspondiente integracin al sistema. 4.) Sistema de seguridad, que incluya las restricciones del sistema y proteccin contra accesos indebidos y su integracin al sistema.

Planificacin por funcionalidad (1/2)

Se han ordenado los grupos de funcionalidades, segn su prioridad y la dependencia y a cada una de ellas se le asign un responsable:
_ Grupo 2: _ Grupo 3: _ Grupo 4: _ Grupo 5: Sarah. Hernn. Juan Pablo. Cristian.

Planificacin por Funcionalidad(2/2)

Cronograma:
La construccin de cada grupo de funcionalidades dura, mximo 2 semanas, y al final de este perodo se realizar una exposicin del avance del sistema al cliente. En total, la construccin del sistema dura 8 semanas y dos ms de prueba e implementacin el la entidad financiera.

Finalmente, las dos ultimas fases: Diseo y construccin por funcionalidades

Estas dos fases, implican un proceso iterativo, que comienza con el diseo y termina con la prueba de el funcionamiento de la funcionalidad implementada, pasando por la codificacin, su evaluacin y la integracin al sistema.

 El proceso se desarrolla, segn el orden definido en la fase de planificacin. Al finalizar las dos semanas dispuestas para cada grupo de funcionalidades, se muestra su implementacin al cliente, para verificar su aprobacin, si esto ocurre se procede con el siguiente grupo de funcionalidades, de lo contrario se inicia nuevamente el proceso iterativo introduciendo los cambios que el cliente especifico.

 Al finalizar la 8 semanas destinadas, se hace entrega del sistema y de la documentacin correspondiente que se ha ido recolectando en todas las fases del proceso, que incluye notas importantes sobre el sistema, descripcin de los errores y un manual de funcionamiento.

 Ayuda al equipo a producir resultados peridicos y tangibles.

Esta metodologa utiliza pequeos bloques llamados features, los cuales contienen la funcionalidad del sistema.

Organiza los bloques que estn relacionados entre s, en una lista llamada feature set. Hace nfasis en la obtencin de resultados cada dos semanas. 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.