FUNDAMENTOS DE

INGENIERIA DE SOFTWARE
1.3.3 Otras filosofías
TECNOLÓGICO NACIONAL DE MÉXICO – CAMPUS
VERACRUZ / ITVER

FUNDAMENTOS DE INGENIERIA DE SOFTWARE

I.S.C JULIA GUADALUPE TRUJILLO SALAMANCA

UNIDAD 1 - TEMA 1.3.3 – OTRAS FILOSOFÍAS

EQUIPO 4
CÁRDENAS MORTERA DERIAN ALEXIS
CÓRDOVA VÁSQUEZ KARLA MARIANA
NARANJO PAREDES IRVING JOSUÉ
GUILLÉN ROSAS ANTONIO DANIEL

5° SEMESTRE
Contenido
DESARROLLO DE SOFTWARE LEAN ...................................................................................... 4
SIETE PRINCIPIOS DEL DESARROLLO DE SOFTWARE AJUSTADO.......................... 4
LEAN VERSUS ÁGIL .................................................................................................................. 7
LAS VENTAJAS DE SER ESBELTO ........................................................................................ 7
OBJETIVOS DE LA METODOLOGÍA LEAN ........................................................................ 7
VENTAJAS DE LA METODOLOGÍA LEAN .......................................................................... 8
PASOS PARA APLICAR EL LEAN MANAGEMENT A LOS PROCESOS DE TU
NEGOCIO ..................................................................................................................................... 9
DYNAMIC SYSTEMS DEVELOPMENT METHOD DSDM ................................................... 12
DSDM Y EL CONSORCIO DSDM: ORÍGENES ................................................................... 12
PRINCIPIOS Y VALORES ....................................................................................................... 12
ORGANIZACIÓN Y ROLES .................................................................................................... 14
FASES Y ETAPAS ...................................................................................................................... 15
VENTAJAS DEL DSDM ............................................................................................................ 16
DESVENTAJAS DEL DSDM .................................................................................................... 17
FEATURE DRIVEN DEVELOPMENT (FDD) ........................................................................... 18
DEFINICIÓN .............................................................................................................................. 18
HISTORIA ................................................................................................................................... 18
ROLES Y RESPONSABILIDADES ......................................................................................... 19
Gerente de Proyecto / Mánager: ............................................................................................ 19
Jefe de Arquitectura: .............................................................................................................. 19
Gerente de Desarrollo: ............................................................................................................ 19
Programador jefe: ................................................................................................................... 19
Propietarios de clases: ............................................................................................................. 20
Expertos en dominios: ............................................................................................................. 20
ROLES DE APOYO: .............................................................................................................. 20
PRÁCTICAS DEL FDD ............................................................................................................. 20
1. Modelado de objetos de dominio: ...................................................................................... 21
2. Desarrollo por característica:............................................................................................. 23
3. Propiedad de clase individual: ........................................................................................... 23
4. Equipo de funciones: ........................................................................................................... 23
5. Inspecciones: ........................................................................................................................ 24
 6. Gestión de la configuración: ............................................................................................... 24
7. Construcción regular .......................................................................................................... 24
8. Visibilidad: ........................................................................................................................... 24
1. Desarrolle un modelo general: ........................................................................................... 25
2. Cree una lista de funciones:................................................................................................ 25
3. Planificar por función: ........................................................................................................ 26
4. Diseño por función: ............................................................................................................. 27
5. Construir por característica:.............................................................................................. 27
VENTAJAS Y DESVENTAJAS ................................................................................................ 28
Ventajas .................................................................................................................................... 28
Desventajas .............................................................................................................................. 28
REFERENCIAS BIBLIOGRAFICAS .......................................................................................... 30
 DESARROLLO DE SOFTWARE LEAN

El desarrollo de software Lean es un concepto que enfatiza la optimización de la eficiencia y

la minimización del desperdicio en el desarrollo de software. Este enfoque tiene sus raíces
en el movimiento de manufactura esbelta de la década de 1980, pero ahora se considera una
parte integral de la metodología de desarrollo de software ágil .

La filosofía de gestión de procesos Lean surgió del sistema de producción de Toyota; este
consistía en hacer más eficientes algunos procesos de la industria mediante la eliminación de
desperdicios o actividades que no aportaban beneficios. Esto para obtener resultados más
veloces en la productividad, competitividad y rentabilidad de las compañías sin la necesidad
de requerir otras fuentes como la contratación de personal extra o la compra más de
maquinaria, sino aprovechando los recursos actuales de la empresa.
Esta filosofía fue tomada por Tom y Mary Poppendieck y adaptaron los principios Lean al
desarrollo de software y lo llamaron LSD (Lean software development), el cual fue el que
inspiró a los métodos de desarrollo ágil conocidos actualmente.

SIETE PRINCIPIOS DEL DESARROLLO DE SOFTWARE

AJUSTADO
Los principios Lean se centran en la idea de que menos es más, y su objetivo es optimizar
cada parte del ciclo de vida del desarrollo de software.

4
El concepto es que se pueden aplicar eficiencias y gestionar los residuos en todos los niveles:
cada individuo, cada departamento, operaciones interdepartamentales, la organización en su
conjunto y las relaciones de la organización con los clientes y proveedores.
Cuando se trata de desperdicio, la filosofía lean tiene una definición muy amplia que incluye
todo lo que no agrega valor al producto. Un equipo de desarrollo de productos esbeltos debe
centrarse en el aprendizaje y, debido a la fuerte demanda de aplicaciones de software en la
actualidad, debe decidir las características lo más tarde posible para eliminar la necesidad de
rehacer el trabajo a medida que cambia el mercado. Al mismo tiempo, existe la misma presión
para entregar lo más rápido posible.
El lean software development se rige bajo 7 principios fundamentales, que al aplicarse
correctamente en el desarrollo de software dan como resultado sistemas más eficientes y
productivos para los clientes.
A continuación, describiremos los 7 principios del LSD:
1. Eliminación de desperdicios. Tan sencillo como evitar o suprimir todo aquello que
no le aporte valor al proyecto, en este caso el desarrollador debe tener la habilidad de
reconocer que procesos son innecesarios, es decir aquellos que al no aplicarlos pueden
dar los mismos resultados, tales como códigos, retrasos, requisitos poco claros,
cambios constantes y procesos mal desarrollados. Una forma de identificar fácilmente
los desperdicios es mediante la aplicación de un mapa de flujo de valor.
2. Ampliar el aprendizaje. En este caso la idea es que el producto se vaya probando
constantemente para evitar amontonar errores que al final serán más complicados de
resolver, y que darán como resultado demoras en la entrega del proyecto. Otra manera
de aumentar el aprendizaje es mediante la integración del cliente en el proceso de
desarrollo, de esta manera se podrán evitar agregar funciones que este no desee.
3. Decidir lo más tarde posible. Aunque parezca contraproducente decir que se deben
tomar decisiones lo más tarde posible, a la hora de desarrollar se debe esperar a estar
completamente informado sobre el cliente. La persona que va a desarrollar el software
debe tener claro el user story, para esto el cliente debe proporcionar la mayor cantidad
de información acerca del proyecto, sus dificultades y como quiere solucionarlas,
para de esta manera poder proceder al desarrollo.
4. Entregar tan rápido como sea posible. Inmediatamente después de recibir la
información sobre el cliente, se debe iniciar labores y procurar entregar la primera
iteración lo más pronto posible, para así poder agregar recomendaciones a las
siguientes iteraciones y entregar un producto de calidad en el menor tiempo posible,
algo realmente valorado por los clientes.
5. Potenciar el equipo. Se debe fortalecer el equipo de trabajo que se encarga del
desarrollo, esto se hace mediante la integración de todo el equipo en cada actividad
del proyecto, a través de la motivación constante hacia ellos en pro del proyecto y por
medio de una buena relación y comunicación, tanto con el cliente como con los
mismos integrantes del equipo.

5
 6. Crear la integridad. Es ideal que el software sea probado tanto en su estructura como
en su usabilidad, generalmente un software tiene varias ventanas o entradas que tienen
funciones diferentes, y por ello se debe asegurar que exista una integridad en estos
componentes del software, es decir, que funcionen igual de bien en conjunto y de
manera separada.
7. Visualizar todo el conjunto. En este punto se debe analizar la interacción que tiene el
software con los otros sistemas de la empresa, esta acción da la posibilidad de
examinar futuras mejoras que impacten en la calidad del proyecto y en la satisfacción
del cliente.

Los últimos tres principios lean tienen mucho en común con el pensamiento ágil. La idea de
que el equipo marca el ritmo (o, en términos ágiles, el sprint) y es responsable de entregar el
producto prometido está directamente en línea con lo que practican los equipos ágiles. Y la
frase ver el todo trae a la mente la retrospectiva ágil donde el equipo se reúne al final para
discutir los éxitos y desafíos que vio.
Los 7 principios anteriores son una especie de paso a paso que facilitan el trabajo de
desarrollo y que al seguirlos dan como resultado software más eficaces, rápidos y
satisfactorios para los clientes. Esto a su vez tiene algunas ventajas para las compañías, aquí
presentamos algunas de las ventajas más sobresalientes de la implementación de esta
metodología en las empresas.
• La eliminación de desperdicios permite obtener un software más básico e intuitivo,
en donde solo existen las funcionalidades necesarias, lo que significa un ahorro en
tiempo y dinero en capacitación al personal de la empresa en el manejo del software.
• Otra ventaja de esta metodología es que la entrega en un corto periodo de tiempo
posibilita la mejora e implementación de otras funcionalidades dentro del software,
acción que permite obtener un software más completo y totalmente probado.
• La participación activa del cliente dentro del desarrollo del software garantiza una
máxima satisfacción por parte del mismo, lo que implica también una gran

6
 probabilidad de éxito en la implementación del sistema dentro de la compañía, ya que
el cliente alcanzó a conocer a cabalidad su funcionamiento.
• Se recibe un software más seguro, con menos errores, el cual aprovecha al máximo
el uso de los recursos.
Es importante destacar que la implementación de esta metodología a la hora de desarrollar
software, es la mejor opción para aquellas empresas que quieren ser partícipes de la
construcción de su sistema, que quieren recibirlo en un corto periodo de tiempo y que buscan
simplicidad en sus funcionalidades. Al finalizar el proyecto el cliente va a recibir un software
productivo y eficiente, más seguro y optimizado a sus necesidades específicas.

LEAN VERSUS ÁGIL

Debido a que lean y Agile comparten tantos principios en común, algunos argumentan que
no es una situación de lo uno o lo otro: lean y Agile funcionan de la mano de manera tan
fluida que a menudo no se pueden distinguir.
Pero una nueva línea de pensamiento sugiere diferencias sutiles pero importantes entre los
dos procesos. Por ejemplo, un equipo esbelto es una herramienta que se puede utilizar para
perfeccionar o perfeccionar exactamente lo que debería ser el producto, mientras que un
equipo ágil construye el producto.

LAS VENTAJAS DE SER ESBELTO

En un momento en que la demanda de software está aumentando y las empresas no pueden
entregar aplicaciones con la suficiente rapidez, es fácil ver por qué el enfoque de menos es
más esbelto sigue siendo popular.
Lean también incluye una pieza fundamental de lo que muchos llaman desarrollo de
aplicaciones modernas: un enfoque en la comunicación regular con los clientes. Esta es una
mejora continua en todas las partes de la operación, y las reglas tienen un tenor optimista y
positivo.

OBJETIVOS DE LA METODOLOGÍA LEAN

La metodología Lean se basa en una serie de objetivos básicos que permiten alcanzar la
eficacia:
• Excluir actividades que no agregan valor al producto o servicio.
• Mejorar de forma continua para mantener la calidad del producto o servicio.
• Detectar problemas en origen y solucionarlos.
• Cambiar el enfoque de la empresa para aportar soluciones a los clientes, y no solo
venderles productos o servicios.
Por lo tanto, la metodología Lean requiere un cambio estratégico, es decir, una nueva forma
de enfocar el negocio para agilizar todos los procesos.
En un entorno de negocios cada vez más competitivo y complejo, los ejecutivos
empresariales requieren métodos innovadores. Se ha comprobado que, manteniendo la

7
administración de procesos industriales en su antiguo status quo, se pierde terreno en el
mercado.
En la actualidad, gracias a las tecnologías de la comunicación, implantar un sistema de
gestión que provoque un cambio en toda la cultura empresarial se torna más sencillo. Cuanto
mejor es la información, mayor es la eficacia que se consigue.

VENTAJAS DE LA METODOLOGÍA LEAN

Las ventajas que se derivan de tener un equipo muy solido son entonces evidentes y muy
útiles en el mundo del desarrollo de software. Dispones de unos programadores que son
capaces de analizar la situación, tomar decisiones correctas y llevarlas a cabo a una velocidad
fuera de lo normal. Puedes comenzar a desarrollar teniendo una vaga idea de cual es el
objetivo final del proyecto e ir variando el rumbo a la vez que se programa, posponiendo las
decisiones importantes lo más posible a medida que se va disponiendo de datos estadísticos
sobre la aceptación del producto que estás desarrollando. Si ves que tu idea se aleja de lo que
esperan los usuarios, simplemente gira el timón hacia el nuevo rumbo que crees que hay que
tomar y tu equipo se encargará de reaccionar y responder para satisfacer esas necesidades.

Es un método de desarrollo ágil fantástico para proyectos a medio plazo: se concibe una idea,
se programa y se lanza un prototipo que se ofrecen a un conjunto de personas para que lo
prueben y poder analizar su comportamiento. Una vez analizado, se toman decisiones, se
varía el rumbo, se desarrolla rápidamente y se repite el análisis con un nuevo prototipo.
Después de una serie de iteraciones, dispondrás de un producto muy definido y que ha sido
diseñado específicamente para cumplir el objetivo con el que fue concebido en función de
las opiniones de los propios clientes finales.
En este proceso pueden ocurrir dos cosas:
• Sabes que tu producto final funciona como a los usuarios les gustaría porque ya has
probado su comportamiento y operado los cambios oportunos en el propio proceso
de desarrollo. Dispones de un producto de software terminado y vendible que sabes
que gusta a tu público.
• Te has dado cuenta de que tu idea nunca funcionará porque has comprobado que no
tiene buena aceptación entre los usuarios y decides abandonar el proyecto. En este
caso has ahorrado dinero porque has podido abandonar el proyecto en menos tiempo
que si hubieras seguido una metodología de desarrollo tradicional, que necesita llegar
hasta el final del proceso para comprobar la efectividad del producto. Además, habrás
mejorado el compromiso del equipo y mejorado su aprendizaje, acercándote un poco
más al equipo ideal que promulga la filosofía Lean.
Lean va mas allá de ser solamente un conjunto de técnicas, hoy por hoy es una filosofía de
gestión empresarial por sí misma que se ha extendido por el mundo de las compañías
dedicadas a las TIC gracias al libro Lean Startup, escrito por Eric Ries.

8
PASOS PARA APLICAR EL LEAN MANAGEMENT A LOS
PROCESOS DE TU NEGOCIO
La teoría es sencilla, pero la clave está en aplicar correctamente la metodología Lean a tu
negocio en el día a día. Los pasos que puedes seguir son los siguientes:
1. Analiza los procesos de tu empresa
Lo primero que vas a tener que hacer es analizar qué procesos se realizan en cada
departamento de tu empresa para ver qué pasos le siguen y qué se puede mejorar en cada uno
de ellos. Por ejemplo, cuando llega una factura de un proveedor, ¿qué pasos se siguen para
procesarla y pagarla?
El análisis de los procesos empresariales se puede dividir en:
• Estratégico: consiste en identificar los recursos necesarios a largo plazo para cumplir
con los objetivos de competitividad requeridos.
• Táctico: responde a un proceso metodológico que persigue comparar las distintas
alternativas hasta seleccionar la más adecuada. El horizonte de previsión en este caso
es a medio y corto plazo.
• Operativo: se basa en la utilización eficiente de los recursos. Requiere un estudio
detallado de todas las operaciones que se llevan a cabo en el día a día (en términos de
semanas, días y horas empleadas).
2. Elabora la planificación
Cualquier proyecto necesita una definición inicial, es decir, un diagnóstico. Lo mismo ocurre
con la implantación de la metodología Lean, y eso es exactamente lo que hemos hecho en el
primer paso.
A continuación, una vez que sepas cuáles son los procesos que se pueden mejorar en tu
empresa, es el momento de establecer tres cosas:
#1 Los objetivos que quieres alcanzar: deben ser concretos (por ejemplo, aumentar la
productividad un 10% en 3 meses), ambiciosos (pero alcanzables) y medibles (para poder
cotejar el resultado con el objetivo inicial).
#2 Los recursos que vas a necesitar: se requiere una definición completa de los recursos
materiales y personales. ¿Cuántas personas se van a implicar en la aplicación de la
metodología?, ¿qué tecnología necesitas? El ERP o la RPA (automatización robótica de
procesos) pueden ser grandes aliados para la implantación.

9
#3 Los plazos que se deben cumplir: para lograr el objetivo final tendrás que establecer metas.
Los procesos operativos deben estar previstos para el corto plazo, mientras que la
planificación estratégica deberá basarse en un horizonte temporal más dilatado.
3. Involucra a tu equipo, clientes y proveedores
¿Has preguntado a los distintos miembros de tu equipo qué se podría hacer para mejorar sus
procesos? ¿Y a tus clientes y proveedores? Sus respuestas te darán información muy valiosa.
Por ejemplo, ¿es posible recibir el material sobre pedido para ahorrar costes de almacenaje?
En este caso se trata de una mejora en el proceso que requiere la colaboración de nuestros
proveedores. A través de un sistema de comunicación eficaz se podrán acortar los tiempos
de espera para la recepción del material y podremos llegar al objetivo de stock cero.
Otro ejemplo sería contar con información de los clientes, a través de una escucha activa,
para ofrecer un producto adaptado a sus necesidades (como se ha dicho anteriormente,
mejorar los sistemas de información es la base de implantación del Lean management).
Sea como fuere, es necesario estar conectado con todos los agentes que tienen alguna
participación en el desarrollo del negocio.
4. Comienza por lo sencillo
Antes de aplicar la metodología Lean a procesos complejos, comienza por uno que sea
sencillo y ve progresando poco a poco. Sin prisa pero sin pausa.
Para evitar estrés en su implantación, la evolución de los procesos y la gestión operativa
podrán pasar por diversas fases:

• Fase incipiente: comienzan las primeras pruebas sin que exista un procedimiento
estándar. El seguimiento de los procesos es clave para obtener datos.
• Fase de evolución: los procesos comienzan a estandarizarse, así como las normas y
responsabilidades asignadas a cada persona. La empresa va definiendo un cuadro de
mando para monitorizar las variables a optimizar. Comienza a establecerse una mayor
conexión entre todos los agentes internos y externos que intervienen en los procesos.
• Fase de madurez: se obtiene experiencia en la gestión de procesos. Se tiene formación
técnica adecuada y se cuentan con las herramientas digitales adecuadas que permitan
el desarrollo de la metodología Lean.
• Fase de integración: la empresa está totalmente gestionada dentro de la metodología
Lean. Todos sus sistemas permiten relacionarse y compartir información con sus
“partners” (tanto internos como externos)
5. Haz seguimiento
De nada sirve implantar una mejora en los procesos y no controlar lo que ocurre después. La
monitorización y el seguimiento deben ser continuos para detectar problemas y solucionarlos
con rapidez.
10
En este punto, la empresa también debe contar con herramientas y soluciones que le permitan
configurar y mejorar el cuadro de mando del control de procesos.
Básicamente, el seguimiento y control de procesos debe abarcar los siguientes puntos:
Indicadores de gestión: con los correspondientes objetivos que se quieren lograr (por
ejemplo, ratios de productividad, roturas y mermas, obsolescencia de productos, quejas,
devoluciones, plazos, etc.).
Costes: sistema de medición de contabilidad interna (contabilidad de gestión).
Indicadores de resultados: índices de crecimiento en ventas, clientes, participación en el
mercado, etc.

11
 DYNAMIC SYSTEMS DEVELOPMENT METHOD DSDM

El Dynamic Systems Development Method o en español el Método de Desarrollo de Sistemas

Dinámico es una metodología para el desarrollo de software que se apoya en estar siempre
interactuando con el usuario con el fin de tener una gran implicación de este. Lo cual hace
que sea un sistema sensible a los requisitos del usuario en cada momento, logrando adaptarse
mejor a las necesidades de la empresa.
El fin de este sistema es encontrar soluciones sencillas a tareas complejas, para así ser
entregado a tiempo, evitando los errores de fechas topes perdidas, excederse del presupuesto
y la falta de participación del usuario. Por lo que se enfoca en proyectos de Sistemas de
Información.

DSDM Y EL CONSORCIO DSDM: ORÍGENES

El consorcio DSDM fue fundado en 1994 por un conjunto de vendedores y expertos en el
sector de la Ingeniería de Software. Se creó con el objetivo de un "Desarrollo conjunto
promocionando un entorno de trabajo de desarrollo ágil", combinando las mejores
experiencias obtenidas en práctica.

PRINCIPIOS Y VALORES
Los métodos de desarrollo ágiles tienen una serie de valores como son dar más valor a los
individuos en lugar de a las herramientas, o valorar mejor un software que funciona bien en
lugar de una buena documentación. El método DSDM utiliza 9 principios para aplicar estos
valores.
1.- La obligación del usuario de implicarse.
Es considerado el más importante de los principios. Esto es debido a que la implicación del
usuario en el desarrollo reduce en gran parte el número de errores y, por consiguiente, el
dinero y tiempo utilizado para corregir los mismos. Por lo general, se trabaja con un pequeño
número de usuarios selectos, haciendo pequeñas revisiones periódicas. Estos usuarios se
mantendrán durante el desarrollo del Software consiguiendo así una imagen más fiel del
software deseado. La continuidad, por otra parte, es uno de los valores que se aplican en los
principios.
2.- Los equipos deben de tener el poder de tomar decisiones.
Para poder proceder de la manera más rápida posible y sin depender de otras personas, todos
deben de tener poder para tomar decisiones independientemente de los demás integrantes del
equipo. Requerir la autorización de otras personas para poder proceder a actuar según
decisiones tomadas ralentiza el proceso de creación del software, por ello, a todos los
trabajadores se les da permiso para tomar decisiones que afectan a: Requisitos en desarrollo.

12
Requisitos cuya funcionalidad se necesita en futuras interacciones. Priorización de requisitos
y características. Detalles técnicos.
3.- Realización de entregas tempranas.
Las entregas tempranas garantizan la detección rápida de errores para que sean corregidos y
revertidos rápidamente antes de que el coste de reparación sea demasiado elevado. Estas
entregas afectarán tanto al software como a la documentación que se entregará junto al
software terminado.
4.- Las entregas que se acepten han de ser adaptadas a la empresa.
El software que entreguemos ha de ser capaz de satisfacer las necesidades de la empresa. Por
lo general, la Refactorización, el diseño y la mejora de las funciones son tareas que en los
sistemas de modelado de software solo realizan una vez, al comienzo como es el diseño, o al
final como es la refactorización o mejora de las funciones. Sin embargo, el DSDM sostiene
que estas tareas han de formar parte del ciclo de vida del software y han de ser tareas que se
deben de repetir una vez con cada una de las entregas que la empresa haya aceptado para así
conseguir una mayor adaptación a la empresa y, como hemos dicho antes, que los errores no
se hagan mucho más grandes y su coste de reparación no se eleve demasiado. Por otra parte,
repitiendo estas fases una y otra vez se consigue una mucho mejor aproximación al software
que desea la empresa.
5.- El desarrollo es Iterativo e Incremental.
El desarrollo Iterativo e Incremental es el que mejor se adapta a todos los principios
anteriores, y además facilita la división de las tareas para una mejor y más fácil organización
del trabajo. En este desarrollo el software se va haciendo más grande con cada iteración hasta
conseguir con la última que el software se haya adaptado completamente a lo que la empresa
necesitaba. Este principio se basa en el concepto de que todo software está sujeto a cambios.
Por último, cuanto más pequeñas sean las iteraciones, más fácil será identificar y realizar los
cambios que hay que realizar.
6.- Todos los cambios que se hagan durante el desarrollo han de ser reversibles.
Como el propio título indica, cualquier cambio que nosotros realicemos debe de poder ser
revertido con facilidad y sin suponer excesivos costes. Esto es debido a que los principios
anteriores hacen que los cambios surjan continuamente y si no se tiene un control sobre ellos
puede que el tiempo que tardemos en realizarlos sea excesivo. Por ello todos los cambios que
se realicen han de ser escritos ideando que sean sencillos de eliminar o revertir. Es cierto que
este principio pueda hacer que realicemos trabajo para nada si nuestros cambios se revierten
al final, pero sin ello, los principios que sigue el método DSDM no sería aplicable dado que
generaría trabajo muy grande procedente de la continua comunicación con usuario y cliente.

13
7.- Los requisitos se describen en alto nivel y tendrán una línea base.
El DSDM hasta el momento propone que haya una gran libertad a la hora de cambiar los
requisitos. Para limitarlos se establecen una serie de requisitos en alto nivel al comenzar el
proyecto, formando una línea Base sobre la que desarrollar. Así se forma una idea del alcance
que deben tener los requisitos y nos aseguramos que los cambios no alteran demasiado la
funcionalidad del ECS.
8.-Las pruebas se integran a lo largo del ciclo de vida.
Por lo general, las pruebas es una de las últimas fases que forman proceso de ingeniería del
software, siendo estas las que se realizan después de la codificación. Sin embargo, el modelo
DSDM defiende que para conseguir una rápida corrección de los errores, las pruebas deben
integrarse dentro de las fases más tempranas de la elaboración y repetirse en múltiples
ocasiones durante el ciclo de vida del software.
9.- Enfoque cooperativo y colaborativo.
La programación cooperativa es comúnmente utilizada en métodos de desarrollo ágil. Estas
técnicas aceleran la resolución de problemas y la construcción de un software más eficiente
y con menos errores. La más común es la programación por parejas en la que, mientras una
de las dos personas codifica, la otra piensa y resuelve como realizar el algoritmo o la clase
que hay que escribir a continuación además de revisar y ayudar a su compañero y viceversa.

ORGANIZACIÓN Y ROLES
En todo equipo de modelado de software existen diferentes roles que adoptan los integrantes
del equipo. El DSDM identifica un total de 12 roles, aunque, estos son variantes según las
necesidades del equipo de desarrollo en función del software que se desarrolle:
• Patrocinador ejecutivo: Es el rol más alto que adopta la organización. Es la fuente que
proporciona fondos y recursos al proyecto. Es la posición más alta que toma
decisiones.
• Visionario: Es el que tiene la responsabilidad de iniciar el proyecto. El visionario es
el que proporciona las necesidades que tiene la empresa del software. El visionario
tiene también la tarea de supervisar que el proyecto se desarrolla correctamente.
• Usuario “embajador”: Proporciona al proyecto la información proveniente de la
comunidad de usuarios. Tiene la obligación de asegurar que los desarrolladores
reciben suficiente información de la comunidad de usuarios durante la fase de
desarrollo.
• Usuario “consejero”: Es cualquier usuario que proporcione al proyecto un buen punto
de vista de la aplicación.
• Jefe de Proyecto: Es la persona encargada de gestionar el proyecto en general.
• Coordinador Técnico: Es el responsable de organizar la arquitectura del proyecto y
controlar la calidad del software generado.

14
 • Líder de Equipo: Se asegura de que el equipo funciona correctamente.
• Desarrollador: Interpreta los requisitos de sistema y los modela y desarrolla el código.
• Probador “Tester”. Es el encargado de comprobar que el software funciona
correctamente, así como de generar la documentación.
• Escriba: Toma nota de todos los requisitos, acuerdos y cambios que se realizan.
• Facilitador: Es la persona que se encarga de controlar el progreso facilitar y potenciar
la comunicación y el desarrollo.
• Roles especiales: Business Architect, Quality Manager, System Integrator, etc.

FASES Y ETAPAS
El DSDM al ser un modelo de procesos de Ingeniería de software se divide fases y etapas
para así organizar de mejor manera las tareas que se llevaran a cabo en el desarrollo del
software. El modelo DMDS cuenta con tres etapas las cuales son El pre-proyecto, Ciclo de
vida del software, y Post-Proyecto.
1. El Pre-Proyecto. En esta fase se producen las sugerencias de proyectos candidatos,
entre las cuales se elige el más óptimo. Además, se realiza una estimación de los fondos
necesarios para desarrollar el proyecto y se decide si el proyecto se va a realizar o no.
2. El Ciclo de vida del Software. Su objetivo es construir el proyecto planteado en la fase
de Pre-Proyecto. Esta fase está subdividida en fases:
2.1. Estudio de Viabilidad y de Negocio. Los estudios que se plantean deben de ser lo
más cortos y esquemáticos posibles, pero con la información necesaria, dado que la
creación de un documento demasiado complejo atrasaría el proyecto, pero unos
buenos estudios ayudarán a enfocarlo mejor.
2.1.1. Estudio de Viabilidad. En esta fase se realizan reuniones para determinar
aquellas ideas que son de la gestión del proyecto. Los acuerdos que se toman
ayudan a direccionar el desarrollo del proyecto determinando sus costes, la
adaptación de este al modelo DSDM, los riesgos que existen, etc... y teniendo
como producto final un documento de Viabilidad.
2.1.2. Estudio de negocio. Es un documento que extiende al estudio de flexibilidad y
que se realiza cuando ya se decidió que el proyecto se puede desarrollar mediante
DSDM. En esta fase se intentarán definir características del proyecto, y las
necesidades que esperan los usuarios de él. Al final del estudio se determinará
una lista de requisitos, los cuales se priorizarán según su necesidad para el
desarrollo del resto de requisitos.
2.2. Iteración de Modelo Funcional (Functional Model Iteration). Se utilizan los
requisitos identificados en fases anteriores para transformarlos en Modelos
Funcionales. Para ello se crean prototipos funcionales de los requisitos que dan una
idea al usuario de cómo va a funcionar la aplicación y son revisados por diferentes
grupos de usuarios que valoran y certifican la calidad del prototipo.
2.3.Iteración de diseño y desarrollo (Design & Build Iteration). Su principal tarea es
transformar los Modelos funcionales para que satisfagan totalmente las necesidades
del usuario. Para ello, se crearán Prototipos de diseño, y nuevamente serán verificados
por los usuarios.

15
 2.4.Implementación. Los usuarios deberán verificar que los prototipos cumplen con lo
deseado para iniciar la implementación de los mismos, así como el entrenamiento de
los futuros usuarios para que sepan utilizar la aplicación.
3. El Post-Proyecto. Esta última fase se utiliza para comprobar que el funcionamiento del
producto se correcto y eficiente. Al igual que se realizan tareas de mantenimiento, y de
mejora del software si son requeridas. Por lo general esto sucede durante los 6 meses
siguientes a la entrega del proyecto al cliente.

VENTAJAS DEL DSDM

✓ Proporciona un proceso independiente de la técnica
✓ Flexible en términos de evolución de requisitos
✓ Cumplimiento estricto del tiempo y el presupuesto
✓ Incorpora a las partes interesadas en el proceso de desarrollo
✓ El énfasis en las pruebas es tan fuerte que se espera que haya al menos un evaluador
en cada equipo de proyecto.
✓ Diseñado desde cero por gente de negocios, por lo que el valor comercial se identifica
y se espera que sea el entregable de mayor prioridad.
✓ Tiene un enfoque específico para determinar la importancia de cada requisito para la
iteración.
✓ Establece las expectativas de las partes interesadas desde el inicio del proyecto de que
no todos los requisitos se convertirán en el producto final.

16
DESVENTAJAS DEL DSDM
• Implica el desarrollo progresivo de requisitos
• Centrarse en RAD puede provocar una disminución en la robustez del código
• Requiere un compromiso total con el proceso DSDM
• Requiere una participación significativa del usuario
• Requiere un equipo de desarrollo capacitado tanto en el área comercial como técnica
• Probablemente el proyecto más pesado comparado en esta encuesta.
• Espera la participación continua del usuario
• Define varios artefactos y productos de trabajo para cada fase del proyecto;
documentación más pesada.
• El acceso al material está controlado por un consorcio y se pueden cobrar tarifas solo
para acceder al material de referencia.

17
 FEATURE DRIVEN DEVELOPMENT (FDD)

DEFINICIÓN
Como su nombre lo indica, la función sería el aspecto más importante de este proceso. Las
prácticas que sigue este proceso pueden no ser nuevas. Sin embargo, su mezcla si lo es.
Además de lo anterior, este método encuentra solución a problemas importantes y
desafiantes.
A su vez, lo podemos definir con un entorno de trabajo ágil que se enfoca en las
características. Es un framework qu:
➢ Es breve e iterativo
➢ Enfatiza la calidad
➢ Su diseño es compatible con grandes empresas
➢ Ofrece características frecuentes en todas las iteraciones
➢ Proporciona información precisa durante el proceso
➢ Es famoso entre desarrolladores, empresas y clientes
Los valores de un marco son los valores que hacen que ese marco sea diferente de otros. Hay
algunos valores que son importantes y afectan todos los aspectos.
➢ En primer lugar, se centra en el proceso y no en los resultados.
➢ En segundo lugar, adopta un enfoque sistemático para mantener el sistema.
➢ En tercer lugar, simplifica el proceso.
➢ Además de lo anterior, los pasos del proceso deben ser valiosos para cada miembro
del equipo.
➢ Además, los procesos correctos pasan a un segundo plano.

HISTORIA
Historia del desarrollo impulsado por funciones (FDD):
Hay una historia detrás del desarrollo de FDD. En 1997, Jeff De Luca era el director de
proyecto de un banco en Singapur para un proyecto muy importante y de gran escala.
Mientras trabajaba en ese proyecto, Jeff se enfrascó en problemas excepcionalmente
complejos. A pesar de utilizar todas las técnicas disponibles, la pregunta se mantuvo como
está.
Finalmente, Jeff contrató a Coad, que era desarrollador. Como resultado, ambos idearon un
método que se denominó Desarrollo basado en funciones. Recibieron la ayuda de otros 50
programadores y entregaron 2000 funciones funcionales en 15 meses.
La primera publicación de este método ocurrió en 1999 en un libro llamado "Modelado Java
en color con UML".
Cualquier proyecto puede utilizar este método. En otras palabras, ese proyecto se divide en
múltiples funciones; cada característica se divide aún más hasta que sea lo más pequeña

18
posible. Además, esto se hace para asegurar que su entrega pueda ocurrir en 2-10 días.Suele
aplicarse a proyectos a gran escala.

ROLES Y RESPONSABILIDADES
Los integrantes del equipo de trabajo son la parte más crucial del desarrollo del sistema. A
continuación se presentan los 6 roles en el desarrollo del FDD.
Gerente de Proyecto / Mánager:
El Gerente de Proyecto es responsable de compartir informes de progreso con el cliente y
asegurarse de que el proyecto progrese según sea necesario. Además de esto, un director de
proyecto puede gestionar más de un proyecto. Las responsabilidades del gerente de proyecto
incluyen:
• En primer lugar, son los líderes administrativos del proyecto. Los gerentes de
proyecto son responsables de presupuestar, decidir el personal, crear y hacer circular
informes de progreso.
• En segundo lugar, mantiene al equipo enfocado en entregar funciones a tiempo
• Finalmente, son responsables de Operar el sistema del proyecto y el centro de control.
Jefe de Arquitectura:
Un arquitecto es quien diseña el sistema y el arquitecto jefe maneja un equipo de
arquitectos. En un proyecto a pequeña escala, también puede ser una persona.
• Los arquitectos jefes son responsables de las siguientes cosas:
• En primer lugar, son responsables del diseño general del sistema.
• En segundo lugar, son responsables de realizar talleres de diseño dentro del proceso.
Además, se aseguran de que todos los miembros del equipo comprendan el diseño.
• Además, guían el proyecto a través de dificultades técnicas.

Gerente de Desarrollo:
El Gerente de Desarrollo es quien maneja al equipo de desarrolladores y se asegura de que
terminen su trabajo a tiempo. Pueden manejar más de un proyecto o equipo a la vez. Un
gerente de desarrollo se encarga de las siguientes cosas:
• Primero, realiza un seguimiento de las actividades de desarrollo del día a día.
• En segundo lugar, se asegura de que no haya conflictos entre los miembros del
equipo.
• En tercer lugar, coordina con el arquitecto jefe y el gerente de proyectos y les
proporciona informes oportunos.
Programador jefe:
El programador jefe es uno de los programadores más experimentados. Es deber del
programador jefe ayudar en la programación y asegurarse de que vaya en la dirección

19
correcta. El programador jefe maneja un proyecto en particular a la vez. Responsabilidades
del programador jefe
• Es el desarrollador experimentado
• Lidera pequeños equipos de desarrolladores
• Tanto los desarrolladores como los gerentes respetan sus decisiones de desarrollo.
Propietarios de clases:
La clase es el conjunto más pequeño de desarrollo de funciones que se desarrolla en un
máximo de dos semanas.
Los propietarios de la clase son los desarrolladores que crean funciones. Además de esto,
reciben la orientación del programador jefe y envían informes de progreso al gerente de
desarrollo. Responsabilidades del propietario de clase:
• Son desarrolladores individuales
• Diseñe el proyecto y hágalo verificar una vez que se confirme el diseño.
• Además, también realizan pruebas iniciales y de codificación.
• Al final, documentan la característica.

Expertos en dominios:
El experto en el dominio puede ser cualquier persona que tenga el mejor conocimiento de ese
dominio en particular y pueda ayudar al equipo a comprenderlo. Por ejemplo, en la escuela,
tenemos diferentes profesores para diferentes materias, y ningún profesor puede enseñar
todas las materias. En ese caso, cada materia es un dominio y el profesor de la materia es un
experto en el dominio. Responsabilidades de expertos de dominio
• Pueden ser usuarios, clientes, patrocinadores
• Son la base de conocimientos de los desarrolladores
• Aparte de estos seis roles importantes, existen muchos roles de apoyo caso por caso.
ROLES DE APOYO:
• Administrador de dominio
• Administrador de versiones
• Gurú del lenguaje
• Ingeniero de construcción
• Herrero
• Administrador de sistema
• Probadores
• Desarrolladores
• Escritores técnicos

PRÁCTICAS DEL FDD

Para comprender las características, primero debemos comprender la función. El cliente
quiere que el equipo de desarrollo desarrolle un software. Los clientes desearían tener ciertas
20
características en el software, y esas características tendrán sus respectivas funcionalidades.
Estas caracteristicas se conocen como Funciones.

En Feature Driven Development (FDD), una función se puede desarrollar y entregar al cliente
en una o dos semanas, según el tamaño del equipo y la complejidad de la función.
Para hacerlo más claro, consideremos MS Office como el software que el cliente desea.
Ahora en la oficina de MS, el cliente desearía tener:
MS Word,
MS Excel,
PowerPoint
Estas son diferentes características del software. Una de las características que tendrá MS
Word son varias funcionalidades como insertar, cambiar el diseño, cambiar la vista. Etc.
Estas funcionalidades se dividen aún más como:
• Insertar una imagen
• Agregar una mesa
• Insertar una hoja
• Agrega algo de forma
• Inserta un clip art, etc.
Cualquier función que sea difícil de desarrollar y que no se pueda entregar en este breve lapso
(2 semanas) se divide en funciones más pequeñas. Este proceso continúa hasta que la función
no es lo suficientemente pequeña como para entregarse en un máximo de 2 semanas.
En resumen, dado que sabemos cuáles son las funciones y características, hablemos de las
prácticas que sigue a continuación. Las mejores prácticas son las siguientes:
1. Modelado de objetos de dominio:
En términos más simples, el modelado de objetos de dominio consiste en tomar un dominio
de problema y construir un diagrama de clases que muestre diferentes tipos de objetos y la
relación entre ellos. En otras palabras, el modelo de objetos de dominio proporciona un marco
general, que detalla cómo vamos a agregar funciones para cada característica.
Dado que ya discutimos las clases que vamos a usar, y también la interacción entre estas
clases, se vuelve fácil para los desarrolladores seguir esta estructura.
La mejor técnica para el modelado de objetos de dominio es modelar en color. Lo que, a su
vez, significa que diferentes colores representan diferentes clases. Además, su categorización
ocurre según los requisitos.
Peter Coad sugirió estos colores primero. Las clases se dividen en diferentes categorías y
cada clase tiene su color.

21
Rosa: Intervalo de tiempo: aquí, en esta categoría, está el tiempo asociado con un proceso
empresarial o un momento en el tiempo. En otras palabras, podemos decir que cualquier cosa
que tenga un intervalo de tiempo o un momento en el que ocurrió algún evento se incluye en
esta categoría. Por ejemplo, la orden de compra del automóvil se puede clasificar en rosa, ya
que tendrá la fecha y la hora en que se compró el vehículo. Por lo tanto, estos se convierten
en detalles de seguimiento.
Amarillo: Representa un rol activo - Un individuo o una organización puede jugar un rol.
Una persona puede desempeñar un papel único o múltiples roles. Por ejemplo, en un sitio
web de venta de automóviles, un cliente puede ser un comprador, un vendedor o un corredor.
Una persona está desempeñando múltiples roles.
Verde: lugar o cosa: en un sitio web de venta de automóviles como cardekho.com, el vehículo
se clasificará en color verde, ya que es una cosa. Además de eso, esta categoría reconoce
atributos como el número de registro, el número de serie, el número de licencia, el nombre
de la persona, etc. Este atributo tendrá los detalles del comprador y la parte vendedora, los
detalles del lugar o los detalles de las cosas.
Azul: Tipo de catálogo: en esta categoría, la mayoría de las descripciones de tipo catálogo
están allí. Este atributo tendrá la lista de todos los detalles de una fiesta o actividad en
particular. Por ejemplo, en un sitio web de venta de automóviles, si hay un automóvil a la
venta, se darán todas las descripciones de este automóvil. En otras palabras, se mencionarán
todas las características, el tipo de automóvil, la configuración del motor y todo y no solo el
automóvil.
Ejemplo de un centro de yoga, con su diagrama UML

22
2. Desarrollo por característica:
El desarrollo impulsado por características (FDD) se centra en las características. Este
método asegura la entrega rápida de la característica correcta al cliente. Además, se produce
la descomposición de una función significativa, cuya entrega y diseño no es posible terminar
en dos semanas. Ocurre hasta que esté disponible en un máximo de dos semanas.

Como resultado, un equipo de características sigue siendo pequeño porque el tamaño de la

característica es pequeño.
Cada miembro del equipo de funciones contribuye al diseño y desarrollo de una función. Este
equipo trabajará con un desarrollador experimentado. Como resultado, esto reduce el riesgo
y ayuda al propietario de la clase en el desarrollo.
Un propietario de clase puede ser miembro de varios equipos de funciones al mismo tiempo.
Los programadores jefes también son propietarios de clases y también forman parte del
equipo de funciones que está dirigido por algún otro miembro jefe. El propósito principal de
esto es ayudar a los propietarios de clases.

3. Propiedad de clase individual:

Después de la descomposición de la función en características pequeñas, ocurre la asignación
de una característica a un desarrollador. Además de la propiedad de funciones, también
tenemos propiedad de clase. Lo que, a su vez, significa que a cada desarrollador se le asigna
una clase y ese desarrollador será el propietario de la clase para esa clase en particular.
Además de eso, el desarrollador será el único responsable de la entrega total y el desempeño
de esa clase.
4. Equipo de funciones:
La implementación de características requiere el desarrollo de más de una clase. Dado que
cada clase tiene un propietario, el equipo de funciones se compone de todos estos
desarrolladores de clases. El propietario de la función es un líder que se supone que dirige a
estos propietarios de clases. Además de lo anterior, este equipo de funciones posee todas las

23
funcionalidades requeridas en esta función. Por lo tanto, reduce la dependencia de cualquier
otro equipo, y cada equipo de funciones es dueño de su función.
5. Inspecciones:
Después de desarrollar cualquier función, es muy importante comprobar la calidad. Se
realizan inspecciones para garantizar la calidad del diseño, el código y la función. Además
de eso, se asegura de que sea según las expectativas del cliente. La primera etapa del examen
es inmediatamente después del diseño, y si hay algún problema, se solucionará levantando
defectos.
6. Gestión de la configuración:
Gestión de la configuración significa mantener un registro de toda la configuración. Mantiene
un historial de una clase a medida que se desarrollan. Como resultado, ayudan a identificar
la última versión de los archivos de código fuente.
7. Construcción regular:
La construcción regular asegura un trabajo consistente y la implementación de las
características. Es necesario estar actualizado para que el cliente conozca los avances más
recientes, precisos y frecuentes a lo largo del proyecto. Además de lo anterior, asegura que
el equipo de desarrollo siempre tenga listo un sistema demostrable.
8. Visibilidad:
Los gerentes deben mantenerse en contacto con los clientes y mantener la visibilidad del
progreso del proyecto y sus resultados. Además, el gerente controla un proyecto al
proporcionar informes de progreso precisos y puntuales en cada etapa.

PROCESOS
Los procesos de desarrollo impulsado por características consisten en:
➢ En primer lugar, crear un modelo de objetos de dominio basado en el modelado de
objetos con sus expertos en el dominio.
➢ En segundo lugar, los desarrolladores utilizan la información del modelado de objetos
y otras actividades y luego crean una lista de funciones.
➢ En tercer lugar, se prepara un plan general basado en características y roles, y se
asignan responsabilidades.
➢ Además de lo anterior, se abordan las pequeñas características o características de la
característica, lo que sea que tarde menos de dos semanas.
➢ Finalmente, se realiza el diseño y la codificación de cada función. Es la fase de
construcción de esa característica.
Hay cinco procesos documentados en FDD /basados en el ETVX) como se muestra en la
siguiente figura:

24
1. Desarrolle un modelo general:
En este proceso, la creación de un modelo de objeto básico ocurre después de un recorrido
de alto nivel de los requisitos y el alcance.
➢ Criterios de entrada: expertos en el dominio, programadores en jefe, el arquitecto en
jefe seleccionado para trabajar.
➢ Tareas
o Formación del equipo de modelado: el arquitecto jefe decide quiénes
formarán parte del equipo. Por tanto, trabaja en el modelado de esa tarea. El
arquitecto jefe hace esto según los requisitos de la tarea y el conjunto de
habilidades respectivo.
o Recorrido del dominio: una vez que el equipo finaliza, el arquitecto jefe les
explica la tarea que debe ejecutar junto con los plazos.
o Desarrollo del modelo: el equipo comienza a trabajar en la creación de un
modelo, ya que tienen toda la información necesaria.
➢ Verificación: aquí, el desempeño de las evaluaciones ocurre dentro y fuera del equipo.
Estas evaluaciones incluyen pruebas y comentarios.
➢ Salida: Modelo de objeto desarrollado, lo que significa
o Diagrama de clases creado, lo que significa qué clases estarán bajo qué
dominio. Cómo se conectarán esas clases y bajo qué reglas y regulaciones.
o Los métodos a utilizar se resuelven y se colocan debajo de la clase
o Dibujar diagramas de secuencia (si es necesario).
o Consideración de formas y modelos alternativos y la razón detrás de la
selección de este modelo en particular. Se produce la creación de notas de
modelo.
2. Cree una lista de funciones:
En este proceso, la característica se descompone en secciones más pequeñas y se produce la
creación de la lista de características para la última parte.
➢ Entrada: experto en dominio, programador jefe, el arquitecto jefe seleccionado para
trabajar
➢ Tareas:
25
 o Cree los equipos de la lista de características que formarán un equipo de
programadores en jefe a partir del último proceso. Dividirán la funcionalidad
en funciones más pequeñas.
o Crea una lista de características y para eso
o El equipo divide el dominio en un conjunto de características importantes.
Después de eso, tiene lugar la división de esos conjuntos en pequeños
conjuntos de funciones.
o Cada paso de una actividad en particular es una característica.
➢ Verificación: se refiere a las evaluaciones realizadas dentro y fuera del equipo. Estas
evaluaciones incluyen pruebas y comentarios.
➢ Salida: Ocurre la creación de la lista de características, lo que significa
o Se establece una lista de áreas temáticas. El área temática es el conjunto de
características principales. Por ejemplo, si MS Office es software, entonces
MS Word, MS Excel, PowerPoint, etc. será el área temática. En otras palabras,
es como característica principal o característica principal.
o Para cada asignatura se realiza la creación de la lista de actividades que
requieren ejecución.
o Para cada evento, ocurre la definición de los pasos y ocurre la creación de una
lista de características.
3. Planificar por función:
La lista de funciones les dice a los desarrolladores qué funciones deben desarrollarse.
Después de la creación de la lista de funciones; el gerente de desarrollo creará el plan para
las funciones que necesitan mejorarse.
➢ Criterios de entrada: Lista de destacados creada. Ahora, el gerente de proyecto, el
gerente de desarrollo y los programadores en jefe decidirán el orden de las funciones
en las que se desarrollará.
➢ Tareas:
o Formación de un equipo de planificación para cada función.
o Finalizando la secuencia para el desarrollo
o Asignar actividades comerciales a los programadores jefes. Además de esto,
lo dividen aún más en clases.
o Asignar clases a desarrolladores
➢ Verificación: Se realiza una autoevaluación para verificar si las clases se han asignado
y funcionado correctamente.
➢ Salida: ocurre la creación del plan de desarrollo. Lo que, a su vez, significa
o Se realiza la asignación de fechas de finalización para las actividades
comerciales.
o Se lleva a cabo la asignación de las actividades comerciales a los
programadores jefes.
o Todas las clases tendrán asignado un desarrollador y también tendrán fechas
de finalización.

26
4. Diseño por función:
Planificación de un orden en el que ocurre la creación de las características en la última etapa.
En esta etapa, el arquitecto jefe creará un diseño para la característica del objeto.
➢ Criterios de entrada: se completa el proceso de planificación. Por lo tanto, ahora los
desarrolladores y el arquitecto jefe comienzan a diseñar y codificar cada
característica.
➢ Tareas:
o La creación del equipo de funciones ocurre
o Estudiar el documento de referencia y crear el recorrido del dominio.
o Se lleva a cabo la creación del diagrama de secuencia
o Refinando el modelo de objetos y las alternativas de diseño, si las hubiera
o Documentar la clase y los métodos usados
➢ Verificación: el arquitecto jefe inspecciona el diseño.
➢ Salir: el paquete de diseño exitoso está listo, lo que significa:
o En un papel o documento se informa a detalle sobre el diseño del paquete..
Además de eso, debe ser fácil de entender para que los revisores puedan
comprenderlo sin ayuda externa.
o Tiene lugar la creación de todos los memos de confirmación y documentos de
respaldo.
o El modelo de objetos con todos los atributos y clases nuevas y actualizadas
está listo.
o Diseño por función
5. Construir por característica:
Una vez finalizado el diseño y la inspección del diseño, en este proceso, se realizará la
codificación, seguida de la integración e implementación del código.
➢ Criterios de entrada: se lleva a cabo la creación de un paquete de diseño. Ahora los
propietarios de clases implementan y realizan pruebas e inspecciones de programador
jefe.
➢ Tareas:
o Implementación de clase por propietario de clase
o Inspección de código por arquitecto jefe
o Además, el arquitecto jefe realiza las pruebas unitarias.
o Promocionar para construir después de pruebas exitosas
➢ Verificación: Se lleva a cabo la inspección del código y las pruebas unitarias.
➢ Salida: finalización de las funciones valoradas por el cliente.

Combinando todos los procesos anteriores, el flujo de trabajo del proceso para FDD es
➢ En primer lugar, comprender el problema que debe resolverse e identificar su alcance.
➢ En segundo lugar, dividir el problema en funciones más pequeñas y luego en
subconjuntos.

27
 ➢ Además de lo anterior, las pequeñas secciones llamadas Objetos también se dividen
en clases.
➢ Después de eso, ocurre la asignación de esta clase (característica) al desarrollador
individual. Ese desarrollador será propietario de una Clase para esa función en
particular.
➢ Además, el propietario de la clase hace el diseño y luego diseña la inspección de cada
clase. Además de lo anterior, este será un pequeño problema a resolver en
comparación con el último subconjunto. (mostrado en la figura anterior)
➢ Una vez finalizada la codificación de inspección de diseño, se realizan pruebas
unitarias para comprobar si la codificación está a la altura de la marca para esa
característica en particular.
➢ Después de la codificación exitosa, se realiza la integración y la inspección del
código.
➢ Además, una vez que ocurra el desarrollo e implementación de clases; se combinan.
➢ Finalmente, crean una solución a un problema más importante cuando se combinan.

VENTAJAS Y DESVENTAJAS
Ventajas:
➢ El desarrollo basado en funciones tiene muchas ventajas. Algunos de ellos son-
➢ Primero, el seguimiento del progreso del proyecto ocurre mediante una
característica que es un enfoque enfocado.
➢ En segundo lugar, permite que varios equipos trabajen simultáneamente. Lo que,
a su vez, reduce el tiempo.
➢ En tercer lugar, ofrece mejores instalaciones de seguimiento de procesos.
➢ En cuarto lugar, se adapta bien a equipos grandes o bien a un proyecto.
Además de lo anterior, la experiencia del desarrollador varía y esto hace que el equipo sea
mejor. Sobre todo, proporciona mejores oportunidades de aprendizaje para otros miembros
del equipo.
Desventajas:
➢ En primer lugar, funciona muy bien para proyectos de gran tamaño, pero no es ideal
para proyectos de pequeño tamaño. Había otros métodos para proyectos de pequeño
tamaño como Scrum, XP. Además, el diseño de este método ocurrió explícitamente
para proyectos de gran tamaño, pero más tarde, surgió como una desventaja ya que
su aplicación no era posible para proyectos de pequeño tamaño.
➢ En segundo lugar, conduce a una gran dependencia de una persona. El programador
jefe desempeña muchas funciones como coordinador, diseñador principal y mentor.
Jugar múltiples roles en un proyecto de gran tamaño es un problema, ya que aumenta
las posibilidades de errores humanos.
Además de las desventajas anteriores, el diseño de este método ocurre de manera que las
iteraciones no están bien definidas por el proceso, a diferencia de otros métodos ágiles. Son

28
específicos del proyecto y son según los requisitos del proyecto. Por lo tanto, no existe ningún
procedimiento estándar para la iteración.
Para concluir, el desarrollo basado en características ayuda a obtener mejores resultados ya
que sigue las mejores prácticas. Es más organizado y permite que varios equipos trabajen en
paralelo, lo que ahorra tiempo. Este marco ágil no es tan antiguo como otros marcos, sin
embargo, ha desarrollado su lugar seguro en el mercado actual, especialmente en proyectos
a gran escala.

29
 REFERENCIAS BIBLIOGRAFICAS

DESARROLLO DE SOFTWARE LEAN:

https://www.ekon.es/blog/metodologia-lean-
empresa/#:~:text=La%20metodolog%C3%ADa%20Lean%20es%20una,la%20experiencia
%20de%20los%20clientes.
https://danielgrifol.es/metodologias-de-desarrollo-agil-lean-development/
https://searchsoftwarequality.techtarget.com/definition/lean-
programming#:~:text=Lean%20software%20development%20is%20a%20concept%20that
%20emphasizes,development%20methodology.%20Seven%20principles%20of%20lean%2
0software%20development
https://www.globalbit.co/2019/07/11/desarrollo-de-software-lean-lsd-y-sus-beneficios-
para-las-empresas/
DYNAMIC SYSTEMS DEVELOPMENT METHOD DSDM:
http://m.ingenieriadesoftware.mex.tl/images/18149/DSDM%20documento.pdf

https://es.wikiversity.org/wiki/Dynamic_Systems_Development_Method

FEATURE DRIVEN DEVELOPMENT (FDD):

https://www.toolsqa.com/agile/feature-driven-
development/#:~:text=%20Feature%20Driven%20Development%20%28FDD%29%20Pra
ctices%3A%20%201,the%20decomposition%20of%20function%20into%20small...%20M
ore%20

30