clase 4, 29/8/2007

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


- sin diseño

- sin

especificaciones

¿mantención?

Implementar laprimera versión

Modificar hasta queel cliente quede

satisfecho

Mantención post-entrega

Retiro

DesarrolloMantención


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


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


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


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


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)


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


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


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


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


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

clase 4, 29/8/2007

Technology