FASE DESARROLLO

1. FASE DESARROLLO Actividad de pruebas de codificación Basado en presentación de : ANGULO SORIA KARINA AREBALO SANDOVAL ELIZABETH. JALDIN MONTAÑO DEICY. VARGAS VELÁSQUEZ FRANCISCO W.

2. Introducción: El objetivo de la prueba de software (tanto del código como de la especificación) es demostrar la presencia de errores (con el fin de conseguir su eliminación posterior) pero que no permiten demostrar su ausencia Una pruebaen concreto consiste en someter al producto de software (o a una parte del mismo) a una evaluación para conocer si se comporta de acuerdo con una especificación tomada como referencia.

3. Proceso de pruebas En general la fase de planificación de cualquier etapa de prueba requiere las siguientes actividades: 1. Designación del responsable de la etapa. 2. Identificación de los participantes en la etapa y sus roles. 3. Identificación y planificación de los recursos requeridos. 4. Estimación del tiempo y esfuerzo requerido. 5. Documentación del alcance de las pruebas. 6. Documentación de la filosofía de diseño de los casos de prueba.

4. 7. Generación disciplinada y sistemática de casos de prueba, según la filosofía adoptada. 8. Documentación de los casos de prueba. Para cada caso de prueba la documentación debe incluir: (a) Justificación de su inclusión. (b) Datos de entrada e indicaciones de cómo correr el caso. (c) Configuración requerida para la prueba. (d) Resultados esperados. (e) (En ejecución se agrega) Resultados obtenidos. (f) (En ejecución se agrega) Tipo de defecto hallado. Esto puede constar de una indicación de superada o cómo mínimo una indicación de la severidad de la falla (falla grave, seria o menor), una descripción de la falla y una identificación tentativa de la etapa del desarrollo a que se atribuye (Análisis, Diseño, Codificación, etc). 9. Criterio de culminación de las pruebas

5. El proceso de prueba de un software orientado por objetos • Consta de las siguientes etapas • Inspección del análisis (verifica si se cometieron errores o • falla en la etapa de análisis). • 2. Inspección del diseño (debe ser completo y eficiente). • 3. Inspección del código (observar el entendimiento y • facilidad del código). • 4. Pruebas unitarias (probar cada método de las clases • implementadas por separado). • 5. Pruebas de integración (probar todas las clases, verificando • que compaginen entre sí). • 6. Pruebas de validación de requerimientos (verificar que • cumple con todos los requerimientos exigidos por el cliente). • 7. Pruebas de sistema (ejecutar el programa para verificar si • cumple con los requisitos exigidos).

6. A) Una descripción de la prueba. La descripción debe indicar el propósito de la prueba (para qué se hace), el componente de software sobre el que se realiza (podría ser un módulo, subsistema o el sistema completo), los datos de prueba que se van a entregar y los resultados esperados. B) Una ejecución de la prueba. Si se dispone de una descripción ejecutable del sistema (por ejemplo, código) la ejecución de la prueba implica la ejecución de ese módulo en un entorno controlado. Posiblemente, ni el sistema final ni el resto del producto están disponibles y deberán ser simulados. Esta situación obliga a disponer de un entorno específico (conjunto de herramientas que simulen a efectos de la validación el entorno de ejecución del producto de software) para la ejecución de las pruebas.

7. C) Una valoración de los resultados obtenidos. Una vez obtenidos los resultados de la prueba, éstos deben compararse con otros considerados como referencia. En muchos casos, esta referencia es una especificación a partir de la cual se ha generado el programa. En otros casos son heurísticos que los diseñadores han seleccionado. Intuitivamente, podemos decir que cuantas más pruebas se realicen mayor será nuestra confianza en el producto. Cada prueba debe cubrir un aspecto concreto y una secuencia de pruebas nos da la cobertura del producto conseguida

8. Desde el punto de vista técnico, las pruebas se enmarcan en la revisión del diseño y del código. • Los métodos más conocidos son los siguientes: • Inspección de código. Procedimiento para la revisión por un equipo humano de la implementación de un producto software. • Así la técnica de sala limpia («cleanroom») ha demostrado • su utilidad en forma de una reducción significativa de • defectos finales. • B) Paseos por el código («walk-throughs»). Proceso menos formal que el anterior en el que participan usuarios y desarrolladores con el objetivo de descubrir y resolver omisiones e incomprensiones de lo que hace una parte del código.

9. C) Revisiones personales. Recupera la «vieja» práctica de releer cuidadosamente el código antes de compilar. Cuando se dice que un proceso de pruebas ha sido exitoso? Decimos que un caso de prueba es exitoso cuando logra poner en evidencia defectos. Esto pone en manifiesto un hecho importante acerca de la prueba: “La prueba de programas demuestra la presencia y no la ausencia de errores”.

10. Verificación y Validación V&V: Procesos de comprobación y análisis para tratar de asegurar que el software esté acorde con su especificación y cumpla las necesidades de los Clientes Un sistema de software debe ser sujeto a V&V en cada una de las etapas de su desarrollo. Por lo tanto, la V&V comienza con las revisiones de los requerimientos, y continua a través de las revisiones del diseño y del código hasta la prueba (o testing) del producto.

11. Verificación • conjunto de actividades que aseguran que el software cumple su especificación (hace lo que se supone que tiene que hacer). ¿estamos construyendo el producto correctamente? Validación • conjunto (diferente) de actividades que aseguran que el software construido se corresponde con los requisitos del cliente. ¿estamos construyendo el producto correcto?

12. Ejemplo de Verificación y Validación VyV de un programa que permite gestionar los alumnos matriculados en los cursos de una academia Verificación: • ¿las operaciones de gestión de las listas de alumnos funcionan correctamente? • ¿las operaciones de gestión de cursos funcionan correctamente? Validación: • ¿El programa proporciona todas las operaciones que el usuario necesita? • ¿Las operaciones hacen lo que el usuario espera? • ¿La interfaz con el usuario es la apropiada?

13. Para satisfacer los objetivos de V&V, existen técnicas de control estáticas y dinámicas que pueden ser aplicadas. * Las técnicas Estáticas tienen que ver con el análisis y control de las representaciones del sistema, es decir de los diferentes modelos construidos durante el proceso de desarrollo de software tales como documentos de requerimientos, diagramas de análisis, diseño, y código fuente. * Las técnicas dinámicas, también conocidas como testing (o prueba en español) se basan en ejercitar una implementación.

14. La figura muestra donde se aplican las técnicas dinámicas y estáticas durante el proceso de desarrollo de software. Las dinámicas, sin embargo, solo pueden ser usadas cuando disponemos de un prototipo o una versión ejecutable del producto

15. Prueba de métodos Principales mecanismos para la prueba de métodos: • Pruebas funcionales o de “caja negra” - El método de la caja negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requerimientos del programa. Con este equipo de pruebas se intenta encontrar: · Funciones incorrectas o ausentes. · Errores de interfaz. · Errores en estructuras de datos o en accesos a la bases de datos externas · Errores de rendimiento.

16. • Pruebas estructurales o de “caja blanca” o “caja de cristal” Principia con la observación de que un programa difícilmente puede considerarse como probado por completo si su código contiene partes que nunca han sido ejecutadas. Este método analiza la estructura lógica del programa y, para cada alternativa que puede presentarse, los datos de prueba ideados conducirán a ella. Se procura escoger los que verifiquen cada posibilidad en las proposiciones case, las cláusulas de cada proposición ify la condición de terminación de cada ciclo. En un programa extenso, este método es impráctico, pero en un modulo pequeño constituye un excelente medio de prueba y depuración.

17. En el contexto del software, la prueba de caja blanca, también conocida como prueba de caja de cristal o prueba estructural, a diferencia de la prueba funcional o de caja negra, se basa en lo que el programa hacey no en lo que debería hacer, ya que para derivar sus casos de prueba se concentra en el análisis del código del programa y no en sus requerimientos como lo hace la prueba de caja negra. Ambos enfoques no se contraponen sino que más bien se complementan para construir un buen conjunto de casos de prueba.

18. RELACION DE CONCEPTOS

19. EL ÉXITO EN ESTAS ACTIVIDADES ES ENCONTRAR LOS ERRORES

20. Manual de Usuario y Manual Técnico

21. PDSW DEFINICION DESARROLLO MANTENIMIENTO ACT.ANALISIS PLANIFICACION ACT.DISEÑO CODIFICAR PRUEBAS 3 1 2 DOC. REQUE. DOC. DISEÑO CODIGO EXPLICA MANUAL DE USUARIO 1 2 3 MAPEO MANUAL TECNICO

22. ¿QUÉ ES EL MANUAL DE USUARIO? El manual de usuario expone los procesos que el usuario puede realizar con el sistema implantado. Reúne la información, normas y documentación necesaria para que el usuario conozca y utilice adecuadamente la aplicación desarrollada. Objetivos: Que el usuario conozca cómo preparar los datos de entrada. Que el usuario aprenda a obtener los resultados y los datos de salida. Servir como manual de aprendizaje. Servir como manual de referencia. Definir las funciones que debe realizar el usuario. Informar al usuario de la respuesta a cada mensaje de error.

23. Contenido. Diagrama general del sistema Diagrama particular detallado Explicación Genérica De Las Fases Del Sistema Instalación Del Sistema Iniciación Al Uso Del Sistema Manual De Referencia Contenido Mínimo 1.Introducción. 2.Descripción del sistema. 3.Instalación del sistema. 4.Guía de utilización. 5.Índice de referencia. 6.Índice de Comandos.

24. Contenido Máximo 1.Introducción. 2.Descripción del sistema. 3.Descripción del entorno. 4.Instalación del sistema. 5.Guía de utilización. 6.Mensajes de error. 7.Ejemplos. 8.Índice de referencia. 9.Índice de comandos. 10.Anexos. Ojo: Debe redactarse de forma clara y sencilla para que lo entienda cualquier tipo de usuario.

25. ¿QUÉ ES UN MANUAL TÉCNICO? En la guía técnica o manual técnico se reflejan el diseño del proyecto, la codificación de la aplicación y las pruebas realizadas para su correcto funcionamiento. Objetivos: El principal objetivo es el de facilitar el desarrollo, corrección y futuro mantenimiento de la aplicación de una forma rápida y fácil Este manual esta compuesta por tres apartados: Cuaderno de carga Programa fuente Pruebas Doc. Requerimientos Doc. Diseño Código (Fuente, Objeto)

26. Estructura del documento Manual Técnico • 1-Índice. • 2-Introducción. • 2.1-Objetivo general del sistema • 2.2-Objetivos específicos • 3-Contenido técnico. Contenido Mínimo 1.Introducción. 2.Índice. 3.Descripción. 4.Herramientas. 5.Diccionario de datos. 6.Codificación.

27. “La risa es el sol que ahuyenta el invierno del rostro humano”