MANUAL

UNIVERSIDAD DE EL SALVADOR FACULTAD DE INGENIERIA Y ARQUITECTURA ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS
SISTEMA INFORMATICO PARA LA ADMINISTRACION Y CONTROL DE EXPEDIENTES DEL CENTRO DE REHABILITACION INTEGRAL PARA LA NIEZ Y LA ADOLESCENCIA.
PRESENTADO POR: MOISS ELAS CRUZ LPEZ JENNIE XIOMARA GRANADOS GUEVARA NGEL JOS LIZAMA MOLINA LEDWIN BAUDILIO RIVAS SORTO PARA OPTAR AL TITULO DE: INGENIERO DE SISTEMAS INFORMATICOS CIUDAD UNIVERSITARIA, FEBRERO 2011
UNIVERSIDAD DE EL SALVADOR
RECTOR :
MSc. RUFINO ANTONIO QUEZADA SNCHEZ

SECRETARIO GENERAL :
LIC. DOUGLAS VLADIMIR ALFARO CHVEZ
FACULTAD DE INGENIERIA Y ARQUITECTURA

DECANO :
ING. MARIO ROBERTO NIETO LOVO

SECRETARIO :
ING. OSCAR EDUARDO MARROQUN HERNNDEZ
ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS

DIRECTOR INTERINO :
ING. JOS MARA SNCHEZ CORNEJO
UNIVERSIDAD DE EL SALVADOR FACULTAD DE INGENIERIA Y ARQUITECTURA ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS
Trabajo de Graduacin previo a la opcin al Grado de:
INGENIERO DE SISTEMAS INFORMATICOS

Ttulo :
SISTEMA INFORMATICO PARA LA ADMINISTRACION Y CONTROL DE EXPEDIENTES DEL CENTRO DE REHABILITACION INTEGRAL PARA LA NIEZ Y LA ADOLESCENCIA.
Presentado por :
MOISS ELAS CRUZ LPEZ JENNIE XIOMARA GRANADOS GUEVARA NGEL JOS LIZAMA MOLINA LEDWIN BAUDILIO RIVAS SORTO
Trabajo de Graduacin Aprobado por: Docente Director :
ING. SANDRA GUADALUPE ROMERO San Salvador, Febrero 2011
Trabajo de Graduacin Aprobado por:
Docente Director
ING. SANDRA GUADALUPE ROMERO
NDICE
INTRODUCCIN ................................................................................................................................... 1 OBJETIVO ............................................................................................................................................. 2 1.1 1.2 OBJETIVO GENERAL ............................................................................................................. 2 OBJETIVOS ESPECFICOS ...................................................................................................... 2
JUSTIFICACIN..................................................................................................................................... 3 IMPORTANCIA ..................................................................................................................................... 4 ALCANCES ............................................................................................................................................ 4 LIMITACIONES ..................................................................................................................................... 4 1. MARCO TERICO ......................................................................................................................... 5 1.1. 1.2. 1.3. 2. SISTEMAS INFORMTICOS DE SALUD ................................................................................. 5 ACERCA DE LOS SISTEMAS INFORMTICOS ORIENTADOS A LA WEB ................................. 5 MARCO LEGAL ..................................................................................................................... 6
ANTECEDENTES ........................................................................................................................... 6 2.1. GENERALIDADES DEL CENTRO DE REHABILITACIN INTEGRAL PARA LA NIEZ Y LA ADOLESCENCIA ................................................................................................................................ 6 2.2. ANTECEDENTES INFORMTICOS ......................................................................................... 9
3.
SITUACIN ACTUAL DEL CRINA ................................................................................................... 9 3.1. 3.2. DESCRIPCIN ....................................................................................................................... 9 ENFOQUE DE SISTEMAS DE LA SITUACIN ACTUAL.......................................................... 11 VARIABLES DE ENTRADA ........................................................................................... 12 PROCEDIMIENTOS ..................................................................................................... 12 SALIDAS...................................................................................................................... 14
3.2.1. 3.2.2. 3.2.3. 4.
METODOLOGA .......................................................................................................................... 14 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. METODOLOGA PARA LA SOLUCIN DE PROBLEMAS ....................................................... 14 METODOLOGA DE LA INVESTIGACIN A DESARROLLAR ................................................. 15 METODOLOGA PARA EL PLANTEAMIENTO DEL PROBLEMA ............................................ 16 METODOLOGA PARA EL ANLISIS .................................................................................... 16 METODOLOGA PARA EL DISEO ...................................................................................... 17 METODOLOGA PARA EL DESARROLLO ............................................................................. 18 METODOLOGA PARA LA DOCUMENTACIN .................................................................... 19
5.
FACTIBILIDADES ......................................................................................................................... 20 5.1. FACTIBILIDAD TCNICA ...................................................................................................... 20 RECURSO TECNOLGICO Y HUMANO DEL EQUIPO DE DESARROLLO....................... 20 RECURSO TECNOLGICO Y HUMANO DEL CRINA ..................................................... 24 RECURSO HUMANO TCNICO ................................................................................... 25 FACTIBILIDAD ECONMICA ....................................................................................... 25 ANLISIS COSTO BENEFICIO ...................................................................................... 26
5.1.1. 5.1.2. 5.1.3. 5.1.4. 5.1.5. 5.2.
FACTIBILIDAD OPERATIVA ................................................................................................. 32 APLICACIN DE LA TCNICA PIECES .......................................................................... 33 VOLMENES DE DATOS DEL CRINA........................................................................... 34
5.2.1. 5.2.2. 6.
ANLISIS DE LA SITUACIN ACTUAL. ........................................................................................ 36 6.1. Caso de Uso de la Situacin Actual. .................................................................................. 36
7.
REQUERIMIENTOS DEL SISTEMA ............................................................................................... 38 7.1. 7.2. 7.3. 7.4. 7.5. Requerimientos Funcionales ............................................................................................. 38 Requerimientos no funcionales......................................................................................... 41 Requerimientos Operativos .............................................................................................. 42 Requerimientos de desarrollo ........................................................................................... 42 Requerimientos Legales y Ambientales ............................................................................ 43
8.
ESTNDARES DE DISEO DEL SISTEMA ..................................................................................... 43 8.1. Estndares para el Anlisis de Requerimientos. ............................................................... 43 Modelo Conceptual ................................................................................................... 43 Definicin de Clases................................................................................................... 44 Casos de Uso.............................................................................................................. 45 Diagrama de Secuencia (DDS) ................................................................................... 46
8.1.1. 8.1.2. 8.1.3. 8.1.4. 8.2.
Estndares de Diseo. ....................................................................................................... 47 Diagrama de Clases. .................................................................................................. 47
8.2.1. 8.3.
Estndares de Base de Datos. ........................................................................................... 49 Modelo Lgico De La Base De Datos ......................................................................... 50 Modelo Fsico De La Base De Datos .......................................................................... 51
8.3.1. 8.3.2. 8.4.
Estndares de Programacin............................................................................................. 51
8.5.
Estndares para El Diseo de Pantallas ............................................................................. 62 Estndar para interfaces de Entrada ......................................................................... 62 Estndar para interfaces de Salida. ........................................................................... 64 Estndares de Errores ............................................................................................... 65
8.5.1. 8.5.2. 8.5.3. 8.6. 8.7. 9.
Estndares de Manuales a Entregar .................................................................................. 65 Estndares de Seguridad ................................................................................................... 66
Diseo Global ............................................................................................................................ 67 9.1. Modelado de Casos de Uso ............................................................................................... 67 Caso de Uso General. ................................................................................................ 67 Caso de Uso Iniciar Sesin ......................................................................................... 68 Caso de Uso Administracin de Usuarios. ................................................................. 69 Caso de Uso Creacin de Expediente ........................................................................ 71 Caso de Uso Consulta Peditrica ............................................................................... 72 Caso de Uso Pre-Evaluacin Tcnica Ingreso al CRINA........................................... 73 Caso de Uso Inscripcin de Terapias ......................................................................... 74 Caso de Uso Control de Asistencias. ......................................................................... 75 Caso de Uso Actualizar Expediente ........................................................................... 77 Caso de Uso Control de Rehabilitacin ..................................................................... 78 Caso de Uso Control de Seguimiento Mdico ........................................................... 79 Caso de Uso Control de Seguimiento Psicolgico ..................................................... 80 Caso de Uso Control de Trabajo Social ISRI ............................................................... 81 Caso de Uso Control Trabajo Social CRINA................................................................ 82 Caso de Uso Visita Domiciliar .................................................................................... 83 Caso de Uso Generacin de Reportes ....................................................................... 84 Caso de uso Creacin de resumen tcnico................................................................ 85 Caso de Uso Asignar altas a pacientes ...................................................................... 87
9.1.1. 9.1.2. 9.1.3. 9.1.4. 9.1.5. 9.1.6. 9.1.7. 9.1.8. 9.1.9. 9.1.10. 9.1.11. 9.1.12. 9.1.13. 9.1.14. 9.1.15. 9.1.16. 9.1.17. 9.1.18. 9.2.
Diagramas de Secuencia .................................................................................................... 88 DDS Iniciar Sesin ...................................................................................................... 88 DDS Administracin de Usuarios .............................................................................. 88
9.2.1. 9.2.2.
9.2.3. 9.2.4. 9.2.5. 9.2.6. 9.2.7. 9.2.8. 9.2.9. 9.2.10. 9.2.11. 9.2.12. 9.2.13. 9.2.14. 9.2.15. 9.2.16. 9.2.17. 10.
DDS Creacin de Expediente ..................................................................................... 91 DDS Consulta Peditrica ............................................................................................ 91 DDS Pre-Evaluacin Tcnica Ingreso CRINA ........................................................... 92 DDS Inscripcin de Terapias ...................................................................................... 92 DDS Control de Asistencias........................................................................................ 93 DDS Actualizar Expediente ........................................................................................ 94 DDS Control de Rehabilitacin .................................................................................. 94 DDS Control de Seguimiento Mdico ........................................................................ 95 DDS Control de Seguimiento Psicolgico .................................................................. 95 DDS Control de Trabajo Social Consulta Externa ISRI................................................ 96 DDS Control Trabajo Social CRINA ............................................................................. 96 DDS Visita Domiciliar ................................................................................................. 97 DDS Generacin de Reportes .................................................................................... 97 DDS Creacin de resumen tcnico ............................................................................ 98 DDS Asignar altas a pacientes ................................................................................... 99
Diseo de Seguridad .............................................................................................................. 99
10.1. Diseo de niveles de acceso .............................................................................................. 99 10.2. Diseo de seguridad de datos, hardware y software...................................................... 101 11. 12. Diseo de la base de datos .................................................................................................. 101 Diccionario de Datos ........................................................................................................... 103 12.1. 13. Diccionario de Tablas con sus respectivos campos. ................................................ 103
PLAN DE IMPLEMENTACIN ............................................................................................... 124
13.1. ELEGIR LA ARQUITECTURA .............................................................................................. 124 13.1.1. 13.1.2. Recurso Tecnolgico para la Implementacin: ....................................................... 124 Recurso Humano: .................................................................................................... 125
13.2. DESCRIPCIN DE LA ARQUITECTURA DEL SISTEMA. ....................................................... 125 13.2.1. Descripcin de las partes de la arquitectura del Sistema ....................................... 126
13.3. METODOLOGA PARA LA IMPLEMENTACIN.................................................................. 127 13.4. PLANIFICACIN DE ACTIVIDADES. ................................................................................... 128
13.4.1. 13.4.2. 13.4.3. 13.4.4.
Planeacin de Implementacin. .............................................................................. 128 Organizacin de Implementacin. .......................................................................... 128 Ejecucin de Implementacin. ................................................................................ 129 Ejemplo de calendarizacin del plan de Implementacin....................................... 130
13.5. RECURSOS A UTILIZAR: .................................................................................................... 131 13.5.1. Control de la implementacin: ................................................................................ 132
13.6. SISTEMA DE CONTROL..................................................................................................... 132 13.6.1. Formularios para el Control: ................................................................................... 133
13.7. Estrategias de Control. .................................................................................................... 137 14. MANUALES .......................................................................................................................... 138
CONCLUSIONES ............................................................................................................................... 139 BIBLIOGRAFA .................................................................................................................................. 140 GLOSARIO ........................................................................................................................................ 141 ANEXOS ........................................................................................................................................... 145
Sistema Informtico para la Administracin y Control de Expedientes del CRINA
INTRODUCCIN
El CRINA es una dependencia del ISRI, que atiende a personas con capacidades especiales desde el 2005, ayudando a integrar a nios y adolescentes a la actividad productiva del pas. El presente documento propone el desarrollo del Sistema informtico para la Administracin y control de expedientes del CRINA con el propsito de mejorar las condiciones actuales de los procesos realizados en el rea objeto de estudio. Adems, se da a conocer cun importante es el proyecto y por qu es justificable, la metodologa a emplear en la investigacin, solucin y los resultados esperados. Se desarrolla el anlisis y diseo para el proyecto Sistema Informtico para la Administracin y Control de Expedientes del CRINA (SIACE). A travs del documento se permiten abstraer y comprender de manera clara y precisa los conceptos y requerimientos, a travs de una fluida comunicacin con los usuarios y una correcta interpretacin de lo que este necesita para desarrollar adecuadamente sus labores cotidianas. Para el anlisis de la informacin e identificacin de los requerimientos, se utiliza la metodologa de lenguaje unificado, describiendo lo siguiente: casos de uso y diagramas de secuencia, con el propsito de modelar los elementos involucrados en la solucin, tambin se describen los requerimientos funcionales, no funcionales, operativos, de desarrollo, legales y ambientales para el sistema. En el diseo de la solucin se satisfacen elementos identificados en la determinacin de requerimientos, adems en este apartado se desarrolla la descripcin de la arquitectura de toda la solucin, la forma de trabajo en cada una de sus partes, as como el diagrama de clases, el modelado de la base de datos, el diccionario de datos, el diseo de las pantallas y el diseo de la seguridad.
OBJETIVO
1.1 OBJETIVO GENERAL

Desarrollar un sistema informtico para la administracin y control de expedientes del CRINA que permita la disponibilidad y manipulacin de la informacin en forma rpida y correcta.
1.2 OBJETIVOS ESPECFICOS

1. Realizar una investigacin preliminar para el desarrollo del sistema informtico. 2. Realizar un anlisis de requerimientos para el diseo y construccin del sistema informtico. 3. Disear un sistema informtico para la administracin y control de expedientes del CRINA. 4. Programar el sistema informtico para la administracin y control de expedientes del CRINA. 5. Disear y ejecutar las pruebas pertinentes para comprobar el correcto funcionamiento del sistema para la administracin y control de expedientes del CRINA.
JUSTIFICACIN
El CRINA, tiene como objetivo proporcionar servicios de rehabilitacin integral a la niez y adolescencia con discapacidad por medio de profesionales y altamente capacitados, con la participacin activa de los usuarios, padres familia y a comunidad, basados en los principios de calidad, eficiencia y equidad, para lograr el mximo grado independencias y su plena integracin biopsicosocial a travs de las diferentes terapias que ofrece para sus pacientes beneficiando as a un total de por lo menos 2,300 pacientes por ao. Debido a que actualmente no se cuenta con un sistema que permita hacer la consulta de los expedientes y modificacin de los mismos, se tienen que movilizar diariamente un promedio de 300 expedientes diarios, estos se encuentran fsicamente en el ISRI y tienen que ser transportados al CRINA a cada una de las reas donde se reciben las terapias. El procesamiento manual de los datos genera informacin poco confiable, as como retrasos en la generacin de reportes y en consecuencia mayores costos para el CRINA. El proyecto que se llevara a cabo ser de gran beneficio no solamente para el CRINA, sino para los pacientes en general; ya que con ello se har eficiente la manipulacin de los expedientes y la informacin ser mucho ms confiable1. Con la operacin del Sistema Informtico para la Administracin de los expedientes se pretende obtener los siguientes beneficios: Mayor confiabilidad en el registro de datos. Tiempos ptimos para la captura de datos y generacin de reportes. Manejo eficiente de la informacin del paciente. Un registro ms eficiente de nuevos pacientes que ingresan a la institucin. Informacin actualizada y oportuna de los expedientes en las diferentes reas donde son solicitados. Un panorama ms gil de las diferentes actividades realizadas por cada rea de terapias.
Los expedientes manejan una cantidad significativa de formularios que se mencionan en el desarrollo de este anteproyecto, por lo cual se hace de suma importancia garantizar su integridad dado que es aqu donde los terapistas llevan el control de la evolucin de los pacientes.
Entrevista con Dra. Lorena de Zelaya actual directora del CRINA
IMPORTANCIA
El desarrollo del Sistema Informtico para la Administracin y Control de los expedientes del CRINA, se considera importante ya que a travs del este se contribuir a mejorar el desarrollo de los procesos internos. El hecho de movilizar alrededor de 300 expedientes diarios en la institucin, podra generar prdida de datos importantes; lo que implicara que el personal tendra que repetir sus evaluaciones y llenar los expedientes de nuevo. A continuacin se describen de forma ms especfica, algunas de las razones por las cuales este proyecto ser desarrollado: Incremento y mejora en los procesos de consulta de los expedientes, puesto que se llevara un registro y almacenamiento eficiente de las actividades realizadas en cada una de las terapias que cada paciente puede recibir, lo que beneficiar con esto a ms personas ya que se agilizaran los procesos de atencin. Los terapistas y personal de administracin dispondrn de informacin de alta calidad puesto que cada quien ser responsable de los cambios que los expedientes tengan. Se disminuirn, considerablemente, los procesos manuales inmersos en la elaboracin de los informes requeridos por todos los niveles organizativos del rea administrativa del CRINA. Se contara con una herramienta que permita a los usuarios tener acceso a la informacin desde cualquier lugar en que se encuentren, ya que el sistema est desarrollado bajo ambiente Web. Esto con el fin de evitar que los expedientes fsicos tengan que ser transportados.
ALCANCES
Al concluir este proyecto se tendr: El software resultante al finalizar este proyecto estar listo para poder ser instalado. La documentacin del sistema (documentos finales y manuales del sistema, (manual de usuario, manual tcnico, manual de instalacin.)) se proporcionaran de forma impresa y medio ptico al finalizar el proyecto. El desarrollo de este proyecto abarca hasta el plan de implementacin.
LIMITACIONES
No existen limitaciones para el desarrollo del proyecto Sistema Informtico para la Administracin y Control de Expedientes del CRINA
1. MARCO TERICO
A continuacin se presenta la informacin necesaria para tener fundamentos tericos adecuados para la creacin del Sistema Informtico para la Administracin y Control de Expedientes del CRINA, este ser orientado a la Web y se tomaran como bases algunos estudios desarrollados sobre este tipo de sistemas aplicados en instituciones relacionadas con el rea de salud para obtener una idea clara sobre este tipo de desarrollos.
1.1. SISTEMAS INFORMTICOS DE SALUD

Existen diferentes sistemas informticos aplicados al rea de salud que han sido desarrollados para dar solucin a diferentes problemas, como la distribucin de la informacin de dicha rea. En lo que respecta a un estudio preliminar sobre sistemas existentes que contribuyen al rea de salud podemos mencionar los proyectos de sistemas informticos desarrollados en la Universidad de El Salvador los cuales han sido tomados en consideracin para el desarrollo del presente proyecto. Cada uno de los proyectos anteriormente desarrollados proponen una metodologa que permite, segn el autor, desarrollar una solucin ptima para las instituciones correspondientes, por lo tanto estos han seguido una metodologa basada en las necesidades especficas de cada proyecto. Entre estos sistemas podemos mencionar el Sistema de informacin mecanizado para el registro y manejo de los expedientes clnicos de los pacientes del Hospital Nacional Rosales como una herramienta de apoyo para las investigaciones patolgicas, este sistema pretende llevar un registro de cada uno de los expedientes de los pacientes que acude a consultas manteniendo un historial de estos, proporcionando as la informacin requerida para la realizacin de las investigaciones patolgicas. La realizacin de Sistema informtico para la Administracin y Control de expedientes del CRINA, busca lograr la integracin y automatizacin de los procesos realizados en la institucin, llevar un control de los expedientes de los pacientes, as como un registro del historial mdico de estos.
1.2. ACERCA DE LOS SISTEMAS INFORMTICOS ORIENTADOS A LA WEB

La evolucin de Internet como red de comunicacin global y el surgimiento y desarrollo del Web como servicio imprescindible para compartir informacin, cre un excelente espacio para la interaccin del hombre con la informacin hper textual, a la vez que sent las bases para el desarrollo de una herramienta integradora de los servicios existentes en Internet. Un sistema informtico basado en la Web es aquel sistema que los usuarios pueden utilizar accediendo a un servidor Web a travs de internet o de una intranet mediante un navegador, permitindoles un acceso sencillo y controlado a los datos y servicios de la empresa, tanto para empleados como para clientes y proveedores2. Estas aplicaciones se codifican en un lenguaje (ASP, JavaScript, PHP, etc.) soportado por los navegadores Web en la que se confa la ejecucin al navegador. Un sistema informtico, debe poseer los siguientes componentes:
http://es.wikipedia.org/wiki/Aplicaciones_Web
1. Usuarios 2. Mecanismos de entrada y salida de la informacin 3. Almacenes de datos, informacin y conocimiento 4. Mecanismos de recuperacin de informacin. Tambin se puede mencionar que dichos sistemas permiten desarrollar aplicaciones distribuidas, bases de datos compartidas, accesos universal a la informacin, comercio electrnico, atencin al cliente va internet, mejora en la administracin de las empresas, lo que conlleva a la reduccin de costos e internacionalizacin de las empresas.
1.3. MARCO LEGAL

El marco legal del CRINA est determinado a travs de "La Ley del Instituto Salvadoreo de rehabilitacin de Invlidos decretada por la Asamblea Legislativa en Decreto N 1 de veinticinco de enero de 1962 y por el cdigo de salud que en el Artculo. 207 establece: El Ministerio de Salud, por medio del Instituto Salvadoreo de Rehabilitacin de Invlidos, que en el presente Cdigo se le denominar: "El Instituto", promover el establecimiento de centros y servicios de rehabilitacin para las personas incapacitadas en los aspectos fsicos, psquicos, educacionales, profesionales y econmicos, con el fin de integrarlos como miembros activos de la comunidad., as como por los dems artculos que comprenden la seccin 48 y 49 del referido cdigo.
2. ANTECEDENTES 2.1. GENERALIDADES DEL CENTRO DE REHABILITACIN INTEGRAL PARA LA NIEZ Y LA ADOLESCENCIA3
DESCRIPCIN DE CENTRO El CRINA es una dependencia del ISRI y nace de la necesidad de brindar atencin a los nios y adolescentes con discapacidad, en las diferentes reas tcnicas y de apoyo, que les permitan desarrollar sus potenciales para su adaptacin al medio familiar, social, escolar y laboral. Para alcanzar este objetivo se realiz la fusin de tres Centros existentes: Educacin Especial, Invalidez Mltiple y Parlisis Cerebral. Unin que se enmarca dentro de un proceso de modernizacin aprobado por la Junta Directiva y Presidencia del ISRI. El CRINA inicia sus labores el 1 de julio de 2005, con la idea de convertirse en lder en el rea de la rehabilitacin integral especializada en la atencin de la niez y adolescencia, a travs de sus diferentes programas, como son: Hidroterapia Terapia Canina. Piscina Teraputica.
http://www.isri.gob.sv/contenido04/crina.html
Electroterapia. Confeccin y adaptacin de sillas especiales. Neurologa terapia de grupo de artritis.
A travs de los cuales se pretende garantizar la rehabilitacin mxima funcional y facilitar la integracin a la sociedad de sus usuarios. La poblacin atendida por el CRINA es toda aquella que cuenta con discapacidad fsica, intelectual, sensorial o mixta; estas discapacidades son consecuencia de mltiples patologas de origen congnito, hereditario o adquirido, que causan daos a nivel del sistema nervioso central o perifrico, sistema msculo esquelticos u ortopdicas, tales como: sndromes cromosmicos, sndrome Down, autismo, parlisis cerebral, traumas crneo enceflicos, artritis, mielomeningoceles, artrogriposis, entre otras, segn su histrico, en el ltimo ao el CRINA ha brindado en promedio 178,751 servicios de rehabilitacin (terapias).
MISIN
Somos una institucin pblica autnoma cuya finalidad es la provisin de servicios especializados de rehabilitacin a personas con discapacidad, brindndolos con calidad y calidez, en coordinacin entre el usuario y su grupo familiar, organizaciones e instituciones relacionadas, a fin de desarrollar las habilidades y destrezas necesarias para lograr su independencia funcional, calidad de vida y plena inclusin social.
VISIN
Ser una institucin en servicios de rehabilitacin integral para personas con discapacidad reconocida por su excelencia a nivel nacional e internacional.
GERENCIA MEDICA Y DE GERENCIA MEDICA YDE DESERVICIOS SERVICIOS DE REHABILITACIN. REHABILITACIN.

DIRECCION. DIRECCION.
COMIT DE APOYO A LA GESTION.
SERVICIOS DE APOYO.
SERVICIOS DE TERAPIAS. T. OCUPACIONAL.
ADMINISTRACIN DE CENTRO
COLECTURIA.
PSICOLOGIA
EQUIPO INTERDISCIPLINARIO.
T. LENGUAJE. T. FISICA.
ESDOMED
T. SOCIAL
ALMACEN.
EDUC. FISICA. ADAPTADA.
ENFERMERA.
SERV. GENERALES. T. EDUCATIVA.
T. MUSICAL.
Figura 2.1. Organigrama Centro de Rehabilitacin Integral para la Niez y la Adolescencia
2.2. ANTECEDENTES INFORMTICOS

Actualmente en el CRINA el manejo de la informacin de los pacientes no se encuentra automatizado, por ejemplo: Diariamente el centro moviliza un promedio de 300 expedientes, los cuales pueden ser utilizados para consulta mdica, actualizacin o nicamente verificacin de la informacin. Cuenta con una infraestructura de red que es subutilizada debido a que no cuentan con una aplicacin que permita explotar las ventajas de esta. Para la administracin de los expedientes fsicos no existe ninguna herramienta automatizada que apoye esta labor, la organizacin de estos se manejan mediante fichas fsicas en donde se coloca el nombre del paciente, su nmero de identificacin y la ubicacin fsica de este. La programacin de las citas se lleva en un libro de control. El historial clnico y de terapias se lleva en expedientes fsicos que son actualizados de forma manual. El control de asistencia a las terapias se realiza manualmente en una hoja de asistencia.
3. SITUACIN ACTUAL DEL CRINA 3.1. DESCRIPCIN

Actualmente el Centro de Rehabilitacin Integral para la Niez y la Adolescencia (CRINA), atiende cerca de 2300 pacientes al ao y cuenta con alrededor de 119 empleados para cubrir dicha demanda, los cuales estn distribuidos de la siguiente manera:
NOMBRE DE PUESTO
Paramdicos (Terapistas) Tcnicos Personal Administrativo Operativo
CANTIDAD DE PERSONAS
78 14 15 12
Cuadro 3.1. Personal que labora en el CRINA
El horario en el cual se brinda atencin a los pacientes es: Lunes a viernes de 7:00 am. a 1:00 pm. y de 2:00 pm. a 6:00 pm. Y la atencin en oficinas administrativas es: Lunes a Viernes de 7:30 am. a 3:30 pm.
El CRINA realiza diferentes procesos en la administracin de los expedientes de los pacientes, los cuales son:
Asignacin de Terapista Asignacin de Tipo de Terapia Asiganacin de Horarios de Terapia Prestamo y Actualizacin de Expdientes Control de Asistencias
Creacin de Expediente del Paciente
Creacin de Resmenes Tcnicos
Figura 3.1: Procesos en la administracin de los expedientes de pacientes.
Estos procedimientos, que permiten llevar el control de las rehabilitaciones de los pacientes, se realizan de forma manual, directamente en los expedientes fsicos de ellos. La programacin de las citas, para cada paciente, se realiza en un libro de control de citas y posteriormente se trasladan a una hoja de clculo en donde tambin se lleva el control de estas. No existe ninguna herramienta informtica que permita que todos estos procesos se hagan en una forma rpida, ordenada y fiable, que garantice una disponibilidad expedita de la informacin en beneficio de los pacientes. Con el desarrollo del sistema informtico se pretende que el personal encargado de las rehabilitaciones obtenga una herramienta eficiente para la mejora de estos procesos, que permita que la informacin sea fiable y de fcil acceso.
10
3.2. ENFOQUE DE SISTEMAS DE LA SITUACIN ACTUAL
Figura 3.2. Descripcin utilizando enfoque de sistemas de la situacin actual del CRINA
11
3.2.1. VARIABLES DE ENTRADA

Referencia Consultas Externas: Informe que contiene el diagnstico del paciente resultado de la consulta externa realizada por el ISRI. Tarjeta de Control de Citas y Asistencias: Documento en donde se plasmas la fecha y tipo de terapia que el usuario debe de realizar en el centro, as como la asistencia a estas. Formularios del Expediente Clnico4: Estn compuestos por 20 formularios que el usuario debe de completar para que se pueda emitir un expediente dentro de la institucin, bajo la norma del expediente clnico5.
3.2.2. PROCEDIMIENTOS
Creacin de expedientes: 1. Para la elaboracin o apertura del expediente clnico, se debe consultar el ndice de usuarios6 para asegurarse que el documento no existe previamente en el archivo de la institucin. 2. El expediente debe elaborarse hasta que haya comprobado minuciosamente en el tarjetero ndice, que el usuario realmente no tiene expediente previo en el centro. 3. Los datos para la elaboracin de este formulario, se deben de obtener a travs de una entrevista con el usuario o persona responsable para garantizar que la informacin sea exacta, completa y fiable. El estadstico y/o encargado desarrollara la entrevista en un ambiente de respeto y cortesa hacia el usuario. 4. Con la apertura del expediente clnico, se entregara al usuario el Carnet de Identificacin y Citas (Medicas -Terapias). Tambin se elaborara una tarjeta ndice7 para el usuario.
Creacin de resmenes tcnicos: 1. El padre de familia o interesado solicita a trabajo social el resumen de las evaluaciones tcnicas que recibe su hijo en el CRINA. 2. Trabajo Social recibe solicitud, anota el nombre completo del menor y el nmero de expediente del centro en el respectivo listado y orienta al padre de familia de cuando preguntar por dicho resumen, verifica la asistencia a terapias y evaluaciones psicolgicas. 3. Trabajo social entrega a jefatura de terapia la solicitud del interesado y lo anota en el libro respectivo. 4. Jefatura de Terapias solicita el expediente, lo revisa para identificar los ltimos profesionales involucrados en el proceso de rehabilitacin del menor para que cada uno elabore resumen escrito del rea. 5. Profesional responsable elabora resumen escrito el cual debe incluir: diagnstico de la discapacidad, tratamiento recibido, recomendaciones segn ltima nota de evaluacin y motivo de alta, si es que as se determin.
4 5
Consultar Anexo 1: FORMULARIOS DEL EXPEDIENTE CLINICO. Consultar Anexo NORMA DEL EXPEDIENTE CLINICO CRINA 6 Consultar Glosario Tcnico 7 Consultar Glosario Tcnico
12
6. Secretaria asignada recibe y revisa los resmenes con todos los datos proporcionados por los profesionales de las reas y solicita se digite. 7. Secretaria asignada digita el informe tcnico, lo entrega a jefatura de terapias para su revisin y aprobacin, recoge firmas de todos los profesionales y el visto bueno de la direccin remite informe digitado a trabajo social. 8. Trabajo social entrega informe a padre de familia quien deber de firmar de recibido con copia del informe y en el libro de control de entrega la copia firmada del informe se enviara a consulta externa para que sea agregada a su expediente.
Control de asistencias: 1. Usuario presenta Tarjeta de Control a Secretaria asignada. 2. Secretaria proporciona al usuario los tickets para terapias asignadas. 3. Usuario entrega ticket a terapista. 4. Terapista coloca asistencia en Lista de Asistencia junto con su nmero de expediente.
Prstamo de expedientes: 1. El profesional interesado llenara formato de solicitud para prstamo de expedientes, lo fechara y firmara, entrega formato a la encargada de custodia del expediente. 2. La persona encargada de la custodia del expediente recibe y revisa que todos los formatos de solicitud de prstamo de expediente tengan la informacin correcta y completa. 3. Entrega al encargado o auxiliar de archivo de consulta externa las solicitudes de prstamo de expedientes. 4. Encargado de archivo de consulta recibe solicitud, prepara clasifica los expedientes solicitados en los formatos y entrega los expedientes al encargado de custodia del CRINA. 5. Encargado de custodia recibe y verifica sus respectivos formatos de los expedientes a trasladas y firma de recibido, luego entrega al profesional tcnico o de apoyo del CRINA los expedientes solicitados. 6. El profesional revisa los expedientes y firma de recibido.
Actualizacin de expedientes: 1. Profesional solicita prstamo de expediente. 2. Encargado de custodia del expediente enva expediente a Profesional. 3. Profesional controla la evolucin del paciente 4. Profesional actualiza manualmente el expediente. 5. Profesional devuelve expediente a custodia de expedientes.
Asignacin de horarios de terapias: 13
1. Usuario presenta referencia a Secretaria asignada, esta enva a paciente a trabajo social. 2. Trabajo Social brinda charla informativa y evala situacin del usuario, enva a paciente a Secretaria asignada. 3. Secretaria asignada refiere a paciente a los distintos terapistas. 4. Terapista brinda una charla informativa y evala al paciente, y brinda el visto bueno de recepcin del paciente, esta refiere al paciente a Secretaria asignada. 5. Secretaria asignada solicita al paciente los das que prefiere las terapias o asigna las horas segn disponibilidad.
3.2.3. SALIDAS
Reporte Evolucin de Paciente: Documento elaborado por la institucin que contiene la evolucin de todas las terapias que el paciente recibe.
Reporte Llegadas Tardas Usuarios: Documento que contiene todas las inasistencias o llegadas tardas del paciente a las terapias asignada a la institucin. Expediente Clnico Usuarios: Conjuntos de formularios narrativos y grficos en los cuales se registran en forma detallada y ordenada las observaciones, intervenciones mdicas, teraputicas y otras atenciones en rehabilitacin. Documenta la evolucin, el estado de salud y la prestacin de los servicios de rehabilitacin brindados. Resmenes Tcnicos: Documento que contiene un resumen tcnico completo del usuario, as como un resumen de su expediente clnico. Control de Citas: Documento que controla la asistencia de los usuarios a sus respectivas terapias en la institucin. Asignacin de Mdicos a Terapias: Informe que muestra la asignacin de las terapias que se tienen que brindar a los usuarios del centro a los mdicos/terapista con los que se cuenta. 4. METODOLOGA
En todo proyecto se debe establecer de forma clara los pasos a seguir para alcanzar los objetivos propuestos, por lo tanto es de vital importancia especificar una metodologa que defina de modo sistemtico, como se realizar y administrar dicho proyecto, esto ayudara a alcanzar los objetivos planteados. En proyectos informticos la eleccin de un tipo y modelo de ciclo de vida para el desarrollo de sistemas depender de las caractersticas del proyecto y los requerimientos del mismo.
4.1. METODOLOGA PARA LA SOLUCIN DE PROBLEMAS

Para el desarrollo del Sistema Informtico para la Administracin y Control de Expedientes del CRINA se utilizar el Modelo de Ciclo de Vida de Entrega por Etapas8.
Consultar ANEXO 2: EVALUACION Y SELECCION DEL MODELO DE CICLO DE VIDA
14
Este modelo de ciclo de vida consiste en dividir la entrega del sistema en determinado nmero de etapas completamente funcionales, las cuales son entregadas al usuario. El cual ya tiene bien definidas las necesidades que desea cubrir y se mantendr involucrado en el desarrollo del proyecto. Grficamente las etapas que abarca este ciclo de vida se muestran en la figura 4.1:
Conocer la Problemtica
Anlisis de Requerimientos
Diseo Global
Etapa 1: Diseo detallado, construccin, depuracin, pruebas y entrega. Etapa 2: Diseo detallado, construccin, depuracin, pruebas y entrega.
Etapa n: Diseo detallado, construccin, depuracin, pruebas y entrega.
Figura 4.1. Diagrama de ciclo de vida de entrega por etapas.
4.2. METODOLOGA DE LA INVESTIGACIN A DESARROLLAR Tipo de investigacin

El proceso de investigacin es primordial para conocer a profundidad la problemtica por la cual se necesita del sistema, realizar un buen anlisis y determinar los requerimientos del sistema. Para el desarrollo del proyecto se utilizarn dos tipos de investigacin: la investigacin histrica, que se utilizar para recaudar informacin de experiencias o acontecimientos pasados y la investigacin descriptiva, que se utilizar para recaudar informacin de hechos presentes.
Herramientas para la recoleccin de datos

Durante el desarrollo del proyecto se recolectarn los datos utilizando las siguientes herramientas:
Entrevista
La entrevista ser utilizada como medio para recabar informacin de manera verbal. Se realizaran dos clases de entrevistas: Entrevistas dirigidas al personal de Atencin del CRINA: Son entrevistas dirigidas al personal que labora en el CRINA, personas encargadas de las terapias, asignar las citas, llevar el control de los expedientes, etc. tienen una vista general de las necesidades de los pacientes y conocen los requerimientos que pueden ser necesarios para implementar un sistema. Entrevistas dirigidas a los Usuarios (Familiares de Pacientes): Son entrevistas dirigidas a los familiares de los pacientes y que tienen relacin directa con el proceso, ya que son ellos los que regularmente se encuentran en contacto al llevar al paciente a las terapias o controles.
15
Encuesta
La encuesta ser utilizada como medio para recabar informacin de manera escrita. Se realizarn dos clases de encuestas: Encuestas al personal de Atencin del CRINA: El objetivo de esta encuesta es determinar el nivel de productividad del cmo se realiza el procedimiento en la actualidad, as tambin se identificaran problemas y requerimientos tcnicos. Encuestas a los Usuarios (Familiares de Pacientes): El objetivo de esta encuesta tambin es determinar el nivel de productividad del procedimiento actual desde el punto de vista de los pacientes, identificar los problemas del mismo y requerimientos de los usuarios.
Esta encuesta ayudar a medir la productividad del proceso actual ya que por medio de ellas se obtendrn datos relevantes del funcionamiento de este, como son: tiempos de espera, capacitacin del personal, insumos con los que se cuentan, etc. Una vez obtenida dicha informacin se ordenar y analizar, estableciendo mtricas y pesos para su medicin.
Observacin
La observacin se utilizar como medio para recabar informacin de manera visual. Consiste en realizar visitas al CRINA y observar los procesos que a diario el personal ejecuta.
Investigacin bibliogrfica
El material bibliogrfico se utilizar para recolectar informacin sobre los antecedentes, caractersticas, elementos, normas del proceso de atencin. As tambin, se utilizar el Internet para recolectar informacin relevante y herramientas que contribuyan al desarrollo del proyecto.
4.3. METODOLOGA PARA EL PLANTEAMIENTO DEL PROBLEMA

El planteamiento del problema se realizar utilizando el diagrama de causa-efecto o diagrama de Ishikawa, para tener una visin sencilla y concentrada del anlisis de las causas que contribuyen a la situacin problemtica.
4.4. METODOLOGA PARA EL ANLISIS

Para el anlisis del sistema se utilizarn las siguientes metodologas: Enfoque de sistemas Diagramas de casos de uso Diagramas de clase Diagramas de flujo de datos Enfoque de Sistemas Se utiliza para la determinacin de los factores del medio ambiente, mecanismos para transformar entradas en salidas, la frontera del sistema y elementos de control.
16
Diagramas de Casos de Uso Los diagramas de caso de uso proporcionan uno o ms escenarios que indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico. Este tipo de diagramas est compuesto por tres elementos: Casos de Uso Actores Relaciones Diagrama de Clases El diagrama de clases es el diagrama principal para el anlisis y diseo del sistema. Presenta las clases del sistema con sus relaciones de dependencia y de herencia. La definicin de clase incluye definiciones para atributos y operaciones. El modelo de casos de uso debera aportar informacin para establecer las clases, objetos, atributos y operaciones. Diagramas de Flujo de datos Es una representacin grfica de los procesos de datos a lo largo del sistema analizado, que facilita la comprensin de las interrelaciones de los sistemas y subsistemas.
4.5. METODOLOGA PARA EL DISEO

Definicin de estndares del diseo Los estndares son un conjunto de reglas y especificaciones a seguir que sern implementadas durante el desarrollo de un proyecto. Se definirn estndares para el modelado de clases, pantallas, reportes, documentacin, base de datos y programacin. Los cuales tienen como objetivo que todos los involucrados en el desarrollo del proyecto conozcan la metodologa a utilizar, la manera de entenderla, disminuir el tiempo en la bsqueda de errores y optimizar la construccin del sistema. Modelo de casos de uso Se utilizar el modelado de casos de uso como medio de comunicacin entre los usuarios y los desarrolladores, para comprender la funcionalidad del sistema, delimitar los privilegios de cada usuario, etc. Diccionario de datos Un diccionario de datos es un conjunto de metadatos que contiene las caractersticas lgicas de los datos que se van a utilizar en el sistema, incluyendo nombre, descripcin, alias, contenido y organizacin. El diccionario de datos es un listado organizado de todos los elementos de datos que son adecuados para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma comprensin de las entradas, salidas, de las componentes de los almacenes y tambin de los clculos intermedios. El formato del diccionario de datos contiene la siguiente informacin: a) Nombre: el nombre principal del elemento de datos o de control, del almacn de datos, o de una entidad externa. b) Alias: otros nombres usados para el nombre.
17
c) Dnde se usa/ cmo se usa: un listado de los procesos que se usan el elemento de datos o de control y cmo lo usan (ejemplo: como entrada al proceso, como salida al proceso, cmo almacn de datos, como entidad externa). d) Descripcin del contenido: el contenido representado mediante una anotacin. e) Informacin adicional: otra informacin sobre los tipos de datos, los valores implcitos (s se conocen), las restricciones o limitaciones, etc. Diseo de salidas El diseo de las salidas del sistema permite especificar las salidas que debe proveer el sistema. Las salidas se han dividido en: reportes e informes, interfaces de salida, mensajes y ventanas de ayuda. Diseo de entradas El diseo de las entradas del sistema permite especificar las entradas que tendr el sistema. Tales como: procesos de captura de datos e interfaces de entrada. Diseo de seguridades En el diseo de seguridades se incluye la seguridad que tendr el sistema y cada uno de los mdulos que lo conforman, los niveles de acceso de acuerdo a los usuarios y los privilegios que cada uno de ellos tiene, las copias de seguridad de los datos con el fin de mantener segura toda la informacin. Diseo de la base de datos El diseo de la base de datos contempla todos los aspectos concernientes al desarrollo de la base de datos, tales como: diseo lgico, diseo fsico, roles de usuario, esquemas de tablas, vistas, funciones y procedimientos, ndices, particiones de tablas. Adems, se incluye el diseo para la administracin de la base de datos.
4.6. METODOLOGA PARA EL DESARROLLO

Metodologa para la construccin del sistema Diagrama de arriba hacia abajo (Top-Down) Es una estrategia que se utilizar para visualizar el sistema de forma global y posteriormente dividirlo en partes, con el fin de convertir un problema grande y complejo en un problema pequeo y fcil de solucionar. Programacin Orientada a Objetos (POO) El sistema se construir utilizando la programacin orientada a objetos. Dicha metodologa define los programas en trminos de clases de objetos, objetos que son entidades que combinan estado (datos), comportamiento (procedimientos o mtodos) e identidad (propiedad del objeto que lo diferencia del resto). La programacin orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y mdulos ms fciles de escribir, mantener y reutilizar.
18
Metodologa para las pruebas Para la realizacin de pruebas se utilizar la Metodologa de Pruebas Orientada a Objetos para el Ciclo de Vida Completo (en ingles "Full Life-Cycle Object-Oriented Testing", FLOOT). La metodologa a utilizar es una coleccin de tcnicas para verificar y validar software orientado a objetos. El ciclo de vida FLOOT, indica una amplia variedad de tcnicas que estn disponibles en todos los aspectos del desarrollo de software. No es necesario utilizar todas las tcnicas de FLOOT ni aplicarlas de forma secuencial. Las pruebas mediante el uso de FLOOT pueden realizarse durante el desarrollo del software y no solamente durante la codificacin.
En la siguiente tabla se describen las tcnicas de FLOOT a utilizar:

Tcnica FLOOT Prueba de Caja-Negra Prueba de ValoresFrontera Prueba de Componente Prueba de Integracin Descripcin La prueba verifica que el tem que se est probando, cuando se dan las entradas apropiadas, produce los resultados esperados. Es la prueba de situaciones extremas o inusuales que el tem debe ser capaz de manejar. Es el acto de validar que un componente funciona tal como est definido. Consiste en realizar pruebas para verificar que un gran conjunto de partes del software funcionan juntas. Un tipo de inspeccin, que puede ser desde una revisin tcnica formal hasta un recorrido informal, realizado por personas diferentes a las que estuvieron directamente involucradas en el desarrollo del modelo. El objetivo principal es probar si el diseo del prototipo satisface las necesidades de esos usuarios. El acto de asegurar que los comportamientos previamente probados todava trabajan como se espera luego que se han realizado cambios a la aplicacin. El acto de asegurar que el sistema funciona como se espera bajo grandes volmenes de transacciones, usuarios, carga y otras variables relevantes que pueden influir en el software.
Tabla 4.1 tcnicas de floot.
Revisin de Modelos
Revisin de Prototipos Prueba de Regresin
Prueba de Stress
4.7. METODOLOGA PARA LA DOCUMENTACIN

La documentacin del sistema contempla los siguientes manuales: Manual de usuario: Consiste en una descripcin global del sistema, le permite al usuario conocer y utilizar el mismo. Manual tcnico: Descripcin detallada del sistema, por medio del cual el usuario tcnico podr referirse para dar el mantenimiento requerido al sistema. Manual de instalacin/desinstalacin: Describe los pasos para la instalacin o desinstalacin del sistema.
Los manuales se realizarn al finalizar la construccin del sistema. 19
5. FACTIBILIDADES
Un proyecto es factible en el momento que se logra determinar que es posible desarrollarlo con los recursos disponibles. El xito del proyecto, se fundamenta en el grado de factibilidad que se presente en cada uno de los siguientes aspectos: 1. Factibilidad Tcnica 2. Factibilidad Econmica 3. Factibilidad Operativa.
5.1. FACTIBILIDAD TCNICA

Para determinar si el proyecto es factible tcnicamente, se debe realizar una serie de evaluaciones las cuales permitan establecer de manera contundente si el hardware, software y recurso humano con el que se cuenta tanto en el ambiente de desarrollo como en el de produccin (CRINA), posee las capacidades tcnicas necesarias para el desarrollar e implementar el Sistema Informtico para la Administracin y Control de Expedientes del CRINA. Adems en el caso de necesitar nueva tecnologa, se debe evaluar si su adquisicin es asequible.
5.1.1. RECURSO TECNOLGICO Y HUMANO DEL EQUIPO DE DESARROLLO

El recurso tecnolgico incluye en trminos generales herramientas, equipos, instrumentos, materiales, maquinas, dispositivos y software necesarios para lograr el propsito tcnico, establecido por el equipo de desarrollo. Por otro lado; el recurso humano que ser evaluado para determinar la factibilidad tcnica, es aquel que posee los conocimientos tcnicos necesarios para desarrollar el proyecto propuesto. Esta evaluacin se divide en tres partes: Software, Hardware y Recurso Humano.
5.1.1.1.
SOFTWARE
En base a las limitaciones planteadas por el CRINA, la seleccin del lenguaje de programacin y gestor de base de datos solamente podr realizarse entre tecnologas de licenciamiento libre, por otro lado para la seleccin del entorno de desarrollo no hubo restriccin, despus de una evaluacin tcnica9 se determin que las tecnologas a utilizar sern las siguientes: Gestor de Bases de Datos, MySQL MySQL, es un sistema de gestin de base de datos relacional multiplataforma, multihilo y multiusuario, distribuido bajo un sistema de licenciamiento dual, que por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia especfica que les permita este uso. A continuacin se destacan algunas de las caractersticas principales de MySQL: Soporta Procedimientos almacenados, triggers, cursores y vistas actualizables. Aprovecha la potencia de sistemas multiprocesador, gracias a su implementacin multihilo.
Ver ANEXO #4: Evaluacin y seleccin de Tecnologas de Desarrollo
20
Dispone de API's en gran cantidad de lenguajes (C, C++, Java, PHP, etc.). Gran portabilidad entre sistemas. Proporciona sistemas de almacenamiento; transaccionales y no transaccionales. Joins muy rpidos usando un multi-join de un paso optimizado. Las funciones SQL estn implementadas usando una librera altamente optimizada y deben ser tan rpidas como sea posible. Flexible sistema de contraseas (passwords) y gestin de usuarios, con un muy buen nivel de seguridad en los datos. El servidor soporta mensajes de error en distintos idiomas.
Lenguaje de Programacin, PHP 5 PHP, es un lenguaje interpretado de propsito general, ampliamente usado y que est diseado especialmente para desarrollo Web y puede ser incrustado dentro de cdigo HTML. Generalmente se ejecuta en un servidor Web, tomando el cdigo en PHP como su entrada y creando pginas Web como salida. Puede ser desplegado en la mayora de los servidores web y en casi todos los sistemas operativos y plataformas. PHP no necesita ser compilado para ejecutarse. Para su funcionamiento necesita tener instalado Apache o IIS con las libreras de PHP. La mayor parte de su sintaxis ha sido tomada de C, Java y Perl con algunas caractersticas especficas. Algunas de las caractersticas que presenta este lenguaje son las siguientes: Muy fcil de aprender. Es un lenguaje muy rpido. Soporta en cierta medida la orientacin a objeto. Clases y herencia. Capacidad de conexin con la mayora de los manejadores de base de datos: MySQL, PostgreSQL, Oracle, MS SQL Server, entre otras. Capacidad de expandir su potencial utilizando mdulos. Posee documentacin en su pgina oficial la cual incluye descripcin y ejemplos de cada una de sus funciones. Incluye gran cantidad de funciones.
Entorno de desarrollo, Adobe Dreamweaver CS3 Adobe Dreamweaver, es una aplicacin en forma de estudio pero con ms parecido a un taller destinado para la construccin y edicin de sitios y aplicaciones Web basados en estndares. Dreamweaver permite al usuario utilizar la mayora de los navegadores Web instalados en su ordenador para pre visualizar las pginas Web. Tambin dispone de herramientas de administracin de sitios dirigidas a principiantes como, por ejemplo, la habilidad de encontrar y reemplazar lneas de texto y cdigo por cualquier tipo de parmetro especificado, hasta el sitio Web completo. El panel de comportamientos tambin permite crear JavaScript bsico sin conocimiento de cdigo. 21
Servidor Web, Apache 2 Debido a que el Sistema Informtico para la Administracin y Control de Expedientes del CRINA, es un sistema orientado a las Web que estar basado en una arquitectura cliente servidor, la cual sugiere la utilizacin de un servidor que proporcione a los clientes los servicios solicitados, por lo tanto se necesita de un servidor que soporte las tecnologas de desarrollo antes descritas. Para el caso de este proyecto se utilizar un servicio de alojamiento Web provisto por terceros10. En la Tabla 5.1. se muestran las prestaciones obtenidas por el proveedor de alojamiento Web.
Prestaciones por alojamiento Web

Espacio en disco duro para almacenamiento Transferencia mensual de datos Lenguaje de programacin Tipo de servidor Gestor de Bases de Datos Proporciona DNS 20GB 200GB PHP 5.1.4 Apache 2.0.52 MySQL Si
Tabla 5.1. Prestaciones ofrecidas por el proveedor de alojamiento Web
5.1.1.2.
Detalles PC
Pc1 Pc2 Pc3 PC
HARDWARE
Las especificaciones de hardware con el que cuenta el equipo de desarrollo se muestran en la Tabla 5.2. Marca
HP GATEWAY DELL HP
Modelo
530 MT3422 Inspiron 1564 HP Pavilion dv42145dx
Procesador
INTEL CENTRINO DUO AMD Athlon 64 x 2 Intel Pentium Dual Core 2.2 GHz AMD Turion 64 X2
Memoria
3GB 1GB 4 GB 4 GB
DD
250 GB 120 GB 320 GB 320 GB
Monitor
15.1 14.1 17.3 14.1
Tabla 5.2. Especificaciones tcnicas del hardware con que cuenta el equipo de desarrollo.
En el apartado 5.1.1.1. Software, se defini el software a utilizar, en base a este, podemos determinar los requerimientos mnimos en hardware con el que debera contar el equipo tcnico para lograr un ambiente ptimo de desarrollo. En la tabla 5.3. Podemos observar los requerimientos mnimos que exige cada una de las herramientas de desarrollo seleccionadas.
10
Proveedor de alojamiento Web que cumple con los requerimientos de tecnologa de desarrollo es www.godaddy.com.
22
Recurso
Procesador RAM Disco Duro
Dreamweaver
1 GHz 512 MB 10GB
MySQL
400 MHz 256 MB 200 MB
PHP 5
300MHz 128 MB 50 MB
Tabla 5.3. Requerimientos en Hardware de las herramientas seleccionadas.
Debido a que se contratara un servicio de alojamiento Web el cual proporcionara soporte para MySQL, Apache 2 y PHP, las maquinas del equipo de desarrollo adoptaran los requerimientos mnimos propuestos por el fabricante de Dreamweaver, estos se muestran en la tabla 5.4.
Requerimientos Mnimos
Sistema Operativo Procesador Memoria Disco Duro Windows XP 1 GHz 512 MB 20 GB
Tabla 5.4. Requerimientos mnimos de hardware para el equipo de desarrollo.
5.1.1.3.

RECURSO HUMANO TCNICO
El equipo de desarrollo cuenta con los siguientes conocimientos y habilidades tcnicas: Conocimiento en tcnicas de recoleccin de datos. Habilidad para comunicarse con los usuarios del negocio. Anlisis, diseo y programacin de sistemas informticos. Capacidad para resolver problemas. Conocimiento en lenguajes de programacin y Lenguaje Estructurado de Consultas (SQL). Conocimiento en instalacin y configuracin de redes.
La tabla 5.5. Muestra la cantidad de personas y los cargos que estas desempearan durante el desarrollo del presente proyecto.
Cantidad
1 3 1 1
Cargo
Director del Proyecto Analista de Sistema Docente Director (Asesor de proyecto) Observador (Evala al equipo de desarrollo)
Tabla 5.5. Recurso humano disponible para realizar el proyecto.
23
5.1.2. RECURSO TECNOLGICO Y HUMANO DEL CRINA

A continuacin se detallara el software, hardware y el recurso humano tcnico con que cuenta el ambiente de produccin, es decir el CRINA.
5.1.2.1.
SOFTWARE
En cuanto a software el sistema operativo con que cuentan todas las estaciones de trabajo del CRINA es Windows XP.
5.1.2.2.
HARDWARE
A continuacin se muestra una tabla resumen de las caractersticas de las estaciones de trabajo con las que se cuentan en el CRINA.
Procesador
PC1 PC2 PC3 PC4 PC5 PC6 PC7 Pentium 4 2.8 GHz Pentium 4 1.5 GHz Pentium 4 2.4 GHz Pentium 4 2.5 GHz Pentium 4 2.8 GHz Pentium 4 1.8 GHz Pentium 3 793 MHz
Disco Duro
80 GB 40 GB 40 GB 20 GB 60 GB 30 GB 40 GB
Memoria
1 GB 512 MB 512 MB 256 MB 1 GB 512 MB 256 MB
Tarjeta de red
Si Si Si Si Si Si Si
Unidad ptica
Si Si Si Si Si Si Si
Tabla 5.6. Especificaciones de estaciones de trabajo que posee el CRINA.
Para que el Sistema para la Administracin para la Administracin y Control del CRINA, funcione de forma correcta, es necesario contar con un navegador, por lo tanto los requerimientos mnimos en hardware para las maquinas clientes son los mismos definidos por el sistema operativo (S.O.), tomando como referencia Windows XP, ya que este es el S.O. que utilizan los equipos con los que cuenta el CRINA y este, como todos lo S.O., incorpora por defecto un navegador.
Sistema Operativo Procesador Memoria Disco Duro Windows XP 450 MHz 256 MB 8 GB
Tabla 5.7. Requerimientos mnimos de hardware para las maquinas clientes.
24
Tecnologa de Comunicaciones Actualmente el proveedor de Internet del CRINA es Telecom a travs de Turbonett con un ancho de banda de 2Mb. El sistema que se desarrollara estar alojado en un servidor comercial que cumpla con los requerimientos mnimos de produccin del sistema, por lo tanto los usuarios accedern al sistema a travs de Internet.
5.1.3. RECURSO HUMANO TCNICO

Los conocimientos y habilidades mnimas que debe tener un Administrador de Sistemas para realizar una adecuada operacin y mantenimiento de sistemas son los siguientes:
Conocimientos: Disciplinas bsicas de la Ingeniera Administracin Cmputo Anlisis, Diseo e Implementacin de SI Comprensin del funcionamiento de los S.O. Diseo e Implementacin de Redes de Datos Administracin de Recursos Humanos Cultura de Calidad Mantenimiento de Sistemas Computacionales Modelos de Toma de Decisiones Habilidades: Solucionar problemas Capacidad de anlisis Multidisciplinario Autodidacta Bilinge Creatividad Tomar decisiones Administracin del Tiempo
La institucin ya cuenta con un rea de Sistemas que facilite la realizacin de todas las actividades antes descritas. Conclusin. Al haber evaluado los recursos tecnolgicos necesarios para el desarrollo del proyecto, se pudo determinar que el equipo de desarrollo cuenta con el hardware, software y conocimientos tcnicos necesarios para desarrollar el proyecto, as tambin se pudo determinar que el equipo con que cuenta actualmente el CRINA, cumple con los requerimientos mnimos necesarios para que el sistema propuesto pueda operar de forma optima en el ambiente de produccin. Por lo tanto se ha determinado que el proyecto es FACTIBLE TCNICAMENTE.
5.1.4. FACTIBILIDAD ECONMICA

En este apartado se pretende hacer un estudio econmico para determinar si el proyecto a desarrollar ser factible econmicamente o no, esto se har a travs de un anlisis econmico que compara los costos de dos alternativas para determinar cul es la que genera un ahorro sobre la otra.
25
A continuacin se presenta un estudio que dio como resultado la factibilidad econmica del desarrollo del nuevo sistema.
5.1.5. ANLISIS COSTO BENEFICIO

Este anlisis permiti hacer una comparacin entre la relacin costos del sistema actual y los costos que tendra el nuevo sistema, conociendo de antemano los beneficios que ofrece hoy en da la ciencia informtica. Como se menciono anteriormente en el estudio de la factibilidad tcnica, el CRINA cuenta con las herramientas necesarias para la puesta en marcha del sistema, por lo cual el sistema propuesto no requiere de una inversin inicial. El resumen del anlisis costo-beneficio se definen en comparacin de los costos implcitos, tanto del sistema actual como del sistema propuesto y su relacin con los beneficios expresados en forma tangible. Costos de Desarrollo del sistema propuesto. Son aquellos gastos en los que se incurre una tan sola vez, y se aplican en la obtencin de un bien ya sea tangible o intangible. Incluye el costo de los materiales, mano de obra y los gastos indirectos de fabricacin cargados a los trabajos en su proceso. Determinacin de Costos de Operacin Se define como costos de operacin aquella suma de recursos destinados a la administracin, operacin y funcionamiento de un sistema que se pagan de forma recurrente durante periodos regulares. Para realizar un anlisis econmico entre dos alternativas es necesario definir sus costos en trminos monetarios y as poder aplicar una tcnica que nos permita tomar una decisin sobre qu camino seguir. Los costos a definir son: 1. Costos de operacin del sistema actual. 2. Costos de operacin del sistema propuesto. Costos de operacin del sistema actual. Para determinar los costos de operacin del sistema actual se han tomado en cuenta los procesos que se llevan a cabo de forma manual y que con la creacin del sistema propuesto se pretenden eliminar. Consideraciones. Para realizar la estimacin se tomarn en cuenta las siguientes consideraciones: 1. El costo base en el proceso de ingreso y seguimiento de rehabilitacin ser tomado para un paciente 2. Se evaluarn dos alternativas una realizar el proceso de la forma actual y la otra con el apoyo del sistema propuesto. 3. Se tomar el salario base para un Auxiliar de Archivo del CRINA $430.0011. 4. Para las actividades que se desarrollan diariamente se ha considerado una jornada laboral de 5 horas de lunes a viernes se han considerado 22 das hbiles por mes. Esto significa un total de
11
Salario proporcionado por personal administrativo del ISRI
26
11012 horas al mes. Responsable

Auxiliar de Archivo
Salario mensual ($)

$430.00
Salario por hora($)

$3.91
Tabla 5.8 de salario promedio de un auxiliar de archivo
5. Se tomarn en cuenta 230013 pacientes del CRINA 6. La estimacin de tiempos y actividades ha sido basada en la entrevista a un terapista de CRINA, a personal de direccin. 7. Los terapistas ocupan un da completo cuando se presentan las Capacitaciones anuales, estas se realizan para adaptarse a los nuevos lineamientos y metodologas vigentes, lo que incluye el aprendizaje de tcnicas nuevas. 8. El seguimiento de rehabilitacin e ingresos al CRINA se tomaran cuanto menos de cinco aos.
Determinacin del costo del proceso de ingreso y seguimiento de rehabilitacin de un paciente del crina. A continuacin se detallan las actividades y el tiempo estimado de cada una de ellas. Actividad
Capacitacin del Terapista Capacitaciones anuales Ingreso al CRINA Creacin del expediente Charla de Bienvenida (incorporacin al sistema) Charla de trabajo social (anotaciones en el expediente) Charla de Psicologa (control temporal) Evaluacin en cada rea del CRINA (recomendacin del Neurlogo) Seguimiento de Rehabilitacin Control trimestral (peticin de un expediente) Cita para Evaluacin psicolgica Evaluacin psicolgica.(peticin del expediente) Altas a pacientes Otros procesos Resumen medico total
Tabla 5.9 Tiempo en actividades
Tiempo (en horas; Minutos)

8 hrs. 8 hrs. 49:10 hrs 30 min. 24 hrs. 24 hrs. 10 min. 30 min. 72:20 hrs. 24 hrs. 20 min. 24 hrs. 24 hrs. 24 hrs. 24 hrs. 153:30:00
12 13
(5 horas/da*22 das laborales/mes=110 horas/mes). Cantidad de pacientes que el CRINA atiende en un ao
27
A continuacin se detalla el costo por actividad al realizar el proceso de ingreso y seguimiento de rehabilitacin de un paciente del CRINA. Actividad
Ingreso crina Capacitacin del Terapista Seguimiento Rehabilitacin Otros procesos Total
Tabla 5.10 costo por actividades
Tiempo (horas)
49:10:00 8 72:20:00 24
Costo/hora ($)
3.91 3.91 3.91 3.91
Costo/actividad($)
192.24 31.28 282.82 93.84 600.18
Determinacin del costo del proceso con el desarrollo del sistema para un paciente del CRINA. A continuacin se detalla el tiempo estimado para realizar el proceso de seguimiento e ingreso de un paciente del CRINA con el desarrollo del sistema informtico.
Actividad
Capacitacin del Terapista Capacitaciones anuales Ingreso al CRINA Creacin del expediente Charla de Bienvenida (incorporacin al sistema) Charla de trabajo social (anotaciones en el expediente) Charla de Psicologa (control temporal) Evaluacin en cada rea del CRINA (segn recomendacin del Neurlogo) Seguimiento de Rehabilitacin Control trimestral (peticin de un expediente) Cita para Evaluacin psicolgica Evaluacin psicolgica.(peticin del expediente) Altas a pacientes Otros procesos Resumen medico total
Tabla 5.11. Actividades desarrolladas con el sistema.
Tiempo (en horas)

8 hrs. 8 hrs. 1:20 hrs 10 min. 15 min. 15 min. 10 min. 30 min. 25 min. 5 min. 10 min. 5 min. 5 min. 5 hrs. 5 hrs. 9:50 hrs
28
A continuacin se detalla el costo por actividad al realizar el proceso de ingreso y seguimiento de rehabilitacin de un paciente del CRINA con el sistema propuesto.
Actividad Ingreso crina Capacitacin del Terapista Seguimiento Rehabilitacin Otros procesos
Tiempo primer periodo (horas) 1:20 hrs 8 25 min 5 hrs Total
Costo/hora ($) 3.91 3.91 3.91 3.91
Costo/actividad($) 5.21 31.28 1.63 19.55 57.67
Tabla 5.12 Tabla de procesos de ingreso y rehabilitacin.
Determinado el costo de ingresos al CRINA y el seguimiento de rehabilitacin de cada paciente, teniendo 2300 pacientes en proceso de rehabilitacin y un ingreso de 100 anuales en promedio, con el sistema propuesto se presentan las siguientes tablas.
Costo de Procesos de Rehabilitacin 52.46
Cantidad Pacientes 2300
COSTO TOTAL($) 120,658
Tabla 5.13 Costo por seguimiento de rehabilitacin.
Costo de Proceso de ingreso 5.21
Cantidad Pacientes 100
COSTO TOTAL($) 521
Tabla 5.14 Costo por el proceso de ingreso.
El total consolidado de los pacientes en seguimiento de rehabilitacin y los de nuevo ingreso es de $121,179.00.
Costo total del sistema propuesto = costo de desarrollo (inversin inicial) + costos del proceso de planificacin con el sistema propuesto. Costo total del sistema propuesto = $24,198.5714 + $121,179.00.
Costo total del sistema propuesto = $145,396.57.
Comparacin del costo de proceso actual y del proceso con el sistema a desarrollar.
14 Ver ANEXO #4: Determinacin de los costos del proyecto
29
a) Determinacin de la Vida til. Para establecer la vida til, se toman en cuenta los procesos de ingreso y de seguimiento de rehabilitacin durante 5 aos. b) Determinacin de la tasa inflacionaria. La tasa de inters inflacionaria que se utilizar es de 12%15 obtenida del banco central de reserva. Se considera la tasa anual promedio para los prximos 5 aos de vida til del proyecto ser de: 12%/5 aos=2.4%/ao. La tasa de inters anual es del 2.4%. c) Costos totales de las alternativas para realizar el proceso de planificacin. Los costos totales anuales de los procesos de ingreso y seguimiento de rehabilitacin en el CRINA sin el sistema asciende a: $1, 399,638.00 Costo total de realizar el proceso de ingreso y seguimiento de rehabilitacin con el sistema propuesto = costo de desarrollo (inversin inicial) + costos de los procesos de ingreso y seguimiento con el sistema propuesto. Costo total del sistema propuesto = $24,198.57+ $121,179.00 Costo total del sistema propuesto = $145,377.57
EGRESOS DE LAS ALTERNATIVAS DEL PROCESO DE PLANIFICACIN A LO LARGO DE SU VIDA TIL

proceso Actual ($) Con el apoyo del sistema($) Inversin Inicial
$1,399,638 $145,377.57
Ao 1(2011)
$1,399,638
Ao 2(2012)
$1,399,638
Ao 3(2013)
$1,399,638
Ao 4(2014)
$1,399,638
Ao 5(2015)
$1,399,638
Tabla 5.15 Egresos de las alternativas del proceso de ingreso y seguimiento de rehabilitacin.
Proceso de ingreso y seguimiento de rehabilitacin actual 2011 2012 2013 2014 2015 Aos
1,399,638
1,399,638
1,399,638
1,399,638
1,399,638
Figura 5.1 Proceso de ingreso y seguimiento de rehabilitacin actual
15 www.bcr.gob.sv
30
Proceso de ingreso y seguimiento de rehabilitacin con el sistema propuesto. 2011 2012 2013 2014 2015 Aos
145,377.57 145,377.57 145,377.57 145,377.57 145,377.57

Figura 5.2 Proceso de ingreso y seguimiento de rehabilitacin con el sistema propuesto actual.
Clculo del Valor Presente16. Frmula P= S [1/(1+i)n ] Dnde: P: Valor Presente S: Cantidad en el Futuro i: Tasa de inters anual n: Nmero de aos Aplicando la frmula del mtodo valor presente a cada ao y luego sumando cada uno de ellos se obtiene cunto costara el proyecto a lo largo de su vida til en el presente.
Proceso de ingreso y seguimiento de rehabilitacin actual.
Aos n=1 n=2 n=3 n=4 n=5 Costo de realizar el ingreso y seguimiento de la rehabilitacin en presente.
Valor presente ($) 1,399,638 1,115,782.84 996,234.68 889,495.25 749,192.18 5,195,342.95
Tabla 5.16 Tabla de clculo de valor presente proceso actual
16 Gabriel Baca Urbina; Formulacin y evaluacin de proyectos informticos; McGraw Hill, quinta edicin, Mxico D. F., 2006.
31
Proceso de ingreso y seguimiento de rehabilitacin con el sistema propuesto.
Aos n=1 n=2 n=3 n=4 n=5 Costo de realizar el ingreso y seguimiento con el sistema propuesto en el presente.
Valor presente ($) 145,377.57 115,849.11 103,476.88 92,390.10 82,491.10 539,589.76
Tabla 5.17 Tabla de valor presente de los proceso con el apoyo del sistema.
Conclusin de la Factibilidad Econmica. Beneficio = valor presente del proceso actual valor presente del proceso con el apoyo del sistema propuesto. Beneficio = $5, 195,342.95 - $539.589.76 Beneficio = $ 4, 655,753.19 A partir de los resultados obtenidos por el mtodo del Valor Presente Neto (VPN), se puede concluir que el proyecto Sistema informtico de control y administracin de expedientes clnicos de pacientes del CRINA es factible econmicamente, ya que en su vida til el valor presente asciende a $539,589.76 lo que genera un beneficio en el presente de $ 4,655,753.19 en contraste con el valor presente de realizar los procesos de ingreso y seguimiento de rehabilitacin de la forma actual que asciende a $ 5,195,342.95. El resultado obtenido, se puede traducir en un ahorro de tiempo al realizar los procesos de ingreso y seguimiento de rehabilitacin con el apoyo del sistema propuesto, representado monetariamente, lo que no significa que el CRINA dejar de gastar esa cantidad. Ms bien, se redistribuir el tiempo en otras actividades con lo que el personal del CRINA puede fortalecer otras reas.
5.2. FACTIBILIDAD OPERATIVA

Para la aceptacin de desarrollo de Sistema Informtico para la Administracin y Control de Expedientes del CRINA, se ha realizado un estudio sobre la factibilidad operativa, la cual permite medir el grado de urgencia del problema presentado por dicha institucin, inters y aceptacin de la solucin propuesta hacia los usuarios. Para dicho estudio se utilizara la tcnica llama PIECES. Dicha tcnica utiliza una serie de interrogantes en base a las cuales se elabor una encuesta17 para determinar si el proyecto es factible operativamente.
17
Ver ANEXO: ENCUESTA A LOS USUARIOS DEL NEGOCIO
32
5.2.1. APLICACIN DE LA TCNICA PIECES

Prestaciones: Proporciona el sistema la productividad y tiempo de respuesta apropiado? La necesidad expresada por parte de los usuarios involucrados en la institucin, llevo a la aceptacin de un sistema informtico que de una manera sencilla y amigable, cubra los requerimientos solicitados y proporcione la informacin en forma oportuna y confiable para poder incrementar la productividad reduciendo el tiempo en cada uno de los procesos realizados por estos. Informacin: Suministra el sistema a los usuarios finales de la institucin la informacin en forma til y de forma precisa, pertinente y a tiempo? El sistema a desarrollar en el CRINA mecanizara los diferentes procesos que se llevan a cabo en la institucin, lo que permitir obtener y utilizar: Informacin til, que en la mayora del tiempo es primordial para continuar con las labores diarias que se realizan as como la toma de decisiones. Informacin precisa debido a que se reducir el porcentaje de error en su registro, al cambiar el sistema actual por el sistema mecanizado y la informacin necesaria para la toma de decisiones. La informacin que se genera es la que los usuarios esperan obtener, es decir estar de acuerdo a sus intereses.
Economa: El sistema ofrece el nivel de servicio adecuado y suficiente para reducir los costos de la institucin e incrementar los beneficio? La creacin e implementacin del sistema significara un ahorro $1, 254,260.40 en el desarrollo de los procesos de la institucin. Control: Ofrece el sistema controles adecuados que garanticen la seguridad y la precisin de los datos de la informacin? El sistema a desarrollar contara con diferentes perfiles de usuarios segn el manejo de informacin que estos requieran, proporcionando confiabilidad, portabilidad e integridad de la informacin, as mismo se especificaran los controles de seguridad a nivel fsico de los equipos. Eficacia: Hace el sistema un uso mximo de los recursos disponibles, incluidas las personas, el tiempo, el flujo de papeles y similares? El sistema informtico para la administracin y control de expedientes del CRINA, har uso adecuado de los recursos con los que cuenta entre estos: el recurso humano, el tiempo y el flujo de la informacin. Ya que el recurso humano con el que cuenta dicha institucin es un personal con conocimientos bsico en equipo tecnolgico se podr asumir un uso eficiente del sistema, lo que conllevara al ahorro del tiempo en el desarrollo de sus actividades dando como resultado final la generacin oportuna de la informacin requerida por los diferentes usuarios. Servicios: Ofrece el sistema los servos solicitados de forma fiable aquellos que lo necesitan? Es el sistema flexible y ampliable? El sistema ha desarrollar ser diseado de tal manera que los diferentes componentes del negocio de la institucin funcionen armnicamente y sin fuga de datos proveyendo a los usuarios la confianza en el manejo de la informacin generada, la cual ser estrictamente validada y con un formato segn los requerimientos establecidos por los usuarios. El sistema podr ser operado en lnea y con seguridad por los usuarios autorizados. Con respecto a su flexibilidad se puede decir que el sistema ser diseado en base a las necesidades identificadas por parte de los usuarios por lo cual se considera flexible por que se adaptara a la necesidades especficas de cada uno de los componentes, as mismo se proporcionara de manera detallada la informacin necesaria para su posterior mantenimiento y ampliacin del mismo de manera que el responsable de dicha actividad tenga la adecuada informacin para la mejora de cada uno de los componentes que conforman al sistema.
33
5.2.2. VOLMENES DE DATOS DEL CRINA

Porcentaje de 18 crecimiento 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% 15% Total en KB/Ao 55.2 16.8 42.00 111.6 34.8 7.2 7.2 81.6 73.2 78.00 56.4 25.2 92.4 63.6 54.00 32.4 25.2 55.2 30.00 51.6 Total de Kb para 5 aos. 372.18 113.27 283.12 752.45 234.63 48.54 48.54 550.18 493.54 525.91 380.27 160.91 622.99 428.81 364.09 218.45 169.91 372.18 202.27 347.91 67
. Tabla 5.18 Tabla de los formularios utilizados en el CRINA
Formulario F1 Hoja de Inscripcin F2 Hoja de autorizacin de ingreso F3 Hoja de historia clnica de la niez y adolescencia F4 Hoja de historia clnica general F5 Hoja de continuacin medica F6 Hoja de Indicaciones medicas F7 Hoja de reporte de enfermera F8 Hoja de evaluacin equipo interdisciplinario F9 Hoja de evaluacin inicial de terapia fsica y ocupacional F10 Hoja de evaluacin inicial rea de comunicacin humana F11 Hoja de evaluacin inicial de terapia educativa F12 Hoja de continuacin de terapias F13 Hoja de psicologa F14 Hoja de reevaluaciones psicolgicas F15 Hoja de estudio socio familiar F16 Hoja de visita familiar F17 Hoja de Trabajo Social F18 Hoja de Resumen Clnico F19 Hoja de egreso F20 Hoja de exmenes de laboratorio clnico, imagenologa y estudios electrofisiolgicos TOTAL DE MB
18
Calculado a partir de la memoria de labores del CRINA 2008-2009
34
El objeto de definir los volmenes de datos es establecer la dimensin y la cantidad de informacin que se almacena en el sistema a desarrollar para poder as determinar el espacio aproximado en disco duro que necesitara la base de datos para operar en los siguientes 5 aos de vida til del sistema. Para realizar la determinacin de espacios de disco duro, se estim el volumen generado por cada uno de los registros correspondientes a los formularios utilizados por el CRINA19, para lo cual se utilizaron los documentos fuentes proporcionados por la institucin. En el cuadro siguiente se muestra el resumen de la cantidad en espacio de disco duro que se estima necesitara el sistema en su periodo de produccin. El volumen de datos que el sistema tendr que almacenar en sus 5 aos de operacin ser de aproximadamente 67 MB. Conclusin de la Factibilidad Operativa. El Sistema a desarrollar adems de contar con la total aceptacin de los usuarios, contara con personal que ya ha manipulado una computadora, lo que contribuye al xito de la solucin propuesta. La necesidad existe, es real pues los usuarios han expresado el deseo de contar con sistema informtico que permita la obtencin de reportes que faciliten la toma de decisiones y brinde ayuda en la gestin de los procesos que se requieren para llevar un control sobre las actividades que se llevan a cabo en dicha institucin. Tambin se logr determinar el volumen de datos que el sistema tendr a lo largo de su vida til, el cual representan una cantidad mnima en comparacin al espacio disponible en disco duro que se utilizar para la implementacin del proyecto. Por lo tanto el proyecto es FACTIBLE OPERATIVAMENTE.
19
ANEXO: VOLUMENES DE DATOS GENERADOS EN EL CRINA.
35
6. ANLISIS DE LA SITUACIN ACTUAL. 6.1. Caso de Uso de la Situacin Actual.

La figura a continuacin muestra el caso de uso de la situacin actual, la cual describe las diferentes entidades que intervienen en el proceso de solicitud de servicios del CRINA y las interrelaciones que existen entre ellas.
Figura 6.1. Caso de uso de la situacin actual en la administracin del expediente del paciente del CRINA.
Descripcin de cada una de las entidades involucradas que se muestran en la figura 6.1: ISRI-Consulta Externa: Es la entidad encargada de la creacin del expediente del paciente, que es referido para la rehabilitacin. CRINA: Entidad que realiza pre evaluacin tcnica y da ingreso a la institucin, dando seguimiento al proceso de rehabilitacin del paciente en las diferentes reas que ha sido referido del ISRI. Paciente: Es la persona que solicita el servicio de rehabilitacin para ser atendido en el CRINA.
A continuacin se muestra el caso de uso de la situacin actual de forma extendida, donde podemos observar quienes son los usuarios involucrados en la las diferentes operaciones de la administracin y control del expediente del paciente del CRINA.
36
Figura 6.2. Usuarios involucrados en la administracin y control del expediente del paciente del CRINA.
37
Descripcin de cada uno de los usuarios involucrados que se muestran en la figura 6.2: Directora: Encargada de la administracin del centro, encargada de realizar diferentes resmenes de los pacientes del CRINA. Terapista: Responsable del seguimiento de la terapia de rehabilitacin del paciente, la cual elabora informes trimestrales, reportes de asistencia. Paciente: Persona responsable del paciente que es atendido para las rehabilitaciones. Psicloga: Responsable de impartir la charla de bienvenida a los nuevos usuarios del CRINA, y tambin de explicar el reglamento y normativa de la institucin. Recepcionista: Encargada de Entregar los tickets para el control de asistencia del paciente, de la bsqueda de horarios a terapias para los nuevos usuarios.
7. REQUERIMIENTOS DEL SISTEMA 7.1. Requerimientos Funcionales

1. El usuario del sistema podr crear expedientes clnicos (persona autorizada por el ISRI) a. El sistema generara automticamente: i. Nmero de Expediente. ii. Fecha de Apertura. b. El sistema proporcionara los siguientes formularios para la creacin del expediente clnico: F-1 Hoja de Inscripcin c. El sistema deber mostrar al usuario mediante un mensaje los campos que no se encuentren completos y sean de carcter obligatorio. d. El sistema guardara los datos del expediente clnico y proporcionara HOJA DE AUTORIZACIN DE INGRESO, con los siguientes datos: i. Nmero de Expediente ii. Primer Apellido iii. Segundo Apellido iv. Primer Nombre v. Segundo Nombre vi. Nombre del Padre o Responsable vii. Nombre de la Madre o Responsable viii. Fecha y Lugar de Expedicin. e. El sistema mostrara en pantalla los documentos realizados f. El sistema permitir imprimir los documentos. g. El sistema permitir la generacin del Carne de Identificacin del paciente 2. El usuario podr actualizar el control de citas a. b. c. d. El sistema proveer formulario para la bsqueda de expedientes clnicos. El sistema proporcionara la cita para cada paciente en la fecha y hora solicitada. El sistema permitir capturar la asistencia o inasistencia a cada cita. Si la cita es una inasistencia el sistema requerir el motivo de esta como campo obligatorio. e. El sistema guardara los datos y los relacionara con el historial de asistencia del paciente.
38
3. El usuario podr consultar expedientes clnicos a. El sistema permitir la consulta de los expedientes clnicos, proporcionando un formulario para la bsqueda de este mediante: i. Nombre del paciente ii. Nmero de expediente b. El sistema mostrara en pantalla los documentos que componen dicho expediente c. El sistema permitir imprimir los documentos, de acuerdo a los privilegios que tenga cada usuario. d. El sistema no permitir modificar ningn dato del expediente consultado. e. El sistema guardara en el historial del expediente: i. Nombre de usuario que consulto ii. Fecha y Hora de consulta. 4. El sistema permitir la actualizacin de expedientes: a. El sistema deber validar que el usuario cuente con los suficientes privilegios para la actualizacin de un expediente b. El sistema permitir la bsqueda de los expedientes clnicos, proporcionando un formulario para la bsqueda de este mediante: i. Nombre del paciente ii. Nmero de expediente c. El sistema mostrara en pantalla los documentos que componen dicho expediente d. El sistema permitir modificar los campos que sean necesarios. e. El sistema guardara los cambios realizados al expediente f. El sistema guardara en el historial del expediente: i. Nombre de usuario que modifico ii. Fecha y Hora de la modificacin 5. El sistema permitir asignar horarios de terapias: a. El sistema permitir la bsqueda del paciente mediante: i. Nombre del paciente ii. Nmero de Expediente b. El sistema desplegara en pantalla las terapias a las cuales el paciente debe asistir. c. El sistema permitir seleccionar cualquiera de las terapias y desplegar, los das de las semanas y horarios DISPONIBLES. d. El sistema permitir asignar al usuario a un horario determinado siempre y cuando este se encuentre disponible. e. El sistema guardara un historial de horarios asignados en el expediente del usuario. 6. El sistema permitir la creacin de resmenes tcnicos: a. El sistema permitir la bsqueda del paciente mediante: i. Nombre del paciente ii. Nmero de Expediente b. El sistema desplegara en pantalla los documentos que componen dicho expediente. c. El sistema permitir la opcin de crear resmenes de evolucin, los cuales contendrn: i. Diagnstico de la incapacidad ii. Tratamiento recibido iii. Recomendaciones segn ltima nota de evaluacin iv. Motivo de alta (Si existiera) 39
d. El sistema guardar los datos e. El sistema permitir imprimir un resumen tcnico el cual contendr i. F-1 Hoja de Inscripcin ii. Los ltimos resmenes de evolucin que se hayan creado para dicho expediente. f. El sistema guardara en el historial del expediente: i. Nombre de usuario que imprimi. ii. Hora y fecha de impresin. iii. Nmero de impresiones realizadas. 7. El usuario podr generar los siguientes reportes: a. Reporte de evolucin de pacientes. i. El sistema permitir la bsqueda de paciente mediante: 1. Nombre del paciente 2. Nmero de Expediente b. Reporte de llegadas tardas de pacientes i. El sistema permitir la bsqueda de pacientes mediante: 1. Nombre del paciente 2. Nmero de Expediente ii. El sistema permitir la generacin mediante la seleccin de determinado rango de fechas. c. Reporte de Expedientes clnicos de usuarios i. El sistema permitir la bsqueda de pacientes mediante: 1. Nombre del paciente 2. Nmero de Expediente d. Resmenes tcnicos i. El sistema permitir la bsqueda de pacientes mediante: 1. Nombre del paciente 2. Nmero de Expediente e. Reporte de control de citas. i. El sistema permitir la bsqueda de pacientes mediante: 1. Nombre del paciente 2. Nmero de Expediente ii. El sistema permitir la generacin del reporte de control de citas mediante la seleccin de determinado rango de fechas. f. El sistema permitir imprimir los reportes de acuerdo a los privilegios del usuario. g. El sistema permitir exportar los reportes a extensiones pdf. 8. El sistema permitir la creacin para cada expediente de los siguientes formularios: a. b. c. d. e. f. g. h. i. j. F-3 Hoja de Historia Clnica de la Niez y la Adolescencia F-4 Hoja de Historia Clnica General F-5 Hoja de Continuacin Medica F-6 Hoja de Indicaciones Medicas F-7 Hoja de Reporte de Enfermera F-8 Hoja de Evaluacin de Equipo Interdisciplinario F-9 Hoja de Evaluacin Inicial de Terapia Fsica y Ocupacional F-10 Hoja de Evaluacin Inicial rea de Comunicacin Humana F-11 Hoja de Evaluacin Inicial de Terapia Educativa F-12 Hoja de Continuacin de Terapias 40
k. l. m. n. o. p. q. r.
F-13 Hoja de Psicologa F-14 Hoja de Reevaluaciones Psicolgicas F-15 Hoja de Estudio Socio Familiar F-16 Hoja de Visita Domiciliaria F-17 Hoja de Trabajo Social F-18 Hoja de Resumen Clnico F-19 Hoja de Egreso F-20 Hoja de Exmenes de Laboratorio Electrofisiolgicos.
Clnico,
Imagenologa
Estudios
9. El nmero de expediente es un nmero nico y correlativo, que deber incrementarse en uno cada vez que se cree un nuevo expediente clnico; este se reiniciara ao con ao de acuerdo al formato : ####-ao
7.2. Requerimientos no funcionales

1. 2. 3. 4. El sistema deber ser de fcil navegabilidad. El sistema deber ser desarrollado en ambiente WEB El sistema deber tener una interfaz amigable El sistema deber de ser parametrizable para la institucin que lo utilice, permitiendo configurar: 4.1.Nombre de la institucin 4.2.Tipo de Terapias que realizan. 4.3.Departamentos que lo comprenden. 4.4.Logo de la institucin. El sistema deber de permitir configurar los ttulos de los reportes. El sistema deber ser multiplataforma (funcionar en ambiente Windows o Linux). El sistema deber basar su seguridad en perfiles de usuarios El sistema deber de bloquear a un usuario si este se equivoca al momento de ingresar su clave ms de tres veces. El sistema deber mostrar el nombre de usuario en la parte superior derecha de la pantalla.
5. 6. 7. 8. 9.
41
7.3. Requerimientos Operativos

Para la implementacin del Sistema la institucin deber contar al menos con equipos de las siguientes caractersticas:
Caracterstica Procesador Memoria RAM Sistema Operativo Navegador Web Tarjeta de Red Disco Duro Detalle Pentium 4 2.4 GHz 512 MB Windows XP o superior Internet Explorer, Mozilla Firefox, Google Chrome Si 40 GB
Tabla 7.1. Caractersticas de los requerimientos operativos
7.4. Requerimientos de desarrollo

En la siguiente tabla se describen los recursos de hardware con que se cuenta para el desarrollo del sistema:
Detalles PC Pc1 Pc2 Pc3 Pc4 Marca HP GATEWAY DELL HP Modelo 530 MT3422 Inspiron 1564 HP Pavilion dv4-2145dx Procesador INTEL CENTRINO DUO AMD Athlon 64 x 2 Inte Pentium Dual Core 2.2 Ghz AMD Turion(tm) 64 X2 Mobile Technology Memoria 3GB 1GB 4 GB 4 GB DD 250 GB 120 GB 320 GB 320 GB Monitor 15.1 14.1 17.3 14.1
Tabla 7.2 Requerimientos de Hardware para el desarrollo del sistema
En la siguiente tabla se listan los recursos de software con que se cuenta para la realizacin del sistema:
Tipo de software Sistemas Operativos Descripcin Microsoft Windows XP Professional Service Pack 3 Microsoft Windows 7 GNU-Linux Debian Lenny Lenguajes de Desarrollo Manejadores de Base de Datos Software para Oficina PHP 5 MySQL Microsoft Office Professional Edition 2007 MS Project 2007
Tabla 7.3 Requerimientos de Software para el desarrollo del sistema.
Licencias 1 2 1
4 4
42
7.5. Requerimientos Legales y Ambientales

Las operaciones que se realicen dentro del Sistema para la Administracin y Control de Expedientes del CRINA se deber regir por lo siguiente: Instructivo Normativo del Expediente Clnico La Ley del Instituto Salvadoreo de Rehabilitacin de Invlidos
8. ESTNDARES DE DISEO DEL SISTEMA

Esta seccin tiene como propsito, definir las normas de comunicacin entre los usuarios y el grupo de desarrollo, estableciendo los estndares a seguir en las etapas de determinacin y anlisis de requerimientos, diseo de pantallas y desarrollo de la solucin.
8.1. Estndares para el Anlisis de Requerimientos.

El anlisis de requerimientos se desarrollara utilizando UML (Unified Modeling Language o Lenguaje Unificado de Modelado). Los estndares que se aplicaran para representar y modelar los conceptos del dominio sern los que se describen a continuacin.
8.1.1. Modelo Conceptual

El modelo conceptual o modelo de dominio, es una expresin de las clases conceptuales u objetos del mundo real del dominio de inters. Explica los conceptos significativos en un dominio del problema. Se presentan, utilizando la notacin UML, con un conjunto de diagramas de clases, en los que no se define ninguna operacin.
SIMBOLOGA PARA EL MODELO CONCEPTUAL

Figura
Nombre Concepto
Descripcin Representa la abstraccin de un concepto del mundo real.
Indica una comunicacin entre conceptos. Dicha comunicacin establece la relacin que existente entre los conceptos.
Tabla 8.1. Simbologa para ilustrar el modelo conceptual
43
MULTIPLICIDAD EN LAS RELACIONES

Representacin 1 0..* 1..* 0..1 <literal>..* <literal>..<literal> <literal>..<literal>,<literal> Una sola instancia. Cero o ms instancias. Una o ms instancias. Cero o una instancia. Exactamente un nmero o ms de instancias. Especifica un rango de instancias. El nmero de instancias ser en el rango establecido o en un nmero exacto de instancias.
Tabla 8.2: Especificacin de multiplicidad en las relaciones
Descripcin
8.1.2. Definicin de Clases

Una clase es una categora o grupo de cosas que tienen atributos y acciones similares.
ESTNDAR PARA DOCUMENTAR LAS CLASES
Tabla 8.3: Estndar para documentar clases
Dnde: 1. 2. 3. 4. 5. Representa el nombre la clases Se hace una breve descripcin de la clase Indica el nombre que utilizara los atributos que conforman la clase Indica el tipo de dato del atributo, en este caso es un tipo descriptivo Se hace una descripcin de lo que el atributo representa.
44
8.1.3. Casos de Uso

Un caso de uso proporciona uno o ms escenarios que indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico. Normalmente en los casos de usos se evita el empleo de palabras tcnicas prefiriendo en su lugar lenguaje ms cercano al usuario final.
ESTNDARES PARA DOCUMENTAR LOS CASOS DE USO
Tabla 8.4. Estndar para documentar los casos de uso.
Dnde: 1. Indica el nombre de caso de uso 2. Indica el nmero de caso correlativo. 3. Representa al actor principal (agente externo) que participa con mayor frecuencia en el caso de uso. 4. Representa a todos los usuarios involucrados tanto en el flujo bsico como en el flujo alterno del caso de uso. 5. Se describen todas las condiciones que se necesitan para realizar el caso de uso. 6. Hacer referencia a las condiciones que se generan una vez realizado el caso de uso. 7. Especifica los casos de uso relacionados 8. Describe el escenario principal de xito del sistema 9. Describe los flujos que pueden existir al no cumplir en algn punto, el escenario principal de xito. SIMBOLOGA PARA LOS DIAGRAMAS DE CASO DE USO
Figura Descripcin
Actor: Se le llama actor a toda entidad externa al sistema que guarda una relacin con este y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero tambin incluye a todos los sistemas externos. Actor
45
Caso de Uso
Caso de Uso: Muestra la interaccin entre el sistema de informacin y el entorno en el cual opera (Actores). Es decir, representa uno o ms aspectos del sistema que se quiere desarrollar. Comunicacin: Representa la relacin entre un Actor y un caso de uso. Puede agregar una flecha a la relacin para indicar la direccin del flujo de la informacin.
<<use>>
Usa: Relacin de dependencia entre dos casos de uso que denota la inclusin del comportamiento de un escenario en otro.
<<Extend>>
Extiende: Relacin de dependencia entre dos casos de uso que denota que un caso de uso es una especializacin de otro.
Tabla 8.5. Simbologa para los diagrama de casos de uso
8.1.4. Diagrama de Secuencia (DDS)

Los diagramas de secuencia de un sistema, muestran grficamente los eventos que fluyen de los actores al sistema. Muestran los eventos de entrada y salida relacionados con el sistema, constituyendo un elemento importante para modelar el comportamiento del mismo.
SIMBOLOGA PARA LOS DIAGRAMAS DE SECUENCIA.

Figura Descripcin
Nombre Objeto
Objeto: Representa la instancia en particular de una clase. Un objeto tiene un nombre, que est subrayado para indicar un elemento de instancia, y atributos.
Activacin: Representa la lnea de vida de un objeto a travs del tiempo, generada por la accin de un usuario o el sistema.
Mensaje: Indica una accin u operacin generada por un usuario sobre el sistema. Esta debe estar a la izquierda de los dos puntos sobre la flecha. Mensaje Devolver: Indica una accin o respuesta generada por el sistema. Esta debe estar a la derecha de los dos puntos sobre la flecha.
Tabla 8.6. Simbologa para los diagramas de secuencia.
46
8.2. Estndares de Diseo. 8.2.1. Diagrama de Clases.

El diagrama de clases modela la vista esttica del sistema, ya que no describe el comportamiento del sistema en funcin del tiempo. Recoge los conceptos del dominio de la aplicacin y los conceptos que forman parte de la implementacin de la aplicacin. Adems presentan las clases del sistema con sus relaciones estructurales y de herencia. El modelo de casos de uso aporta informacin para establecer las clases, objetos, atributos y operaciones.
METODOLOGA. CLASE: Es la implementacin de un tipo de datos abstractos. Define atributos y mtodos que implementan la estructura de datos y operaciones. Los objetos son instancias de las clases. Las clases definen propiedades y comportamientos de los conjuntos de objetos. ATRIBUTOS: Son los elementos comprendidos por una clase y que almacenan los valores necesarios para la utilizacin de la instancia de una clase (objeto). MTODOS: Son aquellos elementos de la clase encargados de modificar sus atributos. Son rutinas enfocadas al manejo de los atributos para la realizacin de operacin con estos. RELACIONES: Los enlaces entre objetos pueden representarse entre las respectivas clases y sus formas de relacin son : Asociacin Agregacin Generalizacin/Especializacin. Las relaciones de Agregacin y Generalizacin forman jerarquas de clases. Asociacin: La asociacin expresa una conexin bidireccional entre objetos. Una asociacin es una abstraccin de la relacin existente en los enlaces entre los objetos. Puede determinarse por la especificacin de multiplicidad (mnima...mxima). Uno y slo uno 0..1 Cero o uno m..n Desde M hasta N (enteros naturales) 0..* Cero o muchos 1..* Uno o muchos (al menos uno) Agregacin: Es una relacin dinmica en el que el tiempo de vida del objeto incluido es dependiente del objeto que lo incluye. Generalizacin/Especializacin: Permite gestionar la complejidad mediante un ordenamiento taxonmico de clases, se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin. La Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general. La especializacin es una tcnica muy eficaz para la extensin y reutilizacin.
47
PASOS A SEGUIR PARA LA ELABORACIN DEL DIAGRAMA DE CLASES. 1. Elaborar una lista de las clases que debera incluir el sistema que se est diseando. Estos conceptos son extrados del mundo real y es necesario listar siempre los ms importantes. 2. Definir los atributos y mtodos pertenecientes a cada clase, tomando en cuenta el funcionamiento y finalidad de dichas clases. 3. Identificar las relaciones existentes entre las diferentes clases, tomando en cuenta si se trata de una asociacin, una agregacin o una generalizacin/especializacin. 4. Una vez definidos todos los elementos mencionados con anterioridad, es necesaria la representacin grfica de stos, siguiendo las notaciones de UML.
SIMBOLOGA PARA EL DIAGRAMA DE CLASES.

Figura Descripcin Clase: Se refiere al tipo de datos abstracto formado por atributos y mtodos, base de la programacin orientada a objetos.
:tipo :tipo :tipo :----:tipo
Nombre Clase
+Nombre Atributo1 +Nombre Atributo2 +Nombre Atributo3 --------------------------+Nombre AtributoN +Operacin1( ) +Operacin2( )
Cada clase se representa en un rectngulo con tres compartimientos: Nombre de la clase Atributos de la clase Operaciones de la clase
Asociacin:
1..*
Agregacin:
Clase Padre
+Nombre Atributo1 +Nombre Atributo2 +Nombre Atributo3 --------------------------+Nombre AtributoN +Operacin1( ) +Operacin2( ) :tipo :tipo :tipo :----:tipo
Relacin: Se refiere a los enlaces existentes entre las clases y que se dividen en: Asociacin Agregacin Generalizacin/Especializacin
Clase Hijo
Se representan con una lnea recta que une a las dos clases relacionadas, con nmeros en los extremos que indican la cardinalidad de cada clase. Cuando la cardinalidad es de muchos, se representa con un asterisco (*), cuando se refiere a un intervalo, se representa con los extremos del intervalo, separados por puntos suspensivos por ej. si fuera un intervalo de uno a muchos se representara as: 1..*
Generalizacin:
Clase General
Clase Especfica
Tabla 8.7. Simbologa para el diagrama de clases
48
8.3. Estndares de Base de Datos.

Para la asignacin de los nombres a los elementos que sern utilizados en la base de datos, se tomaran en cuenta los siguientes prefijos:
Elemento Tabla Vista Funcin Procedimiento Trigger Paquete
Prefijo tb_ vw_ fn_ pr_ tr_ pq_
Tabla 8.8. Prefijos a utilizar para cada elemento de la base de datos
NORMAS PARA ESTABLECER EL NOMBRE DE LOS ELEMENTOS DE LAS BASES DE DATOS. Para definir los nombres de los elementos se tomarn en cuenta las siguientes normas: 1. La cantidad de letras para el nombre ser como mximo de 40 caracteres (incluyendo el prefijo). 2. Si solo una palabra describe el nombre del elemento, se asignar el nombre con la letra inicial mayscula y el resto minsculas. 3. Si varias palabras describen el nombre del elemento, se definir el nombre con la primera letra de cada palabra en mayscula. 4. No deben existir espacios en blanco entre palabras, en su defecto se sustituir con guin bajo (_).
Ejemplos de establecimiento de nombres a elementos de la base de datos:

Descripcin del elemento Tabla de usuarios Vista de extensiones activas Obtener nmero de extensiones de Facultad Validacin de usuario Actualizar Bitcora Prefijo tb_ vw_ fn_ pr_ tr_ Nombre del elemento Usuarios Extenciones_Activas Numero_Extenciones_Facultad Validar_Usuario Actualizar_Bitacora Nombre establecido segn las normas tb_Usuarios vw_ Extenciones_Activas fn_Numero_Extenciones_Facultad pr_Validar_Usuario tr_ Actualizar_Bitacora _ain
Tabla 8.9. Ejemplos de nombres de elementos de base de datos.
49
NORMAS PARA ESTABLECER EL NOMBRE DE LOS CAMPOS DE TABLAS. Los nombres de los atributos de las tablas sern definidos de acuerdo a las siguientes normas: 1. La cantidad de letras para el nombre del campo ser como mximo de 30 caracteres. 2. Si solo una palabra describe el nombre del campo, se asignar el nombre con la letra inicial mayscula y el resto minsculas. 3. Si varias palabras describen el nombre del campo, se definir el nombre con la primera letra de cada palabra en mayscula.
NORMAS PARA ESTABLECER NOMBRES DE DISPARADORES (TRIGGERS) Para la asignacin de nombres a los triggers, se utilizarn las siguientes normas: I. Tendr el mismo nombre de la tabla para la cual se defini el disparador. II. Se agregar el sufijo segn su funcionalidad de acuerdo a la siguiente tabla:
Operacin Antes de Insertar Despus de Insertar Antes de Actualizar Despus de Actualizar Antes de Eliminar Despus de Eliminar
Sufijo _bin _ain _bup _aup _bde _ade
Tabla 8.10. Sufijo para triggers segn funcionalidad
8.3.1. Modelo Lgico De La Base De Datos

SIMBOLOGA PARA EL MODELO LGICO DE LA BASE DE DATOS
Figura
Entidad 1 # * * o o Llave_Primaria Atributo1 Atributo2 Atributo3 Atributo4 Tipo1 Tipo2 Tipo3 Tipo4 Tipo5
Descripcin
Representa una entidad, que contiene los atributos de la misma.
Relacion 1
Relaciona dos entidades con una multiplicidad de cero o uno a cero o muchos. Relaciona dos entidades con una multiplicidad de uno a cero o muchos. Relaciona dos entidades con una multiplicidad de uno a uno o
Relacion 2
Relacion 3
50
Figura muchos.
Relacion 4
Descripcin
Relaciona dos entidades con una multiplicidad de cero o uno a uno o muchos. Relaciona dos entidades con una multiplicidad de uno a uno. Relaciona dos entidades con una multiplicidad de cero o uno a cero o uno
Tabla 8.11. Simbologa para el modelo lgico de bases de datos
Relacion 5
Relacion 6
8.3.2. Modelo Fsico De La Base De Datos

SIMBOLOGA PARA EL MODELO FSICO DE LA BASE DE DATOS.
Figura
Tabla1 LlavePrimaria Atributo1 Atributo2 Atributo3 Atributo4 Tipo1 <pk> Tipo2 Tipo3 Tipo4 Tipo5
Descripcin
Representa una tabla que contiene, campos, llaves primarias, llaves forneas.
Representa las relaciones, entre tablas y su dependencia.

Tabla 8.12. Simbologa para el diseo fsico de la base de datos
8.4. Estndares de Programacin

Los estndares de programacin es una forma de normalizar la programacin de forma que cualquiera de las personas involucradas en un proyecto comprenda el cdigo. En otras palabras define la escritura y organizacin del cdigo fuente de un programa.
Nombres de los archivos Para nombrar los archivos se har de la siguiente manera. El nombre deber tener relacin a la funcin que en l se ejecuta. En la siguiente tabla se define los nombres de los archivos.
Nombre archivo Obtener_datos Imprimir_formulario Uso Archivo que se usara para obtener los datos de la bas de datos. Archivo para efectuar la impresin de un formulario previa visualizacin en pantalla.
Tabla 8.13. Ejemplo de nombre de los archivos
51
En esta seccin se definirn las extensiones ms comunes que se usaran para el desarrollo de la aplicacin. Como se muestra en la tabla siguiente.
Tipo de archivo Fuente PHP Fuente CSS
Extensin .php .css
Descripcin Contiene el cdigo de marcado y de programacin que se presentar al usuario Contiene el estilo de lo que se presentar al usuario, como el tipo de letra, fuente, color, espaciado entre palabras y prrafos.
Tabla 8.14 Extensiones de los archivos.
Organizacin de los archivos. Los archivos estarn organizados en secciones las cuales estarn separadas por lneas en blanco y comentarios los cuales sern de carcter obligatorio para el buen entendimiento de su funcionalidad e identificacin de cada seccin. En la medida de lo posible se deben evitar archivos demasiado extensos, se permitir hasta un mximo de mil lneas de cdigo incluido comentarios. Adems los archivos estarn almacenados de la siguiente forma: Todos los archivos .php se almacenaran dentro de una carpeta llamada script. Todos los archivos .css se almacenaran dentro de una carpeta llamada css. Todas las imgenes se almacenaran dentro de una carpeta llamada img. Estructura de un archivo fuente de PHP La estructura de un archivo fuente de PHP se la siguiente: Delimitacin de inicio y fin de cdigo php. Comentario Inicial Seccin Include o require. Declaracin de clases o funciones.
Delimitacin de inicio y fin de cdigo PHP Para interpretar un archivo, el intrprete de PHP se vale de caracteres especiales que le permiten identificar donde inicia y finaliza el cdigo PHP. Existen varias formas pero para propsito de estandarizacin se har uso de una sola, siendo la que se presenta a continuacin.
Ejemplo de delimitacin de Inicio y de fin de cdigo PHP <?php (Indica el inicio de cdigo que ser interpretado por el interprete de PHP). Cdigo php <? (Indica la finalizacin del cdigo escrito en PHP).
Tabla 8.15 Ejemplo de Delimitacin.
52
Comentario Inicial Todo archivo fuente deber iniciar con un comentario en el cual se describe el propsito del archivo, versin, fecha de elaboracin y el Copyright. Como se muestra en la siguiente tabla.
Ejemplo de Comentario Inicial /* * Breve descripcin del propsito del archivo * Informacin de la versin * Fecha * Copyright */
Tabla 8.16. Ejemplo de cometario inicial
Seccin include ( ) o require ( )20 Son elementos que usa PHP para llamar funciones que se encuentran definidas en otros archivos fuentes. Como se muestra en la siguiente tabla.
Ejemplo de include( ) <?php $color = 'green'; $fruit = 'apple'; ?> test.php <?php echo "A $color $fruit"; // A include 'vars.php'; echo "A $color $fruit"; // A green apple ?> Ejemplo de require( ) <?php require 'prepend.php'; require $somefile; require ('somefile.txt'); ?>
Tabla 3.17. Ejemplo de Seccin include( ) y de Seccin require( )
La principal diferencia entre ambas funciones esta en el momento de ocurrir un error include ( ) despliega un warning (advertencia), pero permite que se siga ejecutando el script, mientras que require ( ) da un fatal error (error fatal), deteniendo la ejecucin por completo del script. Declaracin de Clases y Funciones en PHP. Para definir una clase en PHP se hace uso de la palabra reservada class esto seguido del nombre de la clase, este deber ser referente a la funcionalidad de la clase y adems no se permite el uso de las palabras reservadas propias del lenguaje. Una vez definida la clase es proseguida de las llaves { }, dentro de estas se contendr la definicin de los miembros de la clase as como sus mtodos.
20
Fuente consultada: Desarrollo Web con PHP y MySql, Ing. Joel Gonzlez Estrada, seccin Estructuras de Control.
53
Las funciones en PHP se declara haciendo uso de la palabra reservada function seguida del nombre de la funcin y entre parntesis ( ) los parmetros que acepta o devolver. Como se muestra en la siguiente tabla:
No. Partes de la declaracin de una Clase o Funcin. Comentario de documentacin de la clase o funcin. (/* 2 */) Notas Ver la seccin de Comentarios de Documentacin para ms informacin sobre lo que debe aparecer en esa seccin. En esta seccin se utiliza la palabra reservada class o function para determinar si se crear una clase o una funcin. Este comentario debe contener cualquier informacin aplicable a toda la clase o interface que no era apropiada para estar en los comentarios de documentacin de la clase o interface. Primero se definirn las Public despus se definirn las Protec, seguidas de Prvate. Se puede hacer por valor (por defecto se usa este), por referencia, as como el uso de parmetros por defecto. Las excepciones se presentan durante la ejecucin de un programa cuando ocurren errores o situaciones poco habituales.
Tabla 8.18. Declaracin de Clases o Funciones en PHP
Sentencia class o function Comentario de implementacin de la clase o funcin si fuera necesario. (/**.......*/)
4 5
Miembros de clase. Variables de funciones
Excepciones
Indentancin Para la indentacin se har uso de estndares ampliamente usados por la industria del software, dentro de los cuales se emplea una indentacin de 4 espacios y tabulacin la cual es de 8 espacios. Longitud de la Lnea En la medida de lo posible evitar las lneas de ms de 80 caracteres, ya que suele ser molesto tener que desplazarse tanto para poder leer el cdigo. Un bloque del cdigo sin separacin de lneas en blanco, deber tener un tamao mximo de 30 lneas. La limitacin de la longitud de los bloques de cdigo hace ms fcil la lectura del cdigo. Cuando en una sola lnea se escriban varias sentencias, para efecto de una mejor lectura esta se partir en varias lneas, como se muestra en la siguiente tabla:
Ejemplo de Longitud de una sola lnea con varias sentencias <?php $nombre_de_variable_largo = $this->algunMetodo('prueba') + ALGUNA_CONSTANTE; if ( $mi_variable + 12 > $max || $default === null) { ...} ?>
Tabla 8.19. Ejemplo de longitud de una sola lnea con varias sentencias
54
Si se tiene varias sentencias escritas una despus de la otra, hacer uso de espacios para alinear el cdigo y que este sea ms entendible, como se muestra en la siguiente tabla:
Ejemplo de sentencias alineadas una debajo de otra <?php $this->id = 0; $this->nombrecorto = 'prueba'; $this->titulo = 'Prueba Articulo'; ?>
Tabla 8.20. Ejemplo de sentencias alineadas una debajo de otra
Tambin es recomendable dejar un espacio en blanco entre operadores para un mejor entendimiento de las sentencias. Una excepcin es el "." que sirve como concatenador, adems del ";" del final de cada lnea. Como se muestra es la siguiente tabla:
Ejemplo de espacios en blanco entre operadores <?php $mi_variable = $otra_variable + 1; echo 'esto es una prueba '.$mi_variable; ?>
Tabla 8.21. Ejemplo de espacios en blanco entre operadores
Comentarios Los programas PHP pueden tener dos tipos de comentarios: de implementacin y de documentacin. Los comentarios de documentacin son aquellos que se encuentran delimitados por /*...*/, y //. Los comentarios de implementacin se limitan por /**...*/. Los comentarios de implementacin son para comentar nuestro cdigo o para comentarios acerca de una implementacin particular. Los comentarios de documentacin son para describir la especificacin del cdigo, libre de una perspectiva de implementacin. Se deben usar los comentarios para dar descripciones de cdigo y facilitar informacin adicional que no es legible en el cdigo mismo. Los comentarios deben contener slo informacin que es relevante para la lectura y entendimiento del programa. Por ejemplo, informacin sobre cmo se construye el paquete correspondiente o en que directorio reside no debe ser incluida como comentario. En nuestro proyecto solo utilizaremos comentarios de documentacin. Comentarios de Documentacin PHP soporta los comentarios que se usan en el lenguaje C y C++, por tal motivo y dado que estos son muy conocidos por la gran mayora de programadores se har uso de los mismo para comentar lneas, instrucciones, etc. Y el inicio de los archivos .PHP. Como se muestra en la siguiente tabla.
55
Ejemplos de Comentarios de Documentacin Comentario de una sola lnea Se har uso del dos plecas //, para comentar una sola lnea Comentarios de varias lneas Para esto se utilizar la pleca / seguida de un asterisco *, para indicar el inicio del comentario y escrito de forma inversa sirven para indicar el fin del mismo */. Ejemplo: /* este es un comentario que tiene varias lneas */
Tabla 8.22. Ejemplo de comentarios de Documentacin
21
Ejemplo: // Esto es un comentario de una sola lnea
Declaraciones
Nombres de variables Los nombres deben ser descriptivos y concisos. No usar frases largas ni abreviaciones pequeas para las variables. Es mejor saber que hace una variable con slo conocer su nombre. Esto aplica para los nombres de variables, funciones, argumentos de funciones y clases. Todos los nombres deben estar en minscula (Excepto las clases, donde la primera letra ha de ser mayscula). En caso de usar ms de una palabra, sta ser separada por un guin bajo "_". En las funciones, es importante que el nombre denote su funcin inmediatamente. Por ejemplo acciones como imprimir_datos, actualizar_datos_usuario, eliminar_usuario, etc. De igual manera, en los argumentos de las funciones, es ms entendible crear_usuario($nombre, $email) que crear_usuario($n, $e). Uso de Corchetes y Llave Los corchetes y llaves permiten tener una mayor claridad y separacin cuando se hace uso de funciones o instrucciones de control, Esto hace el cdigo ms legible. Como se muestra en la siguiente tabla:
Ejemplo de uso de corchetes y llaves Forma incorrecta: if($cosa) funcin(); Forma correcta: if ($cosa) { funcin( ); } Tabla 8.23. Ejemplo de uso de corchetes y llaves
21
Fuente consultada: www.cristalab.com/tutoriales/190/reglas--de-codificacion-y-lineamientos-de-codigo-php
56
Corchetes o llaves donde colocarlas
La mejor prctica en cuanto el uso de los corchetes o llaves es que estos se coloquen en una lnea ellos solos, esto ayuda a identificar mejor los pares tanto de abertura como de cierre, evitando de esta forma posibles errores de sintaxis. Como se muestra en siguiente tabla:
Ejemplo de donde colocar los corchetes y llaves if (algo) { for (iteracin) { //cdigo }} while (condicin) { funcin( ); }
Tabla 8.24. Ejemplo de donde colocar los corchetes y llaves
Uso de espacios entre signos El colocar espacio entre los smbolos, da mayor claridad al cdigo escrito, permitiendo identificar donde inicia o finaliza una declaracin de igualdad u operacin, el ejemplo se muestra en la siguiente tabla:
Ejemplo de Uso de espacios entre signos Forma Incorrecta: $a=0; for($i=5;$i<=$j;$i++) Forma Correcta: $a = 0; for ($i = 5; $i <= $j; $i++)
Tabla 8.25. Ejemplo de uso de espacio entre signos
Precedencia de operadores El uso correcto de la precedencia es esencial para el entendimiento de cualquier cdigo escrito independiente del lenguaje que se use es por ellos que se debe ser lo ms claro posible. Como se muestra en la siguiente tabla.
Ejemplo de precedencia de operadores Forma incorrecta: $bool = ($i < 7 && $j > 8 || $k == 4); Forma correcta: $bool = ($i < 7 && ($j < 8 || $k == 4));
Tabla 8.26. Ejemplo de precedencia de operadores
57
Cadenas de texto entre comillas PHP tiene dos formas de poner strings o cadenas de texto. Con comillas simples y con comillas dobles. La diferencia es que al usar comillas dobles, es que al colocar dentro de ellas texto con un nombre de variable, el compilador lo interpretar y reemplazar por su valor. Por sta razn siempre se ha de usar comillas simples, con la salvedad que se necesite hacer la interpolacin de variables que permiten las dobles. Esta es una caracterstica de PHP con la que se ha de tener sumo cuidado. Existen casos especiales donde es mejor usar dobles comillas. Ejemplo: cuando se hace uso del carcter de escape \ de manera intensivamente, con el fin de mejorar el cdigo. Variables Si no se tiene control sobre el valor de una variable, es mejor que esta sea inicializada de la siguiente manera, tal como se muestra en la siguiente tabla:
Ejemplo de variables Forma incorrecta: if ($cliente == 5) ... Forma correcta: if (isset($cliente) && $cliente == 5) ...
Tabla 8.27. Ejemplo de variables
Se recomienda hacer esto solo cuando no se tenga el control o no se est completamente seguro del valor que esta pueda tener por ejemplo las variables obtenidas mediante el mtodo GET.
Sentencias22
Sentencia Switch Cuando se haga uso de la instruccin swicth se har de la siguiente forma:
Ejemplo de sentencia Switch switch ($modo) { case 'modo1': // Cdigo de xito break; case 'modo2': // Algoritmo que me retirar a los 25 aos break; default: // Cdigo si todo falla break; }
Tabla 8.28 Ejemplo de sentencia Switch
22
Fuente consultada: www.php.net/manual/es/control-structures.foreach.php
58
Sentencia If La declaracin de esta estructura se har tal como se muestra en la en la siguiente tabla:
Ejemplo de sentencia If <?php if (expr) sentencia ?>

Tabla 8.29. Ejemplo de sentencia If
Sentencia Else Para el uso de esta estructura se har de la siguiente forma, como se muestra en la siguiente tabla:
Ejemplo de sentencia Else <?php if ($a > $b){ print "a es mayor que b"; } else { print "a NO es mayor que b"; } ?>
Tabla 8.30. Ejemplo de sentencia Else
Sentencia If-Else Como su nombre sugiere, es una combinacin de if y else. Como else, extiende una sentencia if para ejecutar una sentencia diferente en caso de que la expresin if original. Como se muestra en la siguiente tabla:
Ejemplo de sentencia If-Else <?php if ($a > $b) { print "a es mayor que b"; } else if ($a == $b) { print "a es igual que b"; } else { print "a es mayor que b"; } ?>
Tabla 8.31. Ejemplo de sentencia Else IF
59
Sentencia While Los bucles while son los tipos de bucle ms simples en PHP. La forma bsica de una sentencia while es: While (expr) sentencia Como con la sentencia if, se pueden agrupar mltiples sentencias dentro del mismo bucle while encerrando un grupo de sentencias con llaves, o usando la sintaxis alternativa: While (expr): sentencia... endwhile; Sentencia Do..While Los bucles Do..While son muy similares a los bucles While, excepto que las condiciones se comprueban al final de cada iteracin. La principal diferencia frente a los bucles regulares While es que se garantiza la ejecucin de la primera iteracin de un bucle. Como se muestra en la siguiente tabla:
Ejemplo de sentencia DoWhile do..while <?php $i = 0; do { print $i; } while ($i>0); ?> Tabla 8.32 Ejemplo de sentencia DoWhile
Sentencia For y Foreach Los bucles for son los bucles ms complejos. La sentencia foreach permite operar con matrices, por lo cual devolver un error si se intenta hacer uso con otro tipo de datos o variables. Como se muestra en la siguiente tabla:
Ejemplo de sentencia For Ejemplo de sentencia Foreach <?php $arr = array("one", "two", "three"); reset ($arr); while (list(, $value) = each ($arr)) { echo "Value: $value \n"; } foreach ($arr as $value) { echo "Value: $value \n"; } ?>
for (expr1; expr2; expr3) sentencia
Tabla 8.33. Ejemplo de sentencia For y Foreach
Sentencia Break Break sirve para escapar de las estructuras de control iterativas (bucle) actuales for, while, o switch. Acepta un parmetro opcional, el cual determina cuantas estructuras de control hay que escapar. Esto se muestra a continuacin:
60
Ejemplo de sentencia Break <?php $arr = array ('one', 'two', 'three', 'four', 'stop', 'five'); while (list (, $val) = each ($arr)) { if ($val == 'stop') { break; /* You could also write 'break 1;' here. */ } echo "$val \n"; }/* Using the optional argument. */ $i = 0; while (++$i) { switch ($i) { case 5: echo "At 5 \n"; break 1; /* Exit only the switch. */ case 10: echo "Al 10; saliendo \n"; break 2; /* Exit the switch and the while. */ default: break; } } ?>
Tabla 8.34. Ejemplo de sentencia Break
El uso continuo de esta estandarizacin en el cdigo fuente se busca entregar un cdigo, limpio y entendible por cualquier persona ajena al proyecto que en algn momento se incorpore o fuera a realizar modificaciones al sistema.
61
8.5. Estndares para El Diseo de Pantallas 8.5.1. Estndar para interfaces de Entrada
Interfaz de Inicio de Sesin
Interfaz Principal
62
Interfaz de Gestin
Consideraciones: Se debern tomar en cuenta lo siguiente: Los campos que hagan referencia a cantidades, se expresaran en formato de nmeros enteros, salvo que la cantidad posea fracciones, para esto caso se utilizara dos decimales para su visualizacin. Los campos de tipo numrico en general, que posean fracciones, se mostraran con dos decimales, salvo los casos en que se requiera tener mayor precisin. Los campos de tipo fecha, tendrn siempre el mismo formato, tanto de ingreso como de visualizacin, siendo este formato el que sigue: DD/MM/AAAA, Donde DD es el da, MM es el mes y AAAA es el ao con sus cuatro dgitos. Los campos que sean obligatorios, se les antepondr el smbolo de asterisco (*) para indicarle al usuario que necesariamente debe ingresarlos. La longitud y el tipo de dato para cada campo ser definido en el diccionario de datos.
63
8.5.2. Estndar para interfaces de Salida.
Reportes: Para todas las interfaces de salida ya sean en papel o en pantalla se utilizar el mismo formato. Es posible adaptar algunos reportes de acuerdo a lo requerido por los usuarios varen, de modo que visualmente tengan el formato que ellos han establecido, pero sin perder, en esencia, el formato descrito anteriormente. Los reportes podrn ser exportados a formato PDF, tomando en cuenta que no podrn ser modificados si son exportados para que no exista una alteracin de la informacin.
64
8.5.3. Estndares de Errores
Consideraciones: Los mensajes de error sern desplegados como ventana emergente sobre la interfaz donde se est realizando la operacin. Cuando un campo dentro de un formulario o interfaz de gestin no se encuentre completo se desplegara mensaje de error al y se marcara dicho campo, para que el dato sea completado. Si la base de datos no se encuentra disponible, se desplegara el siguiente mensaje de error al final de la interfaz La base de datos no se encuentra disponible, favor vuelva a intentarlo en algunos minutos
8.6. Estndares de Manuales a Entregar

Los manuales debern de tener el siguiente contenido mnimo: Portada Tabla de contenido Introduccin Desarrollo del contenido de manual Glosario
65
8.7. Estndares de Seguridad

Para el desarrollo de la solucin se definirn los estndares a seguir y cumplir en cuanto a seguridad se refiere. Con respecto al desarrollo del sistema de administracin se implementarn diversas polticas de seguridad lgica entre las que se pueden mencionar: a) Mtodo de acceso restringido al sistema: el acceso al sistema debe estar restringido por el uso de claves asignadas a cada uno de los usuarios. Slo podrn ingresar al sistema las personas que estn registradas, estos usuarios sern clasificados en varios tipos de usuarios (o perfiles) con acceso a las opciones de trabajo definidas para cada perfil. b) Tamao mnimo de la clave de acceso: no menor a 8 caracteres Adems para poder controlar la mayora de problemas que puedan afectar el sistema a nivel de Hardware se implementarn diversas polticas de seguridad de Hardware entre las que se pueden mencionar: a) Medidas de seguridad en el acceso fsico: el acceso al saln donde estar ubicado el equipo ser restringido y solo podr entrar el personal autorizado. b) Medidas de seguridad por alteraciones del entorno: para evitar daos en el equipo ocasionados por el entorno (inclemencia del tiempo, desastres naturales, alteracin de energa elctrica, etc. c) Medidas de respaldo de informacin: se deber proveer de mecanismos para generar copias de seguridad peridicamente de la informacin que se mantiene en el sistema.
66
9. Diseo Global 9.1. Modelado de Casos de Uso

En este apartado se presentan los casos de usos de los procesos propuestos.
9.1.1. Caso de Uso General.
67
9.1.2. Caso de Uso Iniciar Sesin
No. 1
Actor Principal: Usuario del Sistema, Sistema Personal involucrado e intereses:
Nombre de caso de uso: Iniciar sesin
Usuario del Sistema: Es el usuario que desea ingresar al sistema para la realizacin de actividades de configuracin y consulta Precondiciones: El Usuario, debe existir en el sistema Post-condiciones: Se presenta el men personalizado Referencias Cruzadas (Casos de Uso): Todos los casos de uso. Flujo Bsico: 1. El Usuario del Sistema ingresa usuario y contrasea 2. El Sistema valida los datos introducidos sean correctos y que el usuario se encuentre activo. 3. El Sistema presenta en pantalla el men correspondiente al usuario Flujos Alternativos: 2.a. El Sistema muestra que los datos ingresados no son correctos que usuario no existe o est bloqueado. 2.b. El Sistema indica que contrasea no es correcta y bloquea el usuario al 3er mal ingreso.
68
9.1.3. Caso de Uso Administracin de Usuarios.
No. 2
Nombre de caso de uso: Administracin de usuarios
Actor Principal: Administrador del Sistema Personal involucrado e intereses: Administrador del Sistema: Realiza la actividad solicitadas con el visto bueno del jefe de unidad o director de la institucin Precondiciones: El Administrador del Sistema, debe haber iniciado sesin, autenticando su usuario y contrasea. Post-condiciones: Se registra la gestin de usuarios satisfactoriamente Referencias Cruzadas (Casos de Uso): Caso de uso Iniciar sesin Flujo Bsico: 1. El Administrador del Sistema selecciona Administracin de usuarios 2. El Sistema presenta: crear, actualizar, activar, desactivar o eliminar usuario 3. El Administrador del Sistema selecciona crear usuario o flujo Alternativo 2, o flujo Alternativo 3, o flujo alternativo 4, o flujo alternativo 5 o flujo alternativo 6. 4. El Sistema muestra la informacin a ser complementada 5. El Administrador del Sistema ingresa los datos solicitados y selecciona guardar. 6. El Sistema verifica que los datos sean correctos y los almacena. Flujos Alternativos: Flujo Alternativo 1: 6.a El Sistema muestra que los datos ingresados no son correctos, regresa al paso 4. Flujo Alternativo 2: Actualizar Usuario 1. El Administrador del Sistema selecciona actualizar usuario 2. El Sistema pide los datos del usuario a actualizar 3. El Administrador del Sistema ingresa los datos solicitados
69
4. El Sistema verifica que el usuario exista 5. El Sistema indica que el usuario no existe y regresa al paso 2 6. El Sistema presenta la informacin del usuario solicitado 7. El Administrador del Sistema realiza los cambios respectivos y selecciona guardar 8. El Sistema muestra que los datos no son correctos y regresa al paso 7 9. El Administrador del Sistema confirma actualizar o flujo alternativo 6 Flujo Alternativo 3: Eliminar Usuario 1. El Administrador del Sistema selecciona eliminar usuario 2. El Sistema pide los datos del usuario a eliminar 3. El Administrador del Sistema ingresa los datos solicitados 4. El Sistema verifica que el usuario exista y que no haya realizado ninguna transaccin. 5. El Sistema indica que el usuario no existe y regresa al paso 2 6. El sistema solicita confirmacin de eliminacin del usuario o flujo 6.. Flujo Alternativo 4: Desactivar Usuario 1. El Administrador del Sistema selecciona desactivar usuario 2. El Sistema pide los datos del usuario a desactivar. 3. El Administrador del Sistema ingresa los datos solicitados 4. El Sistema verifica que el usuario exista 5. El Sistema indica que el usuario no existe y regresa al paso 2 6. El Sistema presenta la informacin del usuario solicitado. 8. El Sistema solicita confirmacin de desactivacin del usuario. 9. El Administrador del Sistema confirma desactivacin o flujo alternativo 6 Flujo Alternativo 5: Activar Usuario 1. El Administrador del Sistema selecciona activar usuario. 2. El Sistema pide los datos del usuario a activar. 3. El Administrador del Sistema ingresa los datos solicitados. 4. El Sistema verifica que el usuario exista y que se encuentre desactivado o bloqueado. 5. El Sistema indica que el usuario no existe y regresa al paso 2 6. El sistema solicita confirmacin de activacin del usuario. 7. El administrador confirma la activacin o flujo 6. Flujo 6: Cancelar operacin 1. El Administrador del Sistema no confirma la operacin 2. El Sistema cancela la operacin
70
9.1.4. Caso de Uso Creacin de Expediente
No. 3
Nombre de caso de uso: Creacin de expediente
Actor Principal: Usuario del sistema (encargado de archivo), Paciente Personal involucrado e intereses: Paciente: Solicita al encargado de archivo la creacin del expediente Usuario del Sistema: En este caso es el encargado de archivo quien hace la creacin del expediente Pre-condiciones: El paciente debe solicitar la creacin del expediente teniendo consigo la referencia de un medico externo. Post-condiciones: Expediente creado satisfactoriamente. Referencias Cruzadas (Casos de Uso): cita mdica (pediatra) Flujo Bsico: 1. 2. 3. 4. 5. El usuario solicita al sistema la creacin del expediente. El sistema solicita que el usuario ingrese el nombre del paciente para evitar duplicidad. El usuario ingresa la referencia del mdico especialista de la consulta externa. El sistema solicita los datos de paciente. El usuario introduce: a. b. 6. 7. 8. Datos del paciente: Nombre, sexo, lugar y fecha de nacimiento. Datos del responsable: Nombre, edad, profesin, domicilio, Documento con que se identifica.
Sistema solicita guardar los cambios realizados. El usuario guarda los cambios y se crea el expediente. El sistema genera referencia con el pediatra
Flujos Alternativos: 2.a sistema muestra la informacin de expediente existente. 3.a Usuario omite la referencia del mdico de consulta externa. 6.a el usuario no almacena los cambios, regresa al paso 1
71
9.1.5. Caso de Uso Consulta Peditrica
No. 4
Nombre de caso de uso: Consulta Peditrica
Actor Principal: Usuario del sistema, Paciente Personal involucrado e intereses: Paciente: pasa su consulta inicial con pediatra Usuario del Sistema: Pediatra realiza la primera consulta Pre-condiciones : creacin del expediente Post-condiciones: Pre - Evaluacin Tcnica con especialista. Referencias Cruzadas (Casos de Uso): Creacin de expediente, Pre-Evaluacin Tcnica Flujo Bsico: 1. 2. 3. 4. 5. El sistema solicita el nmero de expediente y nombre de paciente para validar la existencia del expediente. El sistema despliega informacin de expediente. El usuario ingresa datos de la evaluacin peditrica El sistema solicita almacenar los cambios al expediente El sistema genera la referencia hacia especialista para Pre-evaluacin Tcnica
Flujos Alternativos: 1.a Error al no coincidir nombre del paciente con nmero de expediente. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda.
72
9.1.6. Caso de Uso Pre-Evaluacin Tcnica Ingreso al CRINA
No. 5
Nombre de caso de uso: Pre-evaluacin Tcnica Ingreso al CRINA
Actor Principal: Usuario del sistema, Paciente Personal involucrado e intereses: Paciente: tiene una pre-evaluacin tcnica con el especialista. Usuario del Sistema: realiza la pre-evaluacin tcnica al paciente Pre-condiciones : evaluacin de consulta peditrica, expediente creado Post-condiciones: Ingreso al CRINA, asignacin de terapias. Referencias Cruzadas (Casos de Uso): Consulta Peditrica Flujo Bsico: 1. 2. 3. 4. 5. 6. 7. El sistema solicita el nmero de expediente. usuario ingresa el nmero de expediente. sistema despliega informacin de expediente. El usuario ingresa datos de la pre-evaluacin tcnica. El sistema solicita almacenar los cambios al expediente. Usuario asigna las terapias necesarias. El sistema genera la referencia para dar ingreso del paciente a CRINA.
Flujos Alternativos: 5.1 El usuario solicita referencia con otro especialista
73
9.1.7. Caso de Uso Inscripcin de Terapias
No. 6
Nombre de caso de uso: Inscripcin de Terapias
Actor Principal: Usuario del sistema (terapista), Paciente Personal involucrado e intereses: Usuario del Sistema: En este caso terapista quien asigna nuevo horario de terapias para continuar proceso de rehabilitacin Pre-condiciones: Expediente del paciente activo, charlas de escuela de padres completa, seguimiento psicolgico del paciente completo, cumplimiento de asistencia. Post-condiciones: horario de terapia asignado satisfactoriamente. Referencias Cruzadas (Casos de Uso): Flujo Bsico 1: 1. 2. 3. 4. 5. El usuario solicita al sistema la inscripcin de horario de terapia (habilitado solamente al final del ao de terapia). El sistema solicita nmero de expediente y nombre del paciente. El usuario ingresa nmero de expediente o nombre del paciente. El sistema solicita los datos para el nuevo horario del paciente. El usuario introduce: 6. 7. 8. 9. Da o das de terapia, hora de terapia, cdigo o nombre de terapeuta.
El sistema verifica que el horario est disponible. Sistema solicita guardar los cambios realizados. El usuario guarda los cambios. El sistema genera horario de terapia
74
Flujo Bsico 2: d) El usuario (Secretaria) Solicita al sistema impresin de horario de terapia e) f) g) El sistema solicita nmero de expediente o nombre del paciente. El usuario ingresa nmero de expediente o nombre del paciente sistema muestra horario asignado al paciente
h) El usuario imprime hoja de horarios Flujo Alternativo 1a: 2.a. sistema muestra la informacin de expediente existente. 4.a. Sistema despliega mensaje Condiciones incompletas, muestra las condiciones que hacen falta. 4.b. Sistema no guarda ningn cambio Flujo Alternativo 1b: 5.a. El horario no se encuentra disponible. 5.b. El sistema despliega horarios disponibles y regresa al paso 4 Flujo alternativo 2: 4.a. sistema despliega mensaje de horarios incompletos, muestra que horarios faltan por ser asignados. 4.b. Sistema no hace ninguna impresin
9.1.8. Caso de Uso Control de Asistencias.
No. 7
Nombre de caso de uso: Control de Asistencias
Actor Principal: Usuario (Enfermera) o Psicloga Personal involucrado e intereses: Usuario: Realiza control de asistencias segn horario inscrito, Paciente: Registra su control de asistencias a terapias o a charla de escuela de padres. Precondiciones: El Usuario del Sistema, debe haber iniciado sesin, autenticando su usuario y contrasea.
75
Post-condiciones: Se registra el control de asistencias satisfactoriamente Referencias Cruzadas (Casos de Uso) Caso de Uso Asignar Altas a Pacientes Flujo Bsico 1 : 1. El usuario el Sistema selecciona Asistencia a Rehabilitacin del Paciente 2. El Sistema presenta: ingresar nmero de expediente o nombre del paciente. 3. El Sistema muestra las terapias asignadas a dicho paciente, en el da y hora consultados 4. El Usuario asigna asistencia a terapia por parte del paciente. 5. El Sistema indica que la informacin ha sido guardada satisfactoriamente. Flujo alternativo : 2. a Error al no coincidir nombre del paciente con nmero de expediente. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda. 4.a El Usuario asigna inasistencia a terapia por parte del paciente. 4.b El sistema solicita motivo por el cual no asisti el paciente a su terapia Flujo Bsico 2: Asistencia a Charla de Escuela de Padres 1. 2. 3. 4. 5. 6. 7. El usuario el Sistema selecciona Asistencia a Escuela de Padres El Sistema presenta: ingresar nmero de expediente y nombre del paciente. Sistema solicita fecha en que se imparti charla para padres. El Usuario asigna asistencia a charla por parte del responsable del paciente. Usuario digita resumen de la reunin. El sistema Actualiza expediente y almacena informacin. El Sistema indica que la informacin ha sido guardada satisfactoriamente.
Flujos Alternativo : 2. a Error al no coincidir nombre del paciente con nmero de expediente. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda. 4.a El Usuario asigna inasistencia a terapia por parte del paciente. 5.a El sistema no guarda ningn resumen.
76
9.1.9. Caso de Uso Actualizar Expediente
No. 8
Nombre de caso de uso: Actualizar Expediente
Actor Principal: Usuario del Sistema (Enfermera) y responsable del paciente. Personal involucrado e intereses: Usuario: Realiza actualizacin del Expediente El responsable del en caso de ser una actualizacin de datos personales brinda la informacin. Precondiciones: El usuario debe haber iniciado sesin , el expediente debe estar creado y activo Post-condiciones: Expediente Modificado Referencias Cruzadas (Casos de Uso): Flujo Bsico: 1. El sistema solicita nmero de expediente o nombre del paciente. 2. Usuario del Sistema actualiza los datos deseados. 3. El sistema permite guardar los cambios realizados. 4. El sistema muestra el expediente con las actualizaciones realizadas. 5. El sistema guarda un histrico de las actualizaciones realizadas, usuario que las realizo y fecha de realizacin. 6. El sistema permite la impresin del expediente. Flujos Alternativos: 1.a Error al no coincidir nombre del paciente y nmero de expediente. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda. 3.a. El usuario ya no desea realizar ninguna modificacin. 1. El sistema permite cancelar la actualizacin del expediente.
77
9.1.10. Caso de Uso Control de Rehabilitacin
No. 9
Nombre de caso de uso: Control de Rehabilitacin
Actor Principal: Terapista y responsable del paciente. Personal involucrado e intereses: Usuario: Realiza actualizacin del Expediente; Responsable del paciente: recibe informe resumen del avance en la rehabilitacin. Precondiciones: Expediente activo y Terapista Asignada Post-condiciones: Resumen del Control de Rehabilitacin. Referencias Cruzadas (Casos de Uso): Iniciar sesin, Actualizar Expediente. Flujo Bsico: 1. 2. 3. 4. 5. 6. Sistema solicita nmero de expediente o nombre del paciente. El usuario consulta metas y objetivos de rehabilitacin. El usuario (terapista) sostiene reunin informativa sobre rehabilitacin con el responsable del paciente y brinda informacin. Usuario digita resumen de la reunin sobre avances de rehabilitacin en el expediente del paciente. Sistema actualiza el expediente y guarda los cambios realizados. Sistema almacena bitcora de control de rehabilitaciones.
Flujos Alternativos: 1.a Error al no coincidir nombre del paciente y nmero de expediente. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda.
78
9.1.11. Caso de Uso Control de Seguimiento Mdico
No. 10
Nombre de caso de uso: Control de Seguimiento medico
Actor Principal: Medico y responsable del paciente. Personal involucrado e intereses: Usuario: Realiza actualizacin del Expediente; Responsable del paciente: en caso de ser una actualizacin de datos pertinentes a la evolucin del paciente, brinda la informacin. Precondiciones: Expediente activo y Cita mdica Asignada Post-condiciones: asignacin de nueva cita mdica para seguimiento. Referencias Cruzadas (Casos de Uso):Solicitud de cita medica Flujo Bsico: 1. 2. 3. 4. 5. 6. 7. Sistema solicita nmero de expediente o nombre del paciente. El usuario consulta informes de los terapeutas. Verificar historial del paciente. El usuario (medico) sostiene reunin informativa sobre rehabilitacin con el responsable del paciente y brinda informacin. Usuario digita resumen de la reunin sobre avances de rehabilitacin en el expediente del paciente. Sistema guarda los cambios realizados. Sistema almacena bitcora de control de rehabilitaciones.
79
9.1.12. Caso de Uso Control de Seguimiento Psicolgico
No. 11
Nombre de caso de uso: Control de Seguimiento Psicolgico
Actor Principal: psiclogo y responsable del paciente. Personal involucrado e intereses: Usuario: Realiza actualizacin del Expediente; Responsable del paciente: en caso de ser una actualizacin de datos pertinentes a la evolucin del paciente, brinda la informacin. Precondiciones: Expediente activo y Cita psicolgica Asignada Post-condiciones: asignacin de nueva cita psicolgica para seguimiento. Referencias Cruzadas (Casos de Uso):Solicitud de cita psicolgica Flujo Bsico: 1. 2. 3. 4. 5. 6. Sistema solicita nmero de expediente o nombre del paciente. El usuario consulta informes de los terapeutas. El usuario (psicloga) sostiene reunin informativa sobre rehabilitacin con el responsable del paciente y brinda informacin. Usuario digita resumen de la reunin sobre avances de rehabilitacin en el expediente del paciente. Sistema guarda los cambios realizados. Sistema almacena bitcora de control de rehabilitaciones.
80
9.1.13. Caso de Uso Control de Trabajo Social ISRI
No. 12
Nombre de caso de uso: Control Trabajo Social ISRI
Actor Principal: Licenciada y responsable del paciente. Personal involucrado e intereses: Usuario: Realiza actualizacin del Expediente; Responsable del paciente: en caso de ser una actualizacin de datos pertinentes a la evolucin del paciente, brinda la informacin. Precondiciones: Expediente activo y sancin por falta de asistencia. Post-condiciones: Referencias Cruzadas (Casos de Uso): Flujo Bsico: 1. 2. 3. 4. 5. 6. Sistema solicita nmero de expediente o nombre del paciente. El usuario consulta asistencias a citas mdicas. El usuario (licenciada) sostiene reunin informativa sobre reglamento y faltas cometidas con el responsable del paciente y brinda informacin. Usuario digita resumen de la reunin sobre acciones a proceder en el futuro en el expediente del paciente. Sistema guarda los cambios realizados. Sistema almacena bitcora de control de rehabilitaciones.
81
9.1.14. Caso de Uso Control Trabajo Social CRINA
No. 13
Nombre de caso de uso: Control trabajo Social CRINA
Actor Principal: Licenciada y responsable del paciente. Personal involucrado e intereses: Usuario: Realiza prstamo de silla de ruedas; Responsable del paciente: hace uso de un bien material proporcionado por el CRINA. Precondiciones: Expediente activo y Terapia Asignada Post-condiciones: Referencias Cruzadas (Casos de Uso): Flujo Bsico: 1. 2. 3. 4. 5. Sistema solicita nmero de expediente o nombre del paciente. El usuario consulta inventario de sillas de ruedas disponibles. El usuario (licenciada) asigna una silla de rueda al paciente. Sistema guarda los cambios realizados. Sistema almacena bitcora de control de prstamo de sillas.
Flujos Alternativos: 1.a Error al no coincidir nombre del paciente con nmero de expediente. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda. 2.a Registra la devolucin de la silla de ruedas
82
9.1.15. Caso de Uso Visita Domiciliar
No. 14
Nombre de caso de uso: Visita Domiciliar
Actor Principal: Usuario del sistema Personal involucrado: Usuario del Sistema: Psiclogo, quien realiza la visita domiciliar Pre-condiciones : cita para visita a la institucin educativa Post-condiciones: Actualizacin de expediente. Referencias Cruzadas (Casos de Uso): Flujo Bsico: 1. 2. 3. 4. 5. 6. 7. El sistema solicita el nmero de expediente. usuario ingresa el nmero de expediente. sistema despliega informacin de expediente. El usuario ingresa datos de la visita domiciliar. El sistema solicita almacenar los cambios al expediente. Usuario asigna las terapias necesarias. El sistema genera la referencia de apertura de expediente.
Flujos Alternativos: 5.1 El usuario no almacena los cambios. El sistema regresa al paso 1 5.2 El usuario solicita referencia con otro especialista
83
9.1.16. Caso de Uso Generacin de Reportes
No. 15
Nombre de caso de uso: Generacin de Reportes
Actor Principal: Usuario del sistema (Directivo). Personal involucrado e intereses: Usuario: Realiza reportes segn necesidades. Precondiciones: Expedientes activos Post-condiciones: Referencias Cruzadas (Casos de Uso): Flujo Bsico 1 : 1. Usuario selecciona tipo de reporte deseado. 2. Reporte de faltas de Asistencia Pacientes. Reporte de cumplimiento de terapeutas
Sistema procesa la solicitud.
Flujos Alternativo 1 : Reporte de faltas de Asistencia Pacientes. 1. 2. 3. 4. 5. 6. Usuario solicita reporte de faltas de asistencia de pacientes Sistema valida existencia de expediente solicitando nmero de expediente y nombre del paciente Sistema solicita: Fecha o rango de fechas, Rango de Edad, Padecimiento, rea de terapia. Usuario (Directivo) imprime resumen. Sistema guarda los cambios realizados. Sistema almacena bitcora de control de rehabilitaciones.
84
Flujo alternativo 2: 1. a Error al no coincidir nombre del paciente con nmero de expediente. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda. Flujo Alternativo 3 : Reporte de cumplimiento de terapeutas 1. 2. 3. 4. 5. Sistema valida existencia de terapeuta solicitando cdigo y nombre Sistema solicita: Fecha o rango de fechas, rea de terapias. Usuario (Directivo) imprime resumen de cumplimiento. Sistema guarda los cambios realizados. Sistema almacena bitcora de control de rehabilitaciones.
Flujo alternativo 4: 1. a Error al no coincidir nombre del terapeuta con el cdigo brindado. 1. El sistema advierte del error. 2. El sistema solicita realizar una nueva bsqueda.
9.1.17. Caso de uso Creacin de resumen tcnico.
85
No. 16
Nombre de caso de uso: Creacin de resumen tcnico
Actor Principal: Usuario del sistema, Paciente Personal involucrado e intereses: Paciente: solicita a trabajo social el resumen de las evaluaciones tcnicas que recibe su hijo(a) en el CRINA Usuario del Sistema: trabajo social: recibe solicitud, y orienta al paciente cuando preguntar por el resumen. Jefatura de terapias: solicita el expediente para verificar los ltimos profesionales involucrados en el proceso de rehabilitacin y solicitar a cada uno un resumen de cada rea. Medico responsable: Elabora un resumen de la terapia que ha impartido. Pre-condiciones : Asistencia a las terapias , Elaboracin de resumen por rea, expediente activo Post-condiciones: Resumen tcnico creado Referencias Cruzadas (Casos de Uso): asignacin de terapias, asignar altas a pacientes. Flujo Bsico: 1. 2. 3. 4. 5. 6. 7. 8. 9. El sistema solicita el nmero de expediente. Usuario ingresa el nmero de expediente. El sistema despliega la informacin del expediente. El usuario selecciona solicitud de resmenes tcnicos. Sistema proporciona fecha de entrega de resumen tcnico. el usuario verifica los mdicos responsables a cargo del paciente. El sistema muestra los mdicos responsables a cargo del paciente. El usuario enva correo a medico responsable para solicitar la elaboracin del resumen por cada rea. El sistema solicita los siguientes datos del resumen. Diagnstico de la discapacidad, tratamiento recibido, recomendaciones segn la ltima nota de evolucin, y motivo del alta, si es que as se determino. 10. El usuario ingresa los datos del resumen y solicita guardar los cambios. 11. El sistema almacena la informacin de los resmenes creados. 12. El usuario verifica los resmenes almacenados para generar el resumen tcnico y solicita impresin. 13. El sistema imprime el resumen tcnico. Flujos Alternativos: 10. a El sistema muestra que los datos ingresados no son correctos o que hacen falta. 11. b El usuario no almacena los cambios. El sistema regresa al paso 9
86
9.1.18. Caso de Uso Asignar altas a pacientes
No. 17
Nombre de caso de uso: Asignar altas a pacientes
Actor Principal: Usuario del sistema, Paciente Personal involucrado e intereses: Paciente: Recibe el alta ya sea por Terapia o por alta permanente Usuario del Sistema: medico responsable asigna el alta Pre-condiciones: resmenes del mdico encargado de cada rea, resumen tcnico Post-condiciones: solicitud de reingreso Referencias Cruzadas (Casos de Uso): creacin de resumen tcnico Flujo Bsico: 1. 2. 3. 4. 5. 6. 7. 8. 9. El sistema solicita el nmero de expediente. Usuario ingresa el nmero de expediente. El sistema despliega la informacin del expediente. El usuario solicita ingresar a asignacin de altas. El sistema muestra los tipos de alta. Usuario selecciona el tipo de alta que se brindar. El sistema solicita los datos del alta. El usuario ingresa los datos del alta y solicita guardar los cambios. el sistema almacena la informacin del alta.
10. el usuario solicita la impresin del alta para entregarse a paciente Flujos Alternativos: 5.a usuario selecciona tipo de alta temporal. 5.b Usuario selecciona tipo de alta voluntaria.
87
5.c Usuario selecciona tipo de alta tcnica. 5.d Usuario selecciona tipo de alta Permanente. 8.a El sistema muestra que los datos ingresados no son correctos o que hacen falta. 8.b El usuario no almacena los cambios. El sistema regresa al paso 5
9.2. Diagramas de Secuencia 9.2.1. DDS Iniciar Sesin
9.2.2. DDS Administracin de Usuarios
88
89
90
9.2.3. DDS Creacin de Expediente
9.2.4. DDS Consulta Peditrica
91
9.2.5. DDS Pre-Evaluacin Tcnica Ingreso CRINA
9.2.6. DDS Inscripcin de Terapias
92
9.2.7. DDS Control de Asistencias
93
9.2.8. DDS Actualizar Expediente
9.2.9. DDS Control de Rehabilitacin
94
9.2.10. DDS Control de Seguimiento Mdico
9.2.11. DDS Control de Seguimiento Psicolgico
95
9.2.12. DDS Control de Trabajo Social Consulta Externa ISRI
9.2.13. DDS Control Trabajo Social CRINA
96
9.2.14. DDS Visita Domiciliar
9.2.15. DDS Generacin de Reportes
97
9.2.16. DDS Creacin de resumen tcnico
98
9.2.17. DDS Asignar altas a pacientes
10. Diseo de Seguridad 10.1. Diseo de niveles de acceso
Los niveles de acceso dentro de SIACE, se establecern por medio de perfiles de usuarios, estos perfiles permitirn tener acceso a algunas o todas las funciones para el sistema. Los niveles a utilizar se pueden clasificar de la siguiente manera: NIVEL 1. Administrador del Sistema: Posee todos los privilegios, posee acceso a la creacin y mantenimientos de usuarios del sistema, permite el acceso a todos los objetos de la base de datos, posee la capacidad de generacin de todos los tipos de reportes, as como la modificacin de cualquier tipo de registros, es el responsable de la seguridad del sistema, de las copias de respaldo y el ptimo funcionamiento del mismo.
99
NIVEL 2. Operador ISRI. Posee los privilegios para realizar la creacin de un nuevo expediente, as como para realizar el control de trabajo social por parte del ISRI, no posee privilegios de eliminar o modificar ningn registro. NIVEL 3. Operador CRINA. Posee los privilegios para realizar la apertura de un nuevo expediente, asignar horarios para la inscripcin de terapias, realizar control de trabajo social por parte del CRINA, y consulta sobre reportes necesarios para la creacin de resmenes tcnicos, control de asistencia a terapias, no posee privilegios de eliminar o modificar ningn registro. NIVEL 4. Doctores. Posee privilegios para actualizar y consultar cualquier expediente, realizar controles de seguimiento mdico, rehabilitacin y psicolgico, adems puede asignar altas a los paciente, no posee privilegios de eliminar o modificar ningn registro. NIVEL 5. Personal Tcnico. Posee los privilegios para actualizar y consultar cualquier expediente, realizar control de asistencias a terapias, adems de asignar altas a los pacientes, no posee privilegios de eliminar o modificar ningn registro. En la siguiente tabla se describen las diferentes opciones al sistema que cada nivel de acceso posee:
OPCIN DEL SISTEMA Crear Usuario Modificar Usuario Eliminar Usuario Creacin Expediente Emitir Referencia Pre Evaluacin Tcnica Inscripcin de Terapias Apertura de Expediente Actualizar Expediente Control Rehabilitacin Control Seguimiento Medico Control Seguimiento Psicolgico Control Trabajo Social ISRI Control Trabajo Social CRINA Generacin Reportes Creacin Resmenes Tcnicos Asignar Altas Control de Asistencia N1 X X X X X X X X X X X X X X X X x X X X X X X x X X X X X X X X X X N2 N3 N4 N5
100
10.2.
Diseo de seguridad de datos, hardware y software
La seguridad del sistema comprende todos aquellos aspectos que le permitirn al sistema su funcionamiento de manera regular, estable y segura. Dichos aspectos se encuentran relacionados con elementos de confidencialidad, integridad de datos, autorizaciones, entre otros. Seguridad de datos: Debern realizarse copias de respaldo (backups) de la base de datos al menos una vez a la semana, esto debido al volumen de datos que se maneja y el grado de importancia de estos. El acceso y modificacin de tablas de catlogos deber ser realizado por el administrador de la base de datos.
Seguridad de Hardware: Los servidores debern estar ubicados en un lugar de acceso restringido El lugar fsico donde se ubicaran tanto medios de almacenamiento como servidores deber estar libre de humedad y con la temperatura adecuada. Deben asignarse responsables sobre el manipulamiento fsico de los servidores y medios de almacenamiento tanto para su limpieza como para posibles cambios de ubicacin fsica. Los cables de comunicaciones debern ser colocados lejos de lmparas u otros objetos con campos electromagnticos que puedan alterar la seal en transmisin.
Seguridad de Software: Se realizara una autentificacin de usuarios para acceder a SIACE, mediante usuario y contrasea Las contraseas de los usuarios debern ser cambiadas por lo menos una vez cada dos meses para los operadores y una vez por mes para el administrador, lo anterior para garantizar la seguridad del acceso al sistema as como tambin prevenir la filtracin de contraseas en el lugar de trabajo, las cuales debern incluir una combinacin de letras maysculas, minsculas, nmeros y caracteres especiales adems deber de poseer una longitud mnima de 6 caracteres mximo 10. La asignacin de perfiles para un usuario ser realizada por el administrador del sistema. La bitcora de transacciones registrar los principales movimientos realizados dentro del SIACE, almacenando para ello lo siguiente: login de usuario, fecha, hora y tipo de transaccin realizada.
11. Diseo de la base de datos

A continuacin se presenta el Diseo Fsico para el desarrollo de la base de datos, en base a este podemos generar el diseo lgico y el diagrama de clases (Ver CD SIACE, Seccin Documentos/Diagramas) con las diferentes herramientas de diseo.
101
102
12. Diccionario de Datos

Un diccionario de datos se define como un conjunto de metadatos que contiene las c aractersticas lgicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripcin, tipo, nulo23. A continuacin se presenta el diccionario de datos dividido en dos secciones que ser utilizado para la creacin de la base de datos del sistema de administracin.
12.1.
Diccionario de Tablas con sus respectivos campos.
A continuacin se presentan cada una de las tablas que componen el sistema, donde se muestran los diferentes campos que las componen as como sus llaves primarias.
tb_altamedica: Tabla que almacena las altas otorgada por el mdico al paciente.
Campo id_altaMed id_cita fecha_altaMedica id_expediente id_tipoAlta id_gravedad id_condicion cod_4 codn4 observacionAlta medicoResponsable Tipo int(11) int(11) date varchar(9) int(11) int(11) int(11) varchar(8) varchar(8) varchar(500) varchar(125) Nulo No No No No No S S S S S S Predeterminado Comentarios
NULL NULL NULL NULL NULL NULL
tb_areaatencion
Campo id_areaAtencion nombre_areaAtencion id_institucion desc_areaAtencion Tipo int(11) varchar(1024) int(11) varchar(1024) Nulo No No S S Predeterminado Comentarios
NULL NULL
tb_capcie10
Campo codCap nombre_cap int(11) varchar(1024) Tipo Nulo No No Predeterminado Comentarios
23
Fuente consultada: http://es.wikipedia.org/wiki/Diccionario_de_datos
103
tb_capcif
Campo id_capitulo nombre_capitulo Tipo varchar(5) varchar(1024) Nulo No No Predeterminado Comentarios
tb_catinasistencia
Campo id_catInasist nombre_catinasist int(11) varchar(256) Tipo Nulo No No Predeterminado Comentarios
tb_citamedica
Campo id_cita id_expediente id_empleado horario_cita cita_PrimeraVez confirmar int(11) varchar(9) int(11) datetime tinyint(1) tinyint(1) Tipo Nulo No S No S No S NULL NULL NULL Predeterminado Comentarios
tb_citaterapia
Campo id_cita id_expediente id_empleado id_dia horario_cita anio_cita confirmar fecha_confirmar int(11) varchar(9) int(11) tinyint(1) time int(11) tinyint(1) datetime Tipo Nulo No S No No S S S S NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_codn2_cif
Campo codn2 id_capitulo nombre_codn2 Tipo varchar(8) varchar(8) varchar(1024) Nulo No No No Predeterminado Comentarios
104
tb_codn3_cif
Campo codn3 codn2 nombre_codn3 Tipo varchar(8) varchar(8) varchar(1024) Nulo No No No Predeterminado Comentarios
tb_comunichumana_f10
Campo id_comunicHumana_f10 id_institucion id_expediente id_referencia fechaEvaluacion_f10 historiaClinica_f10 areaCognitiva_f10 areaSensorial_f10 areaMotora_f10 funcionVeget_f10 praxiasOrales_f10 lenguajeRecep_f10 lenguajeExpres_f10 caracterVoz_f10 cod_4 diagnostico_f10 codn4_AC codn4_AS codn4_AO codn4_CV codn4_DS discapacidad_f10 planTratamiento_f10 observaciones_f10 expectUsuario_f10 evaluador_f10 id_cita int(11) int(11) varchar(9) int(11) date varchar(2048) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(8) varchar(1024) varchar(8) varchar(8) varchar(8) varchar(8) varchar(8) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(128) int(11) Tipo Nulo No S No No No No S S S S S S S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
105
tb_codn4_cif
Campo codn4 codn3 nombre_codn4 Tipo varchar(8) varchar(8) varchar(1024) Nulo No No No Predeterminado Comentarios
tb_condicion
Campo id_condicion nombre_condicion int(11) varchar(128) Tipo Nulo No No Predeterminado Comentarios
tb_confirmacion_terapia
Campo id_cita id_empleado confirmacion fecha int(11) int(11) tinyint(4) datetime Tipo Nulo No S S S NULL NULL NULL Predeterminado Comentarios
tb_contmedica_f5
Campo id_contMedica_f5 id_expediente id_institucion historial_f5 medicoResponsable id_cita int(11) varchar(9) int(11) varchar(2048) varchar(256) int(11) Tipo Nulo No S S S S S NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_deptopais
Campo id_deptoPais nombre_deptoPais int(11) varchar(256) Tipo Nulo No S NULL Predeterminado Comentarios
tb_gravcondicion
Campo id_gravCondicion nombre_gravCondicion int(11) varchar(256) Tipo Nulo No No Predeterminado Comentarios
106
tb_controlmed_f3
Campo id_controlMed id_expediente id_empleado id_institucion saludPadres consanguiniedad edadConcepcion gesta para prematuros abortos vivos fallecidos hermanos saludHermanos patologias_fam numEmbarazo gestacion sem_gestacion tipoEmbarazo coment_tipoEmbarazo enfermedadEmbarazo medToxEmbarazo movFetales coment_movFetales tipo_parto fecha_parto posicion_fetal oper_obstetrica coment_parto ruptura_menbrana tiempo_ruptura sufri_fetal meconico coment_sufri lloroRespiro Asfixia coment_asfixia int(11) varchar(1024) int(11) int(11) tinyint(1) tinyint(1) int(11) int(11) int(11) int(11) int(11) int(11) int(11) int(11) tinyint(1) varchar(2048) int(11) varchar(1024) int(11) varchar(1024) varchar(1024) varchar(1024) varchar(1024) tinyint(1) tinyint(1) varchar(256) date tinyint(1) varchar(256) varchar(2048) tinyint(1) time tinyint(1) tinyint(1) varchar(2048) tinyint(1) tinyint(1) varchar(2048) Tipo Nulo No No No No S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
107
apgar1 apgar5 condicion_nacer peso talla per_cefalico ingresoNac coment_ingreso
int(11) int(11) varchar(2048) float float float tinyint(1) varchar(2048)
S S S S S S S S
NULL NULL NULL NULL NULL NULL NULL NULL
tb_controlpsico
Campo id_controlPsico id_expediente id_empleado id_controlMedico pruebasApliac examenMental resEvaluacion conductaObsv rasgosPersonal conclusion_psico diagnostic_psico tratam_psico int(11) varchar(256) int(11) int(11) varchar(2048) varchar(2048) varchar(2048) varchar(2048) varchar(2048) varchar(2048) varchar(2048) varchar(2048) Tipo Nulo No No No No S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_diagnostico_f3
Campo id_diagnostico_f3 id_historiaNinos_F3 cod_4 codn4 funciones_mental par_craneal fuerzaTonoReflejo vestibular sensibilidad observ_neuro impresion_diagno observ_tratamiento usuario_f3 int(11) int(11) varchar(8) varchar(8) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(100) Tipo Nulo No S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
108
tb_embarazoparto_f3
Campo
id_embarazoParto id_historiaNinos_F3 numEmbarazo gestacion sem_gestacion tipoEmbarazo coment_tipoEmbarazo enfermedadEmbarazo medToxEmbarazo movFetales coment_movFetales tipo_parto fecha_parto posicion_fetal coment_parto ruptura_menbrana tiempo_ruptura sufri_fetal meconico coment_sufri lloroRespiro Asfixia coment_asfixia apgar1 apgar5 apgar10 condicion_nacer peso talla per_cefalico ingresoNac coment_ingreso int(11) int(11) int(11)
Tipo
Nulo No No S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S
Predeterminado
Comentarios
NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL
tinyint(1) int(11) varchar(1024) varchar(1024) varchar(1024) varchar(1024) tinyint(1) tinyint(1) varchar(256) date tinyint(1) varchar(2048) tinyint(1) time tinyint(1) tinyint(1) varchar(2048) tinyint(1) tinyint(1) varchar(2048) int(11) int(11) int(11) varchar(2048) float float float tinyint(1) varchar(2048)
109
tb_empleado
Campo id_empleado apellido_empleado nombre_empleado direcc_empleado tel_empleado cel_empleado email_empleado id_municipio id_puesto cargo_nombrado id_especArea username int(11) varchar(1024) varchar(1024) varchar(1024) varchar(9) varchar(9) varchar(256) int(11) int(11) varchar(1024) int(11) varchar(50) Tipo Nulo No No No S S S S S No S No S NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_equipo
Campo id_equipo nombre_equipo desc_equipo int(11) varchar(1024) varchar(1024) Tipo Nulo No No S NULL Predeterminado Comentarios
tb_prestamoequipo
Campo id_presamo id_equipo fecha_prestamo hora_prestamo hora_devolucion int(11) int(11) date time time Tipo Nulo No No No No No Predeterminado Comentarios
tb_generalidades_f3
Campo id_historiaNios_F3 id_expediente id_empleado id_institucion id_cod4 id_codn4 int(11) varchar(1024) int(11) int(11) varchar(5) varchar(5) Tipo Nulo No No No No No No Predeterminado Comentarios
110
tb_escolaridad
Campo id_escolaridad nombre_escolaridad int(11) varchar(1024) Tipo Nulo No No Predeterminado Comentarios
tb_especarea
Campo id_especArea nombre_especArea id_areaAtencion desc_especArea int(11) varchar(1024) int(11) varchar(1024) Tipo Nulo No No S S NULL NULL Predeterminado Comentarios
tb_examfisico_f3
Campo id_examFisico_f3 id_historiaNinos_F3 peso_kg talla_cm perimetro_cefal presion_art temperatura cabeza ojos oidos narizBocaGarg cuello torax pulmones corazon abdomen genitales articulacion extremidades pulsos_peri Tipo int(11) int(11) varchar(256) varchar(256) varchar(256) varchar(256) varchar(256) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) Nulo No No S S S S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
111
tb_expediente
Campo id_expediente fecha_apertura nombre_paciente prim_apellido segun_apellido sexo_paciente fecha_nac id_escolaridad id_estadoCivil dui_paciente num_parNac folio_parNac libro_parNac extend_parNac ocupacion_pac direcc_pac id_municipio tel_pac cel_pac email_pac referencia id_protecSocial nombre_madre nombre_padre nombre_conyugue resp_usuario direcc_resp tel_resp nombre_informante parentesco dui_informante tel_informante direcc_informante observacion_exp username date varchar(1024) varchar(1024) varchar(1024) tinyint(1) date int(11) int(11) varchar(10) int(11) int(11) int(11) varchar(1024) varchar(1024) varchar(1024) varchar(9) varchar(9) varchar(9) varchar(1024) varchar(1024) int(11) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) int(8) varchar(1024) varchar(1024) varchar(10) varchar(9) varchar(1024) varchar(2048) varchar(50) Tipo varchar(9) Nulo No No No No S No S S S S S S S S S S S S S S S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
112
tb_estadocivil
Campo id_estadoCivil nombre_estadoCivil int(11) varchar(256) Tipo Nulo No No Predeterminado Comentarios
tb_gravedad
Campo
id_gravedad nombre_gravedad int(11)
Tipo
varchar(128)
Nulo
No No
Predeterminado
Comentarios
tb_heredfamiliares_f3
Campo id_heredofamilia id_historiaNios_F3 saludPadres consanguiniedad edadConcepcion gesta para prematuros abortos vivos fallecidos hermanos saludHermanos patologias_fam int(11) int(11) tinyint(1) tinyint(1) int(11) int(11) int(11) int(11) int(11) int(11) int(11) int(11) tinyint(1) varchar(2048) Tipo Nulo No No S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_historiaf12
Campo id_historiaF12 id_institucion id_expediente id_cita comentarios fecha_evaluacion evaluador_f12 int(11) int(11) varchar(9) int(11) varchar(2048) datetime varchar(20) Tipo Nulo No S S S S S S NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
113
tb_municipio
Campo id_municipio id_deptoPais nombre_municipio int(11) int(11) varchar(1024) Tipo Nulo No No No Predeterminado Comentarios
tb_gravcondicion
Campo id_gravCondicion nombre_gravCondicion int(11) varchar(256) Tipo Nulo No No Predeterminado Comentarios
tb_historiageneral_f4
Campo id_histoClinica_f4 id_expediente id_institucion motivo_consulta historia_clinica anteced_fam temperatura_f4 presion_f4 pulso_f4 talla_f4 peso_f4 diagnostico_f4 codn4 cod_4 terapia_inicial username id_cita int(11) varchar(9) int(11) varchar(1024) varchar(2048) varchar(2048) decimal(10,0) varchar(7) varchar(7) decimal(10,0) decimal(10,0) varchar(1024) varchar(6) varchar(6) varchar(1024) varchar(150) int(11) Tipo Nulo No S S S S No S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_protecsocial
Campo id_protecSocial nombre_protecSocial int(11) varchar(1024) Tipo Nulo No No Predeterminado Comentarios
114
tb_hojaegreso_f19
Campo id_HojaEgreso_f19 id_expediente cif fecha_egreso_f19 id_condicion id_gravedad motivo_egreso_f19 recomendaciones_f19 observaciones_f19 responsableEgreso_f19 double varchar(9) varchar(9) date int(11) int(11) varchar(3000) varchar(3000) varchar(3000) varchar(100) Tipo Nulo No S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_historianinos_f3
Campo id_historiaNinos_F3 id_expediente id_cita diag_referencia saludPadres consanguiniedad edadConcepcion gesta para prematuros abortos vivos fallecidos hermanos saludHermanos patologias_fam int(11) varchar(9) int(7) varchar(256) tinyint(1) tinyint(1) int(11) int(11) int(11) int(11) int(11) int(11) int(11) int(11) tinyint(1) varchar(1024) Tipo Nulo No S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_puesto
Campo id_puesto nombre_puesto desc_puesto int(11) varchar(1024) varchar(1024) Tipo Nulo No No S NULL Predeterminado Comentarios
115
tb_hojavisitadomiciliar_f16
Campo id_HojaVisitaDomiciliar_f16 id_Institucion id_expediente hora_entrevista_f16 nomb_entrevistado_f16 direccion_f16 objetivo_f16 vivienda_f16 amb_soc_eco_f16 orientaciones_f16 opinion_trab_f16 entrevistador_f16 int(11) int(11) varchar(9) datetime text text text text text text text varchar(384) Tipo Nulo No S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_psicomotor_f3
Campo
id_psicomotor_f3 id_historiaNinos_F3 sonrrisa_soc sedestacion marcha_indep soten_cefalico gateo lenguaje_normal da_vuelta bipedestacion esfinter_vesical esfinter_anal escolarizado aprovechamiento explique_aprovech antec_patologicos padec_actual int(11) int(11)
Tipo
Nulo
No S S S S S S S S S S S S S S S S
Predeterminado
NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL
Comentarios
tinyint(1) tinyint(1) tinyint(1) tinyint(1) tinyint(1) tinyint(1) tinyint(1) tinyint(1) tinyint(1) tinyint(1) tinyint(1) varchar(256) varchar(2048) varchar(2048) varchar(2048)
116
tb_indicacionmedica_f6
Campo id_indicacionF6 id_institucion id_expediente hora_indicacion1 hora_indicacion2 hora_indicacion3 hora_indicacion4 indicacion1 indicacion2 indicacion3 indicacion4 responsable_f6 fecha_hoja int(11) int(11) varchar(9) time time time time varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(100) datetime Tipo Nulo No S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_hojapsicologia_f13
Campo id_hojaPsico_F13 id_expediente id_cita id_referenciaInt profesionalAten gestacion_f13 difgestacion_f13 comentgesta_f13 difParto_f13 tipoParto_f13 comentParto_f13 lloroNacer_f13 comentlloro_f13 edadSentarse_f13 edadCaminar_f13 edadComfrol_f13 difDormir_f13 comentDormir_f13 desarrolloPisco_f13 autoayuda_f13 compoFamiliar_f13 personaMantiene_f13 int(11) varchar(9) int(11) int(11) varchar(600) int(2) tinyint(1) varchar(500) tinyint(1) tinyint(1) varchar(500) tinyint(1) varchar(500) int(3) int(3) int(3) tinyint(1) varchar(500) varchar(1024) varchar(1024) varchar(1024) varchar(200) Tipo Nulo No No No No S S S S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
117
personaCuida_f13 conductaDesc_f13 historiaEscolar_f13 pruebasAplic_f13 examenMental_f13 resulEvaluacion_f13 conductaObsv_f13 rasgosPersona_f13 conclusion_f13 diagnostico_f13 planTratmiento_f13
varchar(200) varchar(1024) varchar(1024) varchar(1024) varchar(2048) varchar(2048) varchar(1024) varchar(1024) varchar(2048) varchar(1024) varchar(2048)
S S S S S S S S S S S
NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL
tb_roles
Campo id_rol nombre_rol int(11) varchar(500) Campo id_institucion nombre_institucion id_municipio direcc_institucion tel_institucion correo_electronico int(11) varchar(256) int(11) varchar(1024) varchar(9) varchar(50) Tipo Tipo Nulo No No Nulo No No No No No S NULL Predeterminado Comentarios Predeterminado Comentarios
tb_instituciones
tb_hojatrabajosocial_f17
Campo id_TrabajoSocial_f17 id_expediente descripcion_f17 fecha responsable int(11) varchar(9) varchar(3000) datetime varchar(50) Tipo Nulo No No No S S NULL NULL Predeterminado Comentarios
tb_referenciainterna
Campo id_referenciaInt id_expediente id_cita int(11) varchar(9) int(11) Tipo Nulo No S S NULL NULL Predeterminado Comentarios
118
Diagnostico MotivoReferencia id_especArea observaciones_ref
varchar(500) varchar(500) int(11) varchar(500)
S S S S
NULL NULL NULL NULL
tb_referenciaexterna
Campo id_referenciaExt id_expediente id_cita id_institucion codn4 cod_4 id_areaAtencion observacion_ref int(11) varchar(9) int(11) int(11) varchar(6) varchar(6) int(11) varchar(256) Tipo Nulo No No No No No No No S NULL Predeterminado Comentarios
tb_tipoalta
Campo id_tipoAlta nombre_tipoAlta int(11) varchar(256) Tipo Nulo No No Predeterminado Comentarios
tb_segpsico
Campo id_segPsico id_institucion id_empleado id_expediente reevalPisco seg_tratamPsico int(11) int(11) int(11) varchar(256) varchar(2048) varchar(2048) Tipo Nulo No No No No S S NULL NULL Predeterminado Comentarios
tb_reporteenfermera_f7
Campo id_repEnfermera_f7 id_institucion id_expediente horaReporte1 horaReporte2 horaReporte3 int(11) int(11) varchar(9) time time time Tipo Nulo No S S S S S NULL NULL NULL NULL NULL Predeterminado Comentarios
119
horaReporte4 rep1Enfermera rep2Enfermera rep3Enfermera rep4Enfermera responsable_f7 fecha_reporte
time varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(50) datetime
S S S S S S S
NULL NULL NULL NULL NULL NULL NULL
tb_resumenclinico_f18
Campo id_resumenClinico id_institucion id_expediente evalIngreso_f18 examenFisico_f18 resultadoExam_f18 intervenMedica_f18 tratamientos_f18 intervenTerapia_f18 condicionEgreso_f18 metasAlcanzadas_f18 orientacionVoc_f18 observaciones_f18 medicoResp_f18 fecha int(11) int(11) varchar(9) text text text text text text text text text text text datetime Tipo Nulo No S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_sub2cie10
Campo codsCap codCap nombre_subcap int(11) varchar(1024) Tipo varchar(8) Nulo No No No Predeterminado Comentarios
tb_solicitudexam_f20
Campo id_solicitudExam id_expediente id_cita examenesSolic int(11) varchar(9) int(11) varchar(2048) Tipo Nulo No S S S NULL NULL NULL Predeterminado Comentarios
120
tb_reevpsico_f14
Campo id_reevalPsico_f14 id_cita id_expediente reevalPisco_f14 seg_tratamPsico_f14 int(11) int(11) varchar(9) varchar(2048) varchar(2048) Tipo Nulo No No No S S NULL NULL Predeterminado Comentarios
tb_sub3cie10
Campo cod_3 codsCap nombre_sub3 Tipo varchar(8) varchar(8) varchar(1034) Nulo No No No Predeterminado Comentarios
tb_sub4cie10
Campo cod_4 cod_3 nombre_sub4 Tipo varchar(8) varchar(8) varchar(1024) Nulo No No No Predeterminado Comentarios
tb_tipoinasistencia
Campo id_tipoInasist id_catInasist nombre_tipoInasist int(11) int(11) varchar(256) Tipo Nulo No No No Predeterminado Comentarios
tb_usuarios
Campo userName clave id_rol Activo Tipo varchar(50) varchar(50) int(11) tinyint(1) Nulo No No S S NULL NULL Predeterminado Comentarios
tb_sociofamiliar_f15
Campo id_socioEconomico id_institucion int(11) int(11) Tipo Nulo No S NULL Predeterminado Comentarios
121
id_expediente trabajo_f15 telTrabajo_f15 nombre1_f15 nombre2_f15 nombre3_f15 nombre4_f15 nombre5_f15 edad1 edad2 edad3 edad4 edad5 parentesco1 parentesto2 parentesco3 parentesco4 parentesco5 nivelEducativo1 nivelEducativo2 nivelEducativo3 nivelEducativo4 nivelEducativo5 profesion1 profesion2 profesion3 profesion4 profesion5 salario1 salario2 salario3 salario4 salario5 aporte1 aporte2 aporte3 aporte4 aporte5 situacionFamilia_f15 vivienda_f15 situacionUsuario_f15
varchar(9) varchar(100) varchar(9) varchar(100) varchar(100) varchar(100) varchar(100) varchar(100) int(3) int(3) int(3) int(3) int(3) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) varchar(50) float float float float float float float float float float varchar(2056) varchar(2056) varchar(2056)
No S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL
122
laboral_f15 economicoFamilia_f15 opinion_f15 conclusiones_f15 evaluador_f15 fecha
varchar(2056) varchar(2056) varchar(2056) varchar(2056) varchar(100) datetime
S S S S S S
NULL NULL NULL NULL NULL NULL
tb_terapiafisica_f9
Campo id_terapiafisica_f9 id_institucion id_cita id_expediente id_referencia fechaEvaluacion_f9 historiaClinica_f9 areaCognitiva_f9 areaSensorial_f9 postura_f9 tono_f9 reflejo_f9 estadoPiel_f9 areaMotora_f9 amplitudArticular_f9 fuerzaMuscular_f9 contracMuscular_f9 actividaDiaria_f9 expecUsuario_f9 conclusiones_f9 planTratamiento_f9 observaciones_f9 evaluador_f9 int(11) int(11) int(11) varchar(9) int(11) date varchar(2048) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(128) Tipo Nulo No No No S S S S S S S S S S S S S S S S S S S S NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL Predeterminado Comentarios
tb_terapiaeducativa_f11
Campo id_terapiaEducativa_f11 id_institucion id_expediente id_referencia int(11) int(11) varchar(9) int(11) Tipo Nulo No No No No Predeterminado Comentarios
123
id_cita fechaEvaluacion_f11 tiempoEvolucion historiaClinica_f11 areaCognitiva_f11 areaSocial_f11 areaPsicomotriz_f11 areaLenguaje_f11 areaSensorial_f11 cod_4 diagnosticoArea_f11 planTratamiento reconUsuario_f11 reconFamilia_f11 evaluador_f11
int(11) date varchar(25) varchar(2048) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(8) varchar(1024) varchar(1024) varchar(1024) varchar(1024) varchar(128)
No No S S S S S S S No S S S S No NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL
13. PLAN DE IMPLEMENTACIN 13.1. ELEGIR LA ARQUITECTURA
La arquitectura necesaria para el ptimo desempeo de SIACE es un punto clave que debe definirse a fin de evitar problemas cuando el sistema se encuentre totalmente en funcionamiento. Es por ello que se ha tratado de brindar como sugerencia las caractersticas del Hardware, Software, necesarios para la implementacin.
13.1.1. Recurso Tecnolgico para la Implementacin:

Como recomendacin se detalla a continuacin el Hardware y Software mnimos necesarios para que SIACE pueda ser implementado sin ningn problema. Hardware: Elemento
RAM HD Drive Procesador Tarjetas de RED
Servidor
2 GB 500 GB, Raid 1 Intel Xeon Dual Core 3.0 Ghz 10/100
Usuarios
512 MB 50 GB Intel Dual Core 1 Ghz 10/100
Tabla 13.1. Descripcin de HW para la implementacin.
124
Software: Elemento
Sistema Operativo Base de datos Servidor Web Otras Herramientas Navegador Web
Servidor
Windows 2003 Server Standard Edition MySQL 5.1.141 Apache 2.2.14 phpMyAdmin 3.2.4 Internet Explorer 8
Usuario
Windows XP o superior N/A N/A N/A Internet Explorer 8
Tabla 13.2. Descripcin de SW para la implementacin.
13.1.2. Recurso Humano:

Para la correcta implementacin del sistema es necesario contar con el personal necesario, que cumpla con los requisitos en conocimiento para la administracin y operacin del sistema. Por lo anterior, se ha definido el siguiente perfil del Administrador del Sistema. Perfil del Administrador del Sistema Requisitos Personales: Capacidad para trabajar en equipo Capacidad para la toma de decisiones oportunas Iniciativa para enfrentar situaciones desconocidas.
Requisitos Tcnicos: Conocimiento deseable (Tiempo de experiencia 1 ao en el rea de soporte tcnico) Instalacin y Configuracin de Servidores bajo ambiente Windows 2003. Instalacin y Configuracin de Servidor Web usando APACHE WEB SERVER. Instalacin y Configuracin de Servidor de base de datos usando MysSQL.
13.2.
DESCRIPCIN DE LA ARQUITECTURA DEL SISTEMA.
La arquitectura del sistema se encuentra compuesta por los elementos presentados en el siguiente diagrama, en l se muestran los enlaces de comunicacin que tienen entre estos.
125
CLIENTE 1
INTERNET
SERVIDOR WEB SERVIDO BAD
CLIENTE 2
Imagen 13.1 Enlaces de comunicacin de los elementos del sistema.
13.2.1. Descripcin de las partes de la arquitectura del Sistema

Los usuarios estarn conectados a travs de estaciones de trabajados que se encuentran distribuidas en el CRINA. El acceso a SIACE se realizara mediante un navegador web, el cual permitir el ingreso al Sistema.
CLIENTE
INTERNET
Internet ser el medio de comunicacin utilizado para el intercambio de informacin entre SIACE y los usuarios del sistema.
Este servidor se encuentra compuesto por : - Un servidor WEB, Apache que tiene soporte para aplicaciones PHP y funciona en cualquier sistema operativos.
SERVIDOR WEB SERVIDO BAD
- El servidor de base de datos MySQL que procesara toda la informacin necesaria para el funcionamiento de SIACE.
Tabla 13.3 Descripcin de los elementos de la arquitectura del sistema.
126
13.3.
METODOLOGA PARA LA IMPLEMENTACIN
La definicin de la metodologa es trascendental para lograr una implementacin del sistema, tomando en cuenta las dos alternativas ms conocidas y utilizadas para este fin: la implantacin directa e implementacin en paralelo. Para ello determinamos las ventajas y desventajas de ellas.
METODOLOGIA VENTAJAS Algunos recursos no son compartidos Implementacin directa. Reduce el tiempo para llevar a cabo la implementacin Los costos de implementacin se reducen. Se cuenta con un respaldo si el sistema propuesto falla Implementacin en Paralelo. Permite una mejor adaptacin al nuevo sistema Promueve el nuevo sistema a travs del actual. DESVENTAJAS Ausencia de respaldo en casa de falla el nuevo sistema. Aumenta las posibilidades de resistencia al cambio. Reduce la promocin del nuevo sistema Algunos recursos pueden ser compartidos. El tiempo de implementacin tiende a aumentar. Los costos pueden aumentar considerablemente.
Tabla 13.4. Ventajas y desventajas de las metodologas de implementacin.
Al evaluar ventajas y desventajas de cada una de las metodologas expuestas, se puede determinar que dependiendo de la situacin en que se encuentre cada sistema a implantar as se tendr una eleccin de una opcin sobre otra. No existe una mejor que otra sino que estas dependen directamente del estado en que se encuentre la organizacin, considerando principalmente la disponibilidad de recursos. Para nuestro caso por ser un sistema que servir principalmente para el anlisis de datos y apoyo a la toma de decisiones, es de vital importancia que mientras se encuentre en el periodo de implementacin se pueda contar un sistema contra el que se comparen los datos y se pueden constatar la validez de la informacin presentada. Debido a esto es que se concluye que la metodologa ms conveniente para este proyecto es la implementacin en paralelo, ya que permitirn que los usuarios puedan adaptarse al sistema, dando la opcin de poder comparar la informacin del sistema actual contra el nuevo sistema. As mismo en caso de que falle el nuevo sistema, no se afectaran las operaciones de la institucin. Habiendo seleccionado la metodologa de implementacin, es necesario definir un punto de convergencia en el que el sistema actual y el sistema propuesto trabajaran de forma paralela para que se pueda verificar la funcionalidad del nuevo sistema y lograr la aceptacin por parte de los usuarios. Para lograr esta evaluacin, se recomienda que el periodo sea de tres a seis meses aunque esto depender del coordinador del proyecto. 127
13.4.
PLANIFICACIN DE ACTIVIDADES.
El proceso de implementacin del sistema desarrollado seguir el siguiente proceso administrativo, basado en macro actividades y desglosadas segn cantidad de procesos a realizar.
13.4.1. Planeacin de Implementacin.

OBJETIVO: Definir los elementos necesarios que compone el ambiente en que se ejecutara la implementacin del sistema desarrollado. ACTIVIDADES: Definir estrategias como inicio de ejecucin del plan de implementacin y puesta en marcha del sistema desarrollado. Gestin de los recursos disponibles y limitantes. Identificar cambios sorpresivos a causa de recursos no disponibles o limitados, previniendo la readecuacin del presupuesto y planificacin cronolgica. Preparacin del ambiente organizacional. Anunciando fechas planificadas para cada una de las direcciones que se vern involucradas y la disponibilidad del recurso humano, preparando el ambiente organizacional para la puesta en marcha del sistema desarrollado. Envi de memo a los coordinadores involucrados. Reunin con Directores para brindar una descripcin del proyecto y del plan de implantacin.
13.4.2. Organizacin de Implementacin.

OBJETIVO: Organizar y planificar el recurso humano necesario para la implementacin del sistema desarrollado. ACTIVIDADES: - Definicin del equipo ejecutor. Establecer el recurso humano encargado de ejecutar el plan de implantacin, estableciendo la estructura organizativa definiendo las lneas de mando y los medios de comunicacin entre los participantes del proceso. - Estudio de perfiles y funciones del equipo ejecutor. Revisin de cada uno de los perfiles que integraran el equipo ejecutor del plan de implantacin, verificando con concordancia de funciones de acuerdo al perfil. - Definicin de responsabilidades. Asignar actividades a cada uno de los miembros del equipo ejecutor y su respectiva responsabilidad dentro de esta.
128
13.4.3. Ejecucin de Implementacin.

OBJETIVO: Ejecutar cada una de las actividades necesarias para la implementacin del proyecto desarrollado bajo el nombre de SIACE ACTIVIDADES: - Instalacin y configuracin del equipo informtico. Los equipos a utilizar estarn bajo la estructura cliente-servidor para lo cual: Servidor: El equipo informtico que se utilizara como servidor para el aplicativo esta detallado en el apartado RECURSO TECNOLOGICO PARA LA IMPLEMENTACION. Este equipo deber estar incorporado a la red local de trabajo del CRINA, recomendando la verificacin de los estndares recomendados por IEEE para la conectividad de la red. La configuracin del Servidor esta detallada en el MANUAL DE INSTALACION Y DESINSTALACION DEL SISTEMA. - Ejecucin y control inicial:En coordinacin con el equipo de desarrollo e implementacin, controlar la correcta ejecucin y carga de datos del repositorio origen hacia la BASE DE DATOS DE SIACE. - Prueba de Aplicativo: Establecimiento de la estructura que organiza evaluaciones, inspecciones, auditorias y revisiones que aseguren que se cumpla las responsabilidades asignadas, se utilicen eficientemente los recursos y se logre el cumplimiento de los objetivos del Sistema. Este equipo deber mantener bajo control un proceso y eliminar las causas de los defectos. - Preparacin de plan de capacitacin: Preparacin del personal que estar asignado al proceso de capacitacin y adiestramiento. El temario de la capacitacin est definido en el manual del usuario. - Presentacin y capacitacin: A continuacin se definen las actividades a realizar con los usuarios: Notificacin de usuarios a capacitar, prepara lugar de capacitacin para usuarios, capacitacin de usuarios.
129
13.4.4. Ejemplo de calendarizacin del plan de Implementacin.
Figura 13.2 Ejemplo de Calendarizacin para la implementacin.
130
13.5.
RECURSOS A UTILIZAR:
La ejecucin de las actividades en la capacitacin y adiestramiento de usuarios, se requiere de recurso tcnico, humano y materiales que den soporte y completen dichas actividades, razn suficiente para tener dentro de los elementos de planificacin el listado de recursos necesarios clasificados por su tipo. En las siguientes tablas se presenta el Recurso Tcnico, Humano y Materiales a utilizar.
Recurso Tcnico Recurso Computadoras Terminales Direccin IP Unidades 5 Descripcin Una computadora para un usuario, un grupo mximo de 5 personas por capacitacin Direcciones IP de acceso a la red local y a la aplicacin, para 5 terminales Un proyector para las presentaciones y ejemplificaciones del manejo de la herramienta Energa disponible en el local que se utilizara para las capacitaciones La sala de capacitacin debe tener una capacidad de espacio para ubicar 5 terminales, 5 usuarios y el capacitador.
Proyecto
Energa de la sala de capacitacin Sala de Capacitacin
Segn horas de capacitacin 1
Tabla 13.5: Tabla de recursos tcnicos a utilizar.
Recurso Humano Recurso Capacitador de personal Unidades 1 Descripcin Persona que brindara las capacitaciones a los usuarios sobre la nueva herramienta. Encargado de configurar las computadoras con acceso a red local.
Administrador de aplicaciones
Tabla 13.6: Tabla de Recurso Humano a utilizar.
131
Materiales
Recurso Manual de Usuario
Unidades 8
Descripcin
Gua de usuario para el uso de la herramienta, soporte fsico para el proceso de capacitacin. Soporte fsico para anotacin. Para escribir.
Libreta de anotaciones Lpiz
20 25
Tabla 13.7 Tabla de Materiales a utilizar.
13.5.1. Control de la implementacin:

OBJETIVO: Asegurar la calidad de la implementacin del aplicativo construido segn lo planificado y programado. ACTIVIDADES: - Verificacin de cumplimiento de control: Verificar que la implementacin del sistema se realice segn lo planificado; para que de esta manera logre establecer la trayectoria a seguir ante posibles variaciones; creando as, una actividad de auditora con lo que se persigue, verificar que la implementacin se ejecuta segn los elementos de control establecidos. - Elaboracin de informes de avance y control:Elaborar los informes sobre el seguimiento del plan de implementacin del sistema y de los inconvenientes detectados durante las actividades de verificacin realizados como parte del control.
13.6.
SISTEMA DE CONTROL.
Con el objetivo de ejecutar el plan de implementacin de una manera eficiente, se propone un plan de control el cual se puede apoyar con tcnicas de medicin basadas en resultados de formularios, los cuales brindan informacin del progreso de la implementacin proyectando un seguimiento en funcin del tiempo. La tcnica basada en formularios se ejecuta principalmente por el encargado de la actividad, el cual debe velar que la ejecucin de la tarea sea completada respecto a lo programado con anterioridad, haciendo uso de las herramientas, recursos y tiempo previamente establecidos, en el caso de surgir alguna variante, se realiza la correccin o adaptacin que sea necesaria para la correcta ejecucin de las actividades. Una vez ejecutada la actividad y completado los formularios de control debern archivarse para tener una bitcora de ejecucin, y adems deben considerarse los cambios efectuados en el proceso mismo de implementacin, para tener un control ms minucioso y completo de las actividades. 132
13.6.1. Formularios para el Control:

La documentacin de actividades genera un beneficio al momento de estudiar fallas, xitos, deficiencias o mejoras que se hayan presentado en las actividades o tareas desarrolladas, adems se puede llevan un mejor control de gastos en los que se haya incurrido, con el propsito de mejorar futuras actividades para lograr reducir costos a la organizacin. Por esa razn, los formularios propuestos para utilizar como herramientas de control son los siguientes: Formulario de Control de Actividades. Formulario de Control de Tareas. Formulario de Gastos.
Formulario de Control de Actividades: Este formulario se deber utilizar en el caso de llevar un control de todas las actividades programadas para la implementacin, de esta manera se posee un panorama ms amplio del progreso de implementacin, adems se lleva un control de las actividades con mayor prioridad y las actividades que se deben de ejecutar antes que otras. Elementos importantes del formulario: Elaborado por: Coordinador de Proyecto Orientado a: Direccin del CRINA Frecuencia recomendada: Periodos semanales de control.
Instructivo de llenado de formulario: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Detallar la persona que llena el Formulario, con nombres y apellidos. Agregar la fecha de elaboracin del formulario (dd/mm/aaaa). Agregar la fecha de inicio del periodo del informe (dd/mm/aaaa). Agregar a fecha de fin del periodo del informe (dd/mm/aaaa). Detallar el nombre de la persona responsable de la actividad. Anotar el correlativo de la actividad. Escribir el nombre de la actividad. Verificar si la actividad ha sido ejecutada. Verificar si la actividad est pendiente. Colocar el nmero de actividades esperadas al momento. Calcular el porcentaje de actividades esperadas respecto al total de actividades al momento. Colocar el nmero de actividades realizadas al momento. Calcular el porcentaje de tareas realizadas. Anotar nmero de actividades pendientes. Anotar porcentaje de tareas pendientes. Anotar total de tareas Anotar porcentaje total 133
18. 19. 20. 21. 22.
Agregar observaciones referentes a las actividades ejecutadas. Agregar nombre de la persona que revisa el formulario Agregar fecha de revisin del formulario (dd/mm/aaaa). Anotar el nmero de pgina del formulario Anotar el nmero total de pginas del formulario.
Figura 13.3. Formulario para el control de actividades
Formulario de control de tares. Este formulario se deber de utilizar en el caso de llevar un control de todas las tareas programadas para la implementacin. Elementos importantes del formulario: Elaborado por: Coordinador de Proyecto. Orientado a: Direccin CRINA. Frecuencia Recomendada: Periodos semanales de control.
Instructivo de llenado del formulario: 1. Detallar la persona que llena el Formulario, con nombres y apellidos. 134
2. Agregar la fecha de elaboracin del formulario (dd/mm/aaaa). 3. Agregar la fecha de inicio del periodo del informe (dd/mm/aaaa). 4. Agregar la fecha fin del periodo del informe (dd/mm/aaaa). 5. Detallar el nombre de la persona responsable de la tarea. 6. Anotar el correlativo de la tarea. 7. Escribir el nombre de la tarea. 8. Verificar porcentaje esperado de la tarea a la fecha. 9. Verificar porcentaje real de avance de la tarea. 10. Agregar observaciones referentes a las tareas ejecutadas. 11. Agregar nombre de la persona que revisa el formulario. 12. Agregar fecha de revisin de formulario (dd/mm/aaaa). 13. Anotar el nmero de pgina del formulario. 14. Anotar el nmero total de pginas de formulario.
Figura 13.4 Formulario para el control de tareas.
135
Formulario de control de gastos:

Este formulario se deber utilizar en caso de llevar un control de todos los gastos estimados y los gastos no previstos de la implementacin. Elementos importantes del formulario: Elaborado por: Coordinador de Proyectos Orientado a: Direccin del CRINA Frecuencia Recomendada: Periodos semanales de control.
Instructivo de llenado de formulario: 1. Detallar la persona que llena el Formulario, con nombres y apellidos. 2. Agregar la fecha de elaboracin del formulario (dd/mm/aaaa). 3. Agregar la fecha de inicio del periodo del informe (dd/mm/aaaa). 4. Agregar la fecha fin del periodo del informe (dd/mm/aaaa). 5. Detallar el nombre de la persona responsable de la actividad. 6. Anotar el correlativo de la actividad. 7. Escribir el nombre de la actividad. 8. Colocar la fecha en la que se ejecuto la actividad (dd/mm/aaaa). 9. Detallar el costo total incurrido para dicha actividad. 10. Realiza la suma total de todas las actividades que se han realizado. 11. Agregar observaciones referentes a las actividades ejecutadas. 12. Agregar nombre de la persona que revisa el formulario. 13. Agregar fecha de revisin de formulario (dd/mm/aaaa). 14. Anotar el nmero de pgina del formulario. 15. Anotar el nmero total de pginas de formulario.
136
Figura 13.5 formulario para el control de gastos
13.7.
Estrategias de Control.
Se recomienda adems de hacer uso de las herramientas de control propuesta, considerar las siguientes estrategias para mejorar en la calidad de la implementacin propuesta: Realizar el control personal de parte de los encargados de las actividades y tareas, para tener un cronograma histrico del plan de implementacin, logrando documentar cada fase, cada tarea y cada gasto de una manera constante, realizando las evaluaciones de una manera sincera y efectiva para lograr evaluar el desempeo del personal teniendo el grado de eficiencia y calidad con el que se ha desarrollado cada fase. Evaluar los resultados de los formularios con cierta frecuencia, para identificar aquellos elementos positivos y negativos que se han presentado, de tal manera que se pueda corregir aquello que genera
137
atraso o mayor costo, con esto se logra realizar una mejor ejecucin del plan propuesto y se mejoran considerablemente las actividades y tareas, minimizando los tiempos y gastos. Proponer un sistema de control alterno en el que se pueda evaluar de manera indirecta a las personas involucradas para tener un mecanismo de control en el que se pueda llevar un seguimiento de todo el plan, esto en el caso que no se lleve un control estricto por parte de los encargados siempre se podrn con otro mtodo de control de respaldo. Los elementos identificados como posibles mejoras se debern no solo detallar en un reporte, sino ms bien tratar de agregarlos al plan de implementacin para que se pongan en marcha, con el propsito de mejorar procesos y disminuir costos de tiempo y otros elementos en los que se pueda generar atrasos de ejecucin.
14. MANUALES ( Referenciarse a CD SIACE) 14.1. Manual de Usuario
Ver CD SIACE. Seccin Documentos / Manuales, opcin Manual de Usuario.
14.2.
Manual de Tcnico
Ver CD SIACE. Seccin Documentos / Manuales, opcin Manual Tcnico.
14.3.
Manual de Instalacin/Desinstalacin
Ver CD SIACE. Seccin Documentos / Manuales, opcin Manual de Instalacin- Desinstalacin
138
CONCLUSIONES
Los procesos planteados facilitaran el control de las actividades, el procesamiento de los datos y el manejo de la informacin en forma centralizada Los requerimientos plasmados en este proyecto determinan las necesidades actuales existentes en CRINA e ISRI. El diseo de la solucin desarrollada en este documento, muestra en detalle los a tres puntos esenciales del proyecto los cuales son: el sistema de administracin, la infraestructura de comunicacin y la integracin de ambos componentes. Adems del diseo de los elementos que intervienen directamente a la solucin, tambin forman parte de este otro componente necesario como lo son la seguridad y las interface con los que interactuara el usuario. El CRINA, obtendr grandes beneficios con la elaboracin de este sistema informtico, ya que se reducirn significativamente el tiempo involucrado en cada actividad del proceso actual de administracin y control de expedientes de los pacientes, y el de recoleccin de datos, as como tambin los costos asociados en el almacenamiento, ordenamiento y bsqueda de informacin. Esto agilizar la toma de decisiones, mejorando a su vez el servicio que se les brinda a las pacientes en el proceso de rehabilitacin. El desarrollo de un sistema informtico que apoye a la administracin y control de expedientes clnicos los pacientes del CRINA, es posible de realizar, dado que el anlisis de la factibilidad tcnica, econmica y operativa dan como resultado la viabilidad de su desarrollo. Adems, se cuenta con el apoyo de la Direccin del CRINA para su desarrollo y puesta en marcha. o Tcnicamente: puesto que se tiene disponible el equipo necesario para su desarrollo y produccin. o Econmicamente: ya que los beneficios alcanzados superan a los costos obtenidos y la inversin inicial ser recuperada en un perodo de tiempo razonable, es decir, 8 aos a partir de la puesta en marcha del Sistema Informtico. o Operativamente: debido a que no existe resistencia al cambio y que se cuenta con el apoyo del personal involucrado, ya que han sido stos mismos quienes han expresado la necesidad de elaborar un sistema informtico que apoye la administracin y control del expediente clnico del paciente y dar un mejor seguimiento en la rehabilitacin.
139
BIBLIOGRAFA
Libros: Kendall y Kendall, Anlisis y diseo de sistemas. Prentice Hall, Segunda Edicin. James A. Senn, Anlisis y diseo de sistemas de informacin, Mc Graw Hill, Segunda Edicin. Pressman, Roger S., Ingeniera de software, Un enfoque prctico; Mc Graw Hill, Quinta Edicin. Rodrguez de la Fuente, Prez, Carretero. UML lenguaje de modelado unificado; Editorial Thompson, 2003. Instituto Salvadoreo de Rehabilitacin de Invlidos. Normativa del Expediente Clnico Bsico; Mayo 2009 Baca Urbina, Gabriel. Formulacin y evaluacin de proyectos informticos; McGraw Hill, quinta edicin, Mxico D. F., 2006. Garca, Carlos Ernesto. Gerencia Informtica; Informatik S.A. de C.V. San Salvador; 2008 Cantone, Dante. Biblia del Programador: Implementacin y Debugging; MP Ediciones, 1a edicin, Buenos Aires, 2008 Bennett, Mc. Robb, Farmer, Anlisis y Diseo Orientado a Objetos; McGraw Hill, 3 edicin; Espaa; 2006.
Pginas Web:
www.sparxsystems.com.ar/resources/tutorial/uml2_classdiagram.html http://pear.php.net/package/PhpDocumentor/docs/1.4.0/li_phpDocumentor.html www.php.net/manual/es/control-structures.foreach.php http://argouml.tigris.org/ http://login.osirislms.com/offline/uml/ www.mspas.gob.sv/leyes.asp www.es.wikipedia.org/wiki/Aplicaciones_Web www.isri.gob.sv/contenido04/crina.html www.bcr.gob.sv www/2.ciat.org/es/bdat/docures/desc/dsv_sistema_tributario_salvador.pdf
140
GLOSARIO
A
Alta Permanente: Esta se da cuando se otorga la condicin de salida de la institucin, el paciente deja de recibir terapias en el CRINA ya sea por rehabilitacin completa o por ser mayor de edad. Cuando se emite el alta permanente por mayora de edad el paciente es referido a otra institucin. Alta Tcnica: Cuando el paciente ya no tiene la necesidad de recibir una terapia, se le otorga el alta tcnica independientemente siga recibiendo otro tipo de terapias. Alta Temporal: Esta es emitida cuando por algn motivo en particular el paciente no puede seguir recibiendo las terapias (ejemplo: enfermedad), el paciente puede reincorporarse nuevamente a las terapias aunque este es colocado en una lista de espera. Alta Voluntaria: Cuando el encargado del paciente manifiesta que no asistir ms a las terapias se le concede el alta voluntaria. Antecedentes Heredofamiliares: Es un apartado de la historia clnica (documento mdico-legal), en este apartado se preguntan al paciente si tiene parientes con enfermedades sistmicas como diabetes mellitus, hipertensin arterial sistmica, cncer, alteraciones neurolgicas, entre muchas otras, para poder darse una idea el mdico de que si su paciente est o no propenso a tener tambin alguna de estas enfermedades y crear una relacin entre el padecimiento actual del paciente y estos antecedentes. Aplicacin Web: En la ingeniera de software se denomina aplicacin web a aquellas aplicaciones que los usuarios pueden utilizar accediendo a un servidor web travs de internet o de una intranet mediante un navegador. rea Cognitiva: Para el caso en estudio es aquella que hace referencia a cmo el nio va tomando conciencia de s mismo y de su entorno, como entidades separadas. A medida que se desarrolla, sus relaciones con los objetos o las personas que le rodean se van haciendo ms complejas. Por ello, el objetivo principal de esta rea es que el nio elabore estrategias cognitivas que le permitan adaptarse a los problemas con los que se va encontrando en los primeros aos. rea Oromotora: relacionada tambin con la actividad motora, ocupa una posicin inmediatamente anterior a la circunvolucin pre-central. La estimulacin de esta rea se traduce en la aparicin de una serie de movimientos de naturaleza generalizada, como la rotacin de la cabeza, giros del tronco y movimientos generales de las extremidades.
B
Base de datos: Es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemticamente para su posterior uso. En este sentido, un ejemplo podra ser una biblioteca puede considerarse una base de datos compuesta en su mayora por documentos y textos impresos en papel e indexados para su consulta. Bipedestacin: La bipedestacin es la capacidad de locomocin y el mantenerse parado en ambos pies, propia de los seres humanos y de algunos animales.
141
C
Caso de uso: En ingeniera de software, un caso de uso es una tcnica para la captura de requisitos potenciales de un nuevo sistema o una actualizacin de software. Cada caso de uso proporciona uno o ms escenarios que indican cmo debera interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo especfico.
D
Desarrollo Psicomotor: Comprende lo referente al desarrollo del paciente como su sonrisa, sedestacin, sostn ceflico, gateo, lenguaje, control de esfnteres, escolaridad y aprovechamiento escolar. Diccionario de datos: es un conjunto de metadatos que contiene las caractersticas lgicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripcin, alias, contenido y organizacin. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de datos y auxilia a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo. Diagramas de Secuencia: Es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema. Muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada mtodo de la clase. Diseo lgico: El diseo lgico es el proceso de construir un esquema de la informacin que utiliza la empresa, basndose en un modelo de base de datos especfico, independiente del SGBD (Sistema gestor de base de datos) concreto que se vaya a utilizar y de cualquier otra consideracin fsica. Diseo Fsico: Es esquema fsico de una base de datos; es una descripcin de la implementacin de una base de datos, describiendo las estructuras de almacenamiento y los mtodos de acceso a esos datos.
E
Equipo Interdisciplinario: Grupo de profesionales en salud que se encarga de Hacer evaluaciones a los pacientes. Estudios Electrofisiolgicos: Son estudios que se realizan a aquellos pacientes que sufren de irregularidades en los latidos del corazn. (lo que se denomina arritmia). Expediente Clnico: Es un conjunto de formularios narrativos y grficos en los cuales se registran en forma detallada y ordenada las observaciones, intervenciones mdicas, teraputicas y otras atenciones en rehabilitacin.
F
Funciones Vegetativas: Referente a las funciones promotoras que intervienen en la alimentacin: succin, deglucin, masticacin, bebida, control de saliva y hbitos alimenticios.
H
Hoja de Inscripcin: Documento que contiene datos generales del paciente, de la familia y del informante; que se utiliza para la apertura del expediente.
142
Hoja de autorizacin de ingreso: Es el formulario por el cual el usuario o su responsable legal autorizan el ingreso para la atencin a (en) los centros de atencin del instituto y la puesta en prctica de aquellas medidas diagnosticas, medicas y teraputicas que los profesionales consideren oportunas.
I
Imagenologa: Conocido tambin como diagnostico por imagen es la especialidad mdica que tiene como fin el diagnstico y tratamiento de las enfermedades. Ejemplos: imagen por radiografa, ultrasonido o resonancia magntica. Indentacin: Es una tcnica informtica que se usa para detectar errores y facilitar el acomodo del programa dentro de sus variables identificando claramente cada bloque.
L
Llave primaria: Una llave primaria es un campo nico , irrepetible que sirve para identificar los registros de una tabla como distintos, adems de que sirve para hacer relaciones 1:1, 1:M , M:M (uno a uno, uno a muchos, muchos a muchos) entre tablas, sin las llaves primarias las bases de dato. Relacionales no tendran sentido y siempre existira informacin repetida. Llave fornea: Es un trmino de las bases de datos, consiste en tener en una tabla, un campo de idntico tipo y tamao al campo clave de otra tabla de la base. A travs de este campo se puede relacionar la informacin entre ambas tablas y es as como se normalizan los diseos para evitar duplicidades e inconsistencias.
M
Metadatos: Los metadatos son datos altamente estructurados que describen informacin, describen el contenido, la calidad, la condicin y otras caractersticas de los datos. Morbilidad: Es la cantidad de personas o individuos considerados enfermos o vctimas de una enfermedad en un espacio y tiempo determinados. La morbilidad es, entonces, un dato estadstico de altsima importancia para poder comprender la evolucin y avance o retroceso de una enfermedad, as tambin como las razones de su surgimiento y las posibles soluciones. Migracin de Base de datos: Hablamos de migracin de datos cuando nos referimos al traspaso de informacin entre bases de datos; es decir cambiar los datos de una base de datos a otra. Ej. Cambiar los datos que se encuentran en Access y pasarlos a Oracle.
O
Ortesis: Las ortesis (a veces llamadas rtosis) son elementos que se insertan en los zapatos para corregir formas de caminar anormales o irregulares.
P
Patologas Familiares: Patologa es la parte de la medicina que estudia las enfermedades y el conjunto de sntomas de una enfermedad. Los inconvenientes y ventajas de la familia como institucin, su oportunidad y sus disfunciones de la vida social se cataloga como patologa familiar. Pares craneales: Doce pares de nervios que salen de la cavidad craneal a travs de diferentes agujeros del crneo.
143
Praxis orales: Referente a la movilidad de los rganos fono articuladores, se utiliza para determinar si el paciente tiene inconvenientes para hablar. Permetro Ceflico: El permetro ceflico o permetro craneal es la medida del contorno de la cabeza en su parte ms grande, situado sobre las orejas y cejas. Pre-Evaluacin Tcnica: Evaluacin que el neurlogo u otro especialista realiza al paciente con el fin de determinar la condicin del mismo; de esta manera poder determinar las terapias necesarias para cada paciente. Pulsos Perifricos: Serie de ondas de la tensin arterial generadas por las sstoles del ventrculo izquierdo tal y como se registran en los miembros.
R
Resmenes Tcnicos: Documento en el que se encuentran los resmenes mdicos creados por cada terapista, en el cual se plasma la evolucin que el paciente tiene en cierto periodo de tiempo.
S
Sedestacin: Conocida tambin como posicin sentada, En esta posicin se presentan los mayores problemas aunque se considera una postura para el descanso, se ha demostrado que no es una postura tan beneficiosa pues en esta se descansan los miembros inferiores pero a la vez se transfieren las fuerzas de tensin hacia la base de la espalda afectando la columna vertebral. Servidor web: Es un programa que est diseado para transferir hipertextos, pginas web o pginas HTML (HyperText Markup Language): textos complejos con enlaces, figuras, formularios, botones y objetos incrustados como animaciones o reproductores de msica.
T
Terapia Ocupacional: El arte y la ciencia de dirigir la respuesta del hombre a la actividad seleccionada para favorecer y mantener la salud, para prevenir la incapacidad, para valorar la conducta y para tratar o adiestrar a los pacientes con disfunciones fsicas o psicosociales Triggers: Un trigger (o disparador) en una Base de datos , es un procedimiento que se ejecuta cuando se cumple una condicin establecida al realizar una operacin de insercin (INSERT), actualizacin (UPDATE) o borrado (DELETE).
U
UML: Lenguaje Unificado de Modelado (LUM) o (UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad.
144
ANEXOS
145
ANEXO 1: FORMULARIOS DEL EXPEDIENTE CLNICO.
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
ANEXO 2: EVALUACIN Y SELECCIN DEL MODELO DE CICLO DE VIDA PARA LA METODOLOGA A UTILIZAR.
Una metodologa es una versin amplia y detallada de un ciclo de vida, el cual incluye reglas, procedimientos, mtodos y herramientas. En este apartado se definen los modelos de ciclo de vida utilizados en el desarrollo de un sistema informtico, se presentan las ventajas y desventajas de cada uno de estos y se realiza una evaluacin que permite seleccionar el modelo que se acople ms a las caractersticas del sistema a desarrollar. A. Definicin de modelos de ciclo de vida. Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de desarrollo de software. Las principales diferencias entre distintos modelos de ciclo de vida estn en: El alcance del ciclo dependiendo de hasta dnde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto o su desarrollo completo. Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (dependiendo del tipo de proyecto: produccin, de servicios, etc.), o de la organizacin (inters de reflejar en la divisin en fases aspectos de la divisin interna o externa del trabajo). La estructura de la sucesin de las fases que puede ser: cascada pura, espiral, prototipo evolutivo, entrega por etapas, etc.
A continuacin se presentan los modelos de ciclo de vida ms conocidos, su definicin y caractersticas, esto permitir tener un conocimiento ms amplio de los mismos.
1. Cascada pura.
Es el ms antiguo de todos los modelos de ciclo de vida y sirve de base para otros modelos de ciclos de vida. En un modelo cascada pura un proyecto progresa a travs de una secuencia ordenada de etapas que no se sobreponen una con la otra, y el proyecto se va revisando tras cada una de las etapas. Para poder pasar a la siguiente etapa se tiene que haber conseguido todos los objetivos de la etapa anterior, es un proceso secuencial. Tiene una buena aplicacin cuando el problema es estable y cuando se trabaja con metodologas y tcnicas conocidas. Este modelo ser apropiado para la migracin de una aplicacin a otra. En la siguiente figura podemos observar los pasos que comprenden este ciclo de vida y la relacin entre cada uno de ellos:
187
Investigacin Preliminar Anlisis de Requerimientos Diseo Global Diseo Detallado Codificacin y Depuracin Prueba del Sistema
Figura 2.1. Etapas del Ciclo de Vida Cascada Pura
Con este modelo se tiene un seguimiento de todas las etapas del proyecto, lo que permite el correcto cumplimiento de cada una de las etapas y el cumplimiento de todos los objetivos marcados en cada etapa tanto de costes, fecha de entrega y lo ms importante que pueden comprobar al final de cada etapa si el proyecto cumple todas las necesidades del usuario.
2. Espiral
El modelo de la espiral es un modelo orientado a riesgo que divide el proyecto software en mini proyectos. Cada proyecto se encargar de resolver uno o varios riesgos hasta que estn todos controlados. Una vez que estn los riesgos ms importantes controlados se finaliza igual que el ciclo de vida en cascada pura; riesgo se refiere a requerimientos poco comprensibles, importantes tecnologas poco conocidas, software con mayor experiencia en el uso. En el ciclo de vida en espiral se localizan los riesgos, se genera un plan para manejarlos y se establece una aproximacin a la siguiente iteracin. Con cada iteracin se produce una aproximacin al producto final. En el modelo en espiral se comienza con una parte pequea del proyecto y se expande tras reducir los riesgos para la siguiente iteracin. Los pasos que comprenden este modelo se representan en el siguiente diagrama:
3. Evaluar las alternativas 2 Identificar y resolver riesgos. 4. Generar entregas de esta iteracin, y comprobar que son correctas.
1. Determinar objetivos, alternativas y lmites.
5. Planificar la siguiente iteracin.
Figura 2.2. Etapas del Ciclo de Vida en Espiral
188
En este modelo las primeras iteraciones son menos costosas y a medida que se avanza aumenta el coste. Las ventajas de este modelo son:

Se disminuyen los riesgos. Al final de cada iteracin se obtienen los puntos de verificacin. Se obtienen con anterioridad indicaciones de cualquier riesgo insuperable.
Las desventajas de este modelo son:

Un aumento de costes. Es un modelo complicado de llevar a cabo porque exige una gestin concienzuda, atenta y unos conocimientos profundos.
3. Prototipo Evolutivo
Modelo de ciclo de vida desarrollado a base de incrementos de acuerdo a la realimentacin y los requerimientos detectados en sus versiones. A diferencia de otros modelos en el prototipado evolutivo no se desecha el cdigo fuente, el cual es finalmente entregado. Se utiliza cuando los requerimientos cambian con rapidez, cuando el cliente es contrario a facilitar los requerimientos y especificaciones o cuando no est clara la forma del rea de aplicacin.
Los pasos que representan este modelo se muestran en el siguiente diagrama:

Concepto del Software Anlisis Preliminar de Requerimientos Diseo Global y del ncleo del sistema Desarrollar una versin Entregar la versin final
Incorporar la realimentacin del cliente
Entregar la versin
Deducir la realimentacin del cliente
Figura 2.3 Etapas del Ciclo de Prototipado Evolutivo
Las ventajas de este modelo son:

Se generan signos visibles de progreso. Permite la modificacin sobre la marcha. 189
El cliente se va familiarizando con el nuevo entorno.
Y las desventajas de este modelo son:

Imposibilidad de conocer a priori el tiempo de desarrollo. La aproximacin puede convertirse en excusa para realizar el desarrollo con el modelo de codificar y corregir.
4. Entrega por etapas

En este modelo se evita el problema del modelo en cascada pura de no terminar ninguna etapa del modelo hasta que est completamente finalizado. Tras el diseo global se puede implementar y entregar la aplicacin en etapas. La diferencia de este modelo con el prototipo evolutivo es que en este modelo conocemos exactamente qu es lo que se va a construir. Este modelo funciona exactamente igual que el de cascada pura en las tres primeras fases y en el diseo detallado se divide por etapas, el funcionamiento de los pasos de este modelo se representa en el siguiente diagrama:
Conocer la Problemtica Anlisis de Requerimientos
Diseo Global
Etapa 1: Diseo detallado, construccin, depuracin, pruebas y entrega. Etapa 2: Diseo detallado, construccin, depuracin, pruebas y entrega.
Etapa n: Diseo detallado, construccin, depuracin, pruebas y entrega.
Figura 2.4 Etapas del Ciclo de Entrega por Etapas
Ventajas de este modelo:

Permite proporcionar una funcionalidad til en manos del cliente sin tener la aplicacin finalizada. Proporciona signos tangibles de progreso.
Desventajas de este modelo:
Su principal inconveniente es que este modelo no es viable sin una planificacin adecuada. 190
C. Comparacin de las caractersticas del sistema a realizar respecto a las caractersticas de los diferentes modelos de ciclo de vida. A continuacin se realiza una comparacin entre las caractersticas que poseen los modelos de ciclo de vida objetos de estudio, con las caractersticas que posee el proyecto a desarrollar, esto con la finalidad de identificar que caractersticas propias del sistema se ajustan a las de cada modelo de ciclo de vida y hacer un previo anlisis para la evaluacin y seleccin del modelo de ciclo de vida.
Modelo de ciclo de vida Caractersticas del Ciclo de vida No Permite yuxtaposicin ya que poder pasar a de una etapa a otra se requiere haber finalizado la anterior. Cascada pura Requiere un Seguimiento preciso de cada una de las etapas Requiere del conocimiento sobre la metodologa y tcnicas que se utilizaran en el desarrollo del proyecto. Divide el proyecto en mini proyectos es decir realiza iteraciones. Espiral Planifica riesgos en cada iteracin. Aumento del costo en cada iteracin. Prioriza en el Diseo y construccin de ms importantes del proyecto. las partes Los requerimientos del usuario son estables ya que estos tiene bien definidas sus necesidades. Caracterstica del proyecto. Se realiza un seguimiento preciso de las etapas del proyecto. Ya que se tiene un previo conocimiento de las metodologas y tcnicas a aplicar durante su desarrollo. Se conocen los requerimientos de los usuarios ya que estos tienen bien definidas sus necesidades.
El proyecto cuenta con asignacin de costos para su desarrollo por lo que no se puede exceder en el aumento de estos.
Prototipo evolutivo
Maneja requerimientos inestables cambian con rapidez. Requiere poca sofisticacin para los directivos y desarrolladores.
Entrega por etapas
Permite el inicio de una etapa sin haber terminado la anterior. Conocimiento claro del proyecto a construir No requiere planificacin del proyecto.
Se tiene un conocimiento claro del proyecto a construir ya que se ha realizado una investigacin previa.
Codificar y corregir
No necesita experiencia ni cantidad de conocimiento. No requiere anlisis ni diseo detallado, se codifica y realiza pruebas informales.
El proyecto a construir se administra a travs de una planificacin de tiempo y recursos adecuada.
Tabla 2.2. Comparacin de las caractersticas del proyecto para del CRINA vs. Las caractersticas de los modelos de ciclo de vida.
D. Evaluacin de las modelos de ciclo de vida. Para seleccionar el modelo de ciclo de vida, se utilizar un proceso que permita tomar la decisin en base a criterios, que como grupo de desarrollo se han establecido y que se consideran necesarios para alcanzar el xito en este proyecto.
191
Codificacin de las metodologas

Cdigo CP ES PE EE Nombre del modelo de ciclo de vida Cascada Pura Espiral Prototipo evolutivo Entrega por etapas
Tabla 2.3. Codificacin de las metodologas
1. Evaluacin a. Valoracin de Criterios. La ponderacin de cada criterio se establece de manera individual asignndoles un valor de importancia, dentro de una escala de 1-3, cuya interpretacin se muestra a continuacin:
Nivel Requerido Importante No requerido Peso 3 2 1
b. Definicin de criterios. Criterios para la seleccin de modelos de ciclo de vida, en base a experiencias del grupo de desarrollo.
Cdigo V1 V2 V3 V4 V5 V6 Criterios Valorados Conocimiento del modelo de ciclo de vida Permite interaccin con el usuario Documentacin del modelo de ciclo de vida Requiere poca sofisticacin para los directivos y desarrolladores Requiere planificacin formal Soporta cambios en los requerimientos Peso Asignado 3 3 2 2 3 3
Tabla 2.5. Criterios de Evaluacin c. Calificacin de modelos de ciclo de vida. La calificacin que a cada modelo de ciclo de vida se le asignar por medio de los criterios valorados, se hace en el previo conocimiento que se tiene como grupo y en base a informacin bibliogrfica consultada utilizando los valores que se muestran en la Tabla de Criterios de Evaluacin Cada calificacin a un criterio se multiplica por el peso estipulado en el de Valoracin de Criterios (asignacin de pesos) al final se suman los resultados para los criterios por modelo de ciclo de vida. 192
Nivel Nada Poco Suficiente
Peso 0 5 10
Tabla 2.6. Valoracin para la calificacin de criterios.
Calificacin asignada por grupo de trabajo.

Metodologas CP ES PE EE Criterios V1 10 0 0 10 V2 10 5 10 10 V3 10 10 5 10 5 0 5 10 V4 V5 10 5 10 10 5 10 10 10 V6
Tabla 2.7. Tabla de Asignacin de Calificacin.
Evaluacin de los criterios de acuerdo a la calificacin asignada.

Pesos Metodologas V1 3 CP ES PE EE 30 0 0 30 V2 3 30 15 30 30 V3 2 30 30 15 30 V4 2 15 0 15 30 V5 3 30 15 30 30 V6 3 15 30 30 30 150 90 120 180 Peso Total
Tabla 2.8. Tabla de Matriz de Evaluacin.
D. Seleccin del modelo de ciclo de vida. En base a los resultados obtenidos en la evaluacin realizada a los modelos de ciclos de vida, la que mejor se adapta al desarrollo del proyecto es el modelo de Entrega por Etapas, ya que este tuvo un peso total mayor en comparacin con los dems modelos en evaluacin.
193
ANEXO # 3.: EVALUACIN Y SELECCIN DE TECNOLOGAS DE DESARROLLO.

Antes de seleccionar el software que nos ayudara a desarrollar la solucin propuesta, se realiz una evaluacin tcnica de productos de software que presentar caractersticas y atributos similares. En el caso del proyecto Sistema Informtico para la Administracin y Control de Expedientes del CRINA, la evaluacin del gestor de base de datos y lenguaje de programacin solo podr realizarse entre tecnologas de licenciamiento libre, debido a las limitaciones establecidas por dicha organizacin. Para poder realizar una evaluacin y seleccin objetiva sobre las tecnologas candidatas a utilizar se tomado como base el proceso de evaluacin para el desarrollo y adquisicin de software propuesto en la parte 3 de la Gua tcnica sobre evaluacin de software para la Administracin Pblica, publicada en Lima, Per en mayo de 2004. Est basada sobre la norma ISO/IEC 9126 de la ISO (Organizacin Internacional de Estandarizacin) y IEC (Comisin Electrnica Internacional) que forman el sistema especializado para la normalizacin internacional. Al realizar una investigacin sobre los mtodos de evaluacin de software se pudo observar que esta gua ha sido utilizada en una serie de evaluaciones de software realizadas por distintas instituciones, adems esta gua presenta documentacin que indica paso a paso la forma de realizar la evaluacin, en base a los antes expuesto se determin utilizar dicha gua. El proceso para la evaluacin ser el siguiente: 1. 2. 3. 4. 5. 6. 7. 8. Establecer el propsito de la evaluacin Identificar el producto que ser evaluado Especificar el modelo de calidad a utilizar Seleccionar mtricas Establecer niveles de escala para cada mtrica Establecer criterios de evaluacin Tomar medidas y comparar criterios Valorar resultados
Propsito de la evaluacin: Determinar cul ser la herramienta de software idnea para desarrollar el proyecto Sistema informtico para la Administracin y Control de Expedientes del CRINA. Producto a ser evaluado:
Gestor de Base de Datos Firebird 2.1 PostgreSQL MySql Lenguaje de Programacin PHP Phyton JSP
Tabla 3.1 Productos a ser evaluados.
Entorno de Desarrollo NotePad Dreamweaver CS3 Eclipse
194
Seleccin de modelo de calidad: Se utilizara el descrito en la parte 1 de la Gua Tcnica Sobre Evaluacin de Software para la Administracin Pblica. 1. Calidad Interna: especifican el nivel de calidad requerido desde la perspectiva interna del producto. Los requerimientos de calidad internos son usados para especificar propiedades internas de productos. Estos pueden incluir modelos estticos y dinmicos, otros documentos y cdigo fuente. Los requerimientos de calidad internos pueden ser usados como objetivos para la validacin en varias etapas de desarrollo. Ellos tambin pueden ser usados para definir estrategias de desarrollo y criterios de evaluacin y verificacin durante el desarrollo. Esto puede incluir el uso de mtricas adicionales (por ejemplo: reusabilidad). Los requerimientos especficos de calidad interna deben ser especificados cuantitativamente usando mtricas internas. 2. Calidad Externa: es la totalidad de las caractersticas del producto de software desde una perspectiva externa. Es la calidad cuando el software es ejecutado, la cual es tpicamente medida y evaluada en un ambiente simulado, con datos simulados y usando mtricas externas. Durante las pruebas, muchas fallas sern descubiertas y eliminadas. Sin embargo, algunas fallas todava pueden permanecer despus de las pruebas. Como es difcil corregir la arquitectura del software u otros aspectos fundamentales del diseo del software, el diseo fundamental permanece sin cambios a travs de las pruebas. 3. Calidad de Uso: es la perspectiva del usuario de la calidad del producto de software cuando ste es usado en un ambiente especfico y en un contexto de uso especfico. Esta mide la extensin en la cual los usuarios pueden conseguir sus metas en un ambiente particular, en vez de medir las propiedades del software en s mismo. Seleccin de mtricas: Las mtricas a utilizar dependern del producto evaluado. Para este caso, se utilizaran las siguientes: 1. Mtricas Internas 2. Mtricas Externas 3. Mtricas de Uso Mtricas Internas: miden atributos internos a travs del anlisis de las propiedades intrnsecas de productos de software. Las mtricas internas proporcionan el beneficio de poder evaluar la calidad del producto de software y lo referido a problemas de calidad antes de que el software sea puesto en marcha. Mtricas Externas: usan medidas de un producto de software, derivadas del comportamiento del mismo, a travs de la prueba, operacin y observacin del software. Las mtricas externas proporcionan el beneficio de poder evaluar la calidad del producto de software durante las pruebas o el funcionamiento del mismo. Mtricas de Uso: miden la extensin de un producto que rene las necesidades especificadas por los usuarios para lograr las metas propuestas, con la efectividad, productividad, seguridad y satisfaccin en un contexto de uso especfico.
195
Establecer niveles de escala para cada mtrica: En cada uno de los productos de software a evaluar, en sus diferentes criterios se le asignara una puntuacin dependiendo del grado de su cumplimiento. La puntuacin de cada criterio debe de ser establecida de manera individual y esta debe de ir vinculada a un factor de importancia dentro de una escala, para el desarrollo de las diferentes evaluaciones se har uso de 2 escalas, las cuales contendrn valores enteros, difiriendo entre ellas su mximo valor, el cual define el nivel de importancia de dicho criterio. A continuacin se presenta el significado estos valores mximos para cada una de las escalas.
Valor 10 5 Factor de Importancia Muy Importante Importante Tabla 3.2. Puntuacin de las mtricas.
A continuacin se presentan la definicin de ambas escalas. Escala de calificaciones para criterios muy importantes.
Valor 10 8 5 1 Significado Cumple en su totalidad con el criterio del equipo de desarrollo para su uso Cumple aceptablemente con el criterio de del equipo de desarrollo para su uso Cumple mnimamente con el criterio del equipo de desarrollo para su uso No cumple con el criterio del equipo de desarrollo para su uso. Tabla 3.3. Escala de calificaciones para cumplimiento de criterio muy importante
Escala de calificaciones para criterios importantes.

Valor 5 3 1 Significado Cumple en su totalidad con el criterio del equipo de desarrollo Cumple mnimamente con el criterio del equipo de desarrollo No cumple con el criterio del equipo de desarrollo
Tabla 3.4. Escala de calificaciones para cumplimiento de criterio importante
Para la definicin de cada una de estas escalas, se ha optado por elegir valores intermedios, esto para hacer ms fiable el proceso de evaluacin, ya que usar valores contiguos no se lograra hacer diferenciacin clara entre cada entre cada una de las herramientas a evaluar.
196
1. EVALUACION DE SISTEMAS GESTORES DE BASE DE DATOS.

Para la realizacin de la evaluacin de los sistemas gestores de bases de datos se han tomado en cuenta solo aquellos gestores open source que presentan un fuerte respaldo en documentacin y en comunidades de desarrolladores, con lo que se busca tener apoyo para la solucin de problemas que se pueden presentar en la etapa de desarrollo, por lo que solamente se han dejado a sujeto de estudio los siguientes gestores de bases de datos:
1.1 Firebird 2.1

Es un sistema de administracin de base de datos relacional de cdigo abierto multiplataforma, basado en la versin 6 de Interbase, cuyo cdigo fue liberado por Borland, es distribuido bajo las licencias IPL e IDPL. Existen dos tipos de arquitecturas de servidor Firebird para ser instalados: Classic y Superserver. Si bien tienen varias diferencias menores entre s, la principal consiste en que el superserver maneja hilos de ejecucin individuales para cada conexin. Por lo tanto para un nmero reducido de conexiones el recomendado sera el classic porque consumir menor cantidad de recursos. Para realizar trabajos bajo Windows la opcin recomendada es Superserver, mientras que para plataformas Linux puede usarse cualquiera de las dos, en este caso la eleccin depende del nmero de conexiones que se utilizaran. Algunas de las caractersticas de Firebird son las siguientes:

Completo soporte para Procedimientos Almacenados y Disparadores Integridad Referencial Bajo consumo de recursos Completo lenguaje interno para procedimientos almacenados y disparadores (PSQL) Poca o ninguna necesidad de DBAs especializados. Prcticamente no requiere configuracin Docenas de herramientas de terceros, como herramientas de administracin grficas, herramientas de replicacin, etc. Muchas formas de acceder a la base de datos: nativo/API, drivers dbExpress, ODBC, OLEDB, proveedor .Net, driver JDBC nativo tipo 4, mdulo Python, PHP, Perl, etc. Tablas de Monitoreo
Sistema Operativo Procesador Memoria Espacio en Disco Duro Multiplataforma 300 MHz 128 MB RAM 10 MB
Tabla 3.5. Requerimientos mnimos del gestor de base de datos Firebird.
197
1.2 Postgrade SQL

PostgradeSQL es un Sistema de Gestin de Bases de Datos Objeto-Relacionales multiplataforma publicado bajo la licencia BSD. PostgradeSQL es un sistema manejador de bases de datos relacionales que presenta una arquitectura donde el cliente y el servidor de la base de datos interactan por medio del clsico modelo cliente-servidor mientras que el acceso a los datos es por medio de capas. La interaccin entre el cliente y el servidor es de peticin respuesta y cada cliente recibe un hilo del servidor de base de datos y cada uno de esos hilos accesa a un Sistema de Administracin de Datos Compartidos. El procesamiento de las consultas es pipeline (segmentado), mientras que el acceso a la base de datos por parte de los sub procesos del servidor tiene una estructura bulletin board (tabln de anuncio o BBS). Este programa para la gestin de bases de datos es uno de los ms usados por los programadores, ya que permite gestionar las bases de datos de forma profesional y muy intuitiva, adems cuenta con el soporte de varias herramientas graficas desarrolladas por terceros. Algunas de sus principales caractersticas son: Implementa las directrices del estndar ANSI/SQL. Procesa las transacciones utilizando el esquema Multi-Version Concurrency Control Implementa integridad referencial Soporta mltiples lenguajes procedimentales: pgSQL - SQL Procedural Language. Perl - Perl Procedural Language Python - Python Procedural Language Soporta tipos de datos nicos: Geomtricos: puntos, lneas, polgonos, crculos, etc. Lgicos Compuestos Es extensible: se pueden implementar nuevos tipos de datos, funciones, operadores, y lenguajes.
Requerimientos Mnimos Sistema Operativo Procesador Memoria Espacio en Disco Duro Multiplataforma 300 MHz 128 MB RAM 100 MB
Tabla 3.6. Requerimientos mnimos del gestor de base de datos Posgrade SQL
198
1.3 MySQL
MySQL es un sistema de gestin de base de datos relacional multiplataforma, multihilo y multiusuario, distribuido bajo un sistema de licenciamiento dual, que por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia especfica que les permita este uso. Este sistema es muy utilizado en aplicaciones web, en varias plataformas (Linux/Windows-ApacheMySQL-PHP/Perl/Python). MySQL es una base de datos muy rpida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificacin. En aplicaciones web hay baja concurrencia en la modificacin de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones.
A continuacin se destacan algunas de las caractersticas principales de MySQL: Soporta Procedimientos almacenados, triggers, cursores y vistas actualizables. Aprovecha la potencia de sistemas multiprocesador, gracias a su implementacin multihilo. Dispone de API's en gran cantidad de lenguajes (C, C++, Java, PHP, etc.). Gran portabilidad entre sistemas. Proporciona sistemas de almacenamiento, transaccionales y no transaccionales. Joins muy rpidos usando un multi-join de un paso optimizado. Las funciones SQL estn implementadas usando una librera altamente optimizada y deben ser tan rpidas como sea posible. Flexible sistema de contraseas (passwords) y gestin de usuarios, con un muy buen nivel de seguridad en los datos. El servidor soporta mensajes de error en distintos idiomas.
Requerimientos Mnimos Sistema Operativo Procesador Memoria Espacio en Disco Duro Multiplataforma 400 MHz 256 MB RAM 200 MB
Tabla 3.7. Requerimientos mnimos del gestor de base de datos MySQL.
En la tabla presentada a continuacin se encontrar la comparacin de las caractersticas y propiedades de los Gestores de Bases de Datos sujetos a evaluacin.
199
Propiedades Fabricante Licencia
FireBird Firebird Project IPL, IDPL Linux, Solaris, HP-UX, MacOs, AIX, SCO, IRIX, FreeBSD, NetBSD, OpenBSD, Windows, BSDI, DEC, OS/2 ODBC, JDBC, C/C++, .NET/Mono, ADO.Net, OLEDB, Delphi, Perl, Python, PHP Si Alta Si Media --Si No Si Si Si Si Si Ilimitado Aprox 32 TB (Tera) 65,536 Bytes Depende del tipo de dato usado
PostgreSQL PostgreSQL Global Development Group BSD Linux, Solaris, HP-UX, AIX, IRIX, FreeBSD, OpenBSD, NetBSD, MacOs, SCO OpenServer, SCO Unixware, BeOS, BSDI, Windows
MySQL Sun Microsystems GNU/GPL comercial
Plataformas (Sistema Operativo)
Linux, Solaris, freeBSD, HP-UX, MacOS, Windows
Interfaces de programacin (Lenguajes Soportados) Cumplimiento del Estndar SQL Estabilidad Integridad de los datos Seguridad Mtodos de autenticacin soportados Vistas Esquemas Subconsultas Procedimientos almacenados Triggers Herramientas Graficas Manejo de Transacciones Mximo tamao de la BD Mximo Tamao de tabla Mximo tamao de la fila Mximo de columnas por fila
ODBC, JDBC, C/C++, Embeded ODBC, JDBC, C/C++, PHP, SQL (in C), Tcl/Tk, Perl, Python, Perl, Kylix, Delphi, Python, PHP .NET/Mono, ADO
Si Alta Si Alta A travs de md5, crypt, password y Kerberos Si Si Si Si Si Si Si Ilimitado 32 TB 1.6 TB Depende del tipo de dato usado
Si (parcialmente) Alta Si Alta A travs de SHA1 Si Si Si Si Si (rudimentario) Si Si Ilimitado 2 GB 64 KB 4096 columnas
Tabla 3.8. Comparacin de las caractersticas de los diferentes gestores de bases de datos.
200
Tabla de anlisis comparativo para los Gestores de Bases de Datos Descripcin de mtricas con sus respectivos niveles de escala para la evaluacin del Gestor de Bases de Datos (GBD). Establecidos a criterio del equipo evaluador.
Mtrica Interno Facilidad de Instalacin Multiplataforma Tolerancia a errores Utilizacin adecuada de recursos Soporte para interfaces de programacin Soporte del estndar SQL Posee un programa asistente de instalacin el cual realiza la instalacin de los componentes de manera automtica. Es funcional en diversos sistemas operativos Grado en que mantiene su funcionamiento cuando ocurren fallos Uso eficiente del CPU y de la memoria al momento en que se realizan operaciones de consultas o transacciones en la BD Capacidad de trabajar con diferentes tecnologas de desarrollo Soporta en su totalidad el lenguaje SQL para la realizacin de consultas El gestor posee una amplia trayectoria con la que puede considerarse libre de fallas como resultado de errores en el SW. 5 5 10 5 Descripcin Puntaje
10
Madurez Externo Documentacin (Aprendizaje)
Facilidad para que el usuario se capacite con respecto al uso del gestor a travs de documentacin, soporte en lnea, foros, etc. El gestor es fcil de administrar con los conocimientos que posee el equipo de desarrollo. El gestor puede ser actualizado a travs de complementos o remplazado por nuevas versiones.
Facilidad de Administracin
10
Actualizacin de software de Uso Manejo de grandes volumen de informacin (Eficacia) Tiempos de respuesta breves en ejecucin en consultas, procedimientos y funciones Herramientas Graficas Seguridad de la base TOTAL
Capacidad de trabajar adecuadamente con grandes volmenes de informacin Proporciona tiempos resultados en tiempos ms cortos con respecto a otros gestores posee soporte para varias herramientas graficas El nivel de proteccin que ofrece ante usuarios no autorizados
10
10
5 10 100
Tabla 3.9. Anlisis comparativo de los gestores de base de datos.
201
Anlisis Tcnico Comparativo de los Gestores de Bases de Datos

Mtrica Interno Facilidad de Instalacin Multiplataforma Tolerancia a errores Utilizacin adecuada de recursos Soporte para interfaces de programacin Soporte del estndar SQL Madurez Externo Documentacin Facilidad de Administracin Actualizacin de software de Uso Manejo de grandes volumen de informacin Tiempos de respuesta breves en ejecucin en consultas, procedimientos y funciones Herramientas Graficas Seguridad de la base PUNTAJE TOTAL 5 10 5 5 5 5 5 5 5 5 10 5 5 5 10 5 5 5 5 5 5 5 8 5 5 5 8 5 Puntaje Mximo FireBird 2.1 PostgreSQL 8.x MySQL 5
5 10 5
5 10 5
5 10 5
5 10 5
10
10
10
10 5 10 100
5 5 5 80
8 5 10 91
8 5 8 92
Tabla 3.10. Anlisis tcnico comparativo de los gestores de Bases de datos
Al realizar la evaluacin de los gestores de bases de datos, se determina que la mejor opcin a utilizar para el desarrollo del proyecto es MySQL, debido a que este gestor soporta un gran volumen de informacin, soporta adems el estndar SQL, sus tiempos de respuesta son buenos, la seguridad del gestor es adecuada y posee amplia documentacin y comunidades de desarrollo en donde se puede encontrar la solucin a los problemas ms diversos. 202
2. EVALUACIN DE LENGUAJES DE PROGRAMACIN

Para la realizacin de la evaluacin de los lenguajes de programacin se han tomado en cuenta solamente lenguajes de script a nivel de servidor que su intrprete sea gratuito y que cuenten con una amplia documentacin y soporte por parte de varias comunidades de programacin, con lo que se busca tener apoyo para la solucin de problemas que se pueden presentar en la etapa de desarrollo, por lo que solamente se han dejado a sujeto de estudio los siguientes lenguajes: 2.1 PHP 5 PHP, es un lenguaje interpretado de propsito general ampliamente usado y que est diseado especialmente para desarrollo Web y puede ser incrustado dentro de cdigo HTML. La implementacin principal de PHP es producida ahora por The PHP Group y sirve como el estndar de facto para PHP al no haber una especificacin formal y se distribuye bajo la licencia PHP License 3.0, que es considerada por la Free Software Foundation como licencia de software libre. Generalmente se ejecuta en un servidor Web, tomando el cdigo en PHP como su entrada y creando pginas Web como salida. Puede ser desplegado en la mayora de los servidores Web y en casi todos los sistemas operativos y plataformas. PHP no necesita ser compilado para ejecutarse. Para su funcionamiento necesita tener instalado Apache o IIS con las libreras de PHP. La mayor parte de su sintaxis ha sido tomada de C, Java y Perl con algunas caractersticas especficas. PHP, est diseado especficamente para ser un lenguaje ms seguro para escribir programas CGI que Perl o C, y con la seleccin correcta de opciones de configuracin en tiempos de compilacin y ejecucin, y siguiendo algunas prcticas correctas de programacin. Algunas de las caractersticas que presenta este lenguaje son las siguientes: Muy fcil de aprender. Es un lenguaje muy rpido. Soporta en cierta medida la orientacin a objeto. Clases y herencia. Capacidad de conexin con la mayora de los manejadores de base de datos: MySQL, PostgreSQL, Oracle, MS SQL Server, entre otras. Capacidad de expandir su potencial utilizando mdulos. Posee documentacin en su pgina oficial la cual incluye descripcin y ejemplos de cada una de sus funciones. Incluye gran cantidad de funciones.
Algunos de los inconvenientes del lenguaje son las siguientes: La legibilidad del cdigo puede verse afectada al mezclar sentencias HTML y PHP. La programacin orientada a objetos es an muy deficiente para aplicaciones grandes. Dificulta la modularizacin. Dificulta la organizacin por capas de la aplicacin.
203
Requerimientos Mnimos Sistema Operativo Procesador Memoria Espacio en Disco Duro Software requerido Multiplataforma 300 MHz 128 MB RAM 50 MB Servidor que incorpore los mdulos necesarios para su ejecucin Tabla 3.11 Requerimientos mnimos de PHP.
2.2. Python 3.1.2 Es un lenguaje de programacin creado en el ao 1990 por Guido van Rossum, es el sucesor del lenguaje de programacin ABC. Python es comparado habitualmente con Perl. Los usuarios lo consideran como un lenguaje ms limpio para programar. Permite la creacin de todo tipo de programas incluyendo los sitios Web.
A continuacin se mencionan algunas caractersticas que posee el lenguaje: Libre y fuente abierta Lenguaje de propsito general Gran cantidad de funciones y libreras Multiplataforma Algunos de los inconvenientes del lenguaje son los siguientes: Lentitud por su lenguaje interpretado
Requerimientos Mnimos Sistema Operativo Procesador Memoria Espacio en Disco Duro Software Requerido Multiplataforma 400 MHz 128 MB RAM 500 MB Servidor que incorpore los mdulos necesarios para su ejecucin
Tabla 3.12 Requerimientos mnimos de Python.
204
2.3. JSP Es un lenguaje para la creacin de sitios Web dinmicos, es un lenguaje multiplataforma desarrollado por Sun Microsystems creado para ejecutarse del lado del servidor. Est desarrollado para la creacin de aplicaciones Web potentes. Para su funcionamiento se necesita tener instalado un servidor Tomcat. Est orientado a desarrollar pginas Web en Java. Permiten la utilizacin de cdigo Java mediante scripts. Adems, es posible utilizar algunas acciones JSP predefinidas mediante etiquetas. Estas etiquetas pueden ser enriquecidas mediante la utilizacin de Libreras de Etiquetas (TagLibs o Tag Libraries) externas e incluso personalizadas. La principal ventaja de JSP frente a otros lenguajes, es que el lenguaje Java es un lenguaje de propsito general que excede el mundo Web y que es apto para crear clases que manejen lgica de negocio y acceso a datos de una manera prolija. Esto permite separar en niveles las aplicaciones Web, dejando la parte encargada de generar el documento HTML en el archivo JSP. Otra ventaja es que JSP hereda la portabilidad de Java, y es posible ejecutar las aplicaciones en mltiples plataformas sin cambios. Es comn incluso que los desarrolladores trabajen en una plataforma y que la aplicacin termine siendo ejecutada en otra. Algunas de las caractersticas del lenguaje son las siguientes: El cdigo JSP puede ser incrustado en cdigo HTML. Sirve para crear y gestionar pginas Web dinmicas. Las pginas son cargadas en la primera peticin. Su objetivo final es separar la interfaz (presentacin visual) de la implementacin (lgica de ejecucin). Para programar con instrucciones JSP no se necesita compilar, lo que lo hace ms rpido. Existe una gran comunidad de Java pero ms orientada a aplicaciones que a Web Permite obtener un buen rendimiento y escalabilidad. Algunos de los inconvenientes del lenguaje son los siguientes: No es muy adecuado su uso para realizar proyectos escalables, aadiendo mdulos,etc. Complejidad de aprendizaje. La manera de escribir los programas es ms rgida.
Requerimientos Mnimos Sistema Operativo Procesador Memoria Espacio en Disco Duro Software Requerido Multiplataforma 300 MHz 256 MB RAM 300 MB JavaServer Web Development Kit (JSWDK) Servidor Apache Tomcat
Tabla 3.13 Requerimientos mnimos de JSP.
205
Comparacin de las caractersticas y propiedades de los lenguajes de programacin sujetos a evaluacin.

Propiedades Fabricante Licencia Sistema Operativo Dificultad de aprendizaje Rendimiento JSP Sun Microsystems GNU/GPL Multiplataforma Relativamente alta Consume muchos recursos Python Python.org Python Software Foundation License Multiplataforma Poca Consume muchos recursos PHP The PHP Group PHP License 3.01 Multiplataforma Poca Consume pocos recursos Optimo (parcialmente) MS SQL Server, Dbase, Oracle, Informix, Sybase, MySQL, FireBird, Postgre Muy Buena Rpida al usar un Framework Si No (aun falta madurez) SI
Deteccin de errores
No es optimo
Optimo
Bases de Datos soportadas
MS SQL Server, Dbase, Oracle, Informix, MySQL, FireBird, Postgre
MS SQL Server, Oracle, MySQL, FireBird
Seguridad Velocidad de desarrollo Herramientas para desarrollo Gratuitas Soporte para OO Soporte y documentacin
Muy Buena Relativamente Lento por la complejidad del lenguaje Si
Buena Rpido por el uso de controles y bibliotecas predefinidas Si
Si
Si
Si
Si
Tabla 3.14 Comparacin de los lenguajes de programacin evaluados.
206
Tabla de anlisis comparativo para los lenguajes de programacin. Descripcin de mtricas con sus respectivos niveles de escala para la evaluacin de lenguajes de programacin. Establecidos a criterios del equipo evaluador.
Mtrica Interno Facilidad de Instalacin Multiplataforma Utilizacin adecuada de recursos La instalacin del intrprete del lenguaje de programacin se realiza de forma automtica. El lenguaje es funcional en diversos sistemas operativos. Uso eficiente de los recursos del PC al momento de ejecutar los scripts. 5 5 10 Descripcin Puntaje Max
Amplitud de sintaxis (que posee La sintaxis de lenguaje posee una amplia gama de funciones que bastantes funciones) permiten realizar diferentes operaciones El lenguaje de programacin posee una amplia trayectoria con la que puede considerarse libre de fallas como resultado de errores en el desarrollo de software. Estabilidad tras la incorporacin de mdulos al intrprete del lenguaje. El cdigo debe de ser visualizado por quienes estn autorizados Los scripts proporcionan los resultados que se esperan
10
Madurez
Estabilidad tras actualizaciones Seguridad Exactitud durante su ejecucin Externo Facilidad de comprensin
5 10 10
El lenguaje de programacin es fcil de implementar con los conocimientos que posee el equipo de desarrollo Facilidad para que el usuario se capacite con respecto al lenguaje de programacin a travs de documentacin, soporte en lnea, comunidades, etc.
Documentacin (Aprendizaje)
10
de Uso Uso adecuado de lneas de cdigo (Productividad) Eficacia del lenguaje Trabaja en diferentes entornos de desarrollo TOTAL
Tabla 3.15 Tabla de anlisis comparativo de los lenguajes de programacin.
El lenguaje de programacin permite al usuario programar las diferentes operaciones con un nmero de lneas de cdigo mnimo El lenguaje de programacin debe de lograr lo propuesto El lenguaje puede utilizarse en diferentes entornos de desarrollo lo que permite al usuario elegir el que ms le convenga
10
10 5 100
207
Anlisis Tcnico Comparativo de los Lenguajes de Programacin.

Mtrica Interno Facilidad de Instalacin Multiplataforma Utilizacin adecuada de recursos Amplitud de sintaxis Madurez Estable tras actualizaciones Seguridad en el cdigo Exactitud durante su ejecucin Externo Facilidad de comprensin Documentacin de Uso Uso adecuado de lneas de cdigo Eficacia del lenguaje Trabaja en diferentes entornos de desarrollo PUNTAJE TOTAL 10 10 5 100 8 10 5 94 8 10 5 87 8 10 5 82 5 10 5 10 3 10 5 10 5 5 10 10 5 5 10 10 5 5 10 8 5 5 8 10 5 5 5 8 5 5 8 10 5 1 5 8 5 5 5 10 Puntaje Mximo PHP JSP Python
Tabla 3.16 Tabla de anlisis tcnico comparativo de los lenguajes de programacin.
De acuerdo a la evaluacin realizada, el lenguaje de programacin ms conveniente es PHP, debido a que este presenta un mejor uso de los recursos en los equipos, es fcil de comprender, su cdigo fuente es ms seguro siempre y cuando se haya desarrollado de forma adecuada la programacin, y existe un gran soporte en entornos de desarrollo tanto de cdigo abierto como comerciales para desarrollar aplicaciones en esta tecnologa.
208
3. Entornos de Desarrollo
Para evaluar los entornos de desarrollo se han seleccionado aquellos que permitan soportar una amplia variedad de lenguajes de programacin, esto debido a que el entorno de desarrollo debe de ajustarse al lenguaje de programacin que resulte seleccionado en esta misma evaluacin. 3.1. Notepad++ 5.2 Notepad++ es un editor de cdigo fuente libre, que admite varios lenguajes de programacin, puede ejecutarse bajo Windows o Linux, se distribuye bajo la Licencia Publica General de GNU. Los lenguajes de programacin admitidos son: C, C++, Java, C#, XML, HTML, PHP, JavaScript, archivos de recursos RC, makefile, Arte ASCII, doxygen, archivos INI, archivos por lotes (BAT), ASP, archivos VB/VBS, Shell script de UNIX, SQL, Objective-C, CSS, Pascal, Perl, Python, Lua, TeX, TCL, lenguaje ensamblador, Ruby, Lisp, Scheme, Smalltalk, PostScript, VHDL, FORTRAN, Ada, Caml, AutoIt, KiXtart, Matlab y Verilog. Notepad++ permite el uso de plugins lo cual lo hace extensible, ya que a travs de los diferentes plugins disponibles puede aumentarse la funcionalidad de este editor. Algunas de las caractersticas de Notepad++ son: Sintaxis coloreada a eleccin del usuario Permite al usuario definir su propio lenguaje a travs de User Language Define System Autocompletado Multi-Documento, se pueden editar varios documentos al mismo tiempo. Multi-Vista, puede visualizar (editar) dos documentos diferentes a la vez. Tambin puede visualizar y editar un mismo documento en vistas y posiciones diferentes. Deteccin automtica del estado del documento Funcionamiento bajo entornos multilinges Resaltado de parntesis y sangra Grabacin y reproduccin de macros, puede guardar varias macros y editar sus atajos de teclado.
Notepad++ presenta el inconveniente de agregar caracteres inservibles cuando se est cambiando la codificacin, adems de la falta de documentacin y de un soporte bien definido en caso de problemas con el software.
Requerimientos Mnimos Sistema Operativo Procesador Memoria Disco Duro Windows XP o Superior 300 MHz 128 MB RAM 10 GB
Tabla 3.17 Requerimientos mnimos de Notepad++
209
3.2 Adobe Dreamweaver CS3

Adobe Dreamweaver, es una aplicacin en forma de estudio pero con ms parecido a un taller destinado para la construccin y edicin de sitios y aplicaciones Web basados en estndares. Creado inicialmente por Macromedia y actualmente producido por Adobe Systems, se distribuye bajo una licencia comercial. Es el programa de este tipo ms utilizado en el sector del diseo y la programacin web, por sus funcionalidades, su integracin con otras herramientas como Adobe Flash y, recientemente, por su soporte de los estndares del World Wide Web Consortium. Un aspecto de alta consideracin de Dreamweaver es su arquitectura extensible. Es decir, permite el uso de "Extensiones". Las extensiones, tal y como se conocen, son pequeos programas, que cualquier desarrollador Web puede escribir (normalmente en HTML y JavaScript) y que cualquiera puede descargar e instalar, ofreciendo as funcionalidades aadidas a la aplicacin. Lo que ms destaca de esta herramienta sobre otras, es su gran poder de ampliacin y personalizacin de la misma, puesto que en este programa, sus rutinas estn hechas en JavaScript-C, lo que le ofrece una gran flexibilidad en estas materias. Esto hace que los archivos del programa no sean instrucciones de C++ sino, rutinas de JavaScript que hace que sea un programa muy fluido, que todo ello hace, que programadores y editores Web hagan extensiones para su programa y lo ponga a su gusto.
Dreamweaver, permite al usuario utilizar la mayora de los navegadores Web instalados en su ordenador para previsualizar las pginas web. Tambin dispone de herramientas de administracin de sitios dirigidas a principiantes como, por ejemplo, la habilidad de encontrar y reemplazar lneas de texto y cdigo por cualquier tipo de parmetro especificado, hasta el sitio Web completo. El panel de comportamientos tambin permite crear JavaScript bsico sin conocimientos de cdigo.
Adems Dreamweaver tiene las funciones tpicas de un editor de cdigo fuente para la Web: Un administrador de sitios, para agrupar los archivos segn el proyecto al que pertenezcan. Un cliente FTP integrado, que permite subir los archivos editados inmediatamente al sitio en Internet. Funcin de autocompletar y resaltado de la sintaxis para instrucciones en HTML y lenguajes de programacin como PHP, JSP o PYTHON.
Requerimientos Mnimos Sistema Operativo Procesador Memoria Disco Duro Windows o superior 1 GHz 512 MB 10 GB
Tabla 3.18 Requerimientos mnimos de Dreamweaver
210
3.3 Eclipse
Eclipse, es un entorno de desarrollo integrado de cdigo abierto multiplataforma desarrollado por la Eclipse Foundation, esta plataforma de desarrollo comprende de un entorno de desarrollo integrado, que trabaja junto con un sistema de extensin a travs de mdulos. En un principio se utilizo para el desarrollo de aplicaciones escritas exclusivamente en Java, pero a travs de la incorporacin de los mdulos puede trabajarse en otros lenguajes como C++, Cobol, Perl, PHP, etc. El entorno de desarrollo integrado (IDE) de Eclipse emplea mdulos para proporcionar toda su funcionalidad al frente de la plataforma de cliente rico, a diferencia de otros entornos monolticos donde las funcionalidades estn todas incluidas, las necesite el usuario o no. Este mecanismo de mdulos es una plataforma ligera para componentes de software. La arquitectura a travs de mdulos permite escribir cualquier extensin deseada en el ambiente, como sera Gestin de la configuracin desarrollo integrado (IDE) de Eclipse emplea mdulos para proporcionar toda su funcionalidad al frente de la plataforma de cliente rico, a diferencia de otros entornos monolticos donde las funcionalidades estn todas incluidas, las necesite el usuario o no. Este mecanismo de mdulos es una plataforma ligera para componentes de software. Adems esta arquitectura permite escribir cualquier extensin deseada en el ambiente, como sera Gestin de la configuracin. Eclipse provee al programador con Framework muy ricos para el desarrollo de aplicaciones grficas, definicin y manipulacin de modelos de software, aplicaciones Web, etc. Algunos de los inconvenientes que presenta este entorno de desarrollo son los siguientes: Presenta una interfaz de usuario complicada La creacin de comentarios intiles dentro del cdigo Debido a que est basado en Java su ejecucin consume muchos recursos No reconoce JavaScript y CSS
Sistema Operativo Procesador Memoria Disco Duro Multiplataforma 1.8 GHz 1 GB 100 GB
Tabla 3.19 Requerimientos mnimos de Eclipse.
211
Tabla de anlisis comparativo para el entorno del desarrollo.

Descripcin de mtricas con sus respectivos niveles de escala para la evaluacin del entorno de desarrollo (IDE). Establecidos a criterio del equipo evaluador.
Mtrica Interno Facilidad de Instalacin Multiplataforma Utilizacin adecuada de recursos Soporta varios lenguajes Opciones y herramientas para facilitar edicin Madurez El SW Incorpora un asistente para su instalacin . El software funciona en diversos sistemas operativos Su ejecucin se realiza con una adecuada utilizacin de recursos el equipo Capacidad de trabajar con diferentes tecnologas de desarrollo provee un adecuado conjunto de funciones para las tareas y objetivos especificados Posee una amplia trayectoria con la que puede considerarse libre de fallas al momento de su ejecucin. Grado en que el software mantiene su funcionamiento cuando ocurren fallos Capacidad para evitar efectos inesperados debido a modificaciones . 5 5 10 Descripcin Puntaje Max
5 10
Tolerancia a errores Estable tras actualizaciones Externo Facilidad de uso Documentacin
5 5
Puede ser utilizado con los conocimientos del equipo de desarrollo Facilidad para que el usuario se capacite con respecto al software a travs de documentacin, soporte en lnea, etc. Facilidad, periodicidad y actualizacin del software automatizacin del proceso de
10 10
Actualizacin del Software Se integra con otras herramientas Diseo de interfaz de Uso Productividad Satisfaccin con respecto a otros IDE Total
5 5
Capacidad para trabajar en conjunto con otras herramientas de desarrollo como GBD, herramientas CASE, etc. El entorno de desarrollo posee una interfaz que facilita su uso
Cuanto esfuerzo ahorra al usuario en el uso del sistema, los tiempos de respuesta, etc. Nivel de ventaja que presenta el entorno de desarrollo para con otro software del mismo tipo.
10
100 Tabla 3.20 Tabla de anlisis comparativo para el entorno de desarrollo.
212
Anlisis Tcnico Comparativo del entorno de desarrollo.

Mtrica Puntaje Mximo Dreamweaver Eclipse Notepad++
Interno Facilidad de Instalacin Multiplataforma Utilizacin adecuada de recursos Soporta varios lenguajes Opciones y herramientas para facilitar la edicin de cdigo Madurez Tolerancia a errores Estable tras actualizaciones Externo Facilidad de uso Documentacin Actualizacin del Software Se integra con otras herramientas Diseo de interfaz de Uso Productividad Satisfaccin con respecto a otros IDE Puntaje Total 10 5 100 10 5 84 8 3 76 8 5 72 10 10 5 5 5 5 10 5 5 5 5 8 5 5 3 10 5 5 1 1 5 5 10 5 10 5 1 5 5 8 5 5 1 5 8 5 1 10 5 5
5 5 5
5 5 5
5 5 5
5 1 5
Tabla 3.21 Tabla de anlisis tcnico comparativo del entorno de desarrollo.
Tras realizar la evaluacin de las herramientas de desarrollo, como se puede observar en la tabla arriba presentada, la herramienta mejor evaluada fue Dreamweaver, debido a que esta presenta mejores opciones a los desarrolladores a la hora de la edicin del cdigo, as como una interfaz amistosa lo que facilita su uso y es capaz de soportar muchos lenguajes de programacin sin la necesidad de instalar mdulos extra, como en el caso de Eclipse; tambin Dreamweaver est respaldado por una amplia trayectoria la cual a dejado una amplia documentacin y muchas comunidades donde los desarrolladores pueden encontrar soluciones a sus problemas. 213
ANEXO #4 DETERMINACION DE LOS COSTOS DEL PROYECTO. COSTOS FIJOS Son aquellos costos que permanecen constantes o casi fijos durante el desarrollo del proyecto, dentro de ciertos lmites de capacidad y tiempo. Suministros
Concepto Alquiler Suministro de agua Agua Embotellada Suministro de energa elctrica Telfono + Internet
25 24
Costo Mensual ($) 100.00 5.00 6.00 47.24 65.54
Periodo (Meses) 8 8 8 8 8 Total $
Subtotal ($) 800.00 40.00 48.00 377.92 450.54 1,712.92
Tabla 4.1 Costos Fijos aplicados al desarrollo del proyecto.
Depreciacin de activo fijo Los bienes muebles pierden valor con el paso del tiempo, debido a su uso; por lo tanto es necesario aplicar la depreciacin del activo fijo del equipo de desarrollo al presupuesto del proyecto.
Cantidad Activo Depreciacin mensua 10.49 8.33 11.33 12.49 0.90 0.68 0.63 1.08 Periodo (Meses) Subtotal ($)
1 1 1 1 4 2 2 1
Laptop HP 530 Laptop GATEWAY MT3422 Laptop DELL Laptop HP pavilion UPS Impresora Ventilador Router
8 8 8 8 8 8 8 8 Total $
83.99 66.64 90.66 99.99 7.2 5.46 5.06 8.66 367.66
Tabla 4.2 Costo por depreciacin de activo fijo utilizado para el desarrollo del proyecto.
24 25
Ver ANEXO #5: Calculo de consumo de energa elctrica. Determinado por el plan de turbonett de 2 MB + llamadas ilimitadas con un valor de $58.00+IVA
214
Salarios del equipo tcnico Analistas /Programadores 4 Salario Mensual26 ($) 605.00 Meses de desarrollo 8 Costo Total ($) 19,360.00
Tabla 4.3 Salarios del equipo tcnico que participara en el desarrollo del proyecto.
Salarios de Docente Director y Observador

Cargo Docente Director Observador Salario mensual ($) $1,100.00 $1,200.00 Salario mensual ($) $36.67 $40.00 Salario por hora ($) $4.58 $5.00
Tabla 4.4 Salarios por hora de Asesor y Observador.
Cargo Docente Director Observador total 64 8 72
Horas invertidas durante el proyecto
Total ($) 293.12 40 333.12
Tabla 4.5 Horas invertidas en el proyecto por asesor y por observador.
El salario del Docente Director y Observador, fue brindado por el Departamento de Jefaturas de la Escuela de Ingeniera de Sistemas Informticos. La duracin del proyecto es de 8 meses. Se estima que el Docente Director invierta dos horas semanales, lo que hace un total de 8 horas mensuales, por lo tanto el salario mensual del docente Director para este proyecto ser de $36.67 dlares mensuales. Se estima que el Observador invierta 8 horas durante todo el proyecto, lo que hace una hora mensual, esto convertido a dinero da un total de $40.00 dlares mensuales en concepto de salario para el Observador. Viticos
Destino Visita a oficina del CRINA 4 No. De personas Transporte X persona ($) 1.50 Alimentacin X persona ($) 2.50 No. De viajes 15 Total $
Tabla 4.6 Costo en concepto de viticos adjudicados al desarrollo del proyecto.
Subtotal ($) 225.00 225.00
26
Garca, C.E; Gerencia Informtica; informatik S.A. de C.V San Salvador; 2008
215
Total Costo de Proyecto

Concepto Costos Fijo Costo por depreciacin Salario de equipo tcnico viticos Total sin imprevistos $ Imprevistos (10%) Total $ Costo ($) 1,712.92 367.66 19,693.12 225.00 21,998.7 2,199.87 24,198.57
Tabla 4.7 Costo Total para el desarrollo del proyecto.
216
ANEXO #5: CALCULO DE CONSUMO DE ENERGIA ELECTRICA
Para determinar el consumo de energa elctrica mensual, se desglosara los importes que determinan el total de dicho consumo. La tarifa est compuesta por 4 costos, 2 de estos son fijos y dos variables, entre los costos fijos se encuentran (1) Costo de comercializacin (2) Costo por tasa municipal por poste. Entre los variables (3) Costo por Distribucin y (4) Costo por energa elctrica.
Costo de Comercializacin: es el costo de atencin al cliente, se calcula a partir de una tarifa fija establecida por la empresa ms IVA. Tarifa de comercializacin vigente durante todo el 2010=0.813324 Costo de comercializacin=tarifa de comercializacin X IVA Costo de comercializacin=0.813324 X 1.13 Costo de comercializacin=0.91905612=$0.92
Costo de la tasa municipal por poste es un costo fijo que establece la municipalidad, actualmente asciende a $0.16 ctvs.
Costo por distribucin este costo vara de acuerdo a la cantidad de KW consumidos. En la siguiente tabla se presenta el equipo con el que se trabajara, cuanto KWh consume y el total de KW/mes que se estima consumir en un mes.
217
Cantidad 4 2 2 2 1
Equipo elctrico Computadora Ventilador Impresor Foco ahorrador Router
Potencia 300 300 150 20 12
Kilowatt/hora 0.30 0.30 0.15 0.02 0.012
Horas mes 100 100 10 100 100 Total KWh
Total KW mes 120.00 60.00 3.00 4.00 1.20 188.20
Tabla 5.1 Estimacin de KW mes que se ha de consumir.
Tabla de precios de distribucin de energa elctrica

Cargo de comercializacin Cargo de distribucin Cargo de distribucin Cargo de distribucin 0.813324 0.023163 0.040401 0.046845
Tabla 5.2 Precios de distribucin de energa para pequeas demandas con consumos mayores de 99KW.
El cargo por distribucin de energa elctrica sera el siguiente:

Pequeas demandas Los primeros 99 KW Los primeros 100 KW Los KW restantes Total KW/mes Cantidad KW/mes 99.00 100.00 19.20 188.20 Precio ($) 0.023163 0.040401 0.046845 Total $ Sub Total ($) 2.293137 4.0401 0.899424 7.232661
Tabla 5.3 Calculo del cargo por distribucin.
Cargo por distribucin = Total por distribucin X IVA Cargo por distribucin = 7.232661 x 1.13 Cargo por distribucin =8.17 218
Costo por energa elctrica consumida Tabla de precios de cargo por energa vigentes en el ao 2010 Tarifa residencial consumo > 99 KWh./mes Bloque 1: Primero 99 KWh/mes Cargo de distribucin 0.154601
Bloque 2: Consumos entre 100 KWh./mes y 199 KWh./mes Cargo de distribucin 0.153730
Bloque 3: Consumos iguales o superiores a 200 KWh/mes Cargo de distribucin 0.153096
Tabla 5.4 Precios de energa elctrica para pequeas demandas con consumos mayores de 99KW
El cargo por energa elctrica consumida sera el siguiente: Pequeas demandas Los primeros 99 KW Los primeros 100 KW Los KW restantes Total KW/mes Cantidad KW 99.00 100.00 19.20 188.20 Precio ($) 0.154601 0.153730 0.153096 Total $ Sub Total ($) 15.305499 15.373000 2.9394432 33.6179422
Tabla 5.5 Calculo del costo de energa elctrica por consumo de 188.20 KW.
Cargo por energa elctrica = Total por energa X IVA Cargo por energa elctrica = $33.6179422 x 1.13=$37.98827469 Cargo por energa elctrica = $37.99
En el recibo de energa elctrica se veran reflejados los siguientes costos:

Cargo de distribucin Cargo por tasa municipal por poste Cargo de comercializacin Cargo de energa Total a pagar $8.17 $0.16 $0.92 $37.99 $47.24
Tabla 5.6 Total a pagar en un mes por un consumo de 188.20 KW.
219
ANEXO #6: CALCULO DE LA DEPRECIACION Segn el documento Antecedentes y Generalidades de la Contabilidad Gubernamental y de las Normas Internacionales de Contabilidad, en el captulo I. Los bienes mueble o inmuebles destinados a las actividades institucionales y productivas, debern depreciarse anualmente aplicando el mtodo de depreciacin basado en el clculo lineal o constante. Lo cual ha sido tomado como referencia para la aplicacin de este mtodo en el clculo de la depreciacin de los bienes muebles con los que contara dicho proyecto. Mtodo Lineal o Constante. Este mtodo, es utilizado muy frecuentemente por ser sencillo y fcil de calcular, el cual supone que el proceso de deterioro o prdida de valor es igual en cualesquiera de los aos y que al final de la vida til, la venta del equipo en el estado en que se encuentre en ese momento, asegura la recuperacin de un cierto monto, denominado valor de salvamento y que tradicionalmente se estima en un 10% del valor nuevo, siempre y cuando su posterior utilizacin no implique la destruccin aplicado a los bienes transportables. En este sentido puede decirse que cuando se refiere a inmuebles o bienes muebles de corta duracin este valor de salvamento no existe. Depreciacin mensual = (costo de equipo por tasa de depreciacin)/12 Aplicacin de la depreciacin. En la Tabla siguiente se muestra el clculo de la depreciacin de los bienes muebles que se utilizaran.
Bienes Muebles Costo ($) Laptop HP 530 Laptop GATEWAY MT3422 Laptop DELL Laptop HP pavlion UPS Impresora Ventilador Router Total costos 629.99 500.00 679.99 749.99 54.00 41.00 38.00 65.00 2,757.97 (629.99*0.2 )/12 (500.00*0.2)/12 (679.99*0.2)/12 (749.99*0.2)/12 ( 54.00*0.2)/12 ( 41.00*0.2)/12 ( 38.00*0.2)/12 ( 65.00*0.2)/12
27
Depreciacin mensual ($)
Depreciacin durante el desarrollo del sistema informtico (8 meses) ($) 83.99 66.64 90.66 99.99 7.2 5.46 5.06 8.66 367.66
Depreciacin Mensual ($)
10.49 8.33 11.33 12.49 0.90 0.68 0.63 1.08
Tabla 6.1 Clculo de depreciacin mensual de activo fijo
27
Porcentajes de depreciacin publicados por el Centro Interamericano de Administraciones Tributarias: http://www/2.ciat.org/es/bdat/docures/desc/dsv_sistema_tributario_salvador.pdf
220

MANUAL

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MANUAL

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD DE EL SALVADOR FACULTAD DE INGENIERIA Y ARQUITECTURA ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS

MSc. RUFINO ANTONIO QUEZADA SNCHEZ

LIC. DOUGLAS VLADIMIR ALFARO CHVEZ

FACULTAD DE INGENIERIA Y ARQUITECTURA

ING. MARIO ROBERTO NIETO LOVO

ING. OSCAR EDUARDO MARROQUN HERNNDEZ

ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS

ING. JOS MARA SNCHEZ CORNEJO

UNIVERSIDAD DE EL SALVADOR FACULTAD DE INGENIERIA Y ARQUITECTURA ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS

Trabajo de Graduacin previo a la opcin al Grado de:

INGENIERO DE SISTEMAS INFORMATICOS

ING. SANDRA GUADALUPE ROMERO San Salvador, Febrero 2011

Trabajo de Graduacin Aprobado por:

ING. SANDRA GUADALUPE ROMERO

3.2.1. 3.2.2. 3.2.3. 4.

5.1.1. 5.1.2. 5.1.3. 5.1.4. 5.1.5. 5.2.

8.1.1. 8.1.2. 8.1.3. 8.1.4. 8.2.

Estndares de Diseo. ....................................................................................................... 47 Diagrama de Clases. .................................................................................................. 47

8.3.1. 8.3.2. 8.4.

8.5.1. 8.5.2. 8.5.3. 8.6. 8.7. 9.

Estndares de Manuales a Entregar .................................................................................. 65 Estndares de Seguridad ................................................................................................... 66

Diseo de Seguridad .............................................................................................................. 99

PLAN DE IMPLEMENTACIN ............................................................................................... 124

13.4.1. 13.4.2. 13.4.3. 13.4.4.

13.7. Estrategias de Control. .................................................................................................... 137 14. MANUALES .......................................................................................................................... 138

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

1.1 OBJETIVO GENERAL

1.2 OBJETIVOS ESPECFICOS

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

Entrevista con Dra. Lorena de Zelaya actual directora del CRINA

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

1.1. SISTEMAS INFORMTICOS DE SALUD

1.2. ACERCA DE LOS SISTEMAS INFORMTICOS ORIENTADOS A LA WEB

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

1.3. MARCO LEGAL

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

Electroterapia. Confeccin y adaptacin de sillas especiales. Neurologa terapia de grupo de artritis.

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

GERENCIA MEDICA Y DE GERENCIA MEDICA YDE DESERVICIOS SERVICIOS DE REHABILITACIN. REHABILITACIN.

COMIT DE APOYO A LA GESTION.

SERVICIOS DE TERAPIAS. T. OCUPACIONAL.

SERV. GENERALES. T. EDUCATIVA.

Figura 2.1. Organigrama Centro de Rehabilitacin Integral para la Niez y la Adolescencia

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

2.2. ANTECEDENTES INFORMTICOS

3. SITUACIN ACTUAL DEL CRINA 3.1. DESCRIPCIN

Cuadro 3.1. Personal que labora en el CRINA

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

Creacin de Expediente del Paciente

Creacin de Resmenes Tcnicos

Figura 3.1: Procesos en la administracin de los expedientes de pacientes.

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

3.2. ENFOQUE DE SISTEMAS DE LA SITUACIN ACTUAL

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

3.2.1. VARIABLES DE ENTRADA

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

Asignacin de horarios de terapias: 13

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

4.1. METODOLOGA PARA LA SOLUCIN DE PROBLEMAS

Consultar ANEXO 2: EVALUACION Y SELECCION DEL MODELO DE CICLO DE VIDA

Sistema Informtico para la Administracin y Control de Expedientes del CRINA

Etapa n: Diseo detallado, construccin, depuracin, pruebas y entrega.