Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
3 views15 pages

Feature - Driven Development Rep.

Ninguna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views15 pages

Feature - Driven Development Rep.

Ninguna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

Feature -Driven Development

DEFINICION:
El desarrollo basado en funciones (FDD por sus siglas en inglés) es una
metodología de desarrollo de software centrada en el cliente conocido por
iteraciones cortas y lanzamientos frecuentes.
Al igual que Scrum, FDD requiere que el cliente, también conocido como
propietario del negocio del proyecto, asista a la reunión de diseño inicial y
las retrospectivas de iteración.

Al lanzar nuevas funciones de forma incremental, los desarrolladores


pueden priorizar las solicitudes de los clientes, responder a las solicitudes
de manera oportuna y mantener a los clientes satisfechos. Para lograr esto,
los desarrolladores planifican qué características son capaces de crear,
dividen las solicitudes complejas en una serie de conjuntos de
características más pequeños y luego crean un plan sobre cómo completar
cada objetivo con el tiempo.
• El desarrollo basado en características consta de cinco pasos
claves, sin embargo hemos agregado la recopilación de datos
como un paso adicional, teniendo en cuenta la importancia de
esta tarea. Todos estos pasos te los detallamos a continuación.
• CARACTERISTICAS:
 Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.

 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 resultados periódicos y
tangibles.

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

 Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.

 No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases
de diseño y construcción.
Roles
• Gerente de proyecto – el jefe administrativo del proyecto,
• Programador jefe – el programador senior que lidera el equipo de
programadores,
• Arquitecto jefe – responsable del diseño general del proyecto,
• Gerente de desarrollo: maneja un equipo de desarrolladores y coordina
con el arquitecto jefe y el programador jefe,
• Propietarios de clases: los diseñadores y codificadores individuales que
trabajan en las subtareas asignadas,
• Expertos en dominios: los expertos del dominio de la función, como
usuario o cliente.
Pasos
Usado típicamente en proyectos de desarrollo a gran escala, existen
seis pasos o actividades básicas durante la FDD:

Recopilación de Datos
Desarrollar modelo general
Crear lista de funciones
Plan por característica
Diseño por característica
Construir por característica
• Recopilación de datos: Al igual que con todas las metodologías
ágiles, el primer paso en FDD es obtener una comprensión
precisa del contenido y el contexto del proyecto, y desarrollar
una comprensión clara y compartida del público objetivo y sus
necesidades. Durante este tiempo, los equipos deben apuntar a
aprender todo lo que puedan sobre el por qué, el qué y para
quién sobre el proyecto que van a comenzar. Esta recopilación de
datos puede considerarse como la etapa 0, pero no se puede
omitir. Comparar el desarrollo de productos con la redacción de
un trabajo de investigación: este es el paso de investigación y
desarrollo de tesis.
• Desarrollar y modelo general: Continuando con la metáfora
del trabajo de investigación, esta etapa es cuando se redacta el
bosquejo. Utilizando la "tesis" (también conocida como objetivo
principal) como guía, el equipo desarrollará modelos de dominio
detallados, que luego se fusionarán en un modelo general que
actúa como un esquema general del sistema. A medida que se
desarrolle y el equipo aprenda, se agregarán detalles.
• Crear una lista de características: Usa la información reunida
en el primer paso para crear una lista de las características
requeridas. Recuerda, una característica es una salida valorada
por el cliente. Has una lista de características (que se puede
completar en dos semanas) y ten en cuenta que estas
características deben ser propósitos u objetivos más pequeños,
en lugar de tareas
Plan por característica: Analiza la complejidad de cada característica y
planifica las tareas relacionadas con los miembros del equipo. Durante la
etapa de planificación, todos los miembros del equipo deben participar en la
evaluación de las características teniendo en cuenta la perspectiva de cada
etapa de desarrollo. Luego, utiliza la evaluación de la complejidad para
determinar el orden en que se implementará cada característica, así como
los miembros del equipo que se asignarán a cada conjunto de
características.
Esta etapa también debes identificar a los propietarios de las clases, los
desarrolladores individuales asignados a las clases. Debido a que cada clase
de la característica de desarrollo pertenece a un desarrollador específico,
alguien es responsable de los principios conceptuales de esa clase, y si se
requieren cambios en varias clases, entonces es necesaria la colaboración
entre los propietarios de cada una para implementarlas.
Y aunque los propietarios de clase son importantes para FDD, también lo
son los equipos de características. En los equipos de características, se
definen roles específicos y se alienta una variedad de puntos de vista. Esto
asegura que las decisiones de diseño consideren múltiples pensamientos y
perspectivas.
• Diseño por característica: Un programador jefe
determinará la característica que se diseñará y creará.
Asimismo, determinará los propietarios de las clases y
los equipos de funciones involucrados, mientras define
las prioridades de las funciones. Parte del grupo podría
estar trabajando en diseño técnico, mientras que otros
trabajan en el marco. Al final de la etapa de diseño,
todo el equipo completa una revisión de diseño antes
de seguir adelante.
• Construir por característica: Este paso implementa
todos los elementos necesarios que respaldarán el
diseño. Aquí, se construyen interfaces de usuario, al
igual que los componentes detallados en el diseño
técnico, y se crea un prototipo de función. La unidad se
prueba, inspecciona y aprueba, luego la característica
completa puede promoverse a la construcción principal.
Cualquier característica que requiera más tiempo que
dos semanas para diseñar y construir se divide en
características hasta que cumpla con la regla de las dos
semanas.
• Ventajas:
• El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando
soluciones innecesariamente generales y complejas que en realidad no son un
requisito del cliente.
• Cada componente del producto final ha sido probado y satisface los
requerimientos.
• Rápida respuesta a cambios de requisitos a lo largo del desarrollo.
• Entrega continua y en plazos cortos de software funcional.
• Trabajo conjunto entre el cliente y el equipo de desarrollo.
• Minimiza los costos frente a cambios.
• Importancia de la simplicidad, al eliminar el trabajo innecesario.
• Atención continua a la excelencia técnica y al buen diseño.
• Mejora continua de los procesos y el equipo de desarrollo.
• Evita malentendidos de requerimientos entre el cliente y el equipo.
• Desventajas:
• Falta de documentación del diseño. El código no puede tomarse como
una documentación. En sistemas de tamaño grande se necesitar leer los
cientos o miles de páginas del listado de código fuente.
• Problemas derivados de la comunicación oral. Este tipo de comunicación
resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas
ambigüedades.
• Fuerte dependencia de las personas. Como se evita en lo posible la
documentación y los diseños convencionales, los proyectos ágiles
dependen críticamente de las personas.
• Falta de reusabilidad. La falta de documentación hacen difícil que pueda
reutilizarse el código ágil.
• Importancia de la FDD:

• En primer lugar, el desarrollo basado en características es un proceso


compacto y sencillo que proporciona el alcance de la revisión y
corrección.
• Mantiene los estándares de desarrollo predeterminados que aceleran
el proyecto
• La gestión de productos se mejora a través de la participación
individual en la planificación y ejecución en áreas específicas.
• El desarrollo basado en características es menos complejo, ya que
funciona en tareas y subtareas que están orientadas a características,
y no necesitará más de dos semanas para realizarlas.
• El enfoque de desarrollo basado en características ayuda a reconocer
las necesidades del usuario de manera más efectiva.
Ayuda a ajustar los errores y mejorar el producto.
• Cuando Usarla:
Toda metodología debe ser adaptada al contexto del proyecto (recursos
técnicos y humanos, tiempo de desarrollo, tipo de sistema).
Exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en
proyectos pequeños y con requisitos muy cambiantes.
Las metodologías ágiles ofrecen una solución casi adecuada para una
gran cantidad de proyectos.

You might also like