Ciclo de Ingeniería de Software

Transcripción

1 Ciclo de Ingeniería de Software Desarrollo Iterativo de Software Aplicaciones Cliente Servidor Aplicaciones OO Universidad FASTA 2008 Licencia

2 Contenido Introducción Conceptos Planificación Calidad del Software Caso real, RUP Caso real, XP Debate casos reales

3 Introducción Ingeniería de Software Establecer y usar sólidos principios de ingeniería y buenas prácticas de gestión, así como la evolución de herramientas y métodos aplicables y su uso cuando sea apropiado para obtener, con los recursos existente, software de calidad en un sentido explícitamente definido. Bauer, 1972.

4 Introducción Definición de Proceso (general) Un proceso se define como un conjunto de tareas, actividades o acciones interrelacionadas entre sí que, a partir de una o varias entradas, dan lugar a una o varias salidas (producto o servicio) con un valor agregado. Objetivo: Administrar, controlar y dar valor.

5 Introducción Definición de Proceso en IS (ciclo de vida del software) Los procesos del ciclo de vida del software son un conjunto de métodos y estándares para mejorar y manejar los procesos de desarrollo de software, y que a la vez permiten soportarlo y administrarlo a través de todo el ciclo de vida. Hay varios procesos en la IS. Adquisición, provisión, desarrollo, operación y mantenimiento

6 Introducción Definición de Proceso de Desarrollo de Software Un proceso en el contexto del desarrollo de software es entonces, el conjunto de actividades definidas explícitamente y organizadas de una determinada manera, para llevar adelante la construcción de software (producto o servicio). Se puede desarrollar software sin procesos, SI Se debe desarrollar software sin procesos, NO

7 Introducción Actividades específicas al Desarrollo de Software Análisis del dominio. Entender, investigar. Análisis del software. No debe ser incompleto, ni haber ambiguedades o contradicciones. Deploy. Especificación. Documentación. Arquitectura de software. Capacitación. Construcción. Soporte. Testing. Mantenimiento.

8 Introducción Procesos de Desarrollo de Software, hay para elegir. Cascada MDD ATAM XP Espiral FDD UP SCRUM Prototype

9 Introducción Procesos de Desarrollo de Software, hay para elegir. Cuál elegir?

10 Introducción Procesos de Desarrollo de Software, hay para elegir. Cuál elegir? Cascada MDD ATAM XP Espiral EL MAS CONVENIENTE FDD SCRUM UP Prototype

11 Introducción Procesos de desarrollo VS. Patrones de desarrollo Se incoporan los principios de patrones Claramente identificados Se aplican en diferentes contextos Reusabilidad de conocimiento y experiencias.

12 Introducción Metaprocesos ISO Aplicable a nivel ciclo de vida, no solo desarrollo CMMI-DEV v1.2 (SEI) Concentrado en el proceso de desarrollo de productos y servicios. ISO (SPICE) SixSigma DMAIC: para mejorar procesos DMADV: para crear procesos

13 Introducción Historia del IID 1970 primeras definiciones y en 1972 el primer proyecto real con el modelo IID Vic Vasili y Joe Turner primer paper Tom Gilb publicó el primer libro en el que se expone la idea del IID ( Evolutionary Project Management ) Entre 80s y 90s se desarrolló RUP. En 1988 Barry Bohem presenta un artículo donde se discute el desarrollo iterativo ( A Spiral Model of Software Development and Enhancement ). En 1999 se publica el primer libro de UP ( The Unified Software Development Process, ISBN: ) por Jacobson, Booch y Rumbaugh.

14 Introducción Problemas de la Ingeniería de Software % en tiempo y forma 52% sobrepasados 32% fallidos (U$S 81b) % en tiempo y forma 51% sobrepasados 15% fallidos Fuente: Standish Group

15 Introducción No Iterativo. Desarrollo en Cascada El desarrollo de software es un proceso complejo, contínuo y repetitivo. Este modelo no se adapta a todas ellas. El valor de negocio se obtiene muy al final del proyecto. Es la causa en el 82% de proyectos fallidos (C. Larman)

16 Introducción Mejoras con Desarrollo Ágil Fuente: VersionOne.com

17 Introducción Modelos Iterativos RUP (1999) XP (1999) ESPIRAL (1988) SCRUM (1986)

18 Introducción Hay Beneficios con IID Disminuye el time to market. Aumenta la productividad. Reduce los defectos del software. Reduce los costos. Simplicidad para modificar prioridades. Mejora la relación de IT con los objetivos de negocio. Satisfacción de los equipos de trabajo. Proyectos con menores riesgos Fuente: VersionOne y Agile Alliance

19 Conceptos Adaptable, no predictivo. Iteración Iterativo Estado de aceptación de un software Incremental Manejo de complejidad

20 Conceptos Adaptable, no predictivo. Iteración Iterativo Estado de aceptación de un software Incremental Manejo de complejidad

21 Conceptos Adaptable, no predictivo. Iteración Iterativo Estado de aceptación de un software Incremental Manejo de complejidad

22 Conceptos Adaptable, no predictivo. Iteración Iterativo Estado de aceptación de un software Incremental Manejo de complejidad

23 Conceptos Adaptable, no predictivo. Iteración Iterativo Estado de aceptación de un software Incremental Manejo de complejidad

24 Conceptos Adaptable, no predictivo. Iteración Iterativo Estado de aceptación de un software Incremental Manejo de complejidad

25 Planificación Consideraciones Implica más trabajo, pero más simple. Número de iteraciones Duración de las iteraciones Ej: Rational con 700 personas manejan iteraciones de 5 a 8 semanas. Factores Experiencia en el modelo Maduración del equipo Automatización y herramientas Bases de conocimiento Métodos de testing

26 Calidad del Software Desarrollo orientado al test Ej: JUnit Feedback temprano del usuario Diferentes test en cada iteración Desventaja, genera alto costo Calidad para el usuario Util, aprovechable, confiable, etc. Calidad para la IS Documentación, modularidad, portabilidad, seguridad, etc.

27 RUP: Proceso Unificado de Rational Basado en UP: Iterativo e incremental Dirigido por casos de uso Centrado en la arquitectura Enfocado en los riesgos

28 RUP: Proceso Unificado de Rational

29 Planificación en RUP Plan de Fase Uno por proyecto. Orientado a algunos stakeholders (PMs y externos) Vista gorda del plan general del proyecto. Centrado en hitos más relevantes. Recordar: el plan correcto no será el primero. Ajuste. Ejemplo de fechas de hitos en UP: LCO (Lifecycle Objective). Incepción. LCA (Lifecycle Architecture). Elaboración. IOC (Initial Operational Capability). Construcción. Beta. PR (Product Release). Transición. Release.

30 RUP: Proceso Unificado de Rational Tips Si el proyecto es riesgoso, o con gente nueva, nuevas herramienats y tecnologías, la fase de Elaboración deberá más larga. La duración de las iteraciones o la velocidad en la que puede iterar depende del tamaño del equipo. Cuidado con iteraciones largas, puede perder el ritmo del proyecto. Iteraciones cortas de un mes o menos son mas comunes en la fase de construcción.

31 RUP: Proceso Unificado de Rational Tips En proyectos normales puede llevar de 6 a 8 iteraciones [1, 2, 2, 1] o [1, 3, 3, 1]. Si el dominio es desconocido extienda la fase de Incepción. Si la arquitectura es un desafío incorpore de 2 a 3 iteraciones en la Elaboración. Si el desarrollo implica un período largo agregue iteraciones a la Construcción. Si no poseee experiencia empiece con 3 iteraciones.

32 Planificación en RUP Plan de Iteración Uno por iteración. Orientado a stakeholders internos. Vista fina de las tareas en cada iteración. Se establecen con un tiempo fijo dentro de cada fase. El PM siempre tiene presente una iteración activa y la próxima.

33 XP: Programación Extrema Fundado con 4 valores Comunicación Simplicidad Feedback Coraje

34 XP: Programación Extrema Fundado sobre 12 prácticas Planning game Versiones pequeñas Testeos de aceptación de usuario Diseño simple Programación de a pares Desarrollo orientado al testing TDD Refactoring Intengración contínua No hay dueños de código Estándares de codificación Metáforas 40 Hs

35 XP: Programación Extrema

36 XP: Programación Extrema

37 XP: Programación Extrema Planning Game. Plan de Release Se basa en las historias de usuario. Definido en Planning Meeting junto al cliente. Cada release incluye 80 (+ - 20) historias de usuario. El cliente establece la prioridad de cada historia de usuario. El equipo de desarrollo estima la duración de cada historia de usuario. En todo momento se aplica la velocidad del proyecto. Cada historia de usuario se traduce a tareas implementables. Cada historia de usuario se traduce en test de aceptación. Siempre que haya desvíos se vuelve a la Planning meeting. Es normal cada 3 o 5 iteraciones.

38 XP: Programación Extrema Planning Game. Plan de Iteración Iteraciones de 1 a 3 semanas de duración. 12 iteraciones aprox. por release plan. Iteraciones de duración fija. No se realiza ninguna tarea no programada para la iteración. Keep it simple. La refactorización lo soluciona. El plan de iteración se compone de las historias de usuario definidas en el pan de release, más los test de aceptación previos que fallaron. Cada tarea se estima de 1 a 3 días. El desarrollador que implementa es el que estima El desarrollador que implementa no es intercambiable.

39 XP: Programación Extrema Planning Game. Plan de Iteración Al inicio de cada iteración se realiza la iteration planning meeting. El cliente selecciona la historia de usuario y/o testeos de aceptación fallidos a incluir, teniendo en cuenta la velocidad del proyecto. Se definen las tareas a realizar. Cada programador toma la/s tareas a realizar, y estima el tiempo. Se contraponen estos tiempos con la velocidad del proyecto. Según el resultado de los tiempos el cliente puede cambiar su elección inicial.

40 XP: Programación Extrema Video 1. Planning game. Video 2. Development.

41 Debate Casos Reales

42 Recursos

43 Ciclo de Ingeniería de Software Desarrollo Iterativo de Software Aplicaciones Cliente Servidor Aplicaciones OO Universidad FASTA 2008 Licencia