DUOC UC - Escuela de Salud

Propuesta de Proyecto y
Especificación de
Requisitos de Software
Proyecto: ELECTROSALUD
Revisión: [01]
19/11/2018

Planificación y Especificación de Requisitos según estándares; IEEE 830, ISO9000 y PMI.

 Especificación de Requisitos, estándar de IEEE 830

Contenido
FICHA DEL DOCUMENTO .............................................................................................................................. 3

1. INTRODUCCIÓN.................................................................................................................................. 4

1.1. PROPÓSITO ....................................................................................................................................... 4

1.2. ÁMBITO DEL SISTEMA ....................................................................................................................... 4
1.3. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ................................................................................ 4
1.4. REFERENCIAS ................................................................................................................................... 6
1.5. VISIÓN GENERAL DEL DOCUMENTO ................................................................................................. 6

2. DESCRIPCIÓN GENERAL ....................................................................................................................... 7

2.1. PERSPECTIVA DEL PRODUCTO ......................................................................................................... 7

2.2. FUNCIONES DEL PRODUCTO ............................................................................................................ 8
2.3. CARACTERÍSTICAS DE LOS USUARIOS ............................................................................................. 9
2.4. RESTRICCIONES................................................................................................................................ 9
2.5. SUPOSICIONES Y DEPENDENCIAS .................................................................................................. 10
2.6. REQUISITOS FUTUROS ................................................................................................................... 11

3. REQUISITOS ESPECÍFICOS ........................................................................................................ 11

.3.1 REQUISITOS COMUNES DE LAS INTERFACES .................................................................................. 11

3.1.1 Interfaces de usuario........................................................................................................... 11
3.1.2 Interfaces de hardware ....................................................................................................... 12
3.1.3 Interfaces de software......................................................................................................... 12
3.1.4 Interfaces de comunicación ............................................................................................... 12
3.2 REQUISITOS FUNCIONALES............................................................................................................. 12
3.3 REQUISITOS NO FUNCIONALES ....................................................................................................... 13
3.3.1 Requisitos de rendimiento .................................................................................................. 13
3.3.2 Seguridad ............................................................................................................................. 14
3.3.3 Fiabilidad ............................................................................................................................... 14
3.3.4 Disponibilidad ....................................................................................................................... 14
3.3.5 Mantenibilidad ...................................................................................................................... 15
3.3.6 Portabilidad ........................................................................................................................... 15
3.4 OTROS REQUISITOS ....................................................................................................................... 15

4. PROPUESTA DE PLANIFICACIÓN ................................................................................................. 15

4.1 DESCRIPCIÓN GENERAL ACERCA DE LA PLANIFICACIÓN ...................................................................... 15

4.1.2 Definición del Equipo de Trabajo .............................................................................................. 15
4.1.3 Definición de Actividades principales del Proyecto ................................................................ 16
4.1.4 Diagrama EDT ............................................................................................................................. 17
4.1.5 Carta Gantt ................................................................................................................................... 18
4.1.6 Resumen Costos del Desarrollo del Proyecto ........................................................................ 18
4.2 PLAN DE CONTROL DE CAMBIO............................................................................................................. 19
5. ANEXOS................................................................................................................................................... 20
5.1 Acta de Proyecto ............................................................................................................................ 20
5.2 Matriz Especificación de Requerimientos ................................................................................... 24

2
 Especificación de Requisitos, estándar de IEEE 830

5.3 Diagrama de Casos de Uso General .......................................................................................... 27

5.4 Planilla Casos de Uso .................................................................................................................... 29
5.5 Prototipado de Software ................................................................................................................ 31
5.6 Resultado Análisis de Calidad Diagramas Modelamiento ....................................................... 38
5.7 Resultado Análisis de Calidad Prototipado No funcional del Sistema ................................... 38
5.8 Planilla entregables del Proyecto ................................................................................................. 38
5.9 Matriz de Control de Cambios ...................................................................................................... 38
5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo ............................................................... 39

Ficha del documento

Fecha Revisión Autor Modificación

Desarrollo de la Propuesta de
Yuliana Aracena
19/11/2018 1 Proyecto y Especificación de
Javiera Rodriguez
Requisitos de Software

Documento validado por las partes en fecha: 19 de noviembre del 2018

Integrantes:

Nombre Integrante del Equipo Rol Definido

Javiera Rodriguez Jerez Ingeniero de Software
Matías Roa Roa Diseñador
Jenniffer Astudillo Tapia Responsable de Pruebas y Calidad
Yuliana Aracena Pérez Jefe de Proyecto

3
 Especificación de Requisitos, estándar de IEEE 830

1. Introducción

1.1. Propósito
El siguiente documento tiene como propósito definir las especificaciones de
requerimientos de software tanto funcionales como no funcionales para la
implementación de una ficha clínica electrónica que registrará y administrará todos
los datos y antecedentes clínicos de los usuarios que se atenderán en el Servicio
de salud Duoc UC, que será utilizado por los profesionales de salud.

1.2. Ámbito del Sistema

La ficha clínica electrónica será un programa de software que funcionará en
sistemas
operativos de Windows 10, que permitirá el ingreso, registro, consulta y
administración de datos clínicos y antecedentes de los usuarios.
A través de este software podrán inscribir consultas médicas, inscribir y
actualizar datos de los pacientes, agregar motivos de consultas y diagnósticos,
consultar horas tomadas con profesionales de salud, consultar datos de los
profesionales y personal de salud, adjuntar exámenes médicos, escribir recetas
médicas electrónicas, generar estadísticas y reportes.
Este sistema no permitirá la abertura de más de 3 fichas clínicas de forma
simultánea por el resguardo y seguridad de los datos clínicos y para evitar la
sobrecarga del sistema, además se cerrará de sesión automáticamente si no ha
sido usado en 10 minutos.

1.3. Definiciones, Acrónimos y Abreviaturas

Inscripción de consultas médicas: proceso en el cual el administrador o
médico deja registrado las próximas citas médicas de los usuarios.
Administrar: Acción de agregar, modificar, eliminar y consultar la
información de un usuario.
Motivo de consulta: razón por la cual el usuario decide atenderse en el
servicio de urgencias.

4
 Especificación de Requisitos, estándar de IEEE 830

Diagnóstico: resultado de la atención de salud de los usuarios que

permitirá entregar los tratamientos adecuados a ellos.
Reporte: organiza y exhibe la información contenida en una base de datos.
Receta médica electrónica: módulo de la FCE que permite el registro del
nombre, run, servicio del médico, nombre comercial o principio activo, dosis,
horario, vía de administración del medicamento, concluyendo con el timbre médico
electrónico.
FCE: ficha clínica electrónica.
Usuario final: persona natural con acceso autorizado para su ingreso a la
ficha clínica electrónica.
Permiso: parámetro que especifica si su poseedor dispone de acceso a
una determinada función del sistema o a una parte de la interfaz de usuario del
sistema.
Administrador del Sistema: persona encargada de ofrecer el soporte
técnico y operativo al sistema, queda a cargo del departamento de informática del
servicio de salud.
Base de datos: es un conjunto de datos que pertenecen al mismo contexto
almacenados sistemáticamente para su posterior uso.
Sistema de gestión de base de datos: son un tipo de software muy
específico, dedicado a servir de interfaz entre la base de datos, el usuario y las
aplicaciones que la utilizan.
Aplicación o software: es un programa informático diseñado para facilitar
al usuario la realización de un determinado tipo de trabajo.
MySQL: sistema de gestión de base de datos relacional.

5
 Especificación de Requisitos, estándar de IEEE 830

1.4. Referencias
Documento
Planificación y especificación de
requisitos según estándares.
Ingeniería del software, un
enfoque practico
Protocolo de registro, gestión y
manejo de ficha clínica única
Referencia
IEEE 830, ISO 9000 y PMI
http://www.academia.edu/download/45525376/Ingenier
ia.de.software.enfoque.practico.7ed.Pressman.PDF
http://200.72.129.100/calidad/archivo1/Manejo%20Fich
a%20-%20REG%201.1_v.7.pdf

1.5. Visión General del Documento

En el presente documento se encontrará la información acerca de las
características del sistema de software, interfaces del usuario, interfaces del
sistema, características de los usuarios, descripción de los requerimientos
funcionales, no funcionales y del sistema.
El documento concluye con las propuestas de planificación del producto
entregable, con definición del equipo de trabajo, actividades relacionadas, Carta
Gantt y estimado presupuestario del costo del sistema.

6
 Especificación de Requisitos, estándar de IEEE 830

2. Descripción General

2.1. Perspectiva del Producto

El programa de software de la FCE estará diseñado para trabajar en
sistemas operativos Windows 10, siendo de preferencia el primer por la
simplicidad de su interfaz gráfica de usuarios. Este producto trabajará de forma
independiente, por lo que no dependerá de otros sistemas mayores.

Ingreso de información al sistema

Acceso de Registro Registro de Diagnósticos, Registro de Registro de
usuarios de horas motivos de tratamientos y receta datos del
autorizados médicas consultas procedimientos del médica personal de
servicio de urgencias electrónica salud

Registro de la información
Módulo de atención de urgencias Módulo de Farmacias Módulo de consulta de datos del
personal

Almacenamiento de la Información
Servidor que contiene una base de datos que es administrada por el departamento de informática
del servicio de salud. La base de datos es invisible para los usuarios

Salida de Información
Estadísticas y Receta médica Ficha clínica Resumen de Cierre de sesión
reportes electrónica electrónica atención médica de usuarios
visualizada

7
 Especificación de Requisitos, estándar de IEEE 830

2.2. Funciones del Producto

a) Inscripción de consultas médicas: proceso en el que quedan registradas
las horas médicas de los pacientes.
b) Registro de datos de los pacientes: registro de los datos indispensables
de los pacientes para el llenado de su ficha clínica electrónica.
c) Registro de motivos de consultas: el administrador podrá ingresar los
motivos de consultas en el módulo de atenciones de urgencias para su
consiguiente admisión.
d) Registro de diagnósticos: el médico podrá registrar en el módulo de
urgencias u otros servicios médicos los diagnósticos resultantes de las
atenciones de los pacientes
e) Adjunción de exámenes médicos: se tendrá un módulo especifico de
exámenes médicos realizados que quedan registrado en la ficha clínica
electrónica de forma única.
f) Consultas de horas de atención: proceso en el cual los usuarios finales
pueden buscar información sobre las horas agendadas.
g) Consultar de datos de los profesionales y personal de salud: proceso
en el cual los usuarios finales pueden buscar información sobre datos de
los trabajadores del servicio de salud.
h) Registro de recetas médicas electrónicas: módulo de la ficha clínica
electrónica que permite la generación de una receta médica digital, con una
notificación enviada a Farmacia.
i) Generación estadísticas y reportes: estos datos son administrados por el
departamento de informática para desarrollar posibles soluciones o ajustes
del software.

8
 Especificación de Requisitos, estándar de IEEE 830

2.3. Características de los Usuarios

La interacción con el software contará con acceso de tres tipos de usuarios:
Administrador Técnico, Administrador Profesional y Administrador del Sistema:
a) Administrador Técnico: corresponde a un tipo de usuario final cuya
función en registrar datos que permitan la admisión de los pacientes para
su consiguiente atención. Están autorizados a admitir al paciente a
urgencias, a agendar horas médicas, consultar horas agendadas y datos
del personal, consultar recetas médicas activas. Idealmente debe contar
con manejo básico de sistemas Windows.
b) Administrador Profesional: usuario que corresponden a profesionales de
salud, los cuales pueden registrar diagnósticos, adjuntar exámenes,
registrar y autorizar recetas médicas. Debe poseer conocimientos medios
de sistemas operativos Windows.
c) Administrador del Sistema: Usuario con gran conocimiento en el manejo
del sistema con una previa capacitación. Encargado de manejar el sistema
con gran responsabilidad sobre los criterios de permisos sobre los usuarios.

2.4. Restricciones
a) Políticas de la empresa: la licencia del software es de tipo privativo,
debido a que éste es único para el Servicio de salud Duoc UC; en caso de
que otra entidad quisiera adquirir este producto, requiere una autorización a
los distribuidores.
b) Limitaciones del hardware: para la instalación del programa se requiere
un computador servidor que soporte MySQL y Java.
c) Interfaces con otras aplicaciones: el software es autónomo y no necesita
conexiones con otros sistemas.
d) Operaciones paralelas: no corresponde a condición del proyecto.

9
 Especificación de Requisitos, estándar de IEEE 830

e) Funciones de auditoría: es importante la puesta en marcha y el control de

todas las modificaciones al sistema operativo, y en general, de todo el
software de base del sistema.es necesario establecer controles y
restricciones adecuados para evitar los cambios desautorizados en el
software del sistema.
f) Funciones de control: el software debe controlar los permisos que tiene
cada tipo de usuario para su accesibilidad, de tal forma que pueda acceder
la información que le corresponde según su tipo.
g) Lenguaje(s) de programación: se accederá a una base de datos MySQL y
la aplicación es desarrollada en JAVA.
h) Protocolos de comunicación: Todo el material que se realice para el
usuario y la aplicación debe de estar en lenguaje español.
i) Requisitos de habilidad: el registro de datos clínicos y atenciones en
salud y la programación de horas médicas deben estar ajustados a la
realidad para que funcione óptimamente.
j) Criticidad de la aplicación: para garantizar su funcionamiento el sistema
deberá ser sometido a una serie de pruebas para establecer que se
encuentra acorde a los requerimientos que se plasman en el documento en
tanto a la consistencia de datos como al rendimiento de la aplicación, tales
como tiempos de respuesta.
k) Consideraciones acerca de la seguridad: cada usuario deberá
autenticarse y su acceso verificado de acuerdo con lo que su tipo
especifique. Todas las claves de seguridad deberán estar seguras y en su
defecto encriptadas en la base de datos para dar una buena seguridad al
sistema y su información.

2.5. Suposiciones y Dependencias

 Debe realizarse una capacitación adecuada y acorde a lo que cada usuario
va a realizar. Su capacitación de hará en el momento que sea necesaria y a
las personas indicadas.
 Sólo se trabajará con el software en sistemas operativos Windows

10
 Especificación de Requisitos, estándar de IEEE 830

2.6. Requisitos Futuros

 El software estará habilitado para actualizaciones o mejoras si se
presentan.
 El software podría trabajar con otros sistemas de software compatible para
la ampliación del flujo de información entre redes asistenciales.

3. Requisitos Específicos
Por medio de la reunión ya realizada con las partes involucradas el cliente expresa
que espera que el proyecto cuente con optimizar el tiempo de espera y conexiones
con los departamentos de Urgencias, Farmacias y Departamento de Informática.

En la institución existen aún ficha de papel las cuales poseen problemas como:

 Congestión en el ingreso de pacientes.

 Demora en el llenado de la ficha.
 Tiempo consumido del personal administrativo.
 Duplicas de información y recetas médicas.

Por esta razón los requisitos específicos con los que debe contar el proyecto son:

 Modernización de las fichas clínicas usadas en los servicios.

 Informatización del registro clínico
 Levantamiento de información.
 Capacitación del personal.
 Evitar duplicidad de ordenes médicas de exámenes.

3.1 Requisitos comunes de las interfaces

La entrada de los sistemas será de distintos departamentos, la salida ira orientada
a un solo sistema.

3.1.1 Interfaces de usuario

La interfaz será una amigable con el profesional de salud, el cual estará enfocado
a un entendimiento rápido y sencillo, donde solo deberá rellenar casillas.

11
 Especificación de Requisitos, estándar de IEEE 830

3.1.2 Interfaces de hardware

El software deberá mostrar información al usuario a través de la pantalla del
monitor para así poder entregarle una mejor atención a los pacientes.

3.1.3 Interfaces de software

El producto poseerá un sistema operativo Windows 10 ya que posee un mejor
soporte actualmente. Este sistema permitirá futuras actualizaciones del software.

3.1.4 Interfaces de comunicación

La interfaz de comunicación entre el servidor de base de datos MySQL y la
aplicación desarrollada en JAVA se lo realiza mediante JDBC.

3.2 Requisitos funcionales

1. Autenticar el ingreso a registro clínico electrónico  permitirá al
usuario ingresar con un perfil entregado por el sistema para interactuar con
ella, ingresando run sin digito verificador con contraseña asignada por el
sistema.
2. Ingreso de datos clínicos en módulos de la ficha clínica  permite
ingresar todos los datos clínicos que el paciente entregan para formar su
historial médico.
3. Acceso a receta médica de planilla estándar  Corresponde a
documento Word en donde se encuentran los datos necesarios para la
generación de una receta según las condiciones mínimas necesarias:
nombre del médico, RUN, fecha de emisión, medicamento, dosis, horario
firma y timbre médico.
4. Impresión de receta médica  Luego de la competición de la receta, se
imprime para entregar al paciente, con una copia electrónica que llega a la
base de datos del servicio de Farmacia.
5. Adjunción de exámenes médicos a ficha clínica  Corresponde a un
módulo definido en la ficha clínica electrónica en donde se crea carpetas
predefinidas de exámenes según su naturaleza.

12
 Especificación de Requisitos, estándar de IEEE 830

6. Ingreso de fechas de consultas médicas  Módulo que permite el

registro de las horas médicas de los pacientes.
7. Acceso y autenticación en ingreso a BBDD del servicio  Manejo de la
interfaz entre los datos ingresados a nivel usuario y los datos reales
almacenados a los cuales el personal de informática sólo tiene acceso.
8. Timbre electrónico del médico  Permite la validación de la entrega de
los medicamentos.
9. Acceso a historial médico  Permite revisar y analizar el historial médico
del paciente.
10. Agregar diagnostico  Ingresar diagnostico entregado por el médico
durante la atención de los pacientes.
11. Generar reportes en salud  Genera reportes para los indicadores de
salud a nivel nacional.
12. Modificar horario de consultas médicas  Permite la modificación,
postergación y eliminación de horas médicas.
13. "Log Out" de la ficha clínica  Permite el cierre de sesión del usuario
evitando su uso por terceros.

3.3 Requisitos no funcionales

1. Manejo de fichas clínicas electrónicas en sistemas operativos
Windows  Es el sistema operativo adecuado para manejar y manipular el
programa de la FCE con seguridad y agilidad.
2. Accesos restringidos a BBDD  Sólo personal autorizado puede acceder
a este tipo de información.

3.3.1 Requisitos de rendimiento

La infraestructura de red, así como sus terminales deben cumplir con normas
según la IEEE en la forma de conexión a los equipos, para tener tiempos de
respuesta mínimos:

13
 Especificación de Requisitos, estándar de IEEE 830

 Numero de terminales a manejar: Se contará con un servidor de base de

datos en la matriz de la cooperativa.
 Número de usuarios simultáneos: El número de usuarios que interactuaran
simultáneamente con nuestro sistema es de 3 usuarios.
 Número de transacciones a manejar dentro de ciertos periodos de tiempo:
Se estima que se manejará alrededor 100 ingresos de pacientes durante el
día, tomando que se realizaran aproximadamente 200 operaciones diarias,
como ingresos, salidas de pacientes. El servidor de base de datos deberá
tener un respaldo apropiado, así como personal técnico listo para cualquier
eventualidad.

3.3.2 Seguridad
La seguridad del sistema es por:

 Uso de contraseñas para cada usuario. Esto permitirá que tengan acceso al
sistema solo las personas que tienen autorización.
 Registros de ingreso al sistema.
 Creación de roles y asignarlos a cada usuario dependiendo su
funcionalidad.

3.3.3 Fiabilidad
Es uno de los factores que dará confianza al cliente, para lo cual el sistema está
controlando todo tipo de transacción y esta apto a responder todo tipo de
incidente.

3.3.4 Disponibilidad
El sistema ha sido desarrollado tomando en cuenta las necesidades,
requerimientos, reglas, política, misión, objetivos etc. De la cooperativa, por lo que
se encuentra disponible el 99% del tiempo.

14
 Especificación de Requisitos, estándar de IEEE 830

3.3.5 Mantenibilidad
El sistema cuenta con características parametrizables lo que permitirá futuros
mantenimientos. Es decir, cada tres meses se va a realizar un mantenimiento
preventivo, encargado de hacerlo están los desarrolladores. Se realizará el
mantenimiento dos veces sin ningún recargo económico, pasados estas dos
revisiones tendrán costos adicionales.

3.3.6 Portabilidad
Una de las ventajas de utilizar herramientas y lenguajes basados en software libre
estamos garantizando la portabilidad. De esta manera: 99.9% es portable la
aplicación por el simple hecho de utilizar el lenguaje y plataforma JAVA. 99% es
portable la base de datos MySQL, es decir, Windows puede sostenerlo.

3.4 Otros Requisitos

NA

4. Propuesta de Planificación

4.1 Descripción general acerca de la Planificación

[Insertar una descripción de cómo se abordará el trabajo en cuanto a los días
totales estimados y las personas involucradas en su ejecución, las buenas
prácticas y condiciones necesarias a considerar para implementar para su buen
término]

4.1.2 Definición del Equipo de Trabajo

Nombre Integrante del Equipo Rol Definido

Javiera Rodriguez Jerez Ingeniero de Software
Matías Roa Roa Diseñador
Jenniffer Astudillo Tapia Responsable de Pruebas y Calidad
Yuliana Aracena Pérez Jefe del Proyecto

15
 Especificación de Requisitos, estándar de IEEE 830

4.1.3 Definición de Actividades principales del Proyecto

[Descripción de las Principales fases y actividades que considera nuestra
Programación de la Planificación argumentando baj

o que estándares y buenas prácticas se basan (Gestión de la planificación PMI e

Ingeniería de Software – es sólo enunciarlas]

16
 Especificación de Requisitos, estándar de IEEE 830

4.1.4 Diagrama EDT

EDT - Planilla Estructura de descomposición de tareas

ROL ROL ROL RO
Fase de Análisis y diseño DIAS 1 2 3 ROL 4 L5
Captura de requerimientos específicos 14 2 8 8 5 1
Análisis de requerimientos 7 2 4 8 8 1
Diseño de la solución. Modelamientos 2 1 2 8 8 1
Propuesta ERS 1 3 4 6 5 4
Plan de proyecto 2 6 6 6 6 6
ROL ROL ROL RO
Fase de Desarrollo 1 2 3 ROL 4 L5
Implementación ambiente de desarrollo 5 1 2 2 2 2
Construcción componente 1 3 0 3 5 4 2
Construcción componente 2 5 0 6 8 3 3
Construcción componente 3 3 0 6 6 4 3
Construcción componente 4 3 0 6 8 3 4
Construcción componente 5 7 0 6 6 5 5
Integración del sistema 5 4 6 8 6 3
ROL ROL ROL RO
Fase de implementación y cierre 1 2 3 ROL 4 L5
Pruebas unitarias componente 1, 2 1 2 5 6 3 3
Pruebas unitarias componente 3, 4 1 2 4 6 4 3
Pruebas unitarias componente 5 1 2 4 6 3 3
Pruebas de integración 1 4 8 8 8 8
Migración del sistema a producción 7 1 3 5 6 8
Pruebas de integración final 3 3 4 4 4 4
Marcha blanca 7 2 3 5 6 8
Capacitación 7 2 3 4 3 6
Cierre de proyecto 0 0 0 0 0 0

DICCIONARIO EDT
ROL
ACTOR NOMBRE ACTOR
ROL 1 Gerente de Proyecto
ROL 2 Lider de Proyecto
ROL 3 Ingeniero de Sotfware
ROL 4 Diseñador
ROL 5 Resp. Prueba y de calidad

17
 Especificación de Requisitos, estándar de IEEE 830

4.1.5 Carta Gantt

4.1.6 Resumen Costos del Desarrollo del Proyecto

Costo
Se evaluará un monto disponible para el Desarrollo Que el costo del
del Sistema como Costo que oscila entre los Desarrollo se encuentre
$28.000.000 y los $30.000.000 según la solución entre el rango de monto
que se defina como factible. en dinero expresado.

18
 Especificación de Requisitos, estándar de IEEE 830

4.2 Plan de Control de Cambio

[Se recomienda primero describir los tipos de cambio que se podrán resolver y sus
alcances]

[Insertar Tabla de Control de Cambios]

[ Obs.

Insertar Descripción de los aspectos del desarrollo en los que se permitirá aplicar
cambios como parte del Desarrollo del Software definiendo sus alcances y
limitaciones asociadas.

El control de cambios es una actividad paralela al desarrollo del proyecto

que responde a eventos que surgen del mismo, sea por requerimientos propios del
usuario o por mejoras o correcciones detectadas por el mismo equipo
del proyecto.

Se describe de manera independiente de las demás fases de la metodología pues

puede ser aplicada indistintamente a proyectos en marcha o proyectos ya
implementados, y porque es necesario resaltar su importancia y no relegarla como
una actividad posterior al desarrollo, sino reconocerla como una actividad que
debe estar definida, presente y es crítica desde el inicio del proyecto. Deberá
describir que tipo aspectos Funcionalidades y no funcionales se podrán modificar
con cambio, en que instancia de proyecto se podrán aplicar y que motivos los
validarían para ser aplicables y en qué caso no será posible aplicar cambios.

Luego esto se debe complementar con la observación de que en el anexo

encontrarán la Planilla de Control de Cambio con los Tipos de Cambio que podrán
aplicarse en la cual posteriormente se debe completar la planilla al ejecutarse la
instancia. ]

19
 Especificación de Requisitos, estándar de IEEE 830

5. Anexos

5.1 Acta de Proyecto

Nombre del Proyecto

Ficha Clínica Electrónica ELECTROSALUD
Cliente
Servicio de Salud Duoc UC
Stakeholder (Nombre/Cargo)
Director del Servicio de Salud Duoc UC
Jefe de Proyecto / Integrantes del Equipo
Yuliana Aracena Pérez– Jefe del Proyecto
Jenniffer Astudillo Tapia – Responsable de Pruebas y Calidad
Matías Roa Roa – Diseñador del Sistema
Javiera Rodriguez Jerez – Ingeniero de Software
Tiempos Asociados (Inicio y Término)

Objetivo del Negocio

“El objetivo principal de nuestra red de salud es entregar una atención equitativa y de
calidad centrada en las personas y sus familias, enfocada en lo preventivo y promocional,
es decir, anticipándose a la enfermedad, bajo el Modelo de Salud Integral con enfoque
familiar y comunitario” – Servicio de Salud Duoc UC
Necesidad
Modernizar el servicio de atención de urgencias, optimizando el ingreso de pacientes a
través de fichas digitalizadas. Se espera que la ficha de atención y la ficha de solicitud de
medicamentos se automaticen a través de un sistema que permita realizar este proceso
de manera digital disminuyendo los tiempos del proceso, fortaleciendo el sistema de
atención.

20
 Especificación de Requisitos, estándar de IEEE 830

Solución
Desarrollo de una Ficha Clínica Electrónica única para el servicio de salud en cuestión,
que cuente con diferentes módulos para entregar una atención integrada e
interconectada a los pacientes que se atiendan con el objetivo de reducir los tiempos del
proceso e integrándose a las nuevas tecnologías en salud.
Objetivo del Proyecto
Informatizar el desarrollo de nuevas fichas clínicas de los pacientes, con la digitalización
de fichas ya existentes, a través de la creación de un sistema informático capaz de
resguardar, asegurar y manejar los datos clínicos que se generan en el servicio de salud,
permitiendo una atención de calidad a los pacientes.
Objetivos del Desarrollo
Desarrollar e implementar a nivel del PC escritorio un sistema informático íntegramente
en JAVA, con una base de datos desarrollada en MySQL, con una interfaz de aplicación
de fácil acceso para todos los usuarios del sistema.
Descripción de Sistema
(Perspectivas del Producto / Funciones / Características de Usuarios)
- Sistema de ingreso autenticado con Rut y contraseña asignada por área de
informática del servicio de salud.
- Software con diferentes módulos y carpetas de acceso de atención especificada e
integrada con todos los servicios del establecimiento.
- Interconexión de módulo de urgencias y farmacias a través de la generación y
envió de receta médica electrónica.
- Registro, consultas y modificaciones de horas asignadas según agenda médica.
- Registro de motivos de consultas y diagnósticos de las atenciones.
- Generación de estadísticas y reportes para indicadores de salud.
- Consultas de datos del personal de salud.

21
 Especificación de Requisitos, estándar de IEEE 830

Alcances y Restricciones
Alcances del Proyecto:
El proyecto se llevará a cabo con reuniones definidas en conjunto entre ambas partes y
formalizadas en el Carta Gantt del Proyecto.
La fecha de inicio del Proyecto se definirá a partir de la firma de contrato por ambas
partes.
Los plazos acordados para el desarrollo e implementación del sistema partirán de la
fecha de inicio de la firma de contrato.
Debe existir por parte del Cliente, un Stakeholder que cumpla la función de aportar
información de negocio fidedigna para el levantamiento de información.
Alcances y Restricciones del Proyecto:
- El sistema es de uso único para el servicio de salud que lo contrató.
- El sistema es compatible con sistemas mayores para el flujo de información y
trabaja de forma independiente.
- Una vez que el producto entregable es finalizado, la responsabilidad del sistema
cae en manos del encargado del área de Informática del servicio de salud.
- El sistema no permite la apertura de más de 3 fichas de forma simultaneas por
seguridad y para evitar la sobrecarga del software.
- El software es sólo compatible con sistemas operativos de Windows.
- El sistema permite la digitalización de fichas clínicas ya existentes, con el objetivo
de no perder la información clínica.
- Los usuarios del sistema se diferencias según las facultades entregadas por el
Administrador del Sistema.
- El módulo de Farmacias cuenta con acceso a un vademécum para revisar
información farmacológica.
- Si el usuario iniciado no utiliza el sistema dentro un periodo de 15 minutos, éste se
cerrará de forma automática para la protección de datos sensibles.

22
 Especificación de Requisitos, estándar de IEEE 830

Especificaciones Técnicas de Herramientas de Desarrollo

JAVA
Base de Datos MySQL
Tipo de Interfaz de Hardware
Computador escritorio con procesador Dual Core de 3,8 GHz con 4 GB de RAM, disco de
500 GB a 7.200 rpm y conexión LAN de 1 Gb/s
Monitor screen 17” – 19”
Impresora multifunctional HP Officejet Pro 8720
Tipo de Interfaz de Software
Windows 10
Tipo de Interfaz de Usuario
Interfaz Gráfica de Usuario
El software se ejecuta en ventana en Escritorio Windows de forma máxima y mínima

23
 Especificación de Requisitos, estándar de IEEE 830

5.2 Matriz Especificación de Requerimientos

RF. Nombre Tipo Actores relacionados Descripción

RF. 1 Autenticar el Funcional Todos los usuarios Permitirá al usuario
ingreso a ingresar con un perfil
registro clínico entregado por el sistema
electrónico para interactuar con ella,
ingresando Rut sin digito
verificador con contraseña
asignada por el sistema.
RF. 2 Ingreso de Funcional Administrador Técnico Permite ingresar todos los
datos clínicos y Profesional datos clínicos que el
en módulos de paciente entregan para
la ficha clínica formar su historial médico.
RF. 3 Acceso a Funcional Administrador Corresponde a documento
receta médica Profesional Word en donde se
de planilla encuentran los datos
estándar necesarios para la
generación de una receta
según las condiciones
mínimas necesarias:
nombre del médico, RUN,
fecha de emisión,
medicamento, dosis,
horario firma y timbre
médico.

24
 Especificación de Requisitos, estándar de IEEE 830

RF. 4 Impresión de Funcional Administrador Luego de la competición

receta Profesional de la receta, se imprime
médica para entregar al paciente,
con una copia electrónica
que llega a la base de
datos del servicio de
Farmacia
RF. 5 Adjunción de Funcional Administrador Corresponde a un módulo
exámenes Profesional definido en la ficha clínica
médicos a electrónica en donde se
ficha clínica crea carpetas predefinidas
de exámenes según su
naturaleza.
RF. 6 Ingreso de Funcional Administrador Técnico Módulo que permite el
consultas registro de las horas
médicas médicas de los pacientes.
RF. 7 Manejo de No Todos los usuarios Es el sistema operativo
FCE en Funcional adecuado para manejar y
sistema manipular el programa de
operativo las fichas clínicas
Windows. electrónicas con seguridad
y agilidad.
RF. 8 Acceso y Funcional Administrador del Manejo de la interfaz entre
autenticación Sistema los datos ingresados a
en ingreso a nivel usuario y los datos
BBDD del reales almacenados a los
servicio cuales el personal de
informática sólo tiene
acceso.

25
 Especificación de Requisitos, estándar de IEEE 830

RF. 9 Acceso No Administrador del Sólo personal autorizado

restringido a Funcional Sistema puede acceder a este tipo
BBDD de información.
RF.10 Timbre Funcional Administrador Permite la validación de la
electrónico Profesional entrega de los
del médico medicamentos.
RF.11 Acceso a Funcional Administrador Permite revisar y analizar
historial Profesional el historial médico del
médico paciente.
RF.12 Agregar Funcional Administrador Ingresar diagnostico
diagnostico Profesional entregado por el médico
durante la atención de los
pacientes.
RF.13 Generar Funcional Administrador del Genera reportes para los
reportes en Sistema indicadores de salud a
salud nivel nacional.
RF.14 Modificar Funcional Administrador Técnico Permite la modificación,
consultas postergación y eliminación
médicas de horas médicas.
RF.15 "Log Out" de Funcional Todos los usuarios Permite el cierre de sesión
la ficha del usuario evitando su
clínica uso por terceros.

26
 Especificación de Requisitos, estándar de IEEE 830

5.3 Diagrama de Casos de Uso General

27
Especificación de Requisitos, estándar de IEEE 830

28
 Especificación de Requisitos, estándar de IEEE 830

5.4 Planilla Casos de Uso

Caso de Uso Caso de Uso n°1
Actores Administrador Profesional
Tipo Caso de Uso primario
Referencias 1.- Acceso autenticado al sistema
2.- Registro de datos
3.- Acceso a receta médica electrónica
4.- Adjunción de exámenes
5.- Acceso a Historial Médico
6.- Log out de la ficha clínica electrónica
Precondición Para el uso óptimo del sistema, éste debe encontrarse en el
escritorio para su fácil acceso.
Postcondición El sistema podrá ser utilizado por el usuario según sus facultades.
Descripción El usuario podrá acceder al sistema para registrar diagnósticos,
adjuntar exámenes, registrar y autorizar recetas médicas.

Caso de Uso Caso de Uso n°2

Actores Administrador Técnico
Tipo Caso de Uso primario
Referencias 1.- Acceso autenticado al sistema
2.- Registro de horas médicas
3.- Registro de datos de los pacientes
4.- Consultas al sistema
5.- Log out de la ficha clínica electrónica
Precondición Para el uso óptimo del sistema, éste debe encontrarse en el
escritorio para su fácil acceso.
Postcondición El sistema podrá ser utilizado por el usuario según sus facultades.
Descripción El usuario está habilitado admitir al paciente a urgencias, a agendar
horas médicas, consultar horas agendadas y datos del personal,
consultar recetas médicas activas.

29
 Especificación de Requisitos, estándar de IEEE 830

Caso de Uso Caso de Uso n°3

Actores Administrador del Sistema
Tipo Caso de Uso primario
Referencias 1.- Acceso autenticado al sistema
2.- Administración de BBDD
3.- Administración de usuarios
4.- Log out de la ficha clínica electrónica
Precondición Para el uso óptimo del sistema, éste debe encontrarse en el
escritorio para su fácil acceso.
Postcondición El sistema podrá ser utilizado por el usuario según sus facultades.
Descripción El usuario está a cargo de manejar el sistema con gran
responsabilidad sobre los criterios de permisos sobre los usuarios.

30
 Especificación de Requisitos, estándar de IEEE 830

5.5 Prototipado de Software

31
Especificación de Requisitos, estándar de IEEE 830

32
Especificación de Requisitos, estándar de IEEE 830

33
Especificación de Requisitos, estándar de IEEE 830

34
Especificación de Requisitos, estándar de IEEE 830

35
Especificación de Requisitos, estándar de IEEE 830

36
Especificación de Requisitos, estándar de IEEE 830

37
 Especificación de Requisitos, estándar de IEEE 830

5.6 Resultado Análisis de Calidad Diagramas Modelamiento

Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de
Análisis de Calidad de modelado de Software.

5.7 Resultado Análisis de Calidad Prototipado No funcional del

Sistema
Insertar Resultado del Análisis de Calidad basado en los estándares y la Planilla de
Análisis de Calidad de Prototipo de Interfaz de Usuario.

5.8 Planilla entregables del Proyecto

PLANTILLA DE ENTREGAGLES
ENTREGABLE DEL ANALISIS DESCRIPCION
- Captura de Requisitos Análisis de requisitos y descripción
- Especificación del sistema Requisitos de datos, hardware y
descripción
- Plan de Pruebas Funcionalidad del sistema
ENTREGABLES DISEÑO
- Interfaces, tanto humanos como de Descripción detallada del sistema
máquinas
ENTREGABLES DE CODIFICACION
- Cadenas de ejecución Resultado de
las pruebas de cada unidad y
programa
-

5.9 Matriz de Control de Cambios

Versión Causa del Cambio Responsable del Cambio Fecha del Cambio
0100 Versión inicial <Nombre Apellido1 Apellido2> DD/MM/AAAA

38
 Especificación de Requisitos, estándar de IEEE 830

5.10 Matriz EDT. Planilla Detallada Cálculo de Esfuerzo

ACTIVIDADES
Fase de Planificación DIAS JP ING SOFT DI RPYC
Kick Off 1 4 4 2 0
Acta de Constitución de proyecto 4 5 5 1 1
Aprobación del Acta 4 5 5 1 1
Definición de requerimientos Generales del proyecto 1 6 6 6 0
Organización del equipo 1 4 4 4 4
Fase de Análisis y diseño ROL 1 ROL 2 ROL 3 ROL 4
Captura de requerimientos específicos 14 8 8 5 2
Análisis de requerimientos 7 4 8 8 2
Diseño de la solución. Modelamientos 2 2 8 8 2
Propuesta ERS 1 4 6 5 4
Plan de proyecto 2 6 6 6 6
Fase de Desarrollo ROL 1 ROL 2 ROL 3 ROL 4
Implementación ambiente de desarrollo 5 2 2 2 2
Construcción componente 1 3 3 5 4 2
Construcción componente 2 5 6 8 3 3
Construcción componente 3 3 6 6 4 3
Construcción componente 4 3 6 8 3 4
Construcción componente 5 7 6 6 5 5
Integración del sistema 5 6 8 6 3
Fase de implementación y cierre ROL 1 ROL 2 ROL 3 ROL 4
Pruebas unitarias componente 1, 2 1 5 6 3 3
Pruebas unitarias componente 3, 4 1 4 6 5 3
Pruebas unitarias componente 5 1 4 6 3 3
Pruebas de integración 1 8 8 8 8
Migración del sistema a producción 7 3 5 6 8
Pruebas de integración final 3 4 4 4 4
Marcha blanca 7 3 5 6 8
Capacitación 7 3 4 3 6
Cierre de proyecto 2 2 2 2 2
SIGLA ROL NOMBRE VALOR HH FASE PLANIFICACION
JP Jefe de Proyecto YULIANA ARACENA $ 23.404 $ 2.785.076
ING SOFT Ing. de Software JAVIERA RODRIGUEZ $ 18.790 $ 2.799.710
DI Diseñador MATIAS ROA $ 16.780 $ 1.896.140
RPYC Responsable PYC JENNIFFER ASTUDILLO $ 13.456 $ 1.197.584

39