29 de noviembre de 2012

Métricas de Calidad de Software

¿Qué pasa si no medimos?
  • No sabemos si estamos mejorando
  • No podemos establecer metas
¿Qué se puede medir?
  • El proceso del software (para mejorarlo).
  • El proyecto del software (para ayudar a estimar, control de calidad, evaluación de productividad, control de proyectos).
  • Calidad del producto (para ayudar el la toma de decisiones tácticas a medida que el proyecto evoluciona).
Medidas, métricas e indicadores
  • Medida: Indicación cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto.
  • Medición: Es el acto de determinar una medida.
  • Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado.
  • Indicador: Es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del SW, del proyecto del SW o del producto en sí.

MÉTRICAS

¿Qué miden?
  • Productividad
  • Calidad
Beneficios
  • Futuras Estimaciones
Medidas
  • Directas
  • Indirectas

Mediciones del Software

Las mediciones del mundo físico se pueden clasificar de dos maneras:
  • Medidas directas: Ej. Longitud de un tornillo :
  • Medidas indirectas: Ej. Calidad de los tornillos producidos, medidos contando los artículos defectuosos
Las métricas del SW, se categorizan de forma similar:
  • Directas: líneas de código producidas (LDC), velocidad de ejecución, tamaño de memoria
  • Indirectas: funcionalidad, calidad, complejidad.

Costos y métricas de calidad
  • Defecto y fallo: son sinónimos dentro del contexto del proceso del software. Implican un problema de calidad que es descubierto una vez entregado el software al cliente.
  • Error: Problema de calidad detectado por los ingenieros u otros dentro del proceso del software.

Indicadores Proyecto/Proceso
  • Indicadores de proceso: Permiten a una organización de ingeniería del software tener una visión profunda  de la eficacia de un proceso ya existente. (las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo).
  • Indicadores de proyecto: Permiten al gestor de proyectos del SW 
                                                    1. evaluar el estado de un proyecto en curso; 
                                                    2. seguir la pista de los riesgos potenciales;
                                                    3. detectar la áreas de problemas antes de que se conviertan en críticas;
                                                    4. ajustar el flujo y las tareas del trabajo;
                                                    5. evaluar la habilidad del equipo.

Métricas
  • Por término general, para la evaluación de la calidad, es más habitual centrarse en medidas del producto que en medidas del proceso.
  • Una métrica es una asignación de un valor a un atributo (tiempo, complejidad, etc.) de una entidad software, ya sea un producto (código) o un proceso (pruebas).

Principios de Medición
  • Los objetivos de la medición deben establecerse antes de empezar la recogida de los datos.
  • Todas la métricas deben definirse sin ambigüedades.
  • La métricas deben obtenerse basándose en una teoría válida para el dominio de la aplicación.
  • Siempre que sea posible, automatizar la recogida de los datos y el análisis.
  • Aplicar técnicas estadísticas válidas para establecer relaciones entre los atributos internos y características  externas de la calidad del producto.
  • Establecer directrices de interpretación y recomendación.

Características de las Métricas
  • Simples y fáciles de calcular
  • Empírica e intuitivamente persuasivas
  • Consistentes y objetivas
  • Independientes del lenguaje de programación
  • Eficaz mecanismo para realimentar la calidad

Etapas del Proceso de Medición
  • Formulación: la obtención de medidas y métricas apropiadas para la representación del SW que se desea desarrollar.
  • Colección: mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
  • Análisis: cálculo de las métricas.
  • Interpretación: evaluación de los resultados.
  • Realimentación: recomendaciones obtenidas a través de la interpretación de las métricas obtenidas por el  equipo de desarrollo.

Métricas

Para la evaluación de las características del SW, utilizaremos métricas. Clasificación:
  • Clasificación 1:
                                 - Métricas de producto.
                                  - Métricas de proceso.
  • Clasificación 2:
                                  - Métricas basadas en atributos internos del producto:
                                                 * Medidas de estructuración de un programa.
                                                * Métricas de complejidad.
                                                 * Métricas de cobertura de pruebas.
                                                 * Métricas de calidad del diseño.

                                  - Métricas basadas en atributos externos del producto:
                                                  * Métricas de portabilidad.
                                                 * Métricas de defectos.
                                                  * Métricas de usabilidad.
                                                  * Métricas de mantenibilidad.
                                                  * Métricas de fiabilidad. 

                                  - Métricas basadas en código fuente:
                                                 * Nº de líneas de código.
                                                 * Nº de líneas de comentario.
                                                 * Nº de instrucciones.
                                                 * Densidad de documentación.

                                  - Métricas basadas en estructura de diseño:
                                                *  Relacionadas con el control intramodular.
                                                * Relacionadas con el acoplamiento entre clases.
                                                * Métricas para sistemas orientados a objetos:
                                                * Acoplamiento.
                                                * Herencia.
                                                * Cohesión.

24 de noviembre de 2012

Métricas del Mantenimiento


Todas las métricas del software pueden usarse para el desarrollo de nuevo software y para el mantenimiento del existente. Sin embargo, se han propuesto métricas diseñadas explícitamente para actividades de mantenimiento.

El estándar EEE 982.1-1988 sugiere un índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto software (basada en los cambios que ocurren con cada versión del producto). Se determina la siguiente información:



El índice de madurez del software se calcula de la siguiente manera:


A medida que el IMS se aproxima a 1 ,O el producto se empieza a estabilizar. EL IMS puede emplearse también como métrica para la planificación de las actividades de mantenimiento del software. El tiempo medio para producir una versión de un producto software puede correlacionarse con el IMS desarrollándose modelos empíricos para el mantenimiento.



Métricas para Pruebas

Aunque se ha escrito mucho sobre las métricas del software para pruebas, la mayoría de las métricas propuestas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse de las métricas de análisis, diseño y código para que les guíen en el diseño y ejecución de los casos de prueba.

Las métricas basadas en la función pueden emplearse para predecir el esfuerzo global de las pruebas. Se pueden juntar y correlacionar varias características a nivel de proyecto (por ejemplo, esfuerzo y tiempo para las pruebas, errores descubiertos, número de casos de prueba producidos) de proyectos anteriores con el número de PF producidos por un equipo del proyecto. El equipo puede después predecir los valores «esperados» de estas características del proyecto actual.

La métrica bang puede proporcionar una indicación del número de casos de prueba necesarios para examinar las medidas primitivas. El número de primitivas funcionales (PFu), elementos de datos (DE), objetos (OB), relaciones (RE), estados (ES) y transiciones (TR) pueden emplearse para predecir el número y tipos de prueba del software de caja negra y de caja blanca. Por ejemplo, el número de pruebas asociadas con la interfaz hombre-máquina se puede estimar examinando: (1) el número de transiciones (TR) contenidas en la representación estado-transición del IHM y evaluando las pruebas requeridas para ejecutar cada transición, (2) el número de objetos de datos (OB) que se mueven a través de la interfaz y (3) el número de elementos de datos que se introducen o salen.

Las métricas del diseño arquitectónico proporcionan información sobre la facilidad o dificultad asociada con
la prueba de integración y la necesidad de software especializado de prueba (por ejemplo, matrices y controladores). La complejidad ciclomática (una métrica de diseño de componentes) se encuentra en el núcleo de las pruebas de caminos básicos. Además, la complejidad ciclomática puede usarse para elegir módulos como candidatos para pruebas más profundas. Los módulos con gran complejidad ciclomática tienen más probabilidad de tendencia a errores que los módulos con menor complejidad ciclomática.
Por esta razón, el analista debería invertir un esfuerzo extra para descubrir errores en el módulo antes de integrarlo en un sistema. Es esfuerzo de las pruebas también se puede estimar usando métricas obtenidas de medidas de Halstead. Usando la definición del volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software, e, puede calcularse como:



El porcentaje del esfuerzo global de pruebas a asignar a un módulo k se puede estimar usando la siguiente relación:


donde e(k) se calcula para el módulo k usando la primera ecuaciones y la suma en el denominador de la segunda ecuación  es la suma del esfuerzo de la ciencia del software a lo largo de todos los módulos del sistema.

A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas. Una medida de la amplitud de las pruebas proporciona una indicación de cuantos requisitos (del número total de ellos) se han probado.
Esto proporciona una indicación de la compleción del plan de pruebas. La profundidad de las pruebas es una medida del porcentaje de los caminos básicos independientes probados en relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. Finalmente, a medida que se van haciendo las pruebas y se recogen los datos de los errores, se pueden emplear los perfiles de fallos para dar prioridad y categorizar los errores descubiertos. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadísticos de errores.




Métricas del Código Fuente


La teoría de Halstead de la ciencia del software es «probablemente la mejor conocida y más minuciosamente estudiada ... medidas compuestas de la complejidad (software)». La ciencia del software
propone las primeras «leyes» analíticas para el software de computadora.

La ciencia del software asigna leyes cuantitativas al desarrollo del software de computadora, usando un conjunto de medidas primitivas que pueden obtenerse una vez que se ha generado o estimado el código después de completar el diseño. Estas medidas se listan a continuación.



Halstead usa las medidas primitivas para desarrollar expresiones para la longitud global del programa; volumen mínimo potencial para un algoritmo; el volumen real (número de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras características tales como esfuerzo de desarrollo, tiempo de desarrollo e incluso el número esperado de fallos en el software.

Halstead expone que la longitud N se puede estimar como:


y el volumen de programa se puede definir como:


Se debería tener en cuenta que V variará con el lenguaje de programación y representa el volumen de información (en bits) necesarios para especificar un programa.
Teóricamente, debe existir un volumen mínimo para un algoritmo. Halstead define una relación de volumen L como la relación de volumen de la forma más compacta de un programa con respecto al volumen real del programa. Por tanto, L debe ser siempre menor de uno. En términos de medidas primitivas, la relación de volumen se puede expresar como:




22 de noviembre de 2012

Métricas del Modelo del Diseño

Es inconcebible que el diseño de un nuevo avión, un nuevo chip de computadora o un nuevo edificio de oficinas se realizara sin definir las medidas del diseño, sin determinar las métricas para varios aspectos de la calidad del diseño y usarlas para guiar la evolución del diseño. Y sin embargo, el diseño de sistemas complejos basados en computadora a menudo consigue proseguir sin virtualmente ninguna medición. La ironía es que las métricas de diseño para el software están disponibles, pero la gran mayoría de los desarrolladores de software continúan sin saber que existen.

Las métricas de diseño para el software, como otras métricas del software, no son perfectas. Continúa el debate sobre la eficacia y cómo deberían aplicarse. Muchos expertos argumentan que se necesita más experimentación hasta que se puedan emplear las métricas de diseño. Y sin embargo, el diseño sin medición es una alternativa inaceptable.


MÉTRICAS DEL DISEÑO ARQUITECTÓNICO

Se centran en la arquitectura del programa y la eficiencia de los módulos. Son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en particular del sistema.

Card y Glass definen tres medidas de la complejidad del diseño del software: complejidad estructural, complejidad de datos y complejidad del sistema.


La complejidad estructural, S(i), de un módulo i se define de la siguiente manera:

 donde es la expansión' del módulo i.



La complejidad de datos, D(i), proporciona una indicación de la complejidad en la interfaz interna de un módulo i y se define como:

donde v(i) es el número de variables de entrada y salida que entran y salen del módulo i.


La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos, y se define como:



MÉTRICAS DE DISEÑO A NIVEL DE COMPONENTES

Las métricas de diseño a nivel de componentes se concentran en las características internas de los componentes del software e incluyen medidas de las «3Cs» la cohesión, acoplamiento y complejidad del módulo. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de los componentes.
Las métricas presentadas en esta sección son de caja blanca en el sentido de que requieren conocimiento del
trabajo interno del módulo en cuestión. Las métricas de diseño de los componentes se pueden aplicar una vez que se ha desarrollado un diseño procedimental. También se pueden retrasar hasta tener disponible el código fuente.

Métricas de Cohesión: Bieman y Ott definen una colección de métricas que proporcionan una indicación de la cohesión de un módulo. Las métricas se definen con cinco conceptos y medidas:

Porción de datos. Dicho simplemente, una porción de datos es una marcha atrás a través de un módulo que busca valores de datos que afectan a la localización de módulo en el que empezó la marcha atrás. Debería resaltarse que se pueden definir tanto porciones de programas (que se centran en enunciados y condiciones) como porciones de datos.

Muestras (tokens) de datos. Las variables definidas para un módulo pueden definirse como muestras de datos para el módulo.

Señales de unión. El conjunto de muestras de datos que se encuentran en una o más porciones de datos.

Señales de superunión. La muestras de datos comunes a todas las porciones de datos de un módulo.

Pegajosidad. La pegajosidad relativa de una muestra de unión es directamente proporcional al número de porciones de datos que liga.

Métricas de acoplamiento: El acoplamiento de módulo proporciona una indicación de la conectividad» de un módulo con otros módulos, datos globales y el entorno exterior. En el Capítulo 13, el acoplamiento se estudió en términos cualitativos.
Dhama ha propuesto una métrica para el acoplamiento del módulo que combina el acoplamiento de flujo de datos y de control, acoplamiento global y acoplamiento de entorno. Las medidas necesarias para calcular el acoplamiento de módulo se definen en términos de cada uno de los tres tipos de acoplamiento apuntados anteriormente.

Para el acoplamiento de flujo de datos y de control:
di = número de parámetros de datos de entrada
ci = número de parámetros de control de entrada
do = número de parámetros de datos de salida
co = número de parámetros de control de salida

Para el acoplamiento global:
g, = número de variables globales usadas como datos
g, = número de variables globales usadas como control

Para el acoplamiento de entorno:
w = número de módulos llamados (expansión)
r = número de módulos que llaman al módulo en cuestión

Métricas de Complejidad: Se pueden calcular una variedad de métricas del software para determinar la complejidad del flujo de control del programa. Muchas de éstas se basan en una representación denominada
gafo de flujo. Un gafo es una representación compuesta de nodos y enlaces (también denominados aristas). Cuando se dirigen los enlaces (aristas), el grafo de flujo es un grafo dirigido.

McCabe identifica un número importante de usos para las métricas de complejidad:
Las métricas de complejidad pueden emplearse para predecir la información crítica sobre la fiabilidad y mantenimiento de sistemas software de análisis automáticos de código fuente (o información de diseño procedimental). Las métricas de complejidad también realimentan la información durante el proyecto de software para ayudar a controlar la [actividad del diseño]. Durante las pruebas y el mantenimiento, proporcionan una detallada información sobre los módulos software para ayudar a resaltar las áreas de inestabilidad potencial.

McCabe también defiende que la complejidad ciclomática puede emplearse para proporcionar una indicación cuantitativa del tamaño máximo del módulo. Recogiendo datos de varios proyectos de programación reales, ha averiguado que una complejidad ciclomática de 10 parece ser el límite práctico superior para el tamaño de un módulo. Cuando la complejidad ciclomática de los módulos excedían ese valor, resultaba extremadamente difícil probar adecuadamente el módulo. 


MÉTRICAS DE DISEÑO DE INTERFAZ

Sears sugiere la conveniencia de la representación (CR) como una valiosa métrica de diseño para interfaces hombre-máquina. Una IGU (Interfaz Gráfica de Usuario) típica usa entidades de representación iconos gráficos, texto, menús, ventanas y otras para ayudar al usuario a completar tareas. Para realizar una tarea dada usando una IGU, el usuario debe moverse de una entidad de representación a otra. Las posiciones absolutas y relativas de cada entidad de representación, la frecuencia con que se utilizan y el «coste» de la transición de una entidad de representación a la siguiente contribuirán a la conveniencia de la interfaz.

Para una representación específica (por ejemplo, un de una IGU específica), se pueden asignar costes a cada secuencia de acciones de acuerdo con la siguiente relación:


Para calcular la representación óptima de una IGU, la superficie de la interfaz (el área de la pantalla) se divide en una cuadrícula. Cada cuadro de la cuadricula representa una posible posición de una entidad de la representación. Para una cuadrícula con N posibles posiciones y K diferentes entidades de representación para colocar, el número posible de distribuciones se representa de la siguiente manera:


A medida que crece el número de posiciones de representación, el número de distribuciones posibles se hace muy grande. Para encontrar la representación óptima (menor coste). Sears propone un algoritmo de búsqueda en árbol.

La CR se emplea para valorar diferentes distribuciones propuestas de IGU y la sensibilidad de una representación en particular a los cambios en las descripciones de tareas (por ejemplo, cambios en la secuencia y/o frecuencia de transiciones). El diseñador de interfaces puede emplear el cambio en la conveniencia de la representación, ACR, como guía en la elección de la mejor representación de IGU para una aplicación en particular.

Es importante apuntar que la selección de un diseño de IGU puede guiarse con métricas tales como CR, pero el árbitro final debería ser la respuesta del usuario basada en prototipos de IGU. Nielsen y Levy informan que «existe una gran posibilidad de éxito si se elige una interfaz basándose solamente en la opinión del usuario. El rendimiento medio de tareas de usuario y su satisfacción con la IGU están altamente relacionadas.»






20 de noviembre de 2012

Métricas del Modelo de Análisis

En esta fase es deseable que las métricas técnicas proporcionen una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionadas.


MÉTRICAS BASADAS  EN LA FUNCIÓN

La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función: 
  • Número de entradas del usuario 
  • Número de salidas del usuario 
  • Número de consultas del usuario 
  • Número de archivos 
  • Número de interfaces externas
La cuenta total debe ajustarse utilizando la siguiente ecuación:  PF = cuenta-total x (0,65 + 0,01 x åFi) 



Donde cuenta total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad"

Para el ejemplo descrito en la figura 9.2 se asume que la EFi es 46 (un producto moderadamente complejo), por consiguiente:
                                                       PF = 50 x (0,65 + 0,01 x 46) = 56

Basándose en el valor previsto del PF obtenido del modelo de análisis, el equipo del proyecto puede estimar el tamaño global de implementación de las funciones de interacción. Asuma que los datos de los que se dispone indican que un PF supone 60 líneas de código (se utilizará un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF. Estos datos históricos proporcionan al gestor del proyecto una importante información de planificación basada en el modelo de análisis en lugar de estimaciones preliminares.


MÉTRICA BANG

Al igual que la métrica de punto de función, la métrica bang puede emplearse para desarrollar una indicación
del tamaño del software a implementar como consecuencia del modelo de análisis.

Desarrollada por DeMarco, la métrica bang es «una indicación independiente de la implementación del tamaño del sistema». Para calcular la métrica bang, el desarrollador de software debe evaluar primero un conjunto de primitivas (elementos del modelo de análisis que no se subdividen más en el nivel de análisis).

Las primitivas se determinan evaluando el modelo de análisis y desarrollando cuentas para los siguientes elementos: 

Primitivas funcionales (PFu). Transformaciones (burbujas) que aparecen en el nivel inferior de un diagrama de flujo de datos.
Elementos de datos (ED). Los atributos de un objeto de datos, los elementos de datos son datos no compuestos y aparecen en el diccionario de datos.
Objetos (OB). Objetos de datos.
Relaciones (RE). Las conexiones entre objetos de datos.
Estados (ES). El número de estados observables por el usuario en el diagrama de transición de estados.
Transiciones (TR). El número de transiciones de estado en el diagrama de transición de estados.


Además de las seis primitivas apuntadas arriba, se determinan las cuentas adicionales para:

Primitivas modificadas de función manual (PMFu). Funciones que caen fuera del límite del sistema y que deben modificarse para acomodarse al nuevo sistema.
Elementos de datos de entrada (EDE). Aquellos elementos de datos que se introducen en el sistema.
Elementos de datos de salida (EDS). Aquellos elementos de datos que se sacan del sistema.
Elementos de datos retenidos (EDR). Aquellos elementos de datos que son retenidos (almacenados) por el sistema.
Muestras (tokens) de datos (TCi). Las muestras de datos (elementos de datos que no se subdividen dentro de una primitiva funcional) que existen en el límite de la i-ésima primitiva funcional (evaluada para cada primitiva).
Conexiones de relación (REi). Las relaciones que conectan el i-ésimo objeto en el modelo de datos con otros objetos.

DeMarco sugiere que la mayoría del software se puede asignar a uno de los dos dominios siguientes, dominio de función o dominio de datos, dependiendo de la relación RE/PFu. Las aplicaciones de dominio de
función (encontradas comúnmente en aplicaciones de ingeniería y científicas) hacen hincapié en la transformación de datos y no poseen generalmente estructuras de datos complejas. Las aplicaciones de dominio de datos (encontradas comúnmente en aplicaciones de sistemas de información) tienden a tener modelos de datos complejos.
       RE/PFu < 0,7 implica una aplicación de dominio de función
     0,8 < RE/PFu < 1,4 indica una aplicación híbrida
     RE/PFu > 13 implica una aplicación de dominio de datos

Como diferentes modelos de análisis harán una partición del modelo con mayor o menor grado de refinamiento. DeMarco sugiere que se emplee una cuenta media de muestra (token) por primitiva 
                                                                
                                                                             Teavg= DC,IPFu 

para controlar la uniformidad de la partición a través de muchos diferentes modelos dentro del dominio de una aplicación.
Para calcular la métrica bang para aplicaciones de dominio de función, se emplea el siguiente algoritmo:

Asignar a bang un valor inicial = 0;
Mientras queden primitivas funcionales por evaluar
Calcular cuenta-token alrededor del límite de la primitiva i;
Calcular el incremento PFu corregido (IPFuC)
Asignar la primitiva a una clase
Evaluar la clase y anotar el peso valorado
Multiplicar IPFuC por el peso valorado
bang = bang + ponderación IPFuC;  
FinMientras

La cuenta-token se calcula determinando cuántos símbolos léxicos (tokens) diferentes son «visibles» dentro de la primitiva. Es posible que el número de símbolos léxicos (tokens) y el número de elementos de datos sea diferente, si los elementos de datos pueden moverse desde la entrada a la salida sin ninguna transformación interna. La IPFuC corregida se determina de una tabla publicada por DeMarco. A continuación, se presenta una versión muy abreviada:


La ponderación valorada apuntada en el algoritmo anterior se calcula de dieciséis clases diferentes de primitivas funcionales definidas por DeMarco. Se asigna una ponderación que va de 0,6 (encaminamiento simple de datos) a 2,5 (funciones de gestión de datos) dependiendo de la clase de la primitiva.
Para aplicaciones de dominio de datos, se calcula la métrica bang mediante el siguiente algoritmo:

Asignar a bang el valor inicial = 0;
Mientras queden objetos por evaluar en el modelo de datos
Calcular la cuenta de relaciones’ del objeto i
Calcular el incremento de OB corregido (IOBC); bang = bang t IOBC;
FinMientras

El IOBC corregido se determina también de una tabla publicada por DeMarco. A continuación se muestra una versión abreviada:


Una vez que se ha calculado la métrica bang, se puede emplear el historial anterior para asociarla con el esfuerzo y el tamaño. DeMarco sugiere que las organizaciones se construyan sus propias versiones de tablas
IPFuC e IOBC para calibrar la información de proyectos completos de software.


MÉTRICAS DE LA CALIDAD DE LA ESPECIFICACIÓN

Davis y sus colegas proponen una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: especificidad (ausencia de ambigüedad), compleción, corrección, comprensión, capacidad de verificación, consistencia interna y externa, capacidad de logro, concisión, trazabilidad, capacidad de modificación, exactitud y capacidad de reutilización. Además, los autores apuntan que las especificaciones de alta calidad deben estar almacenadas electrónicamente, ser ejecutables o al menos interpretables, anotadas por importancia y estabilidad relativas, con su versión correspondiente, organizadas, con referencias cruzadas y especificadas al nivel correcto de detalle.

Aunque muchas de las características anteriores parecen ser de naturaleza cualitativa, Davis sugiere que todas puedan representarse usando una o más métricas. Por ejemplo, asumimos que hay n, requisitos en una especificación, tal como

donde nf es el número de requisitos funcionales y nnf es el número de requisitos no funcionales (por ejemplo,
rendimiento).
Para determinar la especificidad (ausencia de ambigüedad) de los requisitos. Davis sugiere una métrica basada en la consistencia de la interpretación de los revisores para cada requisito:


donde nUi es el número de requisitos para los que todos los revisores tuvieron interpretaciones idénticas. Cuanto más cerca de 1 esté el valor de Q, menor será la ambigüedad de la especificación.
La compleción de los requisitos funcionales pueden determinarse calculando la relación


donde u, es el número de requisitos únicos de función, ni es el número de entradas (estímulos) definidos o implicados por la especificación y n, es el número de estados especificados. La relación Q, mide el porcentaje de funciones necesarias que se han especificado para un sistema. Sin embargo, no trata los requisitos no funcionales. Para incorporarlos a una métrica global completa, debemos considerar el grado de validación de los requisitos.




donde n, es el número de requisitos que se han validado como correctos y n," el número de requisitos que no se han validado todavía.

15 de noviembre de 2012

Estructura para las Métricas del Software

La medición asigna números o símbolos a atributos de entidades en el mundo real. Para conseguirlo se necesita un modelo de medición que comprenda un conjunto consistente de reglas.

Existe la necesidad de medir y controlar la complejidad del software. Y si es difícil de obtener un solo valor de esta «métrica de calidad», si debería ser posible desarrollar medidas de diferentes atributos internos del programa (por ejemplo, modularidad efectiva, independencia funcional y otros atributos). Estas medidas y las métricas obtenidas de ellas pueden usarse como indicadores independientes de la calidad de los modelos de análisis y diseño.

Los principios básicos de la medición, sugeridos por Roche, pueden  caracterizarse mediante cinco actividades:
  • Formulación. la obtención de medidas y métricas del software apropiadas para la representación del software en cuestión.
  • Colección. el mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
  • Análisis. el cálculo de las métricas y la aplicación de herramientas matemáticas.
  • Interpretación. la evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación.
  • Realimentación (feedback). recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo que construye el software.
Los principios que se pueden asociar con la formulación de las métricas técnicas son los siguientes:
  1. Los objetivos de la medición deberían establecerse antes de empezar la recogida de datos.
  2. Todas las técnicas sobre métricas deberían definirse sin ambigüedades.
  3. Las métricas deberían obtenerse basándose en una teoría válida para el dominio de aplicación (por ejemplo, las métricas para el diseño han de dibujarse sobre conceptos y principios básicos de diseño y deberían intentar proporcionar una indicación de la presencia de un atributo que se considera beneficioso).
  4. Hay que hacer las métricas a medida para acomodar mejor los productos y procesos específicos.
Aunque la formulación es un punto de arranque crítico, la recogida y análisis son las actividades que dirigen el proceso de medición. Roche sugiere los siguientes principios para estas actividades:
        
- Siempre que sea posible, la recogida de datos y el análisis debe automatizarse.
- Se deberían aplicar técnicas estadísticas válidas para establecer las relaciones entre los atributos   internos del producto y las características externas de la calidad (por ejemplo, ¿está correlacionado el nivel de complejidad arquitectónico con el número de defectos descubiertos en la producción?).
- Se deberían establecer una directrices de interpretación y recomendaciones para todas las métricas.

Ejiogu define un conjunto de atributos que deberían acompañar a las métricas efectivas del software.
La métrica obtenida y las medidas que conducen a ello deberían ser: 
  • Simples y fáciles de calcular. 
  • Empírica e intuitivamente persuasiva.
  • Consistente y objetiva.
  • Consistente en el empleo de unidades y tamaños.
  • Independiente del lenguaje de programación.
  • Un eficaz mecanismo para la realimentación de calidad.
La experiencia indica que una métrica técnica se usa únicamente si es intuitivo y fácil de calcular. Si se requiere docenas de «cantadores» y se han de utilizar complejos cálculos, la métrica no será ampliamente utilizada.




14 de noviembre de 2012

Calidad del Software

Un elemento clave de cualquier proceso de ingeniería es la medición. Empleamos medidas para entender mejor los atributos de los modelos que creamos. Pero, fundamentalmente, empleamos las medidas para valorar la calidad de los productos de ingeniería o de los sistemas que construimos.
A diferencia de otras disciplinas, la ingeniería del software no está basada en leyes cuantitativas básicas de la Física. Las medidas absolutas, tales como el voltaje, la masa, la velocidad o la temperatura no son comunes en el mundo del software. En su lugar, intentamos obtener un conjunto de medidas indirectas que dan lugar a métricas que proporcionan una indicación de la calidad de algún tipo de representación del software. Como las medidas y métricas del software no son absolutas, están abiertas a debate. Fenton trata este aspecto cuando dice:
La medición es el proceso por el que se asignan números o símbolos a los atributos de las entidades en el mundo real, de tal manera que las definan de acuerdo con unas reglas claramente definidas .... En las ciencias físicas, medicina y, más recientemente, en las ciencias sociales, somos ahora capaces de medir atributos que previamente pensábamos que no eran medibles ... Por supuesto, tales mediciones no están tan refinadas como las de las ciencias físicas ..., pero existen [y se toman importantes decisiones basadas en ellas]. Sentimos que la obligación de intentar «medir lo no medible» para mejorar nuestra comprensión de entidades particulares es tan poderosa en la ingeniería del software como en cualquier disciplina.


CALIDAD DEL SOFTWARE
  • Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
  • Unos estándares específicos definen un conjunto de criterios de desarrollo que guían la manera en que se hace la ingeniería del software. Si no se siguen los criterios, habrá seguramente poca calidad.
  • Existe un conjunto de requisitos implícitos que a menudo no se nombran (por ejemplo, facilidad de mantenimiento). Si el software cumple con sus requisitos explícitos pero falla en los implícitos, la calidad del software no será fiable.
• Pressman (Pressman, 1998) define la calidad del software como:

“la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

• En la definición de la calidad del software pueden estar involucrados aspectos como la ausencia de defectos, aptitud para el uso, seguridad, confiabilidad y reunión de especificaciones. Sin embargo, hay algo importante que se debe tener presente: la calidad del software debe ser construida desde el comienzo, no es algo que puede ser añadido después.

• Para que el producto final sea de calidad, el proceso por medio del cual éste es elaborado debe ser también de calidad.


ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

• Sridharan (Sridharan, 2000) indica que mientras el software que se está desarrollado reúne los requerimientos y su desempeño es el esperado, es preciso que se supervisen las actividades de desarrollo del software y su rendimiento, en distintas oportunidades durante cada fase del ciclo de vida. Este es el papel del aseguramiento de la calidad del software.

• Hay tres (3) aspectos muy importantes con relación al aseguramiento de la calidad del software: (Wiegers, 1990)

– La calidad no se puede probar, se construye.
– El aseguramiento de la calidad del software no es una tarea que se realiza en una fase particular del      ciclo de vida de desarrollo.
– Las actividades asociadas con el aseguramiento de la calidad del software deben ser realizadas por personas que no estén directamente involucradas en el esfuerzo de desarrollo.

• Pressman (Pressman, 1998) considera que el aseguramiento de la calidad del software comprende una gran variedad de tareas asociadas:

– Preparar u plan de aseguramiento de la calidad del software para un proyecto.
– Participar en el desarrollo del proceso de descripción del proyecto de software.
– Revisar las actividades de ingeniería del software para verificar su consistencia con el proceso de software definido.
– Auditar el producto de software para verificar el cumplimiento del proceso de software definido
– Asegurar que las divergencias en el trabajo de software sean documentadas de acuerdo a los estándares definidos.
– Alamacenar cualquier inconformidad y reportarla a la gerencia media.


CONTROL DE LA CALIDAD DEL SOFTWARE


• Según Monsalve (Monsalve, 1998), el control de la calidad se relaciona con la vigilancia permanente de todo el proceso de desarrollo y el ciclo de vida del software. Se logra mediante la observación constante del cumplimiento de cada una de las fases y actividades involucradas en el proceso de desarrollo.

• Para realizar un control de calidad deben ejecutarse frecuentes inspecciones a las metodologías de trabajo y a el uso de las herramientas, revisiones de prototipos y de las pruebas formales de los productos finales.

• El control de la calidad permite realizar las rectificaciones necesarias a cualquier falla encontrada durante el proceso de desarrollo.

• Adicionalmente, el asegurar la calidad en las primeras fases del proceso de desarrollo del software implica que los costos del control en las etapas posteriores tiende a disminuir al tener menos aspectos que controlar, además de que la calidad estaría asegurada en sus bases.


AUDITORIA DE LA CALIDAD DEL SOFTWARE


• La auditoría de la calidad se utiliza para descubrir y detener los errores del software. Se lleva a cabo para monitorear eventos específicos, o bien para revisar todas las actividades de un sistema.

• Las auditorías permiten garantizar la calidad del software: luego de llevar a cabo una auditoría de calidad, es más fácil mantener un registro con las deficiencias presentadas.

• La auditoría de la calidad del software tiene tres (3) metas de seguridad importantes:

  1. Revisar los modelos de acceso a los componentes, las historias de acceso a los procesos y el uso de los mecanismos de protección soportados por el sistema.
  2. Descubrir los usuarios frecuentes y esporádicos que se esfuerzan por desviar los mecanismos de protección.
  3. Descubrir cualquier uso de privilegios que pueden ocurrir cuando un usuario asume una funcionalidad con privilegios mayores que el suyo propio.

CALIDAD DEL PRODUCTO DE SOFTWARE

• Para Monsalve (Monsalve, 1998), la principal meta de un equipo desarrollador de software debe ser siempre producir software de calidad; para ello, se deben tener en cuenta dos (2) ideas muy importantes:
– Los productos de software son realizados por personas y para personas.
– Muchas personas asocian la calidad a un atributo exclusivo del producto y que comienza a considerarse una vez que se escriben las primeras líneas de código.

• La calidad que pueden alcanzar los productos de software, y en general cualquier tipo de producto, está sometida a la manera cómo se desarrolla cada una de las etapas de la vida del producto, iniciándose con la concepción de la idea del producto hasta la entrega final y mantenimiento del mismo.

• La calidad del producto de software involucra actividades como:
– Administración de la calidad.
– Uso de tecnología de Ingeniería de Software eficiente.
– Aplicación de técnicas formales a lo largo de todo el proceso de desarrollo.
–Minimización de las variaciones entre productos.
– Verificación y pruebas formales en las diferentes etapas del desarrollo.
– Control de la documentación.
– Correcto mantenimiento y servicios de post-venta.


CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE

La calidad está presente en todas las etapas del proceso de desarrollo de los productos de software. A grandes rasgos:

 Calidad en el diseño. Se basa en definir un listado de especificaciones a seguir; involucra la descripción de los procesos de desarrollo, tareas y responsabilidades de los equipos de desarrollo; dichos procesos pueden estar estandarizados.

 Calidad en la implementación. Se enfoca al grado de cumplimiento de los requerimientos de diseño. Si los requerimientos está bien definidos y especificados, el cumplimiento de la calidad en esta fase no debe tornarse difícil.

• Calidad en la satisfacción. Es la medida de calidad apreciada por los usuarios finales de los productos de software. No puede esperarse calidad en esta fase si no hubo preocupación por ella en las etapas anteriores.

MÉTRICAS DE CALIDAD

Métricas para determinar los factores de calidad:

· Facilidad de auditoria.
· Exactitud.
· Normalización de las comunicaciones.
· Completitud.
· Concisión.
· Consistencia.
· Estandarización de los datos.
· Tolerancia de errores.
· Eficiencia de la ejecución.
· Facilidad de expansión.
· Generalidad.
· Independencia del hardware.
· Instrumentación.
· Modularidad.
· Facilidad de operación.
· Seguridad.
· Autodocumentación.
· Simplicidad.
· Independencia del sistema software.
· Facilidad de traza.
· Formación.



MODELOS CONOCIDOS
  • MODELO DE McCALL (1977)
Los factores que afectan la calidad del software se pueden categorizar en dos amplios grupos:
   (1) Factores que se pueden medir directamente (por ejemplo, defectos por punto de función) 
   (2) Factores que se pueden medir sólo indirectamente (por ejemplo, facilidad de uso o de mantenimiento).

En todos los casos debe aparecer la medición. Debemos comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad.

Factores de calidad de McCall y colegas (1997)


Refiriéndose a los factores anotados en la figura anterior, McCall proporciona las siguientes descripciones:

Operación del Producto
  • Corrección. Hasta dónde satisface un programa su especificación y logra los objetivos propuestos por el cliente.
  • Fiabilidad. Hasta dónde se puede esperar que un programa lleve a cabo su función con la exactitud requerida. 
  • Eficiencia. La cantidad de recursos informáticos y de código necesarios para que un programa realice su función.
  • Integridad. Hasta dónde se puede controlar el acceso al software o a los datos por personas no autorizadas.
  • Usabilidad (facilidad de manejo). El esfuerzo necesario para aprender a operar con el sistema, preparar los datos de entrada e interpretar las salidas (resultados) de un programa.
Revisión del Producto
  • Facilidad de mantenimiento. El esfuerzo necesario para localizar y arreglar un error en un programa. (Esta es una definición muy limitada).
  • Flexibilidad. El esfuerzo necesario para modificar un programa que ya está en funcionamiento.
  • Facilidad de prueba. El esfuerzo necesario para probar un programa y asegurarse de que realiza correctamente su función.
Transición del Producto
  • Portabilidad. El esfuerzo necesario para transferir el programa de un entorno hardware/software a otro entorno diferente.
  • Reusabilidad (capacidad de reutilización). Hasta dónde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones, en relación al empaquetamiento y alcance de las funciones que realiza el programa.
  • Interoperatividad. El esfuerzo necesario para acoplar un sistema con otro.
Es difícil, y en algunos casos imposible, desarrollar medidas directas de los factores de calidad anteriores.
Por tanto, se definen y emplean un conjunto de métricas para desarrollar expresiones para todos los factores, de acuerdo con la siguiente relación:
F = cI x mI -E c2 x m2 +....+ c, x m,
donde:

                                                     F es un factor de calidad del software, 
                                                     c son coeficienles de regresión 
                                                     m son las métricas que afectan al factor de calidad. 

  • Desgraciadamente, muchas de las métricas definidas por McCall pueden medirse solamente de manera subjetiva. 
  • Las métricas pueden ir en forma de lista de comprobación que se emplea para «puntuar» atributos específicos del software.
  • El esquema de puntuación propuesto por McCall es una escala del O (bajo) al 10 (alto).

Métrica para el esquema de puntuación
  • Facilidad de auditoría. La facilidad con la que se puede comprobar el cumplimiento de los estándares.
  • Exactitud. La exactitud de los cálculos y del control.
  • Estandarización de comunicaciones. El grado de empleo de estándares de interfaces, protocolos y anchos de banda.
  • Complección. El grado con que se ha logrado la implementación total de una función.
  • Concisión. Lo compacto que es el programa en términos de líneas de código.
  • Consistencia. El empleo de un diseño uniforme y de técnicas de documentación a lo largo del proyecto de desarrollo del software.
  • Estandarización de datos. El empleo de estructuras y tipos de datos estándares a lo largo del programa.
  • Tolerancia al error. El daño causado cuando un programa encuentra un error.
  • Eficiencia de ejecución. El rendimiento del funcionamiento de un programa.
  • Capacidad de expansión. El grado con que se pueden ampliar el diseño arquitectónico, de datos o procedimental.
  • Generalidad. La amplitud de aplicación potencial de los componentes del programa.
  • Independencia del hardware. El grado con que se desacopla el software del hardware donde opera.
  • Instrumentación. El grado con que el programa vigila su propio funcionamiento e identifica los errores que ocurren.
  • Modularidad. La independencia funcional de componentes de programa.
  • Operatividad. La facilidad de operación de un programa.
  • Seguridad. La disponibilidad de mecanismos que controlan o protegen los programas y los datos.
  • Autodocumentación. El grado en que el código fuente proporciona documentación significativa.
  • Simplicidad. El grado de facilidad con que se puede entender un programa.
  • Independencia del sistema software. El grado de independencia de programa respecto a las características del lenguaje de programación no estándar, características del sistema operativo y otras restricciones del entorno.
  • Trazabilidad. La capacidad de seguir una representación del diseño o un componente real del programa hasta los requisitos.
  • Formación. El grado en que ayuda el software a manejar el sistema a los nuevos usuarios.

  • MODELO DE FURPS (1987)
Hewlett-Packard ha desarrollado un conjunto de factores de calidad del software al que se le ha  dado el acrónimo de FURPS: funcionalidad, facilidad de uso, fiabilidad, rendimiento y capacidad de soporte.
Los factores de calidad FURPS provienen de trabajos anteriores, definiendo los siguientes atributos para cada uno de los cinco factores principales:

Funcionalidad. se valora evaluando el conjunto de características y capacidades del programa, la generalidad de las funciones entregadas y la seguridad del sistema global.
Facilidad de uso. se valora considerando factores humanos, la estética, la consistencia y la documentación general.
Fiabilidad. se evalúa midiendo la frecuencia y gravedad de los fallos, la exactitud de las salidas (resultados),
el tiempo de medio de fallos (TMDF), la capacidad de recuperación de un fallo y la capacidad de predicción del programa.
Rendimiento. se mide por la velocidad de procesamiento, el tiempo de respuesta, consumo de recursos, rendimiento efectivo total y eficacia.
Capacidad de soporte. combina la capacidad de ampliar el programa (extensibilidad), adaptabilidad y servicios (estos tres atributos representan un término más común -mantenimiento-), así como capacidad de hacer pruebas, compatibilidad, capacidad de configuración, la facilidad de instalación de un sistema y la facilidad con que se pueden localizar los problemas.


  • MODELO DE DROMEY (1996)

Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo documentos de requerimientos, guías de usuarios, diseños, y código).

Sugiere el uso de cuatro categorías que implican propiedades de calidad, que son: correctitud, internas, contextuales y descriptivas.




  • NORMAS ISO 9000 - ISO 9126
El estándar identifica seis atributos clave de calidad:
  • Funcionalidad. El grado en que el software satisface las necesidades indicadas por los siguientes subatributos: idoneidad, corrección, interoperatividad, conformidad y seguridad.
  • Confiabilidad. Cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes subatributos: madurez, tolerancia a fallos y facilidad de recuperación.
  • Usabilidad. Grado en que el software es fácil de usar. Viene reflejado por los siguientes subatributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.
  • Eficiencia. Grado en que el software hace Óptimo el uso de los recursos del sistema. Está indicado por los siguientes subatributos: tiempo de uso y recursos utilizados.
  • Facilidad de mantenimiento. La facilidad con que una modificación puede ser realizada. Está indicada por los siguientes subatributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.
  • Portabilidad. La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes subatributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio.



  • MOSCA (Modelo Sistemático de Calidad)
Consta de 4 niveles: dimensiones, categorías, características y las métricas. En base de tres ramas: el producto, el proceso y la humana. Contiene un total de 715 métricas.









2 de noviembre de 2012

Métricas Técnicas del Software

Definiciones:

  • Medida: Proporciona una indicación cuantitativa de la cantidad, dimensiones o tamaño de algunos  atributos de un producto.
  • Medición: Acto de determinar una medida.
  • Métrica: Es una medida del grado en que un sistema, componente o proceso posee un atributo dado.
                      
                      Métricas de Software

Las métricas del Software comprenden   un amplio rango de actividades diversas, estas son algunas:

        
        ‣ Aseguramiento y control de calidad

        ‣ Modelos de fiabilidad

        ‣ Modelos y evaluación de ejecución

        ‣ Modelos y medidas de productividad







PROCESO DE RECOPILACIÓN DE MÉTRICAS DE SOFTWARE



CLASIFICACIÓN DE LAS MÉTRICAS DE SOFTWARE


Según los criterios:



Según el contexto en que se aplican:

Métricas de proceso
  • Se recopilan de todos los proyectos, y durante un largo periodo de tiempo.
  • Caracterizados por: control y ejecución del proyecto y medición de tiempos de las fases.
Métricas de proyecto
  • Permiten evaluar el estado del proyecto.
  • Permiten seguir la pista de los riesgos.
Métricas de producto
  • Se centran en las características del software y no en como fue producido.
  • También son productos los artefactos, documentos, modelos y componentes que conforman el software.
  • Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad y el esfuerzo.