1. Modelos de Desarrollo
ALLSOFT S.A. de C.V.
Monterrey, N.L.
1

2. Introducción
Para el desarrollo de cualquier producto de
software se realizan una serie de tareas entre la
idea inicial y el producto final.
Un modelo de desarrollo establece el orden en
el que se harán las cosas en el proyecto, nos
provee de requisitos de entrada y salida para
cada una de las actividades.
2002-2003, Derechos Reservados

3. Introducción
Es necesario destacar el ciclo de vida del proyecto y el
modelo de desarrollo.
El ciclo de vida del proyecto ayuda a controlar las
actividades del proyecto desde el inicio al fin del mismo.
El modelo de desarrollo nos ayuda a la forma en la que
vamos a construir el producto.
Ambos se complementan para generar el producto
desde el punto de vista técnico y administrativo.
2002-2003, Derechos Reservados

4. Modelos de Desarrollo...
 El Modelo de Cascada.
 El Modelo en V.
 En Flor.
 Prototipos
 El Modelo de Espiral.
 El Modelo de Procesos.
 Desarrollo Incremental.
2002-2003, Derechos Reservados

5. El Modelo de Cascada
 El ciclo de desarrollo de software.
 Este modelo tiene una secuencia ordenada.
 El trabajo de una etapa previa es la entrada del
siguiente proceso.
 Provee de un gran control sobre las fechas de
entrega y entregables.
2002-2003, Derechos Reservados

6. El Modelo de Cascada
 Establece criterios de entrada y salida en cada
fase claramente definidos.
 Dado que provee pocos puntos de visibilidad da
la impresión de que es lento.
2002-2003, Derechos Reservados

7. El Modelo de Cascada
Inicio
Análisis
Diseño
Código
Pruebas
Implem.
2002-2003, Derechos Reservados

8. A Favor...
 Excelente cuando se tiene un producto estable y
se conoce la tecnología.
 Es un método muy estructurado que funciona
bien con gente de poca experiencia.
 Provee estabilidad en los requerimientos.
 La planeación se puede hacer anticipadamente.
2002-2003, Derechos Reservados

9. En Contra...
 Tiene poca flexibilidad.
 Los proyectos en la práctica raramente siguen un flujo
secuencial.
 Siempre es difícil para el cliente mostrar todos los
requerimientos explícitamente y con mucha
anticipación.
 El cliente debe tener paciencia.
2002-2003, Derechos Reservados

10. En Contra...
 Es inflexible y no motiva al cambio.
 Poco apropiado para aplicaciones para la toma
de decisiones.
 Los usuarios tienen una participación limitada.
2002-2003, Derechos Reservados

11. El Modelo en V
 Una reexaminación del modelo del ciclo de vida
desde el punto de vista de aseguramiento de
calidad.
 Cuando cada proceso termina su producto, las
especificaciones de prueba para la probar los
procesos están también completas.
2002-2003, Derechos Reservados

12. El Modelo en V
Inicio Análisis Diseño
Plan de Aceptación Pruebas de
Integración del Integración del Código
Sistema Sistema
Implem. UAT I.S.T
2002-2003, Derechos Reservados

13. Modelo en Flor
 El propósito del desarrollo de software es el de
desarrollar un producto de software.
 Los equipos no deben de estar preocupados por el
proceso de desarrollo mismo.
 Deben de desarrollarse todas las etapas un poco al
mismo tiempo hasta que el producto final es alcanzado.
2002-2003, Derechos Reservados

14. Prototipos
Un prototipo es una versión preliminar
de un sistema de información con fines
de demostración o evaluación.
2002-2003, Derechos Reservados

15. Construcción de Prototipos
 Identificación de Requerimientos.
 Diseño Rápido.
 Utilizar el Prototipo.
 Revisar y Mejorar.
2002-2003, Derechos Reservados

16. Prototipos...
 Es un método menos formal de desarrollo.
 El prototipeo es una técnica para comprender
las especificaciones.
 Un prototipo puede ser eliminado.
 Un prototipo puede llegar a ser parte del
producto final.
2002-2003, Derechos Reservados

17. A Favor...
 Utiles cuando los requerimientos son
cambiantes.
 Cuando no se conoce bien la aplicación.
 Cuando el usuario no se quiere comprometer
con los requerimientos.
 Cuando se quiere probar una arquitectura o
tecnología.
 Cuando se requiere rapidez en el desarrollo.
2002-2003, Derechos Reservados

18. En Contra...
 No se conoce cuando se tendrá un producto
aceptable.
 No se sabe cuantas iteraciones serán
necesarias.
 Da una falsa ilusión al usuario sobre la
velocidad del desarrollo.
 Se puede volver el producto aún y cuando no
este con los estándares.
2002-2003, Derechos Reservados

19. El Modelo de Espiral
 Los productos de software son creados a través
de múltiples repeticiones del proceso del ciclo
de vida. Se rompen un mini-proyectos.
 Estos modelos han sido aplicados al desarrollo
de software.
 Aun no han madurado al punto de ser aplicados
como modelos de desarrollo con tiempos y
limitaciones de costos.
2002-2003, Derechos Reservados

20. El Modelo de Espiral
Validación del Pruebas de Prototipo
Diseño Integración
Análisis Prototipo
de Riesgo
Diseño del
Requerimientos
Producto Requerimientos del Software
Plan de Validación de
Prototipo Desarrollo Requerimientos
2002-2003, Derechos Reservados

21. A Favor...
 El producto avanza a pasos firmes solucionado
riesgos en cada iteración.
 El producto termina con todos los riesgos
resueltos.
 Se pueden incluir otros métodos de desarrollo
en las iteraciones.
 A medida que el costo aumenta, los riesgos se
reducen.
 Se tienen puntos de control en cada
interacción.
2002-2003, Derechos Reservados

22. En Contra...
 Es complicado.
 Requiere de mucha administración.
 Difícil de definir los objetivos, metas que
indiquen que podemos avanzar al siguiente
ciclo.
 Se puede caer en un desarrollo de nunca
acabar.
2002-2003, Derechos Reservados

23. El Modelo de Procesos
 Impulsa un proceso iterativo de desarrollo.
 Cada ciclo es una versión del producto.
 Utiliza metas definidas para marcar la transición
entre las distintas etapas.
 Ofrece mayor poder de decisión a los usuarios.
 Busca mejorar la calidad y creatividad.
2002-2003, Derechos Reservados

24. El Modelo de Procesos
Estabilización
Idea/Necesidad
Construcción Planeación
2002-2003, Derechos Reservados

25. Las Metas
Liberación
Código
Completo
Visión y
Alcance
Especificaciones
Aprobadas
2002-2003, Derechos Reservados

26. A Favor...
 Etapas claramente definidas con metas,
entregables y responsables.
 Se establecen roles asociados al modelo que
promueven la participación de todos.
 Involucra muy de cerca al usuario.
2002-2003, Derechos Reservados

27. En Contra...
 Dado que la mayoría de las decisiones son en
consenso por el equipo en su conjunto, en
ocasiones toman más tiempo de lo debido.
 Para proyectos pequeños puede resultar poco
practico.
 El considerar versiones hace que se dejen de
lado algunas decisiones.
2002-2003, Derechos Reservados

28. Desarrollo Incremental
 Permite construir el proyecto en etapas
incrementales en donde cada etapa agrega
funcionalidad.
 Cada etapa consiste de requerimientos, diseño,
codificación, pruebas, y entrega.
 Permite entregar al cliente un producto más
rápido en comparación del modelo de cascada.
2002-2003, Derechos Reservados

29. Desarrollo Incremental
Reduce los riesgos ya que:
– Provee visibilidad sobre el progreso a través de sus
nuevas versiones.
– Provee retroalimentación a través de la
funcionalidad mostrada.
– Permite atacar los mayores riesgos desde el inicio.
2002-2003, Derechos Reservados

30. Desarrollo Incremental
 Se pueden hacer implementaciones parciales si se
cuenta con la suficiente funcionalidad.
 Las pruebas y la integración es constante.
 El progreso se puede medir en periodos cortos de
tiempo.
 Resulta más sencillo acomodar cambios al acotar el
tamaño de los incrementos.
2002-2003, Derechos Reservados

31. Desarrollo Incremental
 Se puede planear en base a la funcionalidad
que se quiere entregar primero.
 Por su versatilidad requiere de una planeación
cuidadosa tanto a nivel administrativo como
técnico.
2002-2003, Derechos Reservados

32. A Favor …
 La solución se va mejorando en forma
progresiva a través de las múltiples iteraciones.
 Incrementa el entendimiento del problema y de
la solución por medio de los refinamientos
sucesivos.
2002-2003, Derechos Reservados

33. En Contra …
 Requiere de mucha planeación, tanto
administrativa como técnica.
 Requiere de metas claras para conocer el
estado del proyecto.
2002-2003, Derechos Reservados

34. ¿Qué Modelo Utilizar?
34

35. Un Proyecto...
Un proyecto es una organización transitoria
de individuos dedicados a alcanzar un
objetivo especifico dentro de un periodo de
tiempo, un presupuesto, y un objetivo
técnico.
2002-2003, Derechos Reservados

36. Por lo Tanto...
Un proyecto:
• Tiene un principio y un fin.
• Debe de tener un objetivo (debe de ser medible).
• Requiere de un líder y de un equipo.
Lo que nos indica que es:
• Temporal y Unico, ya que involucra hacer algo que no se
ha hecho antes.
2002-2003, Derechos Reservados

37. ¿Qué Modelo?
Dado que cada proyecto es único, no existe un modelo
que se aplique al 100% a todos los proyectos de una
organización.
Una organización puede contar con uno o más modelos de
desarrollo para ser utilizados dependiendo del tipo de
proyecto.
El modelo seleccionado tendrá influencia en el éxito del
proyecto y en el tipo de decisiones que se deberán hacer.
2002-2003, Derechos Reservados

38. ¿Cuál Seguir?
Para seleccionar el modelo a adoptar habrá que
hacerse una serie de cuestionamientos:
– ¿Qué tantos son los riesgos del proyecto?
– ¿Qué tan claros están los requerimientos?
– ¿Se conoce bien la tecnología ha utilizar?
– ¿Visibilidad que requiere el proyecto?
– ¿Qué tanta planeación hacia adelante es requerida?
– ¿Qué restricciones se tienen?
2002-2003, Derechos Reservados

39. Criterios de Exito
Contar con un modelo debidamente documentado.
(entradas, salidas, entregables, aprobaciones)
Los documentos deben de estar actualizados.
La gente que participa en el proyecto debe estar
capacitada en su uso.
Se debe de reforzar el uso del modelo mediante auditorias
y revisiones.
2002-2003, Derechos Reservados

40. Criterios de Exito
La alta gerencia debe soportar la utilización de
un modelo.
Cualquier desviación al modelo debe ser
documentada y aprobada.
Se debe de medir la eficiencia del modelo.
Retroalimentar y ajustar.
2002-2003, Derechos Reservados

41. Ejercicios
41