1. Plan de Calidad del Proyecto

1. Estructura detallada del trabajo (WBS)

• Casos de pruebas: Cada prueba es especificada mediante un documento que establece las condiciones de ejecución, las entradas de la prueba, y los resultados esperados. Estos casos de prueba son aplicados como pruebas de regresión en cada iteración. Cada caso de prueba llevará asociado un procedimiento de prueba con las instrucciones para realizar la prueba.
• Cronograma de Actividades: Todas las actividades realizadas para llevar a cabo el proyecto.
• Diseño de subsistemas: Es importante definir cada uno de los subsistemas que componen el sistema actual y describirlos uno por uno en forma general. Con base en esto, se realiza un diagnóstico, valorando la eficiencia de los sistema(s) de información existente(s) e identificando los posibles problemas y las mejoras.
• Documento de arquitectura de software: En general, que tiene el documento de arquitectura de software.
• EDT (WBS): Es una descripción gráfica o en texto, que desglosa el objetivo o meta del proyecto.
• Especificación de casos de uso: Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripción narrativa) se realiza una descripción detallada utilizando una plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. También, para casos de uso cuyo flujo de eventos sea complejo podrá adjuntarse una representación gráfica mediante un Diagrama de Actividad.
• Especificaciones suplementarias: Este documento capturará todos los requisitos que no han sido incluidos como parte de los casos de uso y se refieren requisitos no-funcionales globales. Dichos requisitos incluyen: requisitos legales o normas, aplicación de estándares, requisitos de calidad del producto, tales como: confiabilidad, desempeño, etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc. Explica las clases (entradas, salidas, etc) y sus relaciones con otros paquetes.
• Implementación: Constituye la implantación de proyecto, en sus respectivas áreas y funcionalidades.
• Línea Base: Es una especificación o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a través de procedimientos formales de control de cambios.
• Lista de riesgos: Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados en orden decreciente de importancia y con acciones específicas de contingencia o para su mitigación.
• Manual de Usuario: Es un manual de operaciones que describe los procedimientos de supervisión, mantenimiento, instalación y actualización, es documentación de usuario, tanto usuario final como de explotación, de acuerdo a los requisitos establecidos en la tarea Especificación de Requisitos de Documentación de Usuario.
• Material de Entrenamiento: También llamado Plan de formación, contiene procesos y procedimientos para formar a los operadores, administradores y usuarios finales con el objetivo de conseguir la explotación eficaz del nuevo sistema.
• Modelo de análisis y de diseño: Este modelo establece la realización de los casos de uso en clases y pasando desde una representación en términos de análisis (sin incluir aspectos de implementación) hacia una de diseño (incluyendo una orientación hacia el entorno de implementación), de acuerdo al avance del proyecto.
• Modelo de casos de uso: El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso.
• Modelo de casos de uso del negocio: Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). permite situar al sistema en el contexto organizacional haciendo énfasis en los objetivos en este ámbito. Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos específicos.
• Modelo de componentes: ilustra los componentes de software que se usarán para construir el sistema. Se pueden construir a partir del modelo de clases y escribir desde cero para el nuevo sistema o se pueden importar de otros proyectos y de productos de terceros. Los componentes son agregaciones de alto nivel de las piezas de software más pequeñas y proveen un enfoque de construcción de bloques de "caja negra" para la elaboración de software.
• Modelo de datos: Previendo que la persistencia de la información del sistema será soportada por una base de datos relacional, este modelo describe la representación lógica de los datos persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se utiliza un profile UML para Modelado de Datos, para conseguir la representación de tablas, claves, etc.).
• Modelo de despliegue: Este modelo muestra el despliegue la configuración de tipos de nodos del sistema, en los cuales se hará el despliegue de los componentes.
• Modelo de implementación: Este modelo es una colección de componentes y los subsistemas que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de código fuente, y todo otro tipo de ficheros necesarios para la implantación y despliegue del sistema.
• Notas de Release: El propósito de las Notas de release es comunicar nuevas características y cambios el una versión anterior del software.
• Plan de Comunicaciones: Determinación de la información y comunicaciones de quienes tienen intereses en el proyecto: destinatarios, plazos y medios.
• Plan de Costos: Es una herramienta necesaria para poder tomar decisiones acertadas en cualquier modulo del proyecto debido a que existe una relación directa entre los costes y los resultados económicos del proyecto.
• Plan de desarrollo de software: El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para controlar el proyecto. En él se describe el enfoque de desarrollo del software.
• Plan de Despliegue: Describe los procedimientos y programación para cambiar la implementación de un entorno de planificación y prueba a uno de producción, normalmente en varias etapas.
• Plan de Gestión de la Configuración: El propósito del plan de Gestión de configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software.
• Plan de Integración: Su propósito es integrar las unidades y componentes de software en el elemento software y probarlos a medida que se van agrupando.
• Plan de Iteración: Es un conjunto de actividades y tareas ordenadas temporalmente, con recursos asignados, dependencias entre ellas. Se realiza para cada iteración, y para todas las fases.
• Plan de Pruebas: Describe los procedimientos para probar el software implementado, incluidos planes específicos para desarrollar implementaciones prototipo y piloto.
• Plan de QA: "Calidad" se refieren a todas las cosas buenas que nos gustaría ver en nuestro producto. Nosotros construimos un producto de calidad y aseguramos su calidad manteniendo calidad en mente todo el tiempo y realizando las actividades seleccionadas abajo. Las pruebas son una actividad de QA, pero no es la mejor ni la única, otras actividades de QA incluyen el uso de guías de estilo y listas de pendientes, minutas en reuniones, uso de herramientas de análisis y cuidadosas mediciones y estimados de la calidad. Es necesario un plan para seleccionar y coordinar todas las actividades de QA.
• Planificación de Riesgos: Es el proceso por el que los factores de riesgo se identifican sistemáticamente y se evalúan sus propiedades. En la identificación y secuenciación de las actividades, la asignación de recursos humanos, el empleo de recursos materiales, las necesarias asignaciones económicas y los métodos de control del progreso de las actividades; la planificación se realiza suponiendo que todo va a suceder de acuerdo con lo que se ha pensado y valorado. No obstante, durante la puesta en marcha de cualquier actuación pueden surgir acontecimientos indeseables en la planificación inicial de actividades, es por estas razones que necesitamos conocer los riesgos que se puedan presentar.
• Prototipos de interfaz de usuario: Se trata de prototipos que permiten al usuario hacerse una idea más o menos precisa de las interfaces que proveerá el sistema y así, conseguir retroalimentación de su parte respecto a los requisitos del sistema. Estos prototipos se realizarán como: dibujos a mano en papel, dibujos con alguna herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Sólo los de este último tipo serán entregados al final de la fase de Elaboración, los otros serán desechados.
• Realizaciones de casos de uso: ejecución de los casos de usos según las prioridades establecidas.
• Requerimientos no funcionales: Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

8. Análisis de rentabilidad del Proyecto

Egresos

PERSONA POR MES
Requerimientos de Recursos / Mes	Mes1	Mes2	Mes3	Mes4	Mes5	Mes6
Jefe del Proyecto	1	1	1	1	1	1
Analista de Sistemas	1	2	2	0	0	1
Especificador de requerimientos	1	2	2	1	1	0
Diseñador del Negocio	0	1	2	0	0	0
Arquitecto de Software	0	1	1	0	0	0
Diseñador	0	1	2	1	1	0
Diseñador de Interfaces	0	0	1	1	1	0
Diseñador de BD	0	1	1	1	0	0
Porgramador	0	1	1	2	2	1
Jefe de Pruebas	0	1	1	1	1	0
Tester	0	0	0	2	1	0

 

PERSONA POR MES
Recursos mes	Costos por mes S/	Mes 1 S/.	Mes 2 S/.	Mes 3 S/.	Mes 4 S/.	Mes 5 S/.	Mes 6 S/.
Jefe del Proyecto	1200	1200	1200	1200	1200	1200	1200
Analista de Sistemas	1000	1000	2000	1000	0	0	1000
Especificador de requerimientos	1000	1000	0	1000	2000	1000	0
Diseñador del Negocio	900	0	900	1800	0	0	0
Arquitecto de Software	900	0	900	0	0	0	0
Diseñador	800	0	800	1600	0	0	0
Diseñador de Interfaces	800	0	0	0	800	800	0
Diseñador de BD	800	0	800	800	0	0	0
Porgramador	600	0	0	600	1200	1200	0
Jefe de Pruebas	800	0	0	800	800	0	0
Tester	500	0	0	0	1000	500	0
Flujo pago personal		3200	6600	8800	7000	4700	2200

MATERIAL DE ESCRITORIO
Material		Cantidad	Costo Unit. S/.	Subtotal
Papel Bond (Millar)		2	20,00	40,00
Lapiceros		15	0,50	7,50
Corrector Ortográfico		5	2,80	14,00
Engrampador		1	2,50	2,50
Perforador		1	3,00	3,00
Folder de manila		50	1,00	50,00
Sobres de manila		50	1,00	50,00
Clips		100	1,00	100,00
Cinta adhesiva		1	0,90	0,90
Tijera		1	1,50	1,50
Total de Gastos				269,40

Total Egresos

Recurso y Personal por mes
Inversión del Py	Mes 1 S/.	Mes 2 S/.	Mes 3 S/.	Mes 4 S/.	Mes 5 S/.	Mes 6 S/.
Gasto de Personal	3200	6600	8800	7000	4700	2200
Material de escritorio	269,4	0	0	0	0	0	Gastos
Totales Egreso	3469,4	6600	8800	7000	4700	2200	32769

Ingresos

INGRESOS	Por mes S/.
Reducir Costos de alquiler	1200
Monitoreos de la Referencia en el viaje	2500
Monitoreo de la calificación de las referencias	3500
Total Ingresos	7200

Flujo de Caja





9. Conclusiones y Recomendaciones

Este proyecto permitirá automatizar un proceso de vital importancia y tener en tiempo real y de manera oportuna información para el adecuado servicio de salud para los asegurados en los procesos de Referencia y Contrarreferencia y de esta forma facilitar al personal que labora, y mejorar el desempeño profesional, lo cual repercutirá en beneficio de los paciente para el adecuado y oportuno servicio de salud, y tener un control de estos procesos para monitorear la capacidad del hospitales de menor capacidad resolutiva y llevar un control de los pacientes contrarreferidos. Este proceso va permitir controlar todo el proceso; y mejorar los servicios para conllevar a la adecuada y oportuna atención de los paciente y facilitar a los profesionales de salud sus labores.

En este sentido los Sistemas de información ofrecen a las organizaciones de Salud grandes oportunidades que van desde la organización y automatización de sus procesos internos, proporcionando mejoras continuas y la prestación de servicios de salud de Calidad.

Siendo la salud del paciente y de la comunidad el objetivo primordial para EsSalud, para ello se requiere disponer de los recursos necesarios en el momento adecuado, para lo cual se requiere tanto adquirir las herramientas y contar con las fuentes de información que permitan dar soluciones de la manera mas óptima, es decir contar con Bases de datos fiables, procesos sistematizados y actualizadas que permita al profesional de la salud la toma de decisiones acertadas para la atención del paciente.

En conclusión todo este pensamiento en su conjunto forman parte de una estrategia organizacional.

Pero también, existen dificultades o barreras que deben ser superadas como las relacionadas con las políticas organizacionales en su manera de pensar y fundamentalmente en los aspectos de implementación de los procesos y exponer los beneficios que conlleva la automatización..

10. Marco Conceptual

dimi_tok81[arroba]hotmail.com