Inportante

Facultad de Ingeniería Carrera de Ingeniería de Software Sistema Integrado de Salud: Subsistema Laboratorio Clínico 2.0 Perfil del Proyecto para la obtención del Título Profesional de Ingeniero de Software Autores: 200210312 Mariana Y. Segura Zúñiga Toshiba, 2013 Página 1 de 179 200110371 Giuliana P. Veli Cornelio Asesor: Jorge Cabrera Febrero 2009 Perfil del Proyecto 1. Tema Gestión administrativa de un Laboratorio Clínico. 2. Título Sistema Integrado de Salud: Subsistema Laboratorio Clínico 2.0 Toshiba, 2013 Página 2 de 179 3. Objetivos 3.1 Objetivo General Desarrollar un producto software, de calidad, de apoyo a los procesos de un Laboratorio Clínico como parte del Sistema Integrado de Salud. 3.2 Objetivos Específicos Objetivo Específico 1: Implementación del producto software Laboratorio Clínico 2.0, el cual incluirá entre sus características principales:       Administración de Listas y Solicitud de Exámenes de laboratorio. Rotulación Muestras. Registro, validación y consulta de Resultados de Muestra y Envío del Reporte de Resultados de Exámenes. Administración de Pacientes Externos. Asignación de Horarios a personal del laboratorio. Integración con otros subsistemas del Sistema Integrado de Salud. o Servicios ofrecidos: Registro de solicitudes de Exámenes, y consulta de Resultados de exámenes. o Servicios requeridos: Integración con el subsistema Seguridad para autenticación y autorización de los usuarios del sistema; consulta de los datos de los pacientes internos y registro de resultados de exámenes a través del subsistema Historial Clínico; códigos y nomenclaturas desde el subsistema de vocabularios; consulta de los datos de los médicos y del horario de los laboratoristas a través del subsistema Módulo de Gestión Administrativa e Información de los resultados de exámenes apenas se encuentren registrados al subsistema Unidad de Cuidados Intensivos. Objetivo Específico 2: Implantación del producto en la infraestructura de TI del Área de Computación de la UPC. Toshiba, 2013 Página 3 de 179 4. Fundamentación: Oportunidad de Negocio El sistema de salud en el Perú está conformado por el sector público, al cual pertenecen el Ministerio de Salud (MINSA), la seguridad social (EsSalud) y los hospitales de las Fuerzas Armadas y Policiales; y por el sector privado, al cual pertenecen las clínicas afiliadas a la Entidad Prestadora de Salud (EPS) y las independientes, los médicos privados, los institutos especializados, los laboratorios clínicos, los servicios de emergencia, entre otros. Al enfocarnos más en el sector público, se observa que las características más sobresalientes son las siguientes:     Ausencia de una visión de conjunto en la administración del sistema de salud y en el uso del presupuesto. Baja productividad en los hospitales, alto grado de capacidad instalada no utilizada, duplicación en indefinición de funciones e información. Deficiencias en la definición y clasificación hospitalaria y carencias de sistemas de acreditación y referencia en el MINSA, lo que dificulta la discriminación de las funciones y no permite actuar como un sistema de salud integrado. Inexistencia de planes de contingencia frente a la modernidad tecnológica e informática. Para revertir esta situación, en la última década se promovieron una serie de actividades y proyectos piloto, con el objetivo de difundir la modernidad gerencial y a crear sistemas informativos e instrumentos metodológicos que permitieran introducir luego sistemas modernos de gestión en los principales hospitales del país. Pero tal esfuerzo ha quedado en una etapa muy inicial de implementación1. Sin embargo, aprovechando esta oportunidad, el Instituto Nacional de Salud, en el 2007, logró implementar un Sistema de Gestión para Laboratorios Clínicos, NETLAB. Este sistema, desarrollado para Web, consiste en facilitar el acceso a los resultados de los exámenes de laboratorio al personal de salud y a los pacientes. Administra los datos generados durante el proceso de recepción de muestras, procesamiento y publicación de resultados. Sin embargo, este sistema no tiene una relación directa con los hospitales nacionales ni con otras áreas del sector salud, por lo que, la atención de los laboratorios clínicos dentro de los hospitales, demanda una inversión de una gran cantidad de tiempo y esfuerzo. 1 Ref: La Salud Peruana en el Siglo XXI: Retos y Propuestas de Política Toshiba, 2013 Página 4 de 179 Estas deficiencias traen como consecuencia que, los sistemas administrativos, las normas que regulan el funcionamiento interno del sector público, sean un obstáculo para el buen desempeño de los establecimientos de salud, ya que, exigen tiempo y dedicación de los directivos en gestiones que no se orientan a mejorar la calidad de los servicios sino a satisfacer requerimientos puramente formales. Por esta razón, dentro del plan estratégico 2007-2011 para el sector salud, se encuentra lo siguiente: Consolidar un desarrollo adecuado y una transferencia efectiva de tecnologías en salud y en la generación de capacidades en las regiones. Lo cual incluye el fortalecimiento del sistema de la red nacional de laboratorios de salud pública, mediante supervisión, control de calidad y transferencia tecnológica2. Así, el subsistema Laboratorio Clínico 2.0 tiene como oportunidad: o o o Falta de integración entre los laboratorios clínicos y otros departamentos pertenecientes a una entidad de salud pública. La problemática generada por el procesamiento manual de lo servicios de un laboratorio clínico. La búsqueda del desarrollo en tecnologías en salud incluido en el plan estratégico 2007-2011. La existencia de un software que lleve a cabo, de forma integral, rápida, oportuna y confiable, los procesos internos de laboratorios y que sea capaz de interactuar con otros módulos de una entidad de salud será el principal beneficio brindado por el subsistema. 5. Descripción del Producto El producto a desarrollarse, propone la automatización y la mejora de los procesos y manejo de datos dentro de un laboratorio clínico. Para lograr esto, las funcionalidades principales del producto se enfocan en la administración de las solicitudes de exámenes internas y externas a la entidad de salud, así como en la administración de pacientes externos (pacientes que no se encuentran registrados en el subsistema historial clínico). Como requerimiento fundamental de los otros módulos de la entidad de salud, el subsistema Laboratorio Clínico permite registrar nuevas solicitudes de exámenes y consultar los resultados de los mismos a través de los servicios brindados. 2 Ref: Instituto Nacional de Salud: Memoria Anual 2007 Toshiba, 2013 Página 5 de 179 El proceso principal del subsistema Laboratorio Clínico consiste en el registro de las solicitudes de exámenes. Para esto, este proceso cuenta con dos inicios principales:   El primero, en el registro de una solicitud de exámenes por parte de un área interna de la entidad de salud. El segundo, en el pedido de un paciente externo a la entidad de salud, para realizar una solicitud de exámenes. En caso que este paciente no haya realizado exámenes anteriormente en el laboratorio, se realiza el registro del nuevo paciente, de lo contrario se procede al registro de la solicitud. Para el registro de una solicitud de exámenes se requieren los siguientes pasos: la selección de un paciente, un médico, el área del cual procede, los exámenes solicitados, así como los análisis que estos exámenes implican. Una vez registrada la solicitud, dependiendo del área de procedencia, se realiza la priorización de la ejecución de los mismos y se registran los resultados. Finalmente se procede a la validación final de los resultados para registrarlos en Historial Clínico, en caso la solicitud sea interna, o la entrega del reporte al paciente, en caso sea externo. Resultados Área Interna de Salud Paciente Externo Solicitud de Examen Toshiba, 2013 Página 6 de 179 Laboratorista3 Laboratorista1 5.1 Requerimientos Funcionales Administración de Solicitud de Exámenes Esta funcionalidad permite la creación, actualización, consulta y eliminación de las solicitudes de exámenes a gestionar por el laboratorio. De igual manera, estas solicitudes pueden ser creadas, actualizadas y consultadas por los módulos UCI, Consultorio Externo y Maternidad. Administrar Lista de Exámenes Esta funcionalidad se encarga de realizar el ingreso, actualización, consulta y eliminación de los exámenes y sus correspondientes análisis que el laboratorio ofrece. La creación, actualización y eliminación es función propia del laboratorio, sin embargo, todos los otros módulos pueden consultar la lista de exámenes disponible. Registrar Resultados de Muestras Esta funcionalidad permite registrar los resultados obtenidos en el análisis de las muestras extraídas para cada examen por solicitud. Rotular Muestras Esta característica permite generar un identificador único para la muestra extraída a determinado paciente. El registro del resultado de los análisis está relacionado directamente a este identificador. Asignar horarios a laboratoristas Esta funcionalidad permite registrar el horario de trabajo del personal dentro del laboratorio clínico, según las horas de trabajo programadas para cada uno de ellos por el módulo de Recursos Humanos. 7 Validar Resultados de Muestras Para que los resultados de los exámenes puedan ser entregados necesitan pasar por un proceso de validación. En caso de que los resultados de las muestras sean aprobados, se procede a la entrega de las mismas; en caso contrario, ingresa a la lista de las solicitudes con estado pendiente y con la prioridad respectiva para ser reprocesado. Administrar Pacientes por Consulta Externa Permite realizar las funciones de creación, consulta, actualización y eliminación de registros de pacientes que ejecutan solicitudes de exámenes por el subsistema Consulta Externa. Enviar Reporte de Resultados de Solicitud de Exámenes Esta funcionalidad se encarga de registrar en el módulo Historial Clínico los reportes de los resultados de las solicitudes ingresadas para pacientes internos. Consultar Resultados de Solicitud de Exámenes Esta funcionalidad permite al subsistema UCI acceder a los resultados de las solicitudes de exámenes almacenados en Laboratorio Clínico. Por la prioridad de entrega de resultados al módulo, esta información no consta necesariamente de una validación adicional. 5.3 Herramientas de Ingeniería de Software a utilizar Para el desarrollo del Subsistema Laboratorio Clínico 2.0 se utilizarán las siguientes herramientas: 8 La metodología de desarrollo a aplicar será Rational Unified Process – RUP, la cual proveerá los lineamientos necesarios para producir un software de calidad. Las tareas de modelamiento, diseño y especificación del subsistema se realizarán bajo los estándares de Unified Modeling Language – UML, en el ambiente proporcionado por IBM Rational Rose. Las pruebas de software y gestión de cambios están apoyadas en la herramienta de IBM Rational, específicamente con IBM Rational Requisite Pro e IBM Rational ClearQuest. Para la implementación del software se utilizará como lenguaje de programación Visual Basic .NET, bajo el entorno brindado por Visual Studio 2003. El gestor de base de datos a utilizar será MS SQL Server 2000. El desarrollo de la aplicación se realizará sobre el Sistema Operativo Windows 2000. La selección de las herramientas sigue los lineamientos propuestos para el Proyecto Salud. Estas herramientas garantizan la gestión de calidad y cambios para el ciclo de vida iterativo del proyecto. 9 6. Plan y Entregables Iteración Fechas Principales entregables  Visión  Plan de Desarrollo de Software (Preliminar) 07/10/2005  SRS  Modelo de Casos de Uso  Prototipos no funcionales (inicial)  Glosario  Lista de riesgos  Plan de Aceptación del Producto Hito: Alcance del proyecto Inicio: 22/08/2005 Concepción Fin: (7 semanas)  Plan de Desarrollo de Software  Documento de la arquitectura del 02/12/2005 (SAD)  Prototipos no funcionales  Especificaciones Complementarias  Lista de riesgos  Plan de Iteración Hito: Propuesta de la Arquitectura del Sistema Inicio: 17/10/2005 Elaboración Fin: (7 semanas) Construcción 1 (7 semanas) Construcción 2 (7 semanas) Construcción 3 (7 semanas) Inicio: 03/04/2006 Fin: 19/05/2006 Inicio: 22/05/2006 Fin: 03/07/2006 Inicio: 21/08/2006 Fin: 06/10/2006 Software  Release 1: o Asignar Horario de Laboratorista o Administrar Lista de Exámenes o Administrar Pacientes Externos o Administrar Solicitud de Exámenes  Plan de Pruebas de la iteración  Plan de Iteración  Desarrollo del Caso de Uso: o Enviar Resultado de Solicitud de Análisis (Servicio Brindado) o Registrar Resultados de Muestras o Rotular Muestras o Validar Resultados de Muestras  Plan de Pruebas de la iteración  Plan de Iteración  Desarrollo de los Casos de Uso: o Consultar Resultados de Exámenes (Servicio Brindado) o Actualizar Estado de Solicitud de Análisis (Servicio Brindado)  Plan de Pruebas de la iteración  Plan de Iteración 10 Hito: Capacidad Operacional Inicial Inicio: 16/10/2006 Transición Fin: (7 Semanas) 08/12/2006      Plan de Iteración Manual de Usuario Manual de Instalación Paquete de Instalación (CD) Plan de Aceptación del Producto Hito: Lanzamiento del Producto 11 7. Indicadores de Logro de Objetivos  CD del producto empaquetado Este paquete contiene los instaladores del Subsistema de Laboratorio Clínico v2.0 y los manuales de instalación y del usuario.  Documento de Aceptación del Producto Este documento refleja la conformidad del cliente con el producto entregado. 8. Descripción del Contenido del Documento Declaración Jurada Resumen Introducción Capítulo 1. Justificación Teórica En este capítulo se detalla el marco actual de la administración de solicitudes de exámenes en los Laboratorios Clínicos en las Organizaciones de Salud en el Perú y la problemática existente. Se describe la necesidad de contar con un producto para la administración de los exámenes. Por otro lado, se describe la metodología seleccionada, la herramienta de desarrollo y otras tecnologías elegidas para el desarrollo de este sistema. Capítulo 2. Requerimientos del Software 12 En este capítulo se describen los requerimientos funcionales y no funcionales a cubrir por el sistema definidos en conjunto con el Jefe de Producto, luego de haber analizado en las Organizaciones de Salud los procesos de un Laboratorio Clínico. Capítulo 3. Diseño de la Arquitectura del Software Este capítulo explica la arquitectura elegida para el sistema: el diseño en capas, la integración con los demás subsistemas (servicios requeridos y brindados) y el diagrama de despliegue. Capítulo 4. Diseño Detallado del Software En este capítulo se describe, a través de modelos UML, los casos de uso, los actores, las clases y componentes del producto que respaldan la arquitectura planteada para la solución de software. Asimismo, se presenta el modelo de datos (lógico y físico) para la generación de la base de datos del producto. 13 Capítulo 5. Construcción del Software En este capítulo se detallan las consideraciones tomadas en cuenta para la programación del sistema (estándares y patrones de desarrollo utilizados). Capítulo 6. Pruebas del Software En este capítulo se describe el plan de pruebas que se ha llevado a cabo incluyendo los tipos de prueba seleccionados, criterios de evaluación y los resultados alcanzados. Capítulo 7. Transición del Software Este capítulo hace referencia a la documentación realizada para los usuarios finales (manual de uso e instalación) que facilita el uso del producto. Capítulo 8. Gestión del Proyecto En este capítulo se describe la manera cómo se ha gestionado el proyecto (incluye el plan del proyecto, las actividades realizadas, la gestión de los riesgos, gestión de cambios, etc.). Se describe además el proceso que se llevó a cabo para la planificación del proyecto y se presenta un cronograma que detalla las tareas realizadas y el cumplimiento de objetivos. Conclusiones y Recomendaciones Glosario Bibliografía 14 INTRODUCCIÓN La presente memoria describe el proceso completo con el que se realizó el desarrollo del Subsistema Laboratorio Clínico v2.0, módulo que pertenece al Sistema Integrado de Salud, el cual es desarrollado por alumnos de la carrera de Ingeniería de Software de la Universidad Peruana de Ciencias Aplicadas. El tema de este proyecto es la Gestión Administrativa de un laboratorio clínico, el cual tiene como objetivo desarrollar un producto software de apoyo a los procesos de éste, dentro de las entidades del Sistema de Salud del Sector Público. La problemática del negocio en el cual se basa el proyecto, consiste en que el procesamiento manual de los procedimientos actuales de los laboratorios clínicos, de entidades del Sistema de Salud del Sector Público, arriesgan la integridad de la información, generando así, vulnerabilidades en cuanto a errores y pérdida de la misma. Para el desarrollo de este proyecto se aplicaron los conocimientos adquiridos a lo largo de la carrera, como la gestión de proyectos, así como la detección y uso de mejores prácticas para el desarrollo de software. Las etapas del proyecto estuvieron basadas en el modelo Rational Unified Process (RUP), la cual constituye la metodología estándar más utilizada para el desarrollo de productos software. En el primer capítulo se detalla la descripción del negocio, la problemática principal, la oportunidad, los objetivos de la solución propuesta y la metodología y estándares utilizados. En el segundo capítulo se describen los requerimientos funcionales y no funcionales con los que cuenta el producto. En el tercer capítulo se describe el diseño de la arquitectura y los componentes incluidos en la misma. El cuarto capítulo muestra un diseño detallado del producto, con la descripción de cada capa de la arquitectura. En el quinto capítulo se detalla el diseño de la implementación, así como los estándares de funcionalidad y de diseño de la base de datos empleados en la construcción del producto. El sexto capítulo describe el ambiente, la estrategia y la identificación de las pruebas a realizar, para asegurar la calidad del producto. La gestión del proyecto es descrita en el séptimo capítulo y en el capítulo octavo se describe la etapa de transición. Finalmente se detallan las conclusiones y recomendaciones finales del proyecto. 15 16 CAPÍTULO 1: JUSTIFICACIÓN TEÓRICA 1.1 DESCRIPCIÓN DEL NEGOCIO Un laboratorio clínico es el área de salud, en el cual los profesionales de laboratorio de diagnóstico clínico (laboratoristas) realizan análisis clínicos, que contribuyen al estudio, prevención, diagnóstico y tratamiento de los problemas de salud de los pacientes3. Existen dos tipos de Laboratorios Clínicos, de acuerdo a sus funciones 4: 1. Laboratorios de Rutina: Pueden encontrarse dentro de un Hospital o Clínica Privada y/o ser externos a estos. Estos laboratorios se componen básicamente de cuatro departamentos: Hematología, Inmunología, Microbiología y Química Clínica (Bioquímica). Los laboratorios hospitalarios también cuentan con secciones consideradas de urgencia donde, básicamente, se realizan estudios que servirán para tomar decisiones críticas en la atención de pacientes graves. 3 4 Cfr: Instituto Nacional de Salud 2007 Cfr: Ministerio de Salud de Chile 1993 17 2. Laboratorios de Especialidad: Son laboratorios de pruebas especiales, los cuales realizan estudios más sofisticados. Esos estudios requieren instalaciones y adiestramiento especial del personal que los realiza. El proyecto Subsistema Laboratorio Clínico v2.0 tiene como cliente principal a los laboratorios clínicos de rutina. A los laboratorios clínicos acuden tanto pacientes internos como pacientes externos a la entidad de salud. Esta área de salud tiene una relación directa con los servicios de Consulta Externa, Emergencias, Unidad de Cuidados Intensivos, Quirófano, entre otros, además de contar con un fácil acceso a las áreas de hospitalización. Los servicios que un laboratorio clínico brinda son los siguientes:    Toma de Muestras Análisis de Muestras Entrega de Resultados En cada uno de estos servicios se requiere de numerosas medidas de atención y seguridad, con el fin de minimizar los errores factibles de ser cometidos en la práctica diaria. Las razones por las cuales los laboratorios clínicos son una herramienta primordial para el área médica son:  Descubre enfermedades en etapas subclínicas.  Ratifica diagnósticos sospechados clínicamente.  Obtiene información sobre el pronóstico de una enfermedad.  Establece un diagnóstico basado en análisis definidos.  Vigila un tratamiento o conoce una determinada respuesta terapéutica.  Precisa los factores de riesgo. 18 1.2 DESCRIPCIÓN DE LA PROBLEMÁTICA DEL NEGOCIO En la actualidad, realizar exámenes de laboratorio clínico en una entidad pública demanda al paciente gran cantidad de tiempo y esfuerzo. Una de las razones principales de esta situación es que los procedimientos actuales consisten en registros manuales de recepción de solicitudes, entrega de resultados, manejo de inventarios de insumos, entre otros procesos. Debido a la alta concurrencia de pacientes, estos procesos son un problema permanente, ya que, no se logran las atenciones y respuestas en los tiempos requeridos para cada caso. En consecuencia, es el paciente el más perjudicado, no sólo por la lentitud del proceso, sino también por el riesgo que existe en que su tratamiento no siga un curso favorable a causa de demoras de acción hacia el mismo, o por alteraciones y/o pérdida de información relevante5. El procesamiento manual de estos servicios arriesga la integridad de la información, así como genera vulnerabilidades en cuanto a errores y pérdidas de la misma y requiere además de tiempos extensos para la obtención de los resultados. 6 1.3 OPORTUNIDAD El sistema de salud en el Perú está conformado por: El Sector Público, al cual pertenecen el Ministerio de Salud (MINSA), La Seguridad Social (EsSalud) y los Hospitales de las Fuerzas Armadas y Policiales; y por El Sector privado, al cual pertenecen las clínicas afiliadas a la Entidad Prestadora de Salud (EPS) y las independientes, los médicos privados, los institutos especializados, los laboratorios clínicos, los servicios de emergencia, entre otros. 5 6 Cfr: Arroyo 2002: 23 Cfr: Universidad Centro Occidental Lisandro Alvarado 2007 19 Al enfocarnos más en el sector público, se observa que las características más sobresalientes son las siguientes:  Ausencia de una visión de conjunto en la administración del sistema de salud y en el uso del presupuesto.  Baja productividad en los hospitales, alto grado de capacidad instalada no utilizada y duplicación de funciones e información.  Deficiencias en la definición y clasificación de las entidades de salud y carencias de sistemas de acreditación y referencia en el MINSA, lo que dificulta la discriminación de las funciones lo cual no permite actuar como un sistema de salud integrado. Para revertir esta situación, en la última década se promovieron una serie de actividades y proyectos piloto, con el objetivo de difundir la modernidad gerencial y crear sistemas informativos e instrumentos metodológicos que permitieran introducir luego sistemas modernos de gestión en los principales hospitales del país. Pero tal esfuerzo ha quedado en una etapa muy inicial de implementación 7. Sin embargo, el Instituto Nacional de Salud, en el 2007, logró implementar un Sistema de Gestión para Laboratorios Clínicos llamado NETLAB. Este sistema, desarrollado para Web, consiste en facilitar el acceso a los resultados de los exámenes de laboratorio al personal de salud y a los pacientes. Sus principales funcionalidades consisten en administrar los datos generados durante el proceso de recepción de muestras, así como procesar y publicar los resultados. Sin embargo, el alcance de este sistema se limita sólo al Instituto Nacional de Salud y su red de laboratorios8. Esta limitación afecta a hospitales, y sus laboratorios, así como a otras entidades del Sistema de Salud del Sector Público, los cuales no están inscritos en la red del Instituto Nacional de Salud Por esta razón, dentro del plan estratégico 2007-2011 para el sector salud, se encuentra lo siguiente: Consolidar un desarrollo adecuado y una transferencia 7 8 Cfr: Arroyo 2002:35 Cfr: Dirección General de Medicamentos Insumos y Drogas – Ministerio de Salud 2009 20 efectiva de tecnologías en salud y en la generación de capacidades en las regiones. Lo cual incluye el fortalecimiento del sistema de la red nacional de laboratorios de salud pública, mediante supervisión, control de calidad y transferencia tecnológica 9. Así, el subsistema Laboratorio Clínico 2.0 tiene como oportunidad:  Falta de integración entre los laboratorios clínicos y otros departamentos pertenecientes a una entidad de salud pública.  La problemática generada por el procesamiento manual de lo servicios de un laboratorio clínico en las entidades del Sistema de Salud del Sector Público  La búsqueda del desarrollo en tecnologías en salud incluido en el plan estratégico 2007-2011. La existencia de un software que lleve a cabo, de forma integral, rápida, oportuna y confiable, los procesos internos de laboratorios y que sea capaz de interactuar con otros módulos de una entidad de salud será el principal beneficio brindado por el subsistema. 1.4 SOLUCIÓN PROPUESTA 1.4.1 OBJETIVO GENERAL Desarrollar un producto software, de calidad, de apoyo a los procesos de un Laboratorio Clínico como parte del Sistema Integrado de Salud10. 1.4.2 OBJETIVOS ESPECÍFICOS Objetivo Específico 1: Implementación del producto software Laboratorio Clínico 2.0, el cual incluirá entre sus características principales: 9 Ref: Instituto Nacional de Salud 2007 10 Sistema Integrado de Salud: Proyecto de Software, desarrollado por los grupos de proyecto de la carrera de Ingeniería de Software de la UPC, el cual tiene como objetivo desarrollar un sistema integrado de información dividido en subsistemas con giro de negocio en el sector salud. 21  Administración de Listas y Solicitud de Exámenes de laboratorio.  Rotulación Muestras.  Registro, validación y consulta de Resultados de Muestra y Envío del Reporte de Resultados de Exámenes.  Administración de Pacientes Externos.  Asignación de Horarios a personal del laboratorio.  Integración con otros subsistemas del Sistema Integrado de Salud: o Servicios ofrecidos: Registro de solicitudes de Exámenes, y consulta de Resultados de exámenes. o Servicios requeridos: Integración con el subsistema Seguridad para autenticación y autorización de los usuarios del sistema; consulta de los datos de los pacientes internos y registro de resultados de exámenes a través del subsistema Historial Clínico; códigos y nomenclaturas desde el subsistema de vocabularios; consulta de los datos de los médicos y del horario de los laboratoristas a través del subsistema Módulo de Gestión Administrativa e Información de los resultados de exámenes apenas se encuentren registrados al subsistema Unidad de Cuidados Intensivos. Objetivo Específico 2: Implantación del producto en la infraestructura de TI del Área de Computación de la UPC. 1.4.3 METODOLOGÍAS Y ESTÁNDARES A EMPLEAR Para el desarrollo del Subsistema Laboratorio Clínico v2.0, la metodología de desarrollo a aplicar es Rational Unified Process – RUP, el cual proveerá los estándares necesarios para producir un software de calidad. 22 Las tareas de modelamiento y diseño del subsistema se realizaran bajo los estándares de Unified Modeling Language – UML, en el ambiente proporcionado por Rational Rose. Las pruebas de software y gestión de cambios están apoyadas en la herramienta Rational Software, específicamente con Rational ClearQuest y Rational Requisite Pro. Para la implementación del software se utilizará como lenguaje de programación Visual Basic .NET, bajo el entorno brindado por Visual Studio 2003. El gestor de base de datos a utilizar será MS SQL Server 2000. El desarrollo de la aplicación se realizará sobre el Sistema Operativo Windows 2000. 23 24 CAPÍTULO 2: REQUERIMIENTOS DEL SOFTWARE El siguiente capítulo tiene como objetivo describir las necesidades y requerimientos del software, así como la delimitación del alcance de la solución propuesta. 2.1 REQUERIMIENTOS FUNCIONALES Uno de los resultados de la fase de concepción del proyecto, fue el modelado de casos de uso, el cual muestra gráficamente todas las funcionalidades necesarias para cubrir el proceso de negocio un laboratorio clínico, tal como se muestra en el siguiente diagrama: 25 P1 Administración de Solicitud de Exámenes P3 Administración de Pacientes Externos P2 Administración de Lista de Exámenes P8 Administración de Inventario de Insumos P4 Administración de Muestras y Resultados Laboratorista Administrador (f rom Actores) P5 Asignación de Horarios a Laboratoristas P7 Consulta de Solicitudes Pagadas P6 Validación de Resultados de Exámenes Servicios Facturacion Consultorio Externo (f rom Actores) (f rom Actores) Historial Clínico (f rom Actores) Unidad de Cuidados Intensivos (f rom Actores) Figura 2. 1: Diagrama de Agrupación de Funcionalidades A continuación se muestran los diagramas de caso de uso por cada paquete. Cada caso de uso se encuentra descrito brevemente en el documento de Especificación de Requerimientos de Software y con más detalle los documentos de Especificación de Casos de Uso. Paquete: P1 Administración de Solicitud de Exámenes: Este paquete agrupa las funcionalidades de mantenimiento de las solicitudes de exámenes que se ingresan para ser atendidos en el laboratorio, tanto de otros subsistemas así como de pacientes externos. 26 CU1.1. Crear Solicitud de Exámenes Laboratorista Administrador CU1.2. Buscar Solicitud de Exámenes (f rom Actores) CU1.3. Actualizar Solicitud de Exámenes Figura 2.2: Diagrama de Casos de Uso – Administración de Solicitud de Exámenes Paquete: P2 Administración de Lista de Exámenes: Este paquete agrupa las funcionalidades de mantenimiento de la lista de exámenes que el laboratorio clínico en un determinado momento ofrece. CU2.1. Crear Examen de Análisis Laboratorista Administrador CU2.2. Consultar Examen de Análisis (f rom Actores) CU2.3. Actualizar Examen de Análisis Figura 2.3: Diagrama de Casos de Uso – Administración de Lista de Exámenes 27 Paquete: P3 Administración de Pacientes Externos: Este paquete agrupa las funcionalidades de mantenimiento de los datos de pacientes que atienden sus solicitudes de exámenes por consulta externa, es decir, de aquellos pacientes que no cuentan con un historial clínico en la entidad de salud. CU3.1. Crear Paciente Externo CU3.2. Consultar Paciente Externo Laboratorista Administrador (f rom Actores) CU3.3. Actualizar Paciente Externo Figura 2.4: Diagrama de Casos de Uso – Administración de Lista de Exámenes Paquete: P4 Administración de Muestras y Resultados: Este paquete agrupa las funcionalidades de rotulación de las muestras extraídas, así como del registro de los resultados obtenidos luego de los análisis realizados. 28 CU4.1. Registrar Resultados de Muestras <<include>> Laboratorista Administrador (f rom Actores) CU4.2. Rotular Muestras Figura 2.5: Diagrama de Casos de Uso – Administración de Muestras y Resultados Paquete: P5 Asignación de Horarios a Laboratoristas: Este paquete consiste en la asignación de funciones dentro del laboratorio a partir del horario de trabajo registrado por Recursos Humanos. Laboratorista Administrador CU5.1. Asignar Horario de Laboratorista (f rom Actores) Figura 2.6: Diagrama de Casos de Uso – Asignación de Horarios a Laboratoristas Paquete: P6 Validación de Resultados de Exámenes: Este paquete consiste en el registro de la validación de los resultados obtenidos en los análisis realizados. Este proceso se realiza antes del envío de los resultados al Subsistema Historial Clínico. 29 Laboratorista Administrador CU6.1. Validar Resultados de Muestras (f rom Actores) Figura 2.7: Diagrama de Casos de Uso – Validación de Resultados de Exámenes Paquete: P7 Consulta de Solicitudes Pagadas por Paciente Externo Este paquete consiste en las consultas realizadas al Subsistema de Facturación de las solicitudes pagadas por los pacientes externos para poder realizar la ejecución de los mismos. Laboratorista Administrador CU7.1. Consultar Solicitudes Pagadas por Paciente Externo (f rom Actores) Figura 2.8: Diagrama de Casos de Uso – Consultar Solicitudes Pagadas por Paciente Externo Paquete: P8 Administración de Inventario de Insumos: Este paquete agrupa las funcionalidades de mantenimiento del inventario de insumos con el que cuenta el laboratorio para ejecutar los análisis correspondientes. 30 CU8.1. Administrar Insumos <<extend>> Laboratorista Administrador CU8.2. Rotular Insumos (f rom Actores) CU8.3. Reportar Estado de Insumos Figura 2.9: Diagrama de Casos de Uso – Administrar Inventario de Insumos Paquete Servicios: Este paquete agrupa los servicios que el subsistema ofrece y recibe de los otros subsistemas del Sistema Integrado de Salud. 31 Historial Clínico Módulo de Gestión Administrativ... (f rom Actores) (f rom Actores) SR2 Consultar Paciente Interno SR3 Registrar Resultado de SR5 Consultar Médicos Solicitud de Exámenes SR6 Consultar Horario de Laboratorista Facturacion (f rom Actores) Seguridad SR1 Solicitar Autenticación y Autorización de Usuarios (f rom Actores) SR7 Registrar Solicitud Pendiente SR8 Consultar Solicitudes Pagadas de Pago por Paciente Externo Vocabulario SR4 Consultar Códigos y Nomenclaturas (f rom Actores) SB1 Registrar Solicitud de SB2 Actualizar Solicitud de SB3 Consultar Resultados de Exámenes Exámenes Solicitud de Exámenes Consultorio Externo Unidad de Cuidados Intensivos (f rom Actores) (f rom Actores) Figura 2.10: Diagrama de Servicios A continuación se detallan las funcionalidades incluidas y no incluidas en el alcance del producto: 32 Funcionalidades incluidas en el alcance: Casos de Uso: P1 Administración de Solicitud de Exámenes Esta funcionalidad permite la creación, actualización y consulta de las solicitudes de exámenes a gestionar por el laboratorio. De igual manera, estas solicitudes pueden ser creadas, actualizadas y consultadas por los módulos UCI, Consultorio Externo y Maternidad. Figura 2.11: Pantalla Administrar Solicitud de Exámenes 33 P2 Administración de Lista de Exámenes Esta funcionalidad se encarga de realizar el ingreso, actualización y consulta de los exámenes y sus correspondientes análisis que el laboratorio ofrece. La creación y actualización es función propia del laboratorio, sin embargo, todos los otros módulos pueden consultar la lista de exámenes disponible. Figura 2.12: Pantalla Administrar Lista de Exámenes 34 P3 Administración de Pacientes Externos Permite realizar las funciones de creación, consulta y actualización de registros de pacientes que ejecutan solicitudes de exámenes por el subsistema Consulta Externa. Figura 2.13: Pantalla Administrar Pacientes Externos 35 P4 Administración de Muestras y Resultados: Registrar Resultados de Muestras: Esta funcionalidad permite registrar los resultados obtenidos en el análisis de las muestras extraídas para cada examen por solicitud. Figura 2.14: Pantalla Registrar Resultados de Muestras P5 Rotular Muestras: Esta característica permite generar un identificador único para la muestra extraída a determinado paciente. El registro del resultado de los análisis está relacionado directamente a este identificador. 36 Figura 2.15: Pantalla Rotular Muestras P5 Asignar horarios a laboratoristas Esta funcionalidad permite registrar el horario de trabajo del personal dentro del laboratorio clínico, según las horas de trabajo programadas para cada uno de ellos por el módulo de Recursos Humanos. 37 Figura 2.16: Pantalla Asignar Horarios a Laboratoristas P6 Validar Resultados de Exámenes Para que los resultados de los exámenes puedan ser entregados necesitan pasar por un proceso de validación. Los resultados de muestras pueden tener los siguientes estados:  Estado Aprobado: Se procede a la entrega de los resultados al módulo que lo solicitó o al paciente.  Estado Rechazado: Son resultados que no pasaron el proceso de validación. 38  Estado Pendiente: Resultados rechazados priorizados y en lista de espera para ser reprocesados. Figura 2.17: Pantalla Validar Resultados de Exámenes Servicios ofrecidos: SB1 Registrar Solicitud de exámenes Este servicio permite que los Subsistemas Unidad de Cuidados Intensivos (UCI) y Consultorio Externo ingresen solicitudes de exámenes en el Subsistema Laboratorio Clínico 39 SB2 Actualizar Solicitud de exámenes Este servicio permite que los Subsistemas Unidad de Cuidados Intensivos (UCI) y Consultorio Externo actualicen solicitudes de exámenes en el Subsistema Laboratorio Clínico SB3 Consultar Resultados de Solicitud de Exámenes Este servicio permite que el Subsistema Unidad de Cuidados Intensivos (UCI) consulte los resultados de las solicitudes de exámenes que ha ingresado a través del servicio Registrar Solicitud de exámenes. Este servicio sólo es brindado al Subsistema Unidad de Cuidados Intensivos debido a la urgencia de resultados de sus solicitudes. Los demás subsistemas deberán consultar los resultados al Subsistema Historial Clínico. Servicios recibidos SR1 Solicitar Autorización y Autenticación de usuarios Este servicio, brindado por el Subsistema Seguridad, permite la autorización y autenticación de los usuarios que intentan ingresar al Subsistema Laboratorio Clínico. SR2 Consultar Paciente Interno Este servicio, brindado por el Subsistema Historial Clínico, permite consultar los datos generales de los pacientes registrados en la entidad de salud SR3 Registrar Resultados de Solicitud de Exámenes Este servicio envía al Subsistema Historial Clínico los resultados de las solicitudes registradas (excepto las solicitudes generadas por pacientes externos) en el Subsistemas Laboratorio Clínico. 40 SR4 Consultar Códigos y Nomenclaturas Este servicio, brindado por el Subsistema Vocabulario, permite consultar los códigos y nomenclaturas establecidas para el registro de un paciente (ej. sexo, tipo de sangre, tipo de documento, etc.) por la entidad de salud SR5 Consultar Médicos Este servicio, brindado por el Módulo de Gestión Administrativa e Información, permite consultar los datos generales de los médicos SR6 Consultar Horario de Laboratoristas Este servicio, brindado por el Módulo de Gestión Administrativa e Información, permite consultar los horarios de los laboratoristas. Con esta información, se procederá a asignar funciones al laboratorista Funcionalidades no incluidas en el alcance: Casos de Uso: P7 Consultar Solicitudes Pagadas por Paciente Externo Esta funcionalidad permite consultar al Subsistema de Facturación si las solicitudes de exámenes hechas por un paciente externo tienen como estado: “Pagado”, para continuar con el proceso de ejecución de la solicitud. P8 Administrar Insumos Esta funcionalidad permite registrar los insumos a utilizarse en el laboratorio clínico. Asimismo, permite rotular cada insumo y generar un reporte el cual contenga los estados de cada uno de los insumos registrados 41 Servicios: SR7 Registrar Solicitud Pendiente de Pago Este servicio envía al Subsistema Facturación el registro de una solicitud de exámenes para que este actualice su estado de pago. Una vez que el estado sea "pagado", el Subsistema Laboratorio Clínico continuará con el tratamiento de dicha solicitud. SR8 Consultar Solicitudes pagadas por Paciente Externo Este servicio permite consultar al Subsistema Facturación las solicitudes que tienen el estado de pagado para así continuar con su tratamiento. 2.2 REQUERIMIENTOS NO FUNCIONALES Como se ha detallado anteriormente el proyecto tuvo como base el proceso de negocio de los laboratorios clínicos, en este caso, el del Hospital San José del Callao. El producto ha sido implementado para entorno Windows, por indicaciones del cliente y por lineamientos del Sistema Integrado de Salud. A continuación se detallan los requerimientos no funcionales del producto: Interfaz • Interfaces de usuario: Las interfaces de usuario se basarán y seguirán la normativa definida en el estándar para proyectos que formen parte del Sistema Integral de Salud. Para mayor detalle ver ANEXO ESTANDARES DE INTERFACES GRÁFICAS DEL SISTEMA INTEGRADO DE SALUD. 42 • Interfaces de hardware: Se deberá contar con una lectora de código de barras e impresora para la emisión de las etiquetas adhesivas a las muestras de análisis. • Interfaces de software: El Subsistema Laboratorio Clínico v2.0 debe brindar una interfase al módulo de Unidad de Cuidados Intensivos y Consultorio Externo para el servicio Registro de Solicitudes de Exámenes. Usabilidad • Fácil de usar: El usuario podrá realizar las funciones para las que fue hecho sin necesidad de una preparación muy especializada. Es decir, se podrá hacer uso del subsistema sin necesidad de recibir una capacitación que demande apartar al personal de sus labores. Además el equipo de proyecto desarrolló los manuales de Instalación y de Usuario, para incrementar la facilidad de uso del subsistema. Para mayor detalle ver ANEXO MANUALES DE INSTALACIÓN Y MANUALES DE USUARIO. • Adaptación y Autoaprendizaje Como consecuencia de la facilidad de uso del subsistema se dará la adaptación y autoaprendizaje de los usuarios de modo más ágil. Por este motivo, el tiempo de entrenamiento para el uso de la aplicación será óptimo cumpliendo de esta manera el requerimiento en mención. • Amigable: La interfaz del sistema deberá ser gráfica y agradable. 43 44 CAPÍTULO 3: DISEÑO DE LA ARQUITECTURA El Sistema Integrado de Salud está compuesto por varios módulos que interactúan entre sí para satisfacer todos los requerimientos de una entidad de salud. El Subsistema Laboratorio Clínico, como parte del Sistema Integrado de Salud, se desarrolló en paralelo con los siguientes subsistemas:  Facturación  Consultorio Externo  Unidad de Cuidados Intensivos (UCI)  Recursos Humanos  Admisión, Defunción y Transferencias (ADT) 45 Figura 3.1: Diagrama de los Subsistemas del Sistema Integrado de Salud desarrollados en paralelo con el Subsistema Laboratorio Clínico v2.0 De esta manera, el equipo de proyecto, tuvo como consideración, para el diseño de la arquitectura, facilitar la comunicación con los otros módulos del Sistema Integrado de Salud. Además, se tomó en cuenta que, el diseño de la arquitectura de software es vital para definir la estructura que servirá como base para el desarrollo de las funcionalidades del subsistema. En el siguiente capítulo se presenta y explica la arquitectura creada para el subsistema, describiendo detalladamente los componentes de la misma, así como la integración con otros subsistemas y servicios brindados y requeridos. 46 3.1 ARQUITECTURA DE LA APLICACIÓN La arquitectura diseñada tomó como referencia el patrón arquitectónico ModelView-Controller11 (MVC), el cual consiste en:  Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada.  Vista (View): Muestra la información al usuario. Obtiene los datos del modelo. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador.  Controlador (Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio (“service requests” en el texto original) para el modelo o la vista. El usuario interactúa con el sistema a través de los controladores. Figura 3.2: Diagrama del Patrón Arquitectónico Model – View - Controller12 11 12 Cfr. Microsoft 2007 http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/MTJ_3317.asp#M19 Cfr: http://www.pbandsp.com/tools/images/ModelViewController.png 47 Este modelo se adaptó a una arquitectura multicapa, tal como se muestra en la siguiente figura: Figura 3.3: Diagrama de Arquitectura Subsistema Laboratorio Clínico v2.0 3.1.1 Capa de Interfaz de Usuario (GIU) Esta capa presenta al usuario, mediante interfaces gráficas, las funcionalidades del subsistema. Asimismo, se encarga de comunicar y capturar la información necesaria para las demás capas. Las interfaces gráficas del producto están divididas de la siguiente manera:  Interfaz de Solicitud de Exámenes: Son los formularios Windows encargados de las funcionalidades de registro, actualización y consulta de las solicitudes de exámenes. 48  Interfaz de Administración de Lista de Exámenes: Son los formularios Windows encargados de las funcionalidades de registro, actualización y consulta de las listas de exámenes disponibles dentro del laboratorio.  Interfaz de Manejo de Resultados: Son los Formularios Windows encargados del registro, consulta, actualización y validación de los resultados de los exámenes registrados en una solicitud.  Interfaz de Pacientes Externos: Son los Formularios Windows encargados del registro, actualización, consulta y eliminación de la información relacionada con los pacientes externos que acuden al Laboratorio Clínico.  Formulario Base Se identificaron las características y funcionalidades comunes en todos los formularios y se creó un formulario base (llamado BaseForm) para que todos los formularios del proyecto heredan de él. 3.1.2 Componentes de Proceso User Interface (UI)  Controladoras UI (User Interface): Son los componentes que controlan el comportamiento visual y funcional de las interfaces.  Componente de Validación: Es el componente que se encarga de validar, en la Capa de Presentación, la información enviada desde las interfaces hacia las controladoras. Esta validación se realiza adicionalmente de las validaciones dentro de las interfaces. 49  Helpers y Utilitarios: Conjunto de librerías de clases que provee una solución para manejar información a través de la aplicación. Además provee clases que contienen definiciones de tipos, constantes, entre otros. 3.1.3 Capa de Lógica de Negocio Esta capa recibe las peticiones del usuario y envía las respuestas a la capa de presentación después del procesamiento de la información que se efectuó en la capa de acceso a datos. Se denomina lógica del negocio porque es en esta capa donde se establecen todas las reglas del negocio que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de acceso a datos, para solicitar al motor de base de datos almacenar o recuperar datos de él. Ésta capa está conformada por:  Componentes de Negocio: Lógica de Negocio Se encarga de organizar las funcionalidades y procesos internos del negocio, de manera que se ejecuten correctamente en la capa de acceso a datos, así como del envío de las respuestas a la capa de presentación.  Entidades Empresariales: DataSets Tipificados Son objetos de transferencia de datos que se encuentran implementadas como entidades de negocio, los cuales representan un esquema de la base de datos en memoria. 50  Interfaces de Servicios Se encargan de presentar las funcionalidades del negocio como servicios, las cuales se caracterizan por soportar contratos de comunicación con otros módulos (comunicación basada en mensajes, formatos, protocolos, etc.) 3.1.4 Capa de Acceso a Datos  Lógica de Acceso a Datos No Transaccional Son los componentes que permiten el acceso a los datos de manera no transaccional, es decir, son usados para el acceso del tipo solo lectura de acuerdo a determinadas especificaciones de consultas.  Lógica de Acceso a Datos Transaccionales Son los componentes usados para el acceso de tipo escritura, es decir, de manera transaccional. Este acceso se basa en la ejecución de procedimientos almacenados en el repositorio de datos.  Agente de Servicios Son los componentes que van a realizar los llamados, recuperación y adaptación de la información de los servicios proporcionados por los otros módulos del Sistema Integrado de Salud hacia el subsistema Laboratorio Clínico v2.0. 3.1.5 Componentes Transversales  Exception Handling Application Block Conjunto de librerías de clases que permite procesar excepciones que ocurren a través de las capas de la arquitectura de la aplicación. 51  Configuration Handler Conjunto de librerías de clases que provee una solución para manejar información de configuración a través de la aplicación. Específicamente, el Configuration Handler provee un método simple para recuperar información de configuración. Así por ejemplo, a través de estas librerías se controló y uniformó la configuración de los formularios. 3.2 ARQUITECTURA DEL SUBSISTEMA A continuación se muestra el diagrama de despliegue diseñado para el producto: Figura 3.4: Diagrama de Despliegue del sistema  Usuarios Son usuarios internos del subsistema que van a ingresar mediante la LAN Interna. Estos usuarios son: Laboratoristas, Médicos y Auxiliares. 52  Zona Segura Servidor de Aplicaciones: Es el servidor que aloja los componentes de lógica de negocios, lógica de acceso a datos y los agentes de servicios que incluye los servicios Web y COM+. Servidor de Base de Datos: Es el servidor de base de datos SQL Server 2000 o superior disponible en la implementación. 3.2.1 Relación con otros subsistemas El Subsistema Laboratorio Clínico brindó y recibió servicios de otros subsistemas del Sistema Integrado de Salud. Estos servicios se dieron a través de COM+ y WebServices. A continuación se muestra la relación entre el Subsistema Laboratorio Clínico v2.0 y los servicios que reciben. Figura 3.5: Diagrama de los servicios que recibe el Subsistema Laboratorio Clínico En esta figura se puede apreciar que se reciben servicios de los subsistemas Historial Clínico, Recursos Humanos, Vocabulario y Seguridad. En este sentido: 53  El subsistema Historial Clínico brinda servicios de consulta de pacientes internos para poder así gestionar sus solicitudes en el Subsistema Laboratorio Clínico v2.0.  El subsistema Recursos Humanos brinda servicios de consulta del personal que trabaja en el Laboratorio. De esta manera, se podrá a asignar los horarios que le corresponde a cada laboratorista.  El subsistema Vocabulario brinda servicios de consultas de términos reconocidas por la entidad de salud.  El subsistema de Seguridad brinda servicios de acceso para validar y verificar los usuarios para el subsistema Laboratorio Clínico v2.0  Por otro lado, el subsistema Laboratorio Clínico v2.0 brinda servicios a los subsistemas Consultorio Externo y Unidad de Cuidados Intensivos (UCI) Figura 3.6: Diagrama de los servicios que brinda el Subsistema Laboratorio Clínico 54 A los subsistemas Consultorio Externo y Unidad de Cuidados Intensivos (UCI) se les brinda el servicio Registrar Solicitud. Adicionalmente, se le brinda al subsistema de Unidad de Cuidados Intensivos (UCI) los servicios de consultas para obtener los resultados de exámenes mediante el identificador de la solicitud o el paciente/fecha 55 56 CAPÍTULO 4: DISEÑO DETALLADO DEL PRODUCTO 4.1 DISEÑO DEL SUBSISTEMA El diseño del Subsistema Laboratorio Clínico se dividió en tres capas: Capa de presentación, de lógica de negocio y de acceso a datos. 4.1.1. CAPA DE PRESENTACIÓN Conformada por formularios que heredan sus atributos y eventos de dos formularios bases: FrmBaseAdministracion y FrmBaseGeneral. El FrmBaseAdministracion es utilizado por los formularios encargados de la administración de exámenes, insumos, muestras, paciente externos y solicitudes. El formulario contiene funciones orientadas a la administración tales como ingreso, modificación, actualización y eliminación. El FrmBaseGeneral es utilizado por los demás formularios y contiene características comunes a todos los formularios tales como los campos relacionados a los datos del usuario que ingresa al sistema cuando este se loguea. El FrmBaseAdministracion hereda del FrmBaseGeneral. 57 A continuación el listado de los demás formularios utilizados en el Subsistema  FrmAdministrarExamenes Permite registrar, actualizar, eliminar (deshabilitación del estado Habilitado) y consultar los exámenes de laboratorio que el Laboratorio Clínico tendría disponible en un periodo de tiempo  FrmAdministrarMuestra Permite registrar, actualizar, eliminar (modificación del estado Habilitado) y consultar las muestras utilizadas para los exámenes  FrmAdministrarPacienteExterno Permite registrar, actualizar, eliminar (modificación del estado Habilitado) y consultar pacientes externos. Los pacientes externos son aquellos que solicitan análisis de exámenes sin tener una orden interna del hospital  FrmAdministrarSolicitud Permite registrar, actualizar, eliminar (modificación del estado Habilitado) y consultar solicitudes. Las solicitudes están conformadas por exámenes, los cuales están conformados por análisis, y su mantenimiento es a través de este formulario  FrmAsignarLaboratoristas Permite asignar los horarios de los laboratoristas del Laboratorio Clínico  FrmLogin Permite el ingreso del personal del Laboratorio Clínico al Subsistema a través de un servicio proporcionado por el Subsistema Seguridad. Este servicio realiza la validación y verificación del usuario 58  FrmMenu Permite el acceso a todos los formularios que implementan los requerimientos funcionales del Subsistema  FrmRegistrarResulSolExam Permite registrar los resultados de los exámenes ingresados. En caso los resultados sean de exámenes ingresados por el Subsistema de Unidades de Cuidados Intensivos, en cuanto los resultados sean registrados se le enviaría este estatus para que pueda luego acceder a los resultados de los mismos.  FrmResultadoConsulta Permite mostrar los resultados de consultas utilizados en el Subsistema tales como: consulta de pacientes, médicos, solicitudes, etc.  FrmValidarResultadoExamen Permite registrar la validación de los resultados de los exámenes. La validación de los exámenes es el paso final antes de entregar los resultados al paciente. Figura 4.1: Diagrama de Interfase SeguridadUtils.FormSeguro 59 Figura 4.2: Diagrama de Interfase frmBaseGeneral Figura 4.3: Diagrama de Interfase LIUIMantenimiento 60 Figura 4.4: Diagrama de Controladora LIUCtrlInstancia 4.1.2 CAPA DE LÓGICA DE NEGOCIO La capa de negocio del Subsistema Laboratorio Clínico esta conformada por los siguientes componentes  Lógica de Negocio Se encarga de presentar las funcionalidades internas del negocio, es decir, maneja procesos internos del negocio, como el manejo de las solicitudes de análisis, la administración de pacientes externos, manejo de resultados y asignación de laboratoristas 61 Figura 4.5: Diagrama de Componentes de Negocio 62  Servicios Web Son los servicios Web que son invocados por las clases controladoras en la capa de presentación. Se encargan de transmitir las invocaciones de las controladoras de capa de presentación a las interfaces de servicios.  Interfaces de Servicios Se encargan de presentar las funcionalidades del negocio como servicios, las cuales se caracterizan por soportar contratos de comunicación (comunicación basada en mensajes, formatos, protocolos, etc.) que sus consumidores requieren.  DataSets Tipificados Son objetos de transferencia de datos que se encuentran implementadas como entidades de negocio. 63 Orden de Pago Paciente Externo Fecha Nacimiento : DATE Numero Documento : VARCHAR(255) Lugar Nacimiento : VARCHAR(255) Telefono : VARCHAR(255) Paciente_ID : INTEGER Codigo : INTEGER Estado : INTEGER Orden de Pago_ID : INTEGER Muestra Analisis General Codigo : INTEGER Codigo : INTEGER Nombre : VARCHAR(255) Nombre : INTEGER Cantidad Extraida : VARCHAR(255) Unidad de Medida : VARCHAR(255) Muestra_ID : INTEGER Analisis General_ID : INTEGER Insumo Particular Codigo : INTEGER Fecha Compra : DATE Estado : SMALLINT Analisis General_ID : INTEGER Muestra_ID : INTEGER Insumo General_ID : INTEGER Solicitud de Examenes Codigo : SMALLINT Solicitud de Examenes_ID : INTEGER Paciente_ID : INTEGER Medico_ID : INTEGER <<dataset>> DSLaboratorioClinico Insumo General Codigo : VARCHAR(255) Nombre : VARCHAR(255) Precio : DOUBLE PRECISION Insumo General_ID : INTEGER Examen X Solicitud Codigo : INTEGER Estado de Validacion : SMALLINT Estado de Ejecucion : VARCHAR(255) Examen General_ID : INTEGER Solicitud de Examenes_ID : INTEGER ELaboratorista_ID : INTEGER Orden de Pago_ID : INTEGER ELaboratorista Medico Examen General Codigo : VARCHAR(255) Nombres : VARCHAR(255) Apellido Paterno : VARCHAR(255) Apellido Materno : VARCHAR(255) Medico_ID : INTEGER Codigo : INTEGER Nombre : VARCHAR(255) Examen General_ID : INTEGER Analisis Particular Codigo : INTEGER Valor Maximo : INTEGER Valor Minimo : INTEGER Valor Obtenido : INTEGER Observacion : VARCHAR(255) Analisis General_ID : INTEGER Muestra_ID : INTEGER ELaboratorista_ID : INTEGER Codigo : VARCHAR(255) Nombres : VARCHAR(255) Apellido Paterno : VARCHAR(255) Apellido Materno : VARCHAR(255) ELaboratorista_ID : INTEGER Figura 4.6: Diagrama del dataset tipificado DSLaboratorioClinico 4.1.3 CAPA DE ACCESO A DATOS La capa de acceso a datos del Subsistema Laboratorio Clínico está conformado por: 64  Lógica de Acceso a Datos No Transaccional Son los componentes que permiten el acceso a los datos de manera no transaccional. Es decir, son usados para el acceso del tipo solo lectura de acuerdo a determinadas especificaciones de consultas. Figura 4.7: Diagrama de Agentes de Servicios Interfaces No Transaccionales Transaccionales Figura 4.8: Diagrama de Distribución de Interfaces 65  Lógica de Acceso a Datos Transaccionales Son los componentes que permiten el acceso a los datos de manera transaccional. Es decir, son usados para el acceso del tipo escritura sobre la información. Este acceso se basa en la ejecución de procedimientos almacenados en el repositorio de datos.  Data Access Application Block Componentes provistos por Microsoft para realizar el manejo del acceso a datos en el subsistema.  ADO.NET Librería de clases que conforman un modelo de acceso primario a base de datos relacional para aplicaciones basadas en Microsoft .NET. Los componentes de esta librería son usados para acceder a fuentes de datos las cuales tienen un proveedor específico para .NET o vía un proveedor puente a .NET. Estos proveedores específicos pueden ser proveedores OLE DB, un driver ODBC, un driver JDBC, un driver Oracle, o un proveedor nativo de la tecnología Microsoft como SQL Server. Para el caso, esta aplicación usará el SQL Server 2000 o superior.  Agente de Servicios Son los componentes que van a realizar los llamados, recuperación y adaptación de la información de los servicios proporcionados por los otros subsistemas del sistema de Salud hacia el Subsistema Laboratorio Clínico. <<subsystem>> Agentes de Servicio <<subsystem>> Logica de Acceso a Datos 66 Figura 4.9: Diagrama de Capa de Acceso a Datos 4.2 DISEÑO DE LA BASE DE DATOS El Subsistema Laboratorio Clínico necesita utiliza un motor de base de datos. Este permite la persistencia de datos almacenados a través de la aplicación. El diseño de la base de datos consiste en reflejar las entidades de negocio como tablas; asimismo, reflejar cada atributo de estas entidades como columnas de las tablas. Las relaciones entre estas tablas deberán estar normalizadas para evitar redundancia de datos. 67 Figura 4.10: Diagrama de Diseño Lógico de Base de Datos 68 69 CAPÍTULO 5: CONSTRUCCIÓN 5.1 MAPEO DEL DISEÑO DE LA IMPLEMENTACIÓN Los componentes diseñados, los cuales han sido especificados en capítulos anteriores, fueron desarrollados de la siguiente manera:  LIU: En este componente se encuentra el detalle de la implementación de la capa de presentación al usuario: Formas Base, Formas Hijas e Interfaces. Figura 5.1: Formularios de la Capa de Presentación 70  LN: Este componente detalla las clases que contienen la implementación de la lógica de negocio de la solución. Figura 5.2: Clases de la Capa de Lógica de Negocio  AgenteServicio: Este componente se encarga de realizar las llamadas a los servicios brindados por otros módulos y que son utilizados por el Subsistema Laboratorio Clínico v2.0 71 Figura 5.3: Clases del componente AgenteServicio  ConfigurationHandler: Este componente se encargó de proporcionar un método simple para recuperar información de configuración. Figura 5.4: Clases del componente Configuration Handler  Controladoras: Este componente se encarga de entablar una comunicación entre la capa de Lógica de Negocio y la capa de Interfaz de Usuario. 72 Figura 5.5: Clases del componente Controladoras  EntidadesEmpresariales: En este componente se detalla la organización de la data, datasets tipificados, de la aplicación. Figura 5.6: Datasets del componente Entidades Empresariales  Excepcion: Este componente se encarga de realizar todas las validaciones de excepciones que se realizan en la solución. 73 Figura 5.7: Clases del componente Excepción  HelpersyUtilitarios: En este componente se detallan todas las validaciones y el manejo de controles de la aplicación. Figura 5.8: Clases del componente HelpersyUtilitarios  InterfazServicio: En este componente se encuentran desarrollados los WebServices que han sido desarrollados por el módulo Laboratorio Clínico v2.0 a los módulos Unidad de Cuidados Intensivos y Consultorio Externo. 74 Figura 5.9: Clases del componente InterfazServicio  LAD: Este componente contiene las clases de acceso a datos, tanto transaccionales como no transaccionales, así como las interfaces bases transaccionales y no transaccionales. Figura 5.10: Clases de la capa de Acceso a Datos 75  NRServicios: Este componente detalla el uso de servicios mediante NetRemoting, específicamente del módulo de Unidad de Cuidados Intensivos. Figura 5.11: Clases del Componente NRServicios  PruebaCom: En este componente se implementa el servicio mediante COM+ desarrollado por el subsistema Laboratorio Clínico v2.0 a los módulos Unidad de Cuidados Intensivos y Consultorio Externo. Figura 5.12: Clases del Componente PruebaCom 76  Seguridad: En este componente se detalla la implementación para la integración con el módulo de Seguridad. Figura 5.13: Clases del Componente Seguridad 5.2 ESTÁNDARES DE FUNCIONALIDAD Para la implementación del Subsistema Laboratorio Clínico se consideró la funcionalidad en común de los casos de uso. Así, en base a ello se diseño clases bases de la cual heredarían otras clases. De esta manera, se simplificaría tanto el desarrollo como el mantenimiento de las clases. 5.3 ESTÁNDARES DE CODIFICACIÓN DE LA BASE DE DATOS Los estándares de codificación utilizados son los especificados por la propuesta técnica para el desarrollo de proyectos del Gerente Técnico Aarón Ibáñez Werthermänn. En esta propuesta se especifica como nombrar a la base de datos, procedimientos almacenados, parámetros, índices, restricciones, valores por omisión 77 (defaults), triggers, funciones y vistas. Para mayor detalle ver Anexo I ESTÁNDARES DE CODIFICACIÓN DE LA BASE DE DATOS. 78 79 CAPÍTULO 6: PRUEBAS DE SOFTWARE 6.1 AMBIENTE DE PRUEBAS Las pruebas se realizaron en un ambiente especial para ello. Los equipos utilizados para esta tarea contaban con las siguientes aplicaciones:  Máquinas Pentium 4 con 2.18 Ghz, 512Mb de memoria RAM y 80Gb de disco duro.  Sistema operativo Windows XP Profesional ó 2000 Professional.  Herramientas CASE proporcionadas por IBM Rational Software 6.2 ESTRATEGIA DE PRUEBAS El proceso de pruebas empezaba con la entrega al equipo de pruebas del caso de uso terminado de acuerdo a las fechas especificadas en el plan de pruebas. El equipo de pruebas estaba conformado por dos recursos del curso Taller de Desarrollo y Pruebas y desarrollaba las estrategias de pruebas aplicando herramientas para ese fin proporcionadas por IBM Rational Software. 80 Los errores encontrados por el equipo de pruebas eran tratados de la siguiente manera: 1. Cuando un error era registrado, se generaba una notificación vía mail al equipo de desarrollo. El estado del error era “Registrado”. 2. En caso no fuera un error, luego del análisis del equipo de desarrollo, el error pasaba al estado “Rechazado”. En caso fuera un error, se definía si es que la resolución del error era prioritaria para la iteración vigente. En caso no fuera prioridad el error pasaba al estado “Pospuesto”. 3. En caso el error tuviera el estado “Pospuesto” o fuera prioritario para la iteración, el error era resuelto por el equipo de desarrollo. El error pasaba al estado “Resuelto”. 4. Cuando el error estaba en el estado “Resuelto”, el equipo de pruebas procedía a verificar que el error haya sido realmente corregido. Dependiendo de eso, el error pasará al estado de “Cerrado” o “Abierto”. Esta secuencia se repetía hasta que el estado del error sea cerrado. La secuencia de estados antes explicada, se registraba en la herramienta Racional Clear Quest. Esta herramienta informaba al equipo de proyecto cada cambio en los estados de los incidentes identificados durante la fase de pruebas. 81 Figura 6.1: Diagrama de estados de un error reportado Las pruebas se enfocaban en varios tipos de entregables de acuerdo a la iteración vigente. En la etapa de elaboración y concepción las pruebas se hicieron en la documentación del proyecto. En la etapa de construcción se hacia sobre las versiones del aplicativo; mientras que en la etapa de transición se hacia sobre los instaladores. Al final de cada iteración el equipo de pruebas entregaba el Reporte General de Defectos que mostraba el resumen de los errores tratados. 82 Figura 6. 2: Diagrama de cambio de estados de defectos por semana 6.3 IDENTIFICACIÓN DE LAS PRUEBAS Para la identificación de los flujos de pruebas a utilizar (flujos básicos y alternativos), el equipo de proyecto se basaba en la especificación del caso de uso. Este procedimiento se realizaba con la herramienta IBM Rational RequisitePro. Así, por ejemplo, durante la etapa final de la implementación se obtuvo los siguientes resultados De 98 errores registrados inicialmente, estos tuvieron la siguiente severidad: 03→ Crítico 18→ Alta 04→ Promedio 61→ Baja 83 12→ Sugerencia Estos errores se distribuyeron de la siguiente manera de acuerdo a su tipo 03→ Errores de Integración 05→ Errores de Interfaz de Usuario 12→ Funcionalidad Incorrecta 01→ Funcionalidad Incompleta 77→ Documentación En la semana final de la iteración, todos los errores tenían el estado de Cerrado. Para más detalle de los errores mostrados ver Detalle en Anexo II REPORTE GENERAL DE DEFECTOS 6.4 PRUEBAS PLANEADAS Las pruebas que se planearon fueron las siguientes: a. Pruebas de Integración Se enfoca en validar la correcta comunicación entre el Subsistema Laboratorio Clínico y los demás submódulos de Salud. La comunicación entre los submódulos se llevaba a cabo mediante servicios. b. Pruebas de Interfaz de Usuario Se enfocaba en validar si las interfases eran amigables e intuitivas para la navegación del usuario c. Pruebas de Despliegue de Sistema Se enfocó en validar que las tres capas del subsistema pueden comunicarse en 3 lugares físicamente distintos. 84 d. Pruebas de Integridad de Base de Datos Se hicieron con la finalidad de evaluar la confiabilidad e integridad de los datos. Para ello se crearon escenarios especiales para estas pruebas. e. Pruebas de Aceptación Estas pruebas tenían como finalidad asegurar que el Subsistema Laboratorio Clínico cumpla con los requerimientos especificados por el usuario. Estas pruebas se realizaron a lo largo de toda la implementación y en las etapas finales de cada una de las iteraciones. 85 86 CAPÍTULO 7: GESTIÓN DEL PROYECTO 7.1 PLAN DE FASES La gestión de proyectos consiste en organizar, planificar, supervisar y administrar recursos de manera que se pueda culminar el trabajo requerido. De esta manera, se consideró, para el Subsistema Laboratorio Clínico v2.0, las siguientes fases: Figura 7.1: Diagrama de plan de fases del proyecto 87 7.2 PLAN DEL PROYECTO Cada fase del proyecto, fue analizada y evaluada por el Comité de Proyecto, el Gerente de Proyecto, el Jefe de Proyecto, Jefe del Producto y Arquitecto. Cada uno de estos roles estaban representados por las autoridades mostradas en el siguiente cuadro Rol Nombres Comité de proyecto Ludvick Medic, Ilver Anache y Rosario Villalta Gerente del proyecto Miguel Arrunátegui Jefe de Proyecto Ilver Anache Jefe del Producto Jorge Cabrera Arquitecto Aarón Ibáñez Integrantes del Subsistema Mariana Segura Laboratorio Clínico Giuliana Veli Tabla 7.1: Roles de Integrantes del Proyecto Para definir el alcance del proyecto, el equipo de dirección del proyecto definió la siguiente Estructura de Desglose de Trabajo (EDT – WBS: Work Breakdown Structure): 88 Figura 7.2: Diagrama de plan de fases del proyecto 89 7.2.1 FASE CONCEPCIÓN Dentro de la gestión de proyectos de software, la fase de comprensión del negocio y levantamiento de requerimientos, es decir, la fase de concepción, se considera una de las principales y críticas fases para la ejecución, desarrollo y finalización exitosa del proyecto. Para lograr los objetivos de levantamiento y análisis de requerimientos, el equipo de proyecto se reunió con los jefes y laboratoristas del laboratorio clínico del Hospital San José del Callao. En estas reuniones se obtuvo información sobre el giro del negocio y de sus principales actividades, así como de sus deficiencias y necesidades. Con esta información, complementadas con las reuniones con el cliente funcional, Ing. Jorge Cabrera, se definió, en una primera etapa, las principales funcionalidades del Subsistema Laboratorio Clínico v2.0. De esta manera, se definieron los siguientes entregables de esta fase:  Visión del Proyecto El propósito de este documento es obtener, analizar y definir características y necesidades de alto nivel del Subsistema Laboratorio Clínico v2.0. Además, trata las capacidades, beneficios y riesgos que este proyecto involucra. Está centrado en las necesidades de los stakeholders y los usuarios finales.  Especificaciones de Requerimientos de Software(SRS) Este documento tiene como objetivo describir de forma detallada los requerimientos funcionales y no funcionales presentes en el Subsistema Laboratorio Clínico v2.0.  Lista de Riesgos El propósito principal de este documento es dar a conocer al equipo de proyecto tanto los riesgos que podrían afectar el curso del proyecto como la manera de superar el impacto en caso de que ocurran. 90  Plan de Aceptación del Producto El presente documento enumera las características de los compromisos asumidos por el equipo del proyecto respecto al Producto que se va a desarrollar en el ciclo de vida del mismo. De igual manera, describe los criterios de aceptación con que los compromisos asumidos deben cumplir. Este plan provee clara y detalladamente información concerniente a expectativas en cuanto a actividades, recursos y tiempo invertidos para el desarrollo de los requerimientos dispuestos originalmente. Establece todas las funcionalidades que ofrece el Subsistema Laboratorio Clínico v2.0 y las responsabilidades asumidas tanto por el equipo de desarrollo como por el jefe de producto durante la realización del proyecto.  Plan de Desarrollo de Software El objetivo del plan de desarrollo de software es definir las actividades de desarrollo en términos de fases e iteraciones requeridas para implementar el Subsistema Laboratorio Clínico v2.0. El plan de desarrollo de software describe en forma general todo lo planificado para desarrollar el Subsistema Laboratorio Clínico v2.0 en base a los requerimientos definidos por el cliente.  Estimación del Proyecto La estimación del proyecto ha sido realizada en base al alcance del mismo, el tiempo que se tenía para completarlo y los recursos disponibles.  Reporte de Estado del Proyecto: Tiene como propósito presentar los objetivos logrados al cierre de la fase de concepción, así como el nivel de cumplimiento con el cronograma y los resultados de la iteración.  Plan de Iteración – Concepción 91 Este documento establece los principales hitos de la iteración de la fase de conceptualización especificando los artefactos desarrollados.  Plan de Iteración – Elaboración Este documento presenta la descomposición del proyecto en actividades o entregables. Su propósito fundamental es facilitar el logro de los objetivos de la fase.  Prototipo Visual Navegable Luego de obtener las funcionalidades del Subsistema Laboratorio Clínico v2.0 y la identificación de los casos de uso, se procedió a elaborar un prototipo navegable del flujo del subsistema. Este prototipo evolucionó en la siguiente iteración. Los riesgos identificados fueron los siguientes:  Variación del alcance del proyecto Implica que los requerimientos funcionales y no funcionales sean modificados. Esto significaría el incremento o disminución de requerimientos a implementar. Los impactos más relevantes serían los ocasionados al cronograma del proyecto, el cual generaría una variación en la fecha de entrega del mismo. Asimismo, esta modificación podría implicar cambios en artefactos ya entregados y aprobados. La estrategia de mitigación consiste en informar al cliente el impacto de los cambios propuesto (impacto). Esto, con la finalidad de negociar la anulación de dicha variación en el alcance. Los planes de contingencia propuestos consisten en: 1. Luego de una conversación con el equipo de proyecto se rechaza la idea de variar el alcance de proyecto debido a sus repercusiones en el cronograma del mismo. 92 2. Realizar los cambios en la variación del alcance, no sin antes informar al cliente y prever el impacto del mismo.  Falta de coordinación con los Subsistemas ADT, Facturación, Consultorio Externo, RRHH y UCI: Este riesgo consiste en que alguno de los subsistemas asuma la asignación de alguna funcionalidad (requerida como servicio por el Subsistema Laboratorio Clínico v2.0) y que no cumpla con el alcance y tiempo de ésta. El impacto más importante se ve reflejado en el retraso en el cronograma del proyecto. La estrategia de mitigación consiste en la realización de reuniones con los miembros del equipo de proyecto del subsistema que no cumple con el requerimiento asignado. El plan de contingencia propuesto consisten en tener reuniones con el jefe de proyecto y con el cliente para la definición de un nuevo alcance para el Subsistema Laboratorio Clínico v2.0.  Comunicación ineficiente con el cliente y/o el arquitecto: Falta de coordinación con el cliente y/o arquitecto para el seguimiento continuo y en conjunto del desarrollo del proyecto. El principal impacto consiste en el mal levantamiento y definición de los requerimientos del cliente y en la estructura de la arquitectura. La estrategia de mitigación consiste en la planificación de nuevas reuniones con el cliente y/o arquitecto. El plan de contingencia propuesto consiste en realizar un documento donde se informe de la situación surgida, los problemas que acarrean y una solicitud de solución a la brevedad posible. 7.2.2 FASE ELABORACIÓN El objetivo principal de esta fase es definir la arquitectura de software a utilizar para el desarrollo del Subsistema Laboratorio Clínico v2.0. Para verificar que la arquitectura definida es la apropiada, se desarrollo una prueba de concepto, que consistía en implementar uno de los flujos principales (Ver detalles en Capítulo 3) de las funcionalidades establecidas en el subsistema. El caso de uso elegido para la 93 prueba de concepto de la arquitectura fue Administrar Paciente Externo. Como entregables de esta fase se obtuvieron los siguientes documentos:  Especificaciones de Casos de Uso Este documento detalla para cada Caso de Uso el flujo básico, flujos alternativos y actores que utilizan el caso de uso.  Documento de Arquitectura del software (SAD) Este documento provee una visión general de la arquitectura del Subsistema Laboratorio Clínico v2.0, utilizando varias vistas para apreciar los diferentes aspectos del mismo. Está diseñado para capturar y cubrir las decisiones más significativas relacionadas con la arquitectura del Subsistema. Detalla la arquitectura propuesta por el equipo de proyecto y que contempla los principales casos de uso, pasando por las vistas de presentación, lógica, de despliegue y de implementación y el modelo de datos.  Plan de Pruebas Este documento detalla el planeamiento de las pruebas que se llevaran a cabo sobre el producto durante la primera fase de construcción.  Especificaciones Suplementarias Este documento complementa las especificaciones detalladas en el documento de especificaciones de software (SRS) del Subsistema Laboratorio Clínico v2.0.  Reporte de estado del proyecto Fase Elaboración Tiene como propósito presentar los objetivos logrados al cierre de la fase de concepción, así como el nivel de cumplimiento con el cronograma y los resultados de la iteración.  Plan de Iteración – Construcción 1 94 Este documento presenta la descomposición del proyecto en actividades o entregables según la fase que se encuentra, en este caso Construcción 1. Su propósito fundamental es facilitar el logro de los objetivos de la fase.  Modelo de base de datos: Modelo Erwin (vista lógica y física) de la primera versión de la base de datos. Adicionalmente, se elaboraron los siguientes modelos con la herramienta Rational Rose:  Modelo de Casos de Uso: Diagramas UML que permiten ver la interacción entre los actores y los casos de uso.  Modelo de análisis Diagramas de secuencia por cada caso de uso.  Modelo de la Arquitectura del software Diferentes Vistas de la arquitectura de software. Asimismo, los entregables de la fase de concepción fueron actualizados, redefiniendo, validando y explicando a mayor nivel de detalle los requerimientos levantados en la fase inicial del proyecto. Los riesgos identificados fueron los siguientes:  Falta de Estabilidad de la Arquitectura Software Propuesta En el caso que la arquitectura propuesta no sea estable, el impacto se implicaría directamente en la calidad del producto software y en el cronograma. El impacto en el cronograma del proyecto consiste en que una arquitectura no estable dificulta la 95 construcción del producto, por lo que correcciones posteriores retrasarían el cronograma planteado. La forma de mitigar este riesgo se realizó a través de la validación de la arquitectura mediante el desarrollo de la prueba de concepto, implementando uno de los casos de uso principales del producto. 7.2.3 FASE CONSTRUCCIÓN 7.2.3.1. Construcción 1 Esta fase tiene por objetivo generar el primer Release del producto. Este entregable cuenta con control de calidad (pruebas de software) y evaluaciones de iteración y planes de aceptación aprobados por el cliente funcional. Así como las validaciones realizadas por los Gerentes Técnico, de Producto y General del proyecto. Este primer release incluye los siguientes casos de uso:  CU1: Administrar Pacientes Externos  CU2: Administrar Lista de Exámenes  CU3: Asignar Horario a Laboratoristas  CU4: Administrar Solicitud de Exámenes Los riesgos de esta iteración fueron los siguientes: 7.2.3.2. Construcción 2 Esta fase tiene por objetivo generar el segundo Release del producto. Este release cuenta con control de calidad, evaluaciones de iteración y planes de aceptación aprobados por el cliente funcional, así como las validaciones realizadas por los Gerentes Técnico, de Producto y General del proyecto. Este segundo release incluye los siguientes casos de uso:  CU5: Registrar Solicitud de Exámenes 96  CU6: Registrar Resultados de Análisis  CU7: Rotular Muestras  CU8: Validar Resultados de Exámenes  CU9: Generar Reporte de Resultados de Exámenes  Documentación Completa Los riesgos de esta iteración fueron los siguientes:  Comprobación ineficiente de los servicios brindados a Historial Clínico En el desarrollo de esta iteración no existía un responsable asignado al subsistema Historial Clínico. Por esta razón, la comprobación apropiada de la funcionalidad del servicio Generar Reporte de Resultados de Exámenes no se pudo llevar a cabo debido a que es un servicio que el Subsistema Laboratorio Clínico v2.0 brinda al subsistema Historial Clínico. El principal impacto consiste en que el término validado del desarrollo del CU Generar Reporte de Resultados de Exámenes no se lleve a cabo. La estrategia de mitigación desarrollada consiste en simular un ambiente el cual requiera el servicio dado a Historial Clínico. 7.2.3.3. Construcción 3 Esta fase tiene por objetivo generar el Release Final del producto. Este entregable cuenta con control de calidad, evaluaciones de iteración y planes de aceptación aprobados por el cliente funcional, así como las validaciones realizadas por los Gerentes Técnico, de Producto y General del proyecto. Este Release Final incluye los siguientes casos de uso:  SB3.1: Consultar Lista de Solicitudes  SB3.2: Consultar Resultados de Exámenes  NR1: Actualizar Estado de Solicitud de Análisis 97  Documentación Completa Los riesgos de esta iteración fueron los siguientes:  Entrega de Servicios fuera de la fecha coordinada Los equipos de proyecto de otros subsistemas no entregan los servicios en la fecha establecida los contratos. El principal impacto de este riesgo afecta al desarrollo de los casos de uso programados en el Plan de Iteración de Construcción 3. Lo que implica un retraso en el desarrollo del proyecto e incumplir con los objetivos establecidos. La estrategia de mitigación consiste en verificar los contratos establecidos con los equipos de proyecto y con los gerentes. Así como la ejecución de reuniones de Status de Avance. Los planes de contingencia propuestos son: 1. Desarrollo de Dummies que simulen la función de los servicios solicitados. 2. Realización de cambios en el alcance del Proyecto. 7.2.4 FASE TRANSICIÓN La Fase Transición tiene como objetivo obtener los entregables Versión 2.0 del Producto Subsistema Laboratorio Clínico v2.0. La versión 1.0 del Producto incluye:  Instalador del producto  Manual de Instalación  Manual del Usuario  Documentación completa del proyecto. 98 Además se hizo la caja del software y una pancarta publicitaria que describía la tecnología en la que se basa el desarrollo del software Subsistema Laboratorio Clínico v2.0, a quien va dirigido el producto y sus principales funcionalidades. Los principales riesgos identificados en esta fase son:  Servicios de Historial Clínico, Vocabulario, Seguridad, Recursos Humanos y Unidad de Cuidados Intensivos (UCI) se encuentren inhabilitados En el desarrollo de esta fase, el equipo de Dirección de Proyectos del Sistema Integrado de Salud, con su equipo técnico, decidió realizar un cambio de servidores en los que se encontraban instalados los servicios del proyecto. Debido al cambio de servidor realizado, los servicios desarrollados en las iteraciones anteriores presentan complicaciones de integración con los subsistemas del proyecto. Este riesgo tiene un impacto en el cronograma del proyecto, lo cual implica el trabajo del equipo de Taller de Pruebas, en el cierre de los entregables, y finalmente en la presentación a los gerentes de producto y técnico, para su aceptación. La estrategia de mitigación desarrollada para este riesgo consistió en el incremento en los recursos asignados, por parte del equipo de Dirección de Proyectos, para corregir las complicaciones encontradas en estos cambios de servidores. 7.3 ESTIMACIONES La estimación del proyecto consiste en calcular cuánto tiempo y esfuerzo se requiere para construir y desplegar la solución propuesta. Para lograr este objetivo el equipo de proyecto utilizó la técnica Estimación por Casos de Uso. Esta técnica utiliza los actores y casos de uso identificados para calcular el esfuerzo necesario para que sean desarrollados. A cada caso de uso y actor se le asigna una complejidad, basada en transacciones y en el tipo de actor respectivamente (interfaces con usuarios, interfaces con otros sistemas, etc.). Para afinar el resultado se utilizan factores de entorno y de complejidad técnica. 99 Una vez asignada la complejidad de los actores y casos de uso y establecidos los factores técnicos y de entorno, se calcularon los Puntos de Caso de Uso no Ajustados (UUCP), el Factor de Complejidad Técnica (TCF) y el Factor de Entorno (EF). Con ellos, se calculan los Puntos de Caso de Uso (AUCP), que finalmente dan como resultado el Esfuerzo y las Horas-Hombre. Casos de Uso sin Ajustar (UUCP), permitió al equipo de proyecto tener una idea un poco más precisa de la dificultad de los casos de uso e interfaces, tomando en cuenta los pesos de los actores (UAW) y los pesos de los casos de uso (UUCW). Luego de haber hecho los cálculos respectivos, la distribución del Esfuerzo y Tiempo en Fases del Proyecto fue la siguiente: Fases del Esfuerzo Proyecto Tiempo Elaboración 5% 1.18 10% 0.83 Concepción 20% 4.74 30% 2.50 Construcción 65% 15.40 50% 4.16 Transición 10% 2.37 10% 0.83 100% 23.69 100% 8.32 Tiempo: 8.32 meses Tabla 7.2: Estimación del Esfuerzo y Tiempo del Proyecto Para mayor detalle del cálculo de la estimación, ver Anexo CÁLCULO DE LA ESTIMACIÓN DE LAS FASES PROYECTO El desarrollo del alcance del proyecto se realizó dentro del tiempo y el esfuerzo estimado. 100 7.4 PLAN DE GESTIÓN DEL CRONOGRAMA Una vez definido el alcance del proyecto, y la demanda en esfuerzo y tiempo, el equipo de proyecto definió el plan de gestión del cronograma, programando sus actividades dentro de los límites de tiempo del proyecto. En cada fase se definieron entregables, los cuales serán detallados en los siguientes cuadros. Para ver más detalles ver el Anexo PLAN DE GESTIÓN DEL CRONOGRAMA Fase Incepción: Esta etapa tuvo como objetivo plasmar la concepción del proyecto, generando así, los siguientes documentos: 101 1 Iteración Incepción Fase Inicio 15/08/2005 Fin 16/09/2005 Ítem Entregables Semana Plan de desarrollo del Fecha Entrega 19-sep-05 EI 1 Software 1 EI 2 Plan de Aceptación 1 19-sep-05 EI 3 Plan de Iteración 1 19-sep-05 EI 4 Lista de Riesgos 2 26-sep-05 EI 5 Modelo de casos de uso 2 26-sep-05 EI 6 SRS 2 26-sep-05 EI 7 SSS 3 2-oct-05 EI 8 Visión 4 9-oct-05 EI 9 Glosario 4 9-oct-05 EI 10 Evaluación de la iteración 4 9-oct-05 EI 11 Prototipo Visual 5 16-oct-05 EI 12 Estimación del proyecto 5 16-oct-05 Tabla 7.3: Plan de Cronograma de la Fase Incepción Fase Elaboración: En esta etapa, el principal objetivo fue generar una arquitectura la cual estuviera acorde con los requerimientos funcionales y no funcionales extraídos en la etapa de incepción. Los entregables que se presentaron fueron los siguientes: 102 2 Iteración Fase Elaboración Hito Arquitectura del Subsistema Inicio 24/10/2005 Fin 09/12/2005 Ítem Entregables Semana Fecha Entrega EE 1 Prototipo Visual 10 28-oct-05 EE 2 Modelo de casos de uso 10 28-oct-05 EE 3 Reporte de Estado del Proyecto 10 28-oct-05 EE 4 Especificación de Casos de Uso 10 28-oct-05 EE 5 Modelo de Análisis 11 4-nov-05 EE 6 Estimación del proyecto 11 4-nov-05 EE 7 SSS 11 4-nov-05 EE 8 Prototipo de Arquitectura de Software 12 11-nov-05 EE 9 Modelo de Arquitectura de Software (UML) 12 11-nov-05 EE Documento de Arquitectura de Software 10 (SAD) 18-nov-05 13 EE 11 18-nov-05 Plan de Desarrollo de Software 13 Tabla 7.4: Plan de Cronograma de la Fase Elaboración Fase Construcción: La fase de Construcción, se divide en 3 paquetes de trabajo, las cuales tuvieron como principal actividad, el desarrollo por casos de uso del producto propuesto: Construcción 1, Construcción 2, Construcción 3. Los entregables de cada paquete se detallan a continuación. 103  Construcción 1: 3.1 Iteración: Construcción Fase: Release 1 Hito Inicio 17/04/2006 Fin 01/05/2006 Ítem Entregables Semana Fecha Entrega CU1 Administrar Pacientes Externos 4 17-abr-06 CU2 Administrar Lista de Exámenes 4 17-abr-06 CU3 Asignar Horario de Laboratoristas 6 01-may-06 6 01-may-06 6 01-may-06 Administrar Solicitud de CU4 Exámenes Documentación Completa Tabla 7.5: Plan de Cronograma de la Fase Concepción – Release 1  Construcción 2: 3.2 Iteración: Fase: Hito Construcción Release 2 Inicio 16/06/2006 Fin 05/07/2006 Ítem Entregables Semana Fecha Entrega CU5 Registrar Solicitud de Exámenes 13 23-jun-06 CU6 Registrar Resultados de Análisis 13 23-jun-06 104 CU 7 Rotular Muestras 13 23-jun-06 CU8 Validar Resultados de Exámenes 14 30-jun-06 14 30-jun-06 15 05-jul-06 CU9 Generar Reporte de Resultados de Exámenes Documentación Completa Tabla 7.6: Plan de Cronograma de la Fase Concepción – Release 2  Construcción 3: 3.3 Iteración: Fase: Construcción Hito Release Final Inicio 21/08/2006 Fin 29/09/2006 Ítem Entregables Semana Fecha Entrega WS1 Consultar Lista de Solicitudes 3 28-ago-06 WS2 Consultar Resultados de Exámenes 3 28-ago-06 Análisis 6 18-sep-06 Documentación Completa 7 29-sep-06 Actualizar Estado de Solicitud de NR1 Tabla 7.7: Plan de Cronograma de la Fase Concepción – Release Final 105 Fase Transición: Finalmente, en la etapa de Transición, parte final del proyecto, el objetivo principal es la generación de medios por los cuales el producto desarrollado pueda ser implantado en un ambiente específico. Los productos entregables son los siguientes: 4 Iteración: Transición Fase: Producto Final Hito Inicio 23/10/2006 Fin 01/12/2006 Ítem ET 1 Entregables Memoria del Proyecto Semana 9 3-nov-06 Instalador del Producto 10 ET 3 10-nov-06 Manual de Instalación 11 ET 4 10-nov-06 Manual de Usuario 11 ET 5 Entrega 27-oct-06 ET 2 Fecha 17-nov-06 Documentación Completa del Proyecto 12 Tabla 7.8: Plan de Cronograma de la Fase Transición 106 7.5 REPORTES AL CIERRE Al término de cada iteración el equipo de proyecto presentó al Comité de Proyectos un reporte de cierre, en el cual se mostraba las actividades realizadas en la iteración y los productos entregables de la misma. El encargado de revisar estos reportes era el Cliente Funcional, el cual validaba el resultado de la iteración con el plan entregado al inicio de la misma. El equipo de proyecto, en todas las iteraciones, culminó a tiempo lo planificado en los Planes de Iteración, respetando entregables, tiempos y alcance de los casos de uso descritos en las especificaciones correspondientes. 107 108 CAPÍTULO 8: TRANSICIÓN En esta etapa del proyecto se hicieron los manuales, instaladores y la publicidad del sistema. A continuación se describe los entregables finales del proyecto.  Instaladores Los instaladores se hicieron con Microsoft Visual Studio 2003 y se hizo uno para la capa de presentación y otro para la instalación de la base de datos Figura 8.1: Instalador Servidor 109 Figura 8.2: Instalador Cliente  Manuales Durante la implementación del Subsistema Laboratorio Clínico v2.0 se hicieron tres manuales: o Manual de Instalación del Cliente o Manual de Instalación del Servidor o Manual de Usuario. Los dos primeros guían al usuario en los pasos a seguir para poder instalar el producto, tanto la capa de presentación (formularios) como la capa de acceso a datos (servidor) respectivamente. El tercer manual explica la funcionalidad de los diferentes casos de usos del Subsistema a detalle.  Publicidad Durante la implementación del Subsistema Laboratorio Clínico v2.0 se hizo un póster con la publicidad del subsistema. 110 Este póster tiene como objetivo reflejar las principales características del subsistema como sus principales funcionalidades y a quienes está dirigido Figura 8.3: Póster del Subsistema Laboratorio Clínico 111  Caja Contiene los instaladores de cliente y servidor; manuales de cliente, servidor y usuario y la documentación del producto  Diapositivas Al final de cada iteración se desarrollaban presentaciones las cuales resumían los puntos más resaltantes del proyecto en esta etapa tales como: objetivos, riesgos y resultados.  Prerrequisitos Antes de instalar el Subsistema Laboratorio Clínico v2.0 es necesario instalar el cliente de Historial Clínico y de Seguridad 112 113 CONCLUSIONES  El equipo de Proyecto del Subsistema Laboratorio Clínico V2.0 considera que el aspecto más importante y rescatable en el transcurso del proyecto, es la experiencia obtenida frente a la simulación de una empresa desarrolladora de software.  El trabajo bajo presión, la solución rápida de problemas inesperados, la interacción constante con jefes de otros proyectos, equipos de pruebas, equipos de desarrolladores y gerentes del proyecto en general, nos permite aprender, mediante la experiencia, como desenvolvernos frente a distintas situaciones comunes de un proyecto de desarrollo de software.  La concepción de un proyecto desde el inicio, nos permite aplicar conocimientos teóricos adquiridos en ciclos anteriores y verificar la utilidad de los mismos, así como la derivación, a partir de estos, de nuevas soluciones provechosas frente a un caso real.  Un proyecto de software es viable cuando se detectan oportunidades comerciales y cuando el impacto del proyecto sobre el negocio genera utilidades y eficiencia.  El mapeo de los requerimientos funcionales y no funcionales con la arquitectura propuesta, es uno de los aspectos más importantes, para determinar la eficiencia del producto y la satisfacción del cliente.  La planificación de la gestión del proyecto, es una actividad fundamental, para poder controlar el desarrollo normal del proyecto, así como los factores externos que afectan el mismo.  Los estándares de programación, interfaces, bases de datos, etc. forman parte de un aspecto importante y relevante para la integración entre módulos y protocolos de comunicación. 114  La selección de una metodología de desarrollo viable para el proyecto ocupa un lugar importante en el éxito del mismo, ya que basándose en ella, el proyecto podrá alcanzar los objetivos planteados inicialmente.  Una buena gestión de riesgos en el desarrollo de un proyecto garantiza que las estimaciones iníciales calculadas, tengan variaciones mínimas y el impacto sea manejable.  Las pruebas realizadas sobre un producto software, son de vital importancia para determinar la calidad del mismo. Obviar este proceso, además de impactar fuertemente en el esfuerzo, tiempo y alcance del proyecto, disminuye en gran escala su calidad.  Al finalizar un proyecto de software, la verificación y validación de los requerimientos, funcionalidades y pruebas determinan en gran escala la aceptación del producto final. 115 RECOMENDACIONES Para una siguiente versión del producto, se recomienda:  Implementar las siguientes funcionalidades: Consultar Solicitudes Pagadas por Paciente Externo y Administrar Insumos.  Desarrollar los siguientes servicios: Registrar Solicitud Pendiente de Pago y Consultar Solicitudes Pagadas por Paciente Externo.  Estas funcionalidades y servicios se encuentran descritos en el Capitulo 2: Requerimientos del Software.  El taller de pruebas debería incorporar las pruebas de carga y estrés, para verificar la buena performance del producto.  Integrar el producto con el módulo de Seguridad a nivel de perfiles, de manera que cada usuario del Subsistema Laboratorio Clínico v2.0 tenga un perfil, y con esto diferentes niveles de acceso. Esta integración también permitirá llevar un registro de que usuario hace actualizaciones, registros y/o consultas en el Subsistema. 116 BIBLIOGRAFÍA ARROYO, Juan 2002 La Salud peruana en el siglo XXI: retos y propuestas de política Lima: Consorcio de Investigación Económica y Social ISBN 9972804216 ASAMBLEA NACIONAL DE RECTORES (ANR) 2001 (http://www.anr.edu.pe/ ) Se presentan las últimas estadísticas universitarias con datos relacionados a las universidades, alumnado, docentes, graduados y titulados. JACOBSON, Ivar 2000 El Proceso Unificado de Desarrollo de Software. Madrid: Pearson Educación ISBN: 84-7829-036-2 INSTITUTO NACIONAL DE SALUD 2007 Memoria Anual 2007 Lima: INS ISBN: 99934-821-9-6 117 MICROSOFT CORPORATION 2002 Developing Microsoft ASP.NET Web Applications using Visual Studio .Net. Florida: Microsoft Press ISBN: 0735615950 MINISTERIO DE SALUD DE CHILE (MINSAL) 2003 www.minsal.cl/juridico/433_DE_1993.doc Sitio Web Oficial del MINSAL; contiene información sobre la clasificación de laboratorios clínicos en las entidades de salud (consulta: 8 de Junio 2009) MINISTERIO DE SALUD: DIRECCION GENERAL DE MEDICAMENTOS, INSUMOS Y DROGAS 2009 http://www.digemid.minsa.gob.pe/decvs/uni_evaluacion/redlaboficoncal.html Sitio Web Oficial del DIGEMID; contiene información sobre la red de laboratorios oficiales del Perú (consulta: 8 de Junio 2009) ORGANIZACIÓN PANAMERICANA DE LA SALUD 2003 Análisis y Tendencias en la utilización de Servicios Salud Perú 1985 – 2002 Lima: Ministerio de Salud ISBN: 9972785858 118 ORTIZ DE ZEVALLOS, Gabriel 2000 Salud Lima: Instituto Apoyo ISBN: 9972-814-06-8 RUMBAUGH, James 1999 The Unified Modeling Language: Reference Manual. Massachuset: Addison-Wesley ISBN 0-201-30998-X STEVENS, Perdita y POULEY, Rob 2002 Utilización de UML en la ingeniería del software con objetos y componentes. Madrid: Pearson Educación ISBN 84-7829-054-0 UNIVERSIDAD CENTRO OCCIDENTAL LISANDRO ALVARADO 2009 ww.ucla.edu.ve/dac/Departamentos Sitio Web Oficial de UCLA; contiene investigaciones sobre historia y principales problemas en el procesamiento de datos (consulta: 8 de Junio 2009) 119 120 ANEXOS 121 ESTÁNDARES DE INTERFACES GRÁFICAS DEL SISTEMA INTEGRADO DE SALUD El Sistema Integrado de Salud especifica los siguientes estándares para las interfaces gráficas: 1. Formulario  Color : Cornsilk 2. Casilla de Grupo  Fuente o Color : OliveDrab o Tamaño : 9 o Tipo : Microsoft Sans Serif  Color : Cornsilk 3. Casillas de Texto  Estilo del Borde : FixedSingle 4. Botones  Color : OliveDrab  Fuente o Color :Cornsilk o Alineación : MiddleCenter  Estilo : FlatStyle 5. Grillas  Fuente 122 o Color : Cornsilk  Fondo o Color : OliveDrab 6. Tabulador  Fondo o Color  : Cornsilk Fuente o Tamaño : 9 o Tipo Casilla de Grupo : Microsoft Sans Serif Botón Casilla de Texto Formulario Tabulador 123 Grilla 124 ESTANDARES DE CODIFICACIÓN DE LA BASE DE DATOS Nomenclatura de Base de Datos y Archivos de Datos Una Base de Datos incluyendo sus archivos deberá ser creada de acuerdo con la siguiente especificación: Código db_01 Nombre Categoría Especificación Toda base de datos deberá utilizar como prefijo db_ seguido del nombre del Compañía y el nombre del Area (para aplicaciones Nomenclat Database integradas). Todo esto en ura de una Especifica conjunto formará el nombre Base de tion de la Base de Datos. Datos Ejemplo db_EscBusinessSale s (Representa a una base de datos localizada en el Área de Ventas) db_EscBusiness (Representa a una base de datos central corporativa) Grupos de Archivos (SQL Server, Sybase) db_02 & Database Files Los archivos que conforman una base de datos deberán Predeterminado ser creados bajo la siguiente DatabaseName_Dat especificación: a - Prefijo Sys: Para archivos que agrupan elementos del (Elementos del sistema. Negocio y sistema) Espacios de Tablas - Prefijo Log: Para archivos que agrupan logs DatabaseName_Log transacciones. (Oracle) - Prefijo Usr: Para archivos (Elementos del Log que agrupan elementos de de Transacciones) usuario. 125 Código Nombre Categoría Especificación Ejemplo - Nombre: Debe ser definido de la siguiente Lógica de Negocios manera: Central Corporativa. Para Bases de datos por Sys_EscBusiness Áreas o aplicaciones integradas (Elementos del Sistema) Utilizar simplemente un criterio de agrupación de archivos por lógica de Log_EscBusiness negocios, tal como: Compañía: Referido nombre de la empresa. al (Elementos del Log de Transacciones) Área: Referido al nombre de un área de negocio, siempre y cuando la BDs contemple un ERP o un dominio de aplicación extenso. Por ejemplo: Sales Usr_Business (Elementos del Negocio) Lógica de Negocios Por Areas. Sys_EscBusinessSal es (Elementos del Sistema) Log_EscBusinessSa les (Elementos del Log de Transacciones) Usr_EscBusinessSal es1 (Grupo de Archivos 1 para Ventas) 126 Código Nombre Categoría Especificación Ejemplo Usr_EscBusinessSal es2 (Grupo de Archivos 2 para Ventas) Usr_EscBusinessPu rchase (Sistema de Compras) Nomenclatura de Objetos de Definición de Datos Los objetos de definición de datos están conformados por todos aquellos que definen la estructura y comportamiento de los datos como son las tablas, columnas, índices y valores por omisión. Todos estos objetos deberán tener la nomenclatura bajo la siguiente especificación: Código db_03 Nombre Definición de Tablas Categoría data objects Especificación Ejemplo Para definir el nombre de una Sal_Customer tabla deberá considerarse la (Representa a la siguiente norma: tabla Cliente, - Prefijo: Utilizar como prefijo perteneciente al las iniciales del nombre del área de Ventas) área, proyecto ó módulo Ejemplo: Pur, Sal, Acc. - Nombre: Referido a la entidad que representa la tabla. Por ejemplo: Customer. db_04 Definición de data objects Para columnas Para definir el nombre de una con nombres tabla deberá considerarse la simples: 127 Código Nombre Categoría Columnas Especificación Ejemplo siguiente norma: - Claves primarias y foráneas: cliente_id Utilizar como nombre la conjunción en minúscula del nombre nombre de la tabla, seguido del descripcion sufijo _id. - Columnas de datos: deben telefono contener el nombre del dato que almacenan. Por ejemplo: descripcion, telefono, edad. Importante: Los nombres de las columnas deberán obedecer el alfabeto inglés, es decir deben incluir caracteres de la A-Z y números 0-9. También es recomendable no incluir el nombre de la tabla como parte del nombre de la columna ya que esto queda implícito al estar la columna incluida en la tabla db_05 Definición de índices data objects Para columnas con nombres compuestos: nombre_corto nombre_largo Un índice es un elemento idx_ProductoN principal en toda tabla que se ombre utiliza para agilizar el proceso de búsqueda de uno o más registros donde el índice especificados. contiene a los - Prefijo: Todo índice deberá siguientes crearse utilizando el prefijo campos en orden idx_, seguido del nombre de la de precedencia: tabla y el nombre del índice. - Nombre: Deberá ser una palabra que esté asociada a la definición del mismo. Por ejemplo: Si se crea un índice - descripcion - categoria_id 128 Código Nombre Categoría Especificación de cobertura (compuesto) en una tabla de productos estándar sobre los campos: descripcion, estado y categoria_id. Se deberá tener presente dos cosas: Ejemplo No se toma en cuenta la columna estado porque no es muy selectivo. Si el estado maneja N valores, tendrá una densidad igual a: a) Un índice se crea sobre las columnas que son referenciadas en la cláusula Where y Order By de las sentencias SQL realizadas sobre la tabla, con el fin de hacer mucho más rápida la ejecución, debido a que el motor no recorre toda la tabla (table scan) D = 1/N b) Un índice de cobertura debe incluir a las columnas Si una densidad que menos se repiten (mayor selectividad o densidad), es mayor a 0.25 seguido por aquellas que se se considera alta. repiten menos. Para mayor referencia consulte: http://www.microsoft.com/lat am/technet/articulos/200005/ art02/ c) Algunas veces resulta más conveniente crear índices clustered pequeños y non clustered no muy grandes. Porque todo índice non clustered guarda una referencia al índice clustered. Si este es pesado, la consulta que lo utilice tardará más en ejecutarse. db_06 Restriccio nes data objects Para columnas Las restricciones se utilizan para con nombres implementar integridad de simples: dominio sobre una tabla, con la 129 Código Nombre Categoría Especificación Ejemplo finalidad de restringir el ingreso de valores incorrectos en una cnt_ProductoFe columna. cha Prefijo: Utilizar como prefijo cntProductoEst obligatorio cnt_, seguido del ado nombre de la tabla y el nombre de la columna afectada por la restricción. Por ejemplo si queremos restringir el ingreso de valores nulos sobre el campo descripcion de la tabla Producto, se creará la Para columnas restricción como: con nombres cnt_ProductoDescripcion compuestos: cnt_ProductoN ombreCorto cnt_ProductoN ombreLargo db_07 Valores por Omisión data objects Para columnas Los valores por omisión con nombre (Defaults) se utilizan para simple: predeterminar valores en una columna, cuando estos no son omitidos. def_fecha Prefijo: Utilizar como prefijo def_estado obligatorio def_, seguido del nombre de la columna a la cual hace referencia. Por ejemplo: supóngase que se requiere crear Para columnas un valor por omisión con la con nombre 130 Código Nombre Categoría Especificación Ejemplo fecha del sistema sobre la compuestos: columna fecha de la tabla Empleado, el nombre correcto sería: def_fecha def_fechaIngres o def_nombreSim ple Nomenclatura de Objetos de Lógica de Negocio Los objetos de lógica de negocio están conformados por todos los elementos que definen scripts orientados a satisfacer la lógica de negocios del sistema, entre estos objetos tenemos a los procedimientos almacenados, funciones de usuario, disparadores y vistas. Todos estos objetos deberán ser nomenclados bajo la siguiente especificación: Código Nombre Categoría Especificación Ejemplo Para definir el nombre de un procedimiento almacenado deberá considerarse la siguiente uspi_SalCusto mer norma: db_08 Definición de Procedimi entos Almacena dos script objects - Prefijo: Utilizar como prefijo obligatorio uspx_ (User Stored Procedure y x el nombre de la operación relacionada) - Nombre de la Operación: Está dado por la primera letra de la instrucción DML, por ejemplo x = i, si la operación DML es Insert Into. (Procedimiento Almacenado para insertar un nuevo Cliente, perteneciente al área de Ventas) - PostFijo: Esta dado por las iniciales del nombre del 131 Código Nombre Categoría Especificación Ejemplo proyecto, (por ejemplo: Pur, Sal, Acc) seguido del nombre de la tabla. Para definir el nombre de un disparador, deberá considerarse la siguiente norma: - Prefijo: Utilizar como prefijo utri_SalCustom obligatorio utrx_ (User er Trigger y x el nombre de la (Trigger operación relacionada) disparado al - Nombre de la Operación: insertar un Está dado por la primera letra nuevo Cliente) de la instrucción DML, por ejemplo x = i, si la operación DML es Insert Into. Disparado res db_09 (Triggers) script objects En caso de utilizar el trigger para más de una operación utilizar la conjunción de prefijos. Por ejemplo supóngase que se crea un trigger para actualizar el stock de productos. Por lo tanto el trigger se utilizará en dos contextos, tanto para inserción como actualización de stocks en el producto. utriu_SalUpdat eStock (Trigger disparado al insertar o actualizarel stock de un nuevo producto) - PostFijo: Esta dado por las iniciales del nombre del proyecto, (por ejemplo: Pur, Sal, Acc) seguido del nombre de la tabla. 132 Para definir el nombre de una función deberá considerarse la siguiente norma: - Prefijo: Utilizar como prefijo obligatorio udfx_ (User Defined Function y x el nombre de la operación relacionada) - Nombre de la Operación: Está dado por la primera letra de la instrucción DML, por ejemplo x = i, si la operación DML es Insert Into. db_10 Funciones script objects PostFijo: Esta dado por las iniciales del nombre del proyecto, (por ejemplo: Pur, Sal, Acc) seguido del nombre de la tabla. Importante udfs_SalCusto merExists (Función para verificar si un Cliente existe en la BDs) Aunque en SQL Server existen 3 tipos de funciones (escalar, tabla simple, multi tabla). Se recomienda utilizar las funciones solamente como valores escalares. Sin embargo pueden existir excepciones en las cuales amerite utilizar un conjunto de resultado más de una vez, para lo cual convendría crear una función tabla simple o multi tabla que devuelva el conjunto de resultados. En ese caso la función será utilizada como si fuera una tabla y no una columna como ocurre en el caso de una función escalar. 133 Para nombres Para definir el nombre de una simples: vista, deberá considerarse la siguiente norma: Prefijo: Utilizar como prefijo uvw_Categoria obligatorio uvw_ (User View) s Seguido del nombre de la vista uvw_Enfermed que puede ser: ades db_11 Vistas script objects - Simple: En caso que la vista involucre a una tabla. Para nombres - Compuesto: En caso que la compuestos: vista involucre a dos o más tablas. uvw_Productos Vencidos uvw_Empleado sEnVacaciones 134 REPORTE GENERAL DE DEFECTOS Proyecto: Laboratorio Clínico 2 Base de Datos: LABC2 Estudiante(s): Christian Riquelme – Ronald Sarco 135 Comentario [OPEN1]: C:ClearQuest_C QDatabase:ClearQuest:CQDatabase:CQDat abase.Name=^SBDGestionCambio\x3A\x3A LABC2 Estadísticas de Defectos Gráfico de Defectos por CU y Severidad Gráfico de Defectos por CU y Tipo 136 Gráfico de Defectos Totales por Estado y Tipo Gráfico de Tendencia de Transición de Estados (parcial) 137 138 Reporte Total por Estados Comentario [REPEAT2]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554510') ID Defecto Estado Severidad Tipo LABC200000078 Cerrado 4-Baja 1 - Documentación Resumen: Plan de iteración(construcción 1): error de puntuación. Descripción: En la página 3, en el ítem resumen ejecutivo, se está listando los elementos y no es obligatorio el punto, en todo caso se debe de normalizar el uso de este porque en las otros oraciones no presenta punto. ID Defecto Estado Severidad Tipo LABC200000077 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT3]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554509') Resumen: Listas de Riesgos V3.0: Se sugiere colocar el tipo de Alineacion Justificado en el texto Descripción: Pagina 4, Línea 6 columna 1 hasta la Página 4línea 37columna 77 ID Defecto Estado Severidad Tipo LABC200000076 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT4]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554508') Resumen: Plan de iteración(incepción): error ortográfico Descripción: En la página 4, en el ítem artefactos, la palabra "planeacion" se encuentra sin tilde. Comentario [REPEAT5]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554507') 139 ID Defecto Estado Severidad Tipo LABC200000075 Cerrado 3-Promedio 1 - Documentación Resumen: Plan de iteración(incepción): no se ha concluído los ítems dentro de referencias. Descripción: En la página 3, no se ha terminado de introducir los ítems dentro de referencias. ID Defecto Estado Severidad Tipo LABC200000074 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT6]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554506') Resumen: Listas de Riesgos V 2.0 : Error ortografico Descripción: La palabra "especímenes" debe llevar tilde y se encuentra en la pagina 3, linea 40 ID Defecto Estado Severidad Tipo LABC200000073 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT7]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554505') Resumen: Listas de Riesgos V2.0 : Las iniciales de laboratorio clinico deben ir con mayúsculas Descripción: Pagina 3, linea 28, columna 14 ID Defecto Estado Severidad Tipo LABC200000072 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT8]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554504') 140 Resumen: Plan de desarrollo: error de puntuación. Descripción: En la página 12, en el ítem "plan de control de calidad", no se colocó punto final en cada oración. Como se mencionó anteriormente se debería de normalizar si se requiere punto o no ya que simplemente se está mencionando y en ese caso no es obligatorio el punto. ID Defecto Estado Severidad Tipo LABC200000071 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT9]: ClearQuest:D efect:ClearQuest|1.1|Record('BDGestionCa mbio:LABC2','u210020','****','0','BDGestio nCambio','PRIVATE','Defect','33554503') Resumen: Listas de Riesgos V2.0 : Se sugiere colocar el tipo de Alineacion Justificado en el texto Descripción: Pagina 3, Línea 30, columna 1 hasta la Página 3 ,línea 36 columna 40 ID Defecto Estado Severidad Tipo LABC200000070 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT10]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554502') Resumen: Listas de Riesgos V 2.0 : Se sugiere no colocar "etc", en textos formales Descripción: Página 3 , línea 24 ID Defecto Estado Severidad Tipo LABC200000069 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT11]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554501') Resumen: Plan de desarrollo: error de redundancia. Descripción: En la página 12 (línea 14) se presenta un error de redundancia. Se sugiere omitir "la solicitud" y corregir la palabra "evaluar" por evaluarla en la oración: "Una vez recibida la solicitud se deberá evaluar la solicitud". 141 ID Defecto Estado Severidad Tipo LABC200000068 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT12]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554500') Resumen: Listas de Riesgos V1.0 : Signo de puntuacion al final de la oración. Descripción: Pagina 7, linea 4 Página 7, línea 8 Pagina 7, linea 21 ID Defecto Estado Severidad Tipo LABC200000067 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT13]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554499') Resumen: Plan de desarrollo: error ortográfico, omisión de tílde. Descripción: En la página 12, en el ítem "administración de requerimientos" (línea 11), se omitió una tílde en la palabra "qué". ID Defecto Estado Severidad Tipo LABC200000066 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT14]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554498') 142 Resumen: Listas de Riesgos V1.0 : Signo de puntuacion al final de la oración. Descripción: Pagina 5, linea 33 Página 5, línea 38 Página 6, línea 2 Página 6, línea 11 Página 6, línea 13 Página 6, línea 28 ID Defecto Estado Severidad Tipo LABC200000065 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT15]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554497') Resumen: Plan de desarrollo: se sugiere anteponer un artículo antes del sustantivo en una oración. Descripción: En la página 11, en el ítem versiones, se sugiere anteponer un artículo ("la") antes de la palabra iteración para darle mayor fluidez y sentido a la oración. ID Defecto Estado Severidad Tipo LABC200000064 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT16]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554496') Resumen: Listas de Riesgos V1.0 : Se sugiere colocar el tipo de Alineacion Justificado en el texto Descripción: Página 7 , línea 6, columna 1 Comentario [REPEAT17]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554495') 143 ID Defecto Estado Severidad Tipo LABC200000063 Cerrado 5-Sugerencia 1 - Documentación Resumen: Listas de Riesgos V1.0 : Se sugiere colocar el tipo de Alineacion Justificado en el texto Descripción: Página 5 , línea 29, columna 1 ID Defecto Estado Severidad Tipo LABC200000061 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT18]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554493') Resumen: Plan de desarrollo: error de puntuación. Descripción: En la página 8, en "fase 4", se dejo sin punto aparte a ese ítem, mientras las demás fases si tienen punto. Se debería de normaliar si lleva o no punto final. ID Defecto Estado Severidad Tipo LABC200000096 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT19]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554528') Resumen: Plan de aceptación V2.0: mal uso de los signos de puntuación. Descripción: En la página 5,línea 2 hay un mal uso de la coma, debido a que en ese caso no está separando palabras. ID Defecto Estado Severidad Tipo LABC200000095 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT20]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554527') 144 Resumen: Plan de aceptación V2.0: error en la concordancia de número. Descripción: En la página 3, en el ítem propósito, en la línea 10 no hay concordancia de número. En la oración: "...respecto al Producto que se van a desarrollar ...", la palabra "van" debería ser sin n. ID Defecto Estado Severidad Tipo LABC200000094 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT21]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554526') Resumen: Plan de Aceptación v1.0: omisión del uso de signos de puntuación. Descripción: En la página 6, línea 10, se omitió tílde en la palabra "el". Debe de haber tílde debido a que es un pronombre personal, no un artículo. ID Defecto Estado Severidad Tipo LABC200000093 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT22]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554525') Resumen: Plan de aceptación v1.0: error en el uso de los signos de puntuación. Descripción: En la página 6, línea 28, la palabra "mas" debería llevar tilde debido a que es superlativo. ID Defecto Estado Severidad Tipo LABC200000092 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT23]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554524') Resumen: Plan de Aceptación v1.0: incoherencia de géneo en el uso de las palabras. Descripción: En la página 6, línea 10, la palabra "permita" debería de suplantar a la actual palabra que se presenta en el texto. 145 Comentario [REPEAT24]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554523') ID Defecto Estado Severidad Tipo LABC200000091 Cerrado 4-Baja 1 - Documentación Resumen: Plan de Aceptación v1.0: error en el uso de los signos de puntuación. Descripción: En la página 5, línea 16, hay una omisión de tilde en la palabra "examenes". ID Defecto Estado Severidad Tipo LABC200000090 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT25]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554522') Resumen: Plan de Aceptación v1.0: incoherencia de géneo en el uso de las palabras. Descripción: En la página 5, línea 15, la palabra "permita" debería de suplantar a la actual palabra que se presenta en el texto. ID Defecto Estado Severidad Tipo LABC200000089 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT26]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554521') Resumen: Plan de aceptación V1.0: mal uso de los signos de puntuación. Descripción: En la página 5,línea 3 hay un mal uso de la coma, debido a que en ese caso no está separando palabras. ID Defecto Estado Severidad Tipo LABC200000087 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT27]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554519') 146 Resumen: Plan de aceptación V1: error en la concordancia de número. Descripción: En la página 3, en el ítem propósito, en la línea 11 no hay concordancia de número. En la oración: "...respecto al Producto que se van a desarrollar ...", la palabra "van" debería ser sin n. ID Defecto Estado Severidad Tipo LABC200000086 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT28]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554518') Resumen: Plan de iteración (construcción 3): error de puntuación. Descripción: En la página 3, en el ítem "resumen ejecutivo", se colocó un punto aparte solo en una oración, mientras en las otras dos no se hizo. Es necesario normalizar el uso de los puntos. ID Defecto Estado Severidad Tipo LABC200000085 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT29]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554517') Resumen: Plan de iteración(construccion 2): se presenta una oación que carece de sentido. Descripción: En la página 5(línea 3), la oración no tiene ilación y presenta dificultad al leerla. ID Defecto Estado Severidad Tipo LABC200000084 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT30]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554516') Resumen: Plan de iteración (construcción 2): error de puntuación. Descripción: En la página 3, en el ítem "resumen ejecutivo", se colocó un punto aparte solo en una oración, mientras en las otras dos no se hizo. Es necesario normalizar el uso de los puntos. 147 Comentario [REPEAT31]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554515') ID Defecto Estado Severidad Tipo LABC200000083 Cerrado 4-Baja 1 - Documentación Resumen: Listas de Riesgos V4.0 : Signo de puntuacion al final de la oración. Descripción: Pagina 4, linea 4 Página 4, línea 19 Página 4, línea 25 Página 4, línea 19 Página 4, línea 30 Página 5, línea 3 Página 5, línea 8 Página 5, línea 10 ID Defecto Estado Severidad Tipo LABC200000082 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT32]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554514') Resumen: Listas de Riesgos V4.0 : Se sugiere colocar el tipo de Alineacion Justificado en el texto Descripción: Pagina 4, linea 3 hasta pagina 4, linea 12 ID Defecto Estado Severidad Tipo LABC200000081 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT33]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554513') 148 Resumen: Plan de iteración(construcción 1): se presenta una oración que carece de sentido. Descripción: En la página 5, en el ítem artefactos (línea 4), la oración commpleta no tiene ilación y es difícil de entender lo que se pretende decir. ID Defecto Estado Severidad Tipo LABC200000080 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT34]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554512') Resumen: Listas de Riesgos V 3.0 : Error ortografico Descripción: La palabra "asimismo" debe llevar tilde y se encuentra en la pagina 4, linea 23, columna 71 ID Defecto Estado Severidad Tipo LABC200000079 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT35]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554511') Resumen: Listas de Riesgos V 3.0 : Error ortografico Descripción: Pagina 4, linea 4 Pagina 4, linea 11 Pagina 4, linea 13 Pagina 4, linea 16 Pagina 4, linea 30 Pagina 4, linea 35 Pagina 4, linea 37 Comentario [REPEAT36]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554475') 149 ID Defecto Estado Severidad Tipo LABC200000043 Cerrado 4-Baja 1 - Documentación Resumen: Visión: se encontró una oración inconsistente. Descripción: La oración: "Esta funcionalidad permite al laboratorista asignar a los horarios de atención de los laboratoristas. " que se encuentra en la página 13 en el ítem 5.13 carece de sentido gramatical. ID Defecto Estado Severidad Tipo LABC200000041 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT37]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554473') Resumen: Visión: presencia de errores ortográficos. Descripción: En las páginas: 9 (última), 10(está), 12 (simultánea) se observaron palabras que no tienen tilde. ID Defecto Estado Severidad Tipo LABC200000040 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT38]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554472') Resumen: Visión: falta de uso de mayúsculas. Descripción: En la página 9, las palabras "laboratorio clínico" deberían de estar con mayúsculas debido aque es el nombre del producto principal que se presenta en la visión y en los demás documentos. ID Defecto Estado Severidad Tipo LABC200000039 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT39]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554471') 150 Resumen: Visión: falta de uso de mayúsculas. Descripción: Las palabras mostradas en la página 8 en "jefe de producto-entregables" deberían de empezar con mayúscula como las palabras predecesoras. ID Defecto Estado Severidad Tipo LABC200000038 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT40]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554470') Resumen: Visión: falta ortográfica. Descripción: En la página 7 se observa que la palabra auditoría no está con tilde. ID Defecto Estado Severidad Tipo LABC200000037 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT41]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554469') Resumen: SRS: Error espacio de una palabra con un signo de puntuacion Descripción: Página 3, línea 10, columna 24, despues de la palabra Clínico, los dos puntos deden ir junto a esta palabra ID Defecto Estado Severidad Tipo LABC200000036 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT42]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554468') Resumen: Visión: Puntuación mal usada. Descripción: Coma mal usada en las página 6 y 12. Comentario [REPEAT43]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554467') 151 ID Defecto Estado Severidad Tipo LABC200000035 Cerrado 4-Baja 1 - Documentación Resumen: SRS: Error ortografico Descripción: Se encontro error ortografico en la página 11, línea 29, columna 24.("Esta" no lleva tilde en la "a") ID Defecto Estado Severidad Tipo LABC200000034 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT44]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554466') Resumen: Visión: error de puntuación. Descripción: En las páginas 6 (dos veces) y 8 no se colocaron puntos finales para terminar la oración. ID Defecto Estado Severidad Tipo LABC200000033 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT45]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554465') Resumen: SRS: Falta de concordancia en el texto Descripción: Página 11, línea 16, columna 45, se recomienda utilizar la palabra "será" en vez de "serán" ID Defecto Estado Severidad Tipo LABC200000032 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT46]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554464') Resumen: SRS: subrayado incompleto Descripción: Página 11, línea 16, columna 25 152 ID Defecto Estado Severidad Tipo LABC200000031 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT47]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554463') Resumen: Visión: Error de puntuación. Descripción: En página 5 en la parte de "nuestro producto" hace falta una coma. ID Defecto Estado Severidad Tipo LABC200000030 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT48]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554462') Resumen: SRS: Error Ortografico Descripción: Página 8, Línea 19, columna 70 ID Defecto Estado Severidad Tipo LABC200000029 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT49]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554461') Resumen: Visión: Se sugiere no utilizar etc. en textos formales. Descripción: En las páginas 5, 9 (dos veces) y 10 se ha hecho uso de la abreviación etc. ID Defecto Estado Severidad Tipo LABC200000028 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT50]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554460') 153 Resumen: SRS: Error de puntuacion Descripción: pagina 7, linea 25 , columna 19 ID Defecto Estado Severidad Tipo LABC200000027 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT51]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554459') Resumen: Visión: error ortográfico Descripción: Se encontraron errores orotgráficos en la página 4 (cuál lleva acento) y en la página 5 (éstas lleva acento) respectivamente. ID Defecto Estado Severidad Tipo LABC200000026 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT52]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554458') Resumen: Visión: oración incompleta en la última línea de la página 4 Descripción: La oración se presenta incompleta en la parte de "una solución sería" ID Defecto Estado Severidad Tipo LABC200000060 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT53]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554492') Resumen: Plan de desarrollo: se presenta una omisión de palabra. Descripción: En la página 7, se omitió la palabra "ser" antes de "proactivo". Comentario [REPEAT54]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554491') 154 ID Defecto Estado Severidad Tipo LABC200000059 Cerrado 5-Sugerencia 1 - Documentación Resumen: Listas de Riesgos V1.0 : Se sugiere colocar el tipo de Alineacion Justificado en el texto Descripción: Pagina 5, Línea 7, columna 1 hasta la Página 5 ,línea 22, columna 51 ID Defecto Estado Severidad Tipo LABC200000058 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT55]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554490') Resumen: Plan de desarrollo: error de puntuación. Descripción: En la página 6, en el cuadro de roles y responsabilidades, hay un error de puntuación. Se debe tener en cuenta que los listados de palabras o pequeños textos no tienen necesidad de ser termindos en punto. pero habría que normalizar esa regla ya que se presentan dos oraciones que terminan en punto. ID Defecto Estado Severidad Tipo LABC200000057 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT56]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554489') Resumen: Plan de desarrollo: error de tipeo. Descripción: En la página 5, en la tercera oración del ítem supuestos, se tipeó mal la palabra "embargo". De la misma manera, no se concluyó al final de la oración de manera coherente. ID Defecto Estado Severidad Tipo LABC200000056 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT57]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554488') 155 Resumen: Plan de desarrollo: error de ortografía, omisión de tilde. Descripción: En la página5, en el ítem supuestos, se omitió tilde a la palabra "dedicará". ID Defecto Estado Severidad Tipo LABC200000055 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT58]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554487') Resumen: Plan de desarrollo: error de puntuación, omisión del punto final en la oración. Descripción: En la página 5, en el ítem de supuestos, se omitió el punto final en cada oración. ID Defecto Estado Severidad Tipo LABC200000054 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT59]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554486') Resumen: Plan de desarrollo: no hay concordancia en número. Descripción: En la página 4, no hay concordancia de número. Se omitió una "s" en la palabra "mecanismo". ID Defecto Estado Severidad Tipo LABC200000053 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT60]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554485') Resumen: Plan de desarrolo: Error de puntuación, omisión del punto final en la oración. Descripción: En la página 4, al mencionar los objeivos específicos del proyecto, se omitieron los puntos finales de cada oración. Comentario [REPEAT61]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554484') 156 ID Defecto Estado Severidad Tipo LABC200000052 Cerrado 4-Baja 1 - Documentación Resumen: Plan de desarrollo: falta orotgráfica, omisión de tilde. Descripción: En la página 3, en el ítem Informe de laboratorio Clínico, la palabra especímenes debe de llevar tilde. ID Defecto Estado Severidad Tipo LABC200000051 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT62]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554483') Resumen: Glosario: Se sugiere no utilizar ETC en textos formales Descripción: Pagina 2, línea 26, columna 42 ID Defecto Estado Severidad Tipo LABC200000050 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT63]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554482') Resumen: Glosario: Se sugiere no utilizar ETC en textos formales Descripción: Página 2, linea 3, columna 72 ID Defecto Estado Severidad Tipo LABC200000049 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT64]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554481') Resumen: Plan de desarrollo: en textos fomales no se sugiere el uso de etc. Descripción: Las páginas 3 y 12 presentan etc. 157 ID Defecto Estado Severidad Tipo LABC200000048 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT65]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554480') Resumen: Visión: se presenta inconsistencia en la oración. Descripción: En el ítem "Rangos de calidad-mantenimiento", la palabra archivo debería de estar predescedida de un artículo o un pronombre. ID Defecto Estado Severidad Tipo LABC200000047 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT66]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554479') Resumen: Visión: inconsistencia en la oración. Descripción: En la página 11, ítem 5.20, la oración "Estos son códigos es la única información..."presenta inconsistencia. ID Defecto Estado Severidad Tipo LABC200000046 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT67]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554478') Resumen: Visión: se presenta inconsistencia de número. Descripción: En la página 10, ítem 5.16 debería de decir "se haga efectivo" .Se presenta inconsistencia de número. ID Defecto Estado Severidad Tipo LABC200000045 Cerrado 4-Baja 1 - Documentación Comentario [REPEAT68]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554477') 158 Resumen: Visión: se presenta una inconsistencia en la oración. Descripción: En página 10, ítem 5.15 se presenta una inconsistencia en la oración. ID Defecto Estado Severidad Tipo LABC200000044 Cerrado 5-Sugerencia 1 - Documentación Comentario [REPEAT69]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554476') Resumen: Visión: Se sugiere acompañar un sustantivo con un artículo para dar consistencia a la oración. Descripción: En la página 10 en el ítem 5.14 debería de presceder un arrtículo a la palabra "Laboratorista Administrador" ID Defecto Estado Severidad Tipo LABC200000102 Cerrado 2-Alta 2 - Interfaz de Usuario Comentario [REPEAT70]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554534') Resumen: Proyecto Servicio1: En el textbox del codigo de Solicitud, no debe aceptar campos vacios Descripción: En el textbox del codigo de Solicitud, no debe aceptar campos o espacios vacios, porque genera error. ID Defecto Estado Severidad Tipo LABC200000101 Cerrado 2-Alta 2 - Interfaz de Usuario Comentario [REPEAT71]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554533') 159 Resumen: Proyecto Servicio1: En el codigo de Solicitud, si se coloca un codigo que no esta en la base de datos genera error Descripción: En el codigo de Solicitud, si se coloca un codigo que no esta en la base de datos genera error, ejemplo: HC PACIENTE : 01102004030950 Fecha: AGOSTO 2006 COdigo de Solicitud: 200 En la pantalla Proyecto Prueba de Servicio L2 Si el codigo de Solicitud se coloca : 400, se genera error, puesto que este codigo no se encuentra en la base de datos. ID Defecto Estado Severidad Tipo LABC200000100 Cerrado 2-Alta 2 - Interfaz de Usuario Comentario [REPEAT72]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554532') Resumen: Proyecto Servicio1: El boton detalle no debe activarse si en el codigo de lista de solicitudes no existen datos Descripción: El boton detalle, de la pantalla principal, no debe activarse, si en el codigo de lista de solicitudes (Del DataGrid) no existen datos. ID Defecto Estado Severidad Tipo LABC200000099 Cerrado 2-Alta 2 - Interfaz de Usuario Comentario [REPEAT73]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554531') 160 Resumen: Proyecto Servicio1: El codigo de solicitud acepta string Descripción: En el codigo de solicitud no debe de aceptar string tanto mayusculas o minusculas. ID Defecto Estado Severidad Tipo LABC200000098 Cerrado 2-Alta 2 - Interfaz de Usuario Comentario [REPEAT74]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554530') Resumen: Proyecto Servicio1: El HC Paciente Acepta datos tipo caracter como : !"#$%&/()=?¡ Descripción: El servicio acepta los caracteres !"#$%&/()=?¡, el HC Paciente debe ser consistenciado para que solo admita valores tipo string. Comentario [REPEAT75]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554536') ID Defecto Estado Severidad Tipo LABC200000104 Cerrado 2-Alta 4 - Funcionalidad Incorrecta Resumen: WB1: Solicitudes duplicadas Descripción: Al momento de enviar las solicitudes, hay una duplicación de estas. Comentario [REPEAT76]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554537') ID Defecto Estado Severidad Tipo LABC200000105 Cerrado 2-Alta 4 - Funcionalidad Incorrecta Resumen: WB2: Lista de examenes incorrecta Descripción: No se muestra la lista de exámenes correcta de acuerdo a la solicitud. Comentario [REPEAT77]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554538') 161 ID Defecto Estado Severidad Tipo LABC200000106 Cerrado 2-Alta 4 - Funcionalidad Incorrecta Resumen: Al registrar resultados: no hay concordancia entre los parámetros de caracteres Descripción: El historial clínico correspondiente a un paciente de UCI no es el que figura en ese historial clínico puesto que este presenta un error de 13 caracteres en vez de 14. Comentario [REPEAT78]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554539') ID Defecto Estado Severidad Tipo LABC200000107 Cerrado 2-Alta 4 - Funcionalidad Incorrecta Resumen: WS2: Lista incompleta de examenes y análisis Descripción: No se envía la lista completa con todos los exámenes y análisis registrados en una solicitud. Comentario [REPEAT79]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554541') ID Defecto Estado Severidad Tipo LABC200000109 Cerrado 2-Alta 4 - Funcionalidad Incorrecta Resumen: XML: Información incoherente respecto al contrato Descripción: El XML respuesta no muestra la información en la jerarquía establecida inicialmente en el contrato. Comentario [REPEAT80]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554542') ID Defecto Estado Severidad Tipo LABC200000110 Cerrado 2-Alta 4 - Funcionalidad Incorrecta 162 Resumen: NR1: Código de solicitud no se registra en el caso de uso debido. Descripción: El envíodel código de solicitud se está realizando en el CU: "Validar resultado de solicitud" cuando realmente se debería de realizar en el CU:"Registrar Resultado de Solicitud". Comentario [REPEAT81]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554543') ID Defecto Estado Severidad Tipo LABC200000111 Cerrado 2-Alta 4 - Funcionalidad Incorrecta Resumen: NR1: El mensaje de confirmación inválido. Descripción: El mensaje de confirmación se está enviando a UCI a pesar de que la solicitud registrada no pertenece al área de UCI. Comentario [REPEAT82]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554535') ID Defecto Estado Severidad Tipo LABC200000103 Cerrado 2-Alta 6 - Error de Integración Resumen: Error en la conexión con el módulo UCI Descripción: Error en la conexión con el módulo UCI. En error se presenta en el servicio de Net Remoting. Comentario [REPEAT83]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554540') ID Defecto Estado Severidad Tipo LABC200000108 Cerrado 2-Alta 6 - Error de Integración Resumen: WS2: Datos del médico incompleto Descripción: No se envían los datos del médico completamente. Comentario [REPEAT84]: ClearQuest: Defect:ClearQuest|1.1|Record('BDGestion Cambio:LABC2','u210020','****','0','BDGes tionCambio','PRIVATE','Defect','33554544') 163 ID Defecto Estado Severidad Tipo LABC200000112 Cerrado 2-Alta 6 - Error de Integración Resumen: NR1: Error de conexión con el módulo UCI Descripción: El mensaje de error que se genera es debido aque no hay un conexión con el módulo UCI. No es explícito. Comentario [REPEAT85]: ClearQuest: Query:ClearQuest|1.1|Query('BDGestionC ambio:LABC2','u210020','****','0','BDGesti onCambio','PRIVATE','Public Queries/Buscar') 164 CALCULO DE LAS ESTIMACIONES DE LAS FASES DEL PROYECTO ESTIMACIÓN POR CASOS DE USO  Cálculo de los Puntos de Casos de Uso No Ajustados(UUCP): Caso de Uso Ponderación Calificación Administrar Lista de Exámenes Actores 5 3 Transacciones 1 10 Actores 5 3 Transacciones 1 10 Actores 2 3 Transacciones 1 5 Actores 1 3 Transacciones 1 5 Administrar Solicitud de Exámenes Asignar Horario a Laboratoristas Registrar Resultados de Muestras 165 Rotular Muestras Actores 1 3 Transacciones 1 5 Actores 1 3 Transacciones 4 10 Actores 1 3 Transacciones 2 5 Actores 1 3 Transacciones 1 5 Actores 1 3 Transacciones 1 5 Administrar Pacientes por Consulta Externa Validar Resultados de Muestras Consultar Resultados de Solicitud de Exámenes Enviar Reporte de Resultado de Solicitud de Exámenes UUCP 87 UUCP = UAW + UUCW UUCP: Puntos de casos de uso sin ajustar UAW: Factor de peso de los actores sin ajustar 166 UUCW: Factor de peso de los casos de uso sin ajustar.  Cálculo de Factor de Complejidad Técnica (TCF): Factor Descripción Peso Calificación Ponderado T1 Sistema Distribuido 2 5 10 T2 Tiempo de Respuesta 2 5 10 T3 Eficiencia de usuario final 1 5 5 T4 Procesamiento complejo 1 0 0 T5 Reusabilidad 1 3 3 T6 Facilidad de instalación 0.5 5 2.5 T7 Facilidad de uso 0.5 5 2.5 T8 Portabilidad 2 0 0 T9 Facilidad de cambio 1 3 3 T10 Concurrencia 1 3 3 T11 Seguridad 1 5 5 T12 Acceso de terceros 1 3 3 T13 Entrenamiento especial requerido 1 1 1 TFactor 48 TCF 1.08 TCF = 0.6 + (0.01 + TFactor) TCF: Complejidad Técnica TFactor:  (Peso * Calificaci ón) 167  Cálculo del Factor de Entorno (EF): Factor Descripción Peso Calificación Ponderado E1 Familiaridad con RUP 1.5 5 7.5 E2 Experiencia en la aplicación 0.5 1 0.5 E3 Experiencia OO 1 5 5 E4 Capacidad del analista 0.5 5 2.5 E5 Motivación 1 5 5 E6 Requerimientos estabilizados 2 3 6 E7 Trabajadores a tiempo parcial -1 0 0 E8 Dificultad del lenguaje de prog. -2 0 0 EFactor 26.5 EF 0.605 EF = 1.4 + ( -0.3 * EFactor ) EF: Factor de Entorno EFactor:   (Peso * Calificaci ón) Cálculo de Puntos de Casos de Uso Ajustados: AUCP 56.85 AUCP = UUCP * TCF * EF AUCP: Puntos de Casos de Uso Ajustados UUCP: Puntos de Casos de Uso sin Ajustar TCF: Factor de Complejidad Técnica 168 EF: Factor de Entorno  Cálculo del Esfuerzo: Horas - Hombre 1,136.92 Esfuerzo 23.69 Meses 8.32 Horas – Hombre: AUCP *20 Esfuerzo: (Horas – Hombre) / 48 Meses: 2.5 * Esfuerzo 0.38 169 PLAN DE GESTION DEL CRONOGRAMA Hitos y entregables definidos durante cada una de las fases del proyecto Fase Incepción: - Fase Incepción Hito Concepción del Proyecto Inicio 15/08/2005 Fin 16/09/2005 Semana Fecha Entrega Ítem Entregables EI 1 Plan de desarrollo del Software 1 19-sep-05 EI 2 Plan de Aceptación 1 19-sep-05 EI 3 Plan de Iteración 1 19-sep-05 EI 4 Lista de Riesgos 2 26-sep-05 EI 5 Modelo de casos de uso 2 26-sep-05 EI 6 SRS 2 26-sep-05 EI 7 SSS 3 2-oct-05 EI 8 Visión 4 9-oct-05 EI 9 Glosario 4 9-oct-05 EI 10 Evaluación de la iteración 4 9-oct-05 EI 11 Prototipo Visual 5 16-oct-05 EI 12 Estimación del proyecto 5 16-oct-05 En la semana 6 se realizaron las revisiones de los entregables con los gerentes técnicos y funcionales del proyecto, así como las correcciones respectivas. En la semana 7 se realizó la entrega final de la documentación completa v 0.1 170 2005 S3 Septiembre S4 S1 S2 Octubre S3 S4 S1 Entrega Final de Documentación Completa v0.1 S1 S2 Revisión y Corrección de Entregables Fases del Proyecto Agosto Semana 1 EI1 / EI2 / EI3 Semana 2 EI4 / EI5 / EI6 Semana 3 Incepción EI7 Semana 4 EI8 / EI9 / EI10 Semana 5 EI11 / EI12 S2 S3 S4 Fase Elaboración: o Etapa Elaboración: En esta etapa, el principal objetivo fue generar una arquitectura la cual estuviera acorde con los requerimientos funcionales y no funcionales extraídos en la etapa de incepción. Los entregables que se presentaron fueron los siguientes: Fase Elaboración Hito Arquitectura del Subsistema Inicio 24/10/2005 Fin 09/12/2005 Ítem Entregables Semana Fecha Entrega EE 1 Prototipo Visual 10 28-oct-05 EE 2 Modelo de casos de uso 10 28-oct-05 EE 3 Reporte de Estado del Proyecto 10 28-oct-05 EE 4 Especificación de Casos de Uso 10 28-oct-05 EE 5 Modelo de Análisis 11 4-nov-05 EE 6 Estimación del proyecto 11 4-nov-05 EE 7 SSS 11 4-nov-05 EE 8 Protótipo de Arquitectura de Software 12 11-nov-05 171 EE 9 Modelo de Arquitectura de Software (UML) 12 EE 10 Documento de Arquitectura de Software (SAD) 13 EE 11 Plan de Desarrollo de Software 13 - 11-nov-05 18-nov-05 18-nov-05 En la semana 14 se realizó las revisiones de los entregables con los gerentes técnicos y funcionales del proyecto, así como las correcciones respectivas. En la semana 15 se realizó la entrega final de la documentación completa v 0.2 2005 S1 S2 S3 Noviembre S4 S1 Diciembre S2 S3 Semana 10 EE1 / EE2 / EE3 / EE4 Elaboración Semana 11 EE5 / EE6 / EE7 Semana 12 EE8 / EE9 Semana 13 EE10 / E11 S4 S1 S2 S3 S4 Revisión y Corrección de Entregables Entrega Final de Documentación Completa v0.2 Fases del Proyecto Octubre Fase Construcción: La fase de Construcción, se divide en 3 paquetes de trabajo, las cuales tuvieron como principal actividad, el desarrollo por casos de uso del producto propuesto: Construcción 1, Construcción 2, Construcción 3. Los entregables de cada paquete se detallan a continuación.  Construcción 1: Iteración: 1 Fase: Construcción Entregables: Release 1 172 Fechas Artefactos validados Semana 17/Abril/06 4: CU1: Administrar Pacientes Externos Semana 01/Mayo/06 6: CU3: Asignar Horario de Laboratoristas Semana 01/Mayo/06 6: CU2: Administrar Lista de Exámenes CU4: Administrar Solicitud de Exámenes Documentación Completa Hitos Semana Fecha de Entrega Cierre de Línea Base 2 Viernes 07/04/2006 Cierre de CU1 4 Lunes 17/04/2006 Cierre de CU2 4 Lunes 17/04/2006 Entrega de CU1 y CU2 Integrados 4 Miércoles 19/04/2006 Cierre de CU3 6 Lunes 01/05/2006 Cierre de CU4 6 Lunes 01/05/2006 Entrega de CU1, CU2, CU3 y CU4 6 Integrados Viernes 05/05/2006 173 2006 S1 C o n s Construcción 1 t S2 Mayo S3 S4 S1 S2 Entrega de Línea Base Semana 3 Semana 4 CU1 / CU2 Semana 5 Semana 6 CU 3/ CU4 o S3 Semana 2 Semana 7 S4 Revisión y Corrección de Entregables / Presentación Release 1 Fases del Proyecto Abril Construcción 2: Iteración: 2 Fase: Construcción Entregables: Release 2 Fechas Artefactos validados CU5: Registrar Solicitud de Exámenes CU6: Registrar Resultados de Análisis Semana 23/Junio/06 13: CU7: Rotular Muestras CU8: Validar Resultados de Exámenes Semana 30/Junio/06 14: CU9: Generar Reporte de Resultados de Exámenes Semana 05/Julio/06 15: Documentación Completa 174 Hitos Semana Fecha de Entrega Cierre de CU5 13 Viernes 23/06/2006 Cierre de CU6 13 Viernes 23/06/2006 Cierre de CU7 13 Viernes 23/06/2006 Entrega de CU5, CU6 y CU7 Integrados 14 Lunes Cierre de CU8 14 Viernes 30/06/2006 Cierre de CU9 14 Viernes 30/06/2006 Entrega de CU5, CU6, CU7, CU8 y CU9 15 Integrados Lunes 26/06/2006 03/07/2006 2006 Fases del Proyecto S1 S2 S3 Julio S4 S1 S2 S3 Semana 10 Semana 11 Semana 12 Construcción 2 Semana 13 CU5 / CU6 / CU7 Semana 14 CU8 / CU9  Semana 15 S4 Revisión y Corrección de Entregables / Presentación Release 2 Junio Construcción 3: Iteración: 3 Fase: Construcción Entregables: Release Final 175 Fechas Artefactos validados WS1: Consultar Lista de Solicitudes Semana 28/Agosto/06 Semana 18/Setiembre/06 Semana 29/Setiembre/06 3: WS2: Consultar Resultados de Exámenes NR1: Actualizar Estado de Solicitud de 6: Análisis 7: Documentación Completa Hitos Semana Fecha de Entrega Cierre de WS1 3 Lunes 28/08/2006 Cierre de WS2 6 Lunes 18/08/2006 Cierre de NR1 6 Viernes 22/09/2006 Entrega de WS1, WS2 y NR1 Integrados 7 Lunes 29/09/2006 176 2006 S1 S2 S3 Setiembre S4 S1 S2 Octubre S3 S4 Semana 2 Semana 3 WS1 Construcción 3 Semana 4 Semana 5 Semana 6 WS2 / NR1 Semana 7 Semana 8 S1 S2 S3 S4 Revisión y Corrección de Entregables / Presentación Release 3 Fases del Proyecto Agosto Transición: o Finalmente, en la etapa de Transición, parte final del proyecto, el objetivo principal es la generación de medios por los cuales el producto desarrollado pueda ser implantado en un ambiente específico. Los productos entregables son los siguientes : Fase Transición Hito Producto Final Inicio 23/10/2006 Fin 01/12/2006 Ítem Entregables Semana Fecha Entrega ET 1 Memoria del Proyecto 9 27-oct-06 ET 2 Instalador del Producto 10 3-nov-06 ET 3 Manual de Instalación 11 10-nov-06 ET 4 Manual de Usuario 11 10-nov-06 ET 5 Documentación Completa del Proyecto 12 17-nov-06 177 9. Bibliografía VELÁSQUEZ, Luis y VIDAL, Álvaro 2004 Análisis y Tendencias en la utilización de Servicios Salud – Perú 1985 – 2002 Presenta un estudio de la situación del sector Salud en el Perú entre los años 1985 y 2002. ASAMBLEA NACIONAL DE RECTORES (ANR) 2004 (http://www.anr.edu.pe/ ) Se presentan las últimas estadísticas universitarias con datos relacionados a las universidades, alumnado, docentes, graduados y titulados. INSTITUTO NACIONAL DE SALUD 2007 Memoria Anual 2007 Lima: INS, c2008 Sumario de lo acontecido en el 2007 y propuestas para años posteriores ORTIZ DE ZEVALLOS, Gabriel 2000 Salud Lima, Instituto Apoyo, 2000 Descripción del sistema de salud ARROYO, Juan 2002 La Salud peruana en el siglo XXI: retos y propuestas de política Lima: Consorcio de Investigación Económica y Social, 2002 Análisis de la salud peruana en el siglo XXI BOOCH, JACOBSON Y RUMBAUGH 178 2000 El Proceso Unificado de Desarrollo de Software. Madrid: Addison-Wesley. Este libro trata de los fundamentos básicos del RUP. MICROSOFT CORPORATION 2002 Developing Microsoft ASP.NET Web Applications using Visual Studio .Net. Santa Fé de Bogotá : Cargraphics. Manual del curso de certificación Microsoft en .NET. RUMBAUGH, James 1999 The Unified Modeling Language: Reference Manual. Massachuset: AddisonWesley, pp. 3. Presenta información básica sobre el modelamiento orientado a objetos UML. STEVENS, Perdita y POULEY, Rob 2002 Utilización de UML en la ingeniería del software con objetos y componentes. Madrid: Addison-Wesley, pp. 54-57. Este libro tiene información no solo teórica sino también práctica sobre el modelamiento con UML 179