INGENIERIA DE SOFTWARE

II
Mg. Ing. Luis Palacios Quichz
Universidad San Martn de Porres
Lima - Per

Semana 6
Diseo de Interfaces, Casos
de Prueba y Procedimiento
de Pruebas

Temario
Diseo de la interfaz
Diseo de Casos y Procedimientos de
Prueba.

2.1. Diseo de la Interfaz

El diseo de sistemas computacionales engloba
un gran espectro de actividades que van desde el
diseo a nivel de hardware, hasta el diseo de la
interfaz de usuario.
El diseo cuidadoso de una interfaz de usuario es
una parte esencial del proceso de diseo de
software completo.
El buen diseo de la interfaz de usuario es crtico
para la independencia del sistema.
Cuando se realiza
deben de tomar en
y mentales de las
dirigida el sistema.

una interfaz de usuario, se

cuenta las capacidades fsicas
personas hacia las cuales va

Los usuarios no deben de ser

forzados a adaptarse a una
interfaz

1 FAMILIAR PARA
EL USUARIO

La interfaz debe de usar trminos

familiares para el usuario

Los objetos que gestiona o

manipula el sistema, deben estar
estrechamente relacionados con el
ambiente de trabajo del usuario

Los comandos del sistema y

mens deben de tener el mismo
formato

2
EXTREMADAMENTE
CONSISTENTE

Los
parmetros
deben
ser
pasados a todos los comandos de
la misma forma

La puntuacin de los comandos

deben ser similares. Ctrl+b debe
de apegarse la mayor parte de
las aplicaciones del sistema que
se trate

Debe evitar que la gente se irrite

por cuando un sistema se
comporta de manera inadecuada

CAUSAR
SORPRESA
MNIMA

Conforme se utiliza un sistema, el

usuario construye un modelo
mental de su funcionamiento

Los diseadores de la interfaz

deberan intentar asegurar que las
acciones
comparables
tienen
efectos comparables

Confirmacin
de
acciones
destructivas. El sistema debe de
preguntar al usuario la posibilidad
de realizar una accin destructiva

RECUPERABLE
CONTRA
ERRORES

Proveer al sistema con la opcin

de Deshacer ciertas actividades
realizadas con l, entre mayores
niveles de Deshacer se tengan, es
mejor

Otorgar al sistema la capacidad de

almacenar la informacin del
sistema en diferentes intervalos de
tiempo

La interfaz debe de regresar a las

actividades anteriores cuando se
haya presentado un error

5
AMIGABLE PARA
EL USUARIO

La interfaz debe de tener un

conjunto de ayuda para el usuario
que sea sensible al contexto en
diferentes niveles

El sistema de ayuda debe de ser

estructurado de tal forma que los
usuarios no se vean abrumados de
una gran cantidad de informacin

6
ATENDER A VARIOS
TIPOS DE USUARIOS

La interfaz debe de ser capaz

de
proporcionar
una
interaccin
adecuada
a
diferentes tipos de usuarios
relacionados con la temtica
de la misma
Debe de ser capaz de ser
accesible tanto para usuarios
ocasionales como aquellos que
se
consideren
como
potenciales
Los
usuarios
potenciales
necesitarn de un conjunto de
herramienta de acceso rpido,
mientras que los ocasionales
requerirn de una gua de uso
Reflejar la nocin del Diseo
Universal (UD), que tiene una
filosofa de diseo que tiene
como meta excluir a los
usuarios

2.1.2. Proceso de Diseo de la Interfaz Grfica

de usuario
Analizar y entender
las Actividades
del usuario
Producir un
Diseo en papel
del prototipo

Disear
el prototipo

Evaluar el diseo
con los usuarios
finales
Producir un
diseo de
prototipo
dinmico

Evaluar el diseo
con los usuarios
finales

Prototipo
realizado

Implementar
la interfaz
de usuario

2.1.3. Evaluacin de la Interfaz

Es el proceso verificar la usabilidad de la interfaz y
de checar que se cumplen con los requerimientos
del usuario.
ATRIBUTO
DESCRIPCIN
Curva de
aprendizaje

Cunto tiempo le toma al usuario ser

productivo con la interfaz

Velocidad de
operacin

Qu tanto se relaciona el tiempo de respuesta

del sistema con los requerimientos del usuario

Robustez

Qu tanta tolerancia a errores tiene el la

interfaz

Recuperabilidad Qu tan bueno es el sistema para recuperarse

de errores del usuario
Adaptabilidad

Qu tanto se adapta la interfaz a un modelo de

trabajo

3. Casos de Prueba y Procedimientos de

Prueba
Establecer
o
actualizar
los
casos
y
procedimientos de prueba para las pruebas de
integracin.
Estn basadas en la Especificacin
Requisitos y el Diseo de Software.

de

El Cliente provee los datos de prueba, en caso

de ser necesarios.

3.1. Estructura de los casos de prueba

Formalmente, los casos de prueba escritos consisten
principalmente en tres partes con subdivisiones:
Introduccin: Contiene informacin general acerca del Caso
de Prueba.
Identificador: Es nico para futuras referencias.
Creador: Es el nombre del analista o diseador de pruebas,
quien ha desarrollado pruebas o es responsable de su
desarrollo.
Versin: La actual definicin del caso de prueba.
Nombre: debe ser un ttulo entendible, para la fcil
comprensin del propsito del caso de prueba y su campo de
aplicacin.
Identificador de requerimientos: incluido por el caso de
prueba. Tambin puede ser un identificador de casos de uso o
de especificacin funcional.
Propsito: breve descripcin del propsito de la prueba, y la
funcionalidad que chequea.
Dependencias:
Indica
qu
otros
subsistemas
estn

Actividades de los casos de prueba

Ambiente de prueba/configuracin: Contiene informacin
acerca de la configuracin del hardware o software en el cul
se ejecutar el caso de prueba.
Inicializacin: Describe acciones, que deben ser ejecutadas
antes de que los casos de prueba se hayan inicializado. Por
ejemplo, debemos abrir algn archivo.
Finalizacin: Describe acciones, que deben ser ejecutadas
despus 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.
Descripcin de los datos de entrada .

Resultados
Salida esperada: Contiene una descripcin de lo que el
analista debera ver tras haber completado todos los pasos de
la prueba.
Salida obtenida: Contiene una breve descripcin de lo que el
analista encuentra despus de que los pasos de prueba se
hayan completado.
Resultado: Indica el resultado cualitativo de la ejecucin 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 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 cdigo correlativo del defecto, a menudo
corresponde al cdigo del sistema de tracking de bugs que se
est usando.
Estado: Indica si el caso de prueba est: No iniciado, En curso,
o terminado.

3.2. Estructura de los procedimientos de

prueba
Formalmente, los procedimientos de prueba contienen lo
siguiente:
Introduccin: incluye todos los elementos para llevar a cabo el
procedimiento.
Los Procedimientos de Prueba pueden incluir:
Identificacin: nombre de la prueba, descripcin de la prueba
y la fecha de finalizacin de la prueba.
Posibles problemas: Identifica los posibles inconvenientes o
incidencias que podran ocurrir durante la implementacin.
Personal:
Listar
las
personas
que
completen
los
procedimientos de pruebas, as como tambin el progreso de
estas.
Requisitos previos: indica los requisitos previos para llevar a
cabo los procedimientos.
Pasos del procedimiento: indica el nmero de pasos, la accin
requerida por el probador y los resultados esperados. Describe
el COMO debe efectuarse las pruebas.

4. Verificar y aprobar los casos y

procedimientos de prueba
Verificar y obtener la aprobacin del Plan de
Pruebas y los casos y procedimientos de
Prueba.
Verificar la consistencia entre la Especificacin
de Requerimientos, Diseo de Software y los
Casos de Prueba y Procedimientos de Prueba.
Los
resultados
encontrados
estn
documentados en Resultado de Verificacin.
Las correcciones son realizadas hasta que el
documento es aprobado.

Tarea 6
Revisar su proyecto del curso
Revisin de los Roles participantes
Asignar tiempos para las siguiente tareas de la
actividad arquitectura y diseo detallado de
software:
Refinar el diseo de las interfaces que se
detallaron en las Especificaciones de casos de
Uso.
Establecer los casos y procedimientos de prueba.

Conclusiones
Para definir las interfaces es importante:
Comprender la especificacin de requisitos
Disear las interfaces pensando en los usuarios que van
a utilizar el aplicativo.
Los casos y procedimientos de prueba permiten
establecer las pruebas unitarias e integrales
despus de construir los componentes de software.

Gracias por su atencin

Preguntas?