Sistema de transferencia (página 5)

Cronograma de Actividades

8. 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. Análisis de rentabilidad del Proyecto

   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. Conclusiones y Recomendaciones

11. Marco Conceptual

Conceptos Fundamentales en el Desarrollo del Sistema

Sistema de Información: Conjunto de elementos físicos, lógicos y personal que, interrelacionados, permiten la captura, almacenamiento, procesamiento y distribución de la información en toda una Institución; estos apoyan a la toma de decisiones.

Los sistemas de Información son desarrollados con propósitos diferentes de acuerdo a las necesidades de la Institución.

Gestor de Base de Datos SQL Server

El SQL Server 7.0 es una Base de Datos moderna con una arquitectura implantada completada por Microsoft, y diseñada para las direcciones más exigentes de aplicaciones Base de Datos requeridas por decisiones de apoyo operacionales para sistemas implantados hoy y en el futuro.

SQL Server 7.0 y MSDE 1.0 soporta todos los 32-bit de las plataformas de Microsoft Windows (excepto Win32), códigos base compatibles con adaptaciones dinámicas del hardware capaces de soportar un sistema en el cual ya esté instalado. Esto significa que los desarrolladores pueden escribir un conjunto sencillo de aplicaciones con códigos fuente y mandarlo a las database de un Windows 98, de un Windows NT Server y

de un Windows NT Server Enterprise Edition. Las filas de Database también son compatibles con todas las ediciones de SQL Server 7.0.

Ventajas

Escalabilidad: Se adapta a las necesidades de la empresa, soportando desde unos pocos usuarios a varios miles. Empresas centralizadas u oficinas distribuidas, replicando cientos de sites.

Potencia: Microsoft SQL Server es la mejor base de datos para Windows NT Server. Posee los mejores registros de los benchmarks independientes (TCP) tanto en transacciones totales como en coste por transacción.

Gestión: Con un completo interfaz gráfico que reduce la complejidad innecesaria de las tareas de administración y gestión de la base de datos.

Orientada al desarrollo: Visual Basic, Visual C++, Visual J++, Visual Interdev y muchas otras herramientas son compatibles con Microsoft SQL Server.

La mejor base de datos para Internet, Internet y Extranet.

Lenguaje de Programación Visual Basic .Net

Visual Basic es un sistema de desarrollo diseñado especialmente para crear aplicaciones con interfaz grafica, de una forma rápida y sencilla. Para soportar este tipo de desarrollo, Visual Basic utiliza fundamentalmente dos herramientas, una que permite realizar los diseños gráficos y un lenguaje de alto nivel.

Rational Rose

Rational Rose es la más reciente y poderosa herramienta de modelamiento visual para el análisis y diseño de sistemas basados en objetos. Rose es usado para modelar sistemas antes de llevar a cabo los trabajos de construcción.

Esta secuencia de desarrollo es importante para asegurar la consistencia arquitectónica del sistema. Usando los modelos de Rose, se pueden identificar fallas durante una etapa temprana del desarrollo del proyecto y así evitar aumentos en los tiempos y costos del proyecto software, Rational Rose apoya también al planeamiento del negocio, a través de representaciones que facilitan a los usuarios el mejor entendimiento de los procesos del negocio haciéndolos más eficientes.

Un modelo en Rose es la imagen de un sistema desde varias perspectivas. Es decir, incluye todos los diagramas de UML: actores, casos de uso, objetos, clases, componentes y el despliegue de nodos en un sistema. Los modelos Rose, describen con gran detalle lo que el sistema incluirá y como funcionará, para que así los diseñadores puedan usar los modelos como si fueran los planos de un sistema a ser construido (un plano es una buena analogía para los modelos creados en Rose).

Concepto del RUP. Es un proceso de desarrollo de sistema. Un proceso de desarrollo de sistema es un conjunto de actividades necesarias para transformar los requerimientos de los usuarios en un sistema de software.

El Proceso Unificado es iterativo e incremental.- El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar entre varios meses hasta posiblemente un año o más. Es práctico dividir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto.

• Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
• Pretende implementar las mejores practicas en ingeniería de Software
• Desarrollo iterativo
• Administración de requisitos
• Uso de arquitectura basada en componentes
• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso.

Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el codigo fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al final de cada ciclo, cada ciclo se divide en fases que finalizan con un hito donde se debe tomar una decisión importante:

• Inicio: se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos
• Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos
• Construcción: se concentra en la elaboracion de un producto totalmente operativo y eficiente y el manual de usuario
• Transición: se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requerimientos a ser analizados.

UML- Lenguaje Unificado de Modelamiento

UML es un lenguaje estándar para crear planos de software.

No es un lenguaje de programación. Sin embargo permite hacer una rápida transición del modelo al código.

Es una herramienta de la ingeniería de software.

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software). El objetivo de amb os era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los "tres amigos". Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.

Qué es UML?

UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).

UML es un lenguaje estándar que sirve para escribir los planos del software, puede utilizarse para visualizar, especificar, construir y documentar todos los artefactos que componen un sistema con gran cantidad de software. UML puede usarse para modelar desde sistemas de información hasta aplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real.

UML es solamente un lenguaje por lo que es sólo una parte de un método de desarrollo software, es independiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.

El lenguaje UML se compone de tres elementos básicos, los bloques de construcción, las reglas y algunos mecanismos comunes. Estos elementos interaccionan entre sí para dar a UML el carácter de completitud y no-ambigüedad que antes comentábamos.

Los bloques de construcción se dividen en tres partes:

• Elementos, que son las abstracciones de primer nivel.
• Relaciones, que unen a los elementos entre sí.
• Diagramas, que son agrupaciones de elementos.

Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos:

• Elementos estructurales.
• Elementos de comportamiento.
• Elementos de agrupación
• Elementos de anotación.

Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia, relaciones de asociación, relaciones de generalización y relaciones de realización.

Se utilizan diferentes diagramas dependiendo de qué, nos interese representar en cada momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle…, por esta razón UML soporta un gran numero de diagramas diferentes aunque, en la practica, sólo se utilicen un pequeño número de combinaciones.

UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones entre objetos para poder obtener modelos bien formados, estas son reglas semánticas que afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por otros, a la integridad de unos elementos con otros y a la ejecución, o sea la vista dinámica del sistema.

UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo unas ciertas reglas para que en el trasfondo de la adaptación no se pierda la semántica propia de UML. Dentro de estos mecanismos están las especificaciones, que proporcionan la explicación textual de la sintaxis y semántica de los bloques de construcción.

Otro mecanismo es el de los adornos que sirven para conferir a los modelos de más semántica, los adornos son elementos secundarios ya que proporcionan más nivel de detalle, que quizá en un primer momento no sea conveniente descubrir. Las divisiones comunes permiten que los modelos se dividan al menos en un par de formas diferentes para facilitar la comprensión desde distintos puntos de vista, en primer lugar tenemos la división entre clase y objeto (clase es una abstracción y objeto es una manifestación de esa abstracción), en segundo lugar tenemos la división interfaz / implementación donde la interfaz presenta un contrato (algo que se va a cumplir de una determinada manera) mientras que la implementación es la manera en que se cumple dicho contrato.

Por ultimo, los mecanismos de extensibilidad que UML proporciona sirven para evitar posibles problemas que puedan surgir debido a la necesidad de poder representar ciertos matices, por esta razón UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques de construcción, los valores etiquetados, para extender las propiedades un bloque, y las restricciones, para extender la semántica. De esta manera UML es un lenguaje estándar "abierto-cerrado" siendo posible extender el lenguaje de manera controlada.

DIAGRAMA DE SECUENCIA

Este diagrama muestra la interacción de los objetos entre ellos. Es importante comentar que hasta este momento no se han considerado objetos técnicos. En UML, durante el Análisis de los requerimientos y el Análisis, no se consideran objetos técnicos que definan detalles y soluciones en el sistema de software, tales como objetos para interfaces de usuario, bases de datos, comunicaciones, etc. Todos esos objetos se consideran hasta el diseño del sistema

DIAGRAMA DE COLABORACIÓN

Así mismo, se cuenta con el diagrama de colaboración, el cual se centra tanto en las interacciones y las ligas entre un conjunto de objetos colaborando entre ellos (una liga es una instancia de una asociación). Ambos, el diagrama de secuencia y el diagrama de colaboración, muestran interacciones, pero el diagrama de secuencia se centra en el tiempo mientras que el diagrama de colaboración se centra en el espacio. Las ligas muestran los objetos actuales y cómo ellos se relacionan unos con otros. Así como los diagramas de secuencia, los diagramas de colaboración pueden ser utilizados para ilustrar la ejecución de una operación, una ejecución de un use-case o simplemente un escenario de interacción dentro del sistema. En este diagrama también se representa a los objetos en cajas rectangulares y con el nombre subrayado. Las ligas se dibujan con líneas y se puede agregar una etiqueta para un mensaje y un número que define la secuencia de las ligas.

DIAGRAMA DE CLASES

Para la realización del diagrama de clases se toman como base los diagramas de secuencia y de colaboración por lo que se manejarán los objetos que ahí se consideraron pero ahora a nivel de clases. Además, se pueden agregar nuevas clases que no se habían considerado y este paso deberá ser realizado por expertos en el dominio del problema. Para poder definir las clases, UML sugiere seis características selectivas que debe utilizar el analista para considerar una clase candidato en el modelo de análisis:

2. Información retenida. La clase será útil durante el análisis sólo si la información sobre el mismo ha de ser almacenada, transformada, analizada o manejada en algún otro modo. La información puede referirse a conceptos que deberán estar siempre registrados en el sistema, eventos o transacciones que ocurren en un momento específico.
2. Sistema externo. Si se tiene un sistema externo a este sistema, entonces es de interés en la etapa de modelado. Los sistemas externos deberán ser vistos como clases que el sistema contendrá o con los cuales interactuará.
3. Patrones, librerías de clases o componentes. Si se tienen patrones, librerías de clases o componentes, generalmente éstos son clases candidatos.
4. Dispositivos que el sistema maneja. Dispositivos técnicos que maneja el sistema se convertirán en clases que manejarán esos dispositivos.
5. Partes organizacionales. Especialmente en modelos de negocio, todas las partes que representan a la organización, serán clases candidatos.
6. Roles de actores. Los roles de actores serán vistos como clases, por ejemplo, usuario, operador del sistema, administrador, cliente, etc.

DIAGRAMA DE ESTADOS

Posteriormente se realiza el diagrama de estados (figura 8) el cual captura el ciclo de vida de los objetos, subsistemas y sistemas. Dicho diagrama determina los estados que un objeto puede tener y cómo los eventos afectan esos estados a través del tiempo. Un diagrama de estado debe abarcar todas las clases que tengan estados y conducta definidos claramente.

Todos los objetos tienen un estado y éste es el resultado de actividades previas ejecutadas por el objeto. Ese estado está determinado por los valores de los atributos de este objeto y sus relaciones con otros objetos. Una clase puede tener un atributo que especifique el estado, o el estado puede ser determinado por los valores de los atributos "normales" del objeto

DIAGRAMA DE COMPONENTES

Dentro de esta etapa se crea el diagrama de componentes que describe componentes de software y sus dependencias con otros componentes, representando la estructura del código. Los componentes de software pueden ser: componentes de código, componentes binarios que son los generados por la compilación de los componentes de código y los componentes ejecutables.

En este diagrama se pueden manejar paquetes, que son contenedores de clases utilizados para mantener el espacio de nombres de clases dividido en compartimentos, de manera que se utilizan para representar subsistemas del sistema en el mundo físico. Cada paquete se liga con otros a través de dependencias, que se representan con flechas de líneas discontinuas que van del componente dependiente al componente del cual depende.

DIAGRAMA DE DESPLIEGUE

Por último, se realiza el diagrama de despliegue, el cual contiene los nodos y las conexiones que muestran la arquitectura del sistema en tiempo de ejecución a través de procesadores, dispositivos y los componentes de software que se ejecutan en esta arquitectura. Esta es la última descripción física de la topología del sistema, describiendo la estructura de las unidades de hardware y el software que se ejecuta en cada unidad, como se muestra en la figura siguiente.

Los nodos se representan con cubos en tres dimensiones con su nombre en el interior. Si el nodo representa a una instancia en lugar de una clase, el nombre va subrayado. Las conexiones se representan con líneas continuas y contienen el nombre y el estereotipo de la conexión. El nombre es el identificador de la misma y el estereotipo indica el protocolo de comunicaciones entre los dos nodos implicados

9. Bibliografía

• Manual de Organización y Funciones (MOF) de la Red Asistencial de Apurimac (EsSalud) Abancay
• Jame Rumbaungh, Ivar Jacobson y Grady Booch., .El Lenguaje Unificado del Modelado
• Ing. Gesvin Romero Moreno, UML CON RATIONAL ROSE
• Kenneth C Lauden y Jane P. Laudon; Administración de los Sistemas de Información, Tercera Edición, Prentice Hall Hispano Americana S.A., 1996.
• Joseph Schumuller; Aprendiendo UML en 24 horas, 1ra. Edición, Pearson Educación, 2000.
• James Rumbaugh, Ivar Jacobson, Grady Booch , El proceso unificado de desarrollo de software, 1ra. Edición, Pearson Educación, 2000.
• Sommerville, I., Ingeniería de Software, Pearson Educación, 2002.
• Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.

8. Anexos.

Glosario De Términos

• Sistema de Referencia. Conjunto de actividades de orden administrativo y asistencial, que permite el movimiento de usuario ó elementos de diagnóstico mediante un flujo ordenado entre establecimientos de salud y cuyo fin es dar continuidad a la atención, importante atributo del modelo de atención integral de salud.
• Referencia. Es un procedimiento administrativo asistencial, mediante el cual se transfiere la responsabilidad del cuidado de la salud del paciente ( o un elemento diagnóstico ), de la comunidad o un establecimiento de salud a otro establecimiento de salud de mayor capacidad resolutiva.
• Contrarreferencia. Acto administrativo asistencial mediante el cual el establecimiento de salud de destino devuelve la responsabilidad de atención del paciente o el resultado del elemento diagnóstico al establecimiento de origen o a la comunidad.
• Formato de Referencia. Es el documento de solicitud de atención en otro establecimiento de salud, incluye la información necesaria para la mejor evaluación.
• Formato de Contrarreferencia. Es el documento por el cual se hace la devolución de un paciente a su establecimiento de salud de origen, incluye la información necesaria para continuar con su tratamiento.
• Transporte. Acción de movilización de pacientes o elementos de diagnóstico en un establecimiento de salud.
• 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.
• 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.

Autor:

Georgios Dimitrius Tokunaga Iruri

Valia Vedsy Sánchez Ochoa

Nacionalidad: Peruana.

Profesión: Ingenieros de Sistemas y Cómputo

Estudios realizados: Universidad Inca Gracilazo de la Vega – Lima – Perú.

Perfiles de Carrera: Gerencia de proyectos y Ingeniería del Conocimiento

País: Perú – Apurimac – Abancay;

Fecha de realización del proyecto 19/08/2006.