1. MODELOS DE PROCESO DE SOFTWARE

2. TEMAS DE UNIDAD IV
 4.1.- Modelo de cascada
 4.2.- Modelo de espiral
 4.3.- Modelo incremental
 4.4.- Proceso de desarrollo unificado
 4.5.- Proceso software personal

3. MODELOS DE PROCESO DE SOFTWARE
 Por su naturaleza los modelos son simplificados,
por lo tanto un modelo de procesos del software es
una abstracción de un proceso real”.
 Los modelos genéricos no son descripciones
definitivas de procesos de software; sin embargo,
son abstracciones útiles que pueden ser utilizadas
para explicar diferentes enfoques del desarrollo de
software.

4. 4.1. MODELO DE CASCADA
 El modelo en cascada, alguna vez llamado el ciclo de
vida clásico, sugiere un enfoque sistemático,
secuencial hacia el desarrollo del software, que se
inicia con la especificación de requerimientos del
cliente y que continúa con la planeación, el modelado,
la construcción y el despliegue para culminar en el
soporte del software terminado.

5.  Análisis de requisitos: Se analizan las necesidades de los usuarios
finales del software para determinar qué objetivos debe cubrir.
 Diseño: Se descompone y organiza el sistema en elementos que
puedan elaborarse por separado, aprovechando las ventajas del
desarrollo en equipo.
 Codificación: Aquí se desarrolla el código fuente, haciendo uso de
prototipos así como pruebas y ensayos para corregir errores.
 Pruebas: Los elementos, ya programados, se ensamblan para
componer el sistema y se comprueba que funciona correctamente
antes de ser puesto en explotación.
 Implantación: El software obtenido se pone en producción.
 Mantenimiento: Durante la explotación del sistema software
pueden surgir cambios.

6. 4.2. MODELO DE ESPIRAL
 El modelo en espiral, que Boehm propuso
originalmente, es un modelo de proceso de software
evolutivo que conjuga la naturaleza iterativa de la
construcción de prototipos con los aspectos controlados
y sistemáticos del modelo en cascada.

7.  Este método está basado en dos importantes principios:
1) La práctica de diseño profesional es caracterizar en
términos de conocer, actuar en situaciones, conversación
con la situación y reflexión en acción. Hay un distinto
medio de proceso - orientación en esta aproximación al
diseño
2) La necesidad para diseñadores de tomar la práctica de
trabajo seriamente, de supervisar las formas en las que el
trabajo se esté haciendo, en el sentido de una solución
abierta y desplegada para aumentar la complejidad de una
situación que el diseñador sólo entiende parcialmente.

8. LAS ETAPAS DEL MODELO EN ESPIRAL PUEDEN SER LAS
SIGUIENTES
 Planificación: Determinación de objetivos, limites y condiciones de contorno
(condiciones que limitan de alguna manera el desarrollo, económicas, de
tiempo, etc.) y alternativas .
 Análisis de riesgo: Desarrollo de un plan para descubrir los riesgos más
importantes y resolver los mismos.
 Ingeniería: Desarrollo del producto o prototipo según las condiciones de la
etapa anterior.
 Evaluación : Evaluar los resultados del prototipo obtenido, verificar y validar.
 Toma de decisiones: Se determina si se pasa al ciclo exterior o se realiza una
nueva iteración.
 Refinamiento : Si se toma la decisión de continuar en los ciclos internos se
sofistican las condiciones a tomar en cuenta en el planeamiento del nuevo
ciclo, en los ciclos exteriores es una etapa que no se utiliza.

9. 4.3. MODELO INCREMENTAL
 El modelo incremental entrega el software en partes pequeñas,
pero utilizables, llamadas "incrementos". En general, cada
incremento se construye sobre aquel que haya sido entregado
anteriormente.
 Perteneciente a la familia de los Modelos de Procesos Evolutivos,
el Modelo Incremental combina elementos del Modelo Lineal
Secuencial (MLS) con la filosofía interactiva de construcción de
prototipos.

10. CARACTERÍSTICAS DEL MODELO INCREMENTAL
a) Combina elementos del modelo de cascada con la filosofía interactiva de construcción
de prototipos.
b) El primer incremento es un producto esencial (núcleo), se afrontan requisitos básicos.
c) Los requisitos son priorizados.
d) Los requisitos de un incremento son inamovibles.
e) El cliente usa el producto central y en base a la utilización y/o evaluación, Este proceso
se repite hasta que se elabora el producto completo.
f) Es interactivo, al igual que el de construcción de prototipos y otros enfoques evolutivos.
g) Es útil cuando la dotación de personal no está disponible para una implementación
completa.
h) Las siguientes son algunas creencias del modelo incremental:
 La administración de proyectos es más fácil de lograr .
 Es más fácil comprender y probar incrementos de funcionalidad más pequeños.
 La funcionalidad inicial se desarrolla más temprano,.
 Hay más probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos
del software en el tiempo.

11. LOS PASOS DEL MODELO INCREMENTAL
1) El primer incremento a menudo es un producto esencial, se
implementan los requerimientos básicos.
2) Se entrega un producto operacional al cliente
3) El cliente lo utiliza, como resultado de la utilización y/o
evaluación.
4) El cliente solicita mejoras al producto
5) Se desarrolla el siguiente incremento incorporando los nuevos
requisitos y agregando la nueva función.
6) Se desarrolla el siguiente incremento.
7) Se repite nuevamente el ciclo.

12. 4.4. PROCESO DE DESARROLLO UNIFICADO
 De alguna manera, el proceso unificado (PU) es un intento
encaminado a reunir los mejores rasgos y características de
modelos de procesos de software, pero los caracteriza de
manera que implementa muchos de los mejores principios
del desarrollo ágil de software.

13. Fases del proceso unificado
1. Inicio del PU abarca la comunicación con cliente - actividades de
planeación. En este punto, la arquitectura no es más que un
esquema tentativo de los subsistemas más importantes y de las
funciones y características que los forman.
2. Elaboración abarca la comunicación con el cliente y las actividades
de modelado del modelo genérico del proceso.
3. Construcción del PU es idéntica a la actividad de construcción
definida para el proceso genérico del software.
4. Transición del PU abarca las últimas etapas de la actividad genérica
de construcción y la primera parte de la actividad genérica de
despliegue.
5. Producción del PU coincide con la actividad de despliegue del
proceso genérico.

14. Fases del proceso unificado
1. Inicio del PU abarca la comunicación con cliente - actividades de
planeación. En este punto, la arquitectura no es más que un
esquema tentativo de los subsistemas más importantes y de las
funciones y características que los forman.
2. Elaboración abarca la comunicación con el cliente y las actividades
de modelado del modelo genérico del proceso.
3. Construcción del PU es idéntica a la actividad de construcción
definida para el proceso genérico del software.
4. Transición del PU abarca las últimas etapas de la actividad genérica
de construcción y la primera parte de la actividad genérica de
despliegue.
5. Producción del PU coincide con la actividad de despliegue del
proceso genérico.

15. Fases del proceso unificado
1. Inicio del PU abarca la comunicación con cliente - actividades de
planeación. En este punto, la arquitectura no es más que un
esquema tentativo de los subsistemas más importantes y de las
funciones y características que los forman.
2. Elaboración abarca la comunicación con el cliente y las actividades
de modelado del modelo genérico del proceso.
3. Construcción del PU es idéntica a la actividad de construcción
definida para el proceso genérico del software.
4. Transición del PU abarca las últimas etapas de la actividad genérica
de construcción y la primera parte de la actividad genérica de
despliegue.
5. Producción del PU coincide con la actividad de despliegue del
proceso genérico.

16. Fases del proceso unificado
1. Inicio del PU abarca la comunicación con cliente - actividades de
planeación. En este punto, la arquitectura no es más que un
esquema tentativo de los subsistemas más importantes y de las
funciones y características que los forman.
2. Elaboración abarca la comunicación con el cliente y las actividades
de modelado del modelo genérico del proceso.
3. Construcción del PU es idéntica a la actividad de construcción
definida para el proceso genérico del software.
4. Transición del PU abarca las últimas etapas de la actividad genérica
de construcción y la primera parte de la actividad genérica de
despliegue.
5. Producción del PU coincide con la actividad de despliegue del
proceso genérico.

17. Fases del proceso unificado
1. Inicio del PU abarca la comunicación con cliente - actividades de
planeación. En este punto, la arquitectura no es más que un
esquema tentativo de los subsistemas más importantes y de las
funciones y características que los forman.
2. Elaboración abarca la comunicación con el cliente y las actividades
de modelado del modelo genérico del proceso.
3. Construcción del PU es idéntica a la actividad de construcción
definida para el proceso genérico del software.
4. Transición del PU abarca las últimas etapas de la actividad genérica
de construcción y la primera parte de la actividad genérica de
despliegue.
5. Producción del PU coincide con la actividad de despliegue del
proceso genérico.

18. Fases del proceso unificado
1. Inicio del PU abarca la comunicación con cliente - actividades de
planeación. En este punto, la arquitectura no es más que un
esquema tentativo de los subsistemas más importantes y de las
funciones y características que los forman.
2. Elaboración abarca la comunicación con el cliente y las actividades
de modelado del modelo genérico del proceso.
3. Construcción del PU es idéntica a la actividad de construcción
definida para el proceso genérico del software.
4. Transición del PU abarca las últimas etapas de la actividad genérica
de construcción y la primera parte de la actividad genérica de
despliegue.
5. Producción del PU coincide con la actividad de despliegue del
proceso genérico.

19. 4.5. PROCESO SOFTWARE PERSONAL
 El modelo de Proceso Software
Personal (PSP) se caracteriza
porque es de uso personal y se
aplica a programas pequeños de
menos de 10,000 líneas de
código. Se centra en la
administración del tiempo y en
la administración de la calidad
a través de la eliminación
temprana de defectos.

20. NIVELES DE PSP
 PSP tiene un marco de proceso de evolución similar al que
tiene CMM (Evaluación basados en la mejora de procesos
internos CBA IPI). PSP trata parcialmente 12 de las 18 capas
definidas en el CMM.
 PSP logra esto proporcionando un marco de proceso personal
ya definido que el programador puede utilizar. Este marco es:
 Desarrollar un plan para cada proyecto y/o componente.
 Registrar su tiempo de desarrollo.
 Registrar sus defectos
 Conservar sus datos en informes del proyecto
 Utilizar sus datos para planear los proyectos y/o los componentes
futuros.
 Analizar sus datos para desarrollar sus procesos con más calidad para
mejorar su funcionamiento.