c03-Procesos de Ingeniería de Software y su relación con UML

IS, Procesos de Software y
UML en el Contexto de
ADOO
Análisis y Diseño OO, 20092009-1
Luis Carlos Díaz, Angela Carrillo,
Deicy Alvarado y M. Consuelo
Franky
Introducción a los procesos de
desarrollo de software
Ingeniería de Software
Personas
Tecnología
Producto
Proceso
El ciclo de vida del Software
Tiempo …
Ciclos desde su nacimiento hasta su muerte
Nacimiento
Muerte
Problemas en el desarrollo
El dominio de la aplicación no es conocido
Falta de comunicación con el usuario
Falta de comunicación del grupo de desarrollo
Carencia de una buena documentación
Falta de planeación
Sobrecostos
Demoras y cancelación de proyectos
Mala calidad del producto
No cumplimiento de las necesidades del “Negocio”
Ejemplo: Los Costos!
¿Cómo solucionar estos problemas y
suplir los retos del desarrollo de software?
… Tarea de la Ingeniería de Software!
Apuesta: Si el proceso es de calidad
Apuesta:
El producto resultante de ese proceso es de calidad!!!
Sobre el Proceso
Construcción
Desarrollo
Mantenimiento del Software
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
Requisitos nuevos
o modificados
Modelos del Ciclo de Vida
Diente de Sierra
Cascada
Espiral
Diente Tiburón
En “V”
Proceso General
Resumen de los principales procesos
de desarrollo de software:
ADMINISTRACIÓN DEL PROYECTO
Inicio, Supervisión, Control, Calidad
PRE- DESARROLLO
Exploración
Asignación del sistema
DESARROLLO
Requerimientos
Análisis
Diseño
Implementación
Pruebas
POS- DESARROLLO
Instalación
Operación & Soporte
Mantenimiento
Retiro
PROCESOS INTEGRALES
Verificación, Validación, Adm. de configuraciones, Documentación, Entrenamiento
Clasificación de procesos de
desarrollo de software
Varias alternativas de procesos
trabajando con UML
UML es un estándar de lenguaje de
modelaje pero no hay estándar de proceso
de desarrollo de software
Dos categorías de procesos:
Cascada (tradicional): divide un proyecto en
actividades secuenciales que constituyen el ciclo
de vida del software
análisis de requerimientos, diseño, codificación, pruebas
Iterativo (recomendado): divide un proyecto en
subconjuntos de funcionalidad llamadas
iteraciones
en cada iteración se aplican todas las etapas del ciclo de vida
del software a ese subconjunto de funcionalidad
Proceso en cascada
Problemas:
cuando hay que devolverse a una actividad anterior se
replantean todas las actividades afectando el cronograma
es muy riesgoso dejar las todas las pruebas para el final
del proyecto
A pesar de sus problemas, la mayoría de los
proyectos siguen el proceso de cascada
Proceso iterativo
No todo se puede dividir en iteraciones:
Características de las iteraciones:
para poder partir en iteraciones, antes deben tener claros todos
los requerimientos (debería ser un proyecto aparte)
el entrenamiento de los usuarios se deja para después de las
iteraciones
cada iteración debería entrar en operación para obtener
retroalimentación de los usuarios
todas las iteraciones debería ser de la misma duración (3 a 4
semanas): asegura entregas regulares
Modificación frecuente del código realizado
en interaciones pasadas, apoyándose en:
mediante pruebas automáticas se detectan defectos a corregir
refactory: mover o transformar el código
integración continua
Variedades del proceso iterativo:
incremental, espiral, evolucionario, jacuzzi, …
Proceso híbrido "entrega por escalones"
(staged delivery)
Aplica cascada para hacer inicialmente y secuencialmente:
análisis, diseño global
Aplica iteraciones para realizar : codificación y pruebas
Planeación predictiva o adaptativa
Planeación predictiva (usada en proceso en
cascada):
etapa inicial de análisis de requerimientos debería dar el
entendimiento de todo el proyecto que se quiere hacer => estimar
de formar más precisa las demás etapas
permitiría hacer contrato de precio fijo por un alcance fijo
realidad: los requerimientos no se pueden congelar y cambian
aún en las etapas finales.
Planeación adaptativa (usada en proceso
iterativo):
se admite que el cambio es inevitable a lo largo del proyecto
hay planeación permanente (por ejemplo replanteando los
requerimientos en cada iteración)
el contrato es generalmente de precio fijo / alcance variable
Ejemplos más conocidos de
procesos de desarrollo de
software iterativos
RUP: Rational Unified Process
Fases en RUP
Inception
Elaboration
Objetivos
(Vision)
Tiempo …
Construction
Arquitectura
Transition
Capacidad
Operacional
Inicial
Release
del Producto
Fases en RUP
Incepción o Inicio: visión aproximada del producto
final con base en las características del negocio
Elaboración: Visión refinada (inventario de casos
de uso), construcción en iteraciones del núcleo
central, resolución de riesgos altos
Construcción: implantación del sistema en
iteraciones (casos de uso), implementación de
requerimientos de menor riesgo
Transición: Despliegue del producto,
entrenamiento de usuarios
Fases e Iteraciones en RUP
Alcance y
Objetivos
Fases:
Incepción
Iteraciones:
Arquitectura
Elaboración
Iteración
1
Versión Beta
Versión Final
Construcción
Iteración
2
Iteración
3
Transición
Iteración
4
Modelado del Negocio
Entregas
internas
(Versiones)
Requerimientos
Disciplinas:
Análisis y Diseño
Implementación
Pruebas (Fiabilidad,
Funcionalidad, Rendimiento)
Las Iteraciones en RUP
En cada fase
Análisis de Requerimientos
Diseño
Implementación
Pruebas
Se busca un refinamiento sucesivo
del sistema
Longitud máxima: 2 a 6 semanas
Fijar iteraciones cortas y adaptables
Características Generales de RUP
Dirigido por Casos de Uso
Centrado en la Arquitectura
Iterativo e Incremental
Otros
Desarrollo basado en componentes
UML como lenguaje de Modelado
Proceso Integrado
Procesos Agiles
Son procesos fuertemente adaptativos
Son orientados a las personas:
el factor más importante de éxito en un proyecto es la
calidad de la gente que participa en él (las herramientas y
metodologías son secundarias)
Usan iteraciones cortas de un mes o menos
Construyen pocos diagramas y documentos
UML: lo usan más en modo bosquejo
“Agile Manifesto” (Febrero’2001)
VALORES:
Las personas y su interacción son más
importantes que los procesos y las
herramientas
Es mas importante el software
funcionando que la documentación
excesiva
Es mejor crear un ambiente de
colaboración y confianza
cliente↔
↔desarrollador que refinar el
contrato para prever todos los casos
Es preferible responder al cambio que
seguir un plan
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
24
¿Qué es “Extreme Programming” ?
XP es un modelo de proceso ágil, que se concentra
en la producción disciplinada de código.
XP es una disciplina de desarrollo ágil de software
basada en simplicidad, comunicación,
realimentación y coraje, que organiza al grupo de
desarrollo en torno a 12 prácticas concretas, las
cuales permiten
saber cómo va el proyecto
afinar las prácticas a la situación particular.
25
Los 4 Valores de XP
Comunicación
Simplicidad
Realimentación
Coraje
26
Las 12 prácticas de XP
Entregas frecuentes y
pequeñas
Planear el desarrollo a
Propiedad corporativa del
código
“corto” plazo
Pruebas automáticas
permanentes
Diseños simples
Refactoring
Integración permanente
El cliente al lado
Estandarización del
40 horas de trabajo
código
Metáfora (lenguaje común)
Programación por pares
27
Contrato 2
Propuesta 2
Contrato 1
Propuesta 1
Experiencia CincoSOFT: Proceso visible con entregas
frecuentes => Entregables (RUP “light”) + ...
Construcción
por módulos
Elaboración
Doc. Arquitectura
e Integración
1
2
Refinar
Casos de Uso
Especificación
Formal (Z)
Refinar Modelo
de Datos
3
4
Programación
Inserción
...
Pruebas
Transición
Manuales:
Usuario
Administración
Ajustes
Inventario de
Casos de Uso
Documentación de
Casos de Uso
y de Base de Datos
Código documentado
y Manual Usuario
28
Experiencia CincoSOFT: RUP light
+ Extreme Programming +...
Construction
Inception
Elaboration
1
2
3
4
...
Transición
Programación “+ - por pares”
Diseñar las
pantallas de los
Casos Uso
Unit Testing
Aprobación
del
usuario
Documentar
Aspectos
Técnicos
Refinar las
tablas
involucradas en
el Caso de Uso
Integration Testing
Functional Testing
Stress Testing
Extreme Programming
29
1
2
3
Generación de
nuevos WebServices
Generación de
nuevos EJBs
Elaboration
Generación de un
nuevo módulo
Generación del
Sistema inicial:
Seguridad
Menus
Control
Librerias básicas
Inception
4
Experiencia
CincoSOFT: RUP light
+ Extreme
Programming
+ Framework
...
Transición
Programación “+- por pares”
Diseñar las
pantallas de los
Casos Uso
Unit Testing
Aprobación
del
usuario
Generación de código
de control, esqueleto y
y descriptores
del nuevo Caso de Uso
Refinar las
tablas
involucradas en
el Caso de Uso
Integration Testing
Functional Testing
Stress Testing
Extreme Programming
30
Ventajas de los procesos iterativos
(RUP, procesos ágiles)
Mitigación temprana de posibles riesgos
altos
Progreso visible en las primeras etapas
Temprana retroalimentación que se ajuste
a las necesidades reales
Gestión de la complejidad
Conocimiento adquirido en una iteración
puede aplicarse de iteración a iteración
Buenas prácticas
Abordar las cuestiones de alto riesgo y
valor en las primeras iteraciones
Usuarios involucrados continuamente
Verificar continuamente la calidad desde
el principio y con frecuencia
Aplicar casos de uso
Modelar el Software visualmente
Gestión cuidadosa de requisitos
Control de cambios
Diagramas UML utilizados en las
distintas etapas del ciclo de vida
de un proyecto de software
Etapa: Análisis de requerimientos
Objetivo: determinar qué quieren los
usuarios que haga el sistema
Diagramas UML útiles para la comunicación
con los usuarios:
Casos de usos:
usos: describe como los actores interactúan con
el sistema
Diagrama de clases de entidades de negocio (bosquejo):
establece vocabulario del dominio
Diagrama de actividades:
actividades: muestra el flujo de trabajo de la
organización (contexto de los casos de uso)
Diagrama de estados:
estados: para ilustrar entidades con un ciclo
de vida complejo con multiples estados y transiciones
Etapa: Diseño
Objetivo: determinar completamente todos
los elementos del sistema que deben
programarse
Diagramas UML útiles para la comunicación
con los programadores :
Diagrama de clases de los diferentes objetos del sistema
Diagrama de paquetes:
paquetes: muestra agrupamiento de clases
en módulos del sistema
Diagramas de secuencia de escenarios interesantes
(ilustrando acciones en el tiempo para algunos casos de
uso)
Diagrama de estados:
estados: para ilustrar clases de objetos de
vida complejo con multiples estados y transiciones
Diagramas de despliegue:
despliegue: para ilustrar los elementos
físicos en donde va a operar el software
Etapa: Documentación
Objetivo: dejar historia de cómo se construyó el
sistema
Deben ser diagramas globales de todo el sistema (la
documentación detallada se genera a partir del
código)
Diagramas UML útiles para la documentación global:
Diagrama de paquetes:
paquetes: muestra agrupamiento de clases en
módulos del sistema
Diagramas de despliegue:
despliegue: para ilustrar los elementos físicos
en donde va a operar el software
Diagrama de clases importantes
Opcionalmente:
diagramas de interacción entre clases importantes
diagrama de estados para clases complejas
diagramas de actividad