Integrantes:Remberto Prioló

Luis PáezCesar Benítez

Temas: Estándares, Reutilización y Caso de

prueba en la Ingeniería del Software.

Estándares en la Ingeniería del Software

• Se ocupan de la práctica responsable de la ingeniería del software.

• Regularmente tratan con el proceso en vez del producto … aunque algunas veces tratan con las características genéricas del producto o con recursos de apoyo.

• Tratan con temas como la Administración de la Configuración, Aseguramiento de la Calidad, Verificación y Validación.

• Consolidan la tecnología existente en una base firme para introducir nuevas tecnologías.

• Incrementan la disciplina profesional.• Protegen a los negocios.• Protegen al Comprador.• Mejoran al producto.

La Importancia de los Estándares en I.S.

Ciclo de Ingeniería ISO/IEC 12207 Sistema de gestión de calidad ISO 9000:2000

ISO 9001:2000ISO 90003:2004 Software Engineering-

Guidelines for application of ISO 9001:2000 to computer

software Sistema de calidad de productos software ISO 15504 (Spice)

Estándares ISO en Ingenieríade Software

ISO 15504 (Spice)

Propósito Evaluación del proceso de Ingeniería Mejora de proceso de ingeniería Determinación de capacidades (madurez) Dirigida a: Adquiridores Suministradores Evaluadores

ISO 15504 (Spice)Permite la evaluación de procesos software enorganizaciones que realicen alguna de las actividades del ciclo de vida del software: Adquisición Suministro Desarrollo Operación Mantenimiento Evolución Soporte

Idea vieja (reutilización ad hoc). “Cualquier procedimiento que produce o

ayuda a producir un sistema mediante el nuevo uso de algún elemento procedente de un esfuerzo de desarrollo anterior” .

Inicialmente, simple combinación de componentes de código almacenados en una biblioteca

(reutilización del código, sin método)

enfoque muy simple ¿Qué se reutiliza? ¿Cómo?

Reutilización del software

Beneficios de la reutilización

• Reducir el tiempo de desarrollo• Reducir el costo• Incrementar la productividad• No tener que reinventar las

soluciones• Facilitar la compartición de

productos del ciclo de vida

de código librerías de funciones, editores, inclusión de ficheros,

mecanismos de herencia en POO, componentes, etc. de diseños

no volver a inventar arquitecturas p.ej. patrones de diseño P.ej. patrones arquitectónicos (C/S, pipeline, OO, etc.)

de especificaciones reutilización de las abstracciones del dominio debe estar asociada a la generación (semi)automática de

los elementos de diseño e implementación. Elevar el nivel de abstracción reutilización

Asset como subsistema agregación de varios componentes atómicos a distintos niveles de abstracción (mecano).

Niveles de reutilización

Caso de prueba

En la ingeniería del software, los casos de PRUEBA o Test Case son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio.

Estructura de los casos de pruebaFormalmente, los casos de prueba escritos consisten principalmente en tres partes con subdivisiones:Introducción/visión general: Contiene información general acerca de los Casos de Prueba.

Identificador: Es un identificador único para futuras referencias, por ejemplo, mientras se describe un defecto encontrado.

Caso de prueba dueño/creador: Es el nombre del analista o diseñador de pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.

Versión: La actual definición del caso de prueba. Nombre: El caso de prueba debe ser un título entendible por

personas, para la fácil comprensión del propósito del caso de prueba y su campo de aplicación.

Identificador de requerimientos el cuál está incluido por el caso de prueba. También aquí puede ser un identificador de casos de uso o de especificación funcional.

Propósito: Contiene una breve descripción del propósito de la prueba, y la funcionalidad que chequea.

Dependencias: Indica qué otros subsistemas están involucrados y en qué grado.

Actividades de los casos de prueba• Ambiente de

prueba/configuración: Contiene información acerca de la configuración del hardware o software en el cuál se ejecutará el caso de prueba.

• Inicialización: Describe acciones, que deben ser ejecutadas antes de que los casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algún archivo.

• Finalización: Describe acciones, que deben ser ejecutadas después de realizado el caso de prueba. Por ejemplo si el caso de prueba estropea la base de datos, el analista debe restaurarla antes de que otro caso de prueba sea ejecutado.

• Acciones: Pasos a realizar para completar la prueba.

• Descripción de los datos de entrada

Resultados• Salida esperada: Contiene una descripción de lo que el

analista debería ver tras haber completado todos los pasos de la prueba.

• Salida obtenida: Contiene una breve descripción de lo que el analista encuentra después de que los pasos de prueba se hayan completado.

• Resultado: Indica el resultado cualitativo de la ejecución del caso de prueba, a menudo con un Correcto/Fallido.

• Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor, Normal, Menor.

• Evidencia: En los casos que aplica, contiene un link al print de pantalla (screenshot) donde se evidencia la salida obtenida.

• Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al defecto implicado se debe enumerar en esta columna. Contiene el código correlativo del defecto, a menudo corresponde al código del sistema de tracking de bugs que se esté usando.

• Estado: Indica si el caso de prueba está: No iniciado, En curso, o terminado.

Instrucciones para hacer casos de prueba

1. Identifica el requerimiento a probar y escribe su nombre y/o número en el caso de pruebas. Un análisis de negocios por lo regular genera un documento de diseño que incluye los requerimientos.

2. Crea un nombre y/o número de prueba para el caso de prueba. Es útil crear un documento separado con una matriz de trazabilidad para vincular los requerimientos y los casos de prueba entre sí. Identificar el nombre del requerimiento y su número junto con el nombre y número del caso de prueba permite la trazabilidad entre este último y el requerimiento.

3. Escribe una descripción corta del caso de prueba. Esta descripción proporciona una visión general de alto nivel de lo que hace el caso de prueba. Esto debe permitir que alguien sin conocimiento previo acerca del caso tenga una comprensión clara de lo que se hace sin revisar todos los pasos de prueba.

4. Identifica toda la información de configuración necesaria para ejecutar la prueba. Esta información incluye los elementos que son prerrequisitos de pruebas, como los datos, el hardware, el software y los navegadores.

5. Escribe los pasos y los resultados. Para cada paso escribe un número. Lo mejor es mantener el número de pasos aproximadamente en 10, con un máximo de 15. Tener pruebas cortas permite realizar un mantenimiento más fácil, hacer búsquedas de resultados de forma más simple y tener tiempos de prueba reducidos. Escribe la descripción del paso. Esta puede incluir una entrada clara o un conjunto de entradas si tienen relación entre sí. Otros elementos a incluir en cada paso son los resultados esperados, una indicación de aprobación/rechazo, el resultado real, todo tipo de notas y cualquier dato adjunto.

Por su atención Gracias!