materia: Fundamentos de desarrollo de sistemas. profa: Marlene Mijangos Romero

1. ING. EN SISTEMAS COMPUTACIONALES
“TIPOS DE MODELO DEL DESARROLLO DEL SOFTWARE”
MATERIA: FUNDAMENTOS DE DESARROLLO DE SISTEMA
PRESENTAN:
RAUL TRINIDAD PEREZ LOPEZ
YESIKA SANCHEZ HERNANDEZ
MARYSOL SALVADOR MARQUEZ
HUGO ALBERTO ANZURES CRUZ
DOCENTE:
ING MARLENE MIJANGOS ROMERO

2. MODELO CASCADA
 Son las estrategias para crear la estructura de
un programa. Consiste en el análisis de
requerimientos, el diseño, la implementación, la
integración y las pruebas. Estas etapas en
realidad no se ejecutan en una secuencia
estricta ya que suele ser poco práctico
completar totalmente una de estas etapas antes
de comenzar la otra.
 Después de cada etapa se realiza una revisión
para comprobar si se puede pasar a la siguiente.

3. Diseño Cascada
Construye un
modelo de los
requisitos.
Estructura de la
interfaz de usuario.
Construye el sistema.
Criterios de
corrección y
calidad.
Adaptación a
nuevos requisitos.

4. Las características de este modelo son:
Cada fase empieza cuando se ha terminado la
anterior.
Para pasar a la fase posterior es necesario haber
logrado los objetivos de la previa.
Es útil como control de fechas de entregas.
Al final de cada fase el personal técnico y los
usuarios tienen la oportunidad de revisar el
progreso del proyecto.

5. Tipos de proyectos para los que es
adecuado:
 Aquellos para los que se
dispone de todas las
especificaciones desde el
principio, por
ejemplo, los de
reingeniería.
 Se está desarrollando un
tipo de producto que no
es novedoso.
 Proyectos complejos que
se entienden bien desde
el principio.

6. MODELO EN ESPIRAL
La característica clave de un
modelo en espiral es la
gestión del riesgo en
momentos en el ciclo de
desarrollo. Las actividades no
están fijadas a prioridad, sino
que las se eligen en función
del análisis de
riesgo, comenzando por el
bucle interior.

7. FASES DEL MODELO EN ESPIRAL
En este modelo, una
actividad comienza
solo cuando se
entienden los objetivos
y riesgos involucrados.
El desarrollo se
incrementa en cada
etapa, generando una
solución completa.

8. MODELO INCREMENTAL
 Este modelo mantiene la función anterior y
aumenta otra, ya que puede ser que el primer
incremento no hubiera tenido todos los
requerimientos que necesitaba el proyecto.
 Las etapas son las mismas que en el ciclo de
vida en cascada y su realización sigue el
mismo orden, pero corrige la problemática de
la linealidad del modelo en cascada.

9. FASES DEL MODELO INCREMENTAL
Construir un
sistema pequeño es
siempre menos
riesgoso que
construir un
sistema grande.
Los errores de
Al ir desarrollando
desarrollo
parte de las
realizados en un
funcionalidades, es
incremento, pueden
más fácil determinar
ser arreglados antes
si los requerimientos
del comienzo del
planeados para los
próximo incremento
niveles subsiguientes
.
son correctos.
Reduciendo el
tiempo de
desarrollo de un Si un error
sistema los importante es
requerimientos de realizado, sólo la
usuarios pueden última iteración
cambiar durante necesita ser
el desarrollo. descartada

10. Cada incremento tiene su
propio ciclo de vida y se
basa en el anterior, sin
cambiar su funcionalidad
ni sus interfaces. Una vez
entregado un incremento,
no se realizan cambios
sobre el mismo, sino
únicamente corrección
de errores.

11. PROCESO DE DESARROLLO UNIFICADO (UP)
 Integra a diferentes aspectos como
siglos, fases, flujos de trabajo, mitigación de
riesgos, control de calidad, administración de
proyecto y control de configuración. Se basa en
las siguientes creencias:
 Se debe conocer que quieren y necesitan los
usuarios potenciales.
 Debe permitir visualizar un sistema desde
múltiples perspectiva.
 Divide el trabajo en etapa, donde cada
iteración resulta en un incremento del proyecto.

12. Fases del UP
 Fase de concepción.
 Define el alcance del proyecto, propone una
visión de la arquitectura de software y produce
el plan de las fases y el de iteraciones.
 Fase de elaboración.
 Define la arquitectura base del sistema, se
realiza análisis del dominio del problema, se
diseña la solución preliminar.
 Fase de construcción.
 Completa la funcionalidad del sistema y se
realizan las mejoras para el proyecto.
 Fase de transición.
 Ajusta los errores y defectos encontrados en las
pruebas de aceptación, capacita a los usuarios y
provee el soporte técnico necesario.

13. PROCESO DE SOFTWARE PERSONAL (PSP)
Mejora la planeación del trabajo, conoce con precisión el
desempeño mide la calidad de los productos y mejora
las técnicas para su desarrollo.
También muestra como aplicar métodos avanzados de
ingeniería a sus proyectos y/o deberes diarios.
Asimismo provee métodos de estimación y de
planeación muy bien detallados que son necesarios
para dar un seguimiento a su trabajo.

14. Fases del PSP
Requisitos de este modelo:
 Descripción del
problema
 Especificación de
componentes
 Formas de proceso
 Estimadores del tamaño
del producto y tiempos
en base a históricos

15. MODELO XP
La programación extrema (xp) es un modelo de
proceso de software que toma los principios y practicas
aceptadas, y las lleva a niveles extremos.
Las creencias de modelo son las siguientes:
 Los cambios en un sistemas son frecuentes.
 Se deben manejar los cambios de manera
incremental.
 Se debe apoyar los cambios.
 Se debe lograr una rápida retroalimentación.
 Se debe lograr un trabajo de calidad.
 Se debe buscar la simpleza.

16. FASES DEL MODELO XP
 Los equipos de desarrollo trabajan
directamente con el cliente
durante interacción con el usuario.
ciclos cortos de una o dos semanas
como máximo.
 La entrega de las versiones del
software ocurre muy temprano y
en intervalos muy cortos para
maximizar la
 Existe una fuerte colaboración
entre el equipo de desarrollo
mientras trabaja en el código.
 El código se prueba y depura a lo
largo del proceso de desarrollo.
 Existen indicadores que miden el
progreso del proyecto para poder
actualizar el plan de desarrollo.

17. La metodología XP define cuatro
variables para cualquier proyecto
de software: costo, tiempo, calidad y
alcance.
Además, se especifica que, de
estas cuatro variables, sólo tres de
ellas podrán ser fijadas
arbitrariamente por actores
externos al grupo de
desarrolladores (clientes y jefes de
proyecto).
El valor de la variable restante
podrá ser establecido por el equipo
de desarrollo, en función de los
valores de las otras tres.