Programacin Avanzada

Ciclos de vida giles

Agenda
Ciclos de vida giles XP FDD SCRUM DSDM Crystal

Ciclo de Vida: eXtreme Programming (XP)

Ciclo de Vida: XP
Programacin extrema (XP) es un enfoque de la ingeniera del software formulado por Kent Beck. Pone ms nfasis en la adaptabilidad que en la previsibilidad (Que el software pueda adaptarse a nuevos requerimientos en vez de buscar contemplarlos todos previo a su construccin) . Est centrado en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software. Se basa en la realimentacin continua entre el cliente y el equipo de desarrollo (Comunicacin fluida entre todos los participantes). XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes. Para especificar los requisitos del software usa tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer (historias de usuario).

Ciclo de Vida: XP - Principios Bsicos

Simplicidad: Se simplifica el diseo para

agilizar el desarrollo y facilitar el mantenimiento. Comunicacin:
o El cdigo autodocumentado es ms fiable

que los comentarios. o Se debe comentar slo lo que NO va a variar. o Comunicacin con el cliente es fluida.

Ciclo de Vida: XP - Principios Bsicos

Retroalimentacin(feedback): Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real. Coraje o valenta: Aceptar que la programacin en parejas beneficiar la calidad del cdigo.

Ciclo de Vida: XP Conceptos

Refactoring: Spike:
o Reescribir el cdigo fuente de un mdulo sin afectar su funcionalidad con la finalidad de hacerlo ms preciso, conciso y entendible. o Pequeos programas para probar o evaluar una solucin. o Usados ante problemas tcnicos o dificultad en la estimacin de tiempo para implementar la historia de usuario. o Una vez utilizados son desechados.

Ciclo de Vida: XP - Roles

Programador: Recibe pruebas unitarias y genera el cdigo del
sistema.

Cliente: Escribe las historias de usuario, las pruebas funcionales para validar la implementacin y decide el orden para su implementacin. Encargado de pruebas: Ayuda al cliente a escribir pruebas funcionales, ejecuta las pruebas, difunde los resultados. Encargado de seguimiento: Retroalimenta al equipo,verifica el grado de acierto entre las estimaciones y el tiempo real (para mejora de estimaciones), realiza el seguimiento del proceso en cada iteracin.

Ciclo de Vida: XP - Roles

Entrenador: es el responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Consultor: es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas (Experto). Gestor (big boss): es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

Ciclo de Vida: XP Funcionamiento

El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar 2. El programador estima el esfuerzo necesario para su implementacin 3. El programador construye ese valor

4. Vuelve al paso 1

Ciclo de Vida: XP Funcionamiento

Ciclo de Vida: XP Funcionamiento

En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse de que el sistema tenga el mayor valor de negocio posible.

Ciclo de Vida: XP - Prcticas

La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial del coste del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. El juego de la planificacin. Hay una comunicacin frecuente entre el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin.

Entregas pequeas. Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio. Una entrega no debera tardar ms de 3 meses.

Ciclo de Vida: XP - Prcticas

Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. Pruebas. La produccin de cdigo est dirigida por las pruebas unitarias. stas son establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Programacin en parejas. Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor satisfaccin de los programadores).

Ciclo de vida: FDD

Ciclo de Vida: FDD Feature Driven Development

(Desarrollo Basado en

Funcionalidades). Proceso gil para el desarrollo de sistemas. Diseado por Peter Coad, Eric Lefebvre y Jeff DeLuca. No se hace nfasis en la obtencin de los requerimientos sino en cmo se realizan las fases de diseo y construccin. Incluye un monitoreo constante del proyecto.

Ciclo de Vida: FDD Ayuda a contrarrestar situaciones como el exceso en el

presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado. Propone tener etapas de cierre cada dos semanas. Se obtienen resultado peridicos y tangibles.

Ciclo de Vida: FDD Se basa en un proceso iterativo con iteraciones cortas

que producen un software funcional que el cliente y la direccin de la empresa pueden ver y monitorear. Define claramente entregas tangibles y formas de evaluacin del progreso del proyecto

FDD - Proceso
1 2 3

FDD Proceso (1) Desarrollar modelo general

Expertos del dominio estn al tanto del mbito, alcance y requerimientos del sistema a construir. Divisin del dominio en reas que son analizadas detalladamente. Los desarrolladores construyen diagramas de clases o de objetos por cada rea. Se construye un modelo general del software.

Un rasgo es una caracterstica a los ojos

del cliente.
o Elaborar lista de rasgos que resuman al sistema general. o La lista es elaborada por los desarrolladores y es evaluada por el cliente. o Se divide en subconjunto segn afinidad y la dependencia entre rasgos. o Lista es revisada por los usuarios y los responsables para su validacin y aprobacin.

FDD Proceso (2) Construir lista de rasgos

FDD Proceso (3) Planeacin por rasgo

Ordenar los conjuntos de rasgos conforme a su prioridad y dependencia. Asignacin a los programadores jefes.

FDD Proceso (4) y (5) Disear y construir por rasgo.

Seleccin de un conjuntos de rasgos de la lista. Se disea y construye rasgo mediante un proceso iterativo. Una iteracin puede tomar desde unos pocos das a un mximo de dos semanas. Cada iteracin incluye: inspeccin de diseo, codificacin, pruebas e inspeccin de cdigo.

FDD - Roles
Existen 3 categoras de roles para FDD: Key Roles / roles claves Supporting Roles / Roles de Soporte. Additional Roles / Roles Adicionales.

FDD Roles Key Roles

Gerente de proyecto (Project Manager)
o Lder administrativo y financiero del proyecto.

Arquitecto jefe (Chief Architect)

o Diseo global del sistema.

o Ejecucin de todas las etapas.

Gerente de desarrollo (Development Manager)

o Lleva diariamente las actividades de desarrollo.
o Resuelve conflictos en el equipo. o Resuelve problemas referentes a recursos.

FDD Roles Key Roles

Programador Jefe(Chief Programmer)
o Analiza los requerimientos. o Disea el proyecto.

o Selecciona rasgos a desarrolla.

Propietario de clases (Class Owner)

o Responsable del desarrollo de las clases que se le asignaron como propias. o Participa en la decisin de que clase ser incluida en la lista de rasgos para la prxima iteracin.

FDD Roles Key Roles

Experto del dominio

o Puede ser un usuario, un cliente, analista o una mezcla de estos.
o Poseen el conocimiento de los requerimientos del sistema. o Pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.

FDD Roles Supporting Roles

Gerente del dominio (Domain Manager)

o Lidera al grupo de expertos del dominio.
o Resuelve sus diferencias de opinin respecto a requerimientos.

Administrador de release (Release Manager)

o Controla el avance del proceso mediante la revisin de los reportes del Chief Programmer.

o Reporta resultados obtenidos semanalmente al gerente, al cliente donde incluye el porcentaje de avance de cada feature.

FDD Roles Supporting Roles

Guru del Language(Language Lawyer)

o Responsable de poseer un vasto conocimiento en, por ejemplo, el lenguaje de programacin. o Importante cuando se trabaja en nuevas tecnologas.

Ingeniero de construccin (Build Engineer)

o Responsable de preparar, mantener y correr el proceso de construccin. o Realiza el mantenimiento de las versiones y la publicacin de la documentacin.

FDD Roles Supporting Roles

Administrator)

Administrador del sistema (System

o Configura, administra y repara los servidores, estaciones de trabajo y equios de desarrollo y testeo utilizados por el equipo.

Herramentista (toolsmith)
o Rol para la construccin de herramientas especficas para el desarrollo, conversion de datos y testeo.

o Puede trabajar en la preparacin y mantenimiento

tanto de bases de datos o sitios web destinados el proyecto.

FDD Roles Additional Roles

Tester
o Verifica que el sistema recin creado cumpla con los requerimientos del cliente. o Puede llegar a ser una persona independiente del equipo de proyecto.

Deployer
o Encargado de convertir la informacin existente requerida por el nuevo sistema.

Escritor Tcnico (Technical Writer)

o Prepara la documentacin para los usuarios, que pueden formar parte o no del equipo del proyecto.

XP VS FDD
Tamaos de equipo: Ambos se implementan mejor para proyectos cortos y equipos ms pequeos, siendo quizs FDD ms escalable que XP. Evaluacin estado del proyecto: FDD es posiblemente el proceso ms adecuado para establecer mtricas que definen el estado del proyecto, puesto que al dividirlos en unidades pequeas es bastante sencillo un seguimiento de las mismas, xp tambin define componentes pequeos aunque con menos orden porque se van evaluando en el momento.

XP VS FDD
Carga de trabajo: XP es un proceso ligero, esto es, que los creadores del proceso han tenido cuidado de no poner demasiadas tareas organizativas sobre los programadores, por tu parte FDD genera ms documentacin que XP.Relacin con el cliente: XP y FDD se basan en formalismos en la documentacin, si no en los controles propios y una comunicacin fluida con el cliente.

XP VS FDD
Conocimiento de la arquitectura: En XP se intentar reducir la complejidad del software a travs de la programacin a pares, ya que en la creacin de cdigo se pueden evitar errores y malos diseos. En FDD sin embargo, se usan las sesiones de trabajo conjuntas en fase de diseo para conseguir una arquitectura sencilla y sin errores. Puntos dbiles: FDD tiene la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el inicio, con la elaboracin del modelo global, puesto que no es tan gil como podria serlo XP.

Ciclo de vida: SCRUM

SCRUM

Scrum es una metodologa de desarrollo muy simple, que

requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias de la evolucin del proyecto. Define un sprint como el perodo en el cual se lleva a cabo el trabajo en s y cuya magnitud la define el equipo en base a su experiencia. En cada sprint el equipo crea un incremento de software potencialmente entregable al cliente (utilizable). Puede ser usado tambin para la ejecucin de equipos de mantenimiento de software.

SCRUM
Scrum es una metodologa gil, y como tal:

Es un modo de desarrollo de carcter adaptable ms

que predictivo.

incremental basada en iteraciones y revisiones.

Orientado a las personas ms que a los procesos. Emplea la estructura de desarrollo gil:

SCRUM - Proceso
Se comienza con la visin general del producto,especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 das). Cada uno de estos periodos de desarrollo es una iteracin que finaliza con la produccin de un incremento operativo del producto. Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su evolucin a travs de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el da anterior y el previsto para el da siguiente.

SCRUM
Control de la evolucin del proyecto: Scrum controla de forma emprica y adaptable la evolucin del proyecto, empleando las siguientes prcticas de la gestin gil:

Revisin de las Iteraciones. Desarrollo incremental. Desarrollo evolutivo. Auto-organizacin. Colaboracin.

SCRUM - Control de evolucin

Revisin de las Iteraciones: Al finalizar cada iteracin (normalmente 30 das) se lleva a cabo una revisin con todas las personas implicadas en el proyecto. Este es el periodo mximo que se tarda en reconducir una desviacin en el proyecto o en las circunstancias del producto.

Desarrollo incremental: Durante el proyecto, las personas implicadas no trabajan con diseos o abstracciones.

(El desarrollo incremental implica que al final de cada

iteracin se dispone de una parte del producto operativa que se puede inspeccionar y evaluar.)

SCRUM - Control de evolucin

Desarrollo evolutivo: Los modelos de gestin gil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales cmo ser el producto final, y sobre dicha prediccin desarrollar el diseo y la arquitectura del producto.(No as las finales, por el constante cambio) En Scrum se toma a la inestabilidad como una premisa, y se

adoptan tcnicas de trabajo para permitir esa evolucin sin degradar la calidad de la arquitectura que se ir generando durante el desarrollo.

SCRUM - Control de evolucin

Desarrollo evolutivo: El desarrollo Scrum va generando el diseo y la arquitectura final de forma evolutiva durante todo el proyecto.
Un principio clave de Scrum es el reconocimiento

de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma predictiva y planificada.

SCRUM - Sprint

Scrum denomina sprint a cada iteracin de desarrollo

y recomienda realizarlas con duraciones de 30 das. la base de desarrollo iterativo e incremental.

El sprint es por tanto el ncleo central que proporciona

SCRUM Reuniones
Planificacin de sprint: Jornada de trabajo previa al inicio de
cada sprint en la que se determina cul va a ser el trabajo y los objetivos que se deben cumplir en esa iteracin. realizado hasta la fecha y la previsin para el da siguiente. generado.

Reunin diaria: Breve revisin del equipo del trabajo

Revisin de sprint: Anlisis y revisin del incremento

Scrum - Roles Product Owner: Mantiene los procesos y trabaja junto

con el jefe de proyecto (voz del cliente para el equipo). ScrumMaster (o Facilitador): Elimina los obstculos que impiden que el equipo alcance el objetivo del sprint, protege al equipo de distracciones.

Scrum - Roles Equipo de Desarrollo: Son los responsables de

entregar el producto, lo componen un grupo de entre 3 a 9 personas. Stakeholders (Clientes, Proveedores, etc): Es para quienes el software producir beneficios que justifican el desarrollo. (grupo de interesados) Administradores: Los que establecen el ambiente de desarrollo.

Scrum - Documentacin Product Backlog:

Sprint backlog:

o Documento de alto nivel para todo el proyecto. Contiene descripciones genricas de todos los requerimientos, funcionalidades deseables, etc. o Priorizadas segn su retorno sobre la inversin. o Es el "qu" va a ser construido. Es abierto y cualquiera puede modificarlo.
o Documento detallado donde se describe el cmo el equipo va a implementar los requisitos durante el siguiente sprint. o Grfica mostrada pblicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.

Burn Down Chart:

Comparacin entre SCRUM y XP Diferencias

Scrum eXtreme Programming
Es una metodologa de desarrollo Es una metodologa de desarrollo gil basada en la administracin gil que est ms centrada en la del proyecto. programacin o creacin del producto Cada integrante del equipo Programacin en parejas. trabaja de forma individual Las iteraciones tienen una Las iteraciones de entrega duran duracin entre 1 y 4 semanas entre 1 y 3 semanas. Al finalizar un Sprint, las tareas del Sprint Backlog que se hayan realizado y que el Product Owner (propietario del producto) haya mostrado su conformidad ya no se retoca. Las tareas se van terminando aunque son susceptibles de ser modificadas durante el transcurso de proyecto, incluso, despus de que funcionen correctamente.

Comparacin entre SCRUM y XP Diferencias

Scrum
Trata de seguir el orden de prioridades que marca el Product Owner en el Sprint Backlog pero puede variar segn la necesidad del desarrollo de tareas

eXtreme Programming
El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definido por el cliente.

Ciclo de Vida: DSDM

Ciclo de Vida: DSDM

Dynamic systems development method Est basada en la metodologa RAD (Rapid application development). Posee un enfoque iterativo e incremental que enfatiza la participacin continua del usuario.

Su objetivo es entregar sistemas de software en tiempo y presupuesto ajustndose a los cambios de requisitos durante el proceso de desarrollo

Ciclo de Vida: DSDM

DSDM - Caractersticas

Se centra en proyectos de sistemas de Consiste en 3 fases:

o Fase pre-proyecto. o Fase de ciclo de vida del proyecto.

informacin que se caracterizan por planificaciones y presupuestos estrictos.

o Fase post-proyecto.

DSDM - Caractersticas
La fase de ciclo de vida del proyecto est subdividida en 5 etapas:
Estudio de viabilidad. Estudio de negocio Iteracin de modelo funcional Iteracin de diseo Construccin e implementacin.

Es posible integrar otras metodologas tales como: RUP, XP Y PRINCE2.

DSDM - Enfoque
Hay nueve procesos subyacentes que consisten en cuatro fundamentos y cinco puntos de partida. Participacin del usuario es clave. Se le deben otorgar poderes al equipo del proyecto para tomar decisiones y no esperar aprobaciones de ms alto nivel. Poner foco en la entrega frecuente de productos.

DSDM - Enfoque

Principal criterio de aceptacin de un entregable es que sea un sistema que trate las necesidades del negocio actuales.

El desarrollo es iterativo e incremental y conducido por la retroalimentacin del usuario para converger en una solucin efectiva.
Todos los cambios son reversibles. Establecer una lnea base de alcance y los requisitos de alto nivel (mayor prioridad)

DSDM - Enfoque

Las pruebas se efectan a lo largo de

todo el ciclo de vida del proyecto.

Necesidad de cooperacin y

comunicacin entre todas las personas en el negocio.

DSDM - FACTORES CRTICOS DE XITO

Aceptacin de DSDM por parte de la gerencia y otros empleados.(Genera compromiso por parte de los involucrados)

El compromiso de la gestin de asegurar la participacin de usuario final. El equipo ha de estar formado miembros habilidosos que formen una unin estable.

Metodologa:Crystal

Crystal - Caractersticas
Desarrollada por el investigador de IBM el Dr. Alistair Cockburn No es una metodologa en si misma sino una familia de metodologas con un cdigo gentico comn. Identifica con colores diferentes cada mtodo, y su eleccin debe ser consecuencia del tamao y criticidad del proyecto. Factor ms significativo es la comunicacin. o Aconseja que el tamao del equipo sea reducido. Aumento en el nmero de personas deriva en un aumento en la necesidad de coordinacin.

Crystal - Polticas de equipo

Clear es para equipos de hasta 8 personas o menos. Amarillo es para equipos entre 10 a 20 personas. Naranja es para equipos entre 20 a 50 personas. Roja es para equipos entre 50 a 100 personas. Azul es para equipos entre 100 a 200 personas

Crystal - Roles
Executive Sponsor (Patrocinador Ejecutivo)
o Produce la Declaracin de Misin con Prioridades de Compromiso

Project Manager (Jefe de Proyecto) Domain Expert (Experto en el Dominio) Usage Expert (Experto de uso) Designer-Programmer (Programador Diseador) UI Designer (UI Diseador) Tester (Realizador de Pruebas) Technical (Programador Tcnico)

Crystal Clear
Es una metodologa centrada en el factor humano El diseador lder y de dos a siete desarrolladores ms se encuentran juntos en un local grande o en locales adyacentes. Compartan fuente de informacin (pizarras, diagramas) visibles para todos. Acceso a usuarios claves del sistema; Entrega de cdigo funcional, testeado y utilizable. Proyectos de pequea duracin.

Crystal Clear - Caractersticas

Entrega frecuente: Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el cdigo. Comunicacin: entre todos los integrantes del equipo de desarrollo. Mejora reflexiva: Tiempos para compartir reflexiones, discuciones o entregar opiniones a los dems integrantes.

Crystal Clear - Caractersticas

Seguridad personal: Entregar sus juicios respecto a lo realizado por los dems integrantes. Foco: Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo (direccin y prioridad) Fcil acceso a usuarios expertos: Importancia del contacto directo con expertos en el desarrollo de un proyecto.

Crystal Clear y XP
XP es un miembro vlido de la familia Crystal Clear. Ambos tienen: Entregas frecuentes Foco en comunicacin Compromiso del usuario/cliente Test de regresin automtico Preocupacin por la motivacin

Crystal Clear y XP
Diferencia: disciplina y tolerancia. XP: - Pocos entregables y estndares rigurosos: Estndares de diseo y codificacin. Pair programming. 100% unit test pass. El coach es necesario para mantener la disciplina.

Crystal es ms tolerante y ms fcil de seguir.