2. INGENIERA DEL SOFTWARE 2.1.

CICLO DE VIDA
http://es.wikipedia.org/wiki/Archivo:Modelo_Gral_Evolutivo_Incremental.jpg Define el orden y la relacin de las tareas involucradas en el desarrollo del software. Una tcnica es un mtodo que aplica herramientas y reglas especficas para completar una o ms fases del ciclo de vida del desarrollo de Sistemas. Metodologa es una versin amplia y detallada de un ciclo de vida completo de desarrollo. Tareas: Captura, Anlisis y Especificacin de requisitos Diseo del Sistema Codificacin del Software Pruebas

Modelos o Ciclos de Vida: Cascada: Se realizan las tareas de desarrollo de forma secuencial. Actualmente se utilizan procesos retroalimentados: Modelo en Cascada Realimentado. Evolutivos: Se dividen los requisitos en iteraciones y se sigue un ciclo de vida en cascada para cada uno de ellos.

Incremental: En cada incremento se entrega una parte completamente funcional. Cada nuevo incremento se realiza sobre el anterior. La prctica de 2 es claramente incremental.

Figura 3. Ciclo de vida Incremental

Iterativo: En el caso del iterativo se mejoran los requisitos (ms genricos a ms especficos). Puede verse como uno en cascada con una funcionalidad bsica, agregando funcionalidad en la etapa de mantenimiento. Existe unas tareas de anlisis y diseo comunes y posteriormente Diseo detallado y codificacin para cada iteracin. El problema es que avanzas en conjunto pero no tienes nada finalizado.

Figura 4. Ciclo de vida Iterativo

Figura 5. Comparativa entre un ciclod e vida Iterativo e Incremental

Prototipado: Se realiza un diseo y desarrollo rpido para obtener una retroalimentacin del cliente. Se presenta en los primeros prototipos el interfaz y las salidas. Se suele utilizar cuando se est muy lejos de la idea del producto final. Merece la pena el esfuerzo? Espiral: Combina el modelo prototipado con el de cascada, agregando un control de riesgos. Hay incertidumbres sobre el producto final. Un riesgo puede ser requisitos no comprendidos, mal diseo, errores en la implementacin, etc. Por cada espiral, se crea una regin que parte del producto conceptual, el nuevo producto, hasta el producto mejorado. Este Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo ms asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorndose con otro nuevo ciclo. Tiene dos dimensiones, la angular (las fases de cada ciclo) y la radial (la regin). Esta ltima, cuantas ms existan, mayor coste tendr el desarrollo. Generalmente se definen cuatro regiones: Definir objetivos, requisitos, restricciones, etc. Evaluar alternativas e identificar y resolver riesgos. Desarrollar Planificar la siguiente fase.

Figura 6. Ciclo de vida en Cascada. Fuente: http://ingeniumetsomnia.blogspot.com.es/2011/04/ciclo-de-vida-de-desarrollo-desoftware.html

2.2. METODOLOGAS DE DESARROLLO DE SOFTWARE

Las metodologas son marcos de trabajo (frameworks) para planificar y gestionar el desarrollo de un desarrollo de software las cuales combinan ciclos de vida con tecnologas y herramientas. Desde hace algn tiempo han aparecido nuevas metodologas de desarrollo basados en mtodos giles de 12 desarrollo. El Manifiesto gil de desarrollo de software promueve iteraciones durante el desarrollo de los productos software aplicando distintos o combinaciones de ciclos de vida. Este manifiesto tiene como propsito valorar: A los individuos y su interaccin, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentacin exhaustiva. La colaboracin con el cliente, por encima de la negociacin contractual. La respuesta al cambio, por encima del seguimiento de un plan.

As, se intentan suprimir las polticas, procedimientos y burocracia de muchas de las metodologas existentes como MetricaV3, CMMI, ITIL, Prince2, etc. y centrarse en lo realmente importante que es el desarrollo del software. A continuacin se listan varias metodologas, ordenndolas de menos a ms gil, de menos a revolucionaria ms: CMMI (Capability Maturity Model Integration) con una implantacin tradicional : Microsoft Solutions Framework (MSF) MSF for CMMI Process Improvement MSF Agile Rational Unified Process (RUP) Scrum XP
3

1 2 3

http://es.wikipedia.org/wiki/Desarrollo_gil_de_software http://www.agilealliance.org/ http://www.ingenierosoftware.com/calidad/cmm-cmmi.php

2.3. RATIONAL UNIFIED PROCESS (RUP)

http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational Es una implementacin del desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semiordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

Figura 7. Modelo RUP

2.4. SCRUM
http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf http://es.wikipedia.org/wiki/Scrum http://geeks.ms/blogs/rcorral/archive/2006/10/15/Por-qu_E900_-me-gusta-Scrum.aspx http://www.proyectosagiles.org/ http://www.slideshare.net/gquiroz/scrum-en-20-minutos-1607246 http://www.infoq.com/minibooks/scrum-xp-from-the-trenches http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm http://msdn.microsoft.com/en-us/library/dd997796.aspx Es una metodologa, framework o filosofa que permite definir un proceso propio para el desarrollo de nuevos productos en lneas generales, y software para el caso que nos preocupa. Los valores que promulga son: Empowerment (delegar y hacer sentir dueos de su trabajo) y compromiso con las personas. Transparencia y visibilidad del proyecto. Coraje y responsabilidad

Se basa en: Empirismo. Auto-organizacin. Colaboracin. Priorizacin. Compromiso con los tiempos (time-boxing).

Se trata de un modelo iterativo e incremental dividido en sprints. Cada sprint se centrar en unos requisitos concretos (user stories) y tendr una duracin entre una y cuatro semanas. Cuando estamos comenzando con Scrum, es normal realizar sprints de una semana, para simplificar la estimacin de tiempos. Cada sprint recoge las fases de desarrollo de software comunes: anlisis, diseo, programacin y pruebas. Mediante esta metodologa se van finalizando los requisitos sencillos (incremental) y se van perfeccionando aquellos complejos (iterativo). En el caso del cuadro de la Figura 5, aquellas partes sencillas del cuadro las puedo terminar en un sprint. Documentos esenciales: Product Backlog: se describen de forma reducida todos los requerimientos (user stories) priorizados y con una estimacin de tiempos. Tambin se muestra informacin global del desarrollo. La gestin del Product Backlog se puede llevar a cabo mediante una simple hoja de clculo o a travs de herramientas software ms completas.

Figura 8. Ejemplo de Product Backlog

Figura 9. Ejemplo de Product Backlog mediante la herramienta online Yodiz.com

Sprint Backlog: documento detallado de los requerimientos (user stories) de cada sprint. Estos se pueden subdividir en tareas (items) de 4-16 horas. El producto de software resultante debe ser potencialmente usable. Para decidir la carga mxima de trabajo para cada sprint se define una puntuacin mxima al equipo (trabajo mximo que puede soportar) y una puntuacin a cada uno de los requerimientos. Los primeros sprints a desarrollar suelen abordar las historias de usuario o requerimientos ms crticos.

Figura 10. Ejemplo de Sprint Backlog

Figura 11. Ejemplo de Sprint Backlog mediante la herramienta online Yodiz.com

User Stories Los requisitos o los casos de uso en UML, describen de forma muy breve la funcionalidad o capacidades del sistema desde el punto de vista del usuario. Deben ser independientes e indicar: Quin es el usuario que se beneficia? Qu accin lleva a cabo? Cul es el beneficio?
4

Siempre se redactan segn la siguiente plantilla : As a <type of user>, I want <some goal> so that <some reason>. Como profesor, quiero listar los alumnos con nota superior a 6 para saber quin libera el examen El equipo de proyecto debe decidir la descomposicin de la historia de usuario en tareas, estimando la duracin de cada una de ellas y la asignacin a los miembros del equipo.

Figura 12. Ejemplo de representacin de una tarea

http://www.mountaingoatsoftware.com/topics/user-stories

Scrum Board Se recomienda realizar un seguimiento del Product Backlog y sobe todo, del Sprint Backlog mediante un tablero fsico. Aunque existen un gran nmero de herramientas software que permiten llevar esta gestin mediante el ordenador, es conveniente tener nuestro tablero ya que ser nuestro lugar donde se celebrarn las reuniones diarias y se podrn observar los progresos y realizar las actualizaciones a la vista de todos los miembros del equipo. Se utilizarn tarjetas de mayor tamao (blancas) para las historias de usuario y en otro color para las tareas. De forma horizontal se desplazarn las tareas que pertenecen a cada historia entre las tres columnas definidas: pendiente, en curso y terminada. El diagrama de quemado o Burndown permite mostrar el esfuerzo pendiente de realizar frente al estimado.

Figura 13. Ejemplo de un Scrum Taskboard para un Sprint de cuatro historias de usuario. Fuente: http://www.infoq.com. A la derecha ejemplo de Scrum taskboard real.

Planning Poker El equipo debe definir de forma consensuada la duracin de la tarea o de la historia. Para ello se puede emplear la tcnica del Planning Poker o Scrum Poker: mediante cartas cada uno de los miembros de forma annima estima la duracin del hito. Un Rey o smbolo significa una duracin muy grande que es imposible estimar, una interrogacin que esa persona no se ha enterado muy bien de la dimensin del hito o lo desconoce y una taza, un descanso. Es importante que este proceso sea annimo para que no existan influencias. Se suelen utilizar cartas con la serie de Fibonacci.

Figura 14. Ejemplo de puntuacin basado en cartas. Fuente: http://www.crisp.se

Operativa de cada Sprint: Se desarrolla una reunin al comienzo del sprint (Sprint Planning Meeting), en la cual se desarrolla el Sprint BackLog. Esta reunin suele estar ajustada en el tiempo a 4 horas. Cada da se realizan reuniones diarias de 15 minutos (time-boxing) de duracin (siempre en el mismo lugar, a la misma hora y de pie) donde se pone de manifiesto qu se ha hecho y qu se va a hacer, as como de los problemas que pueden surgir para alcanzarlo. Se actualiza el Sprint BackLog y el Burndown. Otras informativas en la que se revisa el Sprint finalizado (sprint review meeting). Adems, se realiza una retrospectiva de los problemas y forma de trabajar (retrospective meeting) plantendose las siguientes cuestiones: qu fue bien, qu cosas no y qu mejoras deberan hacerse para los siguientes sprints. Presentacin del siguiente Sprint.

Figura 15. Esquema de un Sprint

Roles: Propietario del Producto (Cerdo: comprometido) o Mantienes el backlog del producto, prioriza los requerimientos, es la persona que valida el software al finalizar cada sprint y representa a los stakeholders (departamentos involucrados en el producto final) y usuarios. Scrum Manager (C) o Lder al servicio del equipo, responsable del proyecto apoyando y protegiendo al equipo. Es el encargado tambin de eliminar todos los impedimentos organizacionales que afecten al equipo de desarrollo y de transmitir los principios y valores giles. Miembros del Equipo (C): o Formado por grupos de 3 a 10 personas, multidisciplinar (analistas, arquitectos de software, programadores, diseadores, etc.) y autoorganizado. Son los responsables de estimar la Figura 16. Roles Scrum. Fuente: duracin de los requisitos, diseo e http://www.slideshare.net/gquiroz/scru implementacin y de cumplir los compromisos que m-en-20-minutos-1607246 adquieren. StakeHolders (Gallina: involucrada): o Personas involucradas dentro de la organizacin

Usuarios (G)

Figura 17. Modelo gil de Desarrollo de Nuevos Productos

Figura 18. Modelo para el Desarrollo de Software

QUIN USA SCRUM?

Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm, State Street Bank, Philips, BBC, IBM, SAIC, LMCO, APL, Ariba, Federal Reserve Bank, HP, Motorola, Nokia, TransUnion, IDX, Siemens Medical, Gestalt, Yahoo, Conchango, BMC, Lexis-Nexis, Bently Systems, Bose, CapitalOne,Federal Reserve Bank, ClearChannel, Xerox, Patient Keeper, British Telecom, PayPal, Fuente: http://agilepainrelief.com/files/ScrumInANutshell.ppt

SCRUM INTEGRADO EN OTRAS MODELOS DE GESTIN

Los modelos ISO 12207, CMMI o ISO 15504 son modelos que dicen QU hay qu hacer, pero no CMO. Por ese motivo se busca la combinacin de ambos modelos:

Figura 19. Rendimiento de Scrum con CMMI. Fuente: http://www.openviewpartners.com/events/pdfs/scrumcertificationworkshop.pdf

2.5. EXTREME PROGRAMMING

http://es.wikipedia.org/wiki/Programacin_extrema Es el proceso gil ms importante de desarrollo de software. Se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Caractersticas: Valores: Simplicidad. Comunicacin. Retroalimentacin. Respeto entre las personas. Coraje y responsabilidad Se trata de un proceso iterativo Pruebas unitarias continuas (primero se programa la unidad de prueba y posteriormente se codifica). Se programa en parejas. Frecuente integracin con el cliente. Refactorizacin de cdigo (reescribir ciertas partes de cdigo para aumentar su legibilidad, pero sin modificar su funcionalidad). Propiedad del cdigo compartida (cualquiera debe ser capaz de modificar cualquier parte del cdigo).

Otras cosas a tener en cuenta Getting Things Done (GTD): Mtodo de gestin de tiempo para organizarse con eficacia. No se deben tener todas las cosas en la cabeza. Orientado a las acciones que provocan realizacin de tareas, no a la expiracin de las mismas. Si un elemento requiere una accin que puede ser llevada a cabo en menos de dos minutos, hazla. http://es.wikipedia.org/wiki/Getting_Things_Done