Titulo:

Herramienta Web para control de insumos farmacéuticos, personal, expedientes de pacientes

con aplicación de vos IP para mejorar gestión y atención hacia los pacientes del Centro de
Salud de Quetzaltenango ubicada 13 Avenida, 4-51 zona 3 Quetzaltenango, Quetzaltenango.

Falta de eficiencia en el registro de los insumos farmacéuticos, incertidumbre sobre el

personal activo en la jordana laboral, control deficiente de expediente de pacientes y
comunicación no efectiva entre las áreas del centro de Salud.

Esta es una versión preliminar del desarrollo del software, la cual es un plan que se
prepara para incluirla en la propuesta elaborada como respuesta al proyecto de
creación de un TPS (Sistema de procesamiento de datos) a la medida para el Centro
de Salud de la Ciudad de Quetzaltenango ubicada en 13 Avenida, 4-51 zona 3
Quetzaltenango, brinde información en tiempo real de la situación del personal activo
en su turno laboral, el inventario de los insumos que existen en sus almacenes o
bodegas, el equipo o inmobiliaria que tiene asignado cada personal, el estado sobre el
vencimiento de los medicamentos de cada uno de los insumos distribuidos en cada
área o departamento dentro del centro de salud. Este documento provee una visión
global del enfoque de desarrollo propuesto.
El proyecto se apoya en la metodología de Rational Unified Process (RUP), el cual se
hará mención a lo largo del documento. Se incluirá el modelo del negocio y el alcance
del proyecto. Se identifican todos los actores y casos de uso. Se desarrolla un plan de
negocio para determinar qué recursos deben ser asignados al proyecto.
El desarrollo propuesto constituye una configuración del proceso RUP de basado en
las características del proyecto, definimos las actividades a realizar y los artefactos
(entregables) que serán generados. Este documento es a su vez uno de los artefactos
de RUP.

La razón del Plan de Desarrollo de Software es brindar información necesaria para el

control del proyecto. En el que se describe el camino del desarrollo del software.
El usuario del Plan de Desarrollo del Software es:

• Analista y Diseñador del proyecto, en la cual se analizara los procesos a

automatizar para mejorar el desempeño de atención a los pacientes y hacer
más efectivo el tiempo invertido en la jornada laboral.

• El desarrollo se usara para entender lo qué deben hacer, cuándo debe hacerse
y qué otras actividades dependen de ello.
El Plan de Desarrollo del Software describe de forma global el desarrollo del “Sistema
TPS Centro de Salud Pública”. Los detalles de las iteraciones individuales se proyectan
en los planes de cada iteración, los documentos se aportan en forma separada.
Definimos en la Visión las características del producto a desarrollar, lo cual establece
la base para la planificación de las iteraciones. Para la versión 0.1 del Plan de
Desarrollo del Software, nos hemos basado en la captura de requisitos por medio del
stakeholder que represen a la organización y la observación operacional hacia el
personal para hacer una estimación aproximada, una vez comenzado el proyecto y
durante la fase de Inicio se generará la primera versión de la Visión, el cual se utilizará
para refinar este documento. Posteriormente, el avance del proyecto y el
seguimiento en cada una de las iteraciones ocasionará el ajuste de este documento
produciendo nuevas versiones actualizadas.

El documento está organizado en las siguientes secciones:

Vista General del Proyecto — Brinda una descripción del propósito, su alcance y los
objetivos del proyecto, estableciendo los artefactos que serán producidos y utilizados
durante el proyecto.
Gestión del Proceso — explica los costos y planificación estimada, define las fases e
hitos del proyecto y describe cómo se realizará su seguimiento.
Infraestructura — proporciona los requerimientos necesarios para poder implementar
la solución propuesta. Son los requisitos para que el sistema funcione decuadamente.

La información que a continuación se desglosa ha sido recopilada de diferentes

reuniones que se han realizado con el director del centro de Salud y el personal
operativo desde el inicio del proyecto.
Centro de Salud Pública es una organización que se dedica a brindar consultas y
atención médica, vacunaciones, heridas leves y el horario ampliado con el centro de
atención Permanente (CAP), por lo cual brinda el servicio las 24 horas del día. La
demanda por parte de la población que no cuenta con los recursos necesarios para
asistir a una clínica médica privada y el crecimiento de la consultas y visitas conllevará
una previsible adaptación a los nuevos sistemas de información y a la evolución
tecnológica. Por ello, Centro de Salud Pública considera necesario el desarrollo de un
sistema de procesamiento de transacciones (TPS) para el control adecuado de cada
uno de sus procesos y su automatización. Dicho sistema deberá proporcionar
información en tiempo real de la situación de insumos médicos y su vigencia
(vencimiento), la localización del mobiliario y equipo asignado al personal, como un
mejor control sobre los pacientes y sus expedientes, mejorar la comunicación entre
las distintas ares y departamentos.
Las características requeridas del sistema deberán ser las siguientes:

• Planeación de proyectos de inversión (Conformación de presupuestos). Se deberá

llevar a cabo la gestión de: o gestión de proyectos o presupuestos o gastos o gastos
internos y facturables o informes de actividades o registro de servicios o
estimaciones
• Control de almacenes por servicio (entradas/salidas). Se deberá controlar:
o almacenes por insumos y su
respectivo “stock”
o atributos del producto en
almacén o movimientos entre
almacenes o inventario de obras
(físico) o movimientos en lotes,
números de serie, bultos,
etiquetas o entradas, salidas e
inventarios.
• Control y registro de Paciente (Llevar su historial y expediente). Se debe gestionar:
o avance de expediente, recursos
otorgados a paciente
(medicamento o servicios).
• Administración insumo o mobiliario y equipo
o Medicamentos asignados y
ejecutados por persona,
mobiliario, equipo médico o
equipo de cómputo asignado a
personal.
• Registro y control de servicios utilizados
por paciente:
o Servicios utilizado por paciente
en centro de salud: Vacunación,
control prenatal, postnatal,
consulta general, farmacia y
otras.
• Creación de medio de comunicación
digital para conectar a las distintas áreas
o departamento de Centro de Salud
Pública.
o Comunicación a través de VOZ IP
dentro de red WLAN Local,
virtualizando planta telefónica.

Las suposiciones y restricciones respecto del sistema, y que se derivan directamente

de los requerimientos de la empresa son: a) Uso de la metodología RUP
 b) Uso de tecnología Microsoft
c) Uso de la herramienta Linux para mini servidor.
d) Uso de software Libre.
Como es natural, la lista de suposiciones y restricciones se incrementará durante el
desarrollo del proyecto, particularmente una vez establecido el artefacto “Visión”.

A continuación se indican y describen cada uno de los artefactos que serán generados
y utilizados por el proyecto y los cuales serán aquellos a entregar a la organización.
Esta lista está configurada con RUP desde la perspectiva de artefactos, y que
proponemos para este proyecto.

De acuerdo a RUP (y de todo proceso iterativo e incremental), todos los artefactos son
objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término del
proceso podríamos tener una versión definitiva y completa de cada uno de ellos. Sin embargo,
el resultado de cada iteración y los hitos del proyecto están enfocados a conseguir un cierto
grado de completitud y estabilidad de los artefactos.

Este modelo permite visualizar el alcance de la organización, representando lo que

abarca y cuáles son sus límites. Así mismo, modela las actividades y procesos que
ejecuta una organización y metas que persigue la organización, y también permite
identificar cuáles son los roles y entregables de la organización.

Es un modelo de las funciones de negocio vistas desde la perspectiva de los

actores externos (Agentes de registro, pacientes, otros sistemas etc.), permite situar al
sistema en el contexto organizacional haciendo énfasis en los objetivos en este
ámbito. Este modelo se representaremos con un diagrama de clases conceptuales.

Este documento define la visión del software desde la figura del cliente,
especificando las oportunidades, necesidades y características del producto.
Constituye una base de acuerdo en cuanto a los requisitos del sistema.

El objetivo de este documento es registrar todos los requerimientos del sistema,

especificar las funciones del sistema, los requerimientos no funcionales, las
características del diseño y otros elementos necesarios para proporcionar una
descripción completa y comprensiva de los requerimientos para el software a
desarrollar.
 El modelado de los Casos de Uso presenta los procesos del sistema y los actores
que interactúan con ellas. Este modelo se basa en la descripción de elementos o
usuarios externos al sistema (actores) y de la funcionalidad del sistema (casos de uso).
Un modelo de casos de uso describe los requerimientos funcionales de un actor en
términos que éste interactúa con el sistema. Este modelo lo representaremos con el
modelo de casos de uso.

El presente documento describirá el proyecto solamente el flujo de eventos

principales para cada caso de uso. Se desplegara una descripción corta y sencilla.

Es una abstracción de los paradigmas encontrados en los procesos del negocio y

del Modelo de Implementación y su código fuente, el cual fundamentalmente se
emplea para representar y documentar su diseño. Es usado como referencia esencial
en las actividades relacionadas a la implementación. Representa a los casos de uso en
respuesta como la solución. El modelo de diseño lo representaremos con los
diagramas de clases, diagramas de secuencia y el modelo de datos.

Describe la representación en diagrama físico y lógico de los datos constantes

utilizados por la aplicación. Se utilizará siempre que se necesiten manejar datos.
Usualmente describirá los diferentes elementos componentes de la estructura de una
base de datos relacional.

El Modelo de Implementación está compuesto por un conjunto de módulos y

subsistemas que constituyen la composición física de la implementación del sistema.
Entre los componentes relacionados a los módulos podemos encontrar datos,
archivos, ejecutables, código fuente y los directorios. Fundamentalmente, se describe
la relación que existe desde los paquetes y clases del modelo de diseño a subsistemas
y componentes físicos. Para representar los diagramas del Modelo de Implementación
emplearemos el diagrama de UML de Componentes.

Los procedimientos de prueba, son artefactos incluyen un propósito en las

pruebas, qué procesos se van a probar y las herramientas a utilizar. Al tener el
resultado de las pruebas se puede comparar lo obtenido con lo esperado.
 En este paso se define los datos de entradas, condiciones de ejecución y
resultados esperados de las pruebas, se identificara las evaluaciones correspondientes
para verificar resultados esperados. Cada Prueba está asociado a un escenario de un
Caso de Uso en particular.

Es el producto final, es decir, el sistema ya funcionando que puede ser instalado y

ser utilizado por el cliente. Un Sistema se diferencia de una unidad de implantación, ya
que el sistema puede contener varias unidades de implantación. Cabe destacar que el
sistema será hospedado localmente en una computadora utilizada como servidor y su
acceso será para aquellos que se asocien a la red interna a través de wi-fi o conexión
alámbrica por RJ-47.

El objetivo principal del plan de implementación es asegurar que el sistema llegue

satisfactoriamente a los usuarios finales. Se debe definir un conjunto de tareas que
defina una transición sencilla para el usuario, para ello se debe minimizar el impacto
del uso incorrecto del sistema para información coherente y útil para la organización,
los sistemas de control existentes y en todas las rutinas del negocio.

El objetivo principal del plan de implementación es asegurar que el sistema

llegue satisfactoriamente a los usuarios finales. Se debe definir un conjunto de tareas
que defina una transición sencilla para el usuario, para ello se debe minimizar el
impacto del uso incorrecto del sistema para información coherente y útil para la
organización, los sistemas de control existentes y en todas las rutinas del negocio.

Dicha documentación proveerá una ayuda a las personas que manipularen

directamente el software, orienta el uso que se le debe dar al sistema y su instalación.

Para realizar la estimación determinamos el número de actores y casos de uso

identificados en el sistema TPS la atención de los pacientes y mejora de tiempos a través de la
automatización de procesos. De esta forma, identificamos nuestros puntos de caso de uso no
ajustados, y después se determinaron los puntos de casos de uso basados en factores técnicos
y ambientales.