Metodología de ingeniería de software: diseño, desarrollo y evaluación de software, Ejercicios de Química Industrial

¡Descarga Metodología de ingeniería de software: diseño, desarrollo y evaluación de software y más Ejercicios en PDF de Química Industrial solo en Docsity! Maida, Esteban Gabriel ; Pacienzia, Julián Metodologías de desarrollo de software Tesis de Licenciatura en Sistemas y Computación Facultad de Química e Ingeniería “Fray Rogelio Bacon” Este documento está disponible en la Biblioteca Digital de la Universidad Católica Argentina, repositorio institucional desarrollado por la Biblioteca Central “San Benito Abad”. Su objetivo es difundir y preservar la producción intelectual de la Institución. La Biblioteca posee la autorización del autor para su divulgación en línea. Cómo citar el documento: Maida, EG, Pacienzia, J. Metodologías de desarrollo de software [en línea]. Tesis de Licenciatura en Sistemas y Computación. Facultad de Química e Ingeniería “Fray Rogelio Bacon”. Universidad Católica Argentina, 2015. Disponible en: http://bibliotecadigital.uca.edu.ar/repositorio/tesis/metodologias-desarrollo-software.pdf [Fecha de consulta:.........] FACULTAD DE QUÍMICA E INGENIERIA “FRAY ROGELIO BACON” PONTIFICIA UNIVERSIDAD CATÓLICA ARGENTINA SANTA MARIA DE LOS BUENOS AIRES METODOLOGIAS DE DESARROLLO DE SOFTWARE Tesis Final de Licenciatura en Sistemas y Computación Maida, Esteban Gabriel Pacienzia, Julián Diciembre 2015 Cátedra Seminario de Sistemas Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 4 | P á g i n a Resumen En la actualidad la rapidez y el dinamismo en la industria del software han hecho replantear los cimientos sobre los que se sustenta el desarrollo de software tradicional. Estudios recientes y el mismo mercado actual está marcando la tendencia en la ingeniería del software teniendo como características principales atender a las necesidades de rapidez, flexibilidad y variantes externas que hacen de nuestro entorno una ventaja más competitiva al aumentar la productividad y satisfacer las necesidades del cliente en el menor tiempo posible para proporcionar mayor valor al negocio. Ante esta situación, el grado de adaptación de las metodologías tradicionales a estos entornos de trabajo no eran del todo eficientes y no cubrían las necesidades del mercado actual. En la actualidad existen una gran cantidad de metodologías para el desarrollo de software, separadas en dos grandes grupos; las metodologías tradicionales o pesadas y las metodologías agiles. Las metodologías tradicionales se basan en las buenas prácticas dentro de la ingeniería del software, siguiendo un marco de disciplina estricto y un riguroso proceso de aplicación. Las metodologías agiles, en cambio, representan una solución a los problemas que requieren una respuesta rápida en un ambiente flexible y con cambios constantes, haciendo caso omiso de la documentación rigurosa y los métodos formales. El objetivo de esta investigación es presentar e introducir sobre las existentes metodologías para el desarrollo de software y los paradigmas que marcan la diferencia entre un método estructurado y un método ágil para así poder identificar cual se adapta de manera más eficiente a un proyecto determinado. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 5 | P á g i n a INDICE 1. INTRODUCCION 1.1. DEFINICION DEL PROBLEMA 1.2. PROPOSITO DE LA INVESTIGACION 1.3. OBJETIVOS GENERALES 1.4. ALCANCES 1.5. LIMITACIONES 1.6. METODOLOGIAS 2. MARCO TEORICO 2.1. DEFINICION DE INGENIERIA 2.2. SOFTWARE 2.2.1. METODOLOGIA 2.2.2. IMPORTANCIA 2.2.3. PROBLEMAS 2.2.4. CARACTERISTICAS BASICAS 2.2.5. CLASIFICACION 2.3. QUE ES LA INGENIERIA DE SOFTWARE 2.4. QUE ES UNA METODOLOGIA Y PARA QUE SE UTILIZA 2.5. METODOLOGIA TRADICIONAL 2.6. METODOLOGIA AGIL 2.7. DIFERENCIAS ENTRE METODOLOGIA TRADICIONAL Y AGIL 2.8. PARADIGMAS DE LA INGENIERIA DE SOFTWARE Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 6 | P á g i n a 3. INGENIERIA DE SOFTWARE 3.1. INTRODUCCION 3.2. OBJETIVOS 3.3. DISTRIBUCION DEL ESFUERZO EN UN PROYECTO DE SOFTWARE 3.4. ADMINISTRACION DE PROYECTOS DE SOFTWARE 3.4.1. INTRODUCCION 3.4.2. FACTORES DE LA ADMINISTRACION DE UN PROYECTO 3.4.3. SECUENCIA DE ACTIVIDADES DE ADMINISTRACION DE UN PROYECTO 3.4.4. VALORES DEL CAPITAL HUMANO 3.4.5. ORGANIZACIÓN DE UN EQUIPO 3.5. RECURSOS 3.5.1. RECURSOS HUMANOS Y PARTICIPANTES 3.5.2. RECURSOS DE SOFTWARE 3.5.3. RECURSOS DE ENTORNO 3.6. CICLO DE VIDA DE UN PROYECTO DE SISTEMAS 3.6.1. RECOPILACION DE LOS REQUERIMIENTOS 3.6.2. ANÁLISIS 3.6.3. LIMITACIONES 3.6.4. ESPECIFICACIÓN 3.6.5. DISEÑO Y ARQUITECTURA 3.6.6. PROGRAMACIÓN 3.6.7. PRUEBAS DE SOFTWARE 3.6.8. IMPLEMENTACIÓN 3.6.9. DOCUMENTACIÓN 3.6.10. MANTENIMIENTO Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 9 | P á g i n a 1. INTRODUCCION 1.1. DEFINICION DEL PROBLEMA Actualmente las metodologías de ingeniería de software pueden considerarse como una base necesaria para la ejecución de cualquier proyecto de desarrollo de software que se considere serio, y que necesite sustentarse en algo más que la experiencia y capacidades de sus programadores y equipo. Estas metodologías son necesarias para poder realizar un proyecto profesional, tanto para poder desarrollar efectiva y eficientemente el software, como para que sirvan de documentación y se puedan rendir cuentas de los resultados obtenidos. Un amplio y buen conocimiento de estas metodologías servirá de base teórica y permitirá comprender completamente todo lo que requiere el análisis, diseño, desarrollo e implantación de un sistema. Además es importante, por la demanda que se tiene hoy en día por parte de muchas empresas, el conocimiento de algunas metodologías de desarrollo de software en específico. Lo más importante en una primera etapa es poder identificar qué metodología de ingeniería de software se adecúa de la mejor manera a nuestro proyecto, para así lograr el mejor resultado en tiempo y forma. 1.2. PROPOSITO DE LA INVESTIGACION La presente tesis se orienta a realizar una contribución en el área de metodología para el diseño, desarrollo y evaluación de software, necesarios para abordar proyectos con una metodología diferente a la estructurada. 1.3. OBJETIVOS GENERALES La selección y aplicación de una metodología particular para el desarrollo de software, se centra en el uso de un enfoque sistemático de pasos y etapas a seguir para el cumplimiento de los objetivos en común. El objetivo general de la puesta en práctica de una metodología del software es construir un producto de alta calidad de una manera oportuna. Dicha selección implica un conjunto de principios fundamentales que se deben seguir y cumplir. Estos incluyen actividades explícitas para el entendimiento del problema y la comunicación con el cliente, métodos definidos para representar un diseño, mejores prácticas para la implementación de la solución y estrategias y tácticas sólidas para las pruebas. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 10 | P á g i n a Para conseguir el objetivo de construir productos de alta calidad dentro de la planificación, las metodologías en general emplean una serie de prácticas para:  Entender el problema  Diseñar una solución  Implementar la solución correctamente  Probar la solución  Gestionar las actividades anteriores para conseguir alta calidad La utilización de la metodología adecuada, representa un proceso formal que incorpora una serie de métodos bien definidos para el análisis, diseño, implementación y pruebas del software y sistemas. Además, abarca una amplia colección de métodos y técnicas de gestión de proyectos para el aseguramiento de la calidad y la gestión de la configuración del software. 1.4. ALCANCES Se realiza una exposición de los dos grandes grupos de metodologías, estructuradas y ágiles, en toda su extensión, desde las primeras etapas del análisis hasta la implementación final del software y su seguimiento. El alcance de la tesis trata de introducir al conocimiento de metodologías de trabajo más modernas de acuerdo a los desafíos presentados en el mundo actual. 1.5. LIMITACIONES Este trabajo permite la introducción al conocimiento teórico para comprender las fases y etapas de las metodologías para el desarrollo de software existente. También se tratarán algunos casos prácticos en el capítulo 6. 1.6. METODOLOGIAS El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en muchos otros. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 11 | P á g i n a ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. Un objetivo claro ha sido encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software. La evolución de la disciplina de ingeniería del software ha traído consigo propuestas diferentes para mejorar los resultados del proceso de construcción. Las metodologías tradicionales haciendo énfasis en la planificación y las metodologías ágiles haciendo énfasis en la adaptabilidad del proceso, delinean las principales propuestas presentes. En el próximo capítulo trataremos algunos conceptos básicos referidos al marco teórico, tales como, definición de ingeniería, software, metodologías y paradigmas de la ingeniería. En el capítulo 3 (tres) abordaremos temas relacionados específicamente a la ingeniería del software, como por ejemplo, cuáles son los objetivos fundamentales, administración de un proyecto, recursos y el ciclo de vida. Continuaremos con el capítulo nº 4 (cuatro) donde explicaremos las metodologías clásicas, con sus ventajas y desventajas, para luego proseguir con el siguiente capítulo donde trataremos temas exclusivos de las metodologías agiles. Posteriormente veremos estudios y análisis de casos reales, como casos de éxitos, de fracasos y análisis críticos. Finalmente sacaremos nuestras propias conclusiones respecto a todo el trabajo realizado. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 14 | P á g i n a 2.2.3. PROBLEMAS DEL SOFTWARE La planificación y estimación de costos frecuentemente son imprecisas. • Falta de productividad. • La calidad del software es a veces inaceptable. Estos problemas al final crean insatisfacción y falta de confianza de los clientes. Los problemas anteriores son sólo manifestación de otras dificultades: • No tenemos tiempo de recoger datos sobre el proceso de desarrollo del software. • Los proyectos de desarrollo de software se llevan a cabo con sólo una vaga indicación de los requisitos del cliente. • La calidad del software es normalmente cuestionable. • El mantenimiento de software es muy costoso y no se le ha considerado un aspecto importante. Los problemas anteriores son solucionables, dándoles un enfoque de ingeniería al desarrollo de software. 2.2.4. CARACTERISTICAS BASICAS El software es un elemento del sistema que es lógico. Por tanto, el software tiene características considerablemente distintas al hardware: • El software se desarrolla, no se fabrica en un sentido clásico. • El software no se desgasta con el tiempo. • La mayoría de software se construye a medida, en vez de ensamblar componentes existentes. • Está creando en base a la lógica puramente. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 15 | P á g i n a Figura Nº 1 – Comparación de índices de fallas entre hardware y software. 2.2.5. CLASIFICACION El software pude clasificarse en tres grandes grupos: Software de sistema: Se llama Software de Sistema o Software de Base al conjunto de programas que sirven para interactuar con el sistema, confiriendo control sobre el hardware, además de dar soporte a otros programas que administran los recursos y proporcionan una interfaz de uso. El mejor ejemplo en este sentido son los populares sistemas operativos como Windows, Linux o Mac OS. Este tipo de sistemas incluye entre otros:  Sistemas operativos  Controladores de dispositivos  Herramientas de diagnóstico  Herramientas de Corrección y Optimización  Servidores de información  Programas utilitarios Software de programación: Es el conjunto de herramientas que permiten al programador desarrollar programas informáticos, usando diferentes alternativas y lenguajes de programación, de una manera práctica. Estos incluyen básicamente:  Editores de texto  Compiladores  Intérpretes  Enlazadores  Depuradores  Entornos de Desarrollo Integrados (IDE): Agrupan las anteriores herramientas, usualmente en un entorno visual, de forma tal que el programador no necesite introducir múltiples comandos para compilar, interpretar, depurar, etc. Habitualmente cuentan con una avanzada interfaz gráfica de usuario (GUI). ________________ Figura Nº 1 Extraída de [1] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 16 | P á g i n a Software de aplicación: son los programas diseñados para o por los usuarios para facilitar la realización de tareas específicas en la computadora, como pueden ser las aplicaciones ofimáticas u otros tipos de software especializados. Incluye entre muchos otros:  Aplicaciones para Control de sistemas y automatización industrial  Aplicaciones ofimáticas (procesador de texto, hoja de cálculo, programa de presentación)  Software educativo  Software empresarial  Bases de datos  Telecomunicaciones (por ejemplo Internet y toda su estructura lógica)  Software médico  Software de cálculo numérico y simbólico.  Software de diseño asistido (CAD)  Software de control numérico (CAM) 2.3. QUE ES LA INGENIERIA DE SOFTWARE Haciendo una recopilación de todos los conceptos que se han dado sobre la Ingeniería de software, la podemos definir como la disciplina o área de la informática, que hace uso razonable de los principios de ingeniería con el objetivo de obtener soluciones informáticas económicamente factible y que se adapte a las necesidades de las empresas reales, tomando en cuenta los procesos de producción y mantenimiento de software que son desarrollados y modificados en el tiempo y con los costos estimados. Esta ingeniería trata con áreas muy diversas de la informática y de las Ciencias de la Computación, tales como construcción de compiladores, Sistemas Operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Información y aplicables a infinidad de áreas (negocios, investigación científica, medicina, producción, logística, banca, etc.). Algunas definiciones, dadas a través del tiempo son:  “Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas de software” (Zelkovitz, 1978)  “Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software” (Bohem, 1976).  “Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales” (Bauer, 1972).  “Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software” (IEEE, 1993). Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 19 | P á g i n a En la tabla que se muestra a continuación aparece una comparativa entre estos dos grupos de metodologías. Tabla Nº 1 – Comparación entre Metodología Ágil y Tradicional Metodologías ágiles Metodologías Tradicionales Basadas en heurísticas provenientes de prácticas de producción de código Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Especialmente preparados para cambios durante el proyecto Cierta resistencia a los cambios Impuestas internamente (por el equipo) Impuestas externamente Proceso menos controlado, con pocos principios Proceso mucho más controlado, con numerosas políticas/normas No existe contrato tradicional o al menos es bastante flexible Existe un contrato prefijado El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio Grupos grandes y posiblemente distribuidos Pocos artefactos Más artefactos Pocos roles Más roles Menos énfasis en la arquitectura del software La arquitectura del software es esencial y se expresa mediante modelos Poca documentación Documentación exhaustiva Muchos ciclos de entrega Pocos ciclos de entrega Como se muestra en la Tabla Nº 1, se puede apreciar que las metodologías ágiles, son más baratas en tiempo y recursos, obteniendo los mismos o mejores resultado ante las metodologías tradicionales. ________________ Tabla Nº 1 Extraída de [1] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 20 | P á g i n a 2.8. PARADIGMAS DE LA INGENIERIA DEL SOFTWARE La ingeniería de software es reconocida como una disciplina legítima, digna de tener una investigación seria, un estudio cuidadoso y generando una gran controversia. En la industria el ingeniero del software ha sustituido al programador como título de trabajo preferente. Los modelos de procesos de software, métodos de ingeniería de software y herramientas se han adoptado con éxito en el amplio espectro de las aplicaciones industriales. Los gestores y usuarios reconocen la necesidad de un enfoque más disciplinado del software. Un paradigma de programación es un modelo básico de diseño y desarrollo de programas, que permite producir programas con una directriz específica, tales como: estructura modular, fuerte cohesión, alta rentabilidad, etc. Existen tres categorías de paradigmas de programación: a. Los que soportan técnicas de programación de bajo nivel. b. Los que soportan métodos de diseño de algoritmos. c. Los que soportan soluciones de programación de alto nivel. Los paradigmas relacionados con la programación de alto nivel se agrupan en tres categorías de acuerdo con la solución que aportan para resolver el problema: a. Solución procedimental u operacional. Describe etapa a etapa el modo de construir la solución. Es decir señala la forma de obtener la solución. b. Solución demostrativa. Es una variante de la procedimental. Especifica la solución describiendo ejemplos y permitiendo que el sistema generalice la solución de estos ejemplos para otros casos. Aunque es fundamentalmente procedimental, el hecho de producir resultados muy diferentes a ésta, hace que sea tratada como una categoría separada. c. Solución declarativa. Señala las características que debe tener la solución, sin describir cómo procesarla. Es decir señala qué se desea obtener pero no cómo obtenerlo. Paradigma: El concepto de paradigma se utiliza en la vida cotidiana como sinónimo de “ejemplo” o para hacer referencia a algo que se toma como “modelo”. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 21 | P á g i n a 3. INGENIERIA DE SOFTWARE 3.1. INTRODUCCION En este capítulo se desean presentar los fundamentos en que se basa el software, los métodos, las herramientas y los procedimientos que provee la ingeniería de software a fin de considerarlos para el desarrollo de los programas en general. Se describen y analizan las etapas del proceso de la ingeniería del software, desde la recopilación de los requerimientos hasta la implementación y posterior mantenimiento. Uno de los problemas más importantes con los que se enfrentan los ingenieros en software y los programadores en el momento de desarrollar un software de aplicación, es la falta de marcos teóricos comunes que puedan ser usados por todas las personas que participan en el desarrollo del proyecto informático. "La ingeniería del software surge a partir de las ingenierías de sistemas y de hardware, y considera tres elementos claves: que son los métodos, las herramientas y los procedimientos que facilitan el control del proceso de desarrollo de software y brinda a los desarrolladores las bases de la calidad de una forma productiva" (Pressman, 1993). La ingeniería de software está compuesta por una serie de modelos que abarcan los métodos, las herramientas y los procedimientos. Estos modelos se denominan frecuentemente paradigmas de la ingeniería del software y la elección de un paradigma se realiza básicamente de acuerdo a la naturaleza del proyecto y de la aplicación, los controles y las entregas a realizar. Para la construcción de un sistema de software, el proceso puede describirse sintéticamente como: la obtención de los requisitos del software, el diseño del sistema de software (diseño preliminar y diseño detallado), la implementación, las pruebas, la instalación, el mantenimiento y la ampliación o actualización del sistema. El proceso de construcción está formado por etapas que son: la obtención de los requisitos, el diseño del sistema, la codificación y las pruebas del sistema. Desde la perspectiva del producto, se parte de una necesidad, se especifican los requisitos, se obtiene el diseño del mismo, el código respectivo y por último el sistema de software. Algunos autores sostienen que el nombre ciclo de vida ha sido relegado en los últimos años, utilizando en su lugar proceso de software, cambiando la perspectiva de producto a proceso. El software o producto, en su desarrollo pasa por una serie de etapas que se denominan ciclo de vida, siendo necesario, definir en todas las etapas del ciclo de vida del producto, los procesos, las actividades y las tareas a desarrollar. Un ciclo de vida establece el orden de las etapas del proceso de software y los criterios a tener en cuenta para poder pasar de una etapa a la siguiente. El tema del ciclo de vida lo han tratado algunas organizaciones profesionales y organismos internacionales como la IEEE (Institute of Electrical and electronics Engineers) y la ISO/IEC (International Standards Organization/International Electrochemical Commission), que han publicado normas tituladas “Standard for Developing Software Life Cycle Proccesses” (Estándar IEEE para el desarrollo de procesos del ciclo de vida del software) (IEEE, 1991) y “Software life-cycle process” (Proceso de ciclo de vida del software) (ISO, 1994). Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 24 | P á g i n a 3.3. DISTRIBUCION DEL ESFUERZO EN UN PROYECTO DE SOFTWARE El ciclo de vida de un proyecto de software está dividido en varias etapas. Cada una comprende un cierto porcentaje de esfuerzo en donde conjuntamente conforman lo que se denomina el proyecto en sí. Cada etapa va a requerir de una porción de esfuerzo distinta a las demás las cuales son detalladas a continuación: Figura Nº 2 – Distribución porcentual del esfuerzo de un proyecto de software. Como se puede ver en la Figura Nº 2 el mantenimiento está constituido por todas las actividades posteriores a la liberación inicial del producto, las cuales son, el mejoramiento de las capacidades del producto, adaptación del producto a nuevos ambientes de cómputo y la depuración de errores.  Gran porcentaje del esfuerzo total se dedica a mejorar el producto  Asignar poco tiempo a las pruebas piloto y de aceptación es una de las razones de sobrepasar el costo y tiempo de entrega de un producto  El mantenimiento gasta más recursos que las actividades de desarrollo. Por lo tanto, se puede decir que el mantenimiento de un software se lleva la mayor porción de la vida de un sistema, ya que este se va a mantener durante la existencia del sistema hasta que se vuelva obsoleto. _____________________ Figura Nº 2 Extraída de [2] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 25 | P á g i n a 3.4. ADMINISTRACION DE PROYECTOS DE SOFTWARE 3.4.1. INTRODUCCION Las actividades técnicas y gerenciales son igualmente importantes para el éxito de un proyecto de programación. Las actividades de la administración de un proyecto comprenden los métodos para organizar y seguir el curso del proyecto; estimación de costos, políticas de asignación de recursos, control de presupuesto, determinación de avances, ajustes al calendario de trabajo, procedimientos de control de calidad, comunicación con el cliente, etc. La administración de proyectos de desarrollo de software consiste en gestionar el desarrollo de un producto, dentro del plazo previsto y con los fondos establecidos. Como esto requiere recursos humanos, la administración del proyecto involucra no sólo la organización técnica y las habilidades organizativas, sino también el arte de dirigir un equipo de personas. La administración de un proyecto no es una actividad menor, puede ser tan transcendente como desarrollar la arquitectura. La administración de un proyecto comprende:  Estructura (Elementos organizativos involucrados)  Proceso administrativo (Responsabilidades y supervisión de participantes)  Proceso de desarrollo (métodos, herramientas, lenguajes, documentación y apoyo)  Programa (organización de los tiempos en los que deben realizarse los trabajos) Algunos problemas importantes identificados en la administración de software son:  Planeación de proyectos de software pobres.  Procedimientos de selección de gerentes de proyecto pobres.  La medición de proyectos es pobre.  Falta de procedimientos para vigilar el avance del proyecto.  Falta de estándares para medir la calidad del desempeño y cantidad de producción esperada. Algunos métodos sugeridos para solucionar estos problemas son:  Entrenar y educar a la dirección, jefes de proyecto y constructores.  Obligar al uso de estándares, procedimientos y documentación.  Definir objetivos de la calidad deseada.  Desarrollar estimaciones de calendario y costos de forma exacta y verdadera.  Seleccionar jefes de proyecto basados en su capacidad para administrar proyectos más que en su habilidad técnica. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 26 | P á g i n a 3.4.2. FACTORES DE LA ADMINISTRACION DE UN PROYECTO La administración de un proyecto debe controlar los siguientes factores:  El costo total del proyecto (aumentar o disminuir los gastos).  Las capacidades del proyecto (añadir o eliminar características funcionales).  La calidad del producto (aumentar el tiempo entre fallos de una cierta severidad).  La duración del proyecto (reducir el tiempo programado un 20% o posponer un mes la fecha de terminación). La calidad, la capacidad, los costos y los tiempos de realización son magnitudes que hay que gestionar a los largo de un proyecto. El grado en el que estos cuatro factores pueden controlarse depende de la naturaleza del proyecto y de quien o quienes los administra.  Aunque los costos pueden estar prefijados de antemano, frecuentemente se dispone de flexibilidad, ya que en la práctica muy rara vez se cumple con los costos establecidos en una primera instancia.  La capacidad del proyecto puede renegociarse en función de la evolución del proyecto.  La calidad también puede variar. Cuando la calidad se establece baja, se disminuye los costos de corto plazo, pero se incrementan los costos de largo plazo debido al costo de mantenimiento y la insatisfacción de los clientes. Si se establece una calidad excesiva, el costo de desarrollo se puede hacer inaguantable.  Negociar el tiempo frente a cualquiera de las otras magnitudes es también algo habitual. 3.4.3. SECUENCIA DE ACTIVIDADES DE ADMINISTRACIÓN DE UN PROYECTO  Comprender el contenido, alcance y tiempos del proyecto. Se refiere sólo a un entendimiento global de los objetivos del proyecto y no en reunir los requisitos que es función de los técnicos.  Identificar el proceso de desarrollo (métodos, herramientas, lenguajes, documentación, ayudas). Es la decisión de qué metodología de desarrollo usar (cascada, espiral, por incrementos, etc.)  Determinar la estructura organizativa (elementos de la organización involucrados). Esto incluye identificar las unidades, departamentos, compañías, líderes disponibles, etc. Una vez identificadas las partes y sus capacidades hay que decidir cómo deben interactuar para realizar el trabajo. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 29 | P á g i n a 3.6. CICLO DE VIDA DE UN PROYECTO DE SISTEMA El ciclo de vida de un proyecto de sistema está dividido en varias etapas. Cada etapa describe las actividades que hay que realizar para obtener un conjunto concreto de productos de desarrollo del software, las cuales se nombran a continuación: 3.6.1. RECOPILACION DE LOS REQUERIMIENTOS En esta primera etapa se realiza una recopilación y/o encuesta con el cliente, la cual nos permite obtener una visión de alto nivel sobre el proyecto, poniendo énfasis en la descripción del problema desde el punto de vista de los clientes y desarrolladores. También se considera la posibilidad de una planificación de los recursos sobre una escala de tiempos. 3.6.2. ANALISIS El propósito principal de esta etapa es conseguir una comprensión más precisa de los requisitos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema completo, incluyendo la arquitectura. El análisis de requerimientos facilita al ingeniero de sistemas especificar la función y comportamiento de los programas, indicar la interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe cumplir el programa. También permite al ingeniero refinar la asignación de software y representar el dominio de la información que será tratada por el programa. Así como también brinda al diseñador la representación de la información y las funciones que pueden ser traducidas en datos, arquitectura y diseño procedimental. Finalmente, la especificación de requerimientos suministra al técnico y al cliente, los medios para valorar la calidad de los programas, una vez que se haya construido. En la medida que logremos una clara comprensión de lo anterior obtendremos una arquitectura estable y sólida que nos facilite una comprensión en profundidad de los requisitos. 3.6.3. LIMITACIONES En esta etapa se va a detallar la frontera del proyecto, es decir, cuál es el alcance de nuestro sistema. Todo cambio que esté fuera de las limitaciones se deberá tratar como un cambio de alcance en la etapa de mantenimiento. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 30 | P á g i n a 3.6.4. ESPECIFICACIONES La obtención de especificaciones a partir del cliente u otros actores intervinientes es un proceso humano muy interactivo e iterativo. Normalmente a medida que se captura la información, se la analiza y realimenta con el cliente, refinándola, puliéndola y corrigiendo si es necesario. El analista siempre debe llegar a conocer la temática y el problema a resolver, dominarlo, hasta cierto punto, hasta el ámbito que el futuro sistema a desarrollar lo abarque. Por ello el analista debe tener alta capacidad para comprender problemas de muy diversas áreas o disciplinas de trabajo. El analista se debe compenetrar con el área de negocio del cliente, para comprender cómo ella trabaja y maneja su información, desde niveles muy bajos e incluso llegando hasta los gerenciales. Dada la gran diversidad de campos a cubrir, los analistas suelen ser asistidos por especialistas o usuarios/clientes, es decir, gente que conoce profundamente el área para la cual se desarrollará el software. Al contrario de los analistas, los clientes no tiene por qué saber nada de software, ni de diseños, ni otras cosas relacionadas, sólo se debe limitar a aportar objetivos, datos e información (de mano propia o de sus registros, equipos, empleados, etc.) al analista, y guiado por él, para que, en primera instancia defina un documento funcional y/o caso de uso. 3.6.5. DISEÑO Y ARQUITECTURA Una vez realizada la etapa de análisis y especificación, se modela el sistema y definimos su estructura (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los requisitos no funcionales y otras restricciones. Con toda esta información recopilada en los puntos anteriores, los profesionales técnicos traducen la información de alto nivel, en esquemas, diagramas, etc. de bajo nivel, para luego éstos ser comprendidos por el área de desarrollo. 3.6.6. PROGRAMACION Convertir un diseño a código puede ser interpretada como la parte más obvia e importante del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así también como a la calidad del diseño previamente realizado. 3.6.7. PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 31 | P á g i n a Esta etapa implica:  Verificar la interacción de componentes.  Verificar la integración adecuada de los componentes.  Verificar que todos los requisitos se han implementado correctamente.  Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.  Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se asegura la calidad, sino que la prueba debe ocurrir durante todo el ciclo de vida. Podemos probar la funcionalidad de los primeros prototipos, la estabilidad, cobertura y rendimiento de la arquitectura, probar el producto final, etc. La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error que probablemente no fue previsto en las fases iníciales del desarrollo del software. Tipos de pruebas:  Pruebas de unidad: La prueba de unidad se centra en el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito del módulo. La prueba de unidad hace uso intensivo de las técnicas de prueba de caja blanca. Este tipo de prueba la realiza, generalmente, el desarrollador luego de la codificación de un módulo.  Prueba de integración: El objetivo es tomar los módulos testeados en la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Hay dos formas de integración: o Integración no incremental: Se combinan todos los módulos por anticipado y se prueba todo el programa en conjunto. o Integración incremental: El programa se construye y se prueba en pequeños segmentos. En la prueba de integración el foco de atención es el diseño y la construcción de la arquitectura del software. Las técnicas que más prevalecen son las de diseño de casos de prueba de caja negra, aunque se pueden llevar a cabo unas pocas pruebas de caja blanca.  Prueba del sistema: verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Algunas de estas pruebas son: Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 34 | P á g i n a o Diccionario de Datos o Código Fuente (programa)  Manual de Usuario: Describe paso a paso la manera cómo funciona el programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado. 3.6.10. MANTENIMIENTO El mantenimiento consiste en mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Una pequeña parte de este trabajo consiste en arreglar errores o mayormente conocidos como Bugs. La mayor parte consiste en extender el sistema para que sea más útil y completo. La fase de mantenimiento de software es una parte explícita del modelo en cascada del proceso de desarrollo de software el cual fue desarrollado durante el movimiento de programación estructurada en computadores. El otro gran modelo, el Desarrollo en espiral desarrollado durante el movimiento de ingeniería de software orientada a objeto no hace una mención explícita de la fase de mantenimiento. En un ambiente formal de desarrollo de software, la organización o equipo de desarrollo tendrán algún mecanismo para documentar y rastrear defectos y deficiencias. El Software tan igual como la mayoría de otros productos, es típicamente lanzado con un conjunto conocido de defectos y deficiencias. Las deficiencias conocidas son normalmente documentadas en una carta de consideraciones operacionales o notas de lanzamiento (release notes) es así que los usuarios del software serán capaces de trabajar evitando las deficiencias conocidas y conocerán cuando el uso del software sería inadecuado para tareas específicas. Bugs: Defecto de software, es el resultado de un fallo o deficiencia durante el proceso de creación de programas de software. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 35 | P á g i n a 4. METODOLOGIAS CLASICAS 4.1. INTRODUCCION En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término ágil aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el manifiesto Ágil, un documento que resume la filosofía ágil. Principales ideas de la metodología ágil:  Se encarga de valorar al individuo y las iteraciones del equipo más que a las herramientas o los procesos utilizados.  Se hace mucho más importante crear un producto software que funcione, que escribir mucha documentación.  El cliente está en todo momento colaborando en el proyecto.  Es más importante la capacidad de respuesta ante un cambio realizado que el seguimiento estricto de un plan. 4.2. VENTAJAS Y DESVENTAJAS Ventajas:  La primera y más importante, es que estas metodologías ofrecen una rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como después poder modificarlos evitando grandes pérdidas en cuanto a costes, motivación, tiempo.  El cliente, si quiere colaborar, puede observar cómo va avanzando el proyecto, y por supuesto, opinar sobre su evolución gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.  Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologías, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 36 | P á g i n a pequeño intervalo de tiempo un pequeño “trozo” del proyecto al cliente, y si éste quiere cambiarlo, solo se habrá perdido unas semanas de trabajo. Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando meses para que luego un mínimo cambio que quiera realizar el cliente, conlleve la pérdida de todo ese trabajo.  Importancia de la simplicidad al eliminar trabajo innecesario Otros beneficios de las metodologías ágiles.  Simplificación de la sobrecarga de procesos Los equipos que trabajan para crear productos regulados por estándares de la industria, deben demostrar el cumplimiento de esas normas. Estos equipos suelen adoptar importantes sobrecargas de trabajo para asegurarse de que cumplen con los estrictos mandatos de código. Las metodologías ágiles pueden ayudarles a cumplir los estándares de la industria con menos sobrecarga utilizando iteraciones más cortas y empaquetadas. El beneficio neto es un proceso que: o Puede adaptarse a los cambios que, inevitablemente, surgirán o Requiere menos sobrecarga en el proceso end-to-end o Implica menos trabajo a medida que se acerca la fecha final  Calidad mejorada Las prácticas de desarrollo ágil proporcionan la funcionalidad suficiente como para satisfacer las expectativas de los accionistas con una alta calidad. Piensa en lo que significa “ofrecer lo suficiente”. Eso es, proporcionar la mínima funcionalidad con la máxima calidad. La mínima funcionalidad no implica necesariamente una pobre funcionalidad, implica lo suficiente como para conseguir que el trabajo se realice. Los accionistas suelen pensar que saben lo que quieren cuando especifican altos niveles de requerimientos para un producto TI o de software. Sin embargo, la mayoría de las veces, cuando ven el producto final, éste no resuelve el problema. Simplemente, no se han imaginado de forma precisa el mismo, o el problema ha cambiado o, incluso, la tecnología no era tan buena como parecía. También puede ser que el producto no funcione realmente del modo en que las partes interesadas tenían intención, incluso aunque pensaran que habían descrito los requerimientos de manera clara. Desarrollar iteraciones en poco tiempo y demostrar a los accionistas los productos pronto y con frecuencia, permite tanto a los accionistas como a los equipos de desarrollo ponerse de acuerdo y coincidir en que el producto cumple con cada una de sus necesidades. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 39 | P á g i n a 4.3. TIPOS DE METODOLOGIAS 4.3.1. WATERFALL (CASCADA) En Ingeniería de software el desarrollo en cascada, es denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases. Es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida. Este modelo comenzó a diseñarse en 1966 y se terminó alrededor de 1970. El principal problema de esta aproximación es el que no podemos esperar que las especificaciones iníciales sean correctas y completas y que el usuario puede cambiar de opinión sobre una u otra característica. Además los resultados no se pueden ver hasta muy avanzado el proyecto por lo que cualquier cambio debido a un error puede suponer un gran retraso además de un alto coste de desarrollo. Como es evidente esto es solo un modelo teórico, si el usuario cambia de opinión en algún aspecto tendremos que volver hacia atrás en el ciclo de vida. Figura Nº 3 – Modelo del ciclo de vida en Cascada (Waterfall). _____________________ Figura Nº 3 Extraída de [3] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 40 | P á g i n a Ingeniería y Análisis del Sistema: debido que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. Análisis de los requisitos del software: el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas. Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación. Codificación: el diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Mantenimiento: el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a se han encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Desventajas:  Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.  Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.  El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa esté funcionando puede ser desastroso. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 41 | P á g i n a 4.3.2. PROTOTYPING Un prototipo es una versión preliminar de un sistema de información con fines de demostración o evaluación. El prototipo de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipo puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipo puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo. El prototipo ha sido usado frecuentemente en los 90, porque la especificación de requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación convenientemente basada en la manipulación, leer una especificación de requerimientos potencialmente ambigua y extensa. Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente. En caso que ustedes construyan requerimientos bien entendidos, el cliente podría responder con "sí, así es", y nada podría ser aprendido de la experiencia.  Es un método menos formal de desarrollo.  El prototipo es una técnica para comprender las especificaciones.  Un prototipo puede ser eliminado.  Un prototipo puede llegar a ser parte del producto final. Ventajas:  Útiles cuando los requerimientos son cambiantes.  Cuando no se conoce bien la aplicación.  Cuando el usuario no se quiere comprometer con los requerimientos.  Cuando se quiere probar una arquitectura o tecnología.  Cuando se requiere rapidez en el desarrollo. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 44 | P á g i n a El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificación, diseño, realización y evaluación (o conceptos y términos análogos). En cada fase el producto gana “madurez” (aproximación al final deseado) hasta que en una iteración se logre el objetivo deseado y este sea aprobado se termina las iteraciones. 4.3.4. INCREMENTAL Permite construir el proyecto en etapas incrementales en donde cada etapa agrega funcionalidad. Estas etapas, consisten en requerimientos, diseño, codificación, pruebas y entrega. Permite entregar al cliente un producto más rápido en comparación del modelo en cascada.  Reduce los riegos ya que provee visibilidad sobre el progreso de las nuevas versiones.  Provee retroalimentación a través de la funcionalidad mostrada.  Permite atacar los mayores riesgos desde el inicio.  Se pueden hacer implementaciones parciales si se cuenta con la suficiente funcionalidad.  Las pruebas y la integración son constantes.  El progreso se puede medir en periodo cortos de tiempo.  Resulta más sencillo acomodar cambios al acortar el tamaño de los incrementos.  Se puede planear en base a la funcionalidad que se quiere entregar primero.  Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico. Ventajas:  La solución se va mejorando en forma progresiva a través de las múltiples iteraciones, incrementa el entendimiento del problema y de la solución por medio de los refinamientos sucesivos.  Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.  Los clientes pueden aclarar los requisitos que no tengan claros, conforme ven las entregas del sistema.  Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.  Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 45 | P á g i n a Desventaja:  Requiere de mucha planeación, tanto administrativa como técnica  Requiere de metas claras para conocer el estado del proyecto.  Es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. Para apoyar el desarrollo de proyectos por medio de este modelo se han creado Framework (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process (RUP) y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software. Figura Nº 6 – Modelo del ciclo de vida Incremental. ______________________ Figura Nº 6 Extraída de [6] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 46 | P á g i n a 4.3.5. RAD La metodología de desarrollo conocida como diseño rápido de aplicaciones RAD (rapid application development) ha tomado gran auge debido a la necesidad que tienen las instituciones de crear aplicaciones funcionales en un plazo de tiempo corto. RAD es un ciclo de desarrollo diseñado para crear aplicaciones de computadoras de alta calidad. El método comprende el desarrollo interactivo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. Hoy en día se suele utilizar para referirnos al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Lazarus, Gambas, Delphi, Foxpro, Anjuta, Game Maker, Velneo o Clarion. En el área de la autoría multimedia, software como Neosoft Neoboo y MediaChance Multimedia Builder proveen plataformas de desarrollo rápido de aplicaciones, dentro de ciertos límites. Fases del RAD  Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesó?  Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.  Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.  Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 49 | P á g i n a  Más fallas (por síndrome de “codificar a lo bestia”).  Prototipos pueden no escalar, un problema mayúsculo.  Funciones reducidas (por “timeboxing”).  Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales. Figura Nº 7 – Modelo del ciclo de vida RAD. _____________________ Figura Nº 7 Extraída de [7] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 50 | P á g i n a 5. METODOLOGIAS AGILES 5.1. INTRODUCCION En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas pretendieron ser la clave para el éxito en el desarrollo de software, no obstante, las expectativas no fueron satisfechas del todo. Esto se debe en gran parte a que otro importante elemento, la metodología de desarrollo, había sido postergado. De nada sirven buenas notaciones y herramientas si no se proveen directivas eficientes para su aplicación. Hasta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado y eficiente para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la ingeniería del software, asumiendo el riesgo que esto conlleva. Esto puede dar la impresión de que se van a hacer mal las cosas o de dejarlo a medias pero lo cierto es que ser “ágiles" no significa renunciar a formalismos ni dejar de ser estrictos, rigurosos y metódicos. En esta profesión y sobre todo en el área del desarrollo de software, la teoría nos orienta a ser extremadamente estrictos al momento de hacer el análisis y documentación de nuestro sistema, pero en la práctica actual no se puede perder tanto tiempo realizando estas tareas porque cuando se finaliza el sistema, éste ya ha cambiado y el cliente se ha aburrido. Ser abducido y caer en esta nueva dinámica, es muy fácil, cuando la presión nos cae encima y los plazos de entrega se acercan y cada vez se acortan más. La alta competitividad actual hace que los sistemas de información se tengan que desarrollar de forma rápida para adaptarse a la organización. Las prisas hacen que lo primero que se deseche sea un análisis exhaustivo y se sustituye por uno superficial o simplemente se elimina. Éste es sin duda el gran error, ya que deseamos tener un sistema desarrollado rápidamente pero con lo que realmente nos encontramos es con un sistema lleno de errores, inmanejable y que no se puede mantener. Es difícil cambiar las reglas del mercado mundial, así que lo que se ha pensado es adaptar las metodologías de especificación y desarrollo a este entorno cambiante y lleno de presiones, en el que obtener un resultado rápido, algo que se pueda ver, mostrar y sobre todo utilizar, se ha vuelto crucial para el éxito de las organizaciones. La metodología necesariamente ha de ser ágil, debe tener un ciclo corto de desarrollo y debe incrementar las funcionalidades en cada iteración del mismo preservando las existentes, ayudando al negocio en lugar de darle la espalda. Es para este entorno para el que han nacido las metodologías ágiles y como consecuencia se creó el Manifiesto Ágil. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 51 | P á g i n a El Manifiesto Ágil describe, básicamente, cuales son los principios sobre los que se basan los métodos reconocidos como ágiles. Éste manifiesto sugiere un enfoque orientado a la participación de los usuarios y clientes, más que hacia los procesos y herramientas, trabajando más en el software y menos en la documentación, colaborando más con los clientes en vez de estar negociando y respondiendo a los cambios sacrificando el plan de trabajo si es necesario. En el "Manifiesto ágil" se definen los cuatro valores principales por las que se deberían guiar las metodologías ágiles. 1. Al individuo y sus interacciones más que al proceso y las herramientas. 2. Desarrollar software que funciona más que obtener una documentación exhaustiva. 3. La colaboración con el cliente más que la negociación de un contrato. 4. Responder a los cambios más que seguir una planificación. El significado de cada uno de estos valores son los siguientes: 1. Al individuo y sus interacciones más que al proceso y las herramientas. Sin duda, la herramienta fundamental de la ingeniería del software y del desarrollo de aplicaciones es el cerebro humano y nuestra capacidad para desarrollar y desenvolvernos con nuestro entorno. Una persona sola no realiza un proyecto, necesita de un entorno en el que desarrollar su trabajo y de un equipo con el que colaborar. Estas interacciones deben también cuidarse. Un factor clave para el éxito es construir un buen equipo, que se lleven bien entre ellos, y que además sepan cómo construir su propio entorno de desarrollo. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte a él. Esto nos resta eficiencia, es mejor que el equipo se configure sobre la base de sus necesidades y sus características personales. Además, las interacciones que haga el equipo con el usuario final deberían ser igual de fluidas siendo este usuario un miembro más del equipo, con un objetivo común, que es conseguir que el proyecto funcione y sea útil para él. Si todo esto funciona bien, la elección de las herramientas y el proceso mismo de desarrollo pasan a estar en un plano totalmente secundario en la ecuación del éxito del proyecto. 2. Desarrollar software que funciona más que obtener una documentación exhaustiva. Uno de los objetivos de una buena documentación es poder ir a consultarla cuando haya que modificar algo del sistema o surja alguna incertidumbre. Sin duda es un arma de doble filo, una buena documentación actualizada en cada modificación y bien mantenida al día permite saber el estado de la aplicación y cómo realizar las modificaciones pertinentes, pero Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 54 | P á g i n a 5.2. BENEFICIOS Durante la década pasada, las metodologías ágiles demostraron ser muy beneficiosas ayudando a los equipos de desarrollo de software a la hora de entregar en fecha software de alta calidad que compensara las necesidades de los clientes. Los equipos de software quieren trabajar con metodologías ágiles porque necesitan un proceso que pueda responder de manera eficiente a los cambios en los productos en desarrollo. Las metodologías ágiles permiten una mayor flexibilidad que las metodologías tradicionales de desarrollo, ya que éstas se bloquean y ralentizan en los detalles del proyecto y son menos capaces de ajustarse a las cambiantes necesidades de los clientes, del mercado y de los desafíos imprevistos que plantea la tecnología y el medio ambiente. Algunos de los beneficios son los siguientes: 1. Simplificación de la sobrecarga de procesos Los equipos que trabajan para crear productos regulados por estándares de la industria, deben demostrar el cumplimiento de esas normas. Estos equipos suelen adoptar importantes sobrecargas de trabajo para asegurarse de que cumplen con los estrictos mandatos de código. Las metodologías ágiles pueden ayudarles a cumplir los estándares de la industria con menos sobrecarga utilizando iteraciones más cortas y empaquetadas. El beneficio neto es un proceso que:  Puede adaptarse a los cambios que, inevitablemente, surgirán  Requiere menos sobrecarga en el proceso end-to-end  Implica menos trabajo a medida que se acerca la fecha final 2. Calidad mejorada Las prácticas de desarrollo ágil proporcionan la funcionalidad suficiente como para satisfacer las expectativas de los clientes con una alta calidad. Eso es, proporcionar la mínima funcionalidad con la máxima calidad. La mínima funcionalidad no implica necesariamente una pobre funcionalidad, sino que implica lo suficiente como para conseguir que el trabajo se realice. Los clientes suelen pensar que saben lo que quieren cuando especifican altos niveles de requerimientos para un producto de software. Sin embargo, la mayoría de las veces, cuando ven el producto final, éste no resuelve el problema. Simplemente, no se han imaginado de forma precisa el mismo, o el problema ha cambiado o, incluso, la tecnología no era tan buena como parecía. También puede ser que el producto no funcione realmente del modo en que las partes interesadas tenían intención, incluso aunque pensaran que habían descrito los requerimientos de manera clara. Desarrollar iteraciones en poco tiempo y demostrar a los clientes los productos pronto y con frecuencia, permite tanto a los clientes como a los equipos de desarrollo ponerse de acuerdo y coincidir en que el producto cumple con cada una de sus necesidades. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 55 | P á g i n a 3. Mejorar la previsibilidad a través de una mejor gestión del riesgo Cuando los equipos de desarrollo no cumplen con sus fechas de lanzamiento, a menudo se debe a muchas razones completamente justificables. Puede ser que el equipo no hubiera entendido bien lo complejo que sería utilizar la nueva tecnología, los requerimientos podían no estar del todo claros o los clientes cambiaron de opinión cuando el trabajo estaba prácticamente finalizado. En cualquier caso, los negocios demandan productos que cumplan con las fechas de entrega, de modo que los planes de negocio directamente relacionados con ellos puedan cumplirse. Hay muchas formas en las que las metodologías ágiles pueden ayudar a que los proyectos cumplan con las fechas de lanzamiento previstas. Dar prioridad a los riegos. Las prácticas ágiles priorizan los aspectos de desarrollo de alto riesgo permitiendo así una reducción de los riesgos iniciales. Evaluación de riesgos en paralelo. Para áreas de riesgo donde debería haber múltiples soluciones y el equipo no se pone de acuerdo a la hora de tomar el camino más adecuado, se debe tener en cuenta la posibilidad de optar por el desarrollo multi-set. Esto requiere que diferentes equipos trabajen en paralelo resolviendo el mismo problema con diferentes soluciones. La mayoría de los equipos no considerarán ni tan siquiera esta forma de trabajar, porque están convencidos de que el tiempo y el coste requeridos para hacer una evaluación paralela son demasiado grandes. De hecho, el desarrollo paralelo de alternativas es probable que traiga consigo las decisiones clave a seguir. 4. Mejor perfil de productividad Los equipos ágiles son más productivos que aquellos que utilizan métodos tradicionales a lo largo de todo el ciclo de desarrollo. El desarrollo tradicional comienza con un ciclo de diseño de abajo arriba, moviéndose hasta una fase de prototipo para pasar luego a un ciclo de desarrollo largo, seguido por otro ciclo totalmente impredecible en el que se integran las piezas para pasar, por último, a la fase de prueba final. A medida que el proyecto progresa, los equipos tienen que trabajar juntos de manera más coherente, confiando en que todas las piezas trabajen juntas tal y como esperan. Pero lo cierto es que esto raramente ocurre, de modo que la interacción entre los equipos aumenta a medida que lo hacen los problemas de integración. Por último, la fase de pruebas lleva todo esto al límite. Trabajando juntos como un único equipo en fases verticales del producto desde el principio del ciclo de producción, se evita el ciclo de productividad tradicional. Los equipos ágiles tienden a ser muy productivos desde la primera iteración hasta su lanzamiento y su ritmo tiene que ser gestionado de modo que no se produzca agotamiento. Los equipos ágiles que mantienen este código de trabajo con cada iteración, permiten realizar pruebas de rendimiento y sistemas desde el principio, pudiendo empezar en las primeras iteraciones. De este modo, defectos críticos como problemas de integración se descubren antes, la calidad general del producto es mayor y el equipo funciona de manera más productiva durante todo el ciclo de desarrollo. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 56 | P á g i n a 5. Capacidad para aprovechar las inversiones realizadas Adoptar las técnicas ágiles de manera satisfactoria impone un importante soporte de herramientas. La mayoría de los equipos invierten fuertemente en buenas herramientas de software y necesitan elevar esa inversión y reducir la cantidad de cambios cuando empiezan a adoptar las metodologías ágiles. La inversión más crítica es una buena planificación y una herramienta de gestión del trabajo que proporcione una cartera de pedidos del equipo visible y que asocie el trabajo con cada elemento de trabajo en cartera. Idealmente, esa herramienta de planificación se integra con otras herramientas de desarrollo, lo que permite a los equipos mantener la trazabilidad de la cartera de pedidos en otros aspectos, incluyendo:  Los requerimientos que la impulsan.  La arquitectura bajo desarrollo.  El software de la solución.  Las pruebas que validan la solución. Algunas de las herramientas más conocidas para la gestión y administración de proyectos ágiles son:  Team Foundation Server (Microsoft)  Rational (IBM)  HP Quality Center (Hewlett Packard) 6. Realimentación continua con el cliente De forma temprana el cliente recibe entregables de valor, lo que permite ver los constantes avances, logrando así, aportar en lo necesario para que el equipo vaya construyendo en la dirección correcta lo anterior, inmediatamente reduce de forma drástica los errores y la posibilidad de costosas correcciones, respondiendo a los cambios en requisitos de forma rápida y eficaz. El cliente es una parte más del equipo. 7. Equipo motivado Cuando se realiza un proyecto aplicando alguna de las metodologías agiles, las personas involucradas en el mismo están más motivadas ya que pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo. Esto hace que las personas se sienten más satisfechas cuando pueden mostrar los logros que consiguen tomando sus propias decisiones. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 59 | P á g i n a Figura Nº 9 – Curva de relación Coste/Tiempo en metodologías tradicionales. Lo que XP mantiene es que esta curva ha perdido vigencia y que con una combinación de buenas prácticas de programación y tecnología es posible lograr que la curva no crezca siempre de forma exponencial. XP pretende conseguir una curva de coste del cambio con crecimiento leve, que en un inicio es más costosa, pero que a lo largo del proyecto permite tomar decisiones de desarrollo lo más tarde posible sin que esa nueva decisión de cambio implique un alto coste en el proyecto. Figura Nº 10 – Curva de relación Coste/Tiempo en metodologías ágiles. La programación extrema, propone una ecuación de equilibrio entre el coste, el tiempo de desarrollo, la calidad del software y el alcance de funcionalidades del mismo. _______________________ Figura Nº 9 Extraída de [9] Figura Nº 10 Extraída de [10] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 60 | P á g i n a Las variables: coste, tiempo, calidad y alcance El punto de partida de la metodología XP son las variables que utiliza para cada proyecto:  Coste (la inversión económica y en recursos).  Tiempo (el tiempo empleado, determinado por la fecha de entrega final).  Calidad (del código y del aplicativo desarrollado).  Alcance (Conjunto de funcionalidades). De estas cuatro variables, tres podrán ser fijadas por el cliente y/o por el jefe de proyectos, la cuarta es responsabilidad del equipo de desarrollo y se establecerá en función de las otras tres. Obviamente con XP no se establece el valor de todas las variables a la primera de cambio, es un proceso paulatino en el que cada uno de los responsables (cliente, jefe de proyecto y equipo de desarrollo) negocian los valores de las variables que tienen asignadas hasta conseguir una ecuación equilibrada y que satisfaga a todos. Distinguir entre los requisitos más importantes y los que aportan menor valor al negocio, dando prioridad a los primeros, nos ayudará a conseguir que el proyecto tenga en cada instante tanta funcionalidad como sea posible. De esta manera, cuando nos acerquemos al plazo de entrega nos aseguraremos de que lo principal está implementado y que sólo quedarán los detalles de los que podemos prescindir en el caso de necesidad. El objetivo es siempre maximizar el valor de negocio. Los valores: comunicación, simplicidad, realimentación y coraje Los creadores de esta metodología quisieron medir su utilidad a través de cuatro valores, que representan aquellos aspectos cuyo cumplimiento nos va a garantizar el éxito en el proyecto: comunicación, simplicidad, realimentación y coraje.  Comunicación: debe ser fluida entre todos los participantes en el proyecto. El entorno tiene que favorecer la comunicación espontánea, ubicando a todos los miembros en un mismo lugar. La comunicación directa nos da mucho más valor que la escrita, podemos observar los gestos del cliente, o la expresión de cansancio de nuestro compañero.  Simplicidad: cuanto más sencilla sea la solución, más fácilmente podremos adaptarla a los cambios. Las complejidades aumentan el coste del cambio y disminuyen la calidad del software. Sólo se utiliza lo que en ese momento nos da valor, y lo haremos de la forma más sencilla posible. Esto podría dar a pensar que va en contra de toda la filosofía de diseño y utilización de patrones. Nada más alejado de la realidad. En un proyecto XP, el uso de patrones nos va a ayudar a reducir el tiempo de implantación, pero lo que no vamos a hacer es dedicar tiempo a la implementación de patrones que no vayamos a utilizar en este proyecto, sólo haremos los que sean necesarios para éste, no utilizaremos tiempo del proyecto para beneficiar a otro proyecto futuro que quizás no llegue nunca. Por otro lado, nada nos impide Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 61 | P á g i n a desarrollar un proyecto que únicamente se dedique a desarrollar patrones que más tarde se utilicen en proyecto XP.  Realimentación: el usuario debe utilizar y probar el software desarrollado desde la primera entrega, dándonos sus impresiones y sus necesidades no satisfechas, de manera que estas cosas encontradas vuelvan a formar parte de los requisitos del sistema y así poder atacarlas con tiempo.  Coraje: con XP debemos tocar continuamente cosas que ya funcionan, para mejorarlas, optimizarlas o agregar funcionalidad. Es por eso que el coraje es parte del proyecto también, ya que el miedo a tocar o modificar cosas que ya funcionan perfectamente, a veces puede ser difícil. Las doce prácticas básicas de XP Kent Beck, Ward Cunninghamn y Ron Jeffries tenían muy claro las prácticas que les habían dado mejores resultados en sus proyectos. Así que intentaron aplicarlas todas juntas dando una vuelta de tuerca. Ésa fue la semilla de la metodología de Programación Extrema. Crearon las doce prácticas que se refuerzan entre sí para obtener los mejores resultados. Las relaciones entre ellas las podemos ver en el siguiente gráfico: Figura Nº 11 – Prácticas de la Programación Extrema. _______________________ Figura Nº 11 Extraída de [11] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 64 | P á g i n a If (vbPeriodo_no_calculable) {odFinal_Periodo = pdInicio_Periodo;} tengo mucha más información que si hubiese visto la siguiente: If (pnc) { fp = ip;} El funcionamiento es el mismo y ambas sentencias están bien codificadas, pero la primera nos da el valor añadido de la comprensión de la codificación estándar. 4. Propiedad colectiva del código: para poder aplicar la refactorización y para asegurarnos de que el diseño es simple y que se codifican según los estándares, tenemos que eliminar otra de las ideas que están muy arraigadas en el mundo del desarrollo de aplicaciones que es la “propiedad individual del código”. Frases como "que lo modifique quien lo hizo que seguro que lo entiende mejor" o "¿quién ha tocado mi función?" dejan de tener sentido en XP, ya que el diseño simple nos garantiza que será fácilmente entendible, la refactorización permite que cualquier miembro del equipo rehaga el código, los test automatizados nos garantizan que no hemos modificado el comportamiento esperado del código con nuestra modificación, y la codificación con estándares nos da ese grado de comprensión adicional. En XP el código es propiedad de todo el equipo y cualquier miembro tiene el derecho y la obligación de modificarlo, para hacerlo más eficiente o comprensible, sin que nadie se tenga por qué sentir ofendido o con miedo de tocar algo. 5. Programación por parejas: la programación siempre se ha visto como algo solitario, y tener dos personas delante de un solo teclado y de un solo monitor sorprende en un inicio. Pero las ventajas son muchas. Nos es muy complicado pensar a nivel abstracto y luego pasar a pensar a nivel concreto, y si lo hacemos de forma continua, acabamos desconcentrados y cometemos errores. Es por esto por lo que, cuando programamos, primero pensamos la estrategia de codificación que vamos a seguir y luego nos ponemos a codificar cada una de las partes, sin pensar de nuevo a nivel estratégico hasta que no finalizamos alguna de las partes o a veces la totalidad del código, y entonces vemos los errores o las cosas que nos hemos dejado en la estrategia de codificación original. Pensar a lo grande y en detalle a la vez nos es imposible con un solo cerebro. En la programación en parejas uno de los miembros debe estar pensando a nivel táctico y el otro a nivel estratégico de manera que esos dos procesos siempre estén activos reduciendo así los errores y mejorando la calidad del programa. Obviamente, estos dos roles deben intercambiarse cada poco tiempo entre los miembros de la pareja para abarcar todas las posibilidades tácticas y estratégicas. El nivel de los miembros de la pareja ha de ser equivalente, no sirve que uno sepa mucho y otro no tenga ni idea, deben de estar equilibrados y obviamente llevarse bien para que tenga éxito. También la rotación ha de ser muy importante, cada miembro del equipo ha de ser capaz de trabajar en cualquier área de la aplicación que se esté desarrollando. De esta manera no provocaremos cuellos de botella cuando asignemos las tareas. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 65 | P á g i n a El hecho de que asignemos las tareas por parejas hace que el tiempo de aprendizaje se reduzca casi a cero, simplemente sustituyendo uno de los miembros por otro nuevo. Así pues, la rotación de áreas y de parejas nos garantiza que podremos hacer un reparto más equitativo del trabajo sin tener que depender de una sola persona para un trabajo específico. Otro efecto que produce la programación en parejas es el psicológico, disminuye la frustración de la programación en solitario, tienes a alguien que entiende el problema justo al lado, y con el que compartir el problema. Además, muchas veces los problemas vienen por falta de concentración y se tiene la solución delante de nosotros y no se ve, y se pierde mucho tiempo. 6. Integración continúa: en XP no esperamos a que todas las partes estén desarrolladas para integrarlas en el sistema, sino que a medida que se van creando las primeras funcionalidades ya se ensamblan en el sistema, de manera que éste puede ser construido varias veces durante un mismo día. Esto se hace para que las pruebas de integración vayan detectando los errores desde el primer momento y no al final de todo y hace que el impacto sea mucho menor. Es responsabilidad de cada equipo publicar lo antes posible cada funcionalidad o cada modificación. La idea es que todos los miembros del equipo trabajen con la última versión del código, para así evitar pisar versiones desarrolladas por otros compañeros y también poder interactuar nuestro código con la última versión vigente y así evitar posibles errores de compatibilidad. 7. 40 horas semanales: no se pueden trabajar durante 14 horas seguidas y hacerlo con calidad. Las semanas de 70 horas de trabajo son contraproducentes. Al final de la semana se tiene que llegar cansado pero satisfecho, nunca exhausto ni desmotivado. Trabajar horas extras disminuye la moral y el espíritu del equipo. Si durante dos semanas hay que hacer horas extras, entonces es que el proyecto va mal y se debe replantear alguna de las cuatro variables. 8. Metáfora del negocio: para que dos o más personas se puedan comunicar de forma eficiente, deben tener el mismo vocabulario y compartir el mismo significado. El modelo de negocio que entiende el usuario final seguramente no se corresponderá con el que cree entender el programador. Es por esto por lo que en los equipos de XP se debe crear una "metáfora" con la que el usuario final se encuentre cómodo y que le sirva al equipo de desarrollo a la hora de modelar las clases y métodos del sistema. La metáfora, es un requerimiento común compartido por el usuario y el equipo de desarrollo que describe cómo deben comportarse las diferentes partes del sistema que se quiere implementar, en un alto nivel de abstracción. 9. Cliente in situ: en más de una ocasión, cuando estamos programando o analizando el sistema, nos surge una duda y pensamos en que cuando veamos al usuario final se la preguntaremos. Posiblemente tengamos que seguir trabajando sin resolver esa duda y, si nuestra suposición Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 66 | P á g i n a ha sido errónea, mucho del trabajo realizado puede ser en vano y así haber aumentado el coste de nuestro proyecto. XP necesita que el cliente final forme parte del equipo de desarrollo y esté ubicado físicamente en el mismo sitio para que así se agilice el tiempo de respuesta y se puedan validar todas las funcionalidades lo antes posible. En XP, el cliente siempre tiene que estar disponible para el resto del equipo, formando parte de él y fomentando la comunicación cara a cara, que es la más eficiente de las comunicaciones posibles. 10. Entregas frecuentes: Se deben desarrollar lo antes posible versiones pequeñas del sistema, que aunque no tengan toda la funcionalidad, nos den una idea de cómo ha de ser la entrega final y que nos sirvan para que el usuario final se vaya familiarizando con el entorno y para que el equipo de desarrollo pueda ejecutar las pruebas de integridad. Las nuevas versiones tienen que ser tan pequeñas como sean posibles, pero tienen que aportar un nuevo valor agregado del negocio para el cliente. Dar valor al negocio es lo que hará que la visión final del cliente sea la mejor posible. 11. Planificación incremental: la planificación nunca será perfecta, variará en función de cómo varíen las necesidades del negocio y en cada ciclo de re planificación se volverán a establecer las cuatro variables de la metodología XP. Asumir una planificación estática no corresponde con la agilidad que queremos dar, ya que las necesidades del negocio pueden cambiar drásticamente mientras estamos desarrollando el aplicativo. En XP la planificación se va revisando continuamente, de forma incremental, priorizando aquellas necesidades de negocio que nos aporten mayor valor. La planificación se plantea como un permanente diálogo entre los responsables de la perspectiva empresarial y de la perspectiva técnica del proyecto. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 69 | P á g i n a No debemos confundir las historias de usuario con el análisis de requisitos, la principal diferencia está en la profundidad de análisis, con los requisitos queremos llegar al último detalle para no quedar mal frente al cliente, pero en XP el cliente forma parte del equipo y le podemos preguntar más cosas durante la implementación, así que el nivel de detalle en las historias de usuario ha de ser el mínimo imprescindible para que nos hagamos una idea general de la funcionalidad. Las historias de usuario han de ser:  Escritas por el cliente final, en su lenguaje y sin tecnicismos.  Descripciones cortas de la usabilidad y funcionalidad que se espera del sistema. Paralela y conjuntamente se empieza con el spike arquitectónico, en el que el equipo de desarrollo empieza a familiarizarse con la metodología, herramientas, lenguaje y codificaciones que se van a usar en el proyecto. En el spike arquitectónico el equipo de desarrollo:  Prueba la tecnología.  Se familiariza con la metodología.  Se familiariza con las posibilidades de la arquitectura.  Realiza un prototipo que demuestre que la arquitectura es válida para el proyecto. Una vez finalizadas las historias de usuario y el spike arquitectónico, se pasa a desarrollar conjuntamente la metáfora del negocio. La metáfora del negocio:  Es una historia común compartida por el usuario y el equipo de desarrollo.  Debe servir para que el usuario se sienta a gusto refiriéndose al sistema en los términos de ella.  Debe servir a los desarrolladores para implementar las clases y objetos del sistema. 2. La fase de planificación: el resultado ha de ser una planificación, de manera flexible, del proyecto. El procedimiento es el siguiente:  El cliente entrega al equipo de desarrollo las historias de usuario que ha confeccionado, pero priorizándolas de mayor a menor importancia.  El equipo de desarrollo las estudia y estima el coste de implementarlas.  Si el equipo de desarrollo considera que la historia de usuario es demasiado compleja, entonces el usuario final debe descomponerla en varias historias independientes más sencillas.  Si el equipo de desarrollo no ve claro cómo implementar una parte de la historia, el usuario puede realizar un spike tecnológico para ver cómo se podría implantar y así poder evaluar el coste. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 70 | P á g i n a  Una vez tenemos la lista de historias priorizadas junto con su coste de implementación, pasamos a convocar la reunión del plan de entregas. El plan de entregas se compone de una serie de planes de iteración en el que se especifica qué funcionalidades se van a implementar en cada vuelta de la fase de iteraciones. Participan de esta reunión tanto los usuarios como el equipo técnico y cada uno debe aportar su visión del negocio de manera que se obtengan más rápidamente aquellas funcionalidades que den el mayor beneficio para el negocio posible. A cada iteración se le asigna un tiempo intentando que todas sean lo más parecido posible. Se determina el alcance del proyecto. 3. La fase de iteraciones: como hemos dividido el proyecto en iteraciones, esta fase se repetirá tantas veces como iteraciones tengamos. Generalmente, cada iteración suele ser de dos a tres semanas. El plan de iteración se trata de la siguiente manera:  Se recogen las historias de usuario asignadas a esta iteración.  Se detallan las tareas a realizar por cada historia de usuario.  Las tareas deben ser de uno o tres días de desarrollo. Si son más grandes, se debería intentar dividir en varias más sencillas.  Se estima el coste de cada tarea. Si el total es superior al tiempo de iteración, se deberá prescindir de alguna historia de usuario que se pasaría a la siguiente iteración. Si son muchas las historias de usuario desechadas, entonces hay que volver a estimar las cuatro variables de la metodología y volver a planificar el proyecto.  Si el tiempo total estimado de las tareas es inferior al tiempo de iteración, se puede asumir una historia de usuario que correspondiese a la siguiente iteración.  Se priorizan las tareas que más valor darán al negocio, intentando que se finalicen historias de usuario lo antes posible.  Se reparten las primeras tareas al equipo de desarrollo y el resto se deja en una cola de tareas sin asignar de dónde se irán tomando a medida que se vayan finalizando las anteriores. Se convocan reuniones de seguimiento diarias para ver si nos vamos retrasando en las estimaciones o nos vamos adelantando a ellas y así poder desechar o incorporar historias de usuario. Lo más importante es que en cada momento de cada iteración estemos realizando la tarea que más valor posible da al negocio de entre las que tenemos pendientes, de manera que, si tenemos que reducir el alcance del proyecto, sólo afecte a las funcionalidades secundarias de nuestro aplicativo. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 71 | P á g i n a 4. La fase de producción: llegamos a esta fase al alcanzar la primera versión que el usuario final decida que puede ponerse en producción. Pasaremos el aplicativo a producción cuando alcance las funcionalidades mínimas que aporten un valor real al negocio y una operativa arquitectónica estable. Es decir, no esperamos a tener todas las funcionalidades implementadas, sino que en cuanto tenemos algo que los usuarios pueden utilizar y que ayuda al negocio, pasamos la primera versión a producción. Paralelamente, se sigue con las iteraciones finales de proyecto. De esta manera, antes de que finalice el proyecto, ya estamos dando valor a la organización, el ROI (retorno de la inversión) del proyecto empieza a generarse antes de que éste finalice su versión final. En la etapa de producción se realizan también iteraciones como en la anterior etapa, pero el ritmo de éstas ya no es de dos a tres semanas, sino mensuales. Esta fase se mantiene hasta que realizamos la última entrega, con la que finalizamos el ámbito del aplicativo y pasamos al mantenimiento del mismo. Durante la fase de producción, el ritmo de desarrollo decae debido a que el equipo debe solventar las incidencias de los usuarios. Es por esto por lo que a veces es necesario incorporar nuevo personal al equipo. 5. La fase de mantenimiento: una vez el alcance del proyecto se ha conseguido, y tenemos todas las funcionalidades en producción, se revisan con el usuario aquellas nuevas historias de usuario que se han producido tras la puesta en producción del proyecto. Estas nuevas funcionalidades se van incorporando según su valor de negocio y el presupuesto adicional del que se disponga. El equipo de desarrollo se reduce a la mínima expresión, dejando algunos miembros para el mantenimiento. 6. La fase de muerte del proyecto: Cuando no existen más historias de usuario para introducir en nuestro sistema o cuando se reduce progresivamente valor de las historias de usuario implementadas en él, el proyecto entra en la fase de muerte. Se irá desinvirtiendo en él hasta abandonarlo totalmente cuando no aporte valor al negocio o cuando sus historias de usuario hayan sido absorbidas por otro sistema de información. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 74 | P á g i n a Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. Fundamentos de Scrum Scrum se basa en los siguientes puntos:  El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Las iteraciones se pueden entender como mini proyectos, en todas las iteraciones se repite un proceso de trabajo similar (de ahí el nombre “iterativo”) para proporcionar un resultado completo sobre el producto final, de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental. Para ello, cada requisito se debe completar en una única iteración. El equipo debe realizar todas las tareas necesarias para completarlo (incluyendo pruebas y documentación) y que esté preparado para ser entregado al cliente con el mínimo esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos.  La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración. Para que un proyecto proporcione el mejor resultado posible, y como soporte fundamental al control empírico del proyecto, es necesario repriorizar los requisitos de manera regular, en cada iteración, según el valor que proporcionan al cliente en ese momento y su coste estimado de desarrollo. Como resultado de esta re priorización se actualiza la lista de requisitos priorizada (Product Backlog).  El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al cliente el resultado real obtenido, de manera que pueda tomar las decisiones necesarias en función de lo que observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones necesarias.  La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le otorga la autoridad necesaria para organizar su trabajo.  La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el cliente.  El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir resultados. La técnica del timebox consiste en fijar el tiempo máximo para conseguir ciertos objetivos, tomar una decisión o realizar unas tareas, y hacer lo mejor que podamos en ese Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 75 | P á g i n a intervalo. De esta manera, en lugar de ponerse a trabajar en algo hasta que esté hecho, de antemano se acuerda que sólo se dedica un tiempo limitado. La consciencia de esta limitación temporal favorece la priorización de objetivos/tareas y fuerza la toma de decisiones. Requisitos para poder utilizar Scrum Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de proyectos como Scrum:  Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continua.  Compromiso del cliente en la dirección de los resultados del proyecto, gestión del ROI y disponibilidad para poder colaborar.  Compromiso de la Dirección de la organización para resolver problemas frecuentes y realizar cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación llevada a cabo por líderes al servicio del equipo.  Compromiso conjunto y colaboración de los miembros del equipo.  Relación entre proveedor y cliente basada en la colaboración y transparencia.  Facilidad para realizar cambios en el proyecto.  Tamaño de cada equipo entre 5 y 9 personas (con técnicas específicas de planificación y coordinación cuando varios equipos trabajan en el mismo proyecto).  Equipo trabajando en un mismo espacio común para maximizar la comunicación.  Dedicación del equipo a tiempo completo.  Estabilidad de los miembros del equipo. A continuación se realiza un detalle más específico sobre los requisitos de Scrum: 1. Cultura de empresa La cultura de la empresa proveedora del proyecto debe estar alineada con la filosofía de una gestión ágil de proyectos como Scrum y debe fomentar:  El trabajo en equipo y la colaboración entre todas las personas implicadas en un proyecto.  Equipos autogestionados a los que se ha delegado la responsabilidad y autoridad para hacer su trabajo.  La creatividad del equipo.  La transparencia y la mejora continua, tanto del contexto de la organización y del proyecto y como de las herramientas del equipo. Scrum sistematiza la identificación de obstáculos que pueden impedir el correcto progreso del proyecto. Los problemas previamente existentes en la organización (procesos, personas, Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 76 | P á g i n a herramientas, etc.) y que atentan contra la productividad se harán más evidentes cuando se aplique Scrum y será necesario ir solucionándolos en cada iteración. 2. Compromiso del cliente Scrum exige del cliente una alta implicación y una dedicación regular:  El cliente tiene la responsabilidad de dirigir los resultados del producto o proyecto.  El cliente debe disponer de una visión de alto nivel del producto o proyecto y tener reflejadas sus expectativas en forma de lista de requisitos priorizada donde ha indicado el valor que le aportará cada uno. A partir de los costes de desarrollo que le proporcione el equipo, priorizará los requisitos en función del Retorno de la Inversión (ROI) más rápido.  El cliente re planifica el proyecto en cada iteración para maximizar este ROI de manera continua.  Al tratarse de un proyecto que va entregando resultados en iteraciones regulares, el cliente debe colaborar participando en el inicio de cada iteración (reunión de planificación) y en el fin de cada iteración (demostración), y debe estar disponible durante la ejecución de cada iteración para resolver dudas. 3. Compromiso de la Dirección La Dirección debe estar comprometida y apoyar el uso de la metodología:  Se harán muy evidentes los obstáculos ya existentes y por venir que impiden el correcto desarrollo de los proyectos (a nivel de expectativas del cliente, productividad, calidad, etc.), sean organizativos, técnicos, procesos, relaciones entre personas/departamentos, habilidades de los equipos y demás.  Será necesario tomar decisiones, realizar cambios organizativos, alinear a personas y proporcionar recursos para hacer la transición. Gestores y equipos deberán desaprender formas de trabajar y de relacionarse a las que estaban habituados y aprender nuevas dinámicas.  Un proyecto ya no consistirá en que cada Departamento/Área realice su parte del trabajo y se la pase al siguiente. Será necesario formar equipos autogestionados y multidisciplinares capaces de conseguir un objetivo por ellos mismos.  Habrá gestores que tendrán que cambiar sus roles para ser Facilitadores o Clientes, en una jerarquía de equipos organizada.  Se tendrá que gestionar aquellas conductas personales que no permiten que otras personas puedan aportar ideas sobre el qué y el cómo de un proyecto, que defienden a toda costa su parcela de responsabilidad, que les cuesta mucho cederla al equipo y dejar de controlarlo, que no son capaces de delegar tareas o de colaborar con otras personas en la resolución de problemas. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 79 | P á g i n a 10. Estabilidad del equipo El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo mínimo posible, para poder aprovechar el esfuerzo que les ha costado construir sus relaciones interpersonales, conectarse y establecer su organización del trabajo. El proceso de aplicación de Scrum En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de 2 a 4 semanas como máximo). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite. Figura Nº 14 – Proceso de Scrum. El proceso parte de la lista de objetivos/requisitos priorizada del producto (Product Backlog), que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversión mediante la replanificación de objetivos del producto, que realiza durante la iteración con vista a las siguientes iteraciones. _______________________ Figura Nº 14 Extraída de [14] Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 80 | P á g i n a Las actividades que se llevan a cabo en Scrum son las siguientes: 1. Planificación de la iteración (Sprint Planning) La planificación de las tareas a realizar en la iteración se divide en dos partes:  Primera parte de la reunión. Se realiza en un timebox promedio de 1 a 2 horas. o El cliente presenta al equipo la lista de requisitos priorizada (Product Backlog) del producto o proyecto, pone nombre a la meta de la iteración (de manera que ayude a tomar decisiones durante su ejecución) y propone los requisitos más prioritarios a desarrollar en ella. o El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade más condiciones de satisfacción y selecciona los objetivos/requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados si el cliente lo solicita.  Segunda parte de la reunión. Se realiza en un timebox promedio de 1 a 2 horas. El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado que ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien mejor conoce cómo realizarlo. o Define las tareas necesarias para poder completar cada objetivo/requisito, creando la lista de tareas de la iteración (Sprint Backlog). o Se realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea (Pocker Planning). o Cada miembro del equipo se autoasigna a las tareas que puede realizar. Beneficios  Productividad mediante comunicación y creación de sinergias. Todos los miembros del equipo tienen una misma visión del objetivo y se ha utilizado los conocimientos y las experiencias de todos para elaborar la mejor solución entregable en el mínimo tiempo y con el mínimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y dependencias entre tareas.  Potenciación del compromiso del equipo sobre el objetivo común de la iteración: o Es todo el equipo quien asume la responsabilidad de completar en la iteración los requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algún impedimento que bloquea el progreso de la iteración, especialmente si cuando se está llegando al final de la iteración es necesaria la participación de todos para poder completar los objetivos comprometidos. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 81 | P á g i n a o Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que se autoasignó) en los tiempos que proporcionó. Si existe falta de compromiso con respecto al resto de miembros del equipo se hará muy evidente en las reuniones diarias de sincronización del equipo (Daily meeting).  Una estimación conjunta es más fiable, dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de los integrantes del equipo. 2. Ejecución de la iteración (Sprint) En Scrum un proyecto se ejecuta en bloques temporales de tiempos cortos y fijos (iteraciones de 2 a 4 semanas). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea potencialmente entregable, de manera que cuando el cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el producto esté disponible para ser utilizado. Para ello, durante la iteración el equipo colabora estrechamente y se llevan a cabo las siguientes dinámicas:  Cada día el equipo realiza una reunión de sincronización (Daily meeting), donde cada miembro inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, comunica cuales son los impedimentos con que se encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).  El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se reduzca su productividad. También se encarga de eliminar los obstáculos que el equipo no puede resolver por sí mismo y protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad. Para poder completar el máximo de requisitos en la iteración, se debe minimizar el número de objetivos/requisitos en que el equipo trabaja simultáneamente, completando primero los que den más valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de tareas de la iteración, permite tener más capacidad de reacción frente a cambios o situaciones inesperadas. 3. Reunión diaria de sincronización del equipo (Daily meeting) El objetivo de esta reunión es facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros. Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este objetivo) para al finalizar la reunión poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso conjunto que el equipo adquirió para la iteración (en la reunión de planificación de la iteración). Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 84 | P á g i n a Los cambios en la lista de requisitos pueden ser debidos a:  Modificaciones que el cliente solicita tras la demostración que el equipo realiza al final de cada iteración sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o proyecto.  Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc).  Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto. Para realizar esta tarea, el cliente colabora con el equipo:  Para cada nuevo objetivo/requisito, conjuntamente se hace una identificación inicial de sus condiciones de satisfacción (que se detallarán en la reunión de planificación de la iteración).  El cliente obtiene del equipo la re estimación de costes de desarrollo para completar los objetivos/requisitos siguientes. El equipo ajusta el factor de complejidad, el coste para completar los requisitos y su velocidad de desarrollo en función de la experiencia adquirida hasta ese momento en el proyecto.  El cliente re prioriza la lista de objetivos/requisitos en función de estas nuevas estimaciones. Roles y responsabilidades de las personas involucradas en la metodología 1. Cliente (Product Owner) Las responsabilidades del Cliente son:  Ser el representante de todas las personas interesadas en los resultados del proyecto (internas o externas a la organización, promotores del proyecto y usuarios finales o consumidores finales del producto) y actuar como interlocutor único ante el equipo, con autoridad para tomar decisiones.  Definir los objetivos del producto o proyecto.  Dirigir los resultados del proyecto y maximizar su ROI.  Es el propietario de la planificación del proyecto. Crea y mantiene la lista priorizada con los requisitos necesarios para cubrir los objetivos del producto o proyecto, conoce el valor que aportará cada requisito y calcula el ROI a partir del coste de cada requisito que le proporciona el equipo.  Reparte los objetivos/requisitos en iteraciones y establece un calendario de entregas.  Antes de iniciar cada iteración re planifica el proyecto en función de los requisitos que aportan más valor en ese momento, de los requisitos completados en la iteración anterior y del contexto del proyecto en ese momento  Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos de cada iteración. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 85 | P á g i n a  Participar en la reunión de planificación de iteración, proponiendo los requisitos más prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se comprometer a hacer.  Estar disponible durante el curso de la iteración para responder a las preguntas o dudas que puedan surgir.  No cambiar los requisitos que se están desarrollando en una iteración, una vez ésta esta iniciada. 2. Facilitador (Scrum Master) Se encarga de liderar al equipo llevando a cabo las siguientes responsabilidades:  Controlar que todos los participantes del proyecto sigan los valores y principios ágiles, las reglas y proceso de Scrum y guiar la colaboración dentro del equipo y con el cliente de manera que las sinergias sean máximas.  Asegurar que exista una lista de requisitos priorizada y que esté preparada antes de la siguiente iteración.  Facilitar las reuniones de Scrum (planificación de la iteración, reuniones diarias de sincronización del equipo, demostración, retrospectiva), de manera que sean productivas y consigan sus objetivos.  Enseñar al equipo a auto gestionarse. No da respuestas, si no que guía al equipo con preguntas para que descubra por sí mismo una solución.  Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteración, proporcionar un resultado útil al cliente de la manera más efectiva y así poder finalizar el proyecto con éxito. Estos obstáculos se identifican de manera sistemática en las reuniones diarias de sincronización del equipo y en las reuniones de retrospectiva.  Proteger y aislar al equipo de interrupciones externas durante la ejecución de la iteración (introducción de nuevos requisitos, desvinculación no prevista de un miembro del equipo, etc.). De esta manera, el equipo puede mantener su productividad y el compromiso que adquirió sobre los requisitos que completaría en la iteración. 3. Equipo (Team) Es el grupo de personas que de manera conjunta desarrollan el producto del proyecto. Tienen un objetivo común y comparten la responsabilidad del trabajo que realizan. El tamaño del equipo está entre 5 y 9 personas. Por debajo de 5 personas cualquier imprevisto o interrupción sobre un miembro del equipo compromete seriamente el compromiso que han adquirido y, por tanto, el resultado que se va a entregar al cliente al finalizar la iteración. Por encima de 9 personas, la comunicación y colaboración entre todos los miembros se hace más difícil y se forman subgrupos. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 86 | P á g i n a Este equipo está constituido por los siguientes perfiles:  Desarrollador  Analista funcional  Analista Técnico  Tester  Arquitecto  Proyect Manager  Team Leader Es un equipo auto-organizado, que comparte información y cuyos miembros confían entre ellos. Realiza de manera conjunta las siguientes actividades:  Seleccionar los requisitos que se compromete a completar en una iteración, de forma que estén preparados para ser entregados al cliente.  Estimar la complejidad de cada requisito en la lista de requisitos priorizada del producto o proyecto.  En la reunión de planificación de la iteración decide cómo va a realizar su trabajo: o Seleccionar los requisitos que pueden completar en cada iteración, realizando al cliente las preguntas necesarias. o Identificar todas las tareas necesarias para completar cada requisito. o Estimar el esfuerzo necesario para realizar cada tarea. o Cada miembro del equipo se auto asigna a las tareas.  Durante la iteración, trabajar de manera conjunta para conseguir los objetivos de la iteración. Cada especialista lidera el trabajo en su área y el resto colaboran si es necesario para poder completar un requisito.  Al finalizar la iteración: o Demostrar al cliente los requisitos completados en cada iteración. o Hacer una retrospectiva la final de cada iteración para mejorar de forma continua su manera de trabajar. Herramientas que se utilizan en Scrum  Lista de objetivos / requisitos priorizada (Product Backlog) La lista de objetivos/requisitos priorizada representa la visión y expectativas del cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es el responsable de crear y gestionar la lista con la ayuda del Facilitador y del equipo, quien proporciona el coste estimado de completar cada requisito. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 89 | P á g i n a Propiedades de Crystal Clear: • Entrega frecuente: consiste en entregar software a los clientes con frecuencia, no solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal o mensual. • Comunicación osmótica: todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseñador senior y discutir respecto del tema que se trate. • Mejora reflexiva: tomarse un pequeño tiempo diariamente para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir.  Seguridad personal: hablar con los compañeros cuando algo molesta dentro del grupo.  Foco: saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo.  Fácil acceso a usuarios expertos: tener alguna comunicación con expertos desarrolladores. Roles: • Patrocinador: produce la Declaración de Misión con Prioridades de Compromiso (Tradeoff). Consigue los recursos y define la totalidad del proyecto. • Usuario Experto: junto con el Experto en Negocios produce la Lista de Actores­Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe familiarizarse con el uso del sistema, sugerir atajos de teclado, modos de operación, información a visualizar simultáneamente, navegación. • Diseñador Principal: produce la Descripción Arquitectónica. Se supone que debe ser al menos un profesional de Nivel 3. En Metodologías Ágiles se definen tres niveles de experiencia: o Nivel 1 es capaz de seguir los procedimientos. o Nivel 2 es capaz de apartarse de los procedimientos específicos y encontrar otros distintos. o Nivel 3 es capaz de manejar con fluidez, mezclar e inventar procedimientos. El Diseñador Principal tiene roles de coordinador, arquitecto, mentor y programador más experto. • Diseñador/Programador: produce, junto con el Diseñador Principal, los Borradores de Pantallas, el Modelo Común de Dominio, las Notas y Diagramas de Diseño, el Código Fuente, el Código de Migración, las Pruebas y el Sistema Empaquetado.  Experto en Negocios: junto con el Usuario Experto produce la Lista de Actores/Objetivos y el Archivo de Casos de Uso y Requerimientos. Debe conocer las reglas y políticas del negocio. • Coordinador: con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de Iteración y la Agenda de Visualización. • Verificador: produce el Reporte de errores. Puede ser un programador en tiempo parcial, o un equipo de varias personas. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 90 | P á g i n a • Escritor: produce el Manual de Usuario. El Equipo como Grupo es responsable de producir la Estructura y Convenciones del Equipo y los Resultados del Taller de Reflexión. La guía de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeños. Da flexibilidad y prioriza la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza en los miembros del equipo. Presta especial importancia a la ubicación física del grupo, donde la comunicación cumple el principal rol. La entrega frecuente de código confiable mantiene el foco y evita distracciones. 5.3.4. Kanban Esta metodología tiene como base de su origen la aplicación de los procesos de producción JIT (Just in Time) ideados por la empresa automotriz Toyota, en la cual utilizaban tarjetas visuales para identificar necesidades de material en la cadena de producción. Kanban se basa en la idea de que el trabajo en curso debería limitarse, y sólo deberíamos empezar con algo nuevo cuando un bloque de trabajo anterior haya sido entregado o ha pasado a otra función posterior de la cadena. La metodología Kanban utiliza un mecanismo de control visual para hacer seguimiento del trabajo conforme este viaja a través del flujo de valor. Normalmente, se emplea un panel o pizarra con notas adhesivas o un panel electrónico de tarjetas para gestionar el flujo de trabajo y las asignaciones. Las mejores prácticas apuntan al uso de ambos métodos. El Kanban (o tarjeta visual) implica que se genera una señal visual para indicar que hay nuevos bloques de trabajo que pueden ser comenzados porque el trabajo en curso actual no alcanza el máximo acordado. El aporte principal de Kanban a las metodologías agiles es que a través de la implementación de tarjetas visuales, proporciona transparencia al proceso, ya que su flujo de trabajo expone los cuellos de botella, colas, variabilidad y desperdicios a lo largo del tiempo y todas las cosas que impactan al rendimiento de la organización en términos de la cantidad de trabajo entregado y el ciclo de tiempo requerido para entregarlo. Proporciona a los miembros del equipo y a las partes interesadas visibilidad sobre los efectos de sus acciones o falta de acción. De esta forma, cambia el comportamiento y motiva a una mayor colaboración en el trabajo. La visibilidad de los cuellos de botella, desperdicios y variabilidades y su impacto también promueve la discusión sobre las posibles mejoras, y hace que los equipos comiencen rápidamente a implementar mejoras en su proceso. Como resultado, Kanban propicia la evolución incremental de los procesos existentes, una evolución que generalmente está alineada con los valores de las metodologías agiles. Kanban no genera una revolución radical de la forma en la que las personas trabajan, sino que sugiere un cambio gradual. Es un cambio que surge del entendimiento y del consenso de entre todos los participantes del proyecto. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 91 | P á g i n a Las principales ventajas de esta metodología es que es muy fácil de aplicar, actualizar y asumir por parte del equipo. Además, se destaca por utilizar una técnica de gestión de las tareas muy visual y práctica, lo que permite ver a simple vista el estado de los proyectos, así como también pautar el desarrollo del trabajo de manera efectiva. Principios del método Kanban  Calidad garantizada: todo lo que se hace debe salir bien en la primera instancia, no hay margen de error. Para lograr esto no se premia la rapidez, sino la calidad final de las tareas realizadas. Esto se basa en el hecho que muchas veces cuesta más arreglarlo después que hacerlo bien de entrada.  Reducción del desperdicio: se basa en hacer solamente lo justo y necesario, para garantizar que se haga bien. Esto supone la reducción de todo aquello que es superficial o secundario.  Mejora continua: Se acuerda perseguir el cambio incremental y evolutivo. No es simplemente un método de gestión, sino también un sistema de mejora en el desarrollo de proyectos, según los objetivos a alcanzar. El equipo debe estar de acuerdo que el cambio continuo, gradual y evolutivo es la manera de hacer mejoras en el sistema y debe apegarse a ello. Los cambios radicales pueden parecer más eficaces, pero tienen una mayor tasa de fracaso debido a la resistencia y el miedo en la organización.  Flexibilidad: es necesario poder priorizar aquellas tareas entrantes según las necesidades del momento y tener la capacidad de dar respuesta a estas tareas imprevistas. Aplicación del método Kanban La aplicación del método Kanban implica la generación de un tablero de tareas que permitirá mejorar el flujo de trabajo y alcanzar un ritmo sostenible. Para implantar esta metodología, deberemos tener claro los siguientes aspectos: 1. Definir el flujo de trabajo de los proyectos: para ello, simplemente deberemos crear nuestro propio tablero, que deberá ser visible y accesible por parte de todos los miembros del equipo. Cada una de las columnas corresponderá a un estado concreto del flujo de tareas, que nos servirá para saber en qué situación se encuentra cada proyecto. El tablero debe tener tantas columnas como estados por los que pasa una tarea, desde que se inicia hasta que finaliza. A diferencia de SCRUM, una de las peculiaridades del tablero es que este es continuo. Esto significa que no se compone de tarjetas que se van desplazando hasta que la actividad queda realizada por completo. En este caso, a medida que se avanza, las nuevas tareas (mejoras, incidencias o nuevas funcionalidades) se acumulan en la sección inicial, de manera que en las reuniones periódicas con el cliente se priorizan y se colocan dentro de la sección que se estima oportuna. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 94 | P á g i n a Es un valor a tener en cuenta, que la resolución de cuellos de botella, la mayoría de las veces, motiva la colaboración del equipo entre los diferentes procesos. Pues mientras existen procesos colapsados, existen a la vez, procesos libres para aceptar nuevos ítems. El cuello de botella ha generado un estancamiento, y los procesos libres, pueden ayudar a destrabar a los procesos colapsados. 3. Optimizar el flujo de trabajo El objetivo es generar una producción estable, continua y previsible. Midiendo el tiempo que el ciclo completo de ejecución del proyecto demanda (por ejemplo, cantidad de días desde el inicio del análisis hasta el fin de la implementación), se obtiene el CycleTime. Al dividir, el CycleTime por el WIP (trabajo en curso), se obtiene el rendimiento de trabajo, denominado Throughput, es decir, la cantidad de ítems que un equipo puede terminar en un determinado período de tiempo. Con estos valores, la optimización del flujo de trabajo consistirá en la búsqueda de:  Minimizar el CycleTime  Maximizar el Throughput  Lograr una variabilidad mínima entre CycleTime y Throughput Dicho todo esto, se puede decidir que implementando Kanban se consigue aumentar la eficiencia en los procesos, evitar retrasos y no desaprovechar recursos, reducción de tiempos muertos en y entre procesos, mejor mantenimiento, información más rápida y precisa, minimización de entregas con errores y evitar sobrecarga de trabajo. 5.3.5. FEATURE DRIVEN DEVELOPMENT (FDD) La metodología ágil FDD, con sus siglas en inglés Feature Driven Development, fue impulsada por Jeff de Luca y Meter Coad en los años 80. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. Dicho enfoque no hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y construcción. Sin embargo, fue diseñado para trabajar con otras actividades de desarrollo de software y no requiere la utilización de ningún modelo de proceso específico. Hace énfasis en aspectos de calidad durante todo el proceso e incluye un monitoreo permanente del avance del proyecto. Al contrario de otras metodologías, FDD promete ser conveniente para el desarrollo de sistemas críticos y está orientada a equipos de trabajo más grandes, con más personas que aquellos a los que normalmente se aplican otras metodologías como Scrum. Define claramente entregas tangibles y formas de evaluación del progreso del proyecto. No hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y construcción. FDD se basa en un ciclo muy corto de iteración, nunca superior a dos semanas, y en el que el análisis y los desarrollos están orientados a cumplir una lista de Features que tiene que tener el software a desarrollar. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 95 | P á g i n a Un Feature debe cumplir las siguientes características:  Debe ser simple y poco costosa de desarrollar, de entre uno y diez días.  Debe aportar valor al cliente y ser relevante para su negocio.  Debe poderse expresar en términos de acción, resultado y objeto. La metodología sigue cinco fases iterativas: 1. Desarrollo/Modificación de un Modelo Global 2. Creación/Modificación de la lista de Features 3. Planificación 4. Diseño 5. Implementación Ventajas  El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones innecesariamente generales y complejas que en realidad no son un requisito del cliente.  Cada componente del producto final ha sido probado y satisface los requerimientos.  Rápida respuesta a cambios de requisitos a lo largo del desarrollo.  Entrega continua y en plazos cortos de software funcional.  Trabajo conjunto entre el cliente y el equipo de desarrollo.  Minimiza los costos frente a cambios.  Importancia de la simplicidad, al eliminar el trabajo innecesario.  Atención continua a la excelencia técnica y al buen diseño.  Mejora continua de los procesos y el equipo de desarrollo.  Evita malentendidos de requerimientos entre el cliente y el equipo. Desventajas  Falta de documentación del diseño. El código no puede tomarse como una documentación. En sistemas de tamaño grande se necesita leer los cientos o miles de páginas del listado de código fuente.  Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades.  Fuerte dependencia de las personas. Como se evita en lo posible la documentación y los diseños convencionales, los proyectos ágiles dependen críticamente de las personas.  Falta de reusabilidad. La falta de documentación hacen difícil que pueda reutilizarse el código ágil. Metodologías de Desarrollo de Software Tesis Final – Cátedra: Seminario de Sistemas Carrera: Licenciatura en Sistemas y Computación ______________________________________________________________________ 96 | P á g i n a 5.3.6. ADAPTIVE SOFTWARE DEVELOPMENT (ASD) Esta metodología parte de la idea de que las necesidades del cliente son siempre cambiantes durante el desarrollo del proyecto y posteriormente a su entrega. Esta técnica fue desarrollada por Jim Highsmith y Sam Bayer a comienzos de los 90. La novedad de esta metodología es que en realidad no es una metodología de desarrollo de software, sino un método/técnica, a través del cual inculcar una cultura adaptativa a la empresa para adaptarse al cambio y no luchar contra él. En ella no hay un ciclo de vida estático (planear-diseñar-construir), si no que ofrece un ciclo de vida iterativo, donde cada ciclo puede ser modificado al tiempo que otro es ejecutado (especular colaborar-aprender). Los objetivos de esta metodología son: 1) Concienciar a la organización de que debe esperar cambio e incertidumbre y no orden y estabilidad. 2) Desarrollar procesos iterativos de gestión del cambio. 3) Facilitar la colaboración y la interacción de las personas a nivel interpersonal, cultural y estructural. 4) Marcar una estrategia de desarrollo rápido de aplicaciones pero con rigor y disciplina. Sus principales características son: 1) Iterativo. 2) Orientado a los componentes software más que a las tareas. 3) Tolerante a los cambios. 4) Guiado por los riesgos. 5) La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. El ciclo utilizado por ASD es conocido como: especular-colaborar-aprender, el cual está dedicado a un constante aprendizaje y colaboración entre desarrollador y cliente. Ciclo de vida ASD Especulación 1) Inicio, para determinar la misión del proyecto. 2) Fijación del marco temporal del proyecto. 3) Determinación de número de iteraciones y la duración de cada una. 4) Definición de objetivo de cada iteración. 5) Asignación de funcionalidad de cada iteración.