Programacin Extrema

Universidad Mariano Glvez Facultad de Ingeniera en Sistemas Clase de Anlisis de Sistemas

Proceso de desarrollo de software

El tpico proceso de desarrollo de software consta de las siguientes fases:
Conceptualizacin y captura de requisitos. Anlisis y Descripcin funcional Diseo Codificacin Pruebas Distribucin

El problema de la productividad
Los documentos y diagramas se producen de las fases desde la Conceptualizacin hasta el Diseo. Estos documentos incluyen la descripcin de los requisitos, diagramas UML como casos de uso, diagramas de clases, de actividad, etc. Se produce un montn de papeles considerable. Este montn de papeles pierde su valor en cuanto se empieza a crear el cdigo, sobre todo si es un sistema que va cambiando con frecuencia dado que no hay tiempo para actualizar toda la documentacin y los cambios se hacen slo en el cdigo. Se pierde la conexin entre documentacin y cdigo.

Por qu fracasan los proyectos de software?

Retrasos y desviaciones en la planificacin. Coste de mantenimiento elevados. Alta tasa de defectos. Requisitos mal comprendidos. Cambios de negocio. Falsa riqueza de caractersticas. Cambios de personal.

Como soluciona XP estos problemas?

Retrasos y desviaciones: versiones cortas. Cancelan el proyecto: entregas peridicas. Sistemas deteriorados y defectos: pruebas continuas. Requisitos mal comprendidos: cliente dentro del equipo. Cambios de negocio: versiones cortas. Falsa riqueza de caractersticas: realizar tareas prioritarias. Cambios de personal: anima el contacto y la integracin.

Metodologas giles de desarrollo de software (i)

Conocidos anteriormente como Metodologas Livianas, los procesos giles de desarrollo de software evitan los tortuosos y burocrticos caminos de las metodologas tradicionales y se enfocan en la gente y los resultados.

Metodologas giles de desarrollo de software (ii)

Minimizar la cantidad de esfuerzo y tiempo gastados en construir modelos que slo servirn como documentacin. Asegurar que el software entregado funciona para los usuarios. Permitir que el proyecto se adapte de manera flexible e inmediata a los cambios originados por tecnologas y/o requisitos.

Metodologas giles de desarrollo de software (iii)

Programacin extrema (XP) Metodologas Crystal SCRUM Desarrollo de software adaptativo Desarrollo guiado por caractersticas (FDD) Metodologa de desarrollo de sistemas dinmicos (DSDM)

Qu es XP?
Un proceso ligero, de bajo riesgo, flexible, predecible, cientfico y divertido de desarrollar software. Kent Beck (Extreme Programming Explained) Naci en 1996 Proyecto C3 de DaimlerChrysler

Caractersticas de XP
Metodologa creada a base de prueba y error. Surge considerando 4 valores que pueden mejorar cualquier proyecto de software: Simplicidad, Comunicacin, Realimentacin, Coraje. Expresada en forma de 12 prcticas (algunas existentes desde hace aos), que se soportan las unas a las otras y conforman un conjunto completo.

Los 4 valores (i)

Simplicidad: XP propone el principio de hacer la cosa ms simple que pueda funcionar, en relacin al proceso y la codificacin. Es mejor hacer algo simple hoy, que hacerlo ms complicado hoy y probablemente nunca usarlo. Comunicacin: Algunos problemas en los proyectos tienen su origen en que alguien no dijo algo a alguien ms sobre algo importante en algn momento. XP hace casi imposible la falta de comunicacin.

Los 4 valores (ii)

Realimentacin: retroalimentacin concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo. Coraje: se requiere coraje para confiar en que la retroalimentacin durante el camino es mejor que tratar de adivinar todo con anticipacin. Se requiere valor para comunicarse con los dems cuando eso podra exponer la propia ignorancia. Se requiere valor para mantener el sistema simple, dejando para maana las decisiones de maana. Y, sin un sistema simple, comunicacin constante y retroalimentacin, es difcil ser valeroso.

XP en la prctica (i)
Retroalimentacin a escala fina:
Desarrollo guiado por pruebas Planificacin iterativa Cliente como parte del equipo Programacin en pares

Proceso continuo:

Integracin continua Refactorizacin Liberacin pequea, entregas frecuentes

XP en la prctica (ii)
Entendimiento compartido:
Diseo simple Metforas del sistema Propiedad colectiva del cdigo Estndares de codificacin

Bienestar del programador:

Ritmo sostenible (Semanas de 40 horas)

Ciclo de la XP

Proceso de desarrollo de software con XP (i)

Proceso de desarrollo de software con XP (ii)

Proceso de desarrollo de software con XP (iii)

Proceso de desarrollo de software con XP (iv)

Relatos (historias) de Usuario (i)

Una Historia de usuario es un relato acerca de qu problema debe resolver el sistema. Cada relato se escribe en una tarjeta y representa una parte de la funcionalidad que es coherente para el cliente. Son escritos por el cliente o usuario, con la ayuda de los desarrolladores, para permitir estimar los tiempos y asignar prioridades. Los clientes ayudan a asegurar que la mayora de la funcionalidad deseada para el sistema est cubierta con las historias. Constan de 3 4 lneas escritas por el cliente en un lenguaje no tcnico sin hacer mucho hincapi en los detalles; no se debe hablar ni de posibles algoritmos para su implementacin, ni de diseos de base de datos adecuados, etc.

Relatos (historias) de Usuario (ii)

Planificacin
En el juego de planificacin, el cliente y los programadores negocian el alcance del proyecto para cada iteracin. El factor crtico es permitir al cliente tomar las decisiones de negocio y al equipo de desarrollo tomar las decisiones tcnicas.

Diseo simple
El diseo debe ser lo ms simple posible: no introducir estructura, ni funcionalidad antes de tiempo. Se puede aadir complejidad ms adelante. Inconveniente: Vencer la tendencia al gran diseo previo

Pruebas automatizadas (i)

Todo cdigo que puede fallar debe tener una prueba. Hacer la prueba an antes de la implementacin. Inconveniente: Obliga a imponer una forma de trabajar y puede ser necesaria formacin/experiencia. Dos tipos: Prueba de Unidad (o del Programador) y Prueba de Aceptacin (o Funcional, o del Cliente). La Prueba de Aceptacin es una prueba formal conducida para determinar si un sistema satisface los criterios de aceptacin y permite al cliente determinar si acepta o no el sistema.

Pruebas automatizadas (ii)

Para cada lenguaje de programacin hay herramientas de Prueba de Unidad que permiten automatizar la ejecucin de las mismas, como JUnit para Java. (ver http://www.xprogramming.com/software.htm) Frecuentemente una Prueba de Unidad es mejor que un comentario para ayudar a entender por qu una determinada funcin es necesaria, para demostrar cmo es llamada una funcin y cuales son los resultados esperados, y para documentar defectos en versiones previas del programa que queremos asegurarnos de que no vuelvan.

Integracin continua
Todos los cambios deben ser integrados a la base del cdigo al menos diariamente. Las pruebas deben correr al 100% antes y despus de la integracin. Cada nueva versin debe tener la mnima funcionalidad extra que tiene sentido. Encaja con release early, release often Ventajas: tener realimentacin de los usuarios y ofrecer pronto nueva funcionalidad (+xito).

Programacin en pares
La Programacin en Pares requiere que dos desarrolladores participen en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo en ese momento: Mientras uno redacta Pruebas de Unidad el otro piensa acerca de la clase que satisfar a dicha prueba, por ejemplo. Los estudios demuestran que, tras aprender Habilidades Personales dos programadores son ms que doblemente productivos que uno slo para una tarea determinada.

Refactorizacin (i)

Es una tcnica disciplinada de reestructurar cualquier cdigo existente, alterando su estructura interna sin modificar su comportamiento externo.

Si su software fuera un edificio, se parecera mas a uno de la izquierda o de la derecha?

Refactorizacin (ii)
Si un programa funciona pero est mal diseado, pronto surgirn problemas a la hora de actualizarlo. Los problemas ms comunes pueden ser catalogados como olor de cdigo (ya que la acumulacin de los mismos provocan que el cdigo apeste). Existen listas de refactorizaciones. Ejemplo:

Add Parameter
A method needs more information from its caller.

Add a parameter for an object that can pass on this information.

Caso de Estudio (i)

Tomado de Universidad Politcnica de Valencia (Espaa)
http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemploxp/

El proyecto consiste en el desarrollo de un sistema de gestin para una empresa de confecciones. En dicha gestin de la empresa se incluyen gestin de pedidos, gestin de clientes (tanto principal como los de temporada), facturacin, gestin de productos, gestin de materias primas, etc...

Caso de Estudio (ii)

Gestin del proyecto:
Planificacin del proyecto Diario de Actividades

Implementacin:
Base de Datos Interfaces de Usuario Cdigo Fuente

Pruebas

ltimas ideas
El mtodo de desarrollo empleado por la programacin extrema y el que suele llevarse a cabo en la generacin de Software Libre tienen grandes parecidos. Hay algunas prcticas de la programacin extrema que no se usan de manera mayoritaria (pruebas de unidad y de aceptacin, metfora y refactorizacin) y que son muy interesantes y provechosas. XP y bases de datos: cuidar que tanto BDs relacionales como orientadas al objeto sean flexibles, de manera de migrar fcilmente los datos en caso de cambios. En cuanto al lanzamiento de cada mini-versin, usar una estacin de integracin que permite a los desarrolladores observar quin y cundo se est realizando, manteniendo estabilidad en el sistema.