Riesgos, Procesos y Métodos Ágiles de Software

1. Riesgos, Procesos y Métodos Ágiles de Software Marcello Visconti

2. ¿Ingeniería? de Software

3. Ingeniería de Software Establecimiento y uso de principios con caracteres de ingeniería apropiados para obtener, eficientemente, software confiable, que opere eficaz y eficientemente en máquinas reales Concepto se acuñó en 1968, en Conferencia de la OTAN en Alemania, con la intención de que mediante el uso de filosofías y paradigmas de disciplinas ingenieriles establecidas se resolviera la denominada crisis del software

4. Ingeniería de Software • Objetivos • maximizar calidad • maximizar productividad • minimizar riesgos

5. Ingeniería de Software • Implicancias • constructores básicos más poderosos • mejores técnicas de control de calidad • mejores herramientas y métodos • todo en la forma de procesos de software adecuados al tipo de problema que se resuelve y que permitan gestionar de mejor manera los principales riesgos relevantes para todos los stakeholders (involucrados o afectados)

6. Dificultades en Producción de Software • Esencia • complejidad • conformidad • necesidad de cambios • invisibilidad • Accidentes • avances de investigación • no silver bullet? (Brooks, 1986)

7. Proceso de Software • Proveer un producto o un servicio, siempre consiste en seguir una secuencia de pasos, para llevar a cabo un conjunto de tareas. • Las tareas se ejecutan usualmente en el mismo orden todas las veces. • Un proceso es una serie de pasos que involucran actividades, restricciones y recursos, que producen una salida esperada, de algún tipo. • Un proceso involucra usualmente un conjunto de herramientas y técnicas.

8. Proceso de Software • Es importante, pues impone consistencia y estructura al conjunto de actividades. • Es más que un procedimiento, es un conjunto organizado de éstos. • La estructura del proceso guía la acción, permitiendo examinar, entender, controlar y mejorar las actividades comprendidas por éste. • También es importante pues permite capturar y transmitir la experiencia, a proyectos futuros. • Cada proceso puede ser descrito por una combinación de diferentes medios.

9. Modelos de Proceso de Software • En la Ingeniería de Software se describen muchos Modelos de Proceso. • Unos son prescriptivos: establecen la forma en que debería progresar el proceso de software. • Otros son descriptivos: dicen la forma en que el proceso de software progresa en la realidad.

10. Modelos de Proceso de Software • Razones para modelar un proceso: • Conforma un entendimiento común de las actividades, recursos y restricciones involucrados. • Ayuda a encontrar inconsistencias, redundancias y omisiones del proceso y sus partes. • Refleja las metas del desarrollo. El equipo puede evaluar la forma de alcanzar las metas. • El proceso puede ser modificado a la medida de la situación en que será usado.

11. Algunos Modelos de Proceso de Software • Modelo en Cascada. • Modelo en V. • Modelo de Prototipación. • Modelo de Desarrollo en Fases. • Modelo en Espiral. • RUP. • Métodos Ágiles.

12. Modelo en Cascada [1] • Es el más antiguo. • Debe completarse un estado antes de comenzar el siguiente. • Es útil para que el desarrollador visualice lo que va a hacer. • Su principal problema es que no refleja la realidad.

13. Modelo en Cascada [2] En la práctica

14. Modelo V [1] • Alemania 1992. • Variación del modelo en cascada. • El “ángulo” es la codificación. • Los sucesivos testing proceden como contraparte de las actividades de desarrollo. • Se forman “ciclos” desarrollo-verificación-desarrollo...

15. Modelo V [2]

16. Modelo de Prototipación [1] • Permite la construcción rápida del sistema (o parte de éste). • Usuario y desarrollador tienen una visión común. • Se reduce el riesgo y la incerteza del desarrollo.

17. Modelo de Prototipación [2]

18. Modelo de Desarrollo en Fases [1] • Hoy, el mercado no acepta grandes retardos. • Una forma de reducirlos es desarrollar en fases. • El sistema se diseña de manera que pueda ser entregado por partes. • Así, el usuario tiene algo de funcionalidad, mientras se desarrolla el resto. • Hay dos sistemas funcionando en paralelo: • El de Producción. Usado por el Cliente. • El de Desarrollo. La siguiente versión (release) que reemplazará a la actual de Producción.

19. Modelo de Desarrollo en Fases [2]

20. Modelo de Desarrollo en Fases [3] • Hay dos maneras básicas de organizar el desarrollo de los releases: • Incremental. El sistema se especifica y luego es particionado en subsistemas, por funcionalidad. Se comienza con un subsistema pequeño y se va agregando funcionalidad en cada nuevo release. • Iterativo. Se entrega el sistema completo el comienzo y se van haciendo cambios y mejoras en la funcionalidad, en cada nuevo release.

21. Modelo de Desarrollo en Fases [4] Desarrollo Incremental Desarrollo Iterativo

22. Modelo de Desarrollo en Fases [5] • En la realidad, las organizaciones usan generalmente una combinación de desarrollo iterativo e incremental. • Esta forma es beneficiosa porque: • El entrenamiento de los usuarios puede comenzar tempranamente, aunque falte funcionalidad. • Releases frecuentes permiten encontrar y resolver problemas, a partir de las versiones operativas. • El equipo de desarrollo puede enfocarse en diferentes áreas de expertise en cada release.

23. Modelo en Espiral [1] • Se combinan las actividades de desarrollo con Análisis de Riesgo. • El modelo es de tipo iterativo: • Planificación  Análisis de Riesgo  Ingeniería  Evaluación  Planificación  ... • En cada iteración, se evalúan las diferentes alternativas y se elige una. • Los gestores del proyecto intentan eliminar o minimizar el riesgo.

24. Modelo en Espiral [2] PLANIFICACIÓN ANÁLISIS DE RIESGO Análisis de Riesgo basado en los requerimientos iniciales Recolección de Requerimientos y Planificación del Proyecto Análisis de Riesgo (iniciales) basado en la reacción del cliente Planificación basada en los comentarios del cliente Decisión de Seguir/No Seguir Hacia el Sistema Final Evaluación Prototipo inicial del Sw del cliente Prototipo del siguiente nivel Sistema de Ingeniería EVALUACIÓN DEL INGENIERÍA CLIENTE Boehm (1986)

25. RUP – Rational Unified Process [1] • Corresponde a un framework que puede ser usado para describir procesos de desarrollo específicos • Cada ciclo de vida del software abarca 4 fases en el siguiente orden: concepción/planificación, elaboración, construcción y transición • La esencia de RUP es la iteración, y cada iteración resulta en un entregable preferentemente ejecutable

26. RUP – Rational Unified Process [2]

27. Métodos Ágiles [1] • Interés creciente en los métodos ágiles (inicialmente llamados ligeros, lightweight) en los últimos años • enfrentamiento de requerimientos cambiantes • tiempos de desarrollo escasos • clientes y usuarios cada vez más exigentes • Caracterizados alternativamente como • antídoto a la burocracia (métodos planificados, pesados, heavyweight) • hacking

28. Métodos Ágiles [2] • Algunas características de los métodos ágiles • Documentación mínima • Ciclos iterativos breves • Reacción rápida ante los cambios • Estrecha relación con el cliente • Diseño simple • Satisfacción de necesidades inmediatas • Foco en las personas • Organización libre • Procesos adaptables, no predictivos

29. The highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements, even late in development. Agile process harness change for the customer’s competitive advantage Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Business people and developers must work together daily throughout the project Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done Principios Ágiles [1]

30. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation Working software is the primary measure of progress Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely Continuous attention to technical excellence and good design enhances agility Simplicity – the art of maximizing the amount of work not done – is essential The best architectures, requirements, and designs emerge from self-organizing teams At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly Principios Ágiles [2]

31. Principales Métodos Ágiles • Extreme Programming, XP • Scrum • Crystal Family • Feature-Driven Design • Adaptive Software Development • DSDM • Otros • Open Source • RUP

32. Extreme Programming (XP) • Prácticas • On-site costumer • Whole team • Planning game • Small releases/continuous integration • Sustainable pace/40-hour week • Test-driven development • Simple design • Pair programming • Collective code ownership • Coding standards • Metaphor • Refactoring

33. Agilidad vs. Proceso • Últimamente, distintos trabajos han investigado la relación entre modelos de proceso y métodos ágiles, observando lo siguiente • CMM/CMMI y XP pueden complementarse (foco en aspectos de gestión vs. técnicos) • Métodos ágiles calzan con la esencia del mejoramiento de procesos bajo una interpretación menos literal (que CMMI, por ejemplo) • Métodos ágiles apuntan a gestión de proyectos, no a gestión de procesos

34. Dudas y Desafíos Ágiles • ¿Son los métodos ágiles (XP por ejemplo) para todos? • ¿Qué otros artefactos considerar además de código? • ¿Cuánta agilidad? ¿Cuánto proceso? • Desafío: encontrar un punto de equilibrio, un balance adecuado • Desarrollos potenciales • Modelos ágiles balanceados para migración a la práctica industrial • Mecanismos y herramientas ágiles para selección, adaptación, implantación y adopción de métodos ágiles

35. Referencias • Software Engineering: Theory and Practice (2nd Ed.) • Shari Pfleeger, Prentice Hall (2001), Cap. 1&2 • The Software-Research Crisis • Robert L. Glass, IEEE Software, Noviembre 1994 • Using Risk to Balance Agile and Plan-Driven Methods • Barry Boehm, Richard Turner, IEEE Computer, Junio 2003 • Agile Alliance • http://www.agilealliance.com/ • What is extreme programming? • http://www.xprogramming.com/