calidad de software.pdf

introducción a los modelos de calidad de software En esta unidad desarrollaremos los modelos de calidad y su evolución en el tiempo. Para empezar, deberíamos contar con una primera definición de calidad. Yo propongo la siguiente: Es la aptitud de un producto o servicio de satisfacer las necesidades del usuario. Para que esto suceda, dichas necesidades deben cumplir ciertas condiciones: ☰ Ser precisas esto significa que cualquier persona que las lea interpretará el mismo resultado u operación esperada. ☰ Ser objetivas es decir que se puedan relacionar unívocamente con un valor esperado y conocido, o dentro de un rango. ☰ Ser medibles todas las necesidades, además de tener un valor objetivo a alcanzar, deben indicar, claramente, el momento del proceso en el cual debemos alcanzar ese resultado y la forma en que lo mediremos. Si las necesidades indicadas por el cliente o usuario cumplen estas condiciones se convierten en requerimientos que pueden ser gestionados por el equipo de dirección del proyecto y su grado de cumplimiento podrá ser evaluado. Figura 1: Necesidades Fuente: Elaboración propia. 1. Características Es interesante ver similitudes entre las consideraciones de calidad de los procesos tradicionales de fabricación de algún producto y los de calidad de software. En ambos casos podemos indicar definiciones, requerimientos, medidas, etc. Pero, también, es muy interesante entender las diferencias entre los productos tradicionales y los de software, por ejemplo: El software es en sí un producto inmaterial si lo comparamos con la fabricación de cualquier producto en una línea de ensamble. No tiene las condiciones para que se degrade por el paso del tiempo. Tiene condiciones a evaluar que no son consideradas por el usuario o cliente; por ejemplo, sus condiciones de mantenimiento que, sin embargo, impactan en el resultado final. Podemos decir, entonces, que la calidad de software es el conjunto de características y cualidades que caracterizan a un software y que determinan su utilidad y existencia. Por lo tanto, cuando estudiamos la calidad del software debemos tener en cuenta diferentes “vistas”, como ser: Eficiencia. Flexibilidad. Corrección. Confiabilidad. Mantenibilidad. Seguridad. Integridad. Ahora bien, ¿cómo piensas que estamos en el cumplimiento de los objetivos de un proyecto? 2. Evaluación de los proyectos de software Según un estudio realizado por el Stadnish Group (1994) sobre 50 000 proyectos fallidos se encontró que: El 71 % de los proyectos Tienen sobrecostos, se atrasan, fracasan. El 53 % de los proyectos terminan un 45 % por encima del presupuesto original. 63 % fue el tiempo utilizado por sobre el original estimado en los proyectos problemas. Solo entregaron el 67 % de la funcionalidad comprometida. En consecuencia, podemos observar que durante el desarrollo de un proyecto inciden diferentes factores que presionan para afectar el cumplimiento de los objetivos. Por algún motivo, la reacción para contener estas presiones no rinde el resultado esperado. Con el objetivo de lograr mejoras en el desarrollo del software y en sus procesos a nivel mundial, se fueron desarrollando modelos de calidad. Estos modelos tienen como objetivo permitir a las empresas certificarse y obtener mejores resultados en sus productos y en su gestión administrativa y gerencial. Ahora que conocemos los resultados de los proyectos, piensa: ¿qué alternativas tienes para mejorar estos resultados de los proyectos? 3. Modelos existentes de calidad Existen varios modelos de calidad del software, de los cuales podemos mencionar: ☰ CMMI modelo diseñado por el Carnegie Mellon Software Engineering. Está orientado a mejoras de procesos, identifica diferentes niveles de madurez. ☰ Norma ISO/IEC 12007 este modelo fue diseñado por International Organization for Standarization. Está orientado al proceso de ciclo de vida del software. ☰ Métrica 3 este modelo fue diseñado por el Ministerio de Administración Pública de España. ☰ ISO 15504 modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. ☰ ISO 9000 este modelo detalla cómo opera una organización; cuáles son sus estándares de calidad, tiempos de entrega y niveles de servicio. ☰ EFQM diseñado por European Foundation for Quality Management, es un modelo no normativo, está orientado a la autoevaluación basada en un análisis detallado del funcionamiento del sistema de gestión de la organización. Usa como guía los criterios del modelo. ☰ TickIT basado en la norma ISO 9001:2000, creado por National Accreditation Council of Certification Board del Reino Unido, su objetivo es ayudar a las organizaciones de software a crear sistemas de calidad a través de agregar valor y cumplir con la norma ISO 9001:2000. ☰ Bootstrap creado por la Comisión Europea como parte del programa Esprit, está pensado para evaluar y mejorar la capacidad de las Unidades Productoras de Software. ☰ Team Software Process (TSP) el proceso TSP fue desarrollado por Watt Humphrey en 1996. El objetivo fue suministrar un proceso operacional que ayudase a los ingenieros a hacer trabajos de calidad. Veamos en detalle algunos de estos modelos, dejaré para más adelante el referido a CMMI. ISO 9000 Este modelo identifica y desarrolla un conjunto de normas sobre calidad y gestión continua de calidad que son establecidas por la Organización Internacional para la Estandarización (ISO). Sus conceptos pueden ser aplicados en cualquier tipo de organización o actividad orientada a la producción de bienes o servicios. “Las normas recogen tanto el contenido mínimo como las guías y herramientas específicas de implantación, como los métodos de auditoría” (“ISO 9000 - Sistema de Gestión de Calidad”, s. f., La norma ISO 9000 especifica: la manera en que una organización opera; sus estándares de calidad; tiempos de entrega; niveles de servicio. (“ISO 9000 - Sistema de Gestión de Calidad”, s. f.). Existen más de 20 elementos en los estándares de este ISO que se relacionan con la manera en que los sistemas operan. Implementar esta norma conlleva un fuerte trabajo, pero ofrece numerosas ventajas para las empresas, por ejemplo: Estandarizar las actividades del personal que trabaja dentro de la organización por medio de la documentación. Incrementar la satisfacción del cliente. Medir y monitorear el desempeño de los procesos. Disminuir re-procesos. Incrementar la eficacia y/o eficiencia de la organización en el logro de sus objetivos. Mejorar continuamente los procesos, productos, eficacia, etc. Reducir las incidencias de producción o prestación de servicio. Mantener y mejorar la calidad. (“ISO 9000 - Sistema de Gestión de Calidad”, s. f., https://www.jbsolutions.com.ar/iso-9000/). EFQM Figura 2: Modelo EFQM Fuente: [Imagen sin título sobre modelo EFQM]. (s. f.). Recuperada de Como hemos mencionado, este es un modelo no normativo. Esto no supone una contraposición a otros enfoques (aplicación de determinadas técnicas de gestión, normativa ISO, normas industriales específicas, etc.), sino más bien la integración de esos enfoques en un esquema más amplio y completo de gestión. La utilización sistemática y periódica del modelo EFQM por parte del equipo directivo permite a este el establecimiento de planes de mejora. Estos modelos están basados en hechos objetivos y la consecución de una visión común sobre las metas a alcanzar y las herramientas a utilizar, es decir, su aplicación se basa en: La comprensión profunda del modelo por parte de todos los niveles de dirección de la empresa. La evaluación de la situación en cada una de las áreas. Este modelo consta de dos partes: “Un conjunto de criterios de excelencia empresarial que abarca todas las áreas del funcionamiento de la organización” (Petit Torres, Piedrahita Vanegas y Palacio de la Hoz, 2016, https://www.redalyc.org/journal/280/28049145008/html/). Un conjunto de reglas para evaluar el comportamiento de la organización en cada criterio (Petit Torres, Piedrahita Vanegas y Palacio de la Hoz, 2016). Hay dos grupos de criterios: “Los Resultados representan lo que la organización consigue para cada uno de sus actores” (Petit Torres, Piedrahita Vanegas y Palacio de la Hoz, 2016, Clientes. Empleados. Sociedad. Inversores. “Los agentes son aspectos del sistema de gestión de la organización. Son las causas de los resultados” (Petit Torres, Piedrahita Vanegas y Palacio de la Hoz, 2016, “Para cada grupo de criterios hay un conjunto de reglas de evaluación basadas en la llamada ‘lógica REDER’” (Petit Torres, Piedrahita Vanegas y Palacio de la Hoz, 2016, TickIT Los objetivos principales de este modelo son, además de desarrollar un sistema de certificación aceptable en el mercado, estimular a los desarrolladores de software a implementar sistemas de calidad a través de la dirección y guías necesarias. TickiIT permite pensar en: ¿Qué calidad existe en los contextos de los procesos de desarrollo de software? ¿Cómo puede ser lograda la calidad? ¿Cómo los sistemas de información de calidad pueden ser mejorados en forma continua? Bootstrap Creado por la Comisión Europea como parte del programa Esprit. Este modelo está pensado para evaluar y mejorar la capacidad de las unidades productoras de software y está orientado a mejorar la calidad de los procesos de software. Aquí se define a un proceso como una serie de actividades interrelacionadas donde una entrada se transforma en salida. Este método combina la norma ISO 9000 con las normas europeas de calidad de software y el modelo de madurez CMM. Uno de sus principales objetivos es identificar los atributos del proyecto de una organización que desarrolle software y que se asignen todas las preguntas del cuestionario a los atributos de la calidad del proceso, así como a los niveles de madurez. Los objetivos de la metodología Bootstrap son: Proporcionar soporte para la evaluación de la capacidad de los procesos utilizando un conjunto de prácticas de ingeniería del software (SW). Incluir estándares de ingeniería del software reconocidos internacionalmente como fuentes para la identificación de las prácticas a considerar. Brindar soporte a la evaluación, indicar cómo el estándar de referencia ha sido aplicado en la organización evaluada. Asegurar la fiabilidad y capacidad de repetición de la evaluación. Identificar las fortalezas y debilidades de los procesos de la organización evaluada. Dar soporte a la creación y aplicación de un plan de mejora que genere resultados aceptables y fiables de forma que las acciones del plan de mejora permitan alcanzar los objetivos de la organización. Ayudar a incrementar la eficacia de los procesos poniendo en práctica los requisitos del estándar en la organización. El enfoque de esta metodología es evaluar el proceso, no el producto. Esto se logra obteniendo la información relevante, por ejemplo: Identificar las características identificativas de los procesos. Armar un análisis cuantitativo del proceso. Generar una visión analítica de los procesos. Identificar las fortalezas y debilidades. Identificar las áreas de mejora. Generar recomendaciones. Armar el plan de implementación. El modelo Bootstrap define el paradigma organización metodología tecnología que se usa en Bootstrap para los niveles de evaluación y agrupación de resultados. Dicho modelo ha sido estructurado en correspondencia con la arquitectura de procesos definida en la ISO 15504. Team Software Process (TSP) El proceso TSP fue desarrollado por Watt Humphrey en 1996 (Humphrey, 1989). Su objetivo es “suministrar un proceso operacional que ayude a los ingenieros a hacer trabajos de calidad” (Humphrey, 1989). El principal motivador para el desarrollo de TSP fue la convicción de que los equipos de ingenieros pueden hacer el trabajo de manera extraordinaria, pero solo si ellos son formados y entrenados. El objetivo del TSP es construir y guiar a los equipos. Los equipos son requeridos para la mayoría de los proyectos de ingeniería. El desarrollo de sistemas es una actividad en equipo y la efectividad del equipo determina la calidad de la Ingeniería. En ingeniería, los equipos de desarrollo tienen múltiples especialidades y todos los miembros trabajan en vista de un objetivo en común. Los objetivos de TSP son: 1. Ayudar a los equipos de ingeniería de software a elaborar productos de calidad dentro de los costos y tiempos establecidos. 2. Tener equipos rápidos y confiables. 3. Optimizar la performance del equipo durante todo el proyecto. ISO 9000 - Sistema de Gestión de Calidad. (s. f.). En J&B Solutions [Blog]. Recuperado de https://www.jbsolutions.com.ar/iso-9000/ Petit Torres, E. E.; Piedrahita Vanegas, G. A. y Palacio de la Hoz, A. A. (2016). Estrategia organizacional para afrontar auditorias en sistemas de gestión integrados. Revista de Ciencias Sociales (Ve), XXII(2), https://www.redalyc.org/journal/280/28049145008/html/ pp. 92-110. Recuperado de 1. Modelos de calidad de gran difusión en el medio local. CMM y CMMI Con el fin de ver los modelos de calidad en el medio local, acudiremos al Anexo VI de la Resolución 61 de la Secretaría de Industria de la Nación, en el que se menciona lo siguiente: 1) CERTIFICACIÓN DE PROCESOS DE PRODUCCIÓN CMM CMMI IRAM-ISO 9001 /// ISO/IEC 90003 IRAM 17601 (CMMI (SEI)) ISO/IEC 15504 (IRAM-ISO/IEC 15504) 2) CERTIFICACIÓN DE CALIDAD DE PRODUCTO ISO/IEC 9126 (IRAM-ISO/IEC 9126) Solo como introducción, puedo decir que existen dos normas/modelos de calidad ampliamente difundidos para aplicar. Estos son las normas ISO 9000:2000 (de las cuales la ISO 9001 es la que se certifica) y el modelo CMMI. Ambos tienen los mismos principios, aunque difieren en muchos otros aspectos. Las normas ISO 9000 son de aplicación genérica a cualquier industria u organización, es decir, no son específicas para empresas informáticas. Han sido adaptadas a más de 90 países e implantadas en todo tipo de organizaciones industriales y de servicios. Estas tienen mayor difusión en Europa. Para obtener la certificación de la norma, se deben implementar sus capítulos. ISO 9000:2000 está compuesta básicamente por: ☰ ISO 9000 guía y terminología. ☰ ISO 9001 (la norma propiamente dicha, que se certifica): corresponde a sistemas de calidad destinados al cliente externo. Incluye aspectos tales como el diseño, la fabricación, la instalación y el mantenimiento. ☰ ISO 9004 guía para la mejora continua; en general, está destinada a proporcionar las directrices para la implantación de la calidad interna de la propia empresa y no es certificable. El modelo CMMI (Capability Maturity Model Integration) fue creado en Estados Unidos, tiene gran difusión en dicho territorio y también en muchos otros países, especialmente en polos informáticos como la India y en otros países emergentes. Está específicamente dirigido a empresas informáticas. No es una norma, sino un modelo de referencia que contiene un conjunto de prácticas por áreas de proceso. Como todo modelo, indica “QUÉ” hacer y no “CÓMO” hacerlo. El modelo tiene como objetivo la mejora continua de la calidad de los procesos y productos de una organización, y provee una guía que establece niveles de madurez. El modelo presenta 5 niveles de madurez. Para ser evaluado en determinado nivel, debe implementarse un conjunto determinado de prácticas (requeridas). A grandes rasgos, estas son las características de cada nivel: NIVEL 1: En este nivel se encuentra la mayoría de las organizaciones. Los procesos son impredecibles, pobremente controlados y reactivos. NIVEL 2: Las áreas de proceso de este nivel están orientadas a la gestión. Los procesos son definidos, documentados, utilizados y medidos. NIVEL 3: En este nivel, los procesos se encuentran estandarizados y documentados a nivel organizacional. Las áreas de proceso que se incorporan están orientadas a la ingeniería. NIVEL 4: En este nivel, los procesos son predecibles, medibles y controlables. La calidad y productividad son predecibles cuantitativamente. NIVEL 5: Las organizaciones que se encuentran en este nivel ponen foco en la mejora continua de sus procesos. Historia de los procesos de desarrollo Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Un producto de software es intangible y, por lo general, muy abstracto, lo que dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos de software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. A pesar de la variedad de propuestas de procesos de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos. Podemos mencionar las siguientes actividades: 1. Especificación de software: se debe definir la funcionalidad y restricciones operacionales con las que debe cumplir el software. Diseño e implementación: se diseña y construye el software de acuerdo a la 2. especificación. 3. Validación: el software debe validarse para asegurar que cumpla con lo que quiere el cliente. 4. Evolución: el software debe evolucionar para adaptarse a las necesidades del cliente. Además de estas actividades fundamentales, Pressman menciona un conjunto de “actividades sombrilla” (Pressman, 2010, p. 13). Estas actividades se aplican a lo largo de todo el proceso del software. El autor las identifica como: Seguimiento y control de proyecto de software. Revisiones técnicas formales. Garantía de calidad del software. Gestión de configuración del software. Preparación y producción de documentos. Gestión de reutilización. Mediciones. Gestión de riesgos. Por su parte, Sommerville (2009, p. 8 y 9) define modelo de proceso de software como “una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real”. Los modelos genéricos no son descripciones definitivas de procesos de software, sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Codificar y corregir. Modelo en cascada. Desarrollo evolutivo. Desarrollo basado en reutilización. Desarrollo incremental. Desarrollo en espiral. (“Proceso de Software y Ciclo de Vida”, s. f., Codificar y corregir (Code-and-Fix) Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos: Escribir código y corregir problemas en el código: Se trata, primero, de implementar algo de código y, luego, pensar acerca de requisitos, diseño, validación y mantenimiento. Este modelo tiene tres problemas principales: Después de un número de correcciones, el código puede tener una muy mala estructura, lo que genera que los arreglos sean muy costosos. Frecuentemente, aun cuando el software está bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara. El código es difícil de reparar por su pobre preparación para probar y modificar. (“Proceso de Software y Ciclo de Vida”, s. f., Sin embargo, debemos tener presentes los siguientes comentarios de McConnell (McConnell, S. 1996): ☰ Código infernal El modelo emprendedor o de la empresa pionera, en el que se combinan las técnicas de codeand-fix y planificaciones ambiciosas, no funciona. Es un claro ejemplo de que dos mentiras no hacen una verdad. ☰ Sálvese el que pueda o abandonar el plan bajo presión En muchas empresas, se produce la situación en la que, tras un inicio de planificación, control, y supuesta buena gestión, se llega a una encrucijada en la que la acumulación de problemas y la asfixia de los plazos, problemas y errores hace que el equipo abandone toda planificación y se dedique a programar a toda costa, en un puro y duro "code-and-fix". Esto también se produce cuando en un proyecto por entregas, una primera entrega desastrosa hace que la única decisión que se les ocurra a los gestores de turno sea... abandonar toda planificación. (Miñana, 2012, http://calidadysoftware.blogspot.com/2012/03/code-andfix.html). Este modelo es efectivo para productos o sistemas pequeños, principalmente cuando se trata de desarrollos unipersonales. En contraste, el diseño final puede ser de estilo "spaghetti", es decir que, al ir pegando poco a poco diferentes partes de código, es posible obtener un producto que, aunque funcione, no sea muy coherente y no cuente, desde el punto de vista del diseño, con una arquitectura legible y razonable. Por tanto, este modelo no es adecuado para sistemas medianos y grandes. Su característica principal es que depende de la inspiración personal, del heroísmo, de la experiencia, del conocimiento y de las habilidades del desarrollador. 2. Modelo en cascada Este método ordena rigurosamente las etapas del ciclo de vida de un proyecto de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. Para ser llevado a cabo requiere disciplina, planificación y administración. Además, la puesta en práctica debe ser pospuesta hasta que se entienda claramente el objetivo. Características y ventajas Es el más utilizado. Es una visión del proceso de desarrollo de software, como una sucesión de etapas que producen productos intermedios. Para que el proyecto tenga éxito deben desarrollarse todas las fases. Las fases continúan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final será de inferior calidad. Su planificación es sencilla. Sus fases son conocidas por los desarrolladores y los usuarios las comprenden fácilmente. Desventajas Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande. No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar. El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, lo que implica un reinicio del proyecto con altos costos. (Jiménez y Torres, 2009, https://es.calameo.com/read/000033896c61bca604ff6). Figura 1: Modelo de desarrollo en cascada Fuente: Elaboración propia. Este modelo solo debe usarse si se entienden a plenitud los requisitos. Aún se aplica como parte de proyectos grandes. Desarrollo evolutivo Este modelo se basa en los siguientes pasos: Desarrollar una implantación del sistema inicial. Recibir los comentarios del usuario. Refinar generando varias versiones. Repetir hasta que se desarrolle el sistema adecuado. Este modelo tiene como ventaja que permite obtener una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración. (“Proceso de Software y Ciclo de Vida”, s. f.). Figura 2: Bosquejo de la descripción Como ventajas podemos mencionar: La especificación puede desarrollarse de forma creciente. Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software. Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente. (“Proceso de Software y Ciclo de Vida”, s. f., https://www.fing.edu.uy/tecnoinf/maldonado/cursos/2015/rpyl/desarrolloSoftware.pdf). Como desventajas podemos indicar: Si el sistema necesita desarrollarse rápido, no es efectivo producir documentos que reflejen cada versión del sistema. Los cambios continuos pueden ser perjudiciales para la estructura del software, lo que hace costoso el mantenimiento. Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar. (“Proceso de Software y Ciclo de Vida”, s. f., https://www.fing.edu.uy/tecnoinf/maldonado/cursos/2015/rpyl/desarrolloSoftware.pdf). 3. Desarrollo basado en reutilización Este modelo está fuertemente orientado a la reutilización. Este modelo consta de 4 fases: ☰ Análisis de componentes se determina qué componentes pueden ser utilizados para el sistema en cuestión. Frecuentemente es necesario hacer ajustes para adecuarlos. ☰ Modificación de requisitos se adaptan (en lo posible) los requisitos para que concuerden con los componentes de la etapa anterior. Si no se pueden realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1). ☰ Diseño del sistema con reutilización se diseña o reutiliza el marco de trabajo para el sistema. Se deben tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco. ☰ Desarrollo e integración el software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada. (“Proceso de Software y Ciclo de Vida”, s. f., Las ventajas de este modelo son: Disminuye el costo y esfuerzo de desarrollo. Reduce el tiempo de entrega. Disminuye los riesgos durante el desarrollo. (“Proceso de Software y Ciclo de Vida”, s. Figura 3: Desarrollo basado en reutilización de componentes Desventajas de este modelo: Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla con las expectativas del cliente. Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema. (“Proceso de Software y Ciclo de Vida”, s. f., Desarrollo incremental Este método combina el modelo de cascada y el modelo evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y brinda oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. (“Proceso de Software y Ciclo de Vida”, s. f., Figura 4: Desarrollo incremental Ventajas de este modelo son: 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. Desventajas de este modelo: Cada incremento debe ser pequeño para limitar el riesgo (menos de 20 000 líneas). Cada incremento debe aumentar la funcionalidad. Es difícil establecer las correspondencias de los requisitos contra los incrementos. Es difícil detectar las unidades o servicios genéricos para todo el sistema. (Alarcon Pastor y Carrasco Palomino, s. f., https://www.monografias.com/trabajos108/modelos-delproceso-del-software/modelos-del-proceso-del-software.shtml). 4. Desarrollo en espiral El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa con los aspectos controlados y sistemáticos del modelo cascada. Este proporciona potencial para desarrollo rápido de versiones incrementales. Se divide en un número de actividades de marco de trabajo, llamadas "regiones de tareas". En general, existen entre tres y seis regiones de tareas (hay variantes del modelo). (Gutiérrez Díaz, s. f., Figura 5: Modelo espiral Un modelo evolutivo como el espiral es particularmente apto para el desarrollo de sistemas operativos (complejos). También puede ser usado en sistemas de alto riesgo o críticos (como navegadores y controladores aeronáuticos) y en todos aquellos en que sea necesaria una fuerte gestión del proyecto y sus riesgos, técnicos o de gestión. (Gutiérrez Díaz, s. f., Es un modelo evolutivo, pero en cada vuelta, antes de generar un nuevo prototipo, se evalúa el riesgo que se corre si continuamos con la siguiente iteración. En cada iteración debe acordar el cliente y el equipo de desarrollo que existe tiempo, recursos y decisión para seguir mejorando este proceso de desarrollo. Para el caso que se encuentre que los riesgos son demasiado grandes, puede entonces tomarse las decisiones adecuadas, como la suspensión del proyecto o la solicitud de más recursos. La idea es que antes de generar un prototipo, se evalúe la factibilidad y se analicen los riesgos. Si el resultado es positivo, entonces se genera el primer prototipo (que abarca solo una parte del sistema) y se continúa con las fases siguientes: simulación, comparación, validación de requerimientos. Esto es así, hasta que deje de ser prototipo y se convierta en el sistema completo, cuya puesta en operación, ya integrada y aceptada por el cliente, constituye la salida del proceso. Este modelo es iterativo, pues repite los pasos incrementándolos cada vez, al ir robusteciendo el prototipo en su funcionalidad. Desventajas importantes: Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo que es requisito para el éxito del proyecto. Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo. (Gutiérrez Díaz, s. f., Introducción Este punto del programa tiene como objetivo compartir las ideas de quien fue el líder de desarrollo del mítico Sistema 360 de IBM, Frederick Brooks Jr. (Brooks, F. 1995). Este punto de la unidad lleva el mismo nombre que el libro publicado por Brooks, en el que se sintetizan sus experiencias y frases que la mayoría de los profesionales de sistemas tomamos como verdades reveladas. El tema central es: “agregando recursos humanos a un proyecto retrasado lo hace demorarse aún más". Esta idea es conocida como la "Ley de Brooks" (Brooks, 1995, p. 231). De dicho libro tomo algunas frases que suelo usar en mi trabajo de CIO (Cheif Information Officer). 1. El segundo sistema El segundo sistema que un arquitecto diseña es el más peligroso de todos los que nunca hará, dado que tenderá a incorporar todos los agregados que él mismo generó, pero no pudo agregar (debido a inherentes restricciones de tiempo) a su primer sistema. Por tanto, cuando se embarca en un segundo sistema, un ingeniero debería tener presente su natural tendencia a sobrecargarlo. (Brooks, 1995, p. 233). Seguimiento Pregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero? Respuesta: ¡De a un día a la vez! Pequeñas demoras incrementales en variados frentes eventualmente se acumulan para producir un enorme retraso. Permanente atención al alcance de pequeñas metas individuales se requiere en todos los niveles del proyecto. (Brooks, 1995, p. 246). Documentos Cada gerente de proyecto debe crear un pequeño conjunto de documentos centrales que definan los objetivos del proyecto, cómo se deben alcanzar, quiénes deben alcanzarlos, cuándo deberán alcanzarse y cuánto van a costar. Estos documentos pueden revelar inconsistencias que de otro modo son difíciles de distinguir. (Brooks, 1995, p. 249). Integridad conceptual Para hacer que un sistema sea utilizable (amigable), debe tener integridad conceptual, lo que solo es posible separando la arquitectura de la implementación. Un único arquitecto jefe (o un pequeño número de arquitectos), actuando en representación del usuario, decide qué debe ir en el sistema y qué debe permanecer fuera. Una "súper" idea de alguien no debe ser incluida si no calza armoniosamente con el diseño general del sistema. De hecho, para asegurarse un sistema amigable, se debe brindar deliberadamente menos características de las que es capaz de tener. El punto es que si un sistema es demasiado complejo de usar, entonces muchas de sus características no se utilizarán solo porque nadie tendrá el tiempo de aprender a usarlas. (Brooks, 1995, p. 250). Historia Brooks (1995) fue director del desarrollo del famoso OS/360 de IBM y, a raíz de sus experiencias, éxitos y fracasos, escribió el libro mencionado, dentro del cual encontraremos frases como: - “Añadir recursos humanos a un proyecto con retraso provocará un retraso mayor”. - “En un proyecto la figura del arquitecto software es esencial”. - “Medir el progreso de un proyecto en función del tiempo que lleva desarrollándose es un error”. - “¿Cómo puede un proyecto acumular un retraso de un año...? Acumulando retrasos día a día”. La principal causa de los problemas en el desarrollo software está en la planificación y distribución de recursos. La idea de que horas y recursos humanos son intercambiables lleva a que si un proyecto está retrasado, la solución sea agregar más mano de obra, pero el factor humano y las horas no se pueden conmutar como en una multiplicación. El tiempo extra que se añade por cada persona va a parar a reuniones, planes, e-mails, negociaciones, discusiones, revisiones, coordinación de reuniones, actas, explicaciones, formación, etc. Y, por otro lado, existen tareas que simplemente no se pueden dividir y deben ser realizadas por la misma persona. Brooks (1995) compara el desarrollo software con las arenas movedizas que durante la prehistoria engullían animales gigantes que cuanto más luchaban por escapar más rápido se hundían. La única salida de este pozo de arenas movedizas es aplicar un proceso de ingeniería consciente y métodos probados en la gestión de proyectos. (Garzas, 2007, https://www.javiergarzas.com/2007/11/brooks-mythical-man-month.html). Introducción El modelo IDEAL (Modelo para la Mejora Continua de Procesos) es un modelo elaborado por el SEI para guiar el inicio, planificación e implementación de iniciativas de mejora para el proceso de software en las organizaciones. El modelo IDEAL provee un enfoque disciplinado de ingeniería para la mejora del proceso de software, focaliza en el gerenciamiento del programa de mejoras y establece los fundamentos para una estrategia de largo plazo. (Calidad Software, 2010, http://calidadsw2010.blogspot.com/2010/02/modeloideal.html). 1. Arquitectura del modelo El modelo IDEAL se compone de cinco fases: 1. Iniciar (Initiating). 2. Diagnosticar (Diagnosing). 3. Establecer (Establishing). 4. Ejecutar (Acting). 5. Aprender (Learning). Iniciar En esta fase se definen las bases del trabajo a realizar. Deben identificarse las necesidades de cambio en la organización. El éxito de este proceso dependerá de la claridad en la identificación y presentación de estas necesidades al cliente. Una vez consideradas las razones para iniciar el cambio, es necesario establecer las metas y objetivos del trabajo a realizar. Deben evaluarse la forma en que afectará al trabajo y los beneficios que se esperan obtener. Es crítico contar con el apoyo efectivo y el compromiso de la dirección desde que se inicia el programa. Finalmente, es necesario establecer la estructura organizativa que apoyará el programa de mejora. Es menester, documentar las responsabilidades y expectativas de cada grupo. Diagnosticar En esta fase debe obtenerse un entendimiento completo del trabajo a realizar. Es necesario definir el estado actual de la organización y el estado futuro. El resultado que se obtendrá son recomendaciones que sirven para definir las actividades siguientes del programa. Estas influyen en las decisiones que debe tomar la gerencia. Establecer En esta fase debemos elaborar un plan detallado en el que se identifiquen acciones específicas, entregables y responsabilidades para el programa de mejoras basado en los resultados del diagnóstico y en los objetivos que se quieren alcanzar. En esta fase también se definen las métricas que permitirán medir el progreso alcanzado. Además, se comienza a definir y capacitar a los grupos técnicos de trabajo que desarrollarán los Ejecutar En esta fase se implementan las acciones planificadas. Se trata de la fase que consume más tiempo y recursos. Se inicia con la definición de la solución que cubre los objetivos de la organización. Esta debe abarcar: Herramientas. Procesos. Habilidades. Asesorías. Información. El proceso se itera hasta obtener una solución satisfactoria que funcione, sin esperar que sea perfecta. Finalmente, la solución obtenida se comienza a implantar en la organización. Aprender Esta fase cierra el ciclo de mejora y su objetivo es garantizar que el próximo ciclo sea más efectivo. Durante esta se revisa toda la información recolectada en los pasos anteriores y se evalúan los logros y objetivos alcanzados para lograr implementar el cambio de manera más efectiva y eficiente en el futuro. Las lecciones aprendidas deben quedar documentadas. Conceptos de madurez de procesos “No puedo controlar lo que no puedo medir” (De Marco, 1978). “Si algo puede ser medido y expresado en números entonces se sabe algo acerca de ello” (Lord Kelvin Thompson, 1900). Me parece importante comenzar compartiendo la importancia que las mediciones tienen en la gestión, control y calidad del producto o servicio a desarrollar. Dentro de nuestra profesión, la ingeniería de software es la que se encarga de este tema. A título personal, la defino como: “la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad”. 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. De este modo, aborda todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información. Es aplicable a infinidad de áreas (negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.). Objetivos de la ingeniería de software En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas. La Informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software. Sus objetivos pueden ser resumidos en: mejorar la calidad de los productos de software. aumentar la productividad y trabajo de los ingenieros del software; facilitar el control del proceso de desarrollo de software; suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente; definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado. (“Ingeniería de Software”, s. f., 2. Madurez de procesos Es importante comenzar explicando un poco qué es el Software Engineering Institute (SEI) de Estados Unidos. Es un centro de investigación y desarrollo perteneciente a la Universidad de Carnegie Mellon, fundado y financiado por el departamento de Defensa de los Estados Unidos. Su meta es proporcionar a las organizaciones las pautas de actuación necesarias para obtener mejoras observables en su proceso del software, de manera que desarrollen productos sin defectos respetando requerimientos, fechas y costes. Esto se consigue mediante el cumplimiento de cuatro objetivos: Acelerar la introducción en las organizaciones de producción de software de las prácticas y técnicas de ingeniería del software más eficaces y eficientes, identificando, evaluando y mejorando aquellas que se consideren útiles. Mantener a largo plazo la competencia en ingeniería del software y en la gestión del cambio tecnológico. Habilitar a organizaciones privadas y públicas, trabajando con ellas, para que hagan mejoras en sus prácticas de ingeniería del software. Fomentar la adopción y uso continuo de estándares de excelencia en prácticas de ingeniería del software. (García Alonso e Hidalgo Marquez, El SEI tiene varias sedes y ofrece gran variedad de servicios a las organizaciones de desarrollo de software. En el MODELO DE MADUREZ de la CAPACIDAD del SOFTWARE del SEI (Software Capability Maturity Model, SW-CMM) se define un conjunto de áreas claves del proceso, que describen las funciones de ingeniería de software que deben llevarse a cabo para el desarrollo de las buenas prácticas, agrupadas en cinco niveles. Aplicando una serie de métricas, se determina la calidad de cada área clave, lo que logra una visión precisa del rigor, la eficacia y la eficiencia de la metodología de desarrollo de una organización productora de software. Cada una de esas áreas está organizada en secciones denominadas CARACTERÍSTICAS COMUNES: COMPROMISO DE REALIZACIÓN. CAPACIDAD PARA LLEVARLA A CABO. ACTIVIDADES QUE HAY QUE REALIZAR. MEDICIÓN Y ANÁLISIS. VERIFICACIÓN DE LA IMPLEMENTACIÓN. En cada característica común se especifican prácticas claves que son normas, procedimientos y actividades cuya realización lleva a la consecución de los objetivos del área. (García Alonso e Hidalgo Marquez, s. f., Asimismo, el SEI define indicadores claves que son aquellas prácticas esenciales o componentes de prácticas fundamentales que ofrecen una visión mayor de la consecución de los objetivos de un área imprescindible de proceso. Áreas claves/áreas de procesos Los niveles en los que se agrupan las áreas claves son inclusivos, es decir, para alcanzar uno, es necesario haber alcanzado y poder mantener todos los anteriores. Los niveles que maneja el SEI son los que se observan en la siguiente figura. Figura 1: Niveles de las áreas claves Fuente: Elaboración propia. Podemos sintetizar cada nivel del siguiente modo. INICIAL Se caracteriza por: una aproximación intuitiva al proceso de desarrollo de software, definir al éxito como dependiente del esfuerzo individual, la no definición de procesos metodológicos, la necesidad de realizar medidas que sirvan para estimar y planificar a futuro. Generalmente, podemos ver en este nivel que la organización no provee un ambiente estable para el desarrollo. Cualquier beneficio de una buena práctica de ingeniería de software se pierde por un planeamiento ineficiente. Ante una crisis se abandonan los procedimientos planeados. El éxito depende en gran medida de las habilidades del gerente y de su equipo. Al no tener bien definidas las actividades, el proceso de desarrollo se asemeja a una caja negra. Los requerimientos suelen proceder de manera descontrolada (García Alonso e Hidalgo Marquez, s. f.). REPETIBLE “La madurez metodológica de la organización permite estimar fiablemente el tamaño funcional o físico del sistema” (García Alonso e Hidalgo Marquez, s. f., http://aniei.org.mx/paginas/uam/CursoAI/CMMI_rep.pdf). También permite llevar el control de la gestión de recursos, costos y calendario. Se pueden repetir éxitos anteriores en proyectos de características similares. Las áreas claves de proceso definidas en este nivel, cuyo estado se puede conocer por diversas métricas, son: Gestión de requisitos. Planificación del proyecto de software. Seguimiento y control de proyectos. Gestión de la subcontratación de software. Aseguramiento de la calidad. Gestión de la configuración de software. En este nivel se implementan procesos efectivos que son: Definidos. Documentados. Utilizados. Entrenados. Medidos. Reforzados. Mejorados. Se cuenta con estándar de los proyectos de software y la organización asegura que serán respetados. El gerente de proyecto controla los costos, cronograma y funcionalidades; los problemas de cumplimiento de los compromisos son identificados a medida que surgen (García Alonso e Hidalgo Marquez, s. f.). DEFINIDO Se conoce la forma de construcción del sistema. El proceso de software de las actividades de gestión e ingeniería se documenta y se estandariza. Las actividades intermedias están bien definidas y, por lo tanto, se pueden examinar y medir. Es plausible detectar tempranamente posibles problemas y aplicar una adecuada gestión de riesgos. Las áreas claves definidas para este nivel son: desarrollo y mejora de los procesos de la organización, definición de los procesos de la organización, programa de formación, gestión integrada de software, ingeniería de producto de software, coordinación intergrupos, revisión conjunta. (García Alonso e Hidalgo Marquez, s. f., La capacidad del proceso de software de una organización en este nivel puede ser resumida como estándar y consistente, porque tanto la ingeniería de software como las actividades de administración son estables y repetibles. Esto se basa en el entendimiento común y organizacional de las actividades, roles y responsabilidades de un proceso de software definido (García Alonso e Hidalgo Marquez, s. f.). GESTIONADO Se suma la gestión a un proceso definido. Se usa realimentación desde las primeras actividades del proyecto para seleccionar prioridades en las actividades actuales y conocer cómo se emplean los recursos. Los efectos de los cambios en una actividad se pueden seguir en otras. Se recopilan medidas detalladas del proceso de software y de la calidad del producto. En definitiva, se evalúa la efectividad del proceso. Las áreas claves definidas en este nivel son dos: Gestión cuantitativa del proyecto. Gestión de calidad de software. (García Alonso e Hidalgo Marquez, s. f., http://aniei.org.mx/paginas/uam/CursoAI/CMMI_rep.pdf). En este nivel, la organización establece objetivos de calidad tanto para productos como para procesos de software. Una base de datos de procesos de software de la organización se usa para recolectar y analizar los datos disponibles de los procesos de software definidos de los proyectos. Estos procesos son implementados con medidas bien definidas y consistentes. A su vez, estas medidas establecen los fundamentos cuantitativos para evaluar los procesos y productos de software del proyecto. OPTIMIZADO Existe una mejora continua de los procesos. Las medidas de actividades se usan para mejorar el proceso, eliminando y añadiendo actividades y reorganizando su estructura como respuesta a los resultados de las medidas. Las áreas definidas para este nivel son: prevención de defectos, gestión de cambios tecnológicos, gestión de cambios en los procesos. (García Alonso e Hidalgo Marquez, En este nivel toda la organización se concentra en la mejora continua de procesos. La organización tiene los medios para identificar proactivamente las debilidades y fortalezas del proceso con el objetivo de prevenir defectos. Los datos, en la efectividad de los procesos de software, se usan para realizar análisis de costo/beneficio de nuevas tecnologías y de cambios propuestos a los procesos de software de la organización. Durante el desarrollo del proyecto se analizan defectos para determinar su causa. Se evalúan los procesos para prevenir la recurrencia en tipos de defectos conocidos y esto se transfiere a toda la organización. 3. Evaluaciones de CMMI Como vimos, el modelo de madurez de capacidad (CMM) surge como iniciativa del SEI y propone cinco niveles de madurez, considera que una organización alcanza el nivel cuando cumple todas las prácticas de ese nivel y de los niveles inferiores. Los cinco niveles son: Inicial. Repetible. Definido. Gestionado. Optimizado. Las áreas claves tienen una serie de prácticas o procesos claves, conocidas como áreas claves de procesos (KPA – Key Process Area). Cada área de proceso tiene definidas buenas prácticas que deben ser: Definidas. Provistas. Ejecutadas. Medidas. Verificadas. Esas características reciben el nombre de características comunes. CMM es un modelo que, si bien brinda el soporte para madurar el proceso, no asegura que el producto construido en los proyectos sea el correcto. A medida que el nivel aumenta, también lo hace la cantidad de documentación. CMM le brinda a las organizaciones de software una guía de cómo controlar sus procesos para el desarrollo y mantenimiento de software. Permite evolucionar hacia la cultura de ingeniería de software y excelencia en la administración. La forma de lograr estos objetivos es focalizar en un conjunto de actividades y trabajar fuertemente para que los logros sean continuos y duraderos en el proceso de software. La mejora continua de procesos está basada en realizar pequeños cambios evolutivos en lugar de una innovación revolucionaria. CMM brinda un marco, una forma de organizar pasos para lograr estos objetivos para lo cual define los cinco niveles de madurez. Estos niveles definen en forma ordenada esta evolución. Figura 2: Niveles de madurez Fuente: Elaboración propia. El CMM es un modelo descriptivo dado que describe los atributos esenciales que se esperan para caracterizar a una organización en un nivel de maduración en particular. Por lo tanto, es un modelo de tipo normativo en el sentido que detalla prácticas que caracterizan el tipo normal de comportamiento que se espera en los proyectos de gran escala en una organización. CMM no es prescriptivo, es decir, no dice a la organización cómo debe mejorar. El CMM nos dice en qué nivel de maduración se encuentra la organización. Con CMMI logramos: previsibilidad del presupuesto, mejoras en tiempo de entrega, incrementar productividad, incrementar el retorno de la inversión, decremento en el costo de la calidad. Según el SEI, la utilización de este modelo permite mejoras promedios de costo 34 %, entregas 50 %, productividad 61 %, calidad 48 %, satisfacción del cliente 14 % y retorno de la inversión 4:1. Bloque 1Referencias Paradigma Goal-Question-Metric Goal Question Metric (GQM), o Meta-Pregunta-Métrica, es un enfoque presentado por Víctor Basili, de la Universidad de Maryland (1984), quien afirma que una organización requiere mediciones para entender lo que está pasando y generar una base de conocimiento hacia el futuro. Debe ser definida utilizando un enfoque que parte de los objetivos de la organización para llegar al nivel de productos, de arriba hacia abajo. Una medición es eficaz cuando: 1. está centrada en objetivos específicos; 2. es aplicada a todos los productos de ciclo de vida, procesos y recursos; 3. es interpretada basada en el entendimiento del contexto organizacional, el medio ambiente y las metas existentes. Este enfoque parte de la suposición de que, para medir adecuadamente, una organización debe identificar las metas que desea, derivar objetivos a medir de manera cuantificable y establecer un marco que permita interpretar la información respecto a los objetivos. Modelo GQM o Meta-Pregunta-Métrica El modelo GQM es una estructura jerárquica que especifica, a partir de un objetivo, los efectos de la medición, el objetivo a medir, la cuestión que debe medirse y el punto de vista desde donde se toma la medida. Cada objetivo se descompone en varias preguntas para entender sus componentes y, finalmente, se obtienen métricas que dan respuesta a cada una de las preguntas. Todo este proceso se descompone en tres niveles: conceptual, operativo y cuantitativo. Nivel conceptual (Meta): se establece un objetivo para cada elemento de medición considerando el producto, proceso y los recursos desde diferentes puntos de vista. Nivel operativo (Pregunta): con base en las metas definidas se establece un conjunto de preguntas que permiten caracterizar la evaluación/logro de un objetivo específico. Nivel cuantitativo (Métrica): a cada pregunta se le asocian datos que permitan dar respuesta cuantitativa a los objetivos de manera objetiva o subjetiva. Un modelo GQM puede compartir las mismas preguntas y métricas para diferentes objetivos, aunque se obtienen valores diferentes según el punto de vista. El modelo obtenido requiere ser aplicado, y los datos, recolectados, interpretados y evaluados para determinar el cumplimiento de los objetivos iniciales. Con esto se completan todos los pasos para cubrir el enfoque de GQM. Algunas partes en el modelo CMMI se fundamentan en buena medida en las prácticas que establece el enfoque de GQM. Fundamentos de GQM La literatura abierta describe GQM en términos de un proceso de seis pasos donde los tres primeros se basan en usar los objetivos de negocio para conducir a la identificación de las verdaderas métricas, y los últimos tres pasos se basan en recopilar los datos de las medidas y la fabricación del uso eficaz de las métricas para mejorar la toma de decisión. Basili (1987, p. 8) describió el proceso de GQM en seis pasos: 1. Establecer los objetivos: Desarrollar un conjunto de objetivos corporativos y del proyecto de negocio que estén asociadas a un conjunto de medidas de productividad y calidad. 2. Generación de preguntas: Generar las preguntas (basadas en modelos) que definen objetivos de la manera más completa y cuantificable posible. 3. Especificación de medidas: Especificar las medidas necesarias a ser recolectadas para contestar las preguntas y seguir la evolución del proceso y producto con respecto a las metas. 4. 5. Preparar recolección de datos: Desarrollar mecanismos para la recolección de datos. Recolectar, validar y analizar los datos para la toma de decisiones: Recoger, validar y analizar los datos en tiempo real, para proporcionar la realimentación de proyectos en una acción correctiva. 6. Analizar los datos para el logro de los objetivos y el aprendizaje: Analizar los datos una vez alcanzada una meta para determinar el grado de conformidad y hacer las recomendaciones para mejoras futuras. Los primeros tres pasos del proceso de Basili son llamados, a menudo como fase de definición de GQM que provee la estructura de proceso para pasar al concepto de métricas significativas que, cuando se ponen en funcionamiento, cuantifican los objetivos y proveen datos significativos para la toma de decisiones. Los objetivos identifican lo que queremos lograr; las preguntas nos dicen si estamos satisfaciendo los objetivos, o nos ayudan a comprender cómo interpretarlos; y las métricas identifican las mediciones que son necesarias para responder a las preguntas y cuantificar el objetivo. Los restantes pasos son para recolectar y usar los resultados de las medidas para mejorar la toma de decisiones (Abdala, basado en Solingen y Berghout, 1999, p. 3). GQM comienza identificando los objetivos de la medida (nivel conceptual) que están alineadas con las metas del negocio. El equipo (encargados de proyecto, equipo del desarrollo, clientes, stakeholders) plantea las preguntas (nivel operacional) para clarificar y para refinar más los objetivos, y captura la variación de la comprensión de los objetivos que existen entre los stakeholders con respecto a sus conocimientos de la calidad y del ambiente que afecten el logro del objetivo. El equipo, entonces, identifica las métricas que proporcionarán respuestas a las preguntas (nivel cuantitativo). GQM se distingue de otros paradigmas por su estructura jerárquica en forma de árbol, usada para mantener las relaciones entre objetivos, preguntas y métricas. Una vez que se identifiquen las métricas apropiadas, los últimos tres pasos del proceso de GQM tratan cómo implementar el programa de las métricas de manera que asegure que el propósito siga siendo el logro del objetivo (Abdala, basado en Solingen y Berghout, 1999, p. 4) Es importante mencionar que es crítico planear mecanismos para la recolección de datos, y la organización y presentación de los datos de las métricas para maximizar su valor a los stakeholders, que interpretarán los resultados en lo referente a las metas. Estos son solamente procesados cuando ha ocurrido la definición de las métricas apropiadas. El impulso de definir métricas a través de objetivos utilizando el proceso GQM es lo que separa a GQM de otras metodologías de medida. Un principio primario de GQM, no evidente de manera usual en las ilustraciones del paradigma GQM, es que los stakeholders necesitan estar involucrados durante todo el proceso para que este sea satisfactorio. Basili y otros (Basili, 2005, Perfect, 1997) recomiendan para la mejor planificación de la implementación de GQM, que se aseguren que aquellos que poseen interés en alguna parte del proceso participen para que su conocimiento sea considerado, que entienden su posición (rol) en el proceso y que promueven su aceptación en el programa de medidas. Aquellos que implementen GQM deben usar una variedad de enfoques para asegurar el apropiado nivel de participación. La clave de esto es que el programa de medidas debe ser planeado e implementado desde dentro de la organización o proyecto, en vez de por fuentes externas. Sin embargo, los expertos están de acuerdo en que es útil tener un consultor (experto GQM) trabajando en el equipo u organización en las etapas iniciales para asegurar que los principios de GQM son implementados y pasar estos principios a la gente clave dentro de la organización (Abdala, basado en Solingen y Berghout, 1999, p. 4). Proceso GQM Paso 1 - Establecer las metas El proceso de GQM comienza con el establecimiento de objetivos de medidas, utilizando objetivos de negocios previamente definidos como guía. La esencia de este paso es: Hay dos tipos de objetivos: Objetivos de negocios Objetivos de medida Los objetivos del negocio guían la identificación de objetivos de medida (Abdala, basado en Solingen y Berghout, 1999, p. 5). Paso 2 - Generación de Preguntas El propósito del paso es clarificar y refinar el objetivo de las medidas moviéndonos desde un nivel conceptual a uno operacional planteando preguntas. Respondiendo estas preguntas uno debe ser capaz de concluir si el objetivo es alcanzado. Las preguntas ayudan a identificar interpretaciones del objetivo que pueden existir entre los stakeholders a sí mismos como restricciones impuestas por el entorno. Típicamente, a nivel de proyecto (o tal vez para un grupo de relacionados al proyecto), los objetivos de medida conceptual son identificados relacionando la calidad de producto, proceso, recursos o el entorno. El equipo de proyecto identifica preguntas que el equipo (individualmente o en colectivo) siente que deben ser hechas para capturar varias perspectivas para lograr el objetivo. Las preguntas deben contener todas las percepciones relacionadas al objetivo, dirigiéndose tanto a calidad como al entorno en el cual el objeto va a evolucionar. Este proceso es esencial para los stakeholders para lograr un entendimiento común y una interpretación del objetivo a un nivel apropiado de abstracción. En otras palabras, los gerentes del proyecto y los ingenieros de software proveen sus propias perspectivas del significado del objetivo en dicho entorno. Ellos hacen esto haciendo preguntas y respondiendo con sus métricas (Abdala, basado en Solingen y Berghout, 1999, p. 6). Paso 3 – Especificación de medidas El paso 3 es sobre la revisión de cómo deben ser respondidas las preguntas, moviéndonos desde un nivel cualitativo (o nivel operacional) a un nivel cuantitativo. Una vez que los objetivos son refinados en una lista de preguntas (GQM paso 2), se necesita definir métricas que provean toda información cuantitativa para responder las preguntas de manera satisfactoria. Los directamente involucrados con el objetivo de la meta deben estar directamente involucrados tanto en el paso de identificación de métricas como en el paso de identificación de preguntas. Paso 4 – Preparar la Recolección de datos Una vez que las métricas son identificadas, uno puede determinar qué datos son necesarios para determinar estas métricas y cómo estos serán recolectados. Las métricas proveen una visión acerca de cómo los datos necesitan ser organizados para que tengan sentido ante quien recibe dicha información (Abdala, basado en Solingen y Berghout, 1999, p. 7). Una cantidad significativa de planeamiento es necesaria para proveer procedimientos detallados para la recolección de datos que soporten las métricas identificadas. La mayoría de los proyectos satisface este detallado planeamiento preparando un “Plan de medidas” que incluye, por lo menos, los siguientes pasos: 1. Definición formal de medidas directas. 2. Descripción textual de medidas directas. 3. Todos los resultados posibles de las medidas directas. 4. La persona (rol) que recolecta cada medida directa. 5. Cuándo deben ser recolectadas las medidas directas. 6. Los medios que deben ser usados para recolectar las medidas (Abdala, basado en Solingen y Berghout, 1999, p. 7). Paso 5 - Recolectar, validar y analizar los datos para la toma de decisiones Este paso supone que la recolección de datos sigue los procedimientos predefinidos en el Plan de Medidas, esto es, un proceso continuo o periódico. La recolección de datos es inútil si uno no hace nada con ellos. Necesitamos focalizarnos en la preparación de los datos para un uso óptimo. Sin importar el medio de recolección, los datos deben ser validados antes de ser usados para análisis (Abdala, basado en Solingen y Berghout, 1999, p. 7). Paso 6 - Analizar los datos para el logro de los objetivos y el aprendizaje El último paso del proceso de GQM de Basili es observar los resultados de las medidas de modo post-mortem para evaluar los objetivos logrados y determinar las lecciones aprendidas, y que pueden ser valiosas para ser utilizadas en futuros proyectos. Cuando GQM es implementado como soporte a una organización de proceso de mejora continua, las experiencias y lecciones aprendidas de cada implementación son almacenadas en forma de políticas, procedimientos y mejores prácticas para soporte futuro a proyectos e iniciativas de mejoramiento para ayudar a la organización a lograr influencias más grandes en su programa medidas (Abdala, basado en Solingen y Berghout, 1999, p. 8). Prácticas Clave Existe un conjunto de prácticas clave que pasaremos a describir y que están basadas en el trabajo de Basili. Estas prácticas nos dicen qué hacer y qué no hacer al aplicar GQM en nuestra organización. Son una combinación de los principales factores de suceso identificados por los desarrolladores de organizaciones que ya aplican GQM y prácticas genéricas que son aplicables a la implementación de cualquier metodología de medición (Abdala, basado en Solingen y Berghout, 1999, p. 21). 1. Tener las personas adecuadas involucradas en el proceso de GQM GQM es muchas veces descrito como un enfoque top down, en el cual la alta gerencia debe proveer una guía y dirección para dejar disponible y claramente definidos los objetivos del proyecto y de la organización. Por otro lado, los desarrolladores (usualmente el equipo GQM trabajando en conjunto con el equipo del proyecto) definen los objetivos cuantitativos y, por último, las métricas. El equipo de GQM necesitará coordinar estas tareas para todos los proyectos de forma tal de asegurar consistencia de las métricas entre proyectos. Esta actividad puede ser conducida por la necesidad de la organización de consistencia entre métricas de diferentes proyectos, por lo tanto, cada fase de mediciones de GQM debe involucrar a las personas adecuadas para tal tarea. Los roles claves involucrados en GQM son: GQM Goal Owner, es la persona o personas cuyo punto de vista está establecido dentro del objetivo en cuestión y es responsable por la tarea de análisis. Puede ser un gerente de proyecto, encargado de testing, quality assurance o podría ser, incluso, un cliente. Measurement Manager, es la persona responsable de llevar adelante el programa de medición (desde una perspectiva operacional) y la ejecución del plan de mediciones. Este rol podría estar dentro o fuera del equipo del proyecto, y está explícitamente identificado tanto en el plan del proyecto como en el plan de mediciones. Data Provider, es cualquier persona que provee datos durante la etapa de recolección de los mismos. Estas personas necesitan estar involucradas para entender exactamente cómo los datos recolectados por ellos serán usados, y si están siendo usados como estaba planeado. GQM Expert, es la persona que desarrolla las tareas técnicas del programa de medición. Inicialmente puede ser un consultor, pero, luego de un período de entrenamiento, este rol típicamente se traslada a personas clave dentro del proyecto. GQM Team, dependiendo del tamaño de la organización y del alcance propuesto para la implementación de GQM, puede ser de valor la creación de un equipo de GQM que se especializa en el proceso de GQM. Este equipo generalmente está integrado por el grupo que provee Quality Assurance a los proyectos, pero está enfocado en la implementación de GQM, e inicialmente debería incluir un consultor externo de GQM. Este equipo realiza la coordinación con los gerentes de proyectos, así como, también, gran parte de la plantación y análisis iniciales (Abdala, basado en Solingen y Berghout, 1999, p. 21). 2. Fijar objetivos de mediciones explícitos y especificarlos explícitamente Los objetivos de mediciones no son objetivos organizacionales o de un proyecto en particular, sino que son objetivos que describen cómo medir el progreso orientando a los objetivos del proyecto y de la organización. Es importante para todos los miembros del equipo del proyecto entender y distinguir estos tres tipos de objetivos. Los objetivos de mediciones hacen que las actividades de mediciones estén alineadas con los objetivos del negocio (a nivel de proyecto y organizacional) y guían subsecuentemente todas las actividades del proceso GQM, por esto es que es importante focalizarse en ellos. Debemos preguntarnos si son los objetivos correctos, si fueron identificados todos los objetivos claves, si su significado es claro, etc. (Abdala, basado en Solingen y Berghout, 1999, p. 22). 3. No crear objetivos de mediciones falsos No se deben crear objetivos con el único fin de lograr correspondencia con las métricas que ya tenemos. Se deben elegir las métricas que son fáciles de recolectar sin realizar análisis previo para determinar si encajan en nuestro plan de mediciones. La perspectiva de “Podemos obtener estos datos, entonces ¿qué podemos hacer con ellos?” o “Veamos los datos que ya tenemos (así no debemos emplear esfuerzo extra) y determinar qué se puede descubrir a partir de ellos” es una forma de crear objetivos falsos. Esta perspectiva es evidente algunas veces en proyectos que no siguen un proceso disciplinado de desarrollo. 4. Adquirir modelos de calidad implícitos a partir de la gente involucrada Identificar nociones de calidad, que el equipo de desarrollo o clientes tienen en mente. 5. Considerar el contexto Se deben considerar los factores de variación de la calidad focalizándonos en el contexto de nuestro proyecto, por ejemplo, qué restricciones o limitaciones están presentes. 6. Derivar métricas apropiadas Para un objetivo y una pregunta dados, existen muchas métricas relevantes. La clave está en identificar aquellas métricas que claramente satisfacen la pregunta. Tener más métricas no es necesariamente mejor. La definición de la métrica, recolección de datos, análisis e interpretación representan trabajo extra, por tanto, no se deben crear más métricas de las que son realmente necesarias. En algunos casos, la misma métrica puede responder más de una pregunta. El mapeo entre preguntas y métricas no tiene que ser necesariamente uno a uno. 7. Permanecer focalizado en los objetivos cuando se analizan los datos GQM consiste en ver si los resultados de las mediciones responden las preguntas planteadas y cumplen con el objetivo fijado. Esto no quiere decir que se deban analizar los datos para ver qué comportamientos pueden ser descubiertos. En el plan de análisis, el proceso de análisis debe estar claramente especificado, incluyendo cómo los datos tienen que ser organizados y presentados para su interpretación. El equipo de GQM (o su contraparte en el proyecto) tiene la responsabilidad de determinar cómo agregar y presentar los datos para determinar si cumplen con el objetivo en cuestión, pero esta tarea es realizada teniendo la supervisión del equipo del proyecto. El plan inicial puede no ser perfecto, pero el equipo del proyecto será capaz de identificar problemas o fallas en el plan, ya que ellos son los que están involucrados en la interpretación de los datos. Este feedback es usado, entonces, para mejorar las tareas de análisis (Abdala, basado en Solingen y Berghout, 1999, p. 22-23). 8. Dejar que los datos sean interpretados por las personas involucradas No solo es necesario que aquellos que están involucrados en el desarrollo formen parte del equipo de definición, es necesario que ellos también estén involucrados en las tareas de interpretación de los resultados de las mediciones. 9. Integrar las actividades de mediciones con las actividades regulares del proyecto Llevar adelante un programa de mediciones es en realidad asumir un trabajo extra. La implementación de un programa de métricas es en sí mismo un proyecto que debe estar interconectado con el proyecto de software y las actividades propias del proceso. El gerente del proyecto debe incorporar los aspectos de planificación de GQM dentro del plan del proyecto. 10. No usar mediciones para otros fines Se debe evitar usar los resultados del programa de mediciones para otros fines no relacionados con el objetivo original, porque esto puede poner en riesgo el éxito del programa de mediciones. Esto es especialmente cierto cuando algunas medidas son incorrectamente usadas para medir la productividad a nivel individual dentro de los miembros del equipo, o como base para premiaciones individuales. 11. Asegurar el compromiso de la gerencia con el resultado de las mediciones Este es probablemente el factor de suceso de GQM más crítico, pero no es único para GQM, aplica a cualquier implementación de mediciones que usemos. Si la gerencia ignora el soporte que le dan los resultados de las mediciones, entonces las mediciones en sí son percibidas como un ejercicio fútil y, en este contexto, la mayoría de los programas de mediciones no sobrevive. 12. Establecer la infraestructura necesaria para soportar el programa de mediciones Dado que las mediciones implican un trabajo extra, es importante prevenir que este trabajo no entre en conflicto con el esfuerzo de desarrollo del producto en sí. Los planes de GQM pueden crecer fácilmente a grandes gráficas, un solo objetivo puede generar más de 100 métricas. Si no se cuenta con un soporte adecuado automatizado, mantener bajo control esta gran cantidad de metadatos puede ser una tarea complicada. 13. Asegurar que las mediciones son vistas como una herramienta y no como el objetivo final Las mediciones deben ayudar, y no obstruir el proceso de desarrollo. No debemos focalizarnos en las métricas y las mediciones a tal punto que perdamos de vista el proyecto en sí. Los líderes de proyecto deben esforzarse para que el equipo del proyecto se mantenga focalizado en los objetivos del proyecto, producto y mejora del proceso en vez del conjunto de mediciones recolectadas (Abdala, basado en Solingen y Berghout, 1999, p. 23). 14. Capacitarse en GQM antes de aplicarlo GQM parece sencillo y puede ser una tentación intentar hacerlo uno mismo, pero, más allá de la superficie, es un proceso sofisticado que suele ser muy diferente de la forma de pensar y modelar de muchos de los que lo practican. Tener un entrenamiento inicial es importante para poder comprender y transformar los pensamientos del equipo y sus preocupaciones dentro de la jerarquía de GQM. (Abdala, basado en Solingen y Berghout, 1999, p. 24). Introducción Hemos identificado que una métrica es el proceso por el cual los números o símbolos son asignados a atributos de entidades en el mundo real, de modo de poder describirlos de acuerdo con reglas claramente definidas. Además, debemos poder identificar los objetos del dominio y especificar su comportamiento. Ahora bien, al hacer una medición debemos previamente: Definir el objetivo Definir la escala Establecer una relación entre dicha escala y los atributos de los objetos establecidos Desde nuestra visión en el desarrollo de software, las métricas pueden ser focalizadas como referentes a los procesos y al proyecto propiamente dicho. Los gerentes son una pieza clave en el proceso de recolección de métricas. Las métricas en software nos permiten: Caracterizar un esfuerzo Evaluar y determinar el grado de avance Predecir Poder mejorar Podemos decir que la medición es una herramienta administrativa. La medida captura una característica individual. La medición permite capturar dicha característica. La métrica permite relacionar y comparar mediciones. Las métricas son el fundamento de los indicadores. ¿Y cómo podemos definir a un indicador? La definición que propongo es “una métrica o combinación de métricas que proporciona una visión profunda del proceso del software, del proyecto de software o del producto en sí” (Salazar y Salazar, s.f., p. 1). Debemos considerar como objetivos del proyecto, el hecho de establecer: Figura 1: Objetivos del proyecto Fuente: elaboración propia. Los indicadores del proyecto permiten al gestor: Evaluar el estado del proyecto en curso. Seguir la pista de riesgos potenciales. Detectar áreas problemáticas antes de que se conviertan en críticas. Ajustar el flujo y las tareas de trabajo. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de los trabajos de sistemas. (Aguilar y Lalangui, 2008, https://bit.ly/3klbbUl). Los indicadores del proceso permiten: Al gestor, evaluar lo que funciona y lo que no. A la organización, tener una visión profunda de la eficacia de un proceso ya existente. Técnicamente, no existe gran diferencia entre las métricas del proyecto y las del proceso. Podemos concebir las métricas del proceso como recopilaciones de métricas del proyecto. Figura 2: Métricas del proceso Fuente: elaboración propia. Si la gestión se basa en el personal, problema y proceso, “¿por qué nos centramos en mejorar el proceso? Porque el proceso es un factor clave y controlable para mejorar la calidad del software y el rendimiento de la organización” (Salazar y Salazar, s.f., p. 2). El proyecto es afectado por distintos factores. En el siguiente gráfico indicamos los más importantes: Figura 3: El proceso y los diversos factores de un producto Fuente: Gestión de Proyectos de Software. Ingeniería de Software, 21 de septiembre de 2014, https://bit.ly/3nPx00l Como ya hemos comentado, las métricas del proceso se extraen de las métricas del proyecto. En cualquier caso, hay métricas: Privadas Públicas Las métricas del proceso pueden ser muy útiles, pero hay que saber interpretarlas. Unas normas básicas de interpretación son: Utilizar el sentido común al interpretar los datos. Proporcionar una realimentación regular a particulares y equipos. No utilizar métricas para evaluar a particulares. Establecer métricas claras y objetivos para alcanzarlas. No utilizar métricas para amenazar a particulares o equipos. Si una métrica identifica un área problemática, no se debería considerar como negativa. Hay que interpretar todas las métricas en su conjunto, y no primar una en particular. La utilización de métricas e indicadores fiables da lugar a una mejora estadística del proceso del software. Esta mejora se basa en un análisis de fallos que identifica la causa y origen de errores y defectos para varios proyectos de software. Error: fallo en un producto generado durante el proceso de IS que es detectado antes de la entrega al cliente. Defecto: fallo detectado después de la entrega al cliente. El análisis de fallos funciona del siguiente modo: 1. Se categorizan por origen todos los errores y defectos de varios proyectos. 2. Se registra el coste de corregir cada error o defecto. 3. El número de errores y de defectos de cada categoría se cuenta y se ordena decrecientemente. 4. Se computa el coste global de errores y defectos de cada categoría. 5. Los datos resultantes se analizan para detectar las categorías que producen el coste más alto para la organización. 6. Se desarrollan planes para modificar el proceso con el intento de eliminar (o reducir la frecuencia de apariciones de) la clase de errores y defectos que sean más costosos. (Díaz Silva, 22 de abril de 2014, pp. 10-12) Aplicando los puntos 1 y 2, obtenemos que: Figura 4: Causas de defectos y su origen Fuente: Gestión de Proyectos de Software. Ingeniería de Software, 21 de septiembre de 2014, Las métricas del proceso son estratégicas: determinan el curso del proceso de producción de software; las métricas del proyecto son tácticas: determinan el curso del proyecto actual. La primera aplicación de las métricas del proyecto ocurre durante la estimación (datos históricos). A medida que avanza el proyecto, las medidas del esfuerzo y el tiempo se comparan con la planificación. El gestor utiliza estos datos para supervisar y controlar el avance. Además, para medidas en las técnicas de diseño y programación existen métricas técnicas. Utilización fundamental de las métricas del proyecto: Minimizar la planificación de desarrollo guiando los ajustes necesarios que eviten retrasos y mitiguen problemas y riesgos potenciales. Evaluar la calidad de los productos en el momento actual modificando el enfoque técnico para mejorar la calidad, si es necesario. Como el contexto de uso identifica al tipo de métrica, nos referiremos a las métricas del producto y del proceso como métricas del software. 1. Métricas de productividad orientadas al tamaño Se obtienen considerando las medidas de productividad y normalizándolas por el tamaño del código, es decir, las Líneas De Código (LDC). Se basan en la utilización de registros sencillos para las medidas más relevantes para nuestro proyecto. Otra medida es el esfuerzo, es decir, la multiplicación de: esfuerzo = cantidad de personas * cantidad de tiempo Es una medida que indica que da igual tener a dos personas trabajando tres meses que a tres personas trabajando dos meses. e = 3(p) * 2(m) = 6(pm) e = 2(p) * 3(m) = 6(pm) ¿Cómo calcular las LDC? Debe contabilizarse cada línea nueva o modificada. Las líneas para la instrumentación de código (e.g. para las pruebas) no deben incluirse en el tamaño total, salvo que tengan un carácter definitivo. Las líneas de código de programas de prueba tan solo se contabilizan si se desarrollan con el nivel de calidad exigido al entregar el producto. Se contabilizan las líneas correspondientes a las llamadas al sistema operativo. No se consideran los comentarios. No se contabiliza el pseudocódigo. Cada ocurrencia de macro o include se considera como una línea. El código generado por macros o includes solo se considera una vez. Las LDC no están comúnmente aceptadas Ventajas: - Fáciles de calcular. - Existen muchos modelos de estimación basados en LDC. - Existen muchas medidas de LDC. Inconvenientes: - Dependientes de los lenguajes de programación. - Perjudican a los programas cortos pero bien diseñados. - Difícil uso en estimación debido al nivel de detalle. Métricas de productividad orientadas a la función Se obtienen considerando las medidas de productividad y normalizándolas por una medida de la funcionalidad entregada por la aplicación. Como la funcionalidad no se puede medir directamente, se debe derivar indirectamente de otras medidas directas. Punto de Función La funcionalidad de un programa viene representada por el Punto de Función (PF), que se deriva de las mediciones del software. Se calcula con base en la expresión: PF = cuenta-total * (0,65 + 0,01* ∑i:1-14 F1) En la que tenemos parámetros de medición: Entradas de usuario. Entradas de usuario que proporcionan diferentes datos orientados a la aplicación. Salidas de usuario. Salidas que proporcionan al usuario información orientada a la aplicación (por ej., informes, pantallas, mensajes de error, etc.). Peticiones de usuario. Entradas interactivas que producen la generación de alguna respuesta del software inmediata en forma de salida interactiva. Archivos. Se cuenta cada archivo maestro lógico, es decir, cada grupo de datos que puede ser una parte de una gran base de datos o sistema de archivos. Interfaces externas. Interfaces legibles por la máquina que se utilizan para transmitir información a otro sistema (por ej., cinta, red, etc.). Los valores de ajuste complejidad (Fi) Se calculan respondiendo a las siguientes preguntas en una escala desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial): 1. ¿Requiere el sistema copias de seguridad y de recuperación fiables? 2. ¿Requiere comunicación de datos? 3. ¿Existen funciones de procesamiento distribuido? 4. ¿Es crítico el rendimiento? 5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado? 6. ¿Se requiere entrada de datos interactiva? 7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? 8. ¿Se actualizan los archivos maestros de forma interactiva? 9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 10. ¿Es complejo el procesamiento interno? 11. ¿Se ha diseñado el código para ser reutilizable? 12. ¿Están incluidas en el diseño la conversión e instalación? 13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? 14. ¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el usuario? (Díaz Silva, 22 de abril de 2014, p. 18). Una vez calculado el valor PF, las métricas son análogas a las orientadas al tamaño. Punto de Característica La medida de Punto de Característica (PC) es una ampliación de la medida de PF. La medida de PF tiene su origen en aplicaciones de gestión. Prima, por tanto, la dimensión de datos obviando cuestiones de complejidad funcional. Esto hace a la medida de PF inadecuada para sistemas de ingeniería. Solución: ampliar los parámetros de medición para tener en cuenta a los algoritmos. El PC es una ampliación de la medida de PF aplicable a sistemas con un fuerte componente funcional (por ej., tiempo real). Consiste en ampliar la tabla de cuenta-total de PF con el parámetro de medición de algoritmos. Un algoritmo es un problema de cálculo limitado que se incluye dentro de un programa. El factor de ponderación depende de la importancia que se quiera dar a este parámetro (por ej., 10, 15, 20). Los PC tampoco están comúnmente aceptados. Ventajas Independientes del lenguaje de programación. Permiten hacer estimaciones más fácilmente. Inconvenientes Basadas en cálculos subjetivos. Parámetros y factores no evidentes. No tienen un significado físico directo. Factores que inciden en las métricas Los gestores no deben utilizar directamente las métricas de productividad para evaluar a la gente, la razón reside en que no todos los proyectos son iguales. Hay una serie de factores que afectan la productividad: Factores humanos: Tamaño y experiencia de la organización de desarrollo. Factores del problema: La complejidad del problema que se debe resolver y el número de cambios en las restricciones o los requisitos de diseño. Factores del proceso: Técnicas de análisis y diseño que utilizan, lenguajes y herramientas CASE, y técnicas de revisión. Factores del producto: Fiabilidad y rendimiento del sistema. Factores del recurso: Disponibilidad de herramientas CASE y recursos de hardware y software. Figura 5: Métricas de la calidad Fuente: elaboración propia. Medida de la calidad Vamos a ver una serie de factores que afectan a la calidad y cómo medirlos tomando como base la metodología indicada por Pressman (2010, p. 587). Corrección: Grado en que el software lleva a cabo su función requerida. Cant defectos/cant KLDC Defecto: Es una falta verificada de conformidad con los requisitos. Facilidad de mantenimiento: Facilidad con la que se puede corregir un programa si se encuentra un error. Se puede adaptar a su entorno si cambia, o mejorar si el cliente desea un cambio de requisitos. Tiempo Medio de Cambio (TMC): Tiempo que se tarda en analizar la petición de cambio en diseñar una modificación adecuada, en implementar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. Cuanto más fácil sea de mantener un programa, más bajo tendrá su TMC. Una métrica orientada al coste son los desperdicios: coste en corregir defectos encontrados después de haber distribuido el software a los usuarios finales. Integridad: Mide la habilidad de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad. El ataque puede producirse en cualquier componente del software (programas, datos o documentos). Para medir la integridad debemos medir la seguridad y la amenaza, que se estiman o deducen de la evidencia empírica. Amenaza: Probabilidad de que se produzca un ataque de tipo determinado en un momento determinado. Seguridad: Probabilidad de que se pueda repeler el ataque de un tipo determinado en un momento determinado. integridad = ∑ataques[1-amenaza*(1-seguridad)] Facilidad de uso: Intento por medir lo amigable que puede ser un programa con el usuario. La facilidad de uso se puede medir en función de cuatro características: Habilidad intelectual y/o física para aprender el sistema. Tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema. Aumento neto de la productividad (sobre el sistema que reemplaza), medida cuando alguien utiliza el sistema de manera moderadamente eficiente. Valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema. Eficacia de la Eliminación de Defectos (EED) “Es una medida de la habilidad de filtrar de las actividades de la garantía de calidad y de control, al aplicarse a todas las actividades del marco de trabajo del proceso” (Aguilar y Lalangui, 2008, p. 23). Considerada globalmente para el proyecto: EED = E / (E + D) En el que E: número de errores encontrados antes de la entrega. D: número de defectos. Objetivo: EED = 1 Si E es muy grande, EED estará próxima a 1. Cuantos más errores encontremos antes de la entrega, mejor funcionarán las técnicas de garantía de calidad. La EED también puede utilizarse para medir la habilidad de un equipo para encontrar errores: EEDi = Ei / (Ei + Ei+1) En el que Ei: errores detectados en la actividad i Ei+1: errores detectados en la actividad i+1 que no se detectaron y provienen de la actividad i Objetivo EEDi = 1 Fiabilidad del software Fiabilidad del software: ausencia de fallos. Probabilidad de Fallo Bajo Demanda (PFBD): mide la probabilidad de que un sistema falle cuando se le hace una petición de servicio. Frecuencia de fallo: mide la frecuencia de aparición de fallo de funcionamiento Ejemplo: Una FDF de 0,006 indica que se producen 3 fallos cada 500 unidades de tiempo. Tiempo medio de fallo (TMF): mide el tiempo transcurrido entre fallos del sistema. Ejemplo: Un TMF de 166,66 indica en 500 unidades de tiempo transcurridas se han producido 3 fallos. Si no hay cambios, TMF = 1/FDF Disponibilidad: mide la disponibilidad de un sistema para ser usado. Ejemplo: Una disponibilidad de 0,95 indica que el sistema está disponible 950 unidades de cada 1000 unidades de tiempo. Línea Base de Métricas Línea base de métricas: es una recopilación de métricas que sirve para establecer indicadores. Para ser útil debe tener los siguientes atributos: Los datos deben ser razonablemente exactos. Los datos deben extraerse del mayor número de proyectos que sea posible. Las medidas deben ser consistentes. Las aplicaciones deben ser semejantes para hacer la estimación. Bloque 1ReferenciasRevisión Gestión cuantitativa Resulta clave empezar este punto del programa trayendo una presentación del Departamento de Defensa de los Estados Unidos sobre proyectos de software, que plantea que luego de dos décadas de no cumplir con las promesas sobre aumento de la productividad y calidad con el uso de las nuevas tecnologías y metodologías, las industrias y las organizaciones gubernamentales se han dado cuenta de que el problema fundamental de los proyectos de software es la incapacidad de gestionar el proceso, en especial la pobre gestión de riesgos. Esta presentación del resultado real del producto, que se entrega en un proyecto, hace replantear muchas de las ideas presentadas por la industria, pero también confirma la necesidad de avanzar en un proceso claro de mejoras y que pueda llevarse a cabo. En esta línea, es crítica la importancia de la gestión de proyectos. A fin de poder avanzar en este objetivo, planteamos dos grandes líneas de acción: Tener un medio donde almacenar la información de gestión. Obtener de manera estadística dicha información. Una vez establecido el medio en el que iremos guardando las mediciones, es necesario aplicar el análisis estadístico sobre esa información de procesos/productos almacenada. Llegar al nivel 3 nos obliga a tener ese almacenamiento de activos de proceso bien estructurado e implementado. Las organizaciones que hicieron el esfuerzo para implementarlo lo evalúan como una de las claves para mejorar el nivel de madurez de los procesos y la gestión. Tiene como objetivos poder obtener, definir y compartir todos los procesos de la organización. La primera meta contribuye a gestionar cuantitativamente el proyecto eliminando las desviaciones por variaciones excepcionales en el comportamiento del proceso. Para ello requiere de la información del análisis y gestión estadística del proceso que suministra la segunda meta del área de proceso. (Pérez Escobar, 12 de agosto de 2010, https://bit.ly/3zorCn1). El propósito de esta área de proceso es administrar el proyecto de manera tal de cumplir con sus objetivos de calidad y desempeño. Los objetivos y prácticas específicas del área para una gestión cuantitativa del proyecto son los siguientes: Tabla 1: Gestión cuantitativa y estadística del proyecto Objetivos Administrar el proyecto cuantitativamente El proyecto es administrado, en términos cuantitativos, usando objetivos de calidad y desempeño. Prácticas Establecer y mantener los objetivos de calidad y de rendimiento del proceso en el proyecto. Ensamblar el proceso definido para el Proyecto. Seleccionar los subprocesos que componen el proceso definido del proyecto con base en los datos históricos de estabilidad y de capacidad. Monitorizar el proyecto para determinar si los objetivos de calidad y rendimiento del proceso en el proyecto serán satisfechos, e identificar la acción correctiva según sea apropiado. Administrar estadísticamente el desempeño de los subprocesos El desempeño de los subprocesos seleccionados, pertenecientes al proceso definido del proyecto, es administrado en términos estadísticos. Seleccionar las medidas y las técnicas analíticas a utilizar en la gestión estadística de los subprocesos seleccionados. Establecer y mantener una comprensión de la variación del subproceso seleccionado usando las medidas y técnicas analíticas seleccionadas. Monitorizar el rendimiento de los subprocesos seleccionados para determinar su capacidad para satisfacer sus objetivos de calidad y de rendimiento de proceso, e identificar la acción correctiva según sea necesario. Registrar los datos de gestión estadística y de calidad en el repositorio de medición de la organización. Fuente: elaboración propia basada en Pérez Escobar, 12 de agosto de 2010, https://bit.ly/3zorCn1 Las herramientas que pueden usarse para implementar estas prácticas son herramientas estadísticas de procesos, que tienen el objetivo de permitirnos evaluar el comportamiento de los subprocesos del proyecto (naturaleza de las variaciones, estabilidad, etc.). Revisión de módulo ☰ Métricas Podemos decir que una métrica es cualquier medida o conjunto de ellas destinada a conocer o estimar el tamaño u otra característica de algo que se quiere hacer, controlar o manejar. Por tal motivo, tiene diferentes funciones y nos permite tomar control de una operación o producto. También genera la posibilidad de mejorar o asegurar que su funcionamiento se comporte dentro de sus especificaciones. ☰ Paradigma Goal-Question-Metric Goal Question Metric (GQM), o Meta-Pregunta-Métrica, es un enfoque presentado por Víctor Basili, de la Universidad de Maryland (1984), quien afirma que una organización requiere mediciones para entender lo que está pasando y generar una base de conocimiento hacia el futuro. ☰ Planes de métricas Una métrica es el proceso por el cual los números o símbolos son asignados a atributos de entidades en el mundo real, de modo de poder describirlos de acuerdo con reglas claramente definidas. Ahora bien, al hacer una medición debemos previamente: definir el objetivo, definir la escala y establecer una relación entre dicha escala y los atributos de los objetos establecidos. Desde nuestra visión en el desarrollo de software, las métricas pueden ser focalizadas como referentes a los procesos y al proyecto propiamente dicho ☰ Gestión cuantitativa En esta lectura abordamos la importancia de la gestión de proyectos, a fin de avanzar en procesos de mejoras, que sean claros y puedan llevarse a cabo de forma efectiva. A fin de poder avanzar en este plano es que se plantean dos grandes líneas de acción: tener un medio donde almacenar la información de gestión y obtener de manera estadística dicha información. Referencias Basili, V. (1987). The goal question metric approach. USA, Institute for Advanced Computer Studies. 1. Herramientas de Calidad La calidad es el conjunto de propiedades inherentes a una entidad que permiten juzgar su valor. Está cuantificada por el valor que se le da al conjunto de propiedades seleccionadas. De esta manera, la calidad es subjetiva y circunstancial. James Bach (1997). ¿Qué factores debemos tener en cuenta? Lo importante es la calidad de la información, mucho más que la cantidad. Dejar en claro cómo obtener y usar los datos reduce las tensiones en el grupo de trabajo. No tener datos es problemático, pero tener datos equivocados es catastrófico. Debe haber consistencia en la obtención de datos. El orden de identificación de cada documento de recolección y síntesis de datos es un factor de éxito. Simplificar todo lo posible, no pensar en complicados caminos o herramientas. Los gráficos deben ser sencillos y fáciles de entender para quienes están destinados. Usar el sentido común, no siempre el mismo gráfico indica lo mismo en situaciones diferentes. Siempre priorizar la obtención de muestras tan aleatorias como sea posible. Las siete herramientas de calidad Al referirnos a las siete herramientas de calidad hablamos de un concepto que no es nuevo pero, si bien las conocemos hace muchos años, siguen siendo, en su conjunto, las más utilizadas. ¿Cuáles son las siete herramientas? Checklist u Hoja de Verificación Diagrama de Pareto o Distribución A-B-C Histograma Run Chart o Gráfico de Corrida Scattergram o Diagrama de Causa/Efecto Diagrama de Control Diagrama de Ishikawa Los objetivos de las 7 herramientas de calidad son Poder tener los datos organizados Permitir un proceso de planificación mucho más efectivo Soportar el proceso de decisión Veremos algunos detalles de estas herramientas: ☰ Checklist u hoja de verificación La hoja de verificación es una forma que se usa para registrar la información en el momento en que se está recabando. Esta forma puede consistir en una tabla o gráfico en el que se registren, analicen y presenten resultados de una manera sencilla y directa. Proporciona un medio para registrar de manera eficiente los datos que servirán de base para subsecuentes análisis. Proporciona registros históricos que ayudan a percibir los cambios en el tiempo. Facilita el inicio del pensamiento estadístico. Ayuda a traducir las opiniones en hechos y datos. Se puede usar para confirmar las normas establecidas. ☰ Diagrama de Pareto La idea que presentó Pareto, que es la base de su herramienta, es que hay muchos problemas sin importancia frente a unos pocos muy importantes. Es decir, hay pocos vitales y muchos triviales. El Diagrama de Pareto nos muestra, en forma de gráfico de barras, las causas de los problemas. Los presenta ordenados por orden de importancia y frecuencia (porcentaje) de aparición, costo o actuación. El Diagrama de Pareto permite, además, comparar la frecuencia, costo y actuación de varias categorías de un problema. Las ventajas de utilizar Pareto pueden ser descritas del siguiente modo: Se focaliza en los pocos problemas vitales Prioriza la importancia de cada una de las áreas Es el primer paso para la realización de mejoras Podemos aplicarlo en todas las situaciones en las que se pretende efectuar una mejora, ya sea: la calidad del producto/servicio, costos, entrega, seguridad, etc. Este tipo de gráfica ayuda a organizar datos de forma que estos queden en orden descendente, de izquierda a derecha y separados por barras. Permite, pues, asignar un orden de prioridades. Mediante la gráfica colocamos los "pocos que son vitales" a la izquierda y los "muchos triviales" a la derecha. El diagrama facilita el estudio de las fallas en las industrias o empresas comerciales, así como fenómenos sociales o naturales psicosomáticos. Hay que tener en cuenta que tanto la distribución de los efectos como sus posibles causas no es un proceso lineal, sino que el 20% de las causas totales hace que se origine el 80% de los efectos. El principal uso que tiene la elaboración de este tipo de diagrama es para poder establecer un orden de prioridades en la toma de decisiones dentro de una organización. Evaluar todas las fallas, saber si se pueden resolver o, mejor, evitarlas. ☰ Histograma En términos estadísticos, un histograma es una representación gráfica de una variable. El tipo de gráfico utilizado es el de barras, en el que la superficie de cada barra es proporcional a la frecuencia de los valores representados, ya sea en forma diferencial o acumulada. Su principal característica es que permiten obtener una "primera vista" general o panorama de la distribución del proceso a estudiar, o la muestra, respecto a una característica, cuantitativa y continua, y que es de interés para el observador. De esta manera, ofrece una visión en grupo que permite observar una preferencia o tendencia por parte de la muestra o población por ubicarse hacia una determinada región de valores dentro del espectro de valores posibles (sean infinitos o no) que pueda adquirir la característica. De este modo, podemos evidenciar comportamientos, observar el grado de homogeneidad, acuerdo o concisión entre los valores de todas las partes que componen la población o la muestra o, en contraposición, poder observar el grado de variabilidad y, por ende, la dispersión de todos los valores que toman las partes. También es posible no evidenciar ninguna tendencia y obtener que cada miembro de la población toma por su lado y adquiere un valor de la característica aleatoriamente sin mos

calidad de software.pdf

Document Details

Tags

Related

Full Transcript

Upgrade to continue