Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software. Sandra Dinora Orantes Jiménez

Transcripción

1 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software Sandra Dinora Orantes Jiménez Centro de Investigación en Computación, Instituto Politécnico Nacional, Av. Juan de Dios Bátiz s/n esquina Miguel Othón de Mendizábal, Col. Nueva Industrial Vallejo, México, D.F. C.P Resumen. El desarrollo de software no es tarea fácil y por ello, existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo; así, por un lado se encuentran propuestas tradicionales que se centran en el control del proceso, estableciendo de forma rigurosa actividades involucradas, artefactos que deben producir y herramientas y notaciones que se emplearán. Todas las propuestas han demostrado ser efectivas y necesarias en varios proyectos, pero también han presentado problemas en otros tantos. Se sugieren mejoras, como admitir en los procesos de desarrollo más actividades, artefactos y restricciones, en base a los puntos débiles detectados, como consecuencia se tendría un proceso de desarrollo complejo, que es posible que limite la propia habilidad del equipo para llevar a cabo el proyecto. Es así que, en el proceso de buscar soluciones, hoy en día se encuentran metodologías que se centran en otros aspectos, como por ejemplo el factor humano o el producto de software, siendo esta la filosofía de las Metodologías Ágiles, donde se da mayor importancia a la colaboración con el cliente y al desarrollo incremental del software con iteraciones cortas, mostrando su efectividad en proyectos con requisitos cambiantes y donde se exige reducir drásticamente los tiempos de desarrollo, pero manteniendo una alta calidad. Por consiguiente, esta investigación se centra, en lograr mantener la Calidad de Software en ciclos de desarrollo cortos como los que plantean las Metodologías Ágiles.

2 2 Sandra Dinora Orantes Jiménez Palabras Clave: Metodologías Ágiles, Calidad de Software, Individuos e Interacciones, Software Funcional, Colaboración con Clientes, Respuesta al Cambio. 1 Introducción Existen muchas metodologías para el desarrollo de software y varias de ellas se acoplan bajo el guión de ágiles; todas las metodologías existentes comparten características y algunas diferencias significativas, aunque la presente investigación no se enfoca en resaltar estos puntos, al enfocarse en las Metodologías Ágiles pueden señalarse algunos lugares donde se ven claras semejanzas y diferencias, pese a no tener experiencia significativa sobre muchas de ellas. El desarrollo de software ágil es un marco de trabajo conceptual para emprender proyectos de Ingeniería de software y así, existe un número de métodos de desarrollo de software ágiles, que son apoyados por la llamada Alianza Ágil (The Agile Alliance). Los llamados Métodos Ágiles, intentan minimizar riesgos en tiempos de desarrollo de software cortos, a través de iteraciones que duran de una a cuatro semanas y donde cada iteración, es como un proyecto de software en miniatura que incluye las tareas necesarias para liberar en cada mini-incremento, una nueva funcionalidad que pasó por todas las etapas: planeación, análisis de requerimientos, diseño, codificación, pruebas y documentación. En las metodologías normales basadas en incrementos, no se adiciona suficiente funcionalidad que garantice la liberación de un producto, en tanto, los proyectos de software ágil intentan ser capaces de que un nuevo software se termine al final de cada iteración y que incluso el equipo de desarrollo, reevalue las prioridades del proyecto esperando por supuesto, que cada producto sea de calidad. Los Métodos Ágiles enfatizan una comunicación en tiempo real, preferentemente cara a cara sobre documentos escritos; los equipos ágiles deben involucrar todas las personas necesarias para garantizar la finalización del software, como mínimo se involucran programadores y los clientes (que son finalmente los que definen el producto, quien lo manejará, análisis de negocios o consumidores actuales), el grupo también puede incluir a probadores, diseñadores de interacción, escritores técnicos y gerentes.

3 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 3 Las Metodologías Ágiles también acentúan en que el software trabajando es la primera medida del progreso, combinado con la comunicación cara a cara en todo momento, se produce poca documentación en relación con otros métodos, dando como resultado que se crítique a los Métodos Ágiles considerándoseles indiciplinados y poniendo a veces en riesgo la Calidad del producto resultante y que es donde se centra la presente investigación, tratar de lograr Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software. El artículo está organizado de la siguiente manera: en la sección 2 se introducen las las Metodologías Ágiles y un poco de la historia de cómo surgieron, se habla del Manifiesto y se comparan con metodologías no ágiles. La sección 3 habla de la conveniencia del empleo de Metodologías Ágiles. En la sección 4 se habla brevemente de la Evaluación de la Calidad de Software. En la sección 5 se habla de cómo adaptar los Métodos Ágiles, tomando en cuenta la Calidad de Software. En la sección 6 se dice como manejar un proyecto empleando Metodologías Ágiles asegurando la Calidad de Software. Finalmente, aparecen las conclusiones, que incluyen algunas críticas y las referencias bibliográficas. 2 Metodologías Ágiles, un poco de historia La definición moderna de Desarrollo de Software Ágil surge a mediados de los años 90 como parte de una reacción en contra de los llamados métodos de peso pesado (heavyweight), tipificados, regulados, reglamentados, micromanejados del modelo de desarrollo de Cascada, ya que los procesos que provienen del uso del modelo de cascada fueron vistos como burocráticos, lentos y que contradecían los caminos para que los ingenieros de software realizaran un trabajo eficaz. El hecho es que los métodos de desarrollo ágiles e iterativos son como regresar a las primeras prácticas de desarrollos de software [1]. Al principio las Métodos Ágiles fueron llamados Métodos de peso ligero (lightweight methods) y en el 2001, los miembros prominentes de la comunidad, que incluían 17 expertos de la industria del software, tomando en cuenta a algunos de los creadores o impulsores de metodologías de software, se encontraron en Snowbird, Utah, USA y adoptaron el nombre "Métodos Ágiles" y posteriormente, algunos de los miembros de esta comunidad formaron la llamada Alianza Ágil (The Agile Alliance) [2], que es una organización no lucrativa que promueve el desarrollo ágil.

4 4 Sandra Dinora Orantes Jiménez El punto de partida fue el Manifiesto Ágil (Agile Manifesto) [3], un documento que resume la filosofía ágil. Entre los primeros métodos ágiles que surgieron antes de 2000 se incluyen Scrum (en cuanto a dirección) (1986), Crystal Clear (software development), XP (extreme Programming, Programación Extrema) (1996), el Desarrollo de Software Adaptable (Adaptive Software Development), Desarrollo Conducido (Feature Driven Development) y DSDM (Dynamic Systems Development Method, Métodos de Desarrollo Dinámico de Sistemas) (1995). Aunque definitivamente XP no fue el primer método ágil, estableció la popularidad de los métodos ágiles y fue creado por Kent Beck en 1996 como un modo de rescatar el proyecto C3 (Chrysler Comprehensive Compensation, Chrysler Compensación Comprensiva), no obstante, aquel proyecto fue cancelado en su momento y la metodología XP fue refinada por Ron Jeffries, realizándose una discusión pública en Ward Cunningham's Portland Pattern Repository (Repositorio de Patrones en Portland de Cunningham) y posteriormente, en un trabajo publicado por Beck en 1999, que incluyo un libro [4]. Los elementos de Programación Extrema están basados en Scrum y Episodios del Lenguaje de Patrones de Cunningham (Ward Cunningham's Episodes pattern language). 2.1 Manifiesto Ágil Principios detrás de los Métodos Ágiles Los Métodos Ágiles no son una familia de procesos de desarrollo, ni un acercamiento al desarrollo de software; en 2001, 17 figuras prominentes [5] en el campo del desarrollo ágil (entonces llamados Métodos de peso ligero ) se reunieron en Utah para discutir la manera de crear software rápidamente y la forma de centrar a las personas en ello y finalmente, ellos elaboraron el Manifiesto Ágil (Agile Manifesto), extensamente considerado como la definición canónica de desarrollo ágil y acompañándolo de principios ágiles. Algunos de los principios detrás del Manifiesto Ágil [6] son: Satisfacción del cliente debido a la entrega rápida y continua de software útil. El software trabajando es entregado con frecuencia (en semanas en lugar de meses). El software trabajando es la medida principal de progreso. Incluso las exigencias de cambios tardíos son bienvenidos. Una cercana y diaria cooperación entre la gente del negocio (clientes) y los desarrolladores. La conversación frente a frente es la mejor forma de comunicación.

5 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 5 Los proyectos son construidos alrededor de individuos motivados, que se sienten confiados en su trabajo. La atención continua en la excelencia técnica y un buen diseño. Simplicidad. Equipos con Organización Propia. Adaptación regular a circunstancias cambiantes. La publicación del manifiesto engendró un movimiento en la industria de software conocida como el desarrollo de software ágil y en 2005, Alistair Cockburn y Jim Highsmith juntaron a otro grupo de personas - expertos de dirección, esta vez - y escribieron un apéndice, llamado la PM Declaración de Interdependencia. 2.2 Comparación con otras Metodologías Las Metodologías Ágiles a veces se caracterizan por ser lo opuesto de las llamadas Metodologías conducidas por plan o disciplinadas y esto implica, que los métodos ágiles son imprevistos o indisciplinados y que además, tienden a ser adaptables y predictivos [7]. Los Métodos Adaptativos enfocan rápidamente la adaptación a una realidad cambiante y si las necesidades del proyecto cambian, el equipo de trabajo es adaptable y se cambia también, tomando en cuenta la dificultad, que el equipo siempre tendrá que poder describir exactamente lo que pasará en el futuro y entre más lejana sea una fecha, más vago será lo que un método adaptable permitirá predecir para aquella fecha. Un equipo adaptable debe poder relatar exactamente que tareas tendrán que realizarse la próxima semana, aunque sólo podrá decir cuales rasgos serán planeados durante el próximo mes y si se trata de una liberación para dentro de seis meses, sólo pueden ser capaces de reportar el estado del producto para su liberación o una declaración de valor esperado contra el coste. Los Métodos Predictivos, enfocan la planificación del futuro detalladamente y los equipos predictivos pueden reportar exactamente que características y tareas están planeadas para todo el proceso de desarrollo. Sin embargo, a los equipos predictivos se les dificulta cambiar de dirección, ya que el plan es optimizado típicamente para un destino prefijado y si hay cambios, tendría que modificarse también la planificación, con el riesgo que el trabajo completo sea desechado y tengan que hacer todo nuevamente de manera diferente. Los equipos predictivos a menudo elaboran una tabla de control de cambios o riesgos, para asegurar que sólo los cambios valiosos sean considerados. Entre los Métodos Predictivos, el

6 6 Sandra Dinora Orantes Jiménez Modelo en Cascada es realmente con el que menos tienen en común las Metodologías Ágiles y aunque para algunos este modelo no es para nada adecuado, desde el 2004, se ha comprobado que todavía se emplea comúnmente [8]. Las Metodologías Ágiles tienen mucho en común con las técnicas de las Metodologías RAD (Rapid Application Development, Desarrollo Rápido de Aplicaciones) proporcionadas y expuestas en 1980 por James Martin y otros autores [9]. Algunos Equipos Ágiles, utilizan el modelo en cascada en una pequeña escala, repitiendo el modelo completo en cada iteración; otros equipos, son notablemente Equipos XP, trabajando en varias actividades simultáneamente. La Tabla 1 recoge un comparativo, marcando las principales diferencias de las metodologías ágiles con respecto a las Tradicionales no ágiles que se consideran son las que han servido de base para otras metodologías, las diferencias afectan no sólo al proceso, sino también al contexto del equipo así como a su organización. 3 Conveniencia del Uso de Métodos Ágiles Aunque los Métodos Ágiles se diferencian en sus prácticas, ellos comparten un número de características comunes, incluyendo el desarrollo iterativo y un enfoque sobre interacción, comunicación y reducción de artefactos intermedios intensivos en recursos. [10] La conveniencia de las Metodologías Ágiles en general, puede ser examinada desde múltiples perspectivas; desde el punto de vista del producto, los Métodos Ágiles son más convenientes cuando los requerimientos son cambiantes y requieren una rápida modificación y son menos convenientes, para los sistemas que son altamente riesgosos, fiables y con muchos requerimientos de seguridad, aunque no hay ningún consenso sobre este punto. [10] Desde una perspectiva organizacional, la conveniencia puede ser evaluada examinando tres dimensiones claves de una organización: cultura, personal y comunicación. En relación con estas áreas un número de factores claves han sido identificados para lograr el éxito de los proyectos [10]: 1. La cultura de la organización debe dar soporte a la negociación 2. Las personas involucradas en el desarrollo deben ser confiables

7 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 7 3. Las personas responsables del desarrollo deben ser pocas pero muy competentes 4. Las Organizaciones deben vivir con las decisiones de los desarrolladores 5. Las Organizaciones deben de tener un ambiente que facilite la comunicación rápida entre miembros del equipo de trabajo El factor más importante a tomar en cuenta, es probablemente, el tamaño del proyecto. [10] Cuando el tamaño crece, la comunicación cara a cara se hace más difícil. Por lo tanto, los Métodos Ágiles son convenientes para proyectos con equipos pequeños, es decir, que involucren menos de 20 personas. Para determinar la conveniencia individual del empleo de Métodos Ágiles, se requiere de un análisis sofisticado; los Métodos DSDM, por ejemplo, proporcionan para este propósito un filtro de conveniencia (suitability-filter); la familia de Métodos Crystal proporcionan criterios que ayuden a seleccionar el método adecuado para un proyecto y la elección está basada, en el tamaño del proyecto, riesgos y prioridades. Sin embargo, otros Métodos Ágiles no proporcinan ningún instrumento explícito para evaluar su conveniencia para un proyecto. Algunos Métodos Ágiles, como DSDM y FDD (Feature Driven Development, Desarrollo Conducido por Rasgos), son considerados convenientes para cualquier proyecto de desarrollo de software ágil, independientemente de características circunstanciales. [11] Una comparación de Métodos Ágiles revela que ellos soportan diferentes fases de un ciclo de vida de desarrollo de software en varios grados y esta característica individual puede ser empleada como criterio de selección para elegir al Método Ágil adecuado. El desarrollo ágil ha sido documentado extensamente [7] y se conoce que trabaja bien para equipos pequeños (menos de 10 desarrolladores) que son capaces de afrontar requerimientos imprevisibles o que se cambian rápidamente. La aplicabilidad del Desarrollo Ágil a los siguientes escenarios es cuestionable: Los esfuerzos de desarrollo a gran escala (más de 20 desarrolladores), las estrategias empleadas, ya han sido descritas. [12] Los esfuerzos de desarrollo distribuido (equipos no localizables dentro de la compañía), sus estrategias han sido descritas en Bridging the Distance (Acortamiento de Distancia) [13] y en Using an Agile Software Process with Offshore Development (Utilizando un Proceso de Software Ágil con Desarrollo en el Exterior) [14]. Esfuerzos Críticos: Misión - y vida (Mission- and life-critical efforts). Culturas de Empresa: Comando y Control (Command-and-control).

8 8 Sandra Dinora Orantes Jiménez Barry Boehm y Richard Turner sugieren que el análisis de riesgo sea usado para escoger entre métodos adaptables ("ágil") y predictivos ("conducidos por plan"). [7] Los autores sugieren que cada método tenga su propio sitio: Métodos Ágiles: Bajo riesgo Desarrolladores Senior Requerimientos muy cambiantes Número pequeño de desarrolladores Cultura que prospera sobre el caos Métodos Predictivos: Alto riesgo Desarrolladores Junior Bajos cambios en los requerimientos Número grande de desarrolladores Cultura que exige tener orden 4 Evaluación de la Calidad del Software Al hablar de la calidad del software, pueden distinguirse dos áreas principales: calidad del producto y calidad del proceso de desarrollo [18][19]. 4.1 Evaluación del Producto Para las organizaciones dedicadas al desarrollo de software, es importante ofrecer productos de un alto grado de calidad y así, enfrentarse a la fuertemente creciente competitividad que existe en ese ramo, no solamente a nivel local, sino incluso internacional. Por esta razón, necesitan definirse un conjunto de actividades cuidadosamente planificadas que les permita vigilar los productos a lo largo de todas las etapas del ciclo de vida de desarrollo del software, para asegurar la calidad del producto final. Para evaluar la calidad de un producto de software, han surgido distintos modelos que toman en cuenta diversos atributos de calidad. Al evaluar estos atributos de calidad en diferentes etapas (jerarquía de atributos), se puede determinar la calidad del producto de software. Entre los modelos más importantes que evalúan la calidad del producto de software se encuentran los siguientes:

9 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 9 El modelo de McCall. Incorpora once factores, desde el punto de vista de tres ejes: operación del producto, revisión del producto y transición del producto. Las métricas son preguntas, que ponderan numéricamente un determinado atributo del producto de software. Tras obtener los valores para todas las métricas de un criterio específico el promedio de ellas es el valor para dicho criterio [20]. El modelo de Bohem. Propone una jerarquía de niveles, en forma de un árbol con tres ramas principales de los criterios de calidad que permiten que el software sea de utilidad: Portabilidad, Facilidad de Uso y Facilidad de Mantenimiento. Tiene tres niveles: Aplicaciones primarias, Construcciones Intermedias y Construcciones Primitivas, y finalmente las Métricas que determinan los valores para los criterios (construcciones primitivas) [21]. ISO/IEC Estándar internacional (ISO), aplicable a todo tipo de software. Está basado en un modelo jerárquico con tres niveles: Características, Subcaracterísticas y Métricas. En el primer nivel tiene seis características principales: Funcionalidad, Confiabilidad, Eficiencia, Facilidad de Mantenimiento, Portabilidad y Facilidad de Uso. Estas características (factores) están compuestas a su vez por 27 subcaracterísticas (subfactores) relacionadas con la calidad externa, y 21 subcaracterísticas relacionadas con la calidad interna [22]. 4.2 Evaluación del Proceso de Desarrollo de Software Al evaluar la calidad de los procesos de desarrollo de software, se pretende determinar su rendimiento para corregir problemas o para mejorarlos, con el propósito de disminuir los costos de desarrollo, aumentar la productividad y elevar la calidad de los productos. Un proceso de desarrollo de software es el conjunto de actividades, métodos y prácticas que se usan para desarrollar un producto de software y darle mantenimiento. Entiéndase como producto de software tanto a los programas, componentes y sistemas y la variedad de documentos asociados al mismo (documentos de planificación, diseño, código, casos de prueba, manuales, reportes). Una organización debe establecer estrategias para que al evaluar los procesos que intervienen en el desarrollo de un producto de software y que al conocer su estado actual, se pueda alcanzar el estado deseado para los mismos. El estado actual o deseado de un proceso se asocia directamente con su rendimiento, es decir, los resultados logrados actualmente o que se pretenden alcanzar siguiendo ese proceso de software.

10 10 Sandra Dinora Orantes Jiménez Es importante que todas las tareas que intervienen en el desarrollo de un producto de software sean tratadas como procesos, para que puedan ser medidas y controladas. Se mencionan a continuación, el modelo de CMM (Capability Maturity Model, Modelo de Madurez de Capacidades) y los estándares internacionales considerados importantes para la evaluación de los procesos de desarrollo software: CMM-SEI. El Modelo de Madurez de Capacidades del SEI (Software Engineering Institute, Instituto de Ingeniería de Software), es un modelo que determina la madurez de los procesos de desarrollo de software y que busca mejorar esa madurez, reconociendo las prácticas clave necesarias para lograrlo. En una organización dedicada al desarrollo de software, las prácticas se pueden repetir mediante el establecimiento y uso de políticas y procedimientos que permitan implementarlas y llevarlas a cabo regularmente (estandarización). Estas prácticas deben aplicarse en todos los proyectos que la organización maneja, y por todos los grupos de trabajo que en ella colaboran. Se establecen objetivos cuantitativos y se realizan evaluaciones. Un proceso puede ubicarse en un determinado Nivel de Madurez, el cual es una plataforma evolutiva bien definida, en la búsqueda de la madurez de un proceso de desarrollo de software. En cada uno de los niveles se indica el nivel de la capacidad de un proceso determinado. Existen cinco Niveles de Madurez de Procesos: Inicial, Repetible, Definido, Administrado y Optimizado [23]. ISO/IEC 12207:AMENDMENT 1:2002. Esta norma que tiene por nombre Software life-cycle processes (Procesos del ciclo de vida del Software). Describe los procesos principales que componen un ciclo de vida de software integral, incluyendo sus interrelaciones. No establece un paradigma de Ingeniería de Software a ser utilizado, pero indica los requisitos mínimos de ingeniería necesarios en el contexto del ciclo de vida de software. Agrupa los procesos del ciclo de vida en 3 grandes clases: Procesos Primarios, Procesos de Soporte, y Procesos de Organización. Cada proceso se considera como un conjunto de actividades, que a su vez se subdividen en tareas. Estas últimas transforman las entradas del proceso y generan sus salidas. Se definen en la norma un total de 22 procesos, 95 actividades y 325 tareas. Se identifican dos roles principales desempeñados en una organización a lo largo del ciclo de vida del software: cliente y proveedor [24]. ISO/IEC La norma tiene como titulo Process Assessment (Evaluación del Proceso de Software). Establece los requisitos para realizar una evaluación de los procesos de desarrollo de software, para lograr una mejora de tales

11 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 11 procesos y para determinar su capacidad. La evaluación se lleva a cabo tomando en cuenta los procesos y sus capacidades. Para evaluar los procesos, se acude a un modelo externo, que consta de un conjunto de procesos divididos en cinco categorías, caracterizados por sus objetivos y sus repercusiones. La evaluación de capacidades hace uso de un marco de trabajo que contiene seis niveles de capacidad del proceso (Incompleto, Realizado, Administrado, Establecido, Previsible y Optimizado), con una serie de atributos del proceso, los cuales se relacionan directamente con la administración y mejora de su capacidad de realización. Cada atributo se evalúa, para ubicarlo en alguno de los siguientes estados: No conseguido, Parcialmente conseguido, Ampliamente conseguido, Completamente conseguido. Se realiza la evaluación de todos los atributos de un proceso específico y se calcula su nivel de capacidad. Para alcanzar un determinado nivel, todos los atributos asociados con los niveles inferiores deben haberse valorados como Completamente conseguidos y los atributos de ese nivel específico deben haberse valorado como Ampliamente conseguidos o Completamente conseguidos [25]. 5 Adaptación de Métodos Ágiles asegurando la Calidad de Software Tomando en cuenta lo planteado en la sección 4, sobre la Evaluación de la Calidad del Software, tanto para el producto como para el proceso y que los modelos y estándares han sido elaborados pensando en el empleo de Metodologías Tradicionales y además, considerando que un método debería ser bastante flexible para permitir ajustes durante la ejecución de proyecto. Hay tres problemas claves relacionados con la adaptación de Métodos Ágiles a proyectos de software intentando garantizar la Calidad de Software: la confiabilidad de los Métodos Ágiles (en general y en particular), Métodos Adaptables al Entorno (Tailoring) y finalmente, soporte brindado por la administración al desarrollo del proyecto. 5.1 Confiabilidad de los Métodos Ágiles Lograr que los proyectos desarrollados con Metodologías Ágiles sean de calidad no es una tarea fácil, se tiene que garantizar que el método elegido es confiable y que el producto resultante también lo es.

12 12 Sandra Dinora Orantes Jiménez Como es sabido, comprender los requisitos del cliente es fundamental para asegurar que el desarrollo de software es exitoso, el problema está, en que los usuarios rara vez tienen la habilidad para articular lo que realmente requieren y sus necesidades cambian cuando ven el potencial del sistema y comprenden lo que éste puede hacer por ellos. Por otra parte, la tecnología y el dominio también cambian y mientras más tiempo tome el desarrollo, más cambiarán. Por consiguiente, intentar conocer todos los requisitos del producto al comienzo del proyecto no es factible a un costo razonable. El proceso normal empleando una Metodología Tradicional, es entrevistar al cliente, elaborar un documento de Definición de Requisitos que será revisado por el responsable del proceso que se automatizará y que da como resultado el documento de Especificación de Requisitos que es el que se le entregará al Jefe de Proyecto (Analista de Sistemas) para iniciar el desarrollo, sabiendo que se iteró lo suficiente, para que las necesidades del Cliente hayan quedado realmente bien definidas y entendidas, para que el sistema resultante sea lo que se espera y que se obtenga un desarrollo de Calidad, el problema está en que solamente en la recopilación de requerimientos pasaron semanas o meses (véase Fig. 1). Con las Metodologías Ágiles el proceso no es tan riguroso y el Cliente forma parte del equipo de desarrollo en todo momento y en lugar de revisar documentos, se examinará software funcionando, garantizando que lo que el Cliente observa es lo que necesita y con la calidad que él espera, recordando que la Calidad del Software depende de las necesidades del negocio y que los requisitos irán evolucionando en cada iteración y para que el riesgo no aumente en la explotación del Sistema, se focalizará el esfuerzo en los requisitos que tienen el mayor valor de retorno (véase Fig. 2). Para lograrlo, al comienzo de cada iteración se hace un Levantamiento y Análisis de los Requisitos, donde participa el equipo completo incluyendo al dueño del producto y expertos técnicos que sean necesarios. Además, se realizarán entrevistas sobre características relevantes que se tienen que considerar en el proyecto que se está desarrollando, se harán tantas entrevistas como se requieran para garantizar que el producto sea lo que se espera y cada una durará tiempos cortos prefijados, para elaborar correctamente la lista de requisitos y establecer prioridades. Será necesario dejar claramente establecido con el cliente los Atributos para medir la Calidad. Documento de Definición de Requisitos Documento de Especificación de Requisitos

13 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 13 Cliente Analista de Sistemas Gerente de Producto Fig. 1. Aproximación Clásica (Rigurosa) SOFTWARE Cliente Equipo de Desarrollo Fig. 2. Aproximación Ágil 5.2 Métodos Ágiles y Métodos de Entorno En la literatura, términos diferentes se refieren a la noción de métodos de adaptación, incluyendo el ' Método de Entorno ' (method tailoring), ' Método de adaptación de fragmento ' (method fragment adaptation) e ' Ingeniería Circunstancial de Métodos ' (situational method engineering). El Método de Entorno se define como: Un proceso o capacidad, en el cual, los seres humanos responden al cambio y a interacciones dinámicas entre contextos, intenciones y fragmentos de métodos para determinar el mejor enfoque para el desarrollo de un sistema para un proyecto o situación específica. [15] Potencialmente, casi todos los Métodos Ágiles son convenientes para adaptarse como métodos de entorno. Incluso el método DSDM se está utilizando para este propósito y se ha adaptado con éxito al contexto de CMM [11]. Se puede considerar en situaciones apropiadas, que una característica que distingue entre los métodos ágiles y los métodos tradicionales del desarrollo del software, es que tienden a ser relativamente mucho más rígidos y prescriptivos y no tan fácilmente adaptables.

14 14 Sandra Dinora Orantes Jiménez La implicación práctica es que los métodos ágiles permiten que los equipos de proyecto adapten prácticas de trabajo según las necesidades de proyectos individuales. Las prácticas son actividades concretas y los productos son parte del marco de trabajo del método. En un nivel extremo, la filosofía detrás del método, consiste en un número de principios, que pueden ser adaptados [15]. En el caso de XP la necesidad de adaptación del método se hace explícita y una de sus ideas fundamentales, es que no hay un proceso fijo para cada proyecto como tal, pero en la práctica debe ser adaptado a las necesidades de proyectos individuales. No hay tampoco informes de la experiencia con las prácticas, en las cuales, se ha adoptado XP; sin embargo, una adopción parcial de las prácticas de XP, según lo sugerido por Beck (Kent Beck es el creador de extreme Programming y uno de los fundadores del Manifiesto Ágil), sí ha sido reportado en varias ocasiones [16]. Puede hacerse una distinción entre la adaptación estática y la adaptación dinámica del método. [17] La clave detrás de la adaptación estática, es que el contexto del proyecto está dado al comienzo y el resto es fijado durante su ejecución y el resultado, es una definición estática del contexto del proyecto y dada tal definición, los mapas de ruta se pueden utilizar para determinar cuáles fragmentos estructurados de métodos, se deben emplear para ese proyecto particular, basándose en un conjunto de criterios predefinidos. La adaptación dinámica del método, en contraste, asume que los proyectos están situados en un contexto inesperado. Un contexto inesperado implica que un proyecto tiene que ocuparse de los factores imprevisibles que afectan condiciones relevantes que no son previsibles y esto también significa, que el contexto del proyecto no es fijo, cambia durante su ejecución y que en el caso de rutas reguladas, no son apropiados. La implicación práctica de la adaptación dinámica del método es que los encargados de proyecto tienen que modificar fragmentos estructurados o innovar a menudo nuevos fragmentos, durante la ejecución de un proyecto.[17] 5.3 Soporte brindado por la administración al desarrollo del proyecto No hay que olvidar que al emplear Métodos Ágiles, el Cliente pasa a formar parte del equipo de desarrollo, se le tomará en cuenta como tal en todas las iteraciones y para el éxito del proyecto, la administración de la organización debe estar dando el soporte necesario durante todo el desarrollo, brindando todo lo que sea

15 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 15 necesario para que el producto automatizado resultante, sea con la Calidad esperada por la empresa. Se tendrán que elaborar talleres y delimitar el tiempo que se dedicará a cada uno de ellos y a las actividades a revisar en cada reunión, los estudios sugeridos son: 1. Levantamiento y Análisis de los Requisitos: que tiene que tener una duración fija y corta como sigue: El dueño del producto presenta sus requisitos y el equipo participa a través de preguntas (duración 4 horas). El equipo de desarrollo realiza una lista de tareas que deben realizarse para cumplir con los requisitos (duración 8 horas), las tareas son estimadas en duración (no más de 8 horas cada una). El dueño del producto revisa las estimaciones del equipo y prioriza sus requerimientos por valor, de manera que puedan ser implementados por el equipo en una iteración corta, estableciendo la visión común para la iteración (duración 4 horas). 2. Entrevista sobre características Relevantes: tiene como objetivo obtener del cliente información para elaborar una lista de requisitos, para ello, se establecerán trabajos en grupo (duración 20 minutos), por lo cual, deberán preparse un conjunto de preguntas previas a la entrevista con el cliente que permitan generar una lista con los requerimientos detectados. Una recomendación al elaborar el cuestionario guía para la entrevista, es reflexionar lo siguiente: Cuán difícil es preparse? Cuán consistente es el cliente en sus respuestas? Fue fácil ordenar la información del cliente para hacer una lista de requisitos? 3. Especificación de Atributos de Calidad: su objetivo es identificar atributos de calidad considerados críticos para el éxito del proyecto, para ello se analiza el Backlog del Producto (Trabajo atrasado del Producto), para poder listar los atributos críticos cuantitativos priorizados. Las tareas a realizar en esta reunión son: una lluvia de ideas sobre atributos (pueden tomarse ideas de la norma ISO/IEC 9126 ó de otro modelo que evalúe la calidad del producto), se reunen atributos en temas relacionados, se identifican los atributos considerados críticos, se especifícan cuantitativamente los dos atributos más críticos mediante Escala, Prueba, Plan, Peor y se comparten los resultados. Y al final de la reunión, el equipo debe reflexionar sobre Cómo partir inventando atributos? Qué determina que un atributo sea o no crítico? Qué tan difícil es inventar

16 16 Sandra Dinora Orantes Jiménez una escala y prueba? Qué tan importante es tener los valores planificados, bien definidos desde el comienzo? 5.4 Requisitos de Calidad En resumen y tomando en cuenta los tres problemas claves relacionados con la adaptación de Métodos Ágiles a proyectos de software, que garanticen que el producto resultante sea de calidad y que el proceso seguido por el método también lo sea, de alguna forma es necesario tomar en cuenta la Especificación de Atributos de Calidad e incrustarla como parte del método a seguir, no olvidando lo que ya se mencionó, que la calidad depende de las necesidades del negocio o cliente, así algunos esperan: buen desempeño y funcionamiento, que trabaje bien tanto en una plataforma como en otra (UNIX, PC), que el producto se adapte a necesidades específicas (AD HOC), que sea fácil de usar, que no tenga defectos, que tenga buena manufactura y que dure mucho tiempo, etc. Para establecer bien la lista de requerimientos, es necesario tomar en cuenta que existen dos tipos de requisitos: Funcionales, los cuales, se cumplen o no se cumplen (responden al Qué ) y de Calidad o Atributos, que se pueden cumplir en distinto grado (responden a Qué tan bien ). Todos los atributos se pueden y se deben expresar sin ambigüedades, si un requisito se expresa claramente, se le da prioridad sobre los no tan claros, así por ejemplo, si se desea que los datos sean consistentes puede establecerse el grado de consistencia que se considera aceptable. Para describir un atributo, se sugiere utilizar el siguiente modelo: Atribu Nombre del Atributo to: Tipo: Si es cuantificable, facilidad de uso, facilidad de aprendizaje, completez, recursos, etc. Escala Qué se mide (una dimensión) : Prueb Cómo se mide (un procedimiento) a: Peor: Valor apenas aceptable Plan: Valor que se desea alcanzar, en conjunto con los Autori dad: demás requisitos de calidad Quién, Qué o de Dónde sale (sus orígenes)

17 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 17 Actual Valor alcanzado en el sistema : Mejor: El mejor valor alcanzado por alguien en alguna parte Además, suele ser conveniente expresar los atributos como una jerarquía, existirán atributos que son usualmente importantes y la lista de estos requisitos de calidad, debería ser parte de una plantilla para la especificación de requisitos. De acuerdo a la norma ISO/IEC 9126 [22] son 6 los atributos que se consideran importantes: Funcionalidad, Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad; puede tomarse como base este modelo de evaluación de la calidad del producto u otro que se considere conveniente o que el Cliente considere adecuado. Para poder establecer el listado de atributos es necesario conocer el Backlog del Producto a desarrollar. Backlog del Producto Para establecerlo, es necesario elegir una Metodología Ágil, como puede ser: XP, IXP (Industrial Extreme Programming, Programación Extrema Industrial), Scrum, Agile Modeling (Modelado Ágil), ASD (Adaptive Software Development, Desarrollo de Software Adaptativo), Crystal Clear y otras Crystal Methodologies (Metodologías Crystal), DSDM, FDD, Lean software development (Desarrollo de Software de Soporte), AUP (Agile Unified Process, Proceso Unificado Ágil) o Dialogue-Driven Development (Desarrollo Manejado por Diálogo) y seguir el proceso, que dicte la metodología elegida. Lo importante es que el Backlog del Producto incluye elementos que se necesitan para iniciar el proyecto y los elementos del retraso, están clasificados (Función). Además, deben tomarse en cuenta factores que típicamente, complican el Backlog del Producto: Complejidad del Producto: acuerdo en los requisitos y estabilidad de la tecnología a utilizar. Complejidad del Equipo de Desarrollo: experiencia del equipo trabajando juntos, conocimiento por parte del equipo de la tecnología a utilizar, conocimiento por parte del equipo de negocio donde el producto se desarrolla. La Complejidad se usa para corregir el esfuerzo estimado. Se deberá estimar el esfuerzo de implementación de cada requisito, incluyendo esfuerzo para análisis, diseño, desarrollo, documentación y pruebas, así como el estimado de la cantidad de personas-días y corregir el esfuerzo de cada requisito según su complejidad.

18 18 Sandra Dinora Orantes Jiménez Resumiendo, para la creación del Backlog del Producto se tiene que: 1. Priorizar y estimar el Backlog del Producto. 2. Se necesita para ello, la lista de requisitos y atributos críticos. 3. Las tareas a realizar son: Reunir las entradas poniéndolas en una única lista, priorizar y estimar las características relevantes, planificar el número de iteraciones que se requieren para implementar el retraso. 4. Se deben considerar equipos en donde los desarrolladores han estado trabajando juntos al menos durantes los últimos 12 meses en la tecnología requerida por el proyecto. Al menos tres de los integrantes del equipo, tienen que tener bastante experiencia en desarrollos para el sector en el que se lleva a cabo el proyecto. 6 Métodos Ágiles y la Administración del Proyecto Los Métodos Ágiles se diferencian grandemente de los tradicionales, por la manera en que cubren la administración de proyectos y algunos métodos, se complentan con guías para la administración del proyecto, pero generalmente no existe ninguna documentación de soporte [11]. Tomando en cuenta todo lo descrito en la sección 5 de esta investigación, si se elige un Método Ágil para el desarrollo de un proyecto, es posible que el producto resultante sea de calidad. Como ejemplo, PRINCE2 (PRojects IN Controlled Environments, Proyectos en Ambientes Controlados) es una metodología ágil recomendable para la administración de proyectos que cubre la administración, control y organización de un proyecto.[26] 7 Conclusiones En muchas ocasiones no es posible disponer de unas especificaciones correctas desde el primer momento, porque puede ser difícil para el usuario establecer al inicio todos los requisitos; en otras, hay cambio de parecer de los usuarios sobre las necesidades reales cuando ya se ha comenzado el proyecto, siendo probables que los verdaderos requisitos no se reflejen en el producto final. Otro de los problemas de esta aproximación es que los resultados no se ven hasta muy

19 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 19 avanzado el proyecto, por lo tanto la realización de modificaciones, si ha habido un error, es muy costosa. El desarrollo ágil se confunde en ocasiones con la Codificación de Vaquero (Cowboy Coding), sin embargo ofrece soluciones al problema de la especificación de requerimientos, tratando de garantizar que el producto resultante sea de calidad y lo esperado por el cliente, las Metodologías Ágiles han tenido muchas críticas, por ejemplo, XP inicialmente ocasionó mucho ruido y controversia, sin embargo incluso los partidarios de desarrollos con Métodos Ágiles, lo interpretaron como malos entendidos acerca del desarrollo ágil. Los Métodos Ágiles no presuponen algún tipo de ciclo de vida para su ejecución, es más bien una filosofía de valores, ideas, conceptos y principios para aplicar en la metodología que se desarrolle. Los Métodos Ágiles y las técnicas de desarrollo orientadas a objetos, se adaptan mejor o manejan mejor la incertidumbre, pero, como nada es gratis son más costosas. Por tanto, no siempre se justifican y además, su adopción general, como un camino más, requiere de un cambio cultural que se está produciendo, pero que no se ha completado aún. Existen muchos otros artículos y discusiones sobre este tema de los Métodos Ágiles. Mientras éstas pueden no ser metodologías completas, ofrecen una luz sobre este campo creciente.

20 20 Sandra Dinora Orantes Jiménez Metodologías Ágiles Enfatizan en el desarrollo iterativo construyendo software en períodos cortos de tiempo, como cajas cerradas de un tiempo estricto. El trabajo se realiza de manera colaborativa. Desarrollo Iterativo El período de tiempo es medido en meses y si no se tiene una buena planificación, los proyectos se salen de control. A veces no es muy colaborativo. Metodologías Tradicionales Modelo de Cascada El período de tiempo es medido en meses y si no se tiene una buena planificación, del tiempo que debe durar cada etapa, los proyectos se salen de control, ya que, es la más predictiva de todas las metodologías, pasando por la exigencia de la captura de requerimientos, análisis, diseño, codificación y pruebas en una secuencia estricta preplaneada. Tiende a ser sumamente colaborativo porque cada etapa tiene que estar bien definida y terminada para pasar a la siguiente. Cowboy Coding Es la ausencia de un método definido: los miembros de equipo hacen lo que ellos sienten que es lo correcto. La nueva evaluación frecuente del desarrollo ágil de proyectos, enfatiza en la comunicación cara a cara y el empleo relativamente escaso de documentos, que en ocasiones hace que los desarrolladores lo confundan con Cowboy Coding (Codificación de Vaquero). Sin embargo, los Equipos Ágiles, realmente siguen

21 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 21 Producen un desarrollo completo y probado (pero a una menor escala) en pocas semanas o meses. Enfatizan en obtener piezas funcionando que le den un valor agregado al negocio prontamente y continuamente mejoran y/o adicionan funcionalidad durante el tiempo de vida del proyecto; en ocasiones, no se realizan pruebas, sino hasta que el software se encuentra completamente trabajando. El porcentaje de las pruebas abarca un 40% de todo el desarrollo del software y en ocasiones, si no se planifica bien el tiempo para pruebas puede ser causante de que el proyecto falle. Puede dar como resultado una integración y esfuerzos de pruebas a través de todo el ciclo de desarrollo, un período de tiempo que a veces se extiende a varios meses o varios años. El tamaño y dificultad de la integración y esfuerzo de pruebas es causante de que el proyecto falle. procesos definidos (a menudo de forma muy disciplinada y rigurosa), distinguiendo accesos ágiles de la codificación de vaquero. Como con todas las metodologías, la habilidad y la experiencia del usuario define el grado de éxito y/o abuso de tal actividad. Los controles y/o chequeos más rígidos y los balances encajados dentro de un proceso, ofrecen niveles rigurosos de responsabilidad del usuario; es decir, la degradación de procedimientos

22 22 Sandra Dinora Orantes Jiménez Acentúan en que el software trabajando es la primera medida del progreso. Se produce poca documentación. Pocos artefactos. 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) que es altamente colaborativo y existen pocos roles, bien definidos. Proceso menos controlado, con pocos principios. El progreso se mide por cada entregable tangible al final de una iteración. El progreso se mide en términos de datos específicos que exigen artefactos entregables, documentos de diseño, proyectos de prueba y revisiones de código. Se produce mucha documentación. Más Artefactos. Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo. Cierta resistencia a los cambios, debido a que al planeación tiene que rehacerse y se corre el riesgo de desechar todo el trabajo y volver a empezar todo de nuevo. Impuestas externamente y en ocasiones es necesario combinar las metodologías para llegar al buen termino de los proyectos y cumplir así con la planificación establecida, por otra parte, existen más roles que controlar. Proceso mucho más controlado, con numerosas políticas/normas que ayudan a acotar la planificación de cada etapa. bien intencionados que conducen a actividades, a menudo definidas como Codificación de Vaquero.

23 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 23 No existe contrato tradicional o al menos, es bastante flexible. El cliente es parte del equipo de desarrollo. Grupos pequeños (menos de 10 integrantes) y trabajando en el mismo sitio y tienen que ser personal altamente calificado en el tipo de desarrollo. Menos énfasis en la arquitectura del software. Poco énfasis en el seguimiento de una Gestión de Calidad. Existe un contrato prefijado, para la planificación y tiempos establecidos. El cliente interactúa con el equipo de desarrollo mediante reuniones, pero no se considera parte del equipo, solamente aporta opiniones y da su visto bueno. Grupos grandes y posiblemente distribuidos, no necesariamente con experiencia en el nuevo desarrollo. La arquitectura del software es esencial y se expresa mediante modelos. Mucho énfasis en el seguimiento de una Gestión de Calidad. Tabla 1. Comparativo entre Metodologías Ágiles y Metodologías Tradicionales (No Ágiles)

24 24 Sandra Dinora Orantes Jiménez Referencias [1] Craig Larman, Victor R, Basili. Iterative and Incremental Development: A Brief History. Published by the IEEE Computer Society. June [2] Véase la liga de Alianza Ágil: [3] Véase la liga del Manifiesto Ágil: [4] Ron Jeffries, Ann Anderson, Chet Hendrickson. Extreme Programming Installed (Paperback). The XP Series. December [5] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. [6] Véanse los principios en la liga: [7] Barry Boehm, R. Turner. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley. ISBN Appendix A, pages [8] Laplante, P.A., C.J. Neill (February 2004). The Demise of the Waterfall Model Is Imminent and Other Urban Myths. ACM Queue 1 (10). Retrieved on [9] Coleman and Verbruggen: A quality software process for rapid application development, Software Quality. Journal 7, p [10] Cohen, D., Lindvall, M., & Costa, P. An introduction to agile methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science, [11] Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, , [12] Scott Ambler. Architecture and Design: Supersize Me. Dr. Dobb s Magazine. February 15, (Dr. Dobb s Portal The World of Software Development: [13] Scott Ambler. Architecture and Design: Bridging the Distance. Dr. Dobb s Magazine. August 12, (Dr. Dobb s Portal The World of Software Development: [14] Martin Fowler. Using an Agile Software Process with Offshore Development. Significant Revisions: 18 Jul 06: Updated again after a trip to India. Added a lot of small changes around the document. (Véase liga:

25 Calidad de Software en el uso de Metodologías Ágiles para el Desarrollo de Software 25 [15] Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), , [16] Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. Agile Software Development Methods: Review and Analysis. VTT Publications 478, [17] Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24, [18] Somerville, I., Software Engineering, Sixth Edition. Pearson Education Limited, [19] Pressman, R. S., Software Engineering. A Practitioner s Approach, Fifth Edition. McGraw-Hill International, [20] McCall, J.A., Cavano, J.P., A Framework for the Measurement of Software Quality, ACM Software Quality Assurance Workshop, [21] Bohem, B.W., Software Engineering Economics, Prentice Hall, [22] ISO/IEC 9126: Software Engineering - Product quality, International Organization for Standardization, [23] Paulk, M., Capability Maturity Model for Software, Software Engineering Institute, Carnegie Mellon University, [24] ISO/IEC 12207: AMENDMENT 1:2002: Information technology - Software life cycle processes, International Organization for Standardization, [25] ISO/IEC 15504: Information technology - Process assessment, International Organization for Standardization, [26] Agile Alliance at