Unidad 2: Gestión de calidad.

Calidad del Software

La calidad del software es un concepto complejo que no es directamente comparable con la calidad de la manufactura de productos. En la manufacturación, la noción de calidad viene dada por la similitud entre el producto desarrollado y su especificación. En un mundo ideal, esta definición debería aplicarse a todos los productos, pero, para sistemas de software, existen estos problemas:

1.- La especificación se orienta hacia las características del producto que el consumidor quiere. Sin embargo, la organización desarrolladora también tiene requerimientos (como los de mantenimiento) que no se incluyen en la especificación.

2.- No se sabe cómo especificar ciertas características de calidad (por ejemplo, mantenimiento) de una forma no ambigua.

3.- Es muy difícil redactar especificaciones concretas de software. Por lo tanto, aunque un producto se ajuste a su especificación, los usuarios no lo consideran un producto de alta calidad debido a que no responde a sus expectativas.

Se deben reconocer estos problemas con la especificación del software y se tienen que diseñar procedimientos de calidad que no se basen en una especificación perfecta. En concreto, atributos del software como mantenibilidad, seguridad o eficiencia no pueden ser especificados explícita mente. Sin embargo, tienen un efecto importante en cómo es percibida la calidad del sistema.

2.1 La gestión de proyectos usando un marco de calidad

La gestión de la calidad provee una comprobación independiente de los procesos de desarrollo software. Los procesos de gestión de la calidad comprueban las entregas del proyecto para asegurarse que concuerdan con los estándares y metas organizacionales. El equipo de garantía de calidad debe ser independiente del equipo de desarrollo para que puedan tener una visión objetiva del software. Ellos transmitirán los problemas y las dificultades al gestor principal de la organización.

Un equipo independiente de calidad garantiza que los objetivos organizacionales y la calidad no sean comprometidos por consideraciones de presupuesto o agenda. Una suposición subyacente de la gestión de calidad es que la calidad del proceso de desarrollo afecta directamente a la calidad de los productos derivados. La siguiente figura muestra una aproximación basada en proceso para conseguir la calidad del producto

Hay un vínculo claro entre la calidad del proceso y del producto en producción debido a que el proceso es relativamente fácil de estandarizar y monitorizar. El software no se manufactura, sino que se diseña. El desarrollo de software es un proceso más creativo que mecánico. La calidad del producto, también se ve afectada por factores externos, como la novedad de una aplicación o la presión comercial para sacar un producto rápidamente..

La gestión de la calidad del proceso implica:

1.- Definir estándares de proceso.

2.- Supervisar el proceso de desarrollo para asegurar que se sigan los estándares.

3.- Hacer informes del proceso para el gestor del proyecto y para el comprador del software.

2.2 Estándares y Métricas de calidad en la ingeniería de SW

Un problema de la garantía de la calidad basada en el proceso es que el equipo de garantía de la calidad (QA) insista en unos estándares de proceso independientemente del tipo de software a desarrollar. El gestor principal debe intervenir para asegurar que el proceso de calidad ayude al desarrollo del producto en lugar de impedirlo.

Podemos definir dos tipos de estándares como parte del proceso de garantía de calidad:

1.- Estándares de producto. Se aplican sobre el producto software que se comienza a desarrollar. Incluyen estándares de documentación, como cabecera de comentarios estándar para definición de clases, y estándares de codificación.

2.- Estándares de proceso. Definen los procesos que deben seguirse durante el desarrollo del software. Pueden incluir definiciones de procesos de especificación, diseño y validación, así como una descripción de los documentos que deben escribirse en el curso de estos procesos. Existe una relación muy cercana entre los estándares de producto y los estándares de proceso. Los estándares de producto se aplican a las salidas del proceso software y. en muchos casos, los estándares de proceso incluyen actividades de proceso específicas que garantizan que se sigan los estándares de producto

2.3.1 CMM

CMM es una aplicación del sentido común para el gerenciamiento de procesos y conceptos de mejora de la calidad del desarrollo y mantenimiento del software, es además una guía desarrollada por y para la comunidad profesional del software.Un modelo para la mejora organizacional.

Una estructura confiable y consistente para evaluar y mejorar las capacidades de una organización.

¿Porque surge CMM?

Crisis del software de principios de los 80, debido a una falta de eficiencia en los procesos de desarrollo de programas. 

¿Qué puedo hacer con CMM?

Ayudar a la comunicación, al establecer un lenguaje común en el ámbito organizacional

Facilitar poner el foco de atención en cuestiones críticas

Proveer recomendaciones generales

Ayudar a priorizar acciones de mejora

El CMM ha demostrado su impacto en la calidad del software producido bajo sus directrices. Las limitaciones más determinantes en CMM es que sólo es un modelo de referencia, es decir, sólo describe los procesos clave que una organización debe tener, y no explica cómo se deben implementar estos.

2.3.2 MOPROSOFT

Modelo de Procesos para la Industria del Software

Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo en la comunidad universitaria y profesional, y la norma técnica a la que da contenido es la NMX-059/01-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación de su declaratoria en el Diario oficial de la Federación. Moprosoft considera que los modelos de evaluación y mejora CMMI eI SO/IEC 15504 no resultan apropiados para empresas pequeñas y medianas de desarrollo y mantenimiento de software. Sobre las áreas de procesos de los niveles 2 y 3 del modelo SW-CMM e inspirándose en el marco de ISO/IE 15504 se ha desarrollado este modelo

2.4 Impacto de la calidad en tiempo, costo y alcance del proyecto

El alcance de un proyecto llamado también alcance del trabajo es el trabajo que debe hacerse para que el cliente se convenza de que las entregas (las cosas por hacer), es decir el producto u objetos tangibles que han de suministrarse) cumplan con los requisitos o criterios de aceptación acordados al comenzar el proyecto. Por ejemplo, el alcance podría ser el trabajo de limpiar el suelo, de construir una casa y de poner la jardinería ornamental según las especificaciones hechas por el cliente y aceptadas por el contratista.

Por estructuración se entiende la facilidad con que las funciones pueden ser compartimentalizadas y la naturaleza jerárquica de la información a tratar. A medida que el grado de estructuración aumenta, la posibilidad de estimar con precisión mejora y, por consiguiente, el riesgo disminuye. Bajo el concepto de la administración de proyectos, se asignan representantes de cada uno de los departamentos funcionales de las divisiones al equipo asignado al proyecto.

Análisis de riesgo y tipos de riesgos de un proyecto

La existencia de riesgos es inherente a cualquier actividad humana en tanto que absolutamente todo lo que realizamos en la vida está sometido a un determinado grado de incertidumbre. A la hora de ejecutar un proyecto, por muy buena que sea la planificación realizada, el conocimiento del ámbito y contexto en el que se desarrolla el proyecto y las previsiones sobre el futuro, también siempre existe un cierto margen para el error, que tiene su representación en los riesgos.

Se entiende por riesgo cualquier modificación en el entorno de mercado o en el producto que puede tener influencia sobre el proyecto que se está desarrollando.

Este cambio de circunstancias y de necesidades de los clientes no necesariamente tiene por qué ser un inconveniente para nuestro proyecto. Si estamos preparados para hacer frente a estos cambios, las consecuencias sobre el resultado de nuestro proyecto serán mínimas.

Incluso, si somos capaces de reaccionar adecuadamente ante este riesgo, podemos sacar beneficio de ello y mejorar nuestro producto, nuestras ventas, o la satisfacción de nuestros clientes.

Por tanto, la mejor manera de reducir la exposición a riesgos es realizar una adecuada planificación. En ella, los riesgos se deben abordar desde una perspectiva realista que permita su conocimiento y el trazado de planes de actuación en caso de que se presenten. En ningún caso se debe ignorar la existencia de los riesgos, sino que se deben controlar.

Ademá de una buena planificación, es necesario que el director de proyectos y la dirección de la empresa en su conjunto sepan cómo actuar ante la aparición de riesgos. La gestión adecuada de una situación de riesgo permitirá convertir las debilidades en fortalezas

Tipos de riesgos

Los objetivos de la gestión de riesgos son identificar, dirigir y eliminar las fuentes de riesgo antes de que empiecen a afectar a la finalización satisfactoria de un proyecto software.

El riesgo siempre implica dos características:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir.

Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Para cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo se consideran diferentes categorías de riesgos:

Riesgos del proyecto: o Afectan a la planificación temporal y al coste del proyecto. o Identifican problemas potenciales de presupuesto, calendario, personal, recursos.

Riesgos técnicos: o Amenazan la calidad y la planificación temporal del software que hay que producir. o Identifican posibles problemas de diseño, implementación, interfaz, verificación y mantenimiento.

Riesgos del negocio: o Amenazan la viabilidad del software. o Los principales riesgos de negocio son:

Riesgo de mercado

Riesgo estratégico

Riesgo de ventas

Riesgo de dirección

Riesgo de presupuesto

Se puede hacer otra categorización de los riesgos en función de su facilidad de detección:

Riesgos conocidos: son aquellos que se pueden predecir después de una evaluación del plan del proyecto, del entorno técnico y otras fuentes de información fiables.

Riesgos predecibles: se extrapolan de la experiencia de proyectos anteriores.

Riesgos impredecibles: pueden ocurrir, pero es extremadamente difícil identificarlos por adelantado.

La gestión continuada de los riesgos permite aumentar su eficiencia:

Evaluar continuamente lo que pueda ir mal

Determinar qué riesgos son importantes o Implementar estrategias para resolverlos

Asegurar la eficacia de las estrategias

Elementos de la gestión de riesgos

Estimación de riesgos:

Lista de riesgos capaces de romper la planificación del proyecto.

Análisis de riesgo: Medición de la probabilidad y el impacto de cada riesgo, y los niveles de riesgo de los métodos alternativos.

Priorización de riesgos: Lista de riesgos ordenados por su impacto.

Control de riesgos: Planificación de la gestión de riesgos: plan para tratar cada riesgo significativo.

Resolución de riesgos: Ejecución del plan.

Motorización de riesgos: Comprobación del progreso del control de un riesgo e identificación de la aparición de nuevos riesgos.

Identificación de riesgos

Constituye un intento sistemático para especificar las amenazas al plan del proyecto.

Las incertidumbres sobre diferentes características del proyecto se transforman en riesgos que pueden ser descritos y medidos.

Un método para identificar los riesgos es crear una lista de comprobación de elementos de riesgo que debe contener dos categorías de riesgos:

Riesgos específicos del producto: para identificarlos se examina el plan del proyecto y la declaración del ámbito del software.

Riesgos genéricos: Son comunes a todos los proyectos de software. Para identificarlos se crean las siguientes subcategorías:

amaño del producto

Impacto en el negocio

Características del cliente

Definición del proceso

Entorno de desarrollo

Tecnología a construir

Tamaño y experiencia de la plantilla.

Análisis de riesgos:

Es el proceso de examinar los riesgos en detalle para determinar su extensión, sus interrelaciones y su importancia.

Las actividades básicas son:

Evaluación: mejor comprensión del riesgo. Se cuantifican los siguientes conceptos:

Impacto: pérdida que ocasiona el riesgo.

Probabilidad: probabilidad de que ocurra el riesgo.
Marco de tiempo: periodo de tiempo en el que es posible mitigar el riesgo