Upload
christian-sifaqui
View
1.045
Download
1
Embed Size (px)
Citation preview
Metodologías de Análisis
Clase 4 – 29/8/2007
Christian Sifaqui
Modelos de ciclos de vida
Modelo de ciclo de vida (o modelo del proceso)
El desarrollo de software, las actividades operativas y su ordenamiento temporal
- requerimientos
- especificación
- diseño
- implementación
- integración
- mantención
- retiro
Proceso
Un proceso define QUIÉN hace QUÉ, CUÁNDO y CÓMO en el desarrollo de un sistema de software
- roles y workflows
- productos
- hitos
- guías
- etc.
Requerimientos
nuevos o cambiados
Sistema nuevo
o cambiado
Proceso deingeniería de software
Proceso vs. Producto
Participantes
Resultado
HerramientasModelo del
proceso
ProyectoPersonas
Producto
Automatización
Template
Proceso
Herramientasy equipamiento
Personas conhabilidades,
entrenamientoy motivación
Proceso
Procedimientos y métodosque definen las
relaciones de las tareas
Proceso efectivo
- Provee guías para desarrollo eficiente de software de calidad
- Reduce riesgo e incrementa predictibilidad
- Captura y presenta “best practices”
- Promueve una visión común y cultura
- Provee un mapa para usar herramientas
- Entrega información en línea
Procesos livianos vs. pesados
Pesados
(por ejemplo, Proceso-V)
Ágiles, livianos
(por ejemplo, programación
extrema XP)
Framework customizable
(por ejemplo, RUP)
Orientado al documento
Elabora definiciones de workflow
Muchos roles diferentes
Muchos chequeos
Sobrecarga alta de administración
Altamente burocrático
Enfocado al código en vez que a la documentación
Enfocado en comunicación directa (entre desarrolladores y desarrolladores y los clientes)
Baja sobrecarga de administración
Elección de proceso
- El proceso usado debería depender del tipo de producto que se desarrollará
para sistemas grandes, la administración es usualmente el principal problema, por lo que se necesita un proceso administrado estrictamente. Para sistemas pequeños, se permite mayor informalidad
- Se podría incurrir en costos altos si se fuerza un proceso inapropiado a un equipo de desarrollo
Otros ciclos de vida
Codificar-y-arreglar
Cascada
Prototipo rápido
Programación extrema y procesos ágiles
Sincronizar-y-estabilizar
Espiral
Híbrido
Codificar-y-arreglar
- sin diseño
- sin
especificaciones
¿mantención?
Implementar laprimera versión
Modificar hasta queel cliente quede
satisfecho
Mantención post-entrega
Retiro
DesarrolloMantención
Codificar-y-arreglar
la manera más fácil de desarrollar software
de la forma más cara
Cascada
Requerimientos
Análisis
Diseño
Implementación
Mantenciónpost-entrega
Requerimientoscambiados
RetiroDesarrolloMantención
Cascada
Caracterizada por:
ciclos de retroalimentación
guiado por documentación
Ventajas
documentación
mantención es más fácil
Desventajas
documento de especificación
Prototipo rápido
- modelo lineal
- “rápido”
Prototipo rápido
Análisis
Diseño
Implementación
Mantenciónpost-entrega
Requerimientoscambiados
RetiroDesarrolloMantención
Open-source
Dos fases informales
Primera fase: una persona construye una versión inicial
que publica vía Internet (por ejemplo, SourceForge.net)
Si hay suficiente interés en el proyecto:
- se baja masivamente la versión inicial
- usuarios se convierten en co-desarrolladores
- el producto se extiende
OBS: los individuos trabajan por lo general en forma voluntaria en sus tiempos libres
Open-source
Segunda fase:Se reportan y corrigen defectos (mantención correctiva)Se agrega funcionalidad adicional (mantención perfectiva)Se porta el programa a nuevos ambientes (mantención adaptativa)
La segunda fase informal consiste solamente de mantención post-entrega
Open-source
Modelo de mantención post-entrega
Implementar laprimera versión
Mantención post-entregacorrectiva, perfectiva y adaptativa
RetiroDesarrolloMantención
Open-source
Software cerrado se mantiene y testea por empleados de la organización
Open-source generalmente es mantenido por voluntarios
OBS: Linus’s Law
complejidad ciclomática de McCabe
Open-source
Grupo core:
- pequeño número de mantenedores dedicados
responsables de administrar el proyecto
- tienen la autoridad de instalar parches
Grupo periférico:
usuarios que deciden enviar reportes de errores de vez en cuando
Open-source
Nuevas versiones de software propietario se entregan, por lo general, una vez al año, después de una revisión del grupo SQA
El grupo core libera una nueva versión del producto open-source tan pronto como esté lista:
- quizás un mes o días después de la versión anterior- el grupo core hace test mínimos- el testing extenso lo realiza el grupo periférico
usando el software- “release early and often”
Open-source
Una versión inicial se produce al usar:
- el modelo de “prototipo rápido”
- el modelo “codificar-y-arreglar”
- el modelo “Open-source”
Y después:
- modelo de “prototipo rápido”
la versión inicial se descarta
-modelo “codificar-y-arreglar” y “Open-source”
la versión inicial se convierte en el producto
Open-source
Por lo tanto en un proyecto open-source, por lo general no hay especificación ni diseño
¿Cómo estos proyectos open-source han sido tan exitosos al no tener especificación ni diseño?
Open-source
La producción de software open-source ha atraído a algunos de los mejores expertos de software en el mundo
(ellos pueden funcionar efectivamente sin especificación ni diseño)
Sin embargo, se podría llegar a un punto en que el proyecto open-source no sea mantenible
Open-source
el modelo open-source tiene sus restricciones
pero ha sido extremadamente exitoso para proyectos de infraestructura:
- sistemas operativos (GNU/Linux, OpenBSD, Mach, Darwin)
- navegadores (Firefox, Netscape)
- compiladores (gcc)
- servidores web (apache, zope)
- administradores de bases de datos (MySQL, PostgreSQL)
Open-source
no puede haber desarrollo open-source de un producto de software para ser usado en una sola organización
(los miembros del grupo core y periférico son los usuarios del software que se desarrolla)
el modelo open-source es inaplicable a menos que el producto sea visto por un gran número de usuarios como útil
Open-source
al menos la mitad de los proyectos open-source disponibles no han atraído a un equipo para trabajar en éste
incluso si el trabajo se inicia, puede que no se complete el trabajo
pero donde el modelo open-source ha funcionado, ha mostrado ser extremadamente exitoso
(los proyectos mencionados anteriormente son usados por millones de usuarios)
Procesos ágiles
una nueva aproximación controversial
historias (muestra lo que quiere el cliente)
- estimar duración y costo de cada historia
- elegir historia para la siguiente construcción
- cada construcción se divide en tareas
- casos de test para una tarea se diseñan primero
Programar de a par
Integración continua de tareas
Procesos ágiles
“Programación extrema (XP)”los computadores se ponen al centro de una oficina larga alineada con cubículos
un representante del cliente está siempre presente
profesionales del software no pueden hacer horas extras más de dos semanas consecutivas
no hay especialización
refactoring (modificación al diseño)
Procesos ágiles
“Programación extrema (XP)”
YAGNI (you aren’t gonne need it)
DTSTTCPW (do the simplest thing that could possibly work)
un principio de XP es minimizar el número de características
(no hay necesidad de construir un producto que hace más que lo que el cliente necesita)
Procesos ágiles
“Programación extrema (XP)”
XP es sólo una de un nuevo conjunto de paradigmas llamados procesos ágiles
en febrero de 2001 se redactó el manifesto for Agile Software Development
la Agile Alliance no receta un modelo de ciclo de vida específico
(sólo expone un grupo de principios subyacentes)
Procesos ágiles
Los procesos ágiles son una colección de nuevos paradigmas caracterizados por:
- menor énfasis en análisis y diseño
- implementaciones tempranas (el software funcionando es considerado más importante que la documentación)
- proactivo al cambio
- colaboración cercana con el cliente
Procesos ágiles
un principio del Manifesto es
- entregue software frecuentemente
- idealmente cada 2 ó 3 semanas
una manera de lograr esto es usar timeboxing
(usado por muchos años como una técnica de administración del tiempo)
se asigna una cantidad específica de tiempo a una tarea:
- típicamente 3 semanas para cada iteración
- los miembros del equipo hacen su mejor trabajo durante ese tiempo
Procesos ágiles
entrega al cliente la confianza de saber que una nueva versión con funcionalidad llegará cada 3 semanas
los desarrolladores saben que tendrán 3 semanas (y no más) para entregar una nueva iteración
(sin interferencia del cliente)
si es imposible entregar la tarea completa en el tiempo, el trabajo podría ser reducido (descoped)
(procesos ágiles demandan tiempo fijo, no características fijas)
Procesos ágiles
otro rasgo común de los procesos son las reuniones de pie
- reuniones cortas que se efectúan a una hora cada día
- se requiere asistencia
los participantes están en un círculo- no se sientan en una mesa- para asegurar que la reunión no dure más
de 15 minutos
Procesos ágiles
En una reunión de pie, cada miembro del equipo se turna para responder 5 preguntas
¿Qué hice desde la reunión de ayer?
¿En qué estoy trabajando hoy?
¿Qué problemas tengo para alcanzar esto?
¿Qué hemos olvidado?
¿Qué aprendí que podría compartir con el equipo?
Procesos ágiles
el objetivo de una reunión de pie es:
- detectar problemas
- no de resolverlos
las soluciones se encuentra en reuniones de continuación, que se efectúan directamente después de la reunión de pie
Procesos ágiles
procesos ágiles han tenido algún éxito en desarrollo de software a pequeña escala:
(sin embargo, desarrollo de software mediano y grande es muy diferente)
la clave: el impacto de los procesos ágiles en mantención post-entrega:
- refactoring es una componente esencial en procesos ágiles
- refactoring continúa durante la mantención
- ¿incrementa el refactoring el costo de post-mantención, como lo indica la investigación preliminar?
Procesos ágiles
procesos ágiles son buenos cuando los requerimientos son vagos o cambiantes
es muy pronto para evaluar procesos ágiles:
(no hay suficientes datos)
incluso si los procesos ágiles fueran decepcionantes
(algunas características –como la programación de a pares- podría ser adoptada por prácticas comunes de ingeniería de software)
Procesos ágiles
Redactar tests
Planificación
Test
Programación de a par+ Refactoring
IntegraciónMínimodiariamente
cada 2-3semanas
Release
Sincronizar-y-estabilizar
modelo de ciclo de vida de Microsoft
análisis de requerimientos – entrevistar clientes potenciales
redactar especificaciones
dividir el proyecto en 3 ó 4 construcciones
cada construcción se lleva a cabo por pequeños equipos trabajando en paralelo
Sincronizar-y-estabilizar
al final del día – sincronizar (test y debug)
al final de la construcción – estabilizar (congelar la construcción)
componentes siempre trabajan juntos
(se obtienen vistas tempranas de la operación de producto)
Espiral
Espiral
si no se pueden mitigar todos los riesgos, el proyecto se termina inmediatamente
Espiral
preceder cada fase con:
- alternativas
- análisis de riesgo
continuar cada fase con:
- evaluación
- planificación de la siguiente fase
dimensión radial: costo acumulado a la fecha
dimensión angular: progreso a través de la espiral
Espiral
Fortalezas:
- es fácil decidir cuánto testear
- no hay distinción entre desarrollo y mantención
Debilidades:
- sólo para software de gran escala
- sólo para software interno (in-house)
Modelos de ciclos de vida
Criterios para decidir por un modelo:
- la organización
- su administración
- las habilidades de los empleados
- la naturaleza del producto
Híbrido
Probar mezclar modelos
- Sistemas grandes están hechos de algunos sub-sistemas
- El mismo modelo no necesita ser aplicado en todos los sub-sistemas
- Prototipado para especificaciones altamente riesgosas
- Modelo cascada para desarrollos claros
- Adaptar el proceso al problema
Otros
- RUP
- V-Modell XT
- …
Adicionalmente
- PSP (Personal Software Process)
- TSP (Team Software Process)
Finalmente
- CMMI
- Model IDEAL
Modelos de ciclos de vida
Guiada por documentos
Producto entregado podrían no satisfacer las necesidades del cliente
Aproximación disciplinadaCascada
Insatisfactorio para programas no triviales
Bueno para pequeños programas que no requieren mantención
Codificar-y-arreglar
Subyacente al proceso unificado
Modela cercanamente la producción de software del mundo real
Iterativo-e-incremental
Equivalente al modelo iterativo-e-incremental
Modela cercanamente la producción de software del mundo real
Árbol de evolución
DebilidadesFortalezasModelo de ciclo de vida
Modelos de ciclos de vida
No ha sido probado fielmenteAsegura que el producto entregado concuerda con las necesidades del cliente
Prototipo rápido
Desarrolladores deben ser competentes en análisis de riegos y evolución del riesgo
Puede ser usado sólo en producto internos de gran escala
Orientada al riesgoEspiral
Asegura que las componentes se puedan integrar exitosamente
No ha usado en otra parte distinta a Microsoft
Necesidades futuras de los usuarios se satisfacen
Sincronizar-y-estabilizar
Parece funcionar sólo en proyectos de pequeña escala
Funciona bien si los requerimientos del cliente son vagos
Procesos ágiles
Usualmente no funciona
Aplicación limitadaHa funcionado muy bien en un pequeño número de instancias
Open-source
DebilidadesFortalezasModelo de ciclo de vida