DosMasTresSeis

HMS

Plan de Pruebas

Versin 2.0





HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 2



Historial de Revisin

Fecha Versin Descripcin Autor
2.0 Documento del Diseo de software Vera Cervantes Maria

HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 3



Tabla de contenido

1. Introduccin 4
1.1 Propsito 4
1.2 Alcance 5
1.3 Identificacin del proyecto: Definiciones, acrnimos y abreviaciones 5
2. Fundamentos del diseo de software 5
3. Cuestiones claves en el Diseo de Software 5
3.1 Control y manejo de eventos 6
3.2 Distribucin de componentes 7
3.3 Manejo de errores y excepciones y tolerancia a fallos 7
3.4 Interaccin y Presentacin 8
3.5 Persistencia de Datos 8
4. Estructura y arquitectura del Software 8
4.1 Estructura de la arquitectura y perspectivas 9
4.2 Estilo de arquitectura 13
4.3 Patrones de diseo 15
5. Analisis de la calidad de la evaluacion 17
6. Herramienta 21
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 4



Diseo de Software

1. Introduccin

La definicin de una Arquitectura de Software aporta en particular una visin abstracta de alto nivel al realizarse
el diseo para as poder ilustrar las caractersticas ms importantes del sistema. Se pretende capturar y
transmitir las decisiones arquitectnicas ms importantes realizadas en el sistema.
Por lo cual, al esbozar el diseo, se debe tomar mucha preponderancia en el momento de fijar una arquitectura
y as tomarla como algo clave a la hora de disear una solucin.

1.1 Propsito
El Documento de Arquitectura de Software (DAS) provee una perspectiva general del proyecto HMS, ya que
Presenta un conjunto de vistas arquitectnicas de los diferentes aspectos del sistema, siguiendo el modelo de
Vista 4+1. Este modelo permite a los stakeholders encontrar lo que ellos necesitan en la arquitectura de
software, ya que se muestra una clara visin del diseo de la arquitectura, lo cual podr ser muy til en el
mantenimiento posterior.






HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 5




1.2 Alcance
Este documento se concreta, de manera puntual, en el desarrollo de la vista lgica, vista de procesos, vista fsica,
vista de implementacin y vista de casos de uso. Adems permite la identificacin de los diferentes componentes
pertenecientes a cada vista del sistema HMS (Hospital System Management).

1.3 Identificacin del proyecto: Definiciones, acrnimos y abreviaciones

DAS: Documento de Arquitectura de Software.
RUP: Rational Unified Process.
Stakeholder (Interesados en el proyecto) es responsable de representar a un grupo interesado cuyas
necesidades se deban satisfacer por el proyecto. El rol puede ser jugado por cualquier persona que sea
(o potencialmente estar) afectada materialmente por el resultado del proyecto.
UML: Unified Modeling Language. Lenguaje de Modelamiento Unificado
Vista Lgica: Describe la funcionalidad interna, dirigida a diseadores y desarrolladores, define la
estructura esttica con diagramas de clases, objetos y relaciones, define las colaboraciones dinmicas
mensajes y funciones y propiedades adicionales como persistencia, concurrencia, interfaces y
estructura interna de las clases.
Vista de datos: Es una descripcin de la perspectiva del almacenamiento de datos persistentes en el
sistema. Se muestran las tablas y sus relaciones.
Vista de Implementacin: Muestra los componentes (Archivos, Programas, Formularios, Base de datos
e interfaces u cualquier otro elemento) que se requiere implementar o programar en el sistema.
Vista de despliegue: Muestra la distribucin fsica del sistema (Computadores, dispositivos) y sus
conexiones, dirigida a desarrolladores, integradores y probadores. Se plasma en el Diagrama de
Despliegue.
Back-end: Componentes del aplicativo que forman parte de los servicios de informacin y datos
necesarios para la ejecucin del aplicativo.
Front-end: Componentes que forman la parte de presentacin del aplicativo, interfaces visuales e
interacciones con el usuario.
Core de componentes: Mdulos desarrollados con funciones especficas para resolver determinadas
tareas repetitivas, por lo general son reutilizables.

2. Fundamentos del diseo de software
El software no es el nico campo donde el diseo se encuentra inmiscuido. En general podemos ver el diseo como
una forma para la resolucin de problemas. El problema sin solucin definitiva es interesante en trminos de
compresin de diseo en su sentido general, objetivos, limitaciones, alternativas, representaciones y soluciones.
3. Cuestiones claves en el Diseo de Software
En este punto se habla sobre la composicin de nuestro Software HMS, las tareas y todas las actividades necesarias
para poder brindarle a algn paciente, el servicio de atencin medica; con la interaccin del registrador (ADT) y el
medico que lo atender.



HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 6




Tareas de cada usuario



3.1 Control y manejo de eventos

Mediante un diagrama de actividades se muestra todas las acciones que se pueden realizar en el sistema HMS y
quienes realizan estas respectivas actividades.


































ADT PACIENTE MEDICO
Inicio
Solicita cita
medica
Verifica si el
paciente esta
registrado
Es paciente
Registrado
Solicita datos de
cita
Brinda datos
solicitados
Hay cita
disponible
Se registra nueva
consulta
Verifica citas
programadas
Hay citas
programadas
Atiende al
paciente
Fin
Desea
registrarse
Solicita datos para
el registro de
nuevo paciente
Brinda los datos
solicitados
Son correctos
los datos
Realiza registro
exitosamente
NO
SI
NO
SI
NO
SI
NO
Desea cita
SI
NO
SI
NO
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 7




3.2 Distribucin de componentes

Nuestro software los dividimos en componentes para visualizar las actividades que realizar cada entidad
y a la vez muestra las dependencias que existen.



3.3 Manejo de errores y excepciones y tolerancia a fallos

Las pruebas unitarias se realizaran inmediatamente despus de haber implementado la aplicacin.
Las otras pruebas que se realizaran son:
Prueba de la Integridad de los Datos y de la Base de Datos
Prueba de la Funcin
Prueba del Ciclo de Negocio
Prueba de la Interfaz de usuario
El Perfil de Funcionamiento
Prueba de Estrs
Prueba de Volumen
Prueba de la seguridad y del control de acceso
Prueba de la Configuracin









HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 8




3.4 Interaccin y Presentacin

Aqu se muestra la como la estructura y organizacin del sistema HMS interacta con nuestros usuario mediante la
interfaz.






Diagrama de interaccion de interfaces


3.5 Persistencia de Datos

Aqu se hace un control de los datos que contiene nuestro sistema HMS, como se relacionan nuestras
entidades que colaboran para implementar la funcionalidad del sistema.

4. Estructura y arquitectura del Software

HMS GUI
HMS BD
HMS POJOS
Nombre del
patrn
Puntos de Vista
Propsito
El objetivo del patrn es definir los tipos de vistas con los cuales
se representaran diferentes conjuntos de elementos y su relacin
entre ellos.
Tipo Patrn tarea
Contexto inicial
Deben cumplirse las siguientes condiciones antes de iniciar este
patrn:1)Los requerimientos han sido identificados y analizados
2)Documento de aprobacin de los requisitos por parte del cliente
3)se han identificado las reas del negocio.
Problema
El diseo tiene diferentes facetas o puntos de vista que muestran
propiedades especficas de un sistema de software.
Solucin La arquitectura se basar en el modelo 4+1, que contendr las
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 9











4.1 Estructura de la arquitectura y perspectivas




Modelo de Vista 4+1

vistas definidas por el modelo de 4+1,
Contexto
resultante
El modelo 4+1 permitir a los stakeholders encontrar lo que
ellos necesitan en la arquitectura de software, ya que se muestra
una clara visin del diseo de la arquitectura, lo cual podr ser
muy til en el mantenimiento posterior.
Usos conocidos y
ejemplos
Se utiliza las vistas para tener diferentes perspectivas del sistema
y ver como interactan los mdulos entre si.
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 10



Escenarios (vistas de casos de uso)
o Diagramas de casos de uso
Vista lgica
o Requerimientos funcionales
o Diagramas de clases
o Diagrama Entidad-Relacin
Vista procesos
o Diagramas de actividades
o Diagramas de componentes
Vista Fsica
o Diagrama de despliegue
Vista de desarrollo
o MVC

Diagrama de clases

HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 11
















Diagrama de components
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 12






Diagrama de despliegue








HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 13



4.2 Estilo de arquitectura

Nombre del patrn Estilo Arquitectnico
Propsito
El objetivo es establecer una estructura
para todos los componentes del sistema.
En el caso en el que ha de hacerse la
reingeniera de una arquitectura ya
existente, la imposicin de un estilo
arquitectnico dar como resultado
cambios fundamentales en la estructura
del software, incluida la reasignacin de
las funciones de los componentes.
Tipo Patrn tarea
Contexto inicial
Deben cumplirse las siguientes condiciones
antes de iniciar este patrn:1)Patrn
puntos de vista
Problema
El desarrollo de software debe guiarse por
una plantilla para la construccin, deben
definirse la orientacin del trabajo.
Solucin
Se utilizara el estilo MVC (modelo vista
controlador)
Contexto resultante
Se estar definiendo un estilo de trabajo
para nuestro sistema de tipo iterativo
Usos conocidos y
ejemplos
Queda definida la orientacin y el tipo de
sistema que se va desarrollar



















HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 14






Diagrama de paquetes



Diagrama de interaccion de interfaces








Controlador
Modelo
Vista
BaseDatos.j ava
Si stemaLogi co.j ava
Consulta.java
Diagnostico.java
Medico.java
Paciente.java
ADTview.java
Consultaview.java
HMSView.java
MEDICOView.java
REGISTRARCONSULT
Avi ew.j ava
REGISTRARPACIENTE
vi ew.j ava
Responde a eventos de Usuario
Selecciona la vista adecuada
Consulta estado
Notfica el cambio en la BD
Cambia el estado actual
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 15





4.3 Patrones de diseo

Nombre del patrn Singleton
Propsito Asegurar que una clase tenga una nica
instancia y proporciona un punto de acceso
global a dicha instancia.
Tipo Patrn de tarea
Contexto inicial Para la ejecucin de este patrn se requiere:
diagrama de casos de uso, diagrama de
componentes, diagrama de clases, diagrama
de secuencia, diagrama de iteraccin.
Problema Hay veces en la que es importante asegurar
que una clase tenga una sola instancia, en este
caso para el acceso a la BD necesitaremos que
exista solamente un objeto que acceda a la BD
para evitar problemas de inconsistencia y
duplicidad de datos.
Solucin Crear una variable global que sea el objeto
accesible, pero que tambin puede
instanciarse varias veces.
Contexto resultante Acceso controlado a la BD, Espacio de
nombres reducido lo que mejora el uso de
variables
Usos conocidos y
ejemplos
Cuando debe haber una sola instancia, y debe
ser accesible a los clientes desde un punto de
acceso conocido. Clientes desde un punto de
acceso conocido.


Nombre del patrn Proxy
Propsito Controlar los permisos de acceso de los
diferentes usuarios del sistema.
Tipo Patrn de tarea
Contexto inicial Para la ejecucin de este patrn se requiere:
diagrama de casos de uso, diagrama de
componentes, diagrama de clases, diagrama
de secuencia, diagrama de iteraccin.
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 16



Problema Es importante asegurar que el usuario
tenga acceso solamente a la informacin que
corresponde con su cargo, por eso el
problema surge en controlar los permisos
para el acceso al sistema de los usuarios
Solucin Asignar claves de usuarios para luego
comparar las claves y el nombre de usuario
para obtener la interfaz adecuada al cargo
que le corresponde al usuario y obtener el
objeto correspondiente.
Contexto resultante Permiten realizar tareas de mantenimiento
adicionales cuando se accede a un objeto
Usos conocidos y
ejemplos
Redirigir peticiones al objeto real cuando
sea necesario, para nuestro caso control de
acceso al sistema.


Nombre del patrn Iterator
Propsito Proporciona un medio de acceder a los
elementos de un contenedor secuencialmente
sin exponer su representacin interna.
Tipo Patrn de tarea
Contexto inicial Para la ejecucin de este patrn se requiere:
diagrama de casos de uso, diagrama de
componentes, diagrama de clases, diagrama
de secuencia, diagrama de iteraccin.
Problema El sistema trabajara con varias listas, lista de
pacientes, lista de consultas, litas de resultados
de exmenes, etc. Por lo que definir una
manera de optima de recorrer las listas y
sobre todo no mostrar informacin
innecesaria resulta de vital importancia.
Solucin Escoger un algoritmo de recorrido ,el cual
ser usado por un iterador haciendo que las
inserciones y borrados no afecten el recorrido,
luego se tendr que adicionar operaciones a
estos iteradores, como recuperar el anterior,
recuperar los n anteriores.
Contexto resultante Permite variaciones en el recorrido de un
arreglo. simplifican la interfaz del contenedor,
Se puede hacer ms de un recorrido a la vez
sobre un contenedor.
Usos conocidos y
ejemplos
Los iteradores son frecuentes en los sistemas
orientados a objetos, la mayoria de las
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 17



bibliotecas de clases ofrecen iteradores .


5. Analisis de la calidad de la evaluacion



Metrica de Usabilidad: Capacidad de ser entendido

Nombre:
Funciones evidentes
Propsito:
Qu proporcin de las funciones del sistemas son
evidentes al usuario.
Mtodo de aplicacin:
Contar las funciones evidentes al usuario y comparar
con el nmero total de funciones.
Medicin, frmula:
X = A/B
A = nmero de funciones (o tipos de funciones)
evidentes al usuario
B = total de funciones (o tipos de funciones)
Interpretacin:
0 <= X <= 1
Entre ms cercano a 1, mejor.
Tipo de escala:
absoluta
HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 18



Tipo de medida:
X = count/count
A = count
B = count
Fuente de medicin:
Especificacin de requisitos
Diseo
Informe de revisin
ISO/IEC 12207 SLCP:
Verificacin

Metrica de Eficiencia: Comportamiento temporal

Nombre:
Tiempo de respuesta
Propsito:
Cul es el tiempo estimado para completar
una tarea.
Mtodo de aplicacin:
Evaluar la eficiencia de las llamadas al
SO y a la aplicacin.
Estimar el tiempo de respuesta basado
en ello. Puede medirse:Todo o partes
de las especificaciones de diseo.
Probar la ruta completa de una
transaccin.
Probar mdulos o partes completas
del producto.
Producto completo durante la fase de
pruebas.
Medicin, frmula:
X = tiempo (calculado o simulado)
Interpretacin:
Entre ms corto, mejor.
Tipo de escala:
proporcin
Tipo de medida:
X = time
Fuente de medicin:
Sistema operativo conocido
Tiempo estimado en llamadas al sistema
ISO/IEC 12207 SLCP:
Verificacin
Revisin conjunta



HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 19



Metrica de Fiabilidad: Madurez

Nombre:
Suficiencia de las pruebas
Propsito:
Cuntas de los casos de prueba necesarios estn
cubiertos por el plan de pruebas.
Mtodo de aplicacin:
Contar las pruebas planeadas y comparar con el
nmero de pruebas requeridas para obtener una
cobertura adecuada.
Medicin, frmula:
X = A/B
A = nmero de casos de prueba en el plan
B = nmero de casos de prueba requeridos
Interpretacin:
0 <= X
Entre X se mayor, mejor la suficiencia.
Tipo de escala:
absoluta
Tipo de medida:
X = count/count
A = count
B = count
Fuente de medicin:
A proviene del plan de pruebas
B proviene de la especificacin de requisitos
ISO/IEC 12207 SLCP:
Aseguramiento de Calidad














HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 20




Metrica de Mantenibilidad: Cambios

Nombre:
Registrabilidad de cambios
Propsito:
Se registran adecuadamente los cambios a la
especificacin y a los mdulos con comentarios
en el cdigo?
Mtodo de aplicacin:
Registrar la proporcin de informacin sobre
cambios a los mdulos
Medicin, frmula:
X = A/B
A = nmero de cambios a funciones o mdulos
que tienen comentarios confirmados
B = total de funciones o mdulos modificados
Interpretacin:
0 <= X <= 1
Entre ms cercano a 1, ms registrable.
0 indica un control de cambios deficiente o pocos
cambios y alta estabilidad.
Tipo de escala:
absoluta
Tipo de medida:
X = count/count
A = count
B = count
Fuente de medicin:
Sistema de control de configuraciones
Bitcora de versiones
Especificaciones

















HMS
Versin: 1.0
Plan de Pruebas Fecha: 15/04/2014

C o n f i d e n t i a l HMS Pgina 21




6. Herramientas







Nombre del
patrn
Herramientas case
Propsito Definir herramientas case que puedan ayudarnos hacer nuestro
trabajo orientado a la mayor calidad
Tipo Patrn de rea
Contexto
inicial
Para la ejecucin de este patrn es necesario haber hecho un
anlisis comparativo de las distintas herramientas existentes en el
medio para poder escoger la herramienta q mejor se acomode a
nuestro desarrollo.
Problema Se requiere cumplir con los tiempos previstos por el plan de
accin adems de ejecutar cada fase con la mayor eficiencia es
decir se necesita aumentar la productividad, el uso de
herramientas tiene esa funcion.
Solucin Se escogieron las siguientes herramientas:
Diagramas: Rational Rose Enterprise
Diagramas: Microsoft Visio 2010
Interfaces: Pencil 2.0.5
BD: Toad data modeler
Contexto
resultante
Se automatizo el proceso del diseo y se gano bastante tiempo con
el uso de estas herramientas:
Diagramas de clases, diagramas de iteracin, diagramas de
entidad- relacion,diagramas de actividades, diseo de interfaces.
Usos
conocidos y
ejemplos