1. Modelos de
Proceso del
Software

2. GRUPO 6
INTEGRANTES
• Maria Zeleste Zelada Argani
• Diego Adrian Charca Flores
• Daniel Quispe Cusicanqui
• Diego Junior Llusco Chui
• Cristhian Martinez Oraqueni
• Luis Fernando Cori Tipo
• Vladimir Quispe Condori

3. Proceso de software
Un proceso de desarrollo de software
es un conjunto de personas,
estructuras de organización, reglas,
políticas, actividades y sus
procedimientos, componentes de
software, metodologías, y
herramientas utilizadas o creadas
específicamente para definir,
desarrollar, ofrecer un servicio,
innovar y extender un producto de
software.

4. • Modelo en Espiral(Modelo Iterativo)
• Modelo Evolutivo
• Modelo agil

5. Modelo en Espiral (Modelo Iterativo)
El MODELO en espiral, propuesto originalmente por
BOEHM en 1976, es un modelo de proceso de software
evolutivo donde se conjuga la naturaleza de
construcción de prototipos con los aspectos controlados
y sistemáticos del MODELO LINEAL y SECUENCIAL.
Proporciona el potencial para el desarrollo rápido de
versiones incrementales del software que no se basa en
fases claramente definidas y separadas para crear un
sistema.
EL modelo en espiral se divide en un número de
actividades de marco de trabajo, también llamadas
REGIONES DE TAREAS , Cada una de las regiones están
compuestas por un conjunto de tareas del trabajo
llamado CONJUNTO DE TAREAS que se adaptan a las
características del proyecto que va a emprenderse en
todos los casos se aplican actividades de protección.

6. El modelo espiral tuvo varias
modificaciones que son:
- Modelo Original de Boehm.
- Modelo Típico de Seis Regiones.
- Modelo WINWIN.

7. Modelo Original de
Boehm
No hay un número definido de iteraciones. Las
iteraciones debe decidir las el equipo de gestión de
proyecto
Cada vuelta se divide en 4 sectores:
Planeación : determinación de los objetivos,
alternativas y restricciones
Análisis de riesgo : análisis de alternativas e
identificación/resolución de riesgos
Ingeniería : desarrollo del producto hasta "el siguiente
nivel".
Evaluación : valoración por parte del cliente de los
resultados obtenidos.
El movimiento de la espiral, ampliando con cada
iteración su amplitud radial, indica que cada vez se
van construyendo versiones sucesivas del software,
cada vez más completas.
Uno de los puntos más interesantes del modelo, es la
introducción al proceso de desarrollo a las actividades
de análisis de los riesgos asociados al desarrollo y a la
evaluación por parte del cliente de los resultados del
software.

8. Modelo Típico de
Seis Regiones.
Las regiones de tareas que componen este modelo son:
Comunicación con el cliente: las tareas requeridas para
establecer comunicación entre el desarrollador y el cliente.
Planificación: las tareas requeridas para definir recursos, el
tiempo y otras informaciones relacionadas con el proyecto.
Son todos los requerimientos.
Análisis de riesgos: las tareas requeridas para evaluar riesgos
técnicos y otras informaciones relacionadas con el proyecto.
Ingeniería: las tareas requeridas para construir una o más
representaciones de la aplicación.
Construcción y adaptación: las tareas requeridas para
construir, probar, instalar y proporcionar soporte al usuario.
Evaluación del cliente: las tareas requeridas para obtener la
reacción del cliente según la evaluación de las
representaciones del software creadas durante la etapa de
ingeniería e implementación durante la etapa de instalación.

9. Modelo WINWIN
El modelo en espiral WINWIN
introduce tres hitos en el
proceso, llamados puntos
de fijación que ayudan a
establecer la completitud
de un ciclo alrededor del
espiral y proporcionan hitos
de decisión antes de
continuar el proyecto de
software.

10. VENTAJAS
• El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
• Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente
comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
• El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de
prototipos en cualquier etapa de evolución del producto.
• El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las
etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se
conviertan en problemas.
• En la utilización de grandes sistemas a doblado la productividad.
DESVENTAJAS
• Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
• Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos

11. Modelo Evolutivo
El desarrollo evolutivo consta
del desarrollo de una versión
inicial que luego de exponerse
se va refinando de acuerdo de
los comentarios o nuevos
requerimientos por parte del
cliente o del usuario final. Las
fases de especificación,
desarrollo y validación se
entrelazan en vez de separarse.

12. Hacer prototipos
El diseño rápido lleva a la
construcción de un
prototipo. Esté se entrega
y es evaluado por los
participantes, que dan
retroalimentación para
mejorar los requerimientos.
La iteración ocurre a
medida de que el
prototipo es afinado para
satisfacer las necesidades
de distintos participantes,
y al mismo tiempo le
permite a usted entender
mejor lo que se necesita
hacer.

13. Modelo Espiral de
tipo Evolutivo
Este es un modelo de proceso
de software evolutivo, el cual
enlaza la naturaleza iterativa
de la construcción de
prototipos, pero conservando
aquellas propiedades del
modelo en cascada.
El modelo en espiral fue
desarrollado por Boehm,
quien lo describe así: El
modelo de desarrollo en
espiral es un generador de
modelo de proceso guiado
por el riesgo que se emplea
para conducir sistemas
intensivos de ingeniería de
software concurrente y a la
vez con muchos usuarios.

14. Modelo Cascada
En Ingeniería de software el desarrollo en
cascada, también llamado modelo en
cascada, es el enfoque metodológico que
ordena rigurosamente las etapas del proceso
para el desarrollo de software, de tal forma
que el inicio de cada etapa debe esperar a la
finalización de la etapa anterior.
Un ejemplo de una metodología de desarrollo
en cascada es:
1. Análisis de requisitos.
2. Diseño del Sistema.
3. Diseño del Programa.
4. Codificación.
5. Pruebas.
6. Implantación.
7. Mantenimiento.

15. Modelo Ágil
Las metodologías ágiles son
aquellas que permiten adaptar la
forma de trabajo a las condiciones
del proyecto, consiguiendo
flexibilidad e inmediatez en la
respuesta para amoldar el proyecto
y su desarrollo a las circunstancias
específicas del entorno.

16. Proceso Unificado
Ágil.
(AUP, del inglés Agile Unified Process) es una
versión simplificada del proceso Unificado de
Rational (Rational Unified Process, RUP)
desarrollada por Scott Ambler, que describe
una aproximación al desarrollo de
aplicaciones que combina conceptos propios
del proceso unificado tradicional con técnicas
ágiles, con el objetivo de mejorar la
productividad.
En general, el Proceso Unificado Ágil supone
un enfoque intermedio entre XP (extreme
Programan) y el Proceso Unificado de
Rational, y tiene la ventaja de ser un proceso
ágil que incluye explícitamente actividades y
artefactos a los que la mayoría de
desarrolladores ya están, de alguna manera,
acostumbrados.

17. Desarrollo de
software Lean
El desarrollo Lean es una adaptación a los
entornos de desarrollo de software del
método de producción Toyota para
equipos pequeños de programadores. Se
fundamenta principalmente en constituir
un equipo fuerte y altamente preparado
capaz de llevar a cabo cualquier tarea
en poco tiempo, legando todo a la
eficacia y la cohesión de los
componentes del equipo y obviando los
procesos y la burocracia que conlleva
normalmente el tener un sistema de
producción preestablecido.

18. Kanban
El Kanban (del japonés: kanban, significa "tarjeta" o
"tablero") es un sistema de información que
controla de modo armónico la fabricación de los
productos necesarios en la cantidad y tiempo
necesarios en cada uno de los procesos que tienen
lugar tanto en el interior de la fábrica, como entre
distintas empresas.
También se denomina “sistema de tarjetas”, pues
en su implementación más sencilla utiliza tarjetas
que se pegan en los contenedores de materiales y
que se despegan cuando estos contenedores son
utilizados, para asegurar la reposición de dichos
materiales. Las tarjetas actúan de testigo del
proceso de producción. Otras implementaciones
más sofisticadas utilizan la misma filosofía,
sustituyendo las tarjetas por otros métodos de
visualización del flujo.