1. Integrantes:
Remberto Prioló
Luis Páez
Cesar Benítez
Temas: Estándares,
Reutilización y Caso de
prueba en la
Ingeniería del Software.

2. 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.

3. La Importancia de los
Estándares en I.S.
• 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.

4. Estándares ISO en Ingeniería
de Software
Ciclo de Ingeniería
ISO/IEC 12207
Sistema de gestión de calidad
ISO 9000:2000
ISO 9001:2000
ISO 90003:2004 Software Engineering-
Guidelines for application of
ISO 9001:2000 to computer software
Sistema de calidad de productos software
ISO 15504 (Spice)

5. 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

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

8. Reutilización del software
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?

9. 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

10. Niveles de reutilización
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).

11. 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.

12. Estructura de los casos de prueba
Formalmente, 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.

13. 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

14. 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.

15. 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.

16. Por su atención
Gracias!