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.