Especificación de Requerimientos de

Software
Introducción

El sistema de control hospitalario será el encargado de unificar y desplazar la información

entre los diferentes hospitales y clínicas de la red, además será el responsable de la gestión de
almacenamiento de los datos de cada una de las entidades antes descritas.

La aplicación deberá ser desarrollada en una plataforma web de tal manera que la información
de cada uno de los centros pueda ser consultada en cada una de las localidades de la red,
además se podrá dar mantenimiento a la información del personal y a los suministros que
maneja un hospital o una clínica individual. Todo esto permitirá a los centros hospitalarios
poder tener acceso a la información de una forma rápida y eficaz, teniendo información
precisa en el momento que se requiera.

Objetivos Generales del Sistema

Nuestro sistema está destinado a brindar apoyo para que los centros hospitalarios puedan
responder a las expectativas de los usuarios, de esta manera se pretende instalar un sistema
informático de gestión hospitalaria que permita:

 Conectar los diferentes centros hospitalarios y clínicas, pudiendo mantener

centralizada la información de todos los centros.
 Comunicar a los diferentes centros hospitalarios y clínicas para el correcto
funcionamiento de los mismos.
 Mejorar la eficacia y eficiencia de los centros hospitalarios y clínicas.
 Armonizar la información médica y administrativa - contable, a fin de consolidar los
usos y permitir un sistema integral para la toma de decisiones.

Alcances
El Sistema “iEmergency” será una plataforma para la comunicación de los centros hospitalarios
tanto de las cedes centrales así como también las regionales, las cuales estarán conectados vía
Internet, lo cual permitirá la unificación de información que se genere en cada centro. La
recolección de la información se pretende almacenar en una Base de Datos Centralizada. Con
esto se pretende mejorar la forma de llevar a cabo las operaciones de cada centro hospitalario
así como de cada clínica y de todo el personal de los mismos. Se lista a continuación los
alcances principales:

 Red de hospitales que tiene a cargo la empresa UNIHOS

 Aplicación funcional en centros regionales
Proyecto Final
Metodología RUP

Descripción General
El sistema llevara el control de todos los centros hospitalarios así como las clínicas médicas
localizadas en varias regiones. Este sistema pretende controlar la información que se maneje
en todos y cada uno de los centros que pertenezcan a la red de hospitales y clínicas, como por
ejemplo el manejo de las especialidades, el personal, los suministros y demás, pudiendo así
cumplir con las expectativas de cada uno de ellos.

Funciones del Sistema

 Conectar los diferentes centros hospitalarios y clínicas
 Manejar la Información de cada Centro Hospitalario y Clínico
 Brindar una plataforma segura y fácil de utilizar
 Mejorar la eficacia y eficiencia de los centros hospitalarios y clínicas, pudiendo
brindar una plataforma que agilicen los procesos que a diario se realizan en cada
uno de los centros

Restricciones Generales
 Aplicación desarrollada en ambiente web
 Licencias tanto para la base de datos como para la plataforma de desarrollo

Especificación de Requerimientos
Requerimientos Funcionales:

Listado de requerimientos detallados

No. Descripción
1 Unificación de información de todos los hospitales y clínicas de la red
2 Gestión de clínicas por hospital o clínicas individuales que pertenezcan a la red
3 Mantenimiento de especialidades por hospital o clínica
4 Mantenimiento de personal por hospital o clínica
5 Mantenimiento de suministros por hospital o clínica
6 Gestión de suministros
7 Consulta de especialidades por hospital o clínica
8 Consulta de personal por hospital o clínica
9 Consulta de suministros por hospital o clínica
10 Aplicación accesible las 24 horas del día los 365 días del año
11 Aplicación accesible a través de intranet corporativa
12 Administración de permisos a usuarios del sistema

2|Página
Proyecto Final
Metodología RUP

Gestión del Proyecto

La Gestión de Proyectos tiene como finalidad principal la planificación, el seguimiento y control
de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de
un Sistema de Información y de esta manera organizar y administrar los recursos de manera tal
que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo,
y costos definidos. Como consecuencia de este control es posible conocer en todo momento
qué problemas se producen y resolverlos o paliarlos de manera inmediata.

En este apartado se detalla la planificación inicial del proyecto para la fase de inicio y la fase de
elaboración (según la definición de la metodología RUP) y el diario de ejecución del proyecto,
sesión tras sesión de trabajo.

PLAN DE DESARROLLO DE SOFTWARE

Organización del Proyecto

‫ خ‬Participantes en el Proyecto
El personal del proyecto, considerando las fases de Inicio, Elaboración y la Fase de
Construcción, estará formado por los siguientes puestos de trabajo y personal asociado:

 Jefe de Proyecto: Es la persona que tiene la responsabilidad total respecto a la

planificación y ejecución del proyecto. El Jefe de Proyecto cuenta con una experiencia
modesta en metodologías de desarrollo, herramientas CASE y notaciones, en particular
la notación UML y el proceso de desarrollo RUP.

 Analista de Sistemas: Es la persona responsable de investigar, planear, coordinar y

recomendar opciones de software y sistemas para cumplir los requerimientos de la
empresa. El perfil establecido es: Ingeniero en Informática con conocimientos de UML,
y al menos con experiencia en sistemas afines a la línea del proyecto.

 Analistas – Programadores: Con experiencia en el entorno de desarrollo del proyecto,

con el fin de que los prototipos puedan ser lo más cercanos posibles al producto final.

 Ingeniero de Software: El perfil establecido es “Ingeniero en Informática” quien estará

realizando labores de gestión de requisitos, gestión de configuración, documentación y
diseño de datos. Además es el Encargado de las pruebas funcionales del sistema.

‫ خ‬Interfaces Externas
El equipo de desarrollo interactuará activamente con el personal designado por el hospital
para la especificación y validación de los artefactos generados durante el desarrollo del
proyecto.

3|Página
Proyecto Final
Metodología RUP

‫ خ‬Roles y Responsabilidades
A continuación se describen las principales responsabilidades de cada uno de los puestos en el
equipo de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que
desempeñan en RUP.

Puesto Responsabilidad
El jefe de proyecto asigna los recursos, gestiona las
prioridades, coordina las interacciones con los clientes y
usuarios, y mantiene al equipo del proyecto enfocado en
los objetivos. El jefe de proyecto también establece un
Jefe de Proyecto conjunto de prácticas que aseguran la integridad y calidad
de los artefactos del proyecto. Además, el jefe de proyecto
se encargará de supervisar el establecimiento de la
arquitectura del sistema. Gestión de riesgos. Planificación y
control del proyecto.

Captura, especificación y validación de requisitos,

interactuando con el cliente y los usuarios mediante
Analista de
entrevistas. Elaboración del Modelo de Análisis y Diseño.
Sistemas
Colaboración en la elaboración de las pruebas funcionales y
el modelo de datos.

Construcción de prototipos. Colaboración en la elaboración

Programador de las pruebas funcionales, modelo de datos y en las
validaciones con el usuario.

Gestión de requisitos, gestión de configuración y cambios,

Ingeniero de elaboración del modelo de datos, preparación de las
Software pruebas funcionales, elaboración de la documentación.
Elaborar modelos de implementación y despliegue.

4|Página
Proyecto Final
Metodología RUP

PLANIFICACIÓN DEL PROYECTO

En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.

Plan de las Fases

El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de ellas.
La siguiente tabla muestra una la distribución de tiempos y el número de iteraciones de cada
fase (para las fases de Construcción y Transición es sólo una aproximación muy preliminar)

Fase No. Iteraciones Duración

Fase de Inicio 1 3 semanas

Fase de Elaboración 1 2 semanas

Fase de Construcción 2 7 semanas

Fase de Transición - -

Los hitos son una forma de conocer el avance del proyecto y son la forma más abarcativa de
monitorear la ejecución del proyecto. Los hitos que marcan el final de cada fase se describen
en la siguiente tabla:

Descripción Hito
En esta fase desarrollará los requisitos del producto desde la
perspectiva del usuario, los cuales serán establecidos en el
artefacto Visión. Los principales casos de uso serán
Fase de Inicio
identificados y se hará un refinamiento del Plan de Desarrollo
del Proyecto. La aceptación del cliente / usuario del artefacto
Visión y el Plan de Desarrollo marcan el final de esta fase.

Fase de
En esta fase se analizan los requisitos y se desarrolla un
Elaboración
prototipo de arquitectura (incluyendo las partes más
relevantes y / o críticas del sistema). Al final de esta fase,
todos los casos de uso correspondientes a requisitos que
serán implementados en la primera release de la fase de
Construcción deben estar analizados y diseñados (en el
Modelo de Análisis / Diseño). La revisión y aceptación del
prototipo de la arquitectura del sistema marca el final de esta
fase. En nuestro caso particular, por no incluirse las fases
siguientes, la revisión y entrega de todos los artefactos hasta
este punto de desarrollo también se incluye como hito. La
primera iteración tendrá como objetivo la identificación y

5|Página
Proyecto Final
Metodología RUP

especificación de los principales casos de uso, así como su

realización preliminar en el Modelo de Análisis / Diseño,
también permitirá hacer una revisión general del estado de los
artefactos hasta este punto y ajustar si es necesario la
planificación para asegurar el cumplimiento de los objetivos.
Ambas iteraciones tendrán una duración de una semana.

Durante la fase de construcción se terminan de analizar y

diseñar todos los casos de uso, refinando el Modelo de
Fase de Análisis / Diseño. El producto se construye en base a 2
Construcción iteraciones, cada una produciendo un release a la cual se le
aplican las pruebas y se valida con el cliente / usuario. Se
comienza la elaboración de material de apoyo al usuario.

En esta fase se prepararán dos releases para distribución,

asegurando una implantación y cambio del sistema previo de
manera adecuada, incluyendo el entrenamiento de los
usuarios. El hito que marca el fin de esta fase incluye, la
Fase de Transición
entrega de toda la documentación del proyecto con los
manuales de instalación y todo el material de apoyo al
usuario, la finalización del entrenamiento de los usuarios y el
empaquetamiento del producto.

6|Página
Proyecto Final
Metodología RUP

Calendario del Proyecto

El proceso iterativo e incremental de RUP está caracterizado por la realización en paralelo de
todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los
artefactos son generados muy tempranamente en el proyecto pero van desarrollándose en
mayor o menor grado de acuerdo a la fase e iteración del proyecto.

El calendario presenta las principales tareas del proyecto. La fecha de aprobación indica
cuándo el artefacto en cuestión tiene un estado de completitud suficiente para someterse a
revisión y aprobación, pero esto no resta la posibilidad de su posterior refinamiento y sus
respectivos cambios. Para este proyecto se ha establecido el siguiente calendario:

Disciplinas/Artefactos Generados o
Comienzo Aprobación
Modificados
durante la Fase de Inicio
MODELO DE NEGOCIO
Modelo de Casos de Uso del Negocio y
14/10/09 - 18/10/09 28/10/09 - 02/11/09
Modelo de
Objetos del Negocio
REQUISITOS
Glosario 14/10/09 - 18/10/09 28/10/09 - 02/11/09
Visión 21/10/09- 25/10/09 28/10/09 - 02/11/09
Modelo de Casos de Uso 28/10/09 - 02/11/09 Siguiente Fase
Especificación de Casos de Uso 28/10/09 - 02/11/09 Siguiente Fase
Especificaciones Adicionales 28/10/09 - 02/11/09 Siguiente Fase
ANÁLISIS/DISEÑO
Modelo de Análisis y Diseño 21/10/09- 25/10/09 Siguiente Fase
Modelo de Datos 21/10/09- 25/10/09 Siguiente Fase
IMPLEMENTACIÓN
Prototipos de Interfaces de Usuario 28/10/09- 02/11/09 Siguiente Fase
Modelo de Implementación 28/10/09- 02/11/09 Siguiente Fase
PRUEBAS
Casos de Pruebas Funcionales 28/10/09- 02/11/09 Siguiente Fase
DESPLIEGUE
Modelo de Despliegue 28/10/09- 02/11/09 Siguiente Fase
Durante Todo el Durante todo el
GESTIÓN DE CAMBIOS Y CONFIGURACIÓN Proyecto Proyecto
GESTIÓN DEL PROYECTO
Plan de Desarrollo del Software en su
14/10/09 -18/10/09 28/10/09- 02/11/09
versión 1.0 y
planes de las iteraciones
Durante Todo el Durante Todo el
AMBIENTE Proyecto Proyecto

7|Página
Proyecto Final
Metodología RUP

Disciplinas /Artefactos generados o modificados Comienzo Aprobación

durante la Fase de Elaboración
MODELADO DEL NEGOCIO
Modelo de Casos de Uso del Negocio y Modelo de 14/10/09-
Objetos del Negocio 18/10/09 Aprobado
REQUISITOS
14/10/09-
Glosario 18/10/09 Aprobado
21/10/09-
Vision 25/10/09 Aprobado
28/10/09- 09/11/09-
Modelo de Casos de Uso 02/11/09 13/11/09
28/10/09- 09/11/09-
Especificacion de Casos de Uso 02/11/09 13/11/09
28/10/09- 09/11/09-
Especificaciones Adicionales 02/11/09 13/11/09
ANÁLISIS/DISEÑO
21/10/09- Revisar en cada
Modelo de Análisis / Diseño 25/10/09 Iteración
21/10/09- Revisar en cada
Modelo de Datos 25/10/09 Iteración
IMPLEMENTACIÓN
28/10/09- Revisar en cada
Prototipos de Interfaces de Usuario 02/11/09 Iteración

8|Página
Proyecto Final
Metodología RUP

Modelo del Negocio

La empresa que tiene a su cargo una red de hospitales y clínicas médicas en varias regiones del
país los cuales solicitaron el proyecto de desarrollo de software constan de varios centros que
se encuentran dentro de la capital así como también diversos centros repartidos en distintas
regiones.

Alguno de los controles que se debe llevar es el de los centros y hospitales, por región, clínicas
por cada hospital, o clínicas que no pertenezcan a un hospital, pero si a la red, así como las
especialidades que se manejan por hospital, personal que pertenezcan al hospital o a una
clínica individual dentro de la red de hospitales (Doctores, especialistas, enfermeras etc.),
control de suministros (medicina, medicamentos, utensilios, etc.).

El diagrama que representa los diferentes subsistemas en los que se ha dividido la empresa a
nivel de abstracción es el siguiente:

Modelo de Paquetes del Negocio

9|Página
Proyecto Final
Metodología RUP

Modelo de Casos de Uso del Negocio

10 | P á g i n a
Proyecto Final
Metodología RUP

Requisitos
Especificación de Casos de Uso
uc Hospital

Sistema Inventario

Recibe Solicitud de
Producto

Ingresa Productos al
SIstema
Auxiliar Farmacia
Caj ero

Registra Producto
Sistema

Descarga Producto
Inv entario

Reporte de
Productos v endidos
durante el dia

REgistra Entrega y
Recibido de Producto

Ingreso Paci entes

Elabora Registro de
Ingreso

Enfermera

Da Informacion
Paciente
General

Ingresa Datos al
Sistema

11 | P á g i n a
 Proyecto Final
Metodología RUP

Análisis/Diseño
Modelo de Análisis/Diseño
Diagramas de Clases Negocio (General)
class Class Model

ControlActiv idades Classes, interfaces and

+ actividad logical components for
the new system
+ tarea

Recursos

+ empleado
Administracion + especialidades
+ medico BancoSangre
+ Configuracion
+ general + paciente + BancoSangre
+ persona «import»
+ logo «import» + Donador
+ perfil + servicios
+ permisos
+ usuarios

Hospital_Clinicas
«import»
+ Clinica
Gestion + Hospital
Reportes Contable + Sucursal
+ Citas
+ Historial_citas + Gestion_Servicios + Consolidado
+ Historial_servicios «use» «import» + Detalle
+ Pagos
+ Factura

12 | P á g i n a
 Proyecto Final
Metodología RUP

Modulo de Seguridad del Sistema

class Administracion

general
logo
- direccion: String
- alto: float - horario_atencion: String
- ancho: float - horario_visita: String
- telefono: String
+ borrar_logo() : void
+ crear_logo() : void Configuracion
«property»
+ modificar_logo() : void
- general: general + direccion() : String
«property» - logo: logo + horario_atencion() : String
+ alto() : float + horario_visita() : String
+ ancho() : float + asignar_logo(logo) : void + telefono() : String
+ modifica_info_general(general) : void

usuarios

- estado: int permisos

- nombre: string perfil
- password: string - descripcion: string
- usuario: string - descripcion: string - modulo: string
- permisos[]: permisos
+ asignar_perfil(perfil) : void + borrar_permiso() : void
+ crear_usuario() : void + asignar_permisos(permiso) : void + crear_permiso() : void
+ eliminar_usuario() : void + borra_perfil() : void + listar_permisos() : void
+ crea_perfil() : void 1 1..*
+ es_activo(boolean) : boolean + modificar_permiso() : void
+ listar_usuarios() : void + listar_perfiles() : void
«property»
+ modificar_usuario() : void + modifica_perfil() : void
+ descripcion() : string
«property» «property» + modulo() : string
+ nombre() : string + descripcion() : string
+ password() : string
+ usuarios() : string

uc Administración

Administración

Crear usuario

Crear perfil

Administrador

(from Actors)
Asignar permisos

Configurar sistema

13 | P á g i n a
 Proyecto Final
Metodología RUP
Modulo de Recursos Humanos
class Catalogos_Basicos
persona
- apellidos: string
- direccion: string
- edad: int
- no_identificacion: string
- nombres: string
- telefono: string
«property»
+ apellidos() : string
+ direccion() : string
+ edad() : int
+ no_identificacion() : string
+ nombres() : string
+ telefono() : string
medico
- empleado: empleado
- especilidad: especialidades
- no_colegiado: int
+ crear_medico() : void
+ listar_medicos() : void
«property»
+ empleado() : empleado
+ especilidad() : especialidades
+ no_colegiado() : int
paciente
+ crear_paciente() : void
+ listar_pacientes() : void Administracion::usuarios
- estado: int
- nombre: string
- password: string
empleado - usuario: string
- carnet: int
+ asignar_perfil(perfil) : void
- horario: string
+ crear_usuario() : void
- sueldo: float
+ eliminar_usuario() : void
- usuario: usuarios
+ es_activo(boolean) : boolean
+ listar_usuarios() : void
+ asignar_usuario(usuario) : void
+ modificar_usuario() : void
+ crea_empleado() : void
«property»
+ listar_empleado() : void
+ solicita_vacaciones(empleado) : void + nombre() : string
+ password() : string
«property» + usuarios() : string
+ carnet() : int
+ horario() : string
+ sueldo() : float serv icios
+ usuario() : usuarios
- costo: float
- descripcion: string
- descuento: float
especialidades
- descripcion: string + crear_servicio() : void
+ listar_servicios() : void
+ crear_especialidad() : void «property»
+ listar_especialidades() : void + costo() : float
«property» + descripcion() : string
+ descripcion() : string + descuento() : float
14 | P á g i n a
Proyecto Final
Metodología RUP

uc Catalogos basicos

Catalogos básicos

Ingresar paciente

Medico
(from Actors)

Ingresar empleado

Administrador
Solicitar v acaciones (from Actors)
Empleado interno
(from Actors)

Crear serv icio

15 | P á g i n a
 Proyecto Final
Metodología RUP

Modulo Pacientes
class Gestion

empleado Citas
Catalogos_Basicos::
Catalogos_Basicos::medico serv icios
- fecha: string
- empleado: empleado - medico: medico
- costo: float
- especilidad: especialidades - paciente: paciente
- descripcion: string
- no_colegiado: int - descuento: float
+ agendar_cita() : void
+ crear_medico() : void + eliminar_cita() : void
+ crear_servicio() : void
+ listar_medicos() : void + reagendar_cita() : void + listar_servicios() : void
«property» «property» «property»
+ empleado() : empleado + fecha() : string
+ costo() : float
+ especilidad() : especialidades + medico() : medico
+ descripcion() : string
+ no_colegiado() : int + paciente() : paciente + descuento() : float

Gestion_Serv icios Pagos

- fecha: string
- medico: medico
- servicio: servicios
+ solicita_servicio() : void
«property»
+ fecha() : string
+ medico() : medico
+ servicio() : servicios
- cita: citas
persona
- fecha_pago: string
Catalogos_Basicos::
- monto: float
paciente
- no_documento: int
- servicios[]: servicios
+ crear_paciente() : void
+ listar_pacientes() : void
+ agregar_servicio() : void
+ aplicar_descuento() : void
+ imprimir_boleta() : void
+ realizar_pago() : void
«property»
+ cita() : citas
+ fecha_pago() : string
+ monto() : float
+ no_documento() : int

16 | P á g i n a
 Proyecto Final
Metodología RUP

uc Gestion medica

Gestion medica

Solicitar Cita

Agendar cita

Reagendar cita
Paciente
Medico (from Actors)
(from Actors) Solicita serv icio

Recibe serv icio

Realiza pago

Imprime recibo

Modulo Contable
class Facturacion

Recursos::paciente
Factura
+ crear_paciente() : void
+ Id: int + listar_pacientes() : void
+ Numero: int
+ Serie: string
+ Fecha: Date
+ ClienteId: int
+ Descuento: float
+ DetalleFactura: List<Detalle>

+ Facturar() : void Recursos::persona

+ Anular(int) : void - nombres: string
- apellidos: string
- direccion: string
- edad: int
Consolidado - telefono: string
Detalle Listado de todas las - no_identificacion: string
ventas facturadas + Facturas: Listt<Factura>
+ ProductoId: int
+ Cantidad: int + Reporte(Date, Date) : void «property»
+ Precio: float + Reporte(int) : void + nombres() : string
+ Descripcion: string + Reporte(int, Date, Date) : void + apellidos() : string
+ direccion() : string
+ edad() : int
+ telefono() : string
+ no_identificacion() : string

17 | P á g i n a
Proyecto Final
Metodología RUP

uc Sistema Hotel

Logistica General

Asigna Cita
Genera Factura

Solicita Cita Sistema Contable

Paciente
Verifica Forma Pago
Entrega/Recibe
Factura

Solicita
Ingresa
Medicamentos Productos/Serv icios a
Facturar Encargado

Realiza Pago Verifica Datos

Paciente

Seguridad Sistema

Verificar Permisos

Personal Administrador

Asignar Permiso

18 | P á g i n a
 Proyecto Final
Metodología RUP

Modulo Hospital y Modulo Clínicas

class Hospital

Hospital
Sucursal
+ ListarClinicas() : void
- clinicaID: int
- Descripcion: string
- Direccion: string
- Fax: int
- Telefono: string
- disponibilidad: boolean

+ ObtenerInformacion() : void

Clinica

- Sucursal: Sucursal

+ IngresarClinicas() : void

Modulo Banco de Sangre

class BancoSangre

Catalogos_Basicos::persona
- nombres: string
- apellidos: string
- direccion: string
- edad: int
- telefono: string
- no_identificacion: string
Catalogos_Basicos::
Donador
paciente
- TipoSangre: string
+ crear_paciente() : void
+ listar_pacientes() : void

«property»
+ nombres() : string
+ apellidos() : string
+ direccion() : string
+ edad() : int
+ telefono() : string
+ no_identificacion() : string
BancoSangre
- cantidad: int
- TiposSangre: Donador
- Vencimiento: Date
+ ListarCantidad(string) : void
+ ObtenerInformacion() : void

19 | P á g i n a
 Proyecto Final
Metodología RUP

Modulo Reportes
class Reportes

empleado
Catalogos_Basicos::medico
Historial_serv icios
- empleado: empleado
- medico: medico - especilidad: especialidades
- servicio: servicios - no_colegiado: int

+ generar() : void + crear_medico() : void

«property» + listar_medicos() : void
+ medico() : medico «property»
+ servicio() : servicios + empleado() : empleado
+ especilidad() : especialidades
+ no_colegiado() : int

Historial_citas
- medico: medico
+ generar() : void
«property»
+ medico() : medico
Catalogos_Basicos::
serv icios
- costo: float
- descripcion: string
- descuento: float
+ crear_servicio() : void
+ listar_servicios() : void
«property»
+ costo() : float
+ descripcion() : string
+ descuento() : float

20 | P á g i n a
Proyecto Final
Metodología RUP

Modelo de Datos
Diagrama ER

21 | P á g i n a
Proyecto Final
Metodología RUP

Diseño Arquitectura de Software

La Arquitectura del Software “iEmergency” para la Red de Hospitales aportara una visión
abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a pasos
posteriores del diseño.

El objetivo principal es aportar elementos que ayuden a la toma de decisiones y, al mismo

tiempo, proporcionar conceptos y un lenguaje común que permitan la comunicación entre los
equipos que participen en el proyecto para el hospital General.

Vista Lógica

22 | P á g i n a
Proyecto Final
Metodología RUP

Vista Física

cmp Vista Fisica

Cliente

Serv idor BD
Serv idor Web

Internet

Cliente Externo

23 | P á g i n a
Proyecto Final
Metodología RUP

Vista Implementación

cmp Vista Implementacion

Disponibilidad
Especialista

Aspx SolicitudCita

Acceso Datos
Disponibilidad
Clinica

Solicita Serv icio Recibe serv icios Recibe Factura Acceso a Datos

Ingresa Datos al Valida si Es Dona Sangre Almacena al Banco

Banco de sangre Factible Donar de Sangre

Conceder/Denegar
Paciente

24 | P á g i n a
Proyecto Final
Metodología RUP

Arquitecturas del Sistema WEB

Arquitectura 3 Capas del Sistema “iEmergency”

25 | P á g i n a
Proyecto Final
Metodología RUP

Arquitectura de la Aplicación

26 | P á g i n a
Proyecto Final
Metodología RUP

Implementación
Prototipos del Sistema
Administrador

27 | P á g i n a
Proyecto Final
Metodología RUP

Recursos Humanos

28 | P á g i n a
Proyecto Final
Metodología RUP

Modulo Seguridad

Perfiles de Usuario

29 | P á g i n a
Proyecto Final
Metodología RUP

Servicio al Cliente

30 | P á g i n a
Proyecto Final
Metodología RUP

Plan de Pruebas
Identificación de Pruebas
Propósito
A continuación se describe el Plan de pruebas para el sistema del Hospital. En concreto define
los siguientes objetivos específicos:

 Identifica los elementos que se van a probar.

 Describe la estrategia de pruebas que se va a seguir en el proceso de prueba.
 Identifica los recursos necesarios para llevar a cabo el proceso de prueba y estima los
esfuerzos que conlleva.
 Lista los resultados que se obtienen de las actividades de prueba.

Ámbito
Este Plan de Pruebas describe las pruebas de unidad, integración y del sistema que se aplicarán
al sistema software desarrollado. El objetivo es probar todos los requisitos definidos en la
Especificación de requisitos y en el Modelo de casos de uso.

Elementos a Probar
La lista que proporcionamos a continuación nos describen los elementos (casos de uso,
requisitos funcionales y requisitos no funcionales) que son objetivos de las pruebas. Es decir,
los elementos qué vamos a probar.

Prueba de los Datos

 Verificar el acceso al sistema del hospital.
 Verificar la forma de almacenamiento de los datos.
 Verificar accesos simultáneos de lectura de datos.
 Verificar el acoplamiento de los usuarios al sistema.
 Verificar tiempos de ejecución de los procesos.

Pruebas de Funcionalidad
 Verificar el caso de uso de Solicitar Cita
 Verificar el caso de uso de Atender Cita.
 Verificar el caso de uso de Compra a proveedores.
 Verificar el caso de uso de Donación de Sangre.
 Verificar el caso de uso de Inventarios
 Verificar el caso de uso de Ingreso de pacientes.
 Verificar el Módulo de clínicas

31 | P á g i n a
Proyecto Final
Metodología RUP

 Verificar el Módulo de Contabilidad

 Verificar el Módulo de Medicamentos.
 Verificar el Módulo de Banco de Sangre.
 Verificar el Módulo de Hospitales y clínicas externas.
 Verificar el Módulo de Recursos Humanos.
 Verificar el Módulo de Pacientes.

Pruebas de Interfaz de Usuario

 Verificar que el acceso que tengan los usuarios sea fácil de entender.
 Navegar a través de todos los casos de uso, verificando que cada interfaz de usuario se
comprende fácilmente.
 Verificar todas las funciones de ayuda online.
 Verificar que todas las interfaces de usuario siguen los estándares de GUI.

Pruebas de Desarrollo
Requerimiento: “Existirá un sistema central en el cual se almacene toda la información. “ Por
tanto las pruebas se ejecutaran en dos partes, la implementación del sistema central en una
PC y las pruebas de navegación en otra PC para verificar el sistema web.

Enfoque, Estrategia y Criterios de las Pruebas

En esta sección presentamos el enfoque que vamos a utilizar para probar el sistema software.
En la sección anterior describimos qué elementos del sistema software vamos a probar, y en
esta sección se define cómo se realizaran las pruebas.

Tipos de Pruebas Técnicas

Pruebas de integridad de la base de datos y de los datos.

Comprobar que los procedimientos y métodos de

Objetivos de la prueba
acceso a la base de datos funcionan correctamente.

Invocar cada procedimiento o método de acceso a la

base de datos con datos válidos e inválidos.
Inspeccionar la base de datos para asegurar que los
Técnicas datos son los previstos, todos los eventos de la base
de datos ocurren adecuadamente, o revisar los
valores devueltos para asegurar que la recuperación
de datos es correcta.

Todos los procedimientos y métodos de acceso

Criterios de finalización funcionan como se diseñaron y sin ningún error en
los datos.

Consideraciones Los procesos se deberían invocar manualmente. Se

32 | P á g i n a
Proyecto Final
Metodología RUP

debería usar bases de datos de tamaño pequeño o

mínimo (limitado según el número de registros) para
incrementar la visibilidad de cualquier evento no
aceptable.

Pruebas de funcionalidad
Las pruebas de funcionalidad las ejecutaremos desde el punto de vista del cliente basándonos
en los requisitos recabados en etapas anteriores, guiándonos por lo que el cliente solicito.

El objetivo de estas pruebas es verificar la aceptación, procesamiento y recuperación de datos

y la adecuada implementación de las reglas de negocio.

Objetivos de la prueba Asegurar la navegación correcta de la aplicación, la

entrada de datos, su procesamiento el manejo que
los usuarios le den a la aplicación por vía Web.

Técnicas Ejecutar cada caso de uso y flujo del caso de uso con
datos válidos e inválidos para verificar lo siguiente:

 Cuando se utilizan datos correctos se obtienen

Criterios de finalización
los resultados esperados.
 Cuando se utilizan datos incorrectos se obtienen
los mensajes de error o advertencias adecuadas.
 Cada caso de uso es abarcado dentro del
sistema evidenciando su funcionabilidad.
Todas las pruebas planificadas se han ejecutado.

Todos los defectos identificados se han considerado.

Consideraciones Ninguna.

Pruebas de interfaz de Usuario

Las pruebas de interfaz de usuario verifican la interacción del usuario con el sistema
Hospitalario. El objetivo de esta prueba es asegurar que la interfaz de usuario permite al
usuario acceder y navegar a través de toda la funcionalidad de la aplicación. Además, la prueba
de interfaz de usuario garantiza que las interfaces de usuario cumplen los estándares.

Objetivos de la prueba Verificar los siguientes objetivos:

 La navegación a través de la aplicación refleja

adecuadamente las reglas de negocio y los
requisitos incluyendo ventana a ventana, campo a
campo y métodos de acceso (tabulador,

33 | P á g i n a
Proyecto Final
Metodología RUP

movimientos del ratón y teclas de función).

 Las ventanas y sus características, como menús,
tamaño, posición y estado cumplen los
estándares.
Técnicas Crear o modificar pruebas para cada ventana con el
objetivo de verificar la correcta navegación y su
estado.

Criterios de finalización Cada ventana se ha verificado con éxito y es

consistente con la versión de referencia o con los
estándares utilizados.

Consideraciones Ninguna.

Pruebas de Desarrollo
Las pruebas de desarrollo miden tiempos de respuesta, índices de transacción y otros
requisitos susceptibles al tiempo. El objetivo de estas pruebas es verificar y validar que los
requisitos de rendimiento se han alcanzado.

Las pruebas de desarrollo normalmente se ejecutan varias veces usando cada vez un cargo de
trabajo diferente. La prueba inicial se debería realizar con una carga normal y la segunda
prueba con una carga extrema.

Objetivos de la prueba Validar el tiempo de respuesta del sistema software

para las transacciones diseñadas o funciones de
negocio bajo las condiciones siguientes:

 Volumen de trabajo normal.

 El peor volumen de trabajo.
Técnicas Usar los procedimientos de prueba definidas para las
pruebas de funcionalidad.

Modificar las tablas de alimentación del sistema en la

base de datos para que tengan una carga
considerada y ejecutar ingreso masivo de información
(para incrementar el número de transacciones).

Criterios de finalización Se han completado las pruebas sin ningún error y

dentro de los tiempos de respuesta esperados.

Consideraciones Ninguna.

34 | P á g i n a
Proyecto Final
Metodología RUP

Necesidades Ambientales
Las siguientes herramientas se usarán para llevar a cabo el proceso de prueba:

Tipo de Prueba Herramienta

Herramienta DBMS MySQL

Interfaz de usuario Aplicación Web

Funcionales Aplicación Web y Usuarios

Rendimiento Base de datos (carga)

En esta sección describimos los recursos necesarios para realizar el proceso de prueba, sus
principales responsabilidades y características.

Recursos Hardware
Recurso Cantidad Nombre y Tipo

Estructura del sistema,

PC 2 tanto para base de datos
como para aplicación

Clientes que servirán para

PC 2
interactuar con el sistema.

Recursos Software
Nombre del elemento software Tipo y otras notas

Windows Corrida de aplicación

Navegador de Internet Aplicación de Usuario

MySQL Base de datos

Herramientas de Soporte
 NINGUNA.

35 | P á g i n a
Proyecto Final
Metodología RUP

Rol
Gestor de prueba
Diseñador de prueba
Probador (Tester)
Personal Necesario
RECURSOS HUMANOS
Mínimos recursos Responsabilidades específicas o
recomendados comentarios
1 Proporcionar una gestión adecuada.
Responsabilidades:
 Proporcionar una dirección técnica.
 Adquirir los recursos apropiados.
 Informar de la gestión.
2 Identificar y poner en práctica los casos de
prueba.
Responsabilidades:
 Generar el Plan de pruebas.
 Diseñar los Casos de prueba.
 Evaluar el esfuerzo de prueba.
3 Ejecutar las pruebas.
Responsabilidades:
 Ejecutar pruebas.
 Recuperar los errores.
 Documentar los defectos.

Calendario de Pruebas
Las actividades del proceso de prueba para este sistema software son:

Actividad Fecha de comienzo Fecha de

finalización
Planificación de la prueba 20 de Enero 22 de Enero
Diseño de la prueba 26 de Enero 28 de Enero
Implementación de la prueba 4 de Febrero 15 de Febrero
Ejecución de la prueba 16 de Febrero 27 de Febrero
Evaluación de la prueba 3 de Marzo 10 de Marzo

Del proceso de prueba se obtienen los siguientes documentos de desarrollo de software:

Documento de desarrollo de Fecha

software
Plan de prueba 22 de Enero
Casos de prueba 28 de Enero
Informe de evaluación de pruebas 15 de Marzo

36 | P á g i n a
Proyecto Final
Metodología RUP

Tareas para la Etapa de Pruebas

Las tareas que se realizan en cada una de las actividades son:

Planificación de las Pruebas

 Identificar los requisitos para las pruebas.
 Valorar los riesgos.
 Desarrollar la estrategia de pruebas.
 Identificar los recursos necesarios para realizar las pruebas.
 Planificar la temporalización.
 Generar el Plan de pruebas.

Diseño de las Pruebas

 Análisis de la carga de trabajo.
 Desarrollo de las pruebas.
 Identificar y describir los casos de prueba.

Implementación de las Pruebas

 Establecer el entorno de prueba.
 Desarrollar las clases de prueba, los componentes de prueba y los datos de prueba.

Ejecución de las Pruebas

 Ejecutar los casos de prueba.
 Evaluar la ejecución del proceso de prueba.
 Verificar los resultados.
 Investigar los resultados no esperados.
 Registrar los defectos.

Evaluación de las Pruebas

 Evaluar la cobertura de los casos de prueba.
 Evaluar la cobertura del código.
 Analizar los defectos.
 Determinar si se han alcanzado los criterios de las pruebas.
 Crear los informes de evaluación de las pruebas.

37 | P á g i n a
Proyecto Final
Metodología RUP

Propuesta Económica
Propuesta Económica de la Red de Hospitales para el Diseño e
Implementación del Sistema Informático “iEmergency”
Noviembre/2009

Costo: $$ 48,500.00
(Cuarenta y ocho mil quinientos dólares)

Propuesta basada en el diseño del sistema presentado según los requerimientos iníciales de la
red hospitalaria.

A continuación se presenta la tabla con la definición de los costos detallados para la

implementación del sistema informático iEmergency.

# CONCEPTO BREVE DESCRIPCION TOTAL OBSERVACIONES

Honorarios
1 Director del proyecto Director general de la $$ 3,000.00
(Analista Senior) propuesta
2 Analista Programador Analistas de sistemas $$ 11,600.00 Considerados 4
Senior encargados del correcto meses(finalización
diseño del software del proyecto)
3 Analista Programador Desarrolladores de $$ 10,800.00 Considerados 4
Junior software meses(finalización
del proyecto)
1 Analista de Sistemas Analista de sistemas $$ 1,700.00 Considerados 2
Senior encargado del testeo del meses(finalización
sistema del proyecto)
Sistema iEmergency
7 Módulos de software  Clínicas $$ 19,600.00 Considerando $$
 Medicamentos 2800.00 costo
 Contabilidad por modulo.
 RRHH
 Pacientes
 Hospitales
 Banco de sangre
Implementación, A cargo de analista de $$ 1,800.00
documentación y sistemas Senior
capacitación a usuario
Totales $$ 48,500.00

38 | P á g i n a
Proyecto Final
Metodología RUP

Conclusión
La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños),
dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias
etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación
del equipo de profesionales necesarios.

El aplicar RUP en nuestros proyectos es de mucha ayuda, ya que como se pudo ver si se
necesita volver a hacer el análisis de ciertas etapas, basta con consultar la documentación y
verificar en que se cometió el error.

Por otro lado, en lo que se refiere a la metodología esta comprende tres frases claves: Dirigido
por los casos de uso, centrado en la arquitectura, iterativo e incremental.

En lo referente a dirigido por los casos de uso, está enfocado hacia el cliente y se utilizan con
algunas modificaciones tal vez, hasta la disciplina de pruebas, en la cual, un caso de uso puede
a su vez tener uno o más casos de prueba.

39 | P á g i n a