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.