1

Ingeniería del Software II 2011

Tema 3. Procesos ligeros de desarrollo de

software.

Tipos de procesos ligeros.

Tipos de procesos ligeros:

Desarrollo Rápido de Software.

Desarrollo Ágil.

Programación Extrema.

Scrum.

Escalamiento de Métodos Ágiles.

Desarrollo Rápido de Software.

Las empresas maniobran en un entorno que cambia constantemente, al cual deben adaptarse

para obtener beneficios.

El software es parte de casi todas las operaciones industriales, de modo que debe

desarrollarse rápidamente para aprovechar las nuevas oportunidades.

Además resulta difícil definir un conjunto estable de requisitos, tal y como se requiere en los

modelos de procesos tradicionales.

Cada vez más se elige rapidez en la entrega en contraposición a la fiabilidad o a la calidad del

producto.

Principales características:

Especificación, diseño e implementación están entrelazados.

El sistema se desarrolla como una serie de versiones con los clientes involucrados en

la evaluación de las mismas si es necesario.

Los interfaces de usuario son a menudo desarrollados usando un IDE y herramientas

gráficas.

Métodos Ágiles.

Nace como contraposición a la percepción generalizada durante los años ochenta y noventa de

que una planificación cuidadosa del proyecto conduce a un mejor software. Esta planificación

incluye costes significativos en su diseño y documentación y aunque está justificada en el

2

desarrollo de sistemas críticos, donde trabajen múltiples equipos o donde vayan a trabajar

muchas personas diferentes a lo largo de su mantenimiento.

Los Métodos Ágiles se caracterizan por:

Estar centrados en el código más que en el diseño.

Basados en aproximaciones iterativas al desarrollo de software.

Destinados a entregar software operativo rápidamente y evolucionarlo para

satisfacer los requerimientos cambiantes.

Los objetivos de los Métodos Ágiles son:

Reducir sobrecargas en los procesos software, por ejemplo limitando la

documentación.

Ser capaces de responder rápidamente a los requerimientos cambiantes sin excesivo

trabajo adicional, sin rehacer demasiado trabajo.

Manifiesto Ágil.

Nace como resultado de las metodologías ágiles para el desarrollo de software, de forma

sencilla este manifiesto propone que se valore:

Individuos e interacciones sobre procesos y herramientas.

Software operativo sobre documentación exhaustiva.

Colaboración con el cliente sobre negociación del contrato.

Respuesta al cambio sobre seguimiento de un plan.

Los 5 principios de los Métodos Ágiles.

1. Participación estrecha del cliente. Los clientes deben intervenir estrechamente

durante el proceso de desarrollo. Su función consiste en ofrecer y priorizar nuevos

requerimientos del sistema y evaluar las iteraciones del mismo.

2. Entrega incremental. El software se desarrolla en incrementos con el cliente

especificando los requerimientos que van a ser incluidos en cada uno.

3

3. Personas, no procesos. Deben reconocerse y aprovecharse las habilidades del equipo

de desarrollo. Debe permitirse a los miembros del equipo desarrollar sus propias

maneras de trabajar sin procesos establecidos.

4. Adoptar el cambio. Esperar que los requerimientos cambien y, de este modo, diseñar

el sistema para adoptar dichos cambios.

5. Mantener la simplicidad. Centrarse en la simplicidad tanto en el software como en el

proceso de desarrollo. Siempre que sea posible, trabajar de manera activa para

eliminar la complejidad del sistema. Esfuerzo en mejorar del código.

Aplicabilidad de los Métodos Ágiles.

Las metodologías ágiles son aplicables por ejemplo en:

Desarrollo del producto donde una compañía de software elabora un producto pequeño o

mediano para su venta.

Diseño de sistemas a medida dentro de una organización, donde hay un claro compromiso del

cliente por intervenir en el proceso y donde no existen muchas reglas ni regulaciones

externas que afecten al desarrollo.

Dado su enfoque en equipos reducidos firmemente integrados hay problemas en escalarlos

hacia sistemas grandes pero pueden ser aplicados en sistemas pequeños.

Problemas con los Métodos Ágiles.

Los principales problemas de estas metodologías son:

Puede ser difícil mantener el interés de los clientes que intervienen en el proceso.

Los miembros del equipo pueden ser inadecuados para la participación intensa

característica de los métodos ágiles.

Priorizar los cambios puede ser difícil cuando hay múltiples participantes.

Mantener la simplicidad requiere trabajo adicional.

Los contratos pueden ser un problema, como en otros procesos de desarrollo

iterativo.

Métodos Ágiles y mantenimiento.

La mayoría de las compañías gastan más tiempo manteniendo software que creándolo nuevo.

Por lo tanto si los Métodos Ágiles quieren tener éxito también tienen que dar un buen soporte

al mantenimiento.

4

Las preguntas resultantes de esta afirmación son:

¿Son los sistemas desarrollados usando una aproximación ágil mantenibles, a pesar del

énfasis en minimizar la documentación formal?

¿Los métodos ágiles pueden usarse con efectividad para evolucionar un sistema como

respuesta a requerimientos de cambio por parte del cliente?

Si el equipo cambia, ¿pueden aparecer otros problemas?

Desarrollo Dirigido por un Plan y Ágil.

Desarrollo dirigido por un plan:

Está basado en etapas separadas con salidas producidas en cada una de ellas

planeadas por adelantado.

No es necesario seguir un modelo de cascada, es posible el desarrollo incremental.

La iteración ocurre dentro de las actividades.

Desarrollo Ágil:

Especificación, diseño, implementación y prueba están solapados y las salidas se

deciden a través de un proceso de negociación durante el desarrollo.

La iteración ocurre a través de las actividades.

5

Programación Extrema (XP).

Quizás el método ágil mejor conocido y más ampliamente utilizado. Lleva a niveles “extremos”

el desarrollo iterativo. Método ágil llevado al extremo.

Características:

Pueden construirse versiones nuevas varias veces al día.

Se entregan incrementos a los clientes cada poco tiempo (sobre 2 semanas variando

en base al proyecto).

Deben ejecutarse todas las pruebas para cada nueva versión y sólo es aceptada si las

supera.

Tres principios importantes de la Programación Extrema.

1. Los requerimientos se expresan como escenarios (llamados historias de usuario o

casos de uso) que se implementan directamente como una serie de tarea.

2. Los programadores trabajan en pares o parejas.

3. Antes de escribir el código se desarrollan pruebas para cada tarea.

Programación Extrema y Principios Ágiles.

Desarrollo incremental apoyado por pequeñas y frecuentes liberaciones del sistema.

La participación del cliente implica un compromiso a tiempo completo con el equipo

de desarrollo.

Personas y no procesos a través de programación por parejas, la propiedad colectiva

del código y un proceso que evita las jornadas de trabajo largas.

El cambio es soportado mediante liberaciones regulares del sistema.

Se mantiene la simplicidad mediante la refactorización (depuración) constante del

código.

Ciclo de Liberación de la Programación Extrema.

6

Prácticas de la Programación Extrema.

Planeación incremental. Los requerimientos se registran en tarjetas de historia y las

historias que se van a incluir en una liberación se determinan por el tiempo disponible

y la prioridad relativa. Los desarrolladores las desglosan en tareas.

Pequeñas entregas. Se desarrolla primero el conjunto mínimo de funcionalidad útil

que ofrece valor para el negocio. Las entregas son frecuentes y añaden funcionalidad

incrementalmente.

Diseño simple. Se realiza un diseño estrictamente suficiente para cumplir con los

requerimientos actuales.

Desarrollar primero las pruebas. Se utiliza un marco de trabajo automático de pruebas

para testear cualquier nueva funcionalidad, dicho marco de trabajo es creado antes de

que la nueva funcionalidad sea implementada.

Refactorización. Se espera que todos los desarrolladores refactoricen el código

continuamente tan pronto como sea posible en busca de mejoras. Esta práctica

produce código simple y mantenible.

Programación por parejas. Los desarrolladores trabajan en parejas, cada uno revisa el

trabajo del otro, dando soporte para que siempre se realice un buen trabajo.

Propiedad colectiva. Las parejas de desarrolladores trabajan en todas las áreas del

sistema de manera que no se desarrollen islas de experiencia y todos los

desarrolladores se responsabilicen de todo el código. Cualquiera puede producir

cambios.

Integración continua. Tan pronto como está completa una tarea se integra en el

sistema completo. Después de la integración deben superarse todas las pruebas de

unidad para que dicha tarea se considere añadida al sistema.

Ritmo sostenible. No se consideran aceptables grandes cantidades de tiempo extra ya

que su efecto neto suele ser la reducción de la calidad del código y una rebaja de la

productividad media.

Cliente in situ. Debe disponerse de un representante del usuario final del sistema

(normalmente el cliente) a tiempo completo por parte del equipo. Se le considera un

miembro más del equipo y es responsable de traer al equipo los requisitos para su

implementación.

7

Escenarios de Requerimientos en la Programación

Extrema.

El cliente que forma parte del equipo es responsable de tomar decisiones sobre los

requerimientos.

Los requerimientos de usuario se expresan como escenarios o historias de usuario.

Se escriben en tarjetas y el equipo de desarrollo las descompone en tareas de

implementación.

Estas tareas son la base para la planificación y la estimación de costes.

El cliente elige las historias que hay que incluir en cada entrega en base a sus

prioridades.

Programación Extrema y el Cambio.

Una creencia popular en la Ingeniería del Software tradicional es diseñar para cambiar, es

decir, se considera valioso gastar tiempo y esfuerzo en anticipar cambios ya que se presupone

que esto reducirá costes futuros durante la vida del producto.

En contraposición con esta idea la Programación Extrema mantienen que no merece la pena y

que los cambios no pueden ser anticipados de modo fiable de manera que es mejor

mantener una mejora constante del código o refactorización para facilitar los posibles

cambios que en el futuro tengan que se implementados.

Refactorización en Programación Extrema.

El equipo de programación busca posible mejoras en el software y hace estas mejoras incluso

cuando no hay una necesidad inmediata de ellas, esto mejora la compresión del software y

reduce la necesidad de documentación.

Los cambios son más fáciles de hacer porque el código está bien estructurado, sin embargo

algunos cambios requieren refactorización de la arquitectura algo mucho más costoso.

Reorganizar una jerarquía de clases para remover código duplicado, ordenar y cambiar de

nombre atributos y métodos para que sean más fáciles de comprender o sustituir código por

llamadas a métodos incluidos en librerías son ejemplos prácticos de factorización.

Pruebas dentro de la Programación Extrema.

Probas es primordial para la Programación Extrema y para ello se ha desarrollado un enfoque

donde el programa es probado después de cada cambio realizado.

Este enfoque determinado se caracteriza por:

8

Desarrollar primero las pruebas.

Desarrollo incremental de pruebas a partir de los escenarios.

Implicación del usuario en el desarrollo y validación de las pruebas.

Uso de marcos de pruebas automatizados para correr todas las pruebas cada vez que

se construye una nueva versión.

Desarrollar primero las Pruebas.

Escribir las pruebas antes de codificar es un método de clarificación de los requerimientos.

Son escritas como programas más que como datos de modo que puedan ejecutarse

automáticamente y sirvan como verificación de las funcionalidades.

Todas las pruebas previas y nuevas se ejecutan automáticamente cuando se añada una nueva

funcionalidad, aumentando el control de errores y la depuración del código.

Implicación del Cliente en las Pruebas.

Ayuda a desarrollar pruebas de aceptación a partir de las historias que van a implementarse

en la siguiente versión.

Es parte del equipo que escribe las pruebas a medida que el desarrollo avanza y todo el código

nuevo es validado para así asegurar que es lo que realmente necesita el cliente.

Sin embargo, el cliente tiene disponibilidad muy limitada y es probable que no puedan

participar a tiempo completo. Podría creer que aportar los requerimientos es suficiente

contribución y ser reacio a intervenir en las pruebas.

Dificultades con las Pruebas en Programación Extrema.

Los programadores prefieren programar a probar y algunos toman “atajos” cuando escriben

las pruebas como no comprobar todas las excepciones.

Algunas pruebas pueden ser muy difíciles de escribir de modo incremental.

Es difícil juzgar las completitud de un conjunto de pruebas.

Programación en Parejas.

Los programadores trabajan por pares, sentándose juntos para desarrollar el código en la

misma máquina.

Las parejas son creadas dinámicamente de modo que todos los miembros del equipo trabajen

unos con otros durante el proceso, esto ayuda a desarrollar la idea de propiedad común y

responsabilidad del código y extiende el conocimiento en el equipo.

9

Compartir el conocimiento es muy importante porque reduce el riesgo global del proyecto

cuando se marchan miembros del equipo, al mismo tiempo programar por parejas sirve como

revisión informal ya que el código está “testeado” por dos programadores favoreciendo la

factorización.

La productividad se mantiene o incluso aumenta ya que los programadores menos

experimentados son apoyados por otros con mayor experiencia evitando salidas en falso,

rediseño, errores y, aunque para los programadores experimentados pueda suponer una

pérdida de productividad realmente el intercambio de información dinamiza el trabajo y

reduce los riesgos del proyecto.

Administración de un Proyecto Ágil.

La responsabilidad principal de los administradores es dirigir el proyecto de modo que el

software se entregue a tiempo y con el presupuesto planeado.

El enfoque básico o estándar está basado en un plan:

Qué se debe entregar.

Cuándo se debe entregar.

Quién trabajará en su desarrollo.

El enfoque para la administración ágil es distinto y debe adaptarse al desarrollo incremental y

a las fortalezas y debilidades particulares de los métodos ágiles.

SCRUM.

Es un método ágil general pero enfocado a la administración del desarrollo iterativo más que

a prácticas ágiles específicas.

Consta de tres fases:

Planificación del boceto donde se establecen los objetivos generales del proyecto y el

diseño de la arquitectura del software.

Una serie de ciclos sprint donde cada ciclo desarrolla un incremento del sistema.

Cierre del proyecto donde se completa la documentación requerida, manuales de

usuario etc. En esta fase también se realiza la valoración de las lecciones aprendidas

durante el proyecto.

El Ciclo Sprint en SCRUM.

1. Los sprints tienen longitud fija, normalmente de 2 a 4 semanas. Corresponden al

desarrollo de una liberación del sistema en Programación Extrema.

10

2. El punto de partida es el backlog de producto. Consiste en una lista de trabajo que se

tiene que hacer en el proyecto, se revisan dichas tareas y se asignan prioridades y

riesgos.

3. El equipo de desarrollo que trabaja con el cliente selecciona las características y la

funcionalidad a desarrollar en el sprint.

4. Se organiza el equipo para desarrollar el software, se aísla del cliente y la organización

canalizando todas las comunicaciones a través del Maestro de Scrum (Scrum

Manager).

5. El papel del Maestro de Scrum es proteger al equipo de desarrollo de “distracciones”

externas.

6. Al final se revisa el trabajo hecho y se presenta a los participantes antes de comenzar

el siguiente sprint.

El Equipo de Trabajo en SCRUM.

Maestro de Scrum. Es un facilitador que organiza las reuniones diarias, planifica el trabajo por

hacer, registra las decisiones, mide el progreso del proyecto y detecta los retrasos. Sirve como

punto de comunicación entre el cliente, la dirección del proyecto y el equipo de desarrollo.

Todo el equipo acude a reuniones diarias cortas donde se comparte información, describen su

progreso, los problemas y sus planes desde la última reunión.

Todos conocen todos los problemas y los progresos del resto del equipo y ayudan a replantear

el trabajo a corto plazo y a solucionar dichos problemas de forma colectiva.

Beneficios de SCRUM.

El producto se desglosa en un conjunto de piezas manejables y comprensibles.

Los requerimientos inestables no causan retraso.

Todo el equipo tiene visibilidad total del proyecto mediante una comunicación directa

y continua.

Los clientes ven la entrega a tiempo de los incrementos y obtienen retroalimentación

del funcionamiento del producto.

Se crea confianza entre los clientes y los desarrolladores, es decir, nace una cultura

positiva donde todos esperan el éxito del proyecto.

Escalamiento de los Métodos Ágiles.

11

Se ha probado que son exitosos para proyectos de tamaño pequeño y medio que pueden ser

desarrollados por un equipo local.

Un factor de dicho éxito proviene de la comunicación entre todos los miembros del equipo.

Escalar estos métodos conlleva cambiarlos para tratar con proyecto más grandes y largos o

donde hay múltiples equipos de desarrollo incluso geográficamente distantes.

Desarrollo de Grandes Sistemas.

Usualmente son colecciones de sistemas separados que se comunican, desarrollados por

distintos equipos, frecuentemente trabajando en diferentes sitios y zonas horarias diversas.

Incluyen e interaccionan con sistemas ya existentes, muchos de sus requerimientos tienen

que ver con esto y no permiten la flexibilidad y el desarrollo incremental.

Cuando varios sistemas se integran para crear un sistema, una fracción significativa del

desarrollo tiene que ver con la configuración del sistema más que con el desarrollo del código.

A menudo sus procesos de desarrollo están restringidos por reglas externas y regulaciones

que limitan la forma en que se llevan a cabo.

Tienen un largo tiempo de elaboración y desarrollo. Es difícil mantener equipos coherentes

que conozcan el sistema durante todo el desarrollo. Es inevitable que la gente cambie de

trabajo o de proyecto.

Normalmente tiene un conjunto diverso de participantes, es prácticamente imposible implicar

a todos ellos en el desarrollo.

Scaling Up y Scaling Out.

Scaling Up. (Expansión) Los métodos ágiles se usan para desarrollar grandes sistemas

software que no se logran desarrollar por un equipo pequeño.

Scaling Out. (Ampliación) Los métodos ágiles se pueden introducir en una gran

organización con muchos años de experiencia en el desarrollo de software.

Cuando se escalan métodos ágiles es esencial mantener sus fundamentos ágiles: planificación

flexible, frecuentes entregas del sistema, integración continua, desarrollo dirigido por pruebas

y buenas comunicaciones de equipo.

Adaptaciones para Grandes Sistemas.

No es posible centrarse sólo en el código, se necesita más diseño y documentación.

Tienen que diseñarse y usarse mecanismos de comunicación entre equipos como

teléfono, videoconferencias, reuniones electrónicas, email…

12

La integración continua. El sistema completo se construye cada vez que un

desarrollador comprueba un cambio, es imposible aunque es esencial mantener

construcciones y liberaciones del sistema frecuentes.

Adaptaciones para Grandes Compañías.

Gerentes sin experiencia pueden ser reticentes al riesgo de un nuevo enfoque.

Incompatibilidad con los procesos de calidad y estándares para todos los proyectos.

Los métodos ágiles parecen funcionar mejor cuando se tiene un nivel de habilidad

relativamente alto, pero puede haber una amplia gama de habilidades.

Quizás haya una resistencia cultural en donde se tenga un largo historial de uso de procesos

convencionales de ingeniería de sistemas.