Analista de Sistemas:
Luis Capañari (LC) posteriormente dar soporte a los usuarios finales.Aprender cómo se implantan los módulos para Medio Positivo Incluirlo en la planificación del proyecto y laimplantación de los módulos. -
12 Gerente de proyecto:
Janis Candia (JC)
Que los módulos del sistema sean implantados correctamente satisfaciendo todos los requisitos
establecidos. Muy Alto
Positiv o No aplica - 13 Consultores PMI SAC: Oscar Valderrama (OV)
Que los módulos del sistema sean implantados correctamente satisfaciendo todos los requisitos
establecidos. Medio
Positiv
o Incluirlo en la planificación del proyecto. -
14 Consultores PMI SAC:
Fredy Aranda (FA)
Que los módulos del sistema sean implantados correctamente satisfaciendo todos los requisitos
establecidos. Medio
Positiv
o Incluirlo en la planificación del proyecto. -
________________________________________________________________________________________________________________________________________________________________________________ _
Nro. ( INTERESADO
PERSONAS O GRUPOS) INTERÉS EN EL PROYECTO
EVALUACIÓN DE IMPACTO
TIPO DE IMPACTO
ESTRATEGIA POTENCIAL PARA GANAR SOPORTE O REDUCIR OBSTÁCULOS OBSERVACIONES Y COMENTARIOS 15 Arquitecto PMI SAC: Gustavo Espinoza (GE)
Que el sistema sea instalado correctamente. Medio Positivo Incluirlo en la planificación del proyecto. -
16
Capacitadores PMI SAC:
Ivan Manta (IM) Que los usuarios finales aprendan a utilizar todas lasfuncionalidades del sistema. Bajo Positivo Informar sobre los objetivos de lascapacitaciones a realizar. -
17 Capacitadores PMI SAC:
Gabriela Ulloa (GU)
Que los usuarios finales aprendan a utilizar todas las
funcionalidades del sistema. Bajo Positivo Informar sobre los objetivos de lascapacitaciones a realizar -
18
Organismos gubernamentales :
SUNASA (SUNASA)
Qué se cumpla con la normativa dispuesta por estos
organismos Medio Positivo Incluir su normativa como puntos a verificardentro del proyecto -
19 Organismos gubernamentales : MINISTERIO DE SALUD (MINSA)
Qué se cumpla con la normativa dispuesta por estos
organismos Medio Positivo Incluir su normativa como puntos a verificardentro del proyecto -
20 Otros Organismos: Pacifico EPS y Seguros (PACIF)
Qué se cumplan los convenios establecidos. Medio Positivo Incluir los convenios y reglas de negocio deestas entidades -
21
Otros Organismos: Rímac EPS y Seguros (RIMAC)
Qué se cumplan los convenios establecidos. Medio Positivo Incluir los convenios y reglas de negocio deestas entidades -
_________________________________________________________________________________________________________________
7.
MATRIZ DE
EVALUACIÓN DE
INTERESADOS
Sistema de Gestión
Ambulatoria
CONTROL DE VERSIONES
Versi
ón
Hechapor
Revisada por
Aprobadapor
Fecha
Motivo
_________________________________________________________________________________________________________________
7.1
MATRIZ DE INTERESADOS INFLUENCIA
VS PODER
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
_________________________________________________________________________________________________________________
7.2 MATRIZ DE INTERESADOS IMPACTO VS
PODER
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
IMPLANTACIÓN DEL SISTEMA DE GESTIÓN AMBULATORIA SIGAM
10
8
6
4
2
0
2
4
6
8
10
LG, CF, MA
SC
MB
AR
JP,FM
PR
JC
LC
JC
OV, FA
GE
IM, GU
SUNASA
MINSA, PACIF, RIMAC
PODER
IM
P
A
C
T
O
_________________________________________________________________________________________________________________
7.3 MATRIZ DE INTERESADOS INFLUENCIA
VS IMPACTO
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
_________________________________________________________________________________________________________________
7.4 DIAGRAMA DE VENN
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
_________________________________________________________________________________________________________________
7.5 DOCUMENTO VALORATIVO
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO
IMPLANTACIÓN DEL SISTEMA DE GESTIÓN AMBULATORIA SIGAM
INTERESADO
PODER
INFLUENC
IA
IMPACTO
TOTAL
Directorio:
Luis González (LG)10
8
10
28
Camila Fernández (CF)10
8
10
28
Miguel Abanto (MA)
10
8
10
28
Sponsor:
Sebastián Céspedes (SC)
10
10
10
30
Gerente de Proyecto:
Micaela Barrientos (MB)
7
10
10
27
Líder Funcional:
Aldo Ricardi (AR)
6
8
8
22
Julio Perales (JP)
7
8
7
22
Franco Medina (FM)7
8
7
22
Analista Funcional: Pamela Ramos (PR)3
5
5
13
Jorge Cisneros (JC)3
6
5
14
Analista de Sistemas: Luis Capañari (LC)5
8
7
20
Gerente de proyecto: Janis Candia (JC)8
10
7
25
Consultores PMI SAC:
Oscar Valderrama (OV)
4
4
5
14
Fredy Aranda (FA)
4
4
5
14
Arquitecto PMI SAC:
Gustavo Espinoza (GE)
4
5
7
16
Capacitadores PMI SAC:
Iván Manta (IM)
4
2
5
11
_________________________________________________________________________________________________________________
Organismos gubernamentales:
SUNASA (SUNASA)
2
2
2
6
MINISTERIO DE SALUD (MINSA)
2
2
2
6
Otros Organismos:
Pacifico EPS y Seguros (PACIF)
2
2
2
6
_________________________________________________________________________________________________________________
8.
PLAN DE GESTIÓN DE
REQUISITOS
Sistema de Gestión
Ambulatoria
CONTROL DE VERSIONES
Versi
ón
Hechapor
Revisada por
Aprobadapor
Fecha
Motivo
_________________________________________________________________________________________________________________
PLAN DE GESTIÓN DE REQUISITOS
NOMBRE DEL PROYECTO
SIGLAS DEL PROYECTO
Implantación del Sistema de Gestión
Ambulatoria
SIGAM
INTRODUCCIÓN
El propósito del Plan de Gestión de Requisitos del proyecto SIGAM es la de establecer
y mantener un acuerdo entre la Clínica San Marcos (cliente) y Consultores PMI
(proveedor) con respecto a los requisitos; lo cual representa el alcance del producto
que será dirigido en el proyecto.
Los requisitos serán la base para estimar, planear, ejecutar y controlar las
actividades durante toda la duración del proyecto.
Este plan se ocupa de cómo el proyecto SIGAM administrará la configuración del
producto y sus cambios debido a modificaciones en los requisitos, para asegurar que
las necesidades iniciales del cliente y los objetivos del proyecto estén asignados
dentro de los requisitos funcionales y no funcionales necesarios para implantar el
producto.
Aquí se detalla el proceso, tomando en cuenta los siguientes puntos:
Asignación de responsabilidades.
Identificación de técnicas a implementar.
Las herramientas a usar.
Desarrollo de documentación adecuada.
Es responsabilidad del Gerente de Proyecto asegurarse de que el equipo conozca y
siga este plan y el proceso asociado, también dar a conocer quiénes son los
responsables nombrados.
ACTIVIDADES DE LA GESTIÓN DE REQUISITOS
IDENTIFICACIÓN DE REQUISITOS
Luego de identificar a los principales interesados del proyecto, se procederá a
obtener los requisitos tanto del proyecto como del producto, mediante:
Entrevistas y/o
Encuestas
Dependiendo de la disponibilidad de los interesados, se evaluará la herramienta a
usar.
Cada requisito deberá tener un identificador único y deberá detallarse en el
documento de requisitos.
Para verificar la funcionalidad se puede presentar al cliente los casos de uso, si es
necesario.
ANÁLISIS DE REQUISITOS
En el caso de tener requisitos ambiguos o incompletos se procederá a la
elaboración de prototipos para ser contrastados con el cliente.
Se desarrollará la Matriz de Trazabilidad de Requisitos para verificar que cada
requisito cubra las necesidades y objetivos presentados por los interesados.
Luego de tener todos los requisitos verificados se procederá a la aprobación por
_________________________________________________________________________________________________________________
ACTIVIDADES DE LA GESTIÓN DE REQUISITOS
IDENTIFICACIÓN DE REQUISITOS
Luego de identificar a los principales interesados del proyecto, se procederá a
obtener los requisitos tanto del proyecto como del producto, mediante:
Entrevistas y/o
Encuestas
Dependiendo de la disponibilidad de los interesados, se evaluará la herramienta a
usar.
Cada requisito deberá tener un identificador único y deberá detallarse en el
documento de requisitos.
Para verificar la funcionalidad se puede presentar al cliente los casos de uso, si es
necesario.
ANÁLISIS DE REQUISITOS
parte del cliente.
Los criterios de aprobación serán descritos en el documento de requisitos.
PRIORIZACIÓN DE REQUISITOS
La priorización de los requisitos se realizará en base a la Matriz de Trazabilidad de
Requisitos, de acuerdo al nivel de estabilidad y el grado de complejidad de cada
requisito documentado.
Este proceso será realizado por el equipo de gestión del proyecto durante la
planificación del proyecto, y será aprobado por el Sponsor.
Esta matriz deberá ser generada de manera periódica de acuerdo a las fechas de
celebración de las reuniones programadas del equipo de gestión, estipuladas
dentro de la agenda.
ADMINISTRACIÓN DE CAMBIOS EN LOS REQUISITOS
El proceso de administración de cambios en los requisitos se usará para administrar
eliminaciones, modificaciones y adiciones dentro de la misma línea base o para
modificar formalmente la misma.
Para las actividades de cambio de requisitos se realizará lo siguiente:
El iniciador de un cambio será un individuo autorizado a firmar la “solicitud de
cambio”, detallando el por qué del cambio solicitado. El iniciador debe
comprender que todo cambio tiene un costo desde el momento mismo en que
completa y firma la solicitud de cambio pues aunque no se apruebe, la evaluación
previa requiere de esfuerzo, tiempo y dinero.
El Gerente de Proyecto elaborará en conjunto con su equipo de trabajo el análisis
de impacto, responsabilizándose por tal análisis.
Cuando se haya finalizado el análisis del impacto, éste será enviado al comité de
cambios.
El comité de cambios está conformado por un representante del cliente y dos
representantes del proveedor.
El Comité de cambios evaluará el impacto en el proyecto (nivel de costos,
tiempos, alcance y dependencias).
Si el cambio es aprobado el proceso continúa, el comité adicionará un indicador
que considere el beneficio o prioridad del cambio y lo reportará al equipo de
gestión del proyecto para su respectiva implementación, de lo contrario se
procede al cierre de la solicitud y se comunica al iniciador. Un representante del
comité de cambios firma la solicitud respaldando la resolución tomada.
El iniciador, al ser comunicado de la decisión, firmará la solicitud indicando que ha
tomado conocimiento de la resolución.
_________________________________________________________________________________________________________________
ACTIVIDADES DE LA GESTIÓN DE REQUISITOS
IDENTIFICACIÓN DE REQUISITOS
Luego de identificar a los principales interesados del proyecto, se procederá a
obtener los requisitos tanto del proyecto como del producto, mediante:
Entrevistas y/o
Encuestas
Dependiendo de la disponibilidad de los interesados, se evaluará la herramienta a
usar.
Cada requisito deberá tener un identificador único y deberá detallarse en el
documento de requisitos.
Para verificar la funcionalidad se puede presentar al cliente los casos de uso, si es
necesario.
ANÁLISIS DE REQUISITOS
Si la solicitud fue aprobada, el Gerente de Proyecto junto con el Jefe de Control de
cambios priorizarán los diferentes cambios aprobados.
Durante la priorización y planificación se determinará el orden en el que los
cambios aprobados serán ejecutados. Se define cuando serán ejecutados y en que
versión del producto serán aplicados (actual o subsiguientes).
El Gerente de Proyecto junto con el Jefe de Control de cambios actualizarán las
especificaciones de requerimientos de software y efectuarán las modificaciones
pertinentes en el plan de proyecto.
Luego se procede a las pruebas y su posterior implantación.
El Jefe de Control de cambios formaliza el cierre del cambio.
Herramientas:
Se contará con las siguientes herramientas:
La planilla “Solicitud de Cambios en los Requerimientos”.
El documento “Especificaciones de Requerimientos del Software” (SRS).
Se utilizará el programa SmartSVN para el versionamiento de los documentos.
RESPONSABILIDADES EN LA ADMINISTRACIÓN DE REQUISITOS
Se contará con los siguientes responsables:
Administrador de requisitos: Responsable de la gestión de la configuración de los
requisitos y cambios de requisitos.
Gerente del Proyecto: Responsable de recibir solicitudes de cambios de requisitos
y de validar los requisitos con los interesados.
MÉTRICAS DEL PRODUCTO
Todos los requisitos deberán ser implementados al 100%.
El sistema no deberá consumir más del 50% de los recursos del servidor donde
este alojado ya que ahí se alojan aplicativos existentes.
Se tomarán encuestas en cada reunión con el cliente, para medir el nivel de
satisfacción del trabajo realizado a la fecha. Estas encuestas considerarán tiempo
de entrega, nivel de informes presentados, eficiencia de las reuniones. Se
establecerá una escala para definir si el cliente está satisfecho o insatisfecho.
_________________________________________________________________________________________________________________
En la Matriz de Trazabilidad se documentará la siguiente información:
Atributos de requisitos, que incluye: código, descripción, sustento de inclusión,
propietario, fuente, prioridad, versión, estado actual, fecha de cumplimiento, nivel
de estabilidad, grado de complejidad y criterio de aceptación.
Trazabilidad hacia:
2.
Necesidades, oportunidades, metas y objetivos del negocio.
1.
Objetivos del proyecto.
2.
Alcance del proyecto, entregables del WBS.
3.
Estrategia de prueba.
4.
Escenario de prueba.
5.
Requerimiento de alto nivel.
_________________________________________________________________________________________________________________
9.
DOCUMENTACIÓN DE
REQUISITOS
Sistema de Gestión
Ambulatoria
CONTROL DE VERSIONES
Versi
ón
Hecha
por
Revisada por
Aprobada
por
Fecha
Motivo
_________________________________________________________________________________________________________________
DOCUMENTACIÓN DE REQUISITOS
NOMBRE DEL PROYECTO
SIGLAS DEL PROYECTO
Implantación del Sistema de Gestión
Ambulatoria
SIGAM
NECESIDAD DEL NEGOCIO U OPORTUNIDAD A APROVECHAR
Se ha identificado, que en el mercado actual nacional, muchas de las soluciones que
utilizan los Centros de Atención Ambulatoria no se encuentran integradas en un solo
sistema, trabajan con diferentes aplicaciones para manejar historias clínicas y
administrar atenciones ambulatorias.
Adicionalmente estos centros de atención ambulatoria por lo general están
vinculados a las EPS y a sus planes de salud para atender a los pacientes afiliados a
estas entidades que cuentan con diversos beneficios ofrecidos en sus planes de
salud. El disponer de la información de cada beneficio de planes de salud es crítico
al momento de identificar al paciente para iniciar el proceso de atención
ambulatoria. La solución debe manejar la diversidad y particularidad de cado uno de
los beneficios que ofrecen las EPS para cada paciente. La necesidad de tener la
información a tiempo y exacta en los centros de atención ambulatoria se hace
crítica también debido a la gran cantidad de pacientes que provienen de alguna
EPS. En tal sentido, se requiere responder a los requerimientos de los pacientes de
forma oportuna para garantizar una operación fluida considerando que esto se
encuentra ligado directamente a los ingresos del centro de Atención Ambulatoria.
Con la finalidad de realizar la identificación de pacientes provenientes de las EPS,
sus planes y sus beneficios de una manera eficiente, la SEPS ha creado una solución
que propone realizar una comunicación eficaz entre los agentes participantes en los
servicios de salud en este caso los Centros de atención Ambulatoria y las EPS. Esta
solución se denomina Sistema Integrado para Transacciones Electrónicas en Datos
de Salud (SITEDS). Esto significa que cualquier solución que una clínica desee
implementar debería hacer uso de este componente para que funcione con los
planes y beneficios de las EPS de manera más eficiente y eficaz.
Los centros de atención ambulatoria, sobre todo cuando prestan servicios de salud
ambulatorio a pacientes asegurados en las EPS y requieren tratar con los diversos
planes y beneficios que se comportan de manera diferente, tienen la necesidad de
contar con una solución que gestione los servicios ambulatorios y que sea capaz de
tomar en cuenta la diversidad de planes y beneficios que poseen las distintas EPS,
así como la forma de tratamiento de estos, tanto al momento del proceso de
admisión y atención de pacientes, como para la posterior facturación hacia estas
entidades privadas.
OBJETIVOS DEL NEGOCIO Y DEL PRODUCTO
Objetivos del Negocio:
Optimizar y sistematizar el proceso de gestión ambulatoria.
Registro y control adecuado de los planes de salud.
_________________________________________________________________________________________________________________
Mejorar el control de las admisiones para verificar consumos de los pacientes.
Precisión y control del proceso de facturación.
Facilitar el acceso al sistema, teniendo un solo sistema integrado.
Aumentar la confidencialidad de la información.
Objetivos del Proyecto:
Cumplir los requerimientos establecidos por el cliente para la implantación del
Sistema de Gestión Ambulatoria.
Concluir el proyecto en el plazo solicitado por el cliente, y con el presupuesto
asignado.
Todos los entregables deben iniciarse y completarse en las fechas programadas.
REQUISITOS FUNCIONALES INTERESAD O PRIORIDAD OTORGAD A POR EL INTERESA DO REQUISITOS CÓDIGO DESCRIPCIÓN Franco Medina Gerente de Operaciones (Cliente)
Alta
R01
El sistema permitirá registrar admisiones depacientes que cuenten con algún plan de las
EPS.
Alta
R02
El sistema permitirá registrar admisiones de
pacientes que cuenten con algún plan de la
propia clínica.
Alta
R03
El sistema permitirá registrar admisiones de
pacientes que cuenten con algún plan de
alguna financiadora distinta de las EPS.
Alta
R04
El sistema permitirá registrar admisiones de
pacientes que no posean ningún plan
(pacientes particulares).
Alta
R05
El sistema permitirá obtener los datos delpaciente a través del SITEDS.
Alta
R06
El sistema permitirá distinguir y elegir entre los
distintos planes y beneficios que el paciente
pudiese tener devueltos por la consulta al
SITEDS.
Alta
R07
El sistema permitirá distinguir y elegir entre los
distintos planes y beneficios que el paciente
pudiese tener devueltos por la consulta a la
base de datos local.
Alta
R08
El sistema permitirá imprimir las órdenes deadmisión generadas.
Media
R09
El sistema permitirá generar reportes de lasadmisiones que se han generado.
Aldo RicardiGerente de Facturación
(Cliente)
Alta
R10
El sistema permitirá registrar los servicios quelos pacientes con admisiones activas deseen
recibir.
Alta
R11
El sistema permitirá generar órdenes deatención.
Alta
R12
El sistema permitirá imprimir las órdenes de
_________________________________________________________________________________________________________________ REQUISITOS FUNCIONALES INTERESAD O PRIORIDAD OTORGAD A POR EL INTERESA DO REQUISITOS CÓDIGO DESCRIPCIÓN
atención generadas indicando los servicios que
el paciente desea hacer uso.
Alta
R13
El sistema permitirá elegir al médico que daráel servicio que el paciente desee consumir.
Alta
R14
El sistema permitirá calcular el monto total que
deberá pagar el paciente por los servicios que
va a consumir teniendo en cuenta el plan y
beneficio registrado en la admisión.
Alta
R15
El sistema permitirá identificar internamente
los consumos registrados según el grupo de
servicio al que pertenecen.
Media
R16
El sistema permitirá generar reportes de losconsumos que poseen las admisiones.
Alta
R17
El sistema permitirá marcar los servicios que ya
fueron recibidos por los pacientes para que
estos puedan ser facturados.
Julio Perales
Gerente de Tesorería
(Cliente)
Alta
R18
El sistema permitirá realizar la apertura decaja.
Alta
R19
El sistema permitirá realizar el cierre de caja.
Alta
R20
El sistema permitirá registrar pagos en soles y
dólares efectuados por los pacientes según los
servicios que escogieron en el módulo de
consumos.
Alta
R21
El sistema permitirá emitir documentos depago.
Alta
R22
El sistema permitirá efectuar anulaciones dedocumentos de pago.
Media
R23
El sistema permitirá generar reportes deliquidación de caja.
Alta
R24
El sistema permitirá registrar el tipo de cambiodel día.
Aldo Ricardi
Gerente de Facturación
(Cliente)
Alta
R25
El sistema permitirá aprobar admisiones paraque puedan ser facturadas.
Alta
R26
El sistema permitirá registrar facturacionesrealizadas hacia las empresas financiadoras.
Alta
R27
El sistema permitirá emitir facturas hacia losfinanciadores.
Alta
R28
El sistema permitirá mostrar reportes de
sustento de facturación con los consumos de
las admisiones agrupadas por grupos de
servicio.
Alta
R29
El sistema permitirá hacer seguimiento de lasadmisiones candidatas a ser facturadas.
Luis Capañari Gerente de Facturación (Cliente)Alta
R30
Los usuarios del sistema solamente podrán
acceder a este luego de autenticarse con su
nombre de usuario y su contraseña.
_________________________________________________________________________________________________________________ REQUISITOS FUNCIONALES INTERESAD O PRIORIDAD OTORGAD A POR EL INTERESA DO REQUISITOS CÓDIGO DESCRIPCIÓN
dirección física (MAC) para poder acceder a
este.
Alta
R32
Los usuarios contarán con roles y estos a su vez
con permisos, los cuales le permitirán al
usuario acceder a las diversas opciones del
sistema.
Alta
R33
El sistema permite registrar, modificar y
eliminar registros de los siguientes maestros:
empresa,
financiadores,
contratantes,
pacientes, planes con sus respectivos
beneficios, procedimientos ambulatorios con
las tarifas que ofrece el centro de atención
ambulatoria.
Medio
R34
El sistema permitirá agrupar los procedimientos
en grupos de procedimientos, y a su vez podrán
agruparse grupos de procedimientos.
Alta
R35
El sistema permitirá registrar, modificar y
eliminar la numeración de los documentos de
pago (facturas, boletas y notas de crédito) para
que puedan ser empleados en los procesos de
cobranza en caja y facturación hacia las
empresas financiadoras de planes de salud.
REQUISITOS NO FUNCIONALES INTERESAD O PRIORIDAD OTORGAD A POR EL INTERESA DO REQUISITOS CÓDIGO DESCRIPCIÓN Micaela Barrientos Gerente de Proyecto (Cliente)
Alta
R36
La interacción con el sistema debe ser a travésde teclado y mouse.
Alta
R37
Se utilizará como base de datos Oracle 10g.
Alta
R38
El sistema será accesible desde cualquier
estación de trabajo que cuente con un S.O., un
navegador web Mozilla Firefox (2.0 o superior) o
Internet Explorer (6.0 o superior), y la máquina
virtual de Java.
Alta
R39
El sistema se ejecutará sobre un servidor de
aplicaciones Java, el cual a su vez se ejecutará
sobre cualquier S.O. que cuente con la máquina
virtual de Java.
Alta
R40
El tiempo de respuesta para la obtención de
datos a través del SITEDS no deberá exceder
los 3 segundos.
_________________________________________________________________________________________________________________ Janis Candia Gerente de Proyecto (Proveedor)
Alta
R41
Contar con especificaciones técnicas completas
y claras del sistema SITEDS, con quién
interactuará para obtener información del plan
de salud del paciente.
Alta
R42
Todos los entregables deben iniciarse ycompletarse en las fechas programadas.
Alta
R43
Cumplir con los acuerdos presentados en la
propuesta, respetando los requerimientos del
cliente.
REQUISITOS DE CALIDAD INTERESAD O PRIORIDAD OTORGAD A POR EL INTERESA DO REQUISITOS CÓDIGO DESCRIPCIÓN Equipo de Desarrollo
In document
Proyectos PMBOK
(página 44-165)