Transcript MODELOS DEL CICLO DE VIDA DESARROLLO DE PROYECTOS DE SOFTWARE ING. VERÓNICA RINCÓN.

MODELOS DEL CICLO DE
VIDA
DESARROLLO DE PROYECTOS DE SOFTWARE
ING. VERÓNICA RINCÓN
MODELO
DETERMINA EL ORDEN DE LAS ETAPAS A
TRAVÉS DE LAS CUALES SE DESARROLLO
UN PROYECTO DE SOFTWARE
Cascada
(Pequeños
proyectos – poco
se utiliza)
se debe completar un
paso correctamente
sin ningún error para
pasar al siguiente.
Fácil Explicación
Intuitivo
Tradicional
Paso a Paso
Mucha demora en la
entrega
Versión disponible del
producto al finalizar
Espiral
(Proyectos
grandes)
Ciclos repetitivos
hasta concluir el
proyecto
Análisis de riesgos
Comprensión clientedesarrollador
Mucho tiempo de
desarrollo
Muy complejo
Costoso
Incremental
(software modular
o pequeño)
Interactivo entregado
un producto
terminado por cada
incremento
Reduce tiempo
Entregas Parciales
Susceptible a cambios
Mucha planeación
administrativa y
financiera
Necesita metas
claras
Evolutivo
(Generación de
aplicaciones)
Creación de versiones Retroalimentación
de un producto
Mejoras a cada versión
Costoso
Herramientas y
técnicas actuales
Estructura deficiente
Concurrente
(Todo tipo de
proyectos)
Interacción del grupo
de trabajo en todo el
proyecto
Grupos de trabajo
estables
Reduce tiempo
Reduce Costos
Eleva la productividad
Alta calidad
MODELO CASCADA
MODELO EN ESPIRAL
MODELO INCREMENTAL
MODELO EVOLUTIVO
MODELO CONCURRENTE
MODELO EN V – VERIFICACION Y
VALIDACION
VENTAJAS:
• LA RELACIÓN ENTRE LAS ETAPAS DE DESARROLLO Y LOS DISTINTOS TIPOS
DE PRUEBAS FACILITAN LA LOCALIZACIÓN DE FALLOS.
• ES UN MODELO SENCILLO Y DE FÁCIL APRENDIZAJE
• HACE EXPLÍCITO PARTE DE LA ITERACIÓN Y TRABAJO QUE HAY QUE REVISAR
• ESPECIFICA BIEN LOS ROLES DE LOS DISTINTOS TIPOS DE PRUEBAS A
REALIZAR
• INVOLUCRA AL USUARIO EN LAS PRUEBAS
DESVENTAJAS:
• ES DIFÍCIL QUE EL CLIENTE EXPONGA EXPLÍCITAMENTE TODOS LOS
REQUISITOS
• EL CLIENTE DEBE TENER PACIENCIA PUES OBTENDRÁ EL PRODUCTO AL FINAL
DEL CICLO DE VIDA
• LAS PRUEBAS PUEDEN SER CARAS Y, A VECES, NO LO SUFICIENTEMENTE
EFECTIVAS
• EL PRODUCTO FINAL OBTENIDO PUEDE QUE NO REFLEJE TODOS LOS
REQUISITOS DEL USUARIO
PROTOTIPOS
VENTAJAS
• ES ÚTIL CUANDO EL CLIENTE CONOCE LOS OBJETIVOS GENERALES
PARA EL SOFTWARE, PERO NO IDENTIFICA LOS REQUISITOS
DETALLADOS DE ENTRADA, PROCESAMIENTO O SALIDA.
• OFRECE UN MEJOR ENFOQUE CUANDO EL RESPONSABLE DEL
DESARROLLO DEL SOFTWARE ESTÁ INSEGURO DE LA EFICACIA DE UN
ALGORITMO, DE LA ADAPTABILIDAD DE UN SISTEMA OPERATIVO O DE
LA FORMA QUE DEBERÍA TOMAR LA INTERACCIÓN HUMANOMÁQUINA.
METODOLOGÍAS
• LA METODOLOGÍA INDICA CÓMO HAY QUE OBTENER LOS DISTINTOS
PRODUCTOS PARCIALES Y FINALES.
• UNA METODOLOGÍA PUEDE SEGUIR UNO O VARIOS MODELOS DE CICLO
DE VIDA
• MODELOS DE CALIDAD DEL SOFTWARE
• DEFINEN ARTEFACTOS, ROLES Y ACTIVIDADES
ELEMENTOS DE LA METODOLOGÍA
• FASES: TAREAS A REALIZAR EN CADA FASE
• PRODUCTOS: E/S DE CADA FASE, DOCUMENTOS
• PROCEDIMIENTOS Y HERRAMIENTAS: REALIZACIÓN DE CADA TAREA
• CRITERIOS DE EVALUACIÓN: DE PROCESO Y DE PRODUCTO
METODOLOGÍA TRADICIONAL VS
METODOLOGÍA ÁGIL
• TRADICIONAL: CENTRAN SU ATENCIÓN EN LLEVAR UNA
DOCUMENTACIÓN EXHAUSTIVA DE TODO EL PROYECTO. ALTOS
COSTOS AL IMPLEMENTAR UN CAMBIO.
• ÁGIL: TRABAJO EN GRUPO O EQUIPO DE DESARROLLO, CENTRA EN
DESARROLLO DE SOFTWARE, COLABORACIÓN CON EL CLIENTE Y
RESPONDER A LOS CAMBIOS.
Metodología Ágil
Metodología Tradicional
Pocos Artefactos. El modelado es prescindible, Más Artefactos. El modelado es esencial,
modelos desechables.
mantenimiento de modelos
Pocos Roles, más genéricos y flexibles
Más Roles, más específicos
No existe un contrato tradicional, debe ser
bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de
(además in-situ)
desarrollo mediante reuniones
Orientada a proyectos pequeños. Corta
Aplicables a proyectos de cualquier tamaño,
duración (o entregas frecuentes), equipos
pero suelen ser especialmente
pequeños (< 10 integrantes) y trabajando en efectivas/usadas en proyectos grandes y con
el mismo sitio
equipos posiblemente dispersos
La arquitectura se va definiendo y mejorando Se promueve que la arquitectura se defina
a lo largo del proyecto
tempranamente en el proyecto
Énfasis en los aspectos humanos: el individuo Énfasis en la definición del proceso: roles,
y el trabajo en equipo
actividades y artefactos
Basadas en heurísticas provenientes de
prácticas de producción de código
Basadas en normas provenientes de
estándares seguidos por el entorno de
desarrollo
Se esperan cambios durante el proyecto
Se espera que no ocurran cambios de gran
impacto durante el proyecto
Modelo de
Proceso
Tamaño
del
Proceso
Tamaño
del
Equipo
Complejid
ad del
Problema
RUP
Medio /
Extenso
Medio /
Extenso
Medio /
Alto
ICONIX
Pequeño /
Medio
Pequeño /
Medio
Pequeño /
Medio
XP
Pequeño /
Medio
Pequeño
Medio /
Alto
SCRUM
Pequeño /
Medio
Pequeño
Medio /
Alto
METODOLOGÍAS TRADICIONALES
• RUP (RATIONAL UNIFIED PROCCES)
• MSF (MICROSOF SOLUTION PROCCES)
• WIN-WIN SPIRAL MODEL
• ICONIX
METODOLOGÍAS ÁGILES
• RAPID APPLICATION DEVELOPMENT (RAD)
• SCRUM
• EXTREME PROGRAMMING (XP)
• PROCESO ÁGIL UNIFICADO (AUP)
• CRYSTAL_CLEAR
• (ASD) ADAPTATIVE SOFTWARE DEVELOPMENT