Universidad Técnica Federico Santa MaríaDepartamento de Informática
Riesgos, Procesos y Métodos Ágiles de Software
Marcello Visconti
¿Ingeniería? de Software
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
Ingeniería de Software
Objetivos maximizar calidad maximizar productividad minimizar riesgos
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)
Dificultades en Producción de Software
Esencia complejidad conformidad necesidad de cambios invisibilidad
Accidentes avances de investigación no silver bullet? (Brooks, 1986)
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.
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.
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.
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.
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.
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.
ANÁLISIS DEREQUERIMIENTOS
DISEÑO DELSISTEMA
DISEÑO DEPROGRAMAS
CODIFICACIÓN
TESTING UNITARIOE INTEGRADO
TESTING DELSISTEMA
TESTING DEACEPTACIÓN
OPERACIÓN YMANTENCIÓN
Modelo en Cascada [2]
En la práctica
ANÁLISIS DEREQUERIMIENTOS
DISEÑO DELSISTEMA
DISEÑO DEPROGRAMAS
CODIFICACIÓN
TESTING UNITARIOE INTEGRADO
TESTING DELSISTEMA
TESTING DEACEPTACIÓN
OPERACIÓN YMANTENCIÓN
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...
Modelo V [2]
ANÁLISIS DEREQUERIMIENTOS
DISEÑO DELSISTEMA
DISEÑO DEPROGRAMAS
CODIFICACIÓN
TESTING UNITARIOE INTEGRADO
TESTING DELSISTEMA
TESTING DEACEPTACIÓN
OPERACIÓN YMANTENCIÓN
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.
Modelo de Prototipación [2]
REQUERIMIENTOSDEL PROTOTIPO
DISEÑO DELPROTOTIPO
SISTEMAPROTOTIPO
TESTING
REVISIÓN REVISIÓN REVISIÓN
REQUERIMIENTOSDEL SISTEMA
SISTEMAENTREGADO
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.
Modelo de Desarrollo en Fases [2]
DESARRO-LLADORES
CONSTRUIRVERSIÓN 1
USAR VERSIÓN1
CONSTRUIRVERSIÓN 2
USAR VERSIÓN2
CONSTRUIRVERSIÓN 3
USAR VERSIÓN3
USUARIOS
Sistemas en Desarrollo
Sistemas en Producción/Operación
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.
Modelo de Desarrollo en Fases [4]
Desarrollo Incremental
Desarrollo Iterativo
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.
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.
Modelo en Espiral [2]
Recolección deRequerimientosy Planificacióndel Proyecto(iniciales)
Planificaciónbasada en loscomentariosdel cliente
Evaluacióndel cliente
Análisis de Riesgobasado en los
requerimientosiniciales
Análisis de Riesgobasado en la
reacción del cliente
Hacia el Sistema Final
Prototipo inicial del Sw
Prototipo del siguiente nivel
Sistema de Ingeniería
INGENIERÍAEVALUACIÓN DELCLIENTE
PLANIFICACIÓN ANÁLISIS DE RIESGO
Decisión deSeguir/No Seguir
Boehm (1986)
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
RUP – Rational Unified Process [2]
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
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
Principios Ágiles [1]
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 [2]
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
Principales Métodos Ágiles
Extreme Programming, XP Scrum Crystal Family Feature-Driven Design Adaptive Software Development DSDM Otros
Open Source RUP
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
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
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
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/