Estrategias de Prueba del Software

Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.

Las características generales son:

• La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.
• En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
• La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
• La prueba y la depuración son actividades diferentes.
• Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.

Más concretamente, los objetivos de la estrategia de prueba son:

• Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
• Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
• Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.

Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:

• Planificación de las pruebas.
• Diseño de las pruebas.
• Implementación de las pruebas.
• Ejecución de las pruebas.
• Evaluación de las pruebas.

Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:

•  Plan de Pruebas.
•  Casos de Prueba.
•  Informe de evaluación de Pruebas.
•  Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.

Los participantes responsables de las realizar las actividades y los productos de desarrollo del software son:

• Diseñador de pruebas: Es responsable de la planificación, diseño, implementación y evaluación de las pruebas. Esto conlleva generar el plan de pruebas y modelo de pruebas, implementar los casos de prueba y evaluar los resultados de las pruebas. Los diseñadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparación y evaluación de las mismas.
• Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integración y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecución, recuperar los errores y garantizar los resultados de las pruebas.

Durante la fase de Inicio puede hacerse parte de la planificación inicial de las pruebas cuando se define el ámbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre todo cuando un producto de desarrollo software es sometido a pruebas de integración y de sistema. Esto quiere decir que la realización de pruebas se centra en las fases de elaboración, cuando se prueba la línea base ejecutable de la arquitectura, y de construcción, cuando el grueso del sistema está implementado. Durante la fase de Transición el centro se desplaza hacia la corrección de defectos durante los primeros usos y a las pruebas de regresión.

Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cómo probar los primeros productos de desarrollo software pueden ser utilizadas también como casos de prueba de regresión que especifican cómo llevar a cabo las pruebas de regresión sobre los productos de desarrollo software siguientes. El número de pruebas de regresión necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las últimas iteraciones requerirán un gran esfuerzo en pruebas de regresión. Es natural, por tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, aunque el modelo de pruebas cambia constantemente debido a:

• La eliminación de casos de prueba obsoletos.
• El refinamiento de algunos casos de prueba en casos de prueba de regresión.
• La creación de nuevos casos de prueba para cada nuevo producto de desarrollo de software.

La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.

Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.

“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores".

Pruebas del Software

Las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.

Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pueden costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos.

Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. 

Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores.

Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.

OBJETIVOS DE LAS PRUEBAS

• La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
• Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
• Una prueba tiene éxito si descubre un error no detectado hasta entonces.
• Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.

Nos quitan la idea que, normalmente, tenemos de que una prueba tiene éxito si no descubre errores

PRINCIPIOS DE LAS PRUEBAS

Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.

A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos.

Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.

El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente.

Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero.

No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.

Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Por «mas eficaces» queremos referirnos a pruebas con la más alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las razones que se expusieron anteriormente, el ingeniero del software que creó el sistema no es el más adecuado para llevar a cabo las pruebas para el software.

FACILIDAD DE PRUEBA

En circunstancias ideales, un ingeniero del software diseña un programa de computadora, un sistema o un producto con la «facilidad de prueba» en mente. Esto permite a los encargados de las pruebas diseñar casos de prueba más fácilmente. Pero, ¿qué es la facilidad de prueba?

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos.

Existen, de hecho, métricas que podrían usarse para medir la facilidad de prueba en la mayoría de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. También es empleada por los militares para indicar lo fácil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que «facilidad de prueba del software». La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.

Operatividad

«Cuanto mejor funcione, más eficientemente se puede probar.»

• El sistema tiene pocos errores (los errores añaden sobrecarga de análisis y de generación de informes al proceso de prueba).
• Ningún error bloquea la ejecución de las pruebas.
• El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).

Observabilidad

«Lo que ves es lo que pruebas.».

• Se genera una salida distinta para cada entrada.
• Los estados y variables del sistema están visibles o se pueden consultar durante la ejecución.
• Los estados y variables anteriores del sistema están visibles o se pueden consultar (por ejemplo, registros de transacción).
• Todos los factores que afectan a los resultados están visibles.
• Un resultado incorrecto se identifica fácilmente.
• Los errores internos se detectan automáticamente a través de mecanismos de auto-comprobación.
• Se informa automáticamente de los errores internos.
• El código fuente es accesible.

Controlabilidad

«Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.»

• Todos los resultados posibles se pueden generar a través de alguna combinación de entrada.
• Todo el código es ejecutable a través de alguna combinación de entrada.
• El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software.
• Los formatos de las entradas y los resultados son consistentes y estructurados.
• Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.

Capacidad de Descomposición

«Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. »

• El sistema software está construido con módulos independientes.
• Los módulos del software se pueden probar independientemente.

Simplicidad

«Cuanto menos haya que probar, más rápidamente podremos probarlo.»

• Simplicidad funcional (por ejemplo, el conjunto de características es el mínimo necesario para cumplir los requisitos).
• Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos).
• Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento).

Estabilidad

«Cuanto menos cambios, menos interrupciones a las pruebas.»

• Los cambios del software son infrecuentes.
• Los cambios del software están controlados.
• Los cambios del software no invalidan las pruebas existentes.
• El software se recupera bien de los fallos.

Métricas de Software OO

Gestión de la Configuración del Software

El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores.

La gestión de configuración del software (GCS) es una actividad de autoprotección que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aquellos que puedan estar interesados.

Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina sólo cuando el software queda fuera de la circulación.

El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías: (1) programas de computadora (tanto en forma de código fuente como ejecutable), (2) documentos que describen los programas de computadora (tanto técnicos como de usuario) y (3) datos (contenidos en el programa o externos a él). Los elementos que componen toda la información producida como parte del proceso de ingeniería del software se denominan colectivamente configuración del software.

A medida que progresa el proceso del software, el número de elementos de configuración del software

(ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía de información. Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable -el cambio-. El cambio se puede producir en cualquier momento y por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [BERSO] establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.

¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios:

Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales;

Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora;

Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software;

Restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto.

La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.

La gestión de configuración del software es un elemento importante de garantía de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS también es responsable de la identificación de ECSs individuales y de las distintas versiones del software, de las auditorias de la configuración del software para asegurar que se desarrollan adecuadamente y de la generación de informes sobre todos los cambios realizados en la configuración.

Cuando se construye software los cambios son inevitables

• Los cambios aumentan el nivel de confusión en el equipo de desarrollo
• Confusión debida a:
                                  - No se han analizado los cambios antes de realizarlos.
                                  - No se han registrado antes de implementarlos.
                                  - No se les ha comunicado a aquellas personas que necesitan saberlo.
                                  - No se han controlado de manera que mejoren la calidad y reduzcan los errores.

• La Gestión de la Configuración Software (GCS) es una actividad de protección que  gestiona el cambio a lo largo del ciclo de vida del software

• El cambio se puede producir en cualquier momento
• Por tanto, las actividades de GCS son:
                                                             - Identificar el cambio.
                                                             - Controlar el cambio.
                                                             - Garantizar la correcta implementación del cambio.
                                                             - Informar del cambio a todos aquellos que lo necesiten.


Elementos de Configuración

• El software es el resultado del proceso de IS:
                                                                       - Programas.
                                                                       - Datos.
                                                                       - Documentos.

• Los elementos que componen toda la información generada como parte del proceso de IS se denominan colectivamente configuración del software

• A medida que progresa el proceso de IS el número de Elementos de Configuración Software (ECS) crece rápidamente

• e.g. la SRS produce un plan del proyecto y un diseño que a su vez produce código.

• Los ECS producen otros ECSs para crear una jerarquía de información

• Si simplemente tuviéramos esta jerarquía no habría confusión
• La confusión surge cuando entra en juego el cambio
• Éste puede producirse en cualquier momento y por cualquier razón
• Las fuentes fundamentales del cambio son:
      - Fallos.
      - Nuevos negocios o condiciones comerciales que dictan cambios en los requisitos del producto.
      - Nuevas necesidades del cliente que demandan la modificación de los datos, funciones o servicios.
      - Reorganización y/o reducción del volumen comercial que provoca cambios en el proyecto.
      - Restricciones presupuestarias o de planificación que provocan una redefinición del producto.


Línea Base

Es una configuración de referencia en el proceso de desarrollo del software a partir de la cual las revisiones se han de realizar de manera formal, con el objetivo de controlar los cambios en el software, sin impedir llevar a cabo aquellos que sean justificados, Se definen al comienzo del proyecto, coincidiendo con los hitos marcados y generalmente se corresponden con los resultados de las fases.

• Los cambios por tanto pueden ser necesarios y están justificados

• Una línea base es un concepto de GCS que nos ayuda a controlar los cambios sin perjuicio de aquellos que sean necesarios

• El IEEE define una línea base como una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios

• Antes de que un ECS se convierta en línea base el cambio puede llevarse a cabo de manera rápida e informal

• Sin embargo, una vez que se ha establecido una línea base solo se pueden efectuar los cambios si se aplica un procedimiento  formal para evaluarlos y verificarlos

• El concepto de línea base es similar al de una boda...

• Durante la preparación del evento se pueden cambiar fechas, horas y lugares...... pero una vez mandadas las invitaciones los cambios no son tan sencillos.

• El el contexto de IS definimos una línea base como un punto de referencia en el  desarrollo del software que queda marcado  por el envío de uno o más elementos de  configuración del software y la aprobación  del ECS obtenido mediante una RTF.

Proceso de Generación de Línea Base

• ECSs que forman un conjunto de líneas base:
                                                                       - Plan del proyecto del software.
                                                                       - SRS.
                                                                       - Diseño.
                                                                       - Código.
                                                                       - Casos de prueba.
                                                                       - Manual preliminar de usuario.

                                                                       - Manuales de operación e instalación.
                                                                       - Manual de usuario.
                                                                       - Documentos de mantenimiento.
                                                                       - Estándares y procedimientos de IS.
• Además de estos ECSs pueden inmovilizarse las herramientas de software (e.g., editores, compiladores, herramientas CASE, etc.)


Actividades de GCS

• La GCS es una actividad de protección que  puede considerarse dentro de la SQA
• Aunque su actividad fundamental es el control del cambio también se encarga de otras actividades
• Cualquier GCS debe tener claro:
              - Cómo identificar y gestionar las versiones de un programa para permitir modificaciones.
              - Cómo controlar los cambios antes y después de distribuir el software al cliente.
              - Quién es el responsable de aprobar y de asignar prioridades a los cambios.
              - Como podemos garantizar que los cambios se han llevado a cabo adecuadamente.
              - Qué mecanismos se usan para avisar a otros de los cambios realizados.

• Actividades de GCS:
              - Identificación de ECSs.
              - Control de versiones.
              - Control de cambios.
              - Auditoria de la configuración.
              - Informes de estado.

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.

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:

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.»

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.