Bloque III. Tema 17. La calidad del software y su medida. Modelos, métricas, normas y estándares

Referencias:

 

La calidad del software y su medida

Según Pressman:

     

La concordancia con los requisitos funcionales y de rendimiento, con los estándares de desarrollo y con las características implícitas que se espera del software desarrollado profesionalmente

 

Actualmente la calidad del software debe tenerse en cuenta a dos niveles:

La calidad del software a nivel de empresa se refiere a las acciones que se toman de forma común para asegurar que se desarrolla software de calidad en todos los proyectos. Se divide en dos tipos de procesos:

Los Key Performance Indicators (KPIs) son medidas que reflejan los factores críticos de éxito de una organización. Son los valores que dan una visión general del estado de la organización. Los KPIs representan una medida del progreso hacia los objetivos propuestos.

Modelos

COCOMO

El Constructive Cost Model (COCOMO) es un modelo de estimación del coste del software algorítmico. El modelo usa una fórmula de regresión, con parámetros derivados de datos históricos y sobre el proyecto actual.

COCOMO consiste en una jerarquía de tres niveles cada vez más detallados y exactos, que son Básico, Intermedioy Detallado.

COCOMO Básico

Computa el esfuerzo de desarrollo del software -coste- como una función del tamaño del programa. El tamaño del programa se expresa en miles de líneas de código (SLOC).

El esfuerzo aplicado se mide en hombre-mes. El modelo básico es bueno para:

COCOMO Intermedio

Computa el coste o esfuerzo como una función del tamaño del programa, pero también de un conjunto de “modificadores o drivers de coste” que incluyen valoraciones subjetivas sobre el producto, el hardware, el personal y las características del proyecto. Hay quince modificadores y algunos de ellos son:

Cada uno de los 15 atributos recibe una puntuación en una escala de 6, desde muy bajo hasta extra alto.

COCOMO Detallado

Incorpora las características del modelo intermedio más unas observaciones sobre el impacto de los modificadores de coste cost drivers en cada fase del proceso de ingeniería del software (análisis, diseño, etc.). Las cinco fases en que se enfoca el COCOMO detallado son:

El modelo de Putnam

Un modelo empírico de estimación del esfuerzo para el software.  Se recolecta información de desarrollos pasados y se crea una curva para los datos. La estimación del esfuerzo futuro se realiza usando la ecuación que casa con los datos.

Es uno de los pioneros y de los más ampliamente usados. El resultado se da en personas-mes y la medida del tamaño del software que usa es el número de líneas efectivas de código o Effective Source Lines of Code ESLOC

El Método Delphi

https://secure.wikimedia.org/wikipedia/en/wiki/Wideband_Delphi

 

Factores

Sirven para descomponer el concepto genérico de “calidad” en otros más sencillos, para facilitar su control y medición.

Existen varias clasificaciones de los factores de calidad. Veremos la de McCall, que los agrupa en tres perspectivas:

Métricas

Se aplican para valorar cualitativamente algún factor relativo al software. No existen métricas generales y únicas, aún menos para la calidad, ya que se puede examinar el software desde múltiples perspectivas y con diferentes objetivos. Se pueden desglosar según la fase en la que nos encontremos del ciclo de vida:

Fase de análisis

No existen muchas. Las más representativas miden el tamaño del software a desarrollar.

Punto Función

Tradicionalmente se ha medido el tamaño del software con distintas métricas: recuento de las líneas de código, número de programas fuente, que no han resultado muy aceptables.

La técnica de medición del tamaño en punto-función consiste en asignar una cantidad de “puntos” a una aplicación informática según la complejidad de los datos que maneja y de los procesos que realiza sobre ellos. Siempre tratando de considerarlo desde el punto de vista del usuario.

Y dentro de la familia “Punto Función” hay métodos concretos:

Métrica Bang

Propuesta por DeMarco, sirve para calcular el tamaño del software a desarrollar a partir del modelo de análisis. Una indicación, independiente de la implementación, del tamaño del sistema.

Métrica de calidad de especificación

Propuesta por Pressman, mide la calidad del análisis y de los requisitos capturados. A pesar de medir factores cualitativos, propone métricas como por ejemplo el número de requisitos donde los revisores han interpretado lo mismo.

Fase de Diseño

Trabajan frecuentemente con parámetros típicos de la estructura de los programas (métricas morfológicas) o con medidas del grado de cohesión, acoplamiento y complejidad de los algoritmos.

Métrica de complejidad de Card y Glass

Esta métrica se basa en dos factores, calculados para cada módulo a partir del diagrama de estructuras:

La complejidad del sistema se calcula como la suma de la complejidad estructural y la complejidad de datos de cada módulo.

Métricas de cohesión y acoplamiento

Cuantificar la cohesión y acoplamiento de los módulos en programación estructurada. Ver el tema 9 del bloque III para cohesión y acoplamiento.

Métricas orientadas a objetos

La inestabilidad es un conjunto de métricas para medir la calidad de los diseños orientados a objetos. En términos de la interdependencia entre los subsistemas del diseño partiendo de la base de que, aunque las interrelaciones son necesarias, los diseños con subsistemas fuertemente interrelacionados son muy rígidos, poco reutilizables y difíciles de mantener. Martin propone una medida para cada paquete, que llama inestabilidad, que depende del número de clases dentro del paquete que dependen de clases de otro y del número de clases de otros paquetes que tienen una dependencia con clases del paquete.

El conjunto de métricas CK es una de las más referenciadas. Está orientada a la complejidad de los métodos.

El Árbol de profundidad de herencia (APH) se define como la longitud máxima desde el nodo hasta la raíz del árbol. A medida que crece el APH, es más probable que las clases de niveles inferiores hereden muchos métodos.

El Número de Descendientes (NDD) son las subclases que son inmediatamente subordinadas a una clase. A medida que crece el número de descendientes se incrementa la reutilización, pero la abstracción representada por la clase predecesora puede verse diluida.

La Respuesta para una Clase es el conjunto de métodos que pueden ser ejecutados potencialmente en respuesta a un mensaje recibido por un objeto de esa clase. RPC se define como el número de métodos existentes en el conjunto de respuestas. A medida que crece RPC el esfuerzo necesario para la comprobación crece.

La Carencia de Cohesión en los Métodos se refiere a los atributos en común a los que acceden los diversos métodos. Si hay métodos que acceden a los mismos atributos, los métodos estarán acoplados entre ellos. En general un valor alto de acoplamiento indica que la clase podría diseñarse mejor.

Normas

Marcos de trabajo

Las buenas prácticas pueden venir de fuentes diferentes como marcos de trabajo que son públicos: ITIL, COBIT y CMMI; estándares: ISO/IEC 20000 e ISO 9000 o conocimiento privado de gente y organizaciones.

Recogen una serie de metas y procesos comunes que debe cumplir una organización. A diferencia de los estándares, dicen qué se debe hacer a nivel general, no cómo. Por ejemplo, una directiva de un marco de trabajo, simplificada, sería “se prueban las aplicaciones antes de entregarlas”.

CMMI

https://secure.wikimedia.org/wikipedia/en/wiki/CMMI

Capability Maturity Model Integration es un acercamiento de mejora de procesos cuyo objetivo es ayudar a las organizaciones a mejorar su rendimiento. Se puede usar

Fue desarrollado por el Software Engineering Institute en EEUU y sirve para comprobar la habilidad de los procesos de las organizaciones para realizar determinados proyectos. Se desarrolló a petición del departamento de defensa de EEUU.

Actualmente CMMI tiene tres áreas de interés: Desarrollo de productos y servicios (CMMI-DEV); establecimiento  de servicios, gestión y entrega y finalmente adquisición de productos y servicios.

Su predecesor CMM estaba totalmente orientado a ingeniería del software, pero CMMI es mucho más genérico y por tanto abstracto.

Dependiendo de la constelación CMMI que se elija (adquisición, servicios, desarrollo) las áreas de proceso que contienen variarán. Éstas son las áreas que deberán ser cubiertas por la organización. Hay 22 posibles áreas de proceso categorizados en cuatro categorías: Project Management, Engineering, Support y Process Management.  Cada uno lleva asociado un nivel de madurez y dependiendo de los que se consigan la organización podrá llegar a niveles de madurez más elevados. Éstos son algunos :

Hay cinco niveles de madurez, pero la puntuación de nivel de madurez se concede desde el 2 hasta el 5:

No se consigue una certificación CMMI sino una evaluación por persona autorizada (appraisal). Se llama Standard CMMI Appraisal Method for Process Improvement y hay tres clases: A, B y C.

SPICE

ISO/IEC 15504 o SPICE Software Process Improvement and Capability dEtermination. Tomaron como base ISO 12207-1, el estándar en el que se basa Metricav3 y CMM.

Es un conjunto de documentos de estándares técnicos para el proceso de desarrollo software. Es el modelo de referencia para modelos de madurez. La lista de áreas de procesos cubiertos son 6:

Para cada proceso, ISO/IEC 15504 define un nivel de capacidad en la escala siguiente:

CMMI

SPICE

 

0 proceso incompleto

1 proceso ad-hoc

1 proceso ejecutado

2 gestionado

2 proceso gestionado

3 definido

3 establecido

4 gestionado cuantitativamente

 

 

4 proceso predecible

5 optimizando

5 optimizando proceso

 

ITIL v3

IT Infraestructure Library proporciona un marco de trabajo público de guía de Mejores Prácticas para gestión de servicios TI.

     

Service Management is a set of specialized organizational capabilities for providing value to costumers in the form of services

ITIL plantea el análisis de la administración de los servicios de TI, con el objetivo de identificar las necesidades de los clientes y los distintos usuarios relacionados con los servicios TIC. Se han definido cinco elementos que interaccionan entre sí y se complementan:

 

COBIT

Un marco de trabajo creado por ISACA para gestión de las tecnologías de la información y gobierno de TI.

Proporciona buenas prácticas en un marco de dominios y procesos. Se dividen los procesos TI en cuatro dominios:

Y 34 procesos en línea con las áreas de responsabilidad de plan, build, run y monitor.

Se posiciona a un nivel alto y ha sido alineado y armonizado con otros más detallados como COSO, ITIL, ISO 27000, CMMI, TOGAF y PMBOK.

COSO

 

 

Estándares

Los estándares de calidad de software son normas emitidas por organismos específicos, que sirven para sentar un marco con el que comparar si un proceso de desarrollo es o no de calidad. Las más conocidas son las de la serie ISO 9000.

IEEE Std 610.12-1990

https://secure.wikimedia.org/wikipedia/en/wiki/Software_architecture

ISO 9000

https://secure.wikimedia.org/wikipedia/es/wiki/ISO_9000

https://secure.wikimedia.org/wikipedia/es/wiki/ISO_9001

Son un estándar de calidad para todo tipo de industrias. Contiene una normativa específica para el desarrollo de software, la ISO-90003:2004. Consiste en una serie de cláusulas que deben aplicarse en el marco de trabajo, en el ciclo de vida del proyecto y en las actividades de apoyo al mismo.

ISO 90003:2004

ISO 20000

Si bien existen numerosas aproximaciones al concepto y adopción de la mejora continua, la norma considera la utilización del modelo PDCA:

También conocido como ciclo de Deming. Este modelo establece esas cuatro fases cíclicas a aplicar a cualquier proceso o servicio que se esté gestionando.

La norma ISO/IEC 20000 incluye los ocho principios de la gestión de la calidad de ISO 9000. Los principios son:

ISO/IEC 27000

Parte de una familia creciente de Sistemas de Gestión para la Seguridad de la Información. Su título es:

       

Information Technology – Security Techniques – Information Security management systems – Overview and vocabulary

ISO/IEC 27001

       

Information Technology – Security Techniques – Information Security management systems – Requirements

ISO/IEC 27002

       

Information technology - Security techniques - Code of practice for information security management