riesgos, procesos y métodos Ágiles de software

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


Objetivos maximizar calidad maximizar productividad minimizar riesgos


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


DISEÑO DELSISTEMA

DISEÑO DEPROGRAMAS

CODIFICACIÓN


TESTING DELSISTEMA



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]


DISEÑO DELSISTEMA

DISEÑO DEPROGRAMAS

CODIFICACIÓN


TESTING DELSISTEMA



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.


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


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.


Desarrollo Incremental

Desarrollo Iterativo


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/

riesgos, procesos y métodos Ágiles de software

Documents