esta diapositiva esta subida con el objetivo que todos aprendan el uso y desarrollo de software con altas caracteristicas y requerimientos

1. ING. SOFTWARE 1

2. Desarrollo de un modelo general
Construcción de una lista de
funcionalidades
Planeación por funcionalidad
Diseño por funcionalidad
Construcción por funcionalidad.

4.  Al
comienzo del desarrollo los expertos
del dominio están al tanto e la visión,
contexto y requerimientos del sistema a
construir.

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

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

7.  Una
funcionalidad de un ítem útil a los
ojos del cliente.

8.  Se
elabora una lista de funcionalidades
que resuma la funcionalidad general del
sistema.

9.  La
lista es elaborada por desarrolladores
y es evaluada por el usuario.

10.  Se
divide la lista en subconjuntos según
la afinidad y la dependencia de las
funcionalidades.

11.  La
lista es finalmente revisada por los
usuarios y los responsables para su
validación y aprobación.

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

13.  Se
selecciona un conjunto de
funcionalidades de la lista
 Se
procede a diseñar y construir la
funcionalidad mediante un proceso
iterativo.

14.  Una
iteración de máximo unas dos
semanas, incluye inspección de diseño,
codificación, pruebas unitarias,
integración e inspección de código.

15.  La
debilidad de FDD está en la
necesidad de tener en el equipo
miembros con experiencia que marquen
el camino a seguir desde el principio,
con la elaboración del modelo global,
puesto que no es tan ágil como del
modelo global, puesto que no es tan ágil
como podría serlo XP.

16.  Tamaño
de los equipos: RUP está
pensado para proyectos y equipos
grandes en cuanto a tamaño y duración.
FDD y XP en proyectos cortos y equipos
mas pequeños.

17.  Obtención
de requisitos: RUO y XP
crean como base UseCase y
UserStories, por lo contrario FDD no
define explícitamente esa parte del
proyecto sobre la adquisición de
requisitos.

18.  Evaluación
del estado del proyecto: FDD
es posiblemente el proceso mas
adecuado para definir métricas que
definan el estado del proyecto debido a
las pequeñas divisiones en donde su
seguimiento.

19.  Evaluación
del estado del proyecto: FDD
es posiblemente el proceso mas
adecuado para definir métricas que
definan el estado del proyecto debido a
las pequeñas divisiones en donde su
seguimiento.

20.  Jose
Samuel Iglesias.
 David Polio Torres.
 Edgar Rolando Mendoza.