Este documento describe y compara varios modelos de procesos de desarrollo de software. Presenta el modelo en cascada, los modelos evolutivos como el incremental y el espiral. También describe modelos ágiles como Crystal Clear, XP y FDD, los cuales se enfocan en iteraciones cortas y entregas frecuentes con participación del cliente.

1. MODELOS DE PROCESO
DE SOFTWARE
DEFINICION Y MODELOS

2. DEFINICION
UN MODELO DE PROCESO NO ES MAS QUE LA SIMPLIFICACION O
ABSTRACCION DE UN PROCESO DE REAL
UN MODELO ES L DESCRIPCION DE UN PROCESO DE SOFTWARE QUE
SE PRESENTA DESDE UNA PERSPECTIVA PARTICULAR.

3. MODELOS SECUENCIALES
MODELO CASCADA
ES DE LOS FINALES DE LOS 70.
EL DESARROLLO DE SOFTWARE SE REALIZA A TRAVES DE UNA
SECUENCIA SIMPLE DE FASES.
CADA FASE TIENE CONJUNTO DE METAS Y ACTIVIDADES BIEN
DEFINIDAS.

4. MODELOS EVOLUTIVOS
MODELO INCREMENTAL
Cuanto más complejo es un sistema software, mayor es el riesgo asociado
al proyecto.
Una forma de reducir el riesgo es desarrollar el sistema de forma
incremental. Esto es: dividir el proyecto en fases y desarrollar una parte de
los requerimientos en cada fase.
El modelo incremental mantiene el modelo en cascada, pero lo repite “n”
veces.
Ventajas del modelo incremental:
 Construir un sistema pequeño siempre es menos arriesgado que construir un sistema
grande.
 Si se comete un error importante, afecta a la última fase y siempre se puede ir a una versión
anterior.
 Se puede depurar cada fase (versión) antes de pasar a la siguiente.
 Al desarrollar sólo parte de las funcionalidades y requerimientos en cada fase, es más fácil
comprobar si los requerimientos de las siguientes fases son adecuados y correctos.

5. MODELO ESPIRAL
• En este modelo el esfuerzo de desarrollo es iterativo. Esto es: tan
pronto se completa un esfuerzo de desarrollo (una vuelta a la espiral),
comienza el siguiente.
• En cada vuelta a la espiral se suelen seguir los siguientes pasos:
1.Fijar objetivos y determinar alternativas.
2.Evaluar las alternativas y elegir la mejor.
3.Desarrollo de la alternativa elegida y evaluación y validación del
resultado.
4.Planificación de la próxima iteración.
• Es compatible también con el modelo en cascada.

6. MODELO CONCURRENTE
1. Se representa de forma esquemática como una serie de tareas junto con
sus estados asociados. Da respuesta a la situación habitual de los
proyectos, en la que se realizan varias tareas simultáneamente, aunque
se encuentran en distintos estados. Muchas veces, el mayor conocimiento
del problema en la fase de diseño, de codificación, etc. pueden, por
ejemplo, hacer que se replantee la especificación de requisitos mientras
se sigue desarrollando.
2. Este modelo define una serie de eventos que disparan transiciones de
unos estados a otros para cada una de las tareas o actividades del
proyecto de desarrollo software.
3. Este modelo proporciona, por tanto, una visión exacta del estado actual
del proyecto.

7. MODELOS AGILES
CRYSTAL CLEAR
Crystal Clear no es una metodología en sí misma sino una familia de
metodologías con un “código genético” común.
Clear es para equipos de 3 hasta 8 personas o menos.
CC puede ser usado en proyectos pequeños y como casi todos los
otros métodos, CC consiste en valores, técnicas y procesos.
Menos énfasis en la documentación exhaustiva y más en versiones
que corran y puedan ser probadas. Lo primero son promesas, lo
segundo hechos.
Da flexibilidad y prioriza la parte humana, apuntando a lograr
eficiencia, habitabilidad y confianza en los miembros del equipo.
Presta especial importancia a la ubicación física del grupo, donde la
comunicación cumple el principal rol.

8. MODELO XP
Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión.
Programación en parejas: se recomienda que las tareas de desarrollo se lleven
a cabo por dos personas en un mismo puesto.
Frecuente integración del equipo de programación con el cliente o usuario. Se
recomienda que un representante del cliente trabaje junto al equipo de
desarrollo
Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer
entregas frecuentes.
Refactorización del código, es decir, reescribir ciertas partes del código para
aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento.
Propiedad del código compartida: en vez de dividir la responsabilidad en el
desarrollo de cada módulo en grupos de trabajo distintos, este método
promueve el que todo el personal pueda corregir y extender cualquier parte
del proyecto

9. MODELO FDD
i. No hace énfasis en la obtención de los requerimientos sino en
como se realizan las fases de diseño y construcción.
ii. Se preocupa por la calidad, por lo que incluye un monitoreo
constante del proyecto.
iii. Ayuda a contrarrestar situaciones como el exceso en el
presupuesto, fallas en el programa o el hecho de entregar menos
de lo deseado.
iv. Propone tener etapas de cierre cada dos semanas.
v. Se obtienen resultados periódicos y tangibles.
vi. 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 monitoriar.
vii. Define claramente entregas tangibles y formas de evaluación del
progreso del proyecto.