Estrategias de Verificación en Desarrollo de Software: Pruebas, Trazabilidad y Modelo COCOMO

Pruebas de Software

Las pruebas tienen la finalidad de verificar que la solución planteada satisfaga los requerimientos. Además, comprueban la calidad de la solución.

Documentos de Apoyo para el Plan de Pruebas

Los documentos en que se apoya el plan de pruebas son:

  • Especificación de requisitos.
  • Documentos de casos de uso.
  • Modelo de diseño e implementación.

Estos conforman los documentos del plan de pruebas.

Tipos de Pruebas

Pruebas Funcionales y de Usuario

  • Pruebas de aceptación de usuarios: Se revisa la funcionalidad que se implementará de acuerdo al rol del usuario, así como la aceptación de la interfaz de usuario y que, además, cumplan estándares de presentación.
  • Prueba de regresión: Al hacer cambios en un módulo, se deben hacer nuevamente pruebas a todo el módulo con el fin de validar su completa funcionalidad.
  • Pruebas de función: Comprueba la funcionalidad del sistema usando una serie de procesos o casos de uso que lleven al resultado esperado.
  • Pruebas del ciclo de negocio: Verifica el resultado obtenido desde el inicio hasta el fin del ciclo de negocio, mediante pruebas y simulación de todo el ciclo.
  • Pruebas de interfaz de usuario: Asegura la facilidad de manejo de la interfaz, navegando con casos de uso y verificando que sean comprensibles por los usuarios.

Pruebas No Funcionales y Técnicas

  • Pruebas de manejo de requerimientos: Valida el cumplimiento de estos.
  • Pruebas de manejo de errores: Valida la forma en cómo se controlan los errores.
  • Pruebas en paralelo: Compara el comportamiento y funcionalidad de la solución planteada versus el sistema anterior.
  • Prueba de integridad de base de datos: Verifica la calidad de los datos, mediante inspección de cada base de datos en cada sistema, para evitar incongruencias.
  • Pruebas de desempeño: Facilita el uso adecuado de recursos mediante indicadores para que no presenten demoras.
  • Pruebas de carga: Asegura la disponibilidad del sistema, usando cantidades esperadas de usuarios para que el sistema esté en línea y no tenga problemas.
  • Pruebas de estrés: Determina el límite máximo de clientes que puede procesar, doblando cada vez la carga para permitir reaccionar adecuadamente.
  • Pruebas de volumen: Verifica que la aplicación funciona adecuadamente, determinando la cantidad y carga máxima de datos que puede manejar.
  • Pruebas de seguridad y control de acceso: Asegura que la información no sea accedida por personal no autorizado.
  • Pruebas de tolerancia a fallas: Acepta fallos dentro de parámetros fijados para cada proceso.
  • Pruebas de configuración: Evalúa las validaciones de la aplicación, cambiando valores de configuración.
  • Pruebas de instalación: Determina los requisitos mínimos de software y hardware para la correcta ejecución del programa.

Matrices de Trazabilidad

Es preferible, junto al plan de pruebas, confeccionar una planilla electrónica llamada matriz de trazabilidad de pruebas, en la que se coloca, por cada caso, información detallada:

  • ID caso de prueba
  • Nombre de caso de prueba
  • Aplicación
  • Módulo
  • Versión
  • Prioridad
  • Tipo de prueba
  • Descripción caso de prueba
  • Criterios de aceptación
  • ID req. asociado a caso de prueba
  • Descripción req. asociado caso de prueba
  • Objetivo de caso de prueba
  • Nº paso
  • Descripción del paso
  • Resultados esperados
  • Condiciones de entrada
  • Medio de validación
  • Estado
  • Fecha final
  • Documentación relacionada
  • Ejecutar (Sí/No)

Modelo COCOMO (Constructive Cost Model)

COCOMO es un modelo para la estimación de costos de desarrollo de software. Incluye 3 submodelos de nivel de detalle cada vez mayor.

Características Principales

  • Basado en modelos de estimaciones matemáticas.
  • Orientado al producto final, no a las fases intermedias.
  • Se basa en la cantidad de líneas de código (LOC) del proyecto.

Inconvenientes

  • No considera el impacto de los comentarios en las líneas de código.
  • Las estimaciones sobre el número de líneas son variables.
  • No se da importancia a la productividad referente a hábitos de trabajo.
  • Dificultad para contemplar costos de revisiones, reuniones, etc.

Submodelos COCOMO

  • Modelo Básico: Calcula el esfuerzo y costo de desarrollo en función del tamaño del programa estimado en LOC. Obtiene una aproximación rápida del esfuerzo.
  • Modelo Intermedio: Calcula el esfuerzo del desarrollo en función del tamaño del programa y un conjunto de conductores de costo (cost drivers) que incluyen la evaluación subjetiva del producto, hardware, personal y atributos del proyecto. Añade al modelo básico 15 factores de ajuste.
  • Modelo Avanzado: Incorpora características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costo en cada fase del proceso de desarrollo.

Modos de Desarrollo

  • Orgánico: Proyectos pequeños y sencillos. Equipos pequeños con experiencia. Requisitos poco rígidos. (Hasta 50.000 LOC).
  • Semiacoplado (Semi-detached) / Medio: Tamaño y complejidad intermedia. Equipos con diferente experiencia. Requisitos mixtos. (Sobre 50.000 hasta 300.000 LOC).
  • Empotrado (Embedded): Proyectos con requisitos muy restringidos (interdependencia fuerte con hardware y software). (Más de 300.000 LOC).