Personas. Tecnología. Producto. Proceso

Transcripción

1 IS, Procesos de Software y UML en el Contexto de ADOO Análisis y Diseño OO, Luis Carlos Díaz, Angela Carrillo, Deicy Alvarado y M. Consuelo Franky

2 Introducción a los procesos de desarrollo de software

3 Ingeniería de Software Personas Tecnología Producto Proceso

4 El ciclo de vida del Software Tiempo Ciclos desde su nacimiento hasta su muerte Nacimiento Muerte

5 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

6 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 El producto resultante de ese proceso es de calidad!!!

7 Sobre el Proceso Construcción Desarrollo Mantenimiento del Software Requisitos nuevos o modificados Proceso de Desarrollo de Software Sistema nuevo o modificado

8 Modelos del Ciclo de Vida Diente de Sierra Cascada Espiral Diente Tiburón En V

9 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

10 Clasificación de procesos de desarrollo de software

11 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

12 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

13 Proceso iterativo No todo se puede dividir en 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 Características 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

14 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

15 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

16 Ejemplos más conocidos de procesos de desarrollo de software iterativos

17 RUP: Rational Unified Process

18 Fases en RUP Inception Elaboration Construction Transition Objetivos (Vision) Arquitectura Capacidad Operacional Inicial Release del Producto Tiempo

19 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

20 Fases e Iteraciones en RUP Alcance y Objetivos Arquitectura Versión Beta Versión Final Fases: Incepción Elaboración Construcción Transición Iteraciones: Iteración Iteración Iteración Iteración Disciplinas: Modelado del Negocio Requerimientos Análisis y Diseño Implementación Pruebas (Fiabilidad, Funcionalidad, Rendimiento) Entregas internas (Versiones)

21 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

22 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

23 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

24 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 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 Es preferible responder al cambio que seguir un plan 24

25 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

26 Los 4 Valores de XP Comunicación Realimentación Simplicidad Coraje 26

27 Las 12 prácticas de XP Entregas frecuentes y pequeñas Planear el desarrollo a corto plazo Diseños simples Integración permanente Estandarización del código Programación por pares Propiedad corporativa del código Pruebas automáticas permanentes Refactoring El cliente al lado 40 horas de trabajo Metáfora (lenguaje común) 27

28 Experiencia CincoSOFT: Proceso visible con entregas frecuentes => Entregables (RUP light ) +... Propuesta 1 Contrato 1 Propuesta 2 Contrato 2 Construcción por módulos Inserción Elaboración Transición Doc. Arquitectura e Integración Especificación Formal (Z) Refinar Casos de Uso Refinar Modelo de Datos Programación Pruebas Ajustes Manuales: Usuario Administración Inventario de Casos de Uso Documentación de Casos de Uso y de Base de Datos Código documentado y Manual Usuario 28

29 Experiencia CincoSOFT: RUP light + Extreme Programming +... Construction Inception Elaboration Transición Diseñar las pantallas de los Casos Uso Programación + - por pares Unit Testing Aprobación del usuario Documentar Aspectos Técnicos Integration Testing Refinar las tablas involucradas en el Caso de Uso Extreme Programming Functional Testing Stress Testing 29

30 Generación del Sistema inicial: Seguridad Menus Control Librerias básicas Generación de un nuevo módulo Generación de nuevos EJBs Generación de nuevos WebServices Experiencia CincoSOFT: RUP light + Extreme Programming + Framework Inception Elaboration Transición Diseñar las pantallas de los Casos Uso Programación +- por pares Unit Testing Aprobación del usuario Generación de código de control, esqueleto y y descriptores del nuevo Caso de Uso Integration Testing Refinar las tablas involucradas en el Caso de Uso Extreme Programming Functional Testing Stress Testing 30

31 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

32 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

33 Diagramas UML utilizados en las distintas etapas del ciclo de vida de un proyecto de software

34 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: describe como los actores interactúan con el sistema Diagrama de clases de entidades de negocio (bosquejo): establece vocabulario del dominio Diagrama de actividades: muestra el flujo de trabajo de la organización (contexto de los casos de uso) Diagrama de estados: para ilustrar entidades con un ciclo de vida complejo con multiples estados y transiciones

35 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: 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: para ilustrar clases de objetos de vida complejo con multiples estados y transiciones Diagramas de despliegue: para ilustrar los elementos físicos en donde va a operar el software

36 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: muestra agrupamiento de clases en módulos del sistema Diagramas de 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