Enfoque de la gestión de la calidad en ingeniería de software

Enfoque de la gestión de la calidad

en ingeniería de software

Introducción

La calidad ha sido una preocupación desde hace mucho en los negocios, y debe serlo también para los ingenieros de software en el análisis y diseño de sistemas de información. El principal objetivo de los ingenieros del software es producir un sistema, aplicación o producto de alta calidad, para lo cual emplean métodos y herramientas efectivas dentro del contexto de un proceso maduro de desarrollo del software y además deben desarrollar mediciones que den como resultado sistemas de alta calidad. Para obtener esta evaluación, el ingeniero debe utilizar medidas técnicas, que evalúan la calidad con objetividad, no con subjetividad. Es demasiado riesgoso realizar todo el proceso de análisis y diseño sin usar un enfoque de aseguramiento de la calidad. La planeación y el control son elementos esenciales de todo sistema exitoso. Se necesita un compromiso temprano de los ingenieros de software y de la empresa hacia la calidad para lograr el objetivo de la calidad.

Estructura de la gestión de la calidad

La gestión de calidad de software se estructura en torno a 3 actividades principales:

1) Garantía de calidad
2) Planificación de calidad
3) Control de la calidad

1) Garantía de calidad

La calidad es definida como el grado de relación que tiene el producto para satisfacer las necesidades del usuario. Un software que cumple con todos los requisitos con su usuario, y que sus procesos se ejecuten correctamente garantiza una buena Calidad.

Para ello debe considerar tipos de estándar:

Estándares de producto
Estándares que se aplican sobre el producto software que se comienza a desarrollar. Incluye estándares de documentación, estándares de codificación. 

Estándares de proceso
Define los procesos que deben seguirse durante el desarrollo de software. Incluyen definiciones de procesos de especificación, diseño y validación, así como una descripción de los documentos que deben escribirse durante los procesos.

Importancia de los estándares de software:

Los estándares de un producto guardan relación estrecha con los estándares de un proceso Los estándares de producto se aplican a la salida del proceso de software, mientras que los estándares de proceso incluyen actividades de proceso que garantizan que se sigan los estándares de producto.

Los estándares de software:

a) Se basan en el conocimiento de la mejor práctica de la empresa.

b) Proveen el marco de trabajo alrededor del cual se implementa el proceso de garantía de la calidad.

c) Permite que una persona continúe con facilidad el trabajo iniciado por otra. El utilizar buenas prácticas por todo el personal de la organización reduce el esfuerzo de aprendizaje cuando se inicia un nuevo proyecto.

2) Planificación de la calidad

La planificación de la calidad es el proceso en el cual se desarrolla un plan de calidad para un proyecto. Define la calidad del software deseado y describe cómo debe valorarse.

Humphrey propone una estructura para un plan de calidad basado en los siguientes pasos:

- Introducción del producto: Debe incluir la descripción del producto, el mercado al que se dirige y las expectativas de calidad. 

- Planes de producto: Contiene las fechas y plazos de terminación de producto y las responsabilidades asignadas. 

- Descripciones del proceso: Contiene los procesos de desarrollo y de servicio. 

- Metas de calidad: Contiene metas y planes de calidad para el producto, que deberán incluir la identificación de los atributos seleccionados como más relevantes. 

- Riesgos y gestión de riesgos: Contiene los riesgos clave que podrían afectar la calidad del producto.
Durante el proceso de planificación de la calidad debe considerarse los siguientes atributos:

Generalmente, no es posible optimizar todos los atributos para un sistema, por tanto debe priorizarse los atributos más relevantes para un determinado producto a desarrollar.

Ejemplo de planificación:

Definición de planificación de software:

La planificación es una actividad que se lleva adelante desde que el proyecto inicia hasta que el producto final (software) deja de usarse.

La planificación consiste en definir concretamente tres aspectos fundamentales de un proyecto:

El ámbito del software
Los recursos de a utilizar
Los riesgos del proyecto

Aspectos importantes:

Para realizar una buena planificación se necesita de:

Experiencia
Conocimiento sobre estimación
Herramientas de estimación
Herramientas de gestión de riesgos
Herramientas para el seguimiento a los planes

El ámbito del software:

Se define con absoluta claridad cuál es el alcance del sistema a desarrollar, no puede haber ambigüedades.

Se tiene que establecer con mucha anterioridad cuáles serán las funcionalidades del nuevo sistema.

Se asegura que el contrato de desarrollo se establezca el ámbito.

Para definir el ámbito se debe:

Obtener información por parte del cliente:
-   Observación
-   Entrevista
-   Cuestionarios 

Identificar la viabilidad:
-   Técnica
-   Tecnológica
-   Económica 

Identificar la comunidad usuarios finales:
-   Administradores
-   Supervisores
-   Operadores
-   Etc. 

Definir los “entregables” del proyecto:
-   Código
-   Etc.

Los productos finales del Ámbito:

Contrato
Fuente u origen para estimación
-   Costo
-   Precio
-   Tiempo
-   Esfuerzo
Tecnología de implementación
Organizar equipos de trabajo
Metodología

Pirámide:

Recursos:

Herramientas
-   Servidores (donde alojar el desarrollo del sistema)
-   Equipo Clientes (equipos en los que se desarrollará)
-   Red (tener una buena red que no sea wifi)
-   Impresoras (para imprimir código, pruebas de reportes u otros)
-   Otros dispositivos (para probar o correr el sistema realizado)
-   S.O. Servidor (Licencia Windows server para equipo cliente)
-   S.O. Clientes(Licencia Windows server para equipo cliente)
-   Soporte B.D. (Herramienta SQL server versión para developers)
-   Frameworks (ambientes de desarrollo con licencia versiones developer)
-   Navegadores (ambiente de desarrollo web, en q navegador se usara el sistema)
-   Antivirus
-   Ofimática (rational rose para documentación uml u otros)
-   Mensajería (interna o corporativo, por ejemplo gmail)
-   Otros Softwares (algún otro software más para soporte)

Componentes reutilizables
-   Librerías internas (desarrollo de componentes propios para ser reutilizable)
-   Librerías externas (adquirir librerías gratuitas o pagos)
-   Aplicaciones (para hacer BackUps)
-   Otros productos x/Desarrollo basado en case (para reportes, etc) 

Personas
-   Cargos/funciones (Dependiendo del conocimiento se asigna cargo y función)
-   Habilidades
-   Experiencia (niveles de experiencia de los desarrolladores)
-   Idiomas (La tecnología reciente está en inglés)
-   Conocimientos en otros áreas (otras maestrías o estudios) 

Factores a tomar en cuenta en la planificación
Estimación (Métricas)
Decisión: comprar vs desarrollar
Uso de plataformas CASE 

3) Control de la calidad

El control de calidad considera la vigilancia del proceso de desarrollo de software para asegurar que se sigan los procedimientos y los estándares de garantía de calidad. El control de calidad incluye la comprobación de que las entregas cumplan los estándares definidos.

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad  y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad.

Los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se sigue ninguna metodología, siempre habrá falta de calidad.

Existen algunos requisitos implícitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento), que también pueden implicar una falta de calidad.

La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.

El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.

El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.

El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

A partir del siguiente gráfico se observa la interrelación existente entre la gestión de la calidad, el aseguramiento de la calidad y el control de la calidad.

El control de calidad puede realizarse desde dos enfoques:

a) Revisión personal: El proceso de revisión de calidad de software, documentación y los procesos están a cargo de un grupo de personas.

b) Revisión automática: El proceso de revisión de calidad de software, documentación y los procesos es realizado por un programa utilizando para ello una medida cuantitativa de algunos atributos de software basados en métricas: inspecciones de diseño o programa, revisiones de progreso y revisiones de calidad.

El equipo de garantía de calidad debe crear un manual de estándares, el que debe incluir:

a) Estándares de producto
Formulario para revisión de diseño
Estructura del documento de requerimiento
Formato del encabezado de método
Formato de plan de proyecto
Estilo de programación en Java
Formulario de petición de cambios

b) Estándares de proceso
Conducto para la revisión de diseño
Sometimiento de documentos a CM
Proceso de entrega de versiones
Proceso de aprobación del plan de proyecto
Proceso de registro de pruebas

Estándares de documentación

Los estándares de documentación en un proyecto software son documentos muy importantes ya que son la única forma tangible de representar al software y su proceso. Los documentos deben ser fáciles de leer y de comprender.

Tipos de estándares de documentación:

• Estándares del proceso de documentación: Define que proceso seguir para la producción del documento. 

• Estándares del documento: Determinan la estructura y presentación de los documentos. 

• Estándares para el intercambio de documentos: Permiten que todas las copias electrónicas de los documentos sean compatibles.

Proceso de medición

Todo proceso de medición del software tiene como objetivo fundamental satisfacer necesidades de información a partir de las cuales se deben identificar las entidades y los atributos que deben ser medidos. El proceso de medición de software consiste en derivar un valor numérico desde algún atributo del software o del proceso de software. Las mediciones se realizan para hacer predicciones generales acerca del sistema, o bien para identificar componentes anómalos. Para la medición se utilizan métricas, que son medidas relacionadas con un sistema, proceso o documentación de software. Las métricas pueden ser de control o de predicción.

• Fases del proceso de medición 

El proceso de medición se realiza a través de varias fases. 

Elegir medidas a realizar: debe definirse claramente lo que se quiere medir. Para ello debe formularse las preguntas que la medición quiere responder y definir las mediciones requeridas para resolver las preguntas. 

Seleccionar componentes a valorar: Se debe elegir un conjunto de componentes representativos, para la medición, no es necesario medir todos los componentes. 

Medir características de los componentes: Se miden los componentes seleccionados y se calculan los valores de las métricas. 

Identificar medidas anómalas: Luego de obtenidas las mediciones de los componentes, se comparan entre sí con las mediciones de una base de datos de mediciones. 

Analizar componentes anómalos: Luego de identificados los componentes anómalos para las métricas particulares, se examinan estos componentes para decidir si los valores de las métricas indican que la calidad de los componentes está en peligro.

• Clasificación de métricas 

Con el fin de describir la conducta del software, se establecen las métricas que miden, entre otros aspectos, la competencia, calidad, desempeño y complejidad del software.
Presentamos a continuación la clasificación de las mismas:

- Métricas de complejidad: Definen la medición de la complejidad, tales como volumen, tamaño, anidaciones, costo (estimación) y configuración. Estas son los puntos críticos de la concepción, viabilidad, análisis y diseño de software. 

- Métricas de calidad: Definen la medición de la calidad del software, tales como exactitud, estructuración o modularidad, pruebas, mantenimiento, reusabilidad, entre otras. Estos son los puntos crí- ticos en el diseño, codificación, pruebas y mantenimiento.

- Métricas de competencia: Definen la valoración de las actividades de productividad de los programadores o practicantes con respecto a su certeza, rapidez, eficiencia y competencia.

- Métricas de desempeño: Definen la medición de la conducta de módulos y sistemas de un software, bajo la supervisión del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia de ejecución, tiempo, almacenamiento, complejidad de algoritmos computacionales, etc.

- Métricas estilizadas: Definen los mecanismos para medir la experimentación y preferencia, por ejemplo, estilo de código, las convenciones denominando de datos, las limitaciones, etc. Estas no deben ser confundidas con las métricas de calidad o complejidad.