Unidad 6: Validación y logística de pruebas

6.1 Pruebas y aceptación del cliente

6.2 Entrega de proceso de pruebas.

6.3 Formalización y cierre del proyecto.

6.4 Monitoreo y seguimiento del proyecto.

6.5 Formalización de cambios.

6.6 Administración de defectos.

6.1 Pruebas y aceptación del cliente

“Una PA tiene como propósito demostrar al cliente el cumplimiento de un requisito del software” Describe un escenario (secuencia de pasos) de ejecución o uso del sistema desde la perspectiva del cliente Puede estar asociada a requisitos funcionales o no funcionales Un requisito tiene una o más PAs asociadas Las PAs cubren desde escenarios típicos/frecuentes hasta los más excepcionales

Aprovechamiento de las Pas

Adicional a su propósito fundamental, las PAs pueden rentabilizarse usándose para: Obligar a definir requisitos que sean verificables Valorar adecuadamente el esfuerzo asociado a la incorporación de un requisito Negociar con el cliente el alcance del sistema Planificar el desarrollo iterativo e incremental del sistema Guiar a los desarrolladores Identificar oportunidades de reutilización

Requisitos versus Pruebas de Aceptación

“El proceso de desarrollo debe estar dirigido por los requisitos”. Obvio puesto que los requisitos son el objetivo a cumplir, sin embargo, …

•         ¿Popularmente cómo se especifican los requisitos?

•         Textualmente

•         UML (Diagramas de Casos de Uso y otros diagramas)

•         Plantillas o fichas

•         Interfaces de usuario (bocetos)combinación de los anteriores

Ejemplo:

Identificación de Pruebas de Aceptación

•         Reintegro usando cantidades predefinidas

•         Reintegro con cantidad introducida por cliente

•         Intento reintegro saldo < cantidad

•         Cancelación de operación

•         No disponibilidad de billetes

•         No disponibilidad de papel para recibo

•         Intento reintegro saldo < cantidad con cliente preferencial

•         Excedido tiempo de comunicación con sistema central

•         Excedido tiempo de espera para introducción de acción

6.2 Entrega de proceso de pruebas.

Proceso mediante el cual se aplican una serie de métodos, algunas veces utilizando herramientas, que permiten obtener una conjunto de medidas para verificar y validar el funcionamiento requerido del software.

Consta de las siguientes actividades:

•         Planificación y Control

•         Análisis y Diseño

•         Implementación y Ejecución

•         Evaluación de los criterios de salida e informes

•         Actividades de Cierre

6.3 Formalización y cierre del proyecto.

La fase de cierre se inicia cuando se completa la ejecución del proyecto y el cliente acepta el resultado. El propósito de realizar un cierre formal, adicionalmente a ser un escenario de verificación de cumplimiento de objetivos y criterios de éxito, es aprender de la experiencia ganada en el mismo, con el fin de mejorar el desempeño en el futuro.

El proceso de cierre de proyecto o fase también establece el procedimiento para investigar y documentar las razones para las acciones tomadas, si es que un proyecto es terminado antes de su finalización.

El entregable de cierre de proyecto debe ser generado por el líder del proyecto al final del proyecto, para registrar y hacer una revisión de lo que ocurrió durante su ejecución y decidir cómo maximizar el valor del proyecto.

El documento debe derivarse teniendo como referencia los entregables Plan de Proyecto, Plan de Calidad y Plan de Riesgos, de manera conjunta con la formalización de cambios aprobados.

El documento debe ser revisado en la reunión de cierre de proyecto y las recomendaciones de la reunión, conjuntamente con el documento de cierre deben ser presentados al comité del proyecto, financiador del proyecto o cliente para permitir entonces que formalmente el proyecto sea cerrado (el entregable por supuesto tendrá las firmas de aprobación).

Entregables Establecer los entregables tal como fueron relacionados en los planes de proyecto y calidad y su estado final (completado, abandonado, pospuesto, cerrado). A manera de ejemplo se refleja una sección de la tabla en mención incluida en el entregable de un proyecto real.

Cambios de alcance aprobados durante el curso del proyecto Relacionar los cambios de alcance aprobados durante el curso del proyecto y describir su impacto sobre el proyecto. Las actas de su aprobación (comité de cambios) pueden ser un anexo del entregable de cierre.

Actividades de control de calidad Debe incluirse una tabla resumen de las actividades de control de calidad asociadas a cada entregable en el plan de calidad y para cada una establecer si fueron llevadas a cabo y una breve descripción del beneficio. A manera de ejemplo se refleja una sección de la tabla en mención incluida en el entregable de un proyecto real (note que en el plan de calidad aparece una tabal por cada entregable, aquí solo se incluye una única tabla con todos los entregables).

Ejecución de las actividades del programa En forma breve debe exponerse como fue el cumplimiento del programa con respecto a lo planeado. Para aquellas actividades del plan que presenten varianzas significativas, debe explicarse razón, plan de choque que se realizó y efecto sobre el proyecto de manera general. Un buen nivel de síntesis es una tabla que incluya actividades principales, fecha planeada, fecha real y explicación de varianzas con el alcance aquí expresado.

Ejecución del presupuesto Al igual que en caso anterior, en forma breve debe exponerse como fue la ejecución del presupuesto con respecto a lo planeado. Para aquellas actividades o rubros del plan que presentaron varianzas significativas, debe explicarse con suficiente nivel de detalle las razones de tales varianzas. Un buen nivel de síntesis es una tabla que incluya actividades/rubro, valor presupuestado, valor ejecutado y explicación de varianzas con el nivel de cobertura aquí expuesto.

 Si el proyecto impactó la prestación del servicio, debe explicarse en qué forma fue impactado y qué manejo se realizó del impacto.

Evolución de supuestos y riesgos Relacionar los supuestos consignados en el Plan de Proyecto y establecer si fueron correctos y cómo fueron manejados.

Relacionar del documento de Plan de Riesgos solamente aquellos riesgos que terminaron impactando el proyecto y como fue manejado su impacto (en teoría si las medidas de contingencia estuvieron suficientemente estudiadas, tendría que ser lo realizado).

Acuerdos para soporte y evolución Brevemente describir los acuerdos para el soporte en curso, referenciando cuando sea necesario un acuerdo de nivel de servicio (service level agreement) y el resultado del traspaso a los usuarios y la organización de prestación de servicios.

Reconciliación del presupuesto del proyecto Explicar el estado de las cuentas del proyecto, describiendo cuando sea necesario acuerdos sobre la gestión de operaciones pendientes, tales como previsiones para trabajo residual o la aprobación de facturas pendientes.

Lecciones aprendidas del proyecto Explicar qué lecciones han sido aprendidas de este proyecto y cómo pueden ser comunicadas y aplicadas. Conocimiento que es legado de este proyecto a la organización.

Acciones y responsables Acciones que deban ser llevadas a cabo, responsables de su cumplimiento y fecha planeada de terminación: Completar entregables. Hacer frente a las cuentas del proyecto. Asegurar que los beneficios completos del proyecto sean alcanzados. Comunicar y aplicar las lecciones aprendidas.

6.4 Monitoreo y seguimiento del proyecto.

El monitoreo es considerado una tarea compleja, que requiere de una alta inversión de recursos y tiempo.

El monitoreo no tiene mayor utilidad para el proceso de gestión. Es un requisito que se debe llenar, ya que lo plantea el cooperante. (“No” es una herramienta estratégica de gestión).

Claves fundamentales

Ajustar la estructura del sistema de monitoreo a las necesidades del proyecto.

Tener clara la función que debe cumplir el sistema de monitoreo.

Seguimiento o Monitoreo Algunas funciones: El sistema de monitoreo puede ser:

•         Un instrumento de gestión, que apoya a los responsables del proyecto a conocer el actual estado del mismo y orientar su trabajo hacia los resultados pretendido, mejorando de esta manera el desempeño del proyecto.

Seguimiento o Monitoreo Algunas funciones:

•         Un proceso organizado de comunicación y entendimiento entre los diferentes participantes (Grado de objetividad). q Un instrumento para fomentar la co-responsabilidad de diversos actores. El monitoreo aumenta el compromiso y facilita la coordinación.

•         Un instrumento de desarrollo organizacional, con el que se inicia un proceso de aprendizaje y desarrollo.

•         “El monitoreo es un procedimiento sistemático empleado para comprobar la efectividad y eficiencia del proceso de ejecución de un proyecto, para identificar logros y debilidades y recomendar medidas correctivas para optimizar los resultados deseados”.

6.5 Formalización de cambios.

´        Es la parte de la Gestión de la Configuración del Software que se encarga de controlar cualquier modificación, tanto de características como del comportamiento, del sistema.

´        El control de cambios proporciona mecanismos para gestionar la modificación del sistema, normalmente combinando procedimientos humanos con el uso de herramientas automáticas (SVS, PlasticSCM, SourceSafe…)

´        Existen diferentes niveles en la gestión de los cambios dependiendo del ECS que se quiera modificar:

´        Informal: si el ECS no forma parte de la Línea de Base (LB).

´        Semiforme: cuando el ECS en cuestión no forma parte de la LB, pero su cambio afecta a ECS que sí la conforman.

´        Formal: cuando el ECS forma parte de la LB.

6.6 Administración de defectos.

LOS PASOS PARA ENCONTRAR DEFECTOS

Hay varias formas para encontrar defectos en un programa, pero en esencia tienen los siguientes pasos:

1. Identificación de los síntomas del defecto.

2. Deducir de esos síntomas la localización del defecto.

3. Entender lo que es erróneo en el programa.

4. Decidir cómo corregir el defecto.

5. Hacer la corrección.

6. Verificar que se ha resuelto el problema.

El compilador es una de las herramientas que ayudan a detectar errores aunque no de forma completa, pueden evitar un 90% de errores sintácticos y algunos lógicos.

Otra herramienta es por medio de las pruebas, estas dependen de los casos planteados y de sus condiciones. Además las p ruebas siguen obligando a moverse desde los síntomas al problema, y sólo verifican las condiciones probadas.

Un tercer método es la entrega del programa al usuario y que éste informe de los errores que identifique. La forma más efectiva de encontrar y corregir defectos es la revisión personal del código fuente del programa.

Para hacer la revisión de código se estudia el código fuente a partir de un listado, antes de compilarlo o probarlo. Tras hacer el diseño o la codificación es más fácil recordar la intención que se tiene, simplificando la corrección del problema.

La revisión de código consume tiempo, pero su eficiencia es mayor que las pruebas, ya que se detectan los problemas y no los síntomas. En el momento de revisión del código se piensa sobre lo que el programa debe hacer.

Las desventajas principales de las revisiones son que consumen tiempo y la dificultad de hacerlas correctamente, sin embargo la capacidad de revisión mejora con la práctica.

La razón más importante para revisar los programas antes de compilarlos y probarlos es la dificultad de convertir en un producto de calidad un programa que ha sido varias veces parcheado