Metodologías Agiles en el Desarrollo de Software El proceso de desarrollo se enfatiza en el control de procesos mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Metodologías tradicionales → Restricciones de tiempo y flexibilidad Metodologías agiles → Orientada a proyectos pequeños Manifestó Ágil Documento que resume la filosofía ágil, se valora en: 1) Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas: Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades. 2) Desarrollar software que funciona más que conseguir una buena documentación: Los documentos deben ser cortos y centrarse en lo fundamental. 3) La colaboración con el cliente más que la negociación de un contrato: interacción constante entre el cliente y el equipo de desarrollo. 4) Responder a los cambios más que seguir estrictamente un plan: La habilidad de responder a los cambios, la planificación no debe ser estricta sino flexible y abierta. Los valores anteriores inspiran doce principios: 1) La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software 2) Dar la bienvenida a los cambios para que el cliente tenga una ventaja competitiva, entregar frecuentemente software 3) La gente y desarrolladores deben trabajar juntos a lo largo del proyecto 4) Construir el proyecto en torno a individuos motivados. 5) El software que funciona es la medida principal de progreso, Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. 6) La atención continua a la calidad técnica y al buen diseño mejora la agilidad 7) La simplicidad es esencial. 8) Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. Diferencias entre Metodologías Agiles y Tradicionales Metodologías Agiles Basadas en heurísticas provenientes de prácticas de producción de código Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo) Proceso menos controlado, con pocos principios No existe contrato tradicional o al menos es bastante flexible El cliente es parte del equipo de desarrollo Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio Pocos artefactos Pocos roles Menos énfasis en la arquitectura del software Metodologías Tradicionales Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Cierta resistencia a los cambios Impuestas externamente Proceso mucho más controlado, con numerosas políticas/normas Existe un contrato prefijado El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos grandes y posiblemente distribuidos Más artefactos Más roles La arquitectura del software es esencial y se expresa mediante modelos Programación Extrema (Extreme Programming, XP) Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo preocupándose por el aprendizaje de los desarrolladores y propiciando un buen clima de trabajo. Se basa en: a) Realimentación continua entre el cliente y el equipo de desarrollo b) Simplicidad en las soluciones implementadas c) Enfrentar los cambios Adecuada para: Proyectos con requisitos imprecisos y muy cambiantes y donde existe un alto riesgo técnico, startups o empresas que están en proceso de consodilacion Características esenciales de XP: a) Historias de Usuario: Técnica utilizada para especificar los requisitos del software, se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. Las historias de usuario son descompuestas en tareas de programación (task card) y asignadas a los programadores para ser implementadas durante una iteración. b) Roles XP: 1) Programador: escribe las pruebas unitarias y produce el código 2) Cliente: Escribe las historias de usuario y las pruebas funcionales para validar su implementación 3) Encargado de pruebas (Tester): Ayuda al cliente a escribir las pruebas funcionales 4) Encargado de seguimiento (Tracker): Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones 5) Entrenador (Coach): Es responsable del proceso global. Debe proveer guías al equipo 6) Consultor: Es un miembro externo del equipo con un conocimiento específico 7) Gestor (Big boss): Es el vínculo entre clientes y programadores c) Proceso XP: Ciclo de desarrollo consiste en: 1) El cliente define el valor de negocio a implementar. 2) El programador estima el esfuerzo necesario para su implementación. 3) El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4) El programador construye ese valor de negocio. 5) Vuelve al paso 1. El ciclo de vida ideal de XP consiste en seis fases: 1.- Exploración 2.-Planificación de la Entrega (Release) 3.- Iteraciones 4.-Producción 5.-Mantenimiento 6.-Muerte del Proyecto d) Practicas XP: la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollo de software 1) El juego de la planificación: comunicación frecuente el cliente y los programadores y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración. 2) Entregas pequeñas: Producir rápidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. 3) Metáfora: El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe cómo debería funcionar el sistema 4) Diseño Simple: diseñar la solución más simple que pueda funcionar y ser implementada 5) Pruebas: producción de código está dirigida por las pruebas unitarias 6) Refactorización: actividad constante de reestructuración del código con el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible 7) Programación en parejas: trabajo en parejas de programadores → ventajas implícitas (menor tasa de errores, mejor diseño, mayor satisfacción de los programadores, 8) Propiedad colectiva del código: Cualquier programador puede cambiar cualquier parte del código en cualquier momento. 9) Integración continua: Cada pieza de código es integrada en el sistema una vez que esté lista 10) 40 horas por semana: trabaja r un máximo de 40 horas por semana. 11) Cliente in-situ: La comunicación de los programadores es a través del código es indispensable que sigan ciertos estándares de programación para mantener el código legible. SCRUM Define un marco para la gestión de proyectos, los pilares de la metodología SCRUM son: 1) Transparencia: Todos los implicados tienen conocimiento de que ocurre en el proyecto y como ocurre, entendimiento del proyecto y una visión global 2) Inspeccion: Inspecciona el rpogreso para detectar posibles problemas para saber que el proyecto fluye y el equipo trabaja de forma organizada 3) Adaptación: Cuando hay algo que cambiar el equipo se ajusta para conseguir el objetivo del sprint. Iteraciones, denominadas sprints, con una duración de 30 días, cada sprint es un incremento ejecutable que se muestra al cliente. Roles: 1) Product Owner: Comunicación constante con el cliente, maximiza el valor de trabajo del equipo de desarrollo 2) Scrum Master: Responsable de que las técnicas Scrum sean aplicadas y eliminar impedimentos que tenga el equipo de desarrollo 3) Equipo de desarrollo: Encargados del desarrollo del sistema, realizan tareas priorizadas por el Product Owner Se basa en: a) La flexibilidad en la adopción de cambios y nuevos requisitos durante un proyecto complejo b) La colaboración e interacción con el cliente c) Desarrollo iterativo como forma de asegurar buenos resultados Adecuada para: Proyectos con un rápido cambio de requisitos, proyectos que exigen una flexibilidad y una rapidez esencial a la hora de ejecutar los resultados. Características: a) reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración Crystal Methodologies Conjunto de metodologías para el desarrollo de software, centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Se basa en: 1) Se centra en las personas del equipo 2) Son menos extremas 3) Cuenta con criticidad de vida Adecuada para: Tipologías de proyectos y empresas grandes Características: a) El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. b) Equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas c) Tener políticas de trabajo en equipo definidas, las políticas dependerán del tamaño del equipo y se clasificarán por colores → Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros) Dynamic Systems Development Method (DSDM) Define el marco para desarrollar un proceso de producción de software. Se basa en: 1) 2) 3) 4) 5) 6) 7) 8) Centra en la necesidad comercial Entrega a tiempo Colaborar Nunca comprometer calidad Construir incrementalmente Desarrollar iterativamente Comunicación continua y clara Demostrar control Adecuada para: Proyectos dentro del presupuesto con escalabilidad y para cualquier sector comercial Características: a) proceso iterativo e incremental b) equipo de desarrollo y el usuario trabajan juntos. c) Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Adaptive Software Development (ASD) Ciclo de vida: 1) Especulación: Inicia el proyecto y se planifican las características 2) Colaboración: Desarrollan las características 3) Aprendizaje: Se revisa la calidad y se entrega al cliente Se basa en: 1) Funcionamiento cíclico 2) En cada iteración se producirán cambios y errores Adecuada para: Que el cliente este pidiendo adecuaciones continuamente, el ciclo de vida de esta metodología es dirigible y fácil de implementar Características: a) b) c) d) e) Iterativo Orientado a los componentes de software más que a las tareas Tolerante a los cambios Guiado por riesgos La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo Feature – Driven Dvelopment (FDD) Se basa en: 1) Proceso iterativo, con iteraciones cortas 2) Con estas iteraciones producir software funcional donde el cliente y la empresa pueda ver y monitorear 3) Entregas tangibles Adecuada para: Proyectos y equipos grandes en cuestión de tamaño y duración, FDD puede ser más escalable que XP Características: a) Define un proceso iterativo que consta de 5 pasos b) Iteraciones cortas (hasta 2 semanas) c) Se centra en las fases de diseño e implementación del sistema Lean Development (LD) Los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Se basa en: 1) 2) 3) 4) 5) 6) Visión global e integrada del proyecto Aprendizaje continuo Iteraciones cortas Pruebas continuas Retroalimentación de los usuarios Capacitar al equipo Adecuada para: Características: a) Mecanismo para implementar cambios Kanban Es una metodología que se apoya de un sistema visual para gestionar una tarea o un trabajo a medida en que se avanza en un proceso Se basa en: 1) 2) 3) 4) 5) Mejorar el flujo Reducir el tiempo Mejora los tiempos de entrega Aumentar el valor para el cliente Prevención para posibles fallas y retrasos Adecuada para: Sistemas de producción y muchos procesos Características a) Identificar posibles cuellos de botella y solucionarlos para que el trabajo pueda fluir óptimamente Pasos: 1) Visualizar el flujo de trabajo: Tablero con 3 columnas cada columna contiene tarjetas y cada tarjeta equivale a una tarea. Las columnas se dividen en: por hacer, en proceso y Listo 2) Limitar los trabajos en proceso (WIP): Son las tareas en que un equipo trabaja y limita la capacidad de flujo de trabajo 3) Administrar y mejorar el flujo de trabajo: Es mover las tareas de columna, las que están por hacer a la columna de proceso y después a la columna de listo, se debe tener en cuenta el límite de entrega de los trabajos las fases etc. 4) Hacer explicitas las reglas de proceso: Definir y visualizar las reglas de como se hace un trabajo para que los participantes puedan describir como se hace el trabajo del sistema 5) Implementar bucles de retroalimentación: Retroalimentación para entregar un proyecto de calidad en el menor tiempo posible DIFERENCIAS ENTRE METODOLGOIAS AGILES XP Divide el proyecto en fases y en cada una realiza un ciclo completo de análisis, diseño, desarrollo y pruebas SCRUM Divide el proyecto en bloques (sprints), que se planifica y revisan continuamente. KANBAN Utiliza técnicas visuales, permitiendo saber en que punto se encuentra cada tarea de forma rápida y sencilla LEAN Proceso metodológico dirigido por modelos para el desarrollo ágil de sistemas de información web Arquitectura dirigida por modelos 1) MDA: Es un marco de trabajo para el desarrollo de software que define una arquitectura orientada a modelos, estos proveen herramientas y mecanismo que asisten al desarrollador para los procesos de concepción, desarrollo, implementación y mantenimiento del software. Propone la realización de: a) CIM (Computer Independent Model): Es un modelo de alto nivel de abstracción que identifican el contexto del sistema, representa los modelos independientes de la computación, este tipo de modelo se conciben antes del levantamiento de requisitos para una aplicación particular. b) PIM (Platform Independent Models): Representa modelos que describen una solución de software que no contiene detalles de la plataforma concreta en que la solución va a ser implementada, este modelo surge como resultado de análisis y diseño c) PSM (Platform Specific Models): Modelos derivados de PIM, contiene los detalles de la plataforma o tecnología con que se implementara la solución Proceso metodológico MIDAS MIDAS se combina con la arquitectura MDA con una arquitectura de capas donde cada capa representa una vista del sistema En el eje X: Representa las diferentes vistas el SIW → Hipertexto, vista del contenido y la vista de la funcionalidad En el eje Y: Representa la parte independiente de computación → CIM, la parte independiente PIM, la parte dependiente PSM El proceso de MIDAS comienza siempre en la definición de los CIM y evolucionara a los PIM y hasta los PSM. Mutación de casos de prueba Junit Que son las pruebas de mutación: Dado un programa P que se va a probar, se genera un conjunto de copias de P, pero introduciendo en cada copia una pequeña alteración, normalmente sintáctica, mediante la aplicación de un “operador de mutación”. A estas copias levemente alteradas se las llama “mutantes” de P. Comienzan generando un conjunto de casos de prueba que son pasados al programa original, si la salida es incorrecta en algún caso de prueba se revisa el programa original hasta que las salidas sean correctas, si el programa original responde correctamente se ejecuta el conjunto de mutantes con todos los casos de prueba. Un mutante m se dice que “vive” cuando es igual que P para todos los casoa de prueba, si la salida es distinta es un mutante “muerto” Objetivos de la mutación: 1) Proporciona un criterio de adecuación de las pruebas (calidad) 2) Detecta fallos en el programa que se esté probando Para hacer un caso de prueba se hace un objeto de la Clase y se manda a llamar todos sus métodos con datos aleatorios. testOO Herramienta que genera una clase que contiene la lista de métodos y genera una secuencia de llamadas a los métodos, un conjunto mutante para cada método de prueba Estas técnicas y herramientas ayudan a generar de manera automática casos de prueba adecuados para probar programas JAVA. eXPERT Es un método aplicable a equipos pequeños de desarrolladores, este método es llamado EXPERT porque se construye principalmente de extreme programming(XP) y PSP(personal Software Process). Consiste en los siguientes procesos: 1) 2) 3) 4) Customer Requirements Management (CRM) Project Management (PM) Design (DS) Test (TS) Se basa en: 1) Practicas XP y PSP 2) Proporcionar a los desarrolladores un medio para medir su eficacia, utilizado para planificar y gestionar mejor los proyectos Adecuada para: Proyectos con un cambio seguido de requerimientos, con poco tiempo y una alta calidad de demanda. Características esenciales: 1) Mantener un enfoque compresivo 2) Mantener un enfoque fácil de aplicar 3) Promover los datos necesarios para realizar buenas estimaciones, planificación de proyectos 4) Mantener a la gente motivada para utilizar el enfoque La estructura de los roles de eXPERT son: 1) Customer: Escoge que se va a desarrollar que requerimiento se van a hacer primero 2) Project Leader: Supervisa y guía la aplicación del enfoque eXpert, lidera el equipo, asegura que el equipo entero realiza las iteraciones de acuerdo a lo planeado, mantiene actualizados a los stakeholders que no están directamente en el proyecto. 3) Developer: Analizar, diseñar, probar, codificar e integrar el sistema, estiman la dificultad de los requerimientos y el tiempo que se necesita para desarrollarlo. Proceso eXpert: 1) Administrar requerimientos del cliente: incluye todas las actividades relacionadas con la obtención, análisis y controlar los requisitos del cliente para un producto de software. Se basa en XP, prácticas relacionadas con el manejo de historias de usuarios 2) Administrar proyectos: abarca actividades relacionadas con planificación, seguimiento y control del desarrollo de software, se asegura de entregar un sistema de calidad, en tiempo y con el presupuesto correspondiente. 3) Diseño: Esta relacionado con el Código y el proceso de testeo. 4) Código: Producir el código para satisfacer los requerimientos del cliente, es permanentemente mantenido en buenas condiciones 5) Test: Validar que el producto de software producido cumple los requisitos y satisface los criterios de aceptación definidos por el cliente
