PROCESO DE REVISIONES Y PRUEBAS DE SOFTWARE

PROCESO DE REVISIONES Y PRUEBAS DE SOFTWARE

1. Pruebas: Son un elemento crítico para la garantía de calidad del software y representa un último repaso de las especificaciones, del diseño y de la codificación.

   • Prueba de Resistencia: Son pruebas que ejecuta un sistema de forma que demande recursos de cantidad, frecuencia, volumen, memoria, búsquedas, etc.
   • Prueba de Recuperación de fallas: Es una prueba del sistema que fuerza el fallo del software en muchas formas y verifica que la recuperación se lleve a cabo apropiadamente.
   • Prueba de Aceptación: Estas pruebas aseguran a los clientes que el sistema que pidieron es el sistema que se construyó para ellos.
   • Prueba de Instalación: Estas pruebas permiten que lo usuarios ensayen las funciones del sistema y documenten todos los problemas adicionales surgidos
   • Prueba de función: Verifica que el sistema integrado realiza sus funciones especificadas en los requerimientos.
   • Prueba de rendimiento: Las pruebas están diseñadas para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado, posiblemente se requiera instrumentación tanto de hardware como con software.
   • Pruebas de unidad: Verifica cada módulo que conforma el sistema, se prueban los siguientes aspectos: interfaz, estructura de datos, condiciones límite, bifurcaciones o caminos independientes y el manejo de errores.
   • Prueba de camino básico: Es un método para ejecutar por lo menos una vez cada sentencia del programa, se basa en el manejo de grafos, y complejidad ciclomática.
   • Integración: Una vez que todos los módulos han sido probados por separados, ahora hay que ponerlos juntos, existen varias técnicas de integración entre las más conocidas esta la integración descendente y ascendente.
   • Validación: Tratan de comprobar la conformidad de los requerimientos, la portabilidad, compatibilidad, recuperación de errores, documentación, facilidad de mantenimiento, etc.
   • Seguridad: Son mecanismos de protección incorporados al sistema, lo protegen de penetraciones impropias. Se trata de hacer invulnerable al sistema desde cualquier ataque, frontal, por los flancos o retaguardia.
   • Pruebas del sistema: Son pruebas hasta cierta forma realizadas para ver qué sucede en situaciones externas al sistema, por ejemplo el hardware, el tipo de información, los fallos de energía eléctrica que puedan surgir, etc.
   • Alfa: Los usuarios finales son quienes aplican la prueba en el lugar de trabajo del desarrollador. El software se utiliza en un entorno natural mientras el desarrollador “mira sobre el hombro” de los usuarios típicos y registra los problemas de uso y errores.
   • Beta: Se aplican en el lugar de trabajo de los usuarios finales. A diferencia de las prueba alfa, por lo general el desarrollador no está. Por tanto, la prueba beta es una aplicación “en vivo” del software en un entorno que no controla el desarrollador.
   • Caja negra: Estas pruebas son a nivel de entorno, para verificar el correcto funcionamiento de acuerdo a ciertas clases de datos o valores de entrada, cuales tasas de datos y cual volumen tolera el sistema, verifican que las salidas sean las deseadas.
   • Caja blanca: Son pruebas que utilizan las estructuras de control para derivar los casos de prueba, son pruebas a nivel componente.
   • Prueba de caja gris: Es una combinación de las pruebas de caja negra y caja blanca.

2. Antecedentes históricos

   • La crisis del software: Conjunto de problemas durante el desarrollo de software para computadoras, como nula planificación, mala comunicación, errática estimación de costos, baja productividad, mala calidad, falta de confianza de los clientes, la falta de pruebas del software, etc., que llevaban a los proyectos a fracasos totales, con grandes pérdidas económicas.
   • Programadores aprendían su oficio mediante prueba y error, ya que no existían técnicas ni métodos de desarrollo de software.

3. Conceptos importantes

   • Confiabilidad: La probabilidad de que un programa opere correctamente durante un periodo de tiempo especificado, en un ambiente determinado.
   • Calidad de software: conjunto de características mensurables que debe cumplir el software, para que este realice lo que debe hacer, fácil de usar, que se entregue en presupuesto y en tiempo estimado, que el software no falle, sea rápido, etc.
   • Software: Elemento lógico, es el resultado del intelecto humano, por lo que no está libre de errores.
   • Error: Una acción humana que produce un resultado incorrecto.
   • Falla: Desviación del componente o el sistema de su prevista entrega, servicio o resultado.
   • Defecto: se encuentra en un artefacto y puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. Coincide con la definición de diccionario, "imperfección".
   • Verificación: Proceso de determinar si los productos de una cierta fase del desarrollo de software cumplen o no los requisitos establecidos durante la fase anterior.
   • Validación: Proceso de evaluación del software al final del proceso de desarrollo para asegurar el cumplimiento de las necesidades del cliente.
   • Certificación: Relaciona una serie de factores que debe cumplir un producto para otorgarle ese término.
   • Reutilización: Es la habilidad de los elementos de software para servir en la construcción de muchas aplicaciones diferentes.
   • Compatibilidad: Es la facilidad para combinar un elemento de software con otro
   • ¿Qué es validación y verificación del software? tiene como propósito ayudar a las organizaciones de desarrollo a construir software de calidad durante el ciclo de vida del software. Determinar si los procesos y productos de software, satisfacen plenamente las necesidades de uso y del usuario según los requerimientos especificados.

4. Técnicas de evaluación

   • Estática: Modo de evaluación de artefactos para las primeras fases del proceso de desarrollo (requerimientos, análisis y diseño), cuando no existe código. pláticas estructuradas, inspecciones, auditorías, revisiones entre pares o colegas.
   • Dinámica: Únicamente puede dar comienzo cuando finaliza la actividad de codificación, son todas las pruebas que se realizan con el código presente.

5. Ciclo de vida

   • Concepción: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos
   • Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos
   • Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y el manual de usuario
   • Transición: se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.

6. Método-V

   • Objetivos: Minimización de los riesgos del proyecto, mejora y garantía de calidad, reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida, mejora de la comunicación entre todos los inversionistas.

7. Modelo Incremental

   • Etapas: 1. Definición de requerimientos 2. Asignar los requerimientos a los incrementos. 3. Diseño del incremento a partir de los requirimientos. 4. Desarrollo del incremento. 5. Validar incrementos. 6. Integrar incrementos. 7. Validar funcionamiento.

8. Principios de desarrollo

   • Adaptar el proceso: El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico.
   • Balancear prioridades: Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.
   • Colaboración entre equipos: El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
   • Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto.
   • Elevar el nivel de abstracción: Es conveniente realizar el software empleando o creando herramientas reusables, que no sirvan sólo para el proyecto actual sino también para proyectos futuros.
   • Enfocarse en la calidad El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción

9. Consideraciones de integración para un sistema de tiempo real

   • Procesador: Utilizarse procesadores lo más predecibles posibles, sin caché, sin paginación, sin predicción de saltos, etc.
   • Sistema Operativo: Guiado por eventos sólo cambia de tarea cuando un evento necesita el servicio. Compartición de tiempo cambia de tareas por interrupciones del reloj y por eventos
   • Programación: Una tarea tiene tres estados: ejecución, preparada y bloqueada. La mayoría de las tareas están bloqueadas casi todo el tiempo.
   • Bases de datos de tiempo real: Las bases de datos distribuidas constituyen el método preferido en los sistemas de tiempo real, debido a que la multitarea es muy común
   • Comunicación entre tareas: Las diferentes tareas de un sistema no pueden utilizar los mismos datos o componentes físicos al mismo tiempo.
   • Interrupciones: Las interrupciones son la forma más común de pasar información desde el mundo exterior al programa y son, por naturaleza, impredecibles.
   • Memoria: Hay dos problemas con el reparto de la memoria en SOTR (sistemas operativos en tiempo real).
   • Comunicaciones: Para las comunicaciones se suelen usar redes CAN_bus, ya que las redes más usuales, como Ethernet son indeterministas y no pueden garantizarnos el tiempo de respuesta.

10. Características de los sistemas de tiempo real

    • Determinismo
    • Responsividad
    • Usuarios controladores
    • Confiabilidad
    • Operación a prueba de fallas duras
    • Pruebas de tareas
    • Prueba de comportamiento.
    • Pruebas intertareas.