CÁTEDRA: INGENIERÍA DE SOFTWARE DOCENTE: … · aspectos que se especifican en la Norma ISO...

UNIVERSIDAD DON BOSCO

FACULTAD DE INGENIERÍA

ESCUELA COMPUTACIÓN

CÁTEDRA:

INGENIERÍA DE SOFTWARE

DOCENTE:

ING. MILTON NARVÁEZ

PROYECTO:

“SOFTWARE ADMINISTRATIVO PARA LABORATORIO CLÍNICO MEDICAL TEST - SYSLAB”

ESTUDIANTES: FLAMENCO QUIJADA, VÍCTOR MANUEL GÓMEZ HERNÁNDEZ, KEVIN ERNESTO

SERPAS GONZÁLEZ, JOSUÉ ALEJANDRO

CIUDADELA DON BOSCO 13 DE NOVIEMBRE DE 2014

ÍNDICE

Introducción ................................................................................................................... 2

ETAPA 1. ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE

1. Antecedentes del Proyecto ........................................................................................ 4

1.1. Modelado del proceso del negocio .............................................................. 4

2. Propósito (Planteamiento del problema) .................................................................... 6

3. Objetivos del proyecto ............................................................................................... 7

3.1. General ....................................................................................................... 7

3.2. Específicos .................................................................................................. 7

4. Análisis de requerimientos ......................................................................................... 8

4.1. Determinación del alcance del sistema ........................................................ 9

4.2. Obtención de requisitos ............................................................................. 10

4.3. Elaboración de requisitos ........................................................................... 11

4.4. Negociación de requisitos .......................................................................... 12

4.5. Perspectiva del producto ............................................................................ 13

4.6. Características de usuarios ........................................................................ 16

5. Modelo del Ciclo de Vida del Software ...................................................................... 17

6. Factibilidad del proyecto ........................................................................................... 21

6.1. Factibilidad técnica ..................................................................................... 21

6.2. Factibilidad operativa (recursos y plan de formación) ................................. 22

6.3. Económica ................................................................................................. 23

6.4. Fechas ....................................................................................................... 24

ETAPA 2. DISEÑO DEL SISTEMA

7. Situación Actual ........................................................................................................ 28

7.1. Funcionamiento del sistema actual ............................................................. 28

7.2. Descripción del entorno .............................................................................. 28

7.3. Procedimientos ........................................................................................... 29

7.4. Usuarios involucrados ................................................................................ 30

7.5. Información que se maneja ........................................................................ 31

7.6. Ventajas y desventajas de los procesos actuales ....................................... 31

8. Diseño del sistema .................................................................................................... 33

8.1. Diseño del sistema informático propuesto .................................................. 33

8.2. Especificaciones de requerimientos para el diseño .................................... 34

8.3. Modelado de objetos con UML ................................................................... 35

8.4. Descripción de los casos de uso ................................................................ 38

8.5. Mapa del sistema o diagrama gráfico modular ........................................... 39

8.6. Desarrollo de Prototipo ............................................................................... 40

8.7. Diseño de las interfaces ............................................................................. 41

8.8. Base de datos ............................................................................................ 42

8.9. Diccionario de datos ................................................................................... 44

8.10. Seguridad del sistema .............................................................................. 47

ETAPA 3. DESARROLLO E IMPLEMENTACIÓN DEL SISTEMA

9. Implementación del sistema ...................................................................................... 48

9.1. Pruebas de integración ............................................................................... 48

9.2. Planificación de las pruebas ....................................................................... 55

9.3. Confiabilidad, disponibilidad y facilidad de mantenimiento .......................... 59

9.4. Pruebas de aceptación ............................................................................... 60

9.5. Pruebas de instalación ............................................................................... 63

9.6. Entrega del sistema .................................................................................... 65

9.6.1. Plan de capacitación ...................................................................... 66

9.6.2. Documentación .............................................................................. 68

9.6.3. Plan de mantenimiento ................................................................... 70

Fuentes de información ................................................................................................ 72

Glosario de términos ..................................................................................................... 73

Anexos ......................................................................................................................... 74

Anexo 1. Roles del Equipo de proyecto ............................................................. 74

Anexo 2. Control de versiones ........................................................................... 75

Anexo 3. Ficha de solicitud de examen clínico ................................................. 76

Anexo 4. Ficha de resultados de examen clínico ............................................... 77

Anexo 5. Autoevaluación individual ................................................................... 78

2

INTRODUCCIÓN

El presente documento corresponde a la aplicación del ciclo de vida de desarrollo de

software y los aspectos fundamentales de la Ingeniería de Software al sistema

administrativo SysLab para el laboratorio clínico Medical Test.

En la primera etapa se abordaron en detalle los antecedentes del negocio, generando

así un punto de partida con las experiencias que ha tenido la empresa a lo largo de

sus actividades. Posteriormente, se estableció el planteamiento del problema a

resolver, dónde se estudiaron las diversas dificultades y deficiencias que presenta la

empresa, principalmente en su organización y definición de sus procedimientos,

consecuentemente se planteó de manera general la ventaja competitiva que aportará

el sistema.

En esta misma etapa, se analizó la situación de la empresa y a partir de esta

información se levantaron los requerimientos del sistema. Cada uno de los sub

apartados inherentes al análisis de requerimientos, se fundamentó en diversos

aspectos que se especifican en la Norma ISO 12207, con respecto al ciclo de vida del

software, y en el PMBOK con respecto a la formulación de proyectos.

Para el análisis de los requerimientos, se proporciona información del funcionamiento

actual de la empresa que solicita el software, así como de las razones que justifican

el desarrollo del mismo. Se detallan los resultados de la negociación de los

requerimientos, dónde se especifican claramente las funciones que deberá cumplir el

software en empresa, con la debida justificación de éstas, dando lugar así al diseño

inicial de la interfaz del usuario del software.

Luego de establecer todo lo relacionado al análisis de los requerimientos del sistema

(primera etapa) se realizó el diseño del sistema. Durante la segunda etapa se detalló

cómo funciona el negocio Medical Test en la actualidad, cómo está compuesto, qué

procedimientos se llevan a cabo y quienes son los usuarios involucrados en estos

3

procesos, para así poder estudiar las diversas ventajas y desventajas que presenta la

forma en que funciona empresa.

La segunda etapa se concentra en el diseño del sistema. De acuerdo a la naturaleza

del problema a solventar, se acordó gestionar el diseño de SysLab mediante una

arquitectura por descomposición modular, cuyos pilares son los controles, los reportes

y las transacciones.

En esta misma etapa se especificaron los requerimientos para el diseño, y

auxiliándose de un conjunto de herramientas de Ingeniería de Software asistidas por

computadora, se diagramaron cada uno de los objetos, procesos, usuarios y sus

funciones, que estarán involucrados de forma directa en el sistema. Además, se creó

un prototipo funcional que simulaba la operación en general de SysLab y presentaba

su diseño de interfaz.

La tercera y última etapa del presente trabajo está constituida por los procesos de

desarrollo e implementación de SysLab. En este apartado se presentan todas las

pruebas de integración, de aceptación y de instalación, y su respectiva

documentación.

Durante la última etapa se elaboraron los planes de capacitación y mantenimiento. El

primero se estructuró de manera que tanto el grupo de proyectistas, como el cliente

no tuviesen inconveniente alguno con establecer reuniones para capacitaciones en

los horarios establecidos y negociados. Por su parte, el plan de mantenimiento se

construyó pensando en que SysLab no se desatienda luego de ser implementado y

que de esa forma se asegure la satisfacción del cliente mediante la garantía del

producto.

SYSLAB – SOFTWARE ADMINISTRATIVO PARA EL LABORATORIO CLÍNICO MEDICAL TEST

4 ETAPA 1. ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE1

ETAPA 1. ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE

1 ANTECEDENTES DEL PROYECTO

La empresa Laboratorio Clínico Medical Test es una empresa creada en abril de

1999 por dos profesionales graduadas en Licenciatura en Laboratorios Clínicos de

la Universidad de El Salvador.

Inicialmente se graduaron de auxiliares de enfermería de cursos especiales

impartidos por el Hospital Militar y posteriormente iniciaron sus estudios superiores

universitarios pasando del departamento de enfermería al departamento de

Laboratorio Clínico. Después de trabajar varios años y especializarse en sus

diferentes unidades de laboratorio clínico, se unieron para conseguir financiamiento

y viajar para comprar el equipo básico necesario para iniciar el laboratorio.

Posteriormente, obtuvieron tanto la aprobación de la Junta de vigilancia como el

número registro y funcionamiento.

Actualmente al laboratorio clínico Medical Test tiene 15 años de estar funcionando,

tiene una buena cartera de pacientes, empresas privadas que realizan chequeos

periódicos a su personal operativo y con instituciones del estado.

Diseño estratégico

Misión

Brindar a nuestros clientes una alternativa de diagnósticos clínicos integrales

que generen bienestar y salud mediante la mejora continua de nuestros

servicios clínicos.

Visión

Nuestra visión es ser referentes nacionales en lograr la excelencia en los

servicios de laboratorio, basados en un aseguramiento de calidad que

propicio la satisfacción total a nuestros clientes.



Valores

o Confiabilidad

o Calidad

o Ética profesional

o Responsabilidad

Medical Test tiene como sus principales fortalezas la credibilidad y confianza

adquirida durante los años de funcionamiento; conforme el tiempo ha avanzado, la

empresa ha ido creciendo pero muy lentamente, sin embargo ha logrado

sobrellevar los tiempos de crisis con muchas dificultades y siempre manteniendo

un perfil bajo sin arriesgar mucho.

En ese sentido un de los factores del bajo crecimiento de Medical Test, es la falta

de modernización y mejoras de sus procesos operativos y de gestión; los cuales

actualmente son realizados de forma manual o en hojas en Excel y Word;

mecanismo que es menos eficiente, más lento y por consiguiente más trabajoso

para personal técnico y operativo.



2 PROPÓSITO

El laboratorio clínico Medical Test, en sus 15 años de funcionamiento, ha trabajado

todos los documentos administrativos y técnicos en hojas de Excel y documentos

de Word. Esta manera de gestionar la información de la empresa funcionó por unos

años, pero luego, se convirtió en una característica que restaba competitividad al

laboratorio frente a otras empresas que trabajan en el mismo rubro.

En cuanto a la gestión administrativa de la empresa, no existe un control de

pacientes, lo cual restringe el oportuno seguimiento de las futuras necesidades de

cada uno de ellos. Además, no existe un control de los doctores ni de las empresas

que solicitan exámenes clínicos, para sus pacientes y para sus empleados,

respectivamente.

En el mismo sentido administrativo, no existe un control eficaz de la recepción de

los requerimientos de servicios demandados por pacientes independientes,

doctores o empresas, y además, no existe un mecanismo ágil para el ingreso de

los resultados de un examen clínico. Dichas recepciones e ingresos de resultados

se manejan en formatos estáticos y no muy amigables al usuario, pues toda

información debe ser procesada manualmente, generando serias deficiencias en la

productividad del laboratorio.

Por otra parte, el laboratorio clínico Medical Test no puede obtener información

financiera y estadística acerca de su rendimiento, sus clientes, sus ventas

mensuales o anuales, por mencionar un par de ejemplos, de ninguna fuente, pues

las hojas estáticas en las cuales están alojados los datos, no están diseñadas de

manera tal que pueda extraerse de ellas información significativa que la gerencia

del laboratorio pueda convertir en conocimiento, y a su vez, convertir en una buena

toma de decisiones.



3 OBJETIVOS DEL PROYECTO

3.1. OBJETIVO GENERAL

Diseñar, desarrollar e implementar un sistema informático de gestión administrativa

que permita manejar controles y solicitudes procesados automáticamente, y

reportes estadísticos para el Laboratorio Clínico Medical Test.

3.2. OBJETIVOS ESPECÍFICOS

Desarrollar un módulo de control de clientes, doctores y empresas

agrupados por categorías.

Crear un control de talonarios de boletas enviadas por doctores, un control

de ingreso de boletas de análisis y un control de ingreso de resultados de

exámenes.

Desarrollar un mecanismo de notificación a clientes, doctores y pacientes de

los estados y resultados de sus exámenes.

Generar un módulo de información estadística automática y accesible a la

hora de realizar evaluaciones de paciente.

Desarrollar un módulo de reportes gerenciales y reportes transaccionales.

Implementar un procedimiento automático de respaldo de la información de

la empresa.



4 ANÁLISIS DE REQUERIMIENTOS

La falta de control, expedientes, seguimientos, y el uso de formatos estáticos para

manejar los datos de la empresa, son problemas que vienen afectando a la

productividad y competitividad del Laboratorio Clínico Medical Test desde hace

varios años. La empresa acudió a la ayuda del grupo de proyectistas para que éste

proponga una solución funcional y viable a sus problemas.

Primeramente, el sistema informático requerido por el laboratorio clínico Medical

Test será utilizado únicamente por los operadores, la gerencia y el administrador

del mismo dentro de las instalaciones de la empresa. Por tal razón, se propuso el

desarrollo de un sistema en ambiente de escritorio pues ninguna de las funciones

a implementar requiere de una conexión remota al software.

Al analizar la situación de la empresa, se pudo observar que ésta necesita de un

sistema informático que integre todas las funciones requeridas, tanto de gestión

administrativa, como gestión de documentos legales de la empresa. El sistema

informático debe solucionar todos los aspectos los dos rubros principales a analizar.

En cuanto al primero de dichos rubros, la gestión administrativa de la empresa, el

sistema debe proveer al usuario operativo un control de pacientes, en el cuál se

muestre de manera detallada toda la información personal de cada uno de los

clientes del laboratorio, de tal forma que se pueda llevar un seguimiento oportuno

de cada uno de ellos; un control de doctores, en el cuál se detallen las

características y datos de los doctores que solicitan uno o varios exámenes clínicos

a sus pacientes.

Además, se debe contar con un proceso que permita al usuario operativo ingresar

boletas de análisis clínicos solicitados por paciente o empresa, así como ingresar

los resultados de cada examen realizado. Al ingresar dichos resultados, el sistema

debe ser capaz de notificar al paciente o empresa, por medio de correo electrónico,

que los resultados de sus exámenes están listos para ser recogidos.



En cuanto a reportes, el sistema debe ser capaz de generar reportes de las

solicitudes de cada cliente, sea una empresa, un cliente independiente, las cuales,

deben agruparse por cliente, por fecha y por categoría, y de la misma forma, debe

ser capaz de generar reportes de los resultados de cada examen requerido.

Siguiendo en el ámbito de los reportes, el sistema propuesto contiene un apartado

para uso gerencial, en el cual, se pueden generar reportes de ventas diarias,

mensuales y anuales, de manera totalizada y también reportes de ventas

agrupadas por clientes y por empresas. Además, debe existir la generación de

reportes de ventas con contenido para la declaración de IVA mensual.

En ese mismo sentido, es necesario desarrollar un control de cobros y un control

de ingresos por ventas a caja general. En el último apartado, se debe llevar un

control de IVA, percepción y recepción en facturas.

Por otra parte, el sistema debe incluir un control de privilegios por usuarios, es decir,

un control que permita asignar las funciones específicas que cada uno de los

usuarios que operen el sistema puedan ejecutar, a modo de restringir la información

que puede obtener cada rol en el sistema y evitar fugas de información.

4.1 DETERMINACIÓN DEL ALCANCE DEL SISTEMA

El software SysLab tiene un enfoque administrativo y legal. El sistema no está

diseñado para el uso de los clientes. Es por esto que los clientes (independientes o

empresas) no podrán solicitar citas o exámenes en línea y, en general, no podrán

acceder a ninguna funcionalidad del software.

El sistema está siendo desarrollado para ejecutarse en un ambiente de escritorio.

Por ello, y de igual forma que los clientes, los gerentes, operadores y administrador

del sistema, no podrán conectarse al sistema de forma remota. La única manera de

acceder a los datos de la empresa es conectarse desde un equipo dentro de las

instalaciones de la misma.



4.2 OBTENCIÓN DE REQUISITOS

Los requerimientos del sistema fueron recopilados utilizando la técnica de

entrevistas, tomando como base el quinto apartado del PMBOK, con respecto a la

recopilación de requisitos, la técnica utilizada consiste en una entrevista formal con

los stakeholders.

En cuanto a la comunicación con el cliente, además de la realización de entrevistas,

se dio seguimiento a los requerimientos convenidos con el cliente mediante un

mecanismo de cambios, el cual consiste en recopilar los requisitos y analizarlos con

el equipo de proyectistas para establecer observaciones y resolver cualquier duda

con respecto a éstos.

Durante esta etapa se realizaron retroalimentaciones de los requerimientos con el

cliente. En ellas, se recopilaron las dudas que surgieron al cliente y se resolvieron

en su debido momento, y además, se recopilaron las observaciones que el cliente

realizó al prototipo y mientras fue posible, se incorporaron mejoras al sistema.

Este mecanismo de cambios en requerimientos se planteó de esa forma, con el

objetivo de evitar cualquier tipo de confusión en cuanto a las expectativas del cliente

y lo que el equipo de desarrollo implementó en el software. Cabe mencionar que

esto se realizó tomando como base el apartado F.1.3.1 de Obtención de

requerimientos en el Anexo F de la normativa ISO-EIC 12207.

Por otra parte, todo requerimiento o solicitud planteada por el cliente, se analizó

para determinar el impacto de ésta en el ambiente operacional de la empresa. Dicho

análisis se realizó con el objetivo de evitar que el cumplimiento de un requisito

generara conflicto con otra tarea que realice la empresa. Para ello se tomaron

como fundamento los lineamientos establecidos en el Anexo F de la normativa ISO-

EIC 12207, apartado F.1.3.2 de Análisis de requerimientos.



4.3 ELABORACIÓN DE REQUISITOS

Posterior a la recopilación de requerimientos y el estudio profundo de los procesos

existentes en la gestión administrativa de Medical Test, se determinó que SysLab

debía contar con los requisitos siguientes:

Control de clientes, doctores y empresas agrupados por categorías.

o Listar fichas de pacientes y doctores, agregar nuevas fichas, editar y

eliminar las fichas existentes.

o Listar empresas clientes y sus sectores, agrupar sectores por

empresa, agregar fichas de nuevas empresas, y editar y eliminar

fichas existentes.

Control de talonario de boletas de exámenes clínicos enviadas a doctores.

Ingreso de boletas de análisis clínicos solicitados por los médicos.

Ingreso de resultados de cada examen realizado.

Notificación a clientes sobre el estado de sus exámenes.

o Enviar resultados al cliente y al doctor, con sello y firma digitales, por

medio de correo electrónico.

Control de cobros e ingreso por ventas a caja general.

o Control de IVA, percepción y retención en facturas.

Control de privilegios por usuarios

o Establecer las funciones que puede realizar un usuario con un rol

específico dentro del sistema.

Reportes de cada uno de los módulos de la empresa.

o Reporte de cada solicitud (grupo de exámenes) de análisis clínico por

cliente, por fecha, por categoría.

o Reporte de ventas diarias y mensuales (Ingresos).

Reporte agrupado por clientes o doctores, según categoría de

éstos.

Reporte con contenido para la declaración del IVA mensual.

Copias de seguridad automáticas al apagar el equipo.



4.4 NEGOCIACIÓN DE REQUISITOS

En el proceso de retroalimentación de los requerimientos del sistema, se determinó

que el sistema sería capaz de cumplir con todos los requisitos solicitados y los

requisitos propuestos por el grupo de proyectistas, siempre y cuando la empresa

esté en la disposición de colaborar y facilitar la documentación o información

requerida para el desarrollo de cada una de las funciones a implementar en el

sistema, cuando el equipo de trabajo lo requiera.

4.5 ESPECIFICACIÓN DE LA INTERFACE DE USUARIO

Durante las entrevistas realizadas en la empresa, se determinó que el perfil del

usuario que utilizará el sistema posee conocimientos básicos de computación, por

tanto se ha planteado el diseño de una interfaz amigable con el usuario,

estableciendo un patrón de ubicación y accesibilidad de las diversas funciones que

se encuentren en cada pantalla, colocándolas en la parte superior de cada pantalla,

utilizando iconos representativos para facilitar la visibilidad de los mismos.

Figura 1. Interfaz de inicio del software.



Cuando el programa se inicia, muestra una pantalla con las funciones principales

del sistema, agrupadas en secciones, tal como se muestra en la figura 1. Cada una

de las secciones se representa por medio de un botón grande y vistoso que cuenta

con un ícono representativo, de tal forma que el usuario operador encuentre de

manera sencilla lo que busca.

Además de los botones de la pantalla de inicio, el usuario puede acceder a las

funciones del sistema mediante el menú ubicado en la parte superior de la ventana.

En las figuras de la 2 a la 6 se muestran, respectivamente, las opciones del menú:

Sistema, Operaciones, Administrar, Reportes y Ayuda.

Figura 2. Opción “Sistema” del menú.

Figura 3. Opción “Operaciones” del menú.

Figura 4. Opción “Administrar” del menú.



Figura 5. Opción “Reportes” del menú.

Figura 6. Opción “Ayuda” del menú.

Al seleccionar alguna de las opciones del menú, se despliega una pantalla que

muestra la información requerida. La mayoría de las pantallas del sistema, tal como

se puede ver en la figura 7, contienen información expresada en forma de tablas.

Cada una de las tablas posee identificadores de columna, lo que permite al usuario

ubicarse fácilmente en el contexto de la información.

Las tablas de cada pantalla poseen, en general, una caja de filtros, que pueden

aplicarse a los datos mostrados en la tabla. Cada una de las tablas cuyos datos

posean detalles, pueden ser seleccionadas. Una vez seleccionado un registro de la

tabla, se muestran los detalles del mismo en una tabla de detalles ubicada debajo

de la tabla principal de la interfaz.

Por otra parte, los reportes gerenciales tienen la estructura mostrada en la figura 8.

El reporte se divide en dos secciones. En el encabezado se muestra el logotipo de

Medical Test, información relevante sobre la empresa, el título del reporte, la fecha

y hora de impresión del reporte y el número de página; y en la sección de detalles

se muestra el contenido del reporte en sí.



Figura 7. Modelo de la interfaz de las pantallas informativas del sistema

Figura 8. Modelo de reportes gerenciales del sistema



4.6 CARACTERÍSTICAS DE USUARIOS

Entre los requisitos indispensables de SysLab, se establece un apartado que

corresponde a los privilegios de usuario, permitiendo así establecer un nivel de

seguridad en cuanto a la manipulación de la información que entra y sale a y desde

sistema. Un objetivo secundario es permitir subdividir las actividades según el rol

de cada empleado, por tanto, existen tres tipos de usuarios:

Operativo: capaz de realizar las operaciones cotidianas de la empresa,

ingresar información ya sea de clientes o doctores, así como el registro de

todas las solicitudes de exámenes clínicos y sus respectivos resultados, sin

embargo, no podrá realizar modificaciones ni anulaciones de documentos de

ningún tipo. Puede generar reportes de resultados.

Gerencial: además de las funciones operativas, posee la capacidad de

realizar modificaciones o anulaciones de los documentos, con una debida

justificación de las mismas. Por otra parte, este tipo de usuario está

habilitado para generar reportes de ingresos por ventas y llevar un control de

caja general con la ayuda del sistema.

Administrador: tiene la capacidad de eliminar documentos de manera

permanente, con un debido registro de dicha operación. El usuario de tipo

Administrador es el encargado de la administración de los usuarios del

sistema, incluyendo las credenciales y privilegios de éstos, además está

habilitado para realizar copias de seguridad del sistema, así como de la

restauración de las mismas.



5 MODELO DEL CICLO DE VIDA DEL SOFTWARE

El modelo del ciclo de vida que se implementó en el desarrollo del proyecto es el

modelo en cascada, tal como se muestra en la figura 9, teniendo como objetivo

principal que en cada fase del ciclo de vida, los componentes logren desarrollarse

de la manera correcta, manteniendo así un mejor orden en el desarrollo del proyecto

como tal.

Figura 9. Fases del modelo en cascada

El modelo en cascada es el enfoque metodológico que ordena rigurosamente las

etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada

etapa debe esperar a la finalización de la etapa anterior. Al final de cada etapa, el

modelo está diseñado para llevar a cabo una revisión final, que se encarga de

determinar si el proyecto está listo para avanzar a la siguiente fase. En general,

esta metodología utiliza cinco fases para implementar y aplicar el ciclo de vida de

desarrollo de software. En los siguientes sub apartados se detalla cada una de las

fases del ciclo de vida que se aplicó en el desarrollo de SysLab.



5.1 IDENTIFICACIÓN DE LA PROBLEMÁTICA

Se identificaron y determinaron correctamente los problemas que presenta la

empresa, analizando las diversas actividades que ésta realiza. Lo que se buscó en

esta fase es la oportunidad de mejoras mediante la implementación de una solución

informática, proporcionando a la empresa una ventaja competitiva y por ende, un

valor agregado.

Las actividades consistieron en entrevistar a los encargados de la administración

de los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto

y documentar los resultados.

5.2 DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN

Se utilizaron métodos interactivos como entrevistas, muestreos e investigación de

datos, también se observó el comportamiento de los encargados al tomar

decisiones y sus entornos de oficina.

Las principales interrogantes a resolver fueron:

¿Cuáles son las fortalezas y limitaciones físicas de los usuarios?

¿Qué hay que hacer para el sistema sea perceptible, legible y seguro?

¿Cómo puede diseñarse el nuevo sistema para que sea fácil de usar,

aprender y recordar?

¿Cómo puede el sistema ser agradable o incluso divertido de usar?

¿Cómo puede el sistema apoyar las tareas laborales individuales de un

usuario y buscar nuevas formas de hacerlas más productivas?

5.3 ANÁLISIS DE LOS REQUERIMIENTOS

En este apartado, el equipo de trabajo discutió cuál era la mejor manera de cumplir

los requerimientos planteados por el cliente, sin que esto conlleve a malas prácticas

de programación o desarrollo, de tal manera que se asegura la estabilidad del

sistema, así como de toda la información que éste maneje.



5.4 DISEÑO DEL SISTEMA

Durante esta fase se diseñaron los procedimientos para que los usuarios

introduzcan los datos con precisión, de manera que entren al sistema de

información sean los correctos.

La interfaz del usuario se diseñó con ayuda de los usuarios para asegurar que el

sistema sea perceptible, legible y seguro, así como atractivo y divertido de usar.

Se diseñó la base de datos que almacenará toda la información, considerando la

naturaleza de los datos establecidos en los requerimientos del software, de tal

manera que dicha base de datos se capaz de almacenar de manera íntegra toda la

información que el cliente ha solicitado controlar.

5.5 DESARROLLO Y DOCUMENTACIÓN

La metodología de trabajo que se ocupó es la de programación en parejas, de

manera que el proceso de programación será realizado en pareja como mínimo,

con el objetivo que el progreso fuese más rápido y que se tuviese una visión

complementaria al ir desarrollando cada una de las funciones del sistema.

Al finalizar el desarrollo de cada módulo se realizó un proceso de eliminación de

errores sintácticos y conceptuales con el fin de evitar la propagación de éstos en

posteriores fases.

5.6 PRUEBA Y MANTENIMIENTO

Se completó una serie de pruebas para señalar los problemas con datos de muestra

y después se utilizan datos reales del sistema actual. Esto se realizó debido a que

es menos costoso resolver problemas o errores del sistema cuando esto aún no ha

sido puesto en producción.



5.7 IMPLEMENTACIÓN Y EVALUACIÓN

Para realizar la implementación del sistema se estimó junto con el cliente, una fecha

para realizar la implantación del software, de tal forma que no afecte el calendario

operativo, tanto del Laboratorio, como del grupo de proyectistas.

En esta fase se darán capacitaciones a los usuarios para que puedan operar el

sistema. Dichas capacitaciones se programarán tal como se estipula en el capítulo

1 de este documento, en el apartado 1.6.4 Factibilidad de Fechas. Además, se

realizará un seguimiento del rendimiento del sistema así como la retroalimentación

de las experiencias que vayan teniendo los usuarios de la empresa.



6 FACTIBILIDAD

El software administrativo SysLab se desarrolló tomando en cuenta tres aspectos

fundamentales: sus factibilidades técnica, operativa y de fechas. En los siguientes

sub apartados se detallan cada uno de estos tres aspectos.

6.1 FACTIBILIDAD TÉCNICA

Para la elaboración del software para la empresa Laboratorio Clínico Medical Test

se necesitó de un equipo de programadores con conocimientos técnicos de nivel

intermedio-avanzado en el lenguaje de programación C#, así como un entorno

integrado de desarrollo, en específico Microsoft Visual Studio 2012 en su versión

Express. De la misma forma, se requirió de un sistema gestor de base datos que

permitiese montar una base de datos que alimente a la aplicación. En concreto, se

eligió Microsoft SQL Server 2012 en su versión Express. La ejecución del software

requiere de un ambiente de trabajo Microsoft Windows, partiendo desde la versión

de Windows 7 y sus sucesores.

Para poder ejecutar los entornos integrados de desarrollo y los sistemas gestores

de bases de datos necesarios para el desarrollo de SysLab, se requirió de tres

computadoras personales de gama media que soportaran la carga de trabajo que

se requirió. Además, las computadoras debían estar equipadas con herramientas

de Ingeniería de Software Asistido, que facilitarían el diseño del sistema.

Afortunadamente, el equipo de proyectistas contaba con el equipo informático

adecuado para llevar a cabo todas las tareas planteadas.

El correcto funcionamiento del sistema depende de su implementación en un

equipo informático con especificaciones técnicas de gama media baja, es decir, un

computador básico con una capacidad mínima de 1 GB de memoria RAM, un

procesador con una velocidad de reloj mínima de 1.5 GHz y 10 GB de espacio de

almacenamiento en disco duro.

Por último, algunas de las funciones del software como el envío de resultados por

correo electrónico requieren de una conexión a internet.



6.2 FACTIBILIDAD OPERATIVA

El sistema se diseñó de una manera visualmente agradable e intuitiva de tal forma

que el operador no tenga dificultades para encontrar lo que busca y realizar las

tareas que necesite. Para poder asegurar que SysLab cumpliese con estándares

aceptados actualmente, el equipo de proyectistas se auxilió, principalmente, de tres

de las cinco características de la usabilidad en las aplicaciones informáticas:

facilidad de aprendizaje, eficiencia y satisfacción. Con lo anterior, se buscó que el

usuario pueda en todo momento hacer un uso correcto y eficiente de SysLab.

Sin embargo, el uso correcto de SysLab no se garantiza únicamente

implementando estándares de usabilidad, sino que es evidentemente necesario un

plan de formación de usuarios involucrados en el manejo de la aplicación que

tendrá una estructura semanal según las tablas 1 y 2. Debido a que la empresa

Medical Test inicia sus labores de lunes a viernes a las 8:00 am, las capacitaciones

se llevarán a cabo desde las 7:00 am hasta las 8:00 am tres días por semana, de

forma que sus actividades no se vean interrumpidas. La estructura detallada del

plan de formación de los usuarios se encuentra en la tercera etapa del presente

documento, específicamente en el apartado 9.7.1. Plan de capacitación.

Los empleados de Medical Test serán capacitados para que hagan un uso correcto

de la aplicación y dichas capacitaciones se dividirán en lapsos de una o dos horas

máximo diarias durante una o dos semanas según se aprecie el avance en el

entendimiento de la plataforma, de tal manera que el laboratorio pueda ejecutar sus

labores diarias sin mayores interrupciones.

Tabla 1. Plan de formación semanal (Semana 1)

Día Contenido de la sesión Participantes

Lunes Sesión introductoria: conociendo SysLab.

Todos los empleados

Miércoles Sesión avanzada 1: Operaciones de administrador

Encargados de informática (administradores)

Viernes Sesión avanzada 2: Operaciones gerenciales

Gerencia



Tabla 2. Plan de formación semanal (Semana 2)

Día Contenido de la sesión Participantes

Lunes Taller de uso de SysLab Todos los empleados

Miércoles Documentación: manual de usuario y manual de sistema

Todos los empleados

Viernes Sesión dedicada a la resolución de dudas con respecto a SysLab.

Todos los empleados

6.3 FACTIBILIDAD ECONÓMICA

Los requerimientos establecidos y negociados durante la etapa de análisis y

requerimientos del sistema permiten al grupo de proyectistas evitar gastos previos

para la elaboración del sistema, es decir, no existe una inversión inicial, dado que

actualmente se cuenta con el equipo informático y herramientas de software

necesarias para el diseño y desarrollo de SysLab. El presupuesto de desarrollo e

implementación para el proyecto se detalla en la tabla 3.

Tabla 3. Presupuesto de desarrollo e implementación

N° Descripción Cantidad C/U Costo Total

DESARROLLO

1 Microsoft SQL Server Express 2012 1 $0.00 $0.00

2 Microsoft Visual Studio Express 2012 1 $0.00 $0.00

3 Equipo con SO Windows 7 o superior. 4 $0.00 $0.00

4 Mano de obra 3 $450.00 $1,350.00

SUBTOTAL DESARROLLO $1,350.00

IMPLEMENTACIÓN

5 Nuevo equipo informático 4 $0.00 $0.00

6 Licencias del producto 4 $0.00 $0.00

7 Servicios de migración de datos 1 $0.00 $0.00

SUBTOTAL IMPLEMENTACIÓN $0.00

SUBTOTAL PROYECTO $1,350.00

Imprevistos (5%) $67.50

TOTAL $1,417.50



6.4 FACTIBILIDAD DE FECHAS

Durante las fases del ciclo de vida de SysLab se ejecutaron actividades

correspondientes a cada una de ellas. Tal como se detalló en la etapa 1, en el

apartado 5. Modelo del Ciclo de Vida del Software, se utilizó una implementación

del modelo de desarrollo en cascada, tomando como referencia siete fases.

En la tabla 4 se muestra el cronograma de actividades para la ejecución del

proyecto en cuestión, en el que se detalla cada una de estas siete fases y dentro

de cada una de ellas se listan las actividades específicas a desarrollar que

permitirán completar la fase a la que corresponden, se listan los encargados de

ejecutar dichas actividades y el objetivo que se pretende alcanzar con la realización

de ellas mismas.

En el cronograma se pueden apreciar los intervalos de tiempo que demorará la

ejecución de cada una de las fases. El tiempo total estimado para la realización del

proyecto total es de doce semanas. Se dividió, por tal motivo, el cronograma en

seis intervalos, cada uno con una duración de dos semanas, pues la mayor parte

de las fases del proyecto se demorarán entre dos y cuatro semanas para ser

completadas.


25 ETAPA 1. ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE

Tabla 4. Cronograma de actividades

DESCRIPCIÓN DE LA ACTIVIDAD RESPONSABLE OBJETIVOS SEMANAS

1-2 3-4 5-6 7-8 9-10 11-12

Fase 1: Diagnostico, planificación y recopilación de información.

Diagnóstico de la situación de una empresa.

Identificación de los problemas que tiene dicha empresa con respecto sus ventas.

Solicitud de información general y específica de la empresa.

Análisis de viabilidad del desarrollo del sistema.

Kevin Gómez

Generar un diagnóstico de la situación actual de Medical Test.

Realizar entrevistas formales con empleados y directivos de Medical Test.

Realizar análisis de factibilidad técnica, operativa, económica y de fechas.

Fase 2: Requerimientos de información

Se establecen los requerimientos de información de la empresa

Se recopilan los diferentes documentos o formatos de documentos involucrados en las operaciones básicas de la empresa.

Se establecen la información de seguridad con la que debe contar el software.

Víctor Flamenco

Ejecutar reuniones con empleados operativos de Medical Test.

Sintetizar la información de los formatos brindados en Excel.

Diseñar una metodología de seguridad para el sistema que evite fugas de información.

Fase 3: Análisis de las necesidades

Se plantearán los diversos procesos o pasos en la atención del cliente, utilizando el sistema.

Flujo de información desde el ingreso de los tipos de exámenes, pasando por las

Kevin Gómez

Listar los componentes indispensables del sistema.

Listar los componentes deseables del sistema.

Detectar los requerimientos funcionales y no funcionales.




1-2 3-4 5-6 7-8 9-10 11-12

solicitudes de los clientes, hasta la entrega de resultados.

Negociar con el cliente los requerimientos que se desarrollarán.

Fase 4: Diseño del sistema

Determinación de las entidades que participan en los procesos, ya sea implícita o explícitamente.

Diseño de un diagrama de Entidad-Relación que permita visualizar la estructura general de la base de datos.

Diseño de la interfaz de usuario considerando que sea de fácil manejo y con un estilo agradable y formal

Víctor Flamenco Josué Serpas

Diseñar diagramas de casos de uso y diagramas de clases que reflejen el funcionamiento del negocio.

Realizar un diagrama Entidad-Relación que estructure la base de datos a implementar.

Fase 5: Desarrollo del sistema

Realizar el proceso de normalización de las entidades y las relaciones.

Creación de la base de datos configurada con los tipos de datos y relaciones adecuadas.

Programación de procedimientos almacenados, triggers u otras herramientas utilizadas para la conexión con la base de datos

Desarrollo del sistema: capa de datos

Desarrollo del sistema: capa de interfaz al usuario

Kevin Gómez Víctor Flamenco Josué Serpas

Programar un script en lenguaje SQL para la creación de la estructura de la base de datos normalizada.

Crear vistas para la extracción de información para los reportes empresariales.

Entablar comunicación entre el sistema y la base de datos.

Programar procedimientos de inserción y validación de datos.

Diseñar y programar el módulo de reportes de ventas y solicitudes.

Programar los módulos de control de pacientes, doctores, empresas y sectores.




1-2 3-4 5-6 7-8 9-10 11-12

Programar los módulos de solicitudes de exámenes y procesamiento de resultados.

Fase 6: Pruebas y mantenimiento

Compilación de la fase beta del sistema en un ambiente controlado.

Realización de transacciones de complejas para probar que el rendimiento sea el esperado.

Depuración y refactorización del código buscando mejoras en el rendimiento y posibles errores.

Josué Serpas Víctor Flamenco

Someter el sistema a pruebas de funcionalidad en condiciones similares a las que se enfrentará en Medical Test.

Comprobar la consistencia e integridad referencial de los datos ingresados.

Identificar y corregir errores de programación. Eliminar bugs.

Refactorizar el código fuente.

Fase 7: Evaluación e implementación

Compilación de la versión final del sistema, mediante Visual Studio 2012.

Monitoreo de las transacciones en la base de datos, tiempos de respuesta, bloqueos de solicitudes de servidor, etc. De tal manera de constatar que el sistema se comporta como se esperaba.

Kevin Gómez Víctor Flamenco Josué Serpas

Monitorear el rendimiento del sistema gestor de base de datos, mediante Performance Monitor, SQL Server Profiler y otras herramientas.

Compilar la versión final de SysLab.

Implantar la base de datos a producción en Medical Test.

Instalar SysLab en equipo de Medical Test


28 ETAPA 2. DISEÑO DEL SISTEMA

ETAPA 2. DISEÑO DEL SISTEMA

7. SITUACIÓN ACTUAL

El laboratorio clínico Medical Test tiene una experiencia en el mercado de más de 15

años. Durante su trayectoria, se ha trabajado todos los documentos administrativos y

técnicos en documentos estáticos que resultaban difíciles de mantener. En cuanto a la

gestión administrativa de la empresa, no existen controles que permitan operar de

forma eficiente y con la posibilidad de dar seguimiento a los pacientes, doctores y

empresas.

7.1. FUNCIONAMIENTO DEL SISTEMA ACTUAL

Actualmente todas las actividades administrativas que realiza el Laboratorio Clínico

Medical Test, se hacen en forma manual en formatos procesados en hojas electrónicas

Excel y procesador Word.

No existe un control informático de los pacientes atendidos, por tanto, todos los análisis

al ser procesados solo son guardados una pequeña cantidad de estos, cabe mencionar

y hacer énfasis en que tampoco existe una organización en el almacenamiento de los

datos de la empresa. No se cuenta con un software integrado que permita el

procesamiento, control, acceso de la información que le permita brindar una mejor

calidad en los servicios y poder proyectar un mayor crecimiento a corto, mediano y a

largo plazo.

7.2. DESCRIPCIÓN DEL ENTORNO

En Medical Test por el tamaño de la empresa aún no existe una departamentalización

claramente definida, sin embargo se pueden visualizar los procesos más importantes.

Administrativo

Atención a clientes.

Facturación y compras.



Procesamiento de resultados, revisión, sellado y firma de autorizado del

licenciado en turno.

Entrega de los resultados a los clientes, anotación en el libro de entrega de

exámenes.

Gestión de ventas y promoción

Se realizan visitas a empresas y a doctores para promocionar los servicios de

análisis clínicos y sus beneficios. Se envían cotizaciones vía correo electrónico

y se le da seguimiento al proceso de compra de las empresas.

Así mismo en esta área se llama a los médicos para darle seguimiento a las

necesidad de boletas y mantener una comunicación cercana con doctores de

diferentes especialidades.

Análisis Clínicos

Recepción y rotulación de las muestra, preparación de pacientes.

Toma de muestras y análisis de las muestras según procedimiento establecido

para cada examen.

Procesamiento y entrega de resultados a los clientes. En el servicio a domicilio

se desarrollan acciones de chequeo personalizado, dándole el servicio de

recolección y toma de muestra al personal técnico, administrativo y ejecutivo de

las empresas que así lo requiera hasta la comodidad de sus instalaciones, lo

cual requiere de una planificación, preparación de materiales, logística y algunos

procedimientos técnicos propios de los análisis.

7.3. PROCEDIMIENTOS

Debido al tipo del negocio, el procedimiento principal y fundamental a optimizar y

mejorar, actualmente abarca desde la recepción del paciente hasta la entrega de los

resultados. Actualmente, el procedimiento manual está descrito por los siguientes

pasos.



La secretaria se encarga en recibir al paciente, preguntar si trae una boleta

firmada por un médico, se le dice el costo de cada examen y el total de la factura.

Si no trae boleta, la secretaria marca en una boleta pre-impresa los exámenes

que el paciente necesita sin referencia de un médico.

La secretaria elabora la factura en forma manual y le cobra anticipadamente al

cliente el importe del total de los exámenes.

Posteriormente la secretaria acompaña al paciente a la toma de muestra y le

entrega la boleta al Licenciado de turno para que lo atienda.

El licenciado de turno toma la boleta de exámenes la verifica con el paciente y

recibe las muestra o procede a prepararlo para realizar la toma de muestra

según sea el caso.

Una vez realizado el análisis clínico los resultados, estos son vaciados en un

formato manual, con esta información posteriormente es llenado en la boleta de

resultados de los exámenes por la secretaria. Luego de ser llenado, revisado,

firmado y sellado por el licenciado de turno, el resultado es regresado a la

secretaria.

Cada boleta se coloca en sobres membretados y colocan en un folder para ser

entregados a los interesados que posteriormente entregaran en manos de los

médicos que han requeridos los exámenes.

7.4. USUARIOS INVOLUCRADOS

Medical Test tiene cinco grupos de empleados. Cada uno posee un conjunto de tareas

que debe cumplir. Dichos grupos y sus actividades correspondientes son:

Gerencia: Se encarga de los procesos administrativos de la empresa

Contador: Se encarga de los registros contables y cumplimiento de las

obligaciones fiscales y laborales.

Secretarias: Recepción y atención de pacientes, recepción de llamadas,

facturación, cobros, elaboración de boletas, entrega de exámenes.

Mensajero: Se encarga de llevar la correspondencia, los pagos a bancos, entre

otros.



Licenciados y técnicos en laboratorio clínico: Se encargan de preparar al

paciente y realizar la toma de muestra. El licenciado supervisa los resultados y

es encargado del control de calidad.

7.5. INFORMACIÓN QUE SE MANEJA

En Medical Test se maneja información general de:

Pacientes, proveedores, empresas, pacientes por empresas, médicos.

Control de reactivos.

Estadísticas de compras.

Expedientes de pacientes.

Expedientes de empresas.

Historial de exámenes realizados por cada paciente, control de pacientes por

cada médico.

Chequeos anuales, semestrales y trimestrales por empresas y pacientes.

Control de padecimientos y deficiencias de cada paciente.

Reportes consolidados de resultados por grupo de empleados y reporte de

empleados con necesidad de tratamiento.

7.6. VENTAJAS Y DESVENTAJAS DE LOS PROCESOS ACTUALES

Como se puede observar el Laboratorio Clínico Medical Test por su naturaleza, debe

llevar estadísticas de todo tipo; actualmente la información antes mencionada se lleva

en forma manual y se archiva en folder.

La forma de almacenar y acceder a la información es muy deficiente, lo cual no permite

obtener la información de forma inmediata y con la exactitud que se requiere, dado que

a esto se le agrega que no existe un procedimiento o estructura de almacenamiento de

datos que permite mantener la información correctamente ordenada y clasificada.



Esta forma manual de realizar la mayoría de los procesos del laboratorio, le restan

competitividad y eficiencia a la hora de brindar los servicios a sus clientes.

La utilización de la solución informática propuesta conlleva a obtener determinadas

ventajas en los procesos que realiza la empresa, principalmente en aspecto de tiempo,

y control organizado de la información, permitiendo tener los datos prácticamente al

alcance en cualquier momento.

Tabla 5. Ventajas y desventajas del sistema actual

Ventajas Desventajas

Las capacidades técnicas informáticas requeridas para realizar los procesos actuales son básicas

La implantación de un sistema informático nuevo requiere de habilidades técnicas computacionales intermedias y capacitación de personal

Los procedimientos realizados son sumamente flexibles si se necesitan cambios dado que no dependen de un sistema establecido para el modelo del negocio

La alta flexibilidad de los procesos de negocio puede ocasionar irregularidades o incoherencias dentro de la operación del negocio si no se supervisan.

No se tiene un registro histórico digital de los resultados de análisis clínicos.

Realizar un cambio a los formatos de documentos utilizados por la empresa es complicado

El cálculo de ventas de la empresa puede complicarse debido a la forma en que se manejan las solicitudes.

La información es susceptible a ser manipulada dado que no existen medidas de seguridad para el controlar el acceso a ésta



8 DISEÑO DEL SISTEMA

Para poder asegurar una buena gestión del diseño del sistema, fue necesaria una

reunión entre el grupo de proyectistas, dentro de la cual, se discutió sobre la manera

óptima para resolver los problemas de Medical Test.

Se decidió optar por una segmentación el sistema completo en módulos más pequeños

que permitiesen simplificar el trabajo, y a su vez, que dichos segmentos pudieran

integrarse una vez desarrollados.

Por su parte, para diseñar la base de datos, se tomaron como punto de partida los

formatos en hojas de Excel proporcionados por el laboratorio, para tener un listado de

los campos que el laboratorio necesita, y los campos que deben añadirse para que el

sistema sea funcional de acuerdo a los requerimientos establecidos.

8.1 DISEÑO DEL SISTEMA INFORMÁTICO PROPUESTO

Para gestionar el diseño del sistema, se ha utilizado una herramienta CASE llamada

SyBase PowerDesigner en su versión 16.5. Dicha herramienta facilitó la creación de

diagramas de casos de uso y diagramas de clases para modelar el sistema.

El diseño se basa en una arquitectura por descomposición modular. Se dividió el

software en tres módulos: controles, reportes y transacciones.

Controles: En este módulo se diseñarán las entidades Paciente, Doctor y Empresa. Es

aquí donde se tendrá un registro de las fichas completa con la información respectiva

de cada uno de los actores mencionados.

Reportes: Se diseñará el apartado específico para la generación de reportes de ventas,

solicitudes y datos estadísticos.

Transacciones: Todas las actividades transaccionales ejecutadas por el operador a

diario en el laboratorio se agrupan en este módulo. Entre ellas están: ingreso de

solicitudes de exámenes, ingreso y procesado de resultados de exámenes y

notificaciones electrónicas a los clientes.



Cada uno de los tres módulos fundamentales que componen el proyecto es

independiente funcionalmente de los demás, es comprensible y se acopla y adapta con

los restantes.

8.2 ESPECIFICACIONES DE REQUERIMIENTOS PARA EL DISEÑO

SysLab requiere de las siguientes entidades: pacientes, doctores, exámenes, empresas

y procedimientos. Los procedimientos pueden ser operacionales, gerenciales y

administrativos. Cada una de las entidades y procedimientos se detallan a continuación:

Pacientes: Control de los pacientes

Nombre, fecha de nacimiento, correo electrónico, teléfono, fecha de ingreso,

dirección.

Doctores: Control de doctores y Control de doctor predeterminado por paciente.

Nombre, fecha de nacimiento, correo electrónico, teléfono, fecha de ingreso,

dirección.

Exámenes: Control de exámenes por categorías y por subcategorías y Control de

exámenes de sangre, heces, orina y VDRL. Las categorías son:

Química sanguínea

o Hormonas, electrolitos, pruebas hepáticas, enzimas, inmunología y

general.

Hematología: general, orina y heces.

Bacteriología: general.

Empresas: Control de empresas, Control de clientes y doctores de la empresa y Control

de fechas de exámenes clínicos anuales.

Control de sectores por empresa

o Control de clientes por sector

Procedimientos:



Operacionales

o Ingreso de boletas de análisis clínicos solicitados por los

pacientes/empresas.

o Ingreso de resultados de cada examen clínico realizado.

o Notificar al cliente que sus exámenes ha sido realizados

Enviar resultados al cliente y al doctor, con sello y firma digitales,

vía electrónica.

Gerenciales

o Control de cobros e ingreso por ventas a caja general.

Control de IVA, percepción y retención en facturas.

o Control de talonario de boletas de exámenes clínicos enviadas a doctores.

o Reportes de cada uno de los módulos de la empresa.

Reporte de cada solicitud (grupo de exámenes) de análisis clínico

por cliente, por fecha, por categoría.

Reporte de ventas diarias y mensuales (Ingresos).

Reporte agrupado por clientes o doctores, según categoría

de éstos

Reporte con contenido para la declaración del IVA mensual.

Administrativos

o Control de privilegios por usuarios

Que se pueda establecer las funciones que puede realizar un

usuario en el sistema.

o Realizar copias de seguridad automáticas al apagar el equipo.

8.3 MODELADO DE OBJETOS CON UML

Existen cinco actores principales en los procesos que se ejecutan dentro del laboratorio.

Los pacientes, doctores y empresas son los que actúan fuera del sistema, mientras que

el gerente, administrador y operador actúan de forma directa con el sistema.



En la figura 10 se presenta el diagrama conceptual del funcionamiento de SysLab, que

representa un modelo esquematizado general de los actores del sistema; mientras que

el diagrama de la figura 11 muestra las operaciones generales que puede ejecutar cada

uno de los actores en el sistema. Luego, en la figura 12 se puede ver cómo interactúan

cada uno de ellos para poder llevar a cabo los procesos que hacen que el laboratorio

funcione.

Figura 10. Diagrama conceptual del sistema

Figura 11. Diagrama de clases del sistema



Figura 12. Diagrama de casos de uso del sistema



8.4 DESCRIPCIÓN DE LOS CASOS DE USO

El funcionamiento de todos los procesos que se ejecutan dentro del laboratorio

clínico se ha diseñado de tal manera que tenga como actores fundamentales a:

paciente, doctor, operador, gerente y administrador. Cada uno de estos actores

debe realizar una serie de pasos ordenados para completar una tarea específica.

La actividad inicial en el proceso es la solicitud de exámenes. Esta puede realizarse

de dos maneras:

a) Un paciente enfermo asiste a una clínica privada o pública y el doctor que lo

atiende solicita al cliente un examen clínico para brindar un correcto

diagnóstico. El paciente entonces se dirige al laboratorio clínico y hace una

solicitud de los exámenes requeridos. En este punto, entra en juego el

operador, quien debe buscar una ficha del paciente. Si dicha ficha no

existiera, debe crear una nueva ficha con los datos del cliente.

b) Una empresa, ya sea por rutina o por requisito legal, solicita una serie de

exámenes clínicos al laboratorio para un grupo de empleados. El operador

del sistema debe buscar una ficha de la empresa y los empleados asignados

para los exámenes. Si dicha ficha no existiera, debe crear una nueva con los

datos de la empresa y la persona de contacto de la misma.

En cualquiera de los dos casos anteriores, el operador debe ingresar al sistema una

solicitud de examen de parte del paciente o la empresa en cuestión. Una vez que la

solicitud fue ingresada, el laboratorio clínico debe encargarse de ejecutar el examen

y notificar a un operador que los resultados están listos.

En este punto, el operador debe ingresar los resultados de los exámenes al sistema.

El sistema se encarga de enviar una notificación por medio de correo electrónico de

manera automática a la empresa o cliente respectivo, en la cual, se comenta que

los resultados del examen o exámenes solicitados están listos. Pasado este punto,

el cliente debe presentarse a recoger los resultados de sus exámenes y con eso

finaliza el proceso.



Ahora bien, el gerente por su parte puede generar reportes de ventas y de

solicitudes desde el sistema. A su vez, puede despachar talonarios y controlar el

IVA que maneja el sistema.

Por otra parte, el administrador puede modificar los privilegios de los usuarios, editar

la información de los usuarios y agregar nuevos usuarios. Además, es el

administrador quien se encarga de realizar las copias de seguridad de la

información.

8.5 MAPA DEL SISTEMA

El módulo principal del sistema es un formulario MDI, el cual contiene un menú

principal. Dicho menú posee secciones que representan cada una de las

agrupaciones de tareas relacionadas dentro de los procesos administrativos del

software de gestión administrativa SysLab. En la figura 13 se aprecia el mapa de

SysLab con sus secciones y sub secciones relacionadas.

Figura 13. Mapa del sistema

Syslab

Sistema

Administrar

Catálogo de análisis

Categorias

Familias

DatosUsuarios

Empresas

Pacientes

Doctores

Operaciones Solicitudes

Cotizaciones

Procesar Resultados

Reportes

Reporte de boletas

Ventas Diarias

Ventas Mensuales

Ayuda



A continuación se detallan las secciones mostradas:

Sistema: La sección Sistema permite obtener o establecer parámetros relacionados

a las leyes vigentes en el ámbito de impuestos. Esta sección es mayormente

dedicada al administrador del sistema y en ella se pueden administrar, valga la

redundancia, los usuarios del sistema y a su vez, los respaldos de información que

permiten tener un plan de recuperación en caso de desastres.

Operaciones: En esta sección se agrupan la mayoría de las tareas del usuario

operador, es decir, las funciones cotidianas o transacciones habituales del negocio,

dada su naturaleza de atención al cliente.

Administrar: El operador tiene acceso a esta sección. En ella se pueden, valga la

redundancia, administrar las entidades básicas del funcionamiento del sistema:

pacientes, doctores, empresas y sectores de la empresa.

Reportes: Dentro de la sección de reportes, el gerente puede acceder a un módulo

de generación de reportes de ventas y a su vez, a un módulo de generación de

reportes de solicitudes. El operador también puede generar los últimos.

Ayuda: En este apartado se puede acceder al Manual de Usuario, el cual se

encontrará disponible en formato PDF, incluyendo detalladas explicaciones de

cómo realizar procesos dentro del sistema, así como capturas de pantalla

representativas de cada situación.

8.6 DESARROLLO DE PROTOTIPO

Entre los elementos funcionales del software Syslab se puede visualizar el

formulario del Dashboard en la figura 1 del apartado de la interfaz de usuario, dicho

componente contiene todas las respectivas opciones que tendrá el usuario que vaya

a utilizar el software para acceder a cada uno de los módulos de control de usuarios,

solicitud de análisis, control de pacientes, empresas, resultados de los exámenes,

entre otros.

Entre las opciones del menú, existe un apartado en “Sistema” dónde se

manejan los usuarios, parámetros, respaldo y la opción salir del programa.



En el apartado de “Operaciones” se mostrarán las opciones como las

cotizaciones, ingresar las solicitudes, procesar los resultados y el control de

talonarios.

En el apartado de “Empresas” se mostrará el control a las empresas, los

doctores, los sectores y los pacientes.

Luego en módulo de “Reportes” se generará información importante de las

ventas, las solicitudes y los resultados.

Finalmente, existe un apartado de “Ayuda”, dónde se muestra la opción del

manual de usuario y la información acerca del software, así como la licencia

que la empresa posee sobre el mismo.

El prototipo realizado se diseñó y se estructuró en conjunto con el empresario para

determinar cuáles eran las preferencias de éste, así como la terminología que le

resultaría más fácil comprender a sus empleados, se escogieron color claros con

los que el usuario se siente cómo y la finalidad de haber diseñado un dashboard de

las funciones principales del sistema es que el usuario final al entrar al sistema

puede identificar fácilmente, mediante botones grandes, la función a la que desea

acceder.

8.7 DISEÑO DE LAS INTERFACES

Tal como se mencionó en el capítulo I, apartado 1.4.5 Especificación de la interfaz

de usuario, SysLab cuenta con un formulario MDI principal, en el cual se muestra

un elegante menú con botones de vistosos y amigables al usuario cada vez que se

inicia el programa (ver figura 1).

El sistema completo posee ocho pantallas principales. Sin embargo, los privilegios

de los usuarios definen cuáles de esas pantallas son las que cada usuario puede

utilizar. Las pantallas se detallan en la tabla 6. En la columna de la derecha,

denominada ‘Usuarios’ se especifica qué tipo de usuario puede hacer uso de dicha



pantalla o funcionalidad, y se representan los tipos de usuarios con un número de

la siguiente manera: (1) administrador, (2) gerente y (3) operador.

Tabla 6. Detalle de las pantallas principales del sistema.

8.8 BASE DE DATOS

A continuación, en la figura 14 se presenta el esquema del diagrama de entidad

relación que se ha estructurado y modelado para el funcionamiento del sistema

Pantalla Descripción Usuarios

Control de usuarios

Se listan todos los usuarios que tienen una contraseña de acceso al sistema

1

Solicitud de análisis

Se muestra un formulario con todos los datos necesarios para ingresar solicitudes de exámenes clínicos por parte de clientes independientes o empresas.

3

Copias de seguridad

Esta pantalla permite guardar una copia de seguridad de los datos de la empresa.

1

Resultados de análisis

Se muestra un detalle de los resultados obtenidos en un examen o un grupo de exámenes de cada uno de los pacientes seleccionados, o de una empresa seleccionada.

3

Pacientes Se muestra un listado de todos los pacientes registrados. En el listado se pueden realizar filtros y búsquedas. Es en esta pantalla donde se administra la información y seguimiento de cada uno de los pacientes del laboratorio.

2 y 3

Empresas Se muestra un listado de todas las empresas registradas. En el listado se pueden realizar filtros y búsquedas. Es en esta pantalla donde se administra la información y los contactos de las empresas clientes del laboratorio.

2 y 3

Sectores Se muestra un listado de los sectores de cada empresa registrada. Pueden asignarse nuevos sectores.

2 y 3

Doctores Se muestra un listado de todos los doctores registrados. En el listado se pueden realizar filtros y búsquedas. Es en esta pantalla donde se administra la información de contacto de cada uno de los doctores que han solicitado un examen al laboratorio.

2 y 3

Cotizaciones En esta pantalla se muestra un listado de los servicios prestados por el laboratorio. Es aquí donde se realizan simulaciones del total a cancelar por parte de un paciente o empresa al solicitar una cantidad cualquiera de servicios.

2 y 3

Parámetros Se configuran valores predeterminados como el valor del IVA, entre otros.

2

Reportes de Ventas

Se generan reportes automáticamente sobre las ventas diarias o mensuales del laboratorio,

2

Manual de usuario

Documento en formato PDF que contiene los pasos detallados para realizar las operaciones básicas del sistema.

1, 2 y 3



Figura 14. Diagrama Entidad-Relación


44 ETAPA 2. DISEÑO DEL SISTEMA1

8.9 DICCIONARIO DE DATOS

La base de datos de SysLab está formada por las tablas y relaciones mostradas en

la figura 11. En esta sección se detalla un conjunto de metadatos que contiene las

características lógicas y puntuales de los datos que se van a utilizar en el sistema

que se programa, incluyendo nombre y descripción. En el siguiente diccionario de

datos se encuentra la lista de los elementos más importantes que forman parte del

flujo de datos de todo el sistema.

Doctor: tabla que almacena los datos personales y empresariales de los médicos

que podrán solicitar exámenes clínicos a pacientes. En la tabla 7 se muestra el perfil

del doctor. Es importante también mencionar que el doctor es el destinatario de los

resultados de los exámenes.

Tabla 7. Doctor

CAMPO DESCRIPCIÓN

FECHA_NAC Fecha de nacimiento

FECHA ING Fecha de ingreso

NOMBRES Nombres del doctor

APELLIDOS Apellidos del doctor

DUI Documento único de identidad

NIT Número de registro del trabajador

TELEFONO Número telefónico de contacto

EMAIL Correo electrónico

DIRECCIÓN Ubicación

Empresa: tabla que almacena los datos generales y legales de cada una de las

empresas que requieren de análisis clínicos para todos sus empleados, sus

empleados específicos de uno de sus sectores o un empleado en específico. En la

tabla 8 se muestra el perfil de cada empresa.



Tabla 8. Empresa

CAMPO DESCRIPCIÓN

NOMBRE Nombre completo de la empresa

FECHA_ING Fecha de ingreso al sistema

GIRO Giro de la empresa

TAMAÑO Micro, mediana, Grande

MUNICIPIO Municipio de ubicación de la empresa

DEPARTAMENTO Departamento donde está ubicada

SECTOR Sector de comercio

TELEFONO Teléfono de contacto

EXTENSION

FAX

ISSS

NIT Número de Identificación Tributaria

EMAIL Correo electrónico donde serán enviados los

resultados

CONTACTO_NOMBRE Nombre de la personas de contacto directo entre

el laboratorio y la empresa

CONTACTO_TELEFONO Teléfono de persona de contacto

Paciente: tabla que almacena los datos personales relacionados a los pacientes

de Medical Test. Su perfil se aprecia en la tabla 9.

Tabla 9. Paciente

CAMPO DESCRIPCIÓN

FECHA_NAC Fecha de nacimiento del paciente

FECHA_ING Fecha de registro del paciente en el sistema

NOMBRES Nombre completo del paciente

APELLIDOS Apellidos completos del paciente

DUI Documento único de identidad

NIT Número de identificación del trabajador



TELEFONO Teléfono de contacto

EMAIL Correo electrónico al que serán enviados los resultados

DIRECCION Ubicación del paciente

Sector: La tabla 10 presenta la estructura de la entidad Sector, que representa a un

sector de cada empresa vinculada a la empresa. Los sectores son divisiones de la

empresa encargadas de algún rubro en específico.

Tabla 10. Sector

CAMPO DESCRIPCIÓN

NOMBRE Nombre del sector en la empresa

DESCRIPCION Descripción del sector

Solicitud: entidad que representa cada una de las ventas de exámenes clínicos de

cualquier categoría y familia establecida en SysLab. En la tabla 11 se aprecian los

atributos de esta tabla y sus respectivas descripciones.

Tabla 11. Solicitudes

CAMPO DESCRIPCIÓN

FECHA_ING Fecha de registro en el sistema

FECHA_MOD Última fecha de modificación del registro en el sistema

GRAVADO Monto sujeto a impuestos

EXENTO Monto exento de impuestos

IMPUESTO Monto total del impuesto aplicado

SUBTOTAL Suma del monto gravado e impuesto

RETENCION Retención de grandes contribuyentes

TOTAL Monto total de la factura



8.10 SEGURIDAD DEL SISTEMA

Para garantizar la seguridad el sistema y la fortaleza de las contraseñas, se

implementó encriptación MD5 de 128 bits para el almacenamiento de las mismas

entre otros datos importantes del sistema, de tal manera que ni siquiera un

administrador de base de datos puede ver las contraseñas almacenadas.

La encriptación mencionada se caracteriza por ser unidireccional, por tanto el valor

original almacenado no puede ser obtenido por un proceso inverso.

El sistema cuenta con un control de usuarios, permitiendo clasificarlos en tres tipos

fundamentales: operativo, gerencial y administrativo. Cada tipo de usuario contará

con determinados privilegios que permitirán delimitar las funciones y el alcance o

manejo de la información de la empresa, solo a aquellas personas que la requieran.

El detalle específico de los tipos de usuario se detalla en la sección 4.6

Características de los usuarios.

Cabe mencionar se realizó una clasificación de todas las funciones que posee el

sistema, de tal manera que en el funcionamiento interno del software, luego que un

usuario inicia sesión, se guardará el nivel de privilegios que éste posea y se

comparará internamente en cada uno de los módulos con el nivel de privilegio

previamente clasificado de una determinada función que el usuario desee realizar

o acceder.

Por otra parte, para la implementación de software se configuró el componente

gestor de base de datos con parámetros no predeterminados y con claves, todo

con el objetivo de evitar no dejar expuesto el sistema a ataques de puertos o

instancias predeterminadas de base de datos.


48 ETAPA 3. DESARROLLO E IMPLEMENTACIÓN DEL SISTEMA

ETAPA 3. DESARROLLO E IMPLEMENTACIÓN DEL SISTEMA

9. IMPLEMENTACIÓN DEL SISTEMA

Con el objetivo de asegurar la calidad y satisfacción en la experiencia del usuario,

se realizaron diversas pruebas de integración entre los diferentes módulos que

componen el sistema para comprobar el correcto funcionamiento del sistema en

general.

Igualmente, un aspecto importante del proyecto fueron las pruebas de aceptación

del software realizadas en conjunto con los futuros usuarios del sistema. Dichas

pruebas fueron realizadas por módulos de tal manera que los usuarios podían

aprobar el trabajo realizado y la funcionalidad de los módulos propuestos.

Para asegurar que el sistema se comportara correctamente en el entorno en cual

se va a trabajar, se realizaron pruebas de implementación orientadas a la instalación

del software, configurando los diversos componentes y requerimientos del sistema

operativo.

9.1. PRUEBAS DE INTEGRACIÓN

Para comprobar el correcto funcionamiento del sistema como un todo, se realizaron

pruebas de integración entre los módulos relacionados, realizando operaciones

básicas de inserción de datos y corroborando la integridad de los datos generados

por las operaciones entre módulos.

9.1.1. INTEGRACIÓN ENTRE MÓDULOS DE PACIENTES Y EMPRESAS

Para realizar la prueba, se comenzó por agregar pacientes con información de

prueba como se observa en la figura 15. La información de prueba incluye los datos

personales y datos legales del paciente.



Figura 15. Módulo de pacientes

Posteriormente, se procedió a ingresar empresas de prueba e ingresar sectores

para poder asignar pacientes tal y como se observa en las figuras 16 y 17.

Posterior al haber realizado la inserción de los datos de prueba para pacientes se

comprobó que el módulo de empresas obtenía correctamente los datos de los

pacientes para poder agruparlos por sectores, diferenciando entre pacientes

asignados y no asignados. Por tanto, la prueba fue satisfactoria y permite constatar

que la información tanto de los pacientes como de las empresas se mantiene de

manera integrada correctamente.

Figura 16. Empresas – Sectores



Figura 17. Sectores - Pacientes

9.1.2. INTEGRACIÓN ENTRE MÓDULO DE CATÁLOGO DE ANÁLISIS CON EL

MÓDULO DE SOLICITUDES DE ANÁLISIS CLÍNICOS

Para comprobar la correcta integración del módulo de catálogo de análisis con el

módulo de solicitudes, se realizaron procedimientos de inserción de datos de prueba

para verificar que la información de los tipos de análisis es obtenida correctamente

por la interfaz de solicitudes de análisis clínicos. A continuación, en la figura 18, se

muestra una captura del procedimiento de inserción de datos de prueba.

Figura 18. Inserción de análisis de prueba



Posteriormente, se realizaron pruebas con la interfaz de solicitudes de análisis

clínicos agregando cierta cantidad de ítems, modificando precios de venta así como

editando posteriormente los registros agregados y comprobando la integridad de los

datos. A continuación, en la figura 19, se muestra cómo el módulo de solicitudes

obtiene información de los análisis clínicos como su nombre y precios de venta.

Figura 19. Inserción de análisis de prueba

9.1.3. INTEGRACIÓN ENTRE MÓDULO DE RESULTADOS CON EL MÓDULO

DE SOLICITUDES DE ANÁLISIS CLÍNICOS

Un aspecto importante integración es verificar que los campos de resultados de los

análisis clínicos se obtengan correctamente para realizar el procedimiento de

ingreso de resultados, conservando sus respectivas propiedades como los rangos

de referencia y las unidades de medida. Para una mejor comprensión, los campos

de resultados para un análisis de ejemplo se muestran en la figura 20, y el

procesamiento de los resultados se muestra en la figura 21.



Figura 20. Campos de análisis para procesar resultados.

Figura 21. Procesamiento de resultados según los campos del análisis solicitado



Cabe mencionar que no todos los rangos de los campos son mostrados debido a

que los tipos de campo mostrados no son de valor referencia sino de campo

referencia; igualmente se puede apreciar que los campos y su referencia son

obtenidos satisfactoriamente.

9.1.4. INTEGRACIÓN ENTRE MÓDULO REPORTE DE ANÁLISIS CLÍNICO CON

LOS RESULTADOS, ANÁLISIS Y CATEGORÍAS

Un aspecto importante de integración a comprobar fue el reporte final del análisis

clínico realizado proveniente de la solicitud de un paciente. Dicho reporte posee

cierta complejidad la cual está determinada por la presentación que deben poseer

los campos de los resultados puesto que son 3 tipos de presentaciones y el reporte

debe ser generado dinámicamente y ajustarse al tipo de dato. Para realizar la

prueba se procesó completamente una solicitud de análisis clínico como se observa

en la figura 22.

Figura 22. Análisis completado

Posteriormente, se generó un reporte del análisis para comprobar que los campos

de resultados fueran presentados correctamente según su tipo, así como agrupados

por el tipo y adicionalmente por la categoría del análisis, mostrando la información

respectiva en cada apartado de manera satisfactoria. El resultado de la prueba

realizada se muestra en la figura 23.



Figura 23. Resultado la prueba de reporte de análisis integrando el catálogo,

categorías y solicitudes de análisis clínicos.



9.2. PLANIFICACIÓN DE LAS PRUEBAS

Para poder definir un plan de pruebas es necesario conocer el plan de desarrollo

del producto, que puede apreciarse en el apartado 6.4, Factibilidad de fechas, en el

que se detalla qué componentes específicos se desarrollarán en las fases de ciclo

de vida del sistema y en qué intervalo de tiempo. Además, se necesita el control de

versiones (ver anexos), con el fin de conocer qué parte de SysLab evolucionó, pues

a cada componente modificado se debe aplicar una serie de pruebas de verificación

que permitan asegurar la operatividad del mismo.

Basándonos en la tabla 4, en la sección 6.4. Factibilidad de fechas, específicamente

en las fases 5 y 6 del modelo de ciclo de vida del sistema planteado, se plantean

en la tabla 12 todas las actividades relacionadas a dichas fases, especificando en

cada una de ellas las entradas posibles, sus salidas esperadas, la prueba que se

realizó, junto con sus resultados, las fechas en que se realizaron cada una de ellas

y sus comentarios.

Cabe resaltar que el proceso de pruebas se compuso de un conjunto de pruebas

iterativas a los componentes individuales durante el desarrollo del sistema, y un

conjunto de pruebas generales al sistema unificado.



Tabla 12. Resultados de las pruebas

Componente Prueba realizada Entradas Salidas esperadas

Estado Fecha Realizó Comentarios

Comunicación entre la aplicación y la base de datos

Se colocó el nombre del servidor local de la computadora, el usuario de autenticación de SQL Server configurado durante la instalación, y su contraseña.

Nombre del servidor, usuario de la base de datos y contraseña asociada al usuario

Enlace a una instancia de la base de datos en SQL Server

Superada 24/09/2014 Kevin Gómez

La comunicación entre la aplicación y la base de datos fue exitosa. El tiempo de respuesta del motor de base de datos de SQL Server fue corto.

Procedimientos de inserción, edición y eliminación de registros

Inserción de pacientes, doctores, empresas, sectores

Datos personales: nombre, dirección, correo electrónico, teléfono, fecha de nacimiento; datos legales: NIT, NRC.

Registro insertado en la base de datos


Registros almacenados en la base de datos de forma consistente

Edición de pacientes, doctores, empresas y sectores (1)

Datos personales: nombre, dirección, correo electrónico, teléfono, fecha de nacimiento; datos legales: NIT, NRC.

Registro modificado en la base de datos

No superada

25/09/2014 Víctor Flamenco

El formulario no mostraba los datos del registro a editar

Edición de pacientes, doctores, empresas y sectores (2)

Los mismos parámetros que la prueba anterior.

Registro modificado en la base de datos

Superada 25/09/2014

Víctor Flamenco

Registros editados y almacenados con éxito

Eliminación de pacientes, doctores, empresas y sectores (1)

Identificador del registro en la base de datos

Registro eliminado en la base de datos

No superada

25/09/2014

Josué Serpas

Los registros que tenían llaves foráneas ligadas presentaron problemas

Eliminación de pacientes, doctores, empresas y sectores (2)

Identificador del registro en la base de datos

Registro eliminado en la base de datos

Superada 25/09/2014

Josué Serpas

Registros eliminados con éxito

Módulo de solicitudes de exámenes y

Inserción de nueva solicitud

Paciente, doctor, fecha de emisión, fecha de entrega, tipo de factura,

Solicitud insertada en la base de datos


Solicitud insertada exitosamente





procesamiento de resultados

porcentaje de retención y porcentaje de IVA

Edición de solicitud existente

Los mismos parámetros que la inserción de solicitudes

Solicitud modificada en la base de datos

Superada 28/09/2014 Josué Serpas

Solicitud modificada exitosamente

Eliminación de solicitud existente

Identificador de la solicitud en la base de datos

Solicitud eliminada de la base de datos


Solicitud removida de la base de datos con éxito

Módulo de reportes de ventas

Generación de nuevo reporte de venta de un día en específico

Fecha Documento en formato imprimible

Superada 15/10/2014 Víctor Flamenco

Reporte de ventas diarias generado satisfactoriamente

Generación de un nuevo reporte de ventas de un mes en un año específico (1)

Mes y año Documento en formato imprimible

No superada

15/10/2014 Víctor Flamenco

El motor de base de datos generaba el nombre del mes en idioma inglés, mientras que el sistema, lo generaba en español, lo que ocasionó problemas en las comparaciones.

Generación de un nuevo reporte de ventas de un mes en un año específico (2)

Mes y año Documento en formato imprimible


Reporte de ventas mensuales generado satisfactoriamente

Módulo de reportes de resultados de exámenes

Generación de un nuevo reporte de resultados de exámenes clínicos de un paciente específico

Paciente Documento en formato imprimible


Reporte de resultados de exámenes clínicos del paciente generado con éxito.

Módulo de catálogo de exámenes clínicos

Inserción de nuevo examen clínico

Categoría, familia, nombre del examen, descripción, precios y campos de los resultados.

Examen nuevo insertado en la base de datos


El examen se insertó correctamente

Modificación de examen clínico existente

Los mismos parámetros que la

Examen existente


El examen se modificó correctamente





inserción de nuevo examen

modificado en la base de datos

Eliminación de examen clínico existente

Identificador del examen en la base de datos


El examen se eliminó correctamente

Módulo de cotizaciones

Generar nueva cotización Paciente, doctor, fecha de emisión, fecha de entrega, tipo de factura, porcentaje de retención y porcentaje de IVA

Cotización nueva insertada en la base de datos


La cotización se insertó correctamente

Modificar cotización Los mismos parámetros que la generación de nuevas cotizaciones

Cotización existente modificada en la base de datos


La cotización se modificó correctamente

Eliminar cotización Identificador de la cotización en la base de datos

Cotización existente eliminada de la base de datos


La cotización se eliminó correctamente

Módulo de Control de Talonarios

Registrar entrega de talonarios (1)

Doctor, fecha y cantidad de talonarios

Registro exitoso de entrega

No superada

24/10/2014 Josué Serpas

Existía un defecto de programación que no permitía guardar la fecha de entrega del talonario

Registrar entrega de talonarios (2)

Doctor, fecha y cantidad de talonarios

Registro exitoso de entrega


Registro satisfactorio de la entrega de talonario.



9.3. CONFIABILIDAD, DISPONIBILIDAD Y FACILIDAD DE MANTENIMIENTO

SysLab fue desarrollado siguiendo buenas prácticas de programación y desarrollo

aplicando procesos de ingeniería de software, todo esto con el objetivo de garantizar

que el usuario final puede utilizar el sistema y que su información siempre se

mantendrá íntegra y disponible en todo momento.

Para comprobar la calidad del desarrollo realizado se calcularon métricas de código

las cuales son una evaluación que proporciona el IDE de desarrollo para determinar

distintos aspectos importantes del software, los cuales se detallan, junto con su

respectivo resultado, en la figura 24.

Figura 24. Métricas de código

Índice de mantenimiento: calcula un valor de índice entre 0 y 100 que

representa la facilidad relativa de mantenimiento del código. Un valor alto

significa mayor facilidad de mantenimiento. Las calificaciones codificadas por

colores se pueden utilizar para identificar rápidamente puntos problemáticos del

código. Una clasificación verde se encuentra entre 20 y 100 e indica que el

mantenimiento del código es bueno. Una clasificación amarilla se encuentra

entre 10 y 19 e indica que el mantenimiento del código es moderado. Una

clasificación roja se encuentra entre 0 y 9 e indica un mantenimiento pobre. El

proyecto posee una evaluación de 81 lo cual demuestra que el software tiene un

alto índice de facilidad de mantenimiento.

Acoplamiento de clases y profundidad de herencia: En general una baja

profundidad de herencia (8 obtenido) y acoplamiento de clases (470 calculadas)

con relación a la complejidad ciclomática (3,051 determinada) se traducen en

que el manejo de los objetos y por consiguiente de la información relacionada a

éstos, se realiza de manera correcta garantizando la integridad de los datos.



Por otra parte es importante recalcar que el software tiene una modalidad de

almacenamiento y obtención de datos de manera local, es decir no implementa una

tecnología cliente servidor, por tanto la disponibilidad de los datos no está

determinada por factores externos sino solo los del equipo en el cual se ejecuta, por

consiguiente la velocidad y el acceso a los datos depende de las características del

equipo, las cuales han sido especificadas previamente por los requerimientos

mínimos del sistema. Por tanto, el acceso a los datos es posible en todo momento

sin limitantes o bloques que tenga relación a internet o una red local ni de su

interacción con otros programas.

9.4. PRUEBAS DE ACEPTACIÓN

Una de las actividades más importantes realizadas fueron las pruebas de

aceptación, dado que el objetivo es proporcionar un software de calidad, dichas

pruebas determinaron la satisfacción del cliente con los módulos desarrollados y

con el sistema en general en relación a los requerimientos planteados en la etapa

de levantamiento de requerimientos.

9.4.1 MÓDULO DE PACIENTES, DOCTORES Y EMPRESAS

Se realizaron pruebas en conjunto con la empresa para verificar u obtener su

aprobación con respecto a la información que el software manejará en los módulos

de pacientes, doctores y empresas; de tal manera que la utilización e

implementación del software le trajera beneficios a la empresas, manejando la

información que realmente necesitan.

La figura 25 muestra los datos que maneja el sistema para las empresas y que

fueron aprobados por el cliente.



Figura 25. Información general de empresas

9.4.2 MÓDULO DE CATÁLOGO DE ANÁLISIS CLÍNICOS – ESTRUCTURA DE

DATOS E INFORMACIÓN CLASIFICADA

Uno de los módulos más importantes del sistema es el de catálogo de análisis

clínicos debido a que en éste se basan los procedimientos más importantes de la

empresa puesto a su naturaleza de negocio.

Se realizaron pruebas de la clasificación de los análisis basado en categorías lo cual

permite tener un correcta separación de los datos; en éste sentido el cliente verificó

que los análisis tuvieran la información que se requiere y que pueden ser agrupados

por familias y subfamilias.

Asimismo, se realizaron pruebas para que el cliente comprobara que la modalidad

de ingreso para los campos de resultado de los análisis clínicos cumplía con los

requerimientos planteados. Esto es debido a que existen 3 tipos de campos: Valor

referencia, Texto referencia y Referencia texto, cada uno con un diferente formato

de presentación, por tano se implementó un mecanismo para que el usuario pudiera



crear dichos campos con su tipo de presentación. En la figura 26 se muestra la

modalidad de ingreso de campos de resultados la cual fue a probada por el cliente.

Figura 26. Tipos de campo de resultados

9.4.3 PRUEBA DE MODALIDAD DE INGRESO DE SOLICITUDES

Se realizaron pruebas de la interfaz desarrollada para el ingreso de solicitudes de

análisis clínicos en conjunto con el cliente de tal manera que aprobó su satisfacción

con la modalidad propuesta.

La característica principal aceptada por el cliente que se implementaron buscadores

sencillos los cuales le permiten al usuario poder agregar una solicitud con una seria

de pasos sencillo y claramente visibles evitando confusiones por falta de

información de pacientes, doctores o más importante aún de los análisis clínicos.

La información presentada en la interfaz incluye precios de venta, código y nombre

completo del análisis, asimos se puede realizar búsquedas por nombre de manera

parcial y eficaz de tal manera que el cliente constató que se cumplen los

requerimientos planteados con respecto a la información que manejaría el sistema.

En la figura 27 se muestra la modalidad de ingreso de solicitudes con buscador

incrustado.



Figura 27. Modalidad de ingreso de solicitudes aceptada.

9.5. PRUEBAS DE INSTALACIÓN

Tomando como base el entorno para el cual fue desarrollado el software, se llevaron

a cabo pruebas de instalación en ambiente Windows partiendo de un sistema

operativo que no posee ninguno de los componentes de software y librerías

requeridos por el sistema. Es importante mencionar que las pruebas fueron

realizadas utilizando virtualización lo cual proporcionó flexibilidad para simular el

entorno de trabajo del sistema.

9.5.1 PRUEBA DE BASE DE DATOS

El instalador del sistema realizar las configuraciones necesaria para establecer los

parámetros de funcionamiento del sistema gestor de base de datos requeridos para

el correcto funcionamiento del sistema.



La prueba consistió en la instalación y ejecución correcta del script de la base de

datos sobre la instancia instalada. Para ello se utilizó la autenticación establecida

por el software para la conexión a la base de datos, tal como se muestra en la figura

28.

Figura 28. Prueba de base de datos

9.5.2 PRUEBA CRYSTAL REPORTS

Se realizaron pruebas que consistieron en la instalación del motor de reportes

utilizado por SysLab el cual es requerimiento fundamental para su funcionamiento.

El existo de dicha prueba estaba determinado por la capacidad del software para

generar los reportes que han sido incorporados.

Al finalizar las pruebas, se verifico que el sistema pudiera generar reportes y que al

hacerlo se comportara de la manera esperada con respecto a los tiempos de espera

y procesamiento esperados. Cabe mencionar que de igual manera, gran parte del

rendimiento de la generación de reportes está determinado por las capacidades del

equipo en el que se ejecuta SysLab.



9.5.3 REGISTRO DE LIBRERÍAS

Un componente cuya comprobación e instalación es bastante sencilla y no requiere

de mayor complejidad son las librerías de sistema utilizadas por el software. Sin

embargo, si falta una de estas el software no puede ejecutarse de ninguna manera,

por tanto se realizaron pruebas en un sistema operativo sin actualizaciones ni

componentes de librarías instalados y se precedió a registrar las librerías como se

muestra en la figura 29.

Figura 29. Librerías del sistema

El registro de las librerías en el entorno planteado fue realizado de manera

satisfactoria, independientemente de las librerías locales del sistema y de múltiples

versiones de las mismas, por tanto el software puede funcionar correctamente.

9.6. ENTREGA DEL SISTEMA

La entrega de SysLab a la clínica Medical Test se ejecutó siguiendo un conjunto de

procedimientos ordenados que permitan al grupo de proyectistas proveer de las

herramientas necesarias al laboratorio para la operación del sistema y todas sus

tareas. En primer lugar se diseñó un plan de capacitación, en este punto se detalló

como los empleados serán preparados para el operar el sistema y que tengan una

alta comprensión del mismo.



En el apartado 9.7.2. Documentación, se detallan los tres niveles de documentación

correspondiente a SysLab. La documentación pretende ser una referencia para los

usuarios de Medical Test en caso de dudas con respecto al funcionamiento de la

aplicación.

9.6.1. PLAN DE CAPACTACIÓN

Durante la etapa 1, específicamente en el apartado 6.2. Factibilidad operativa se

estableció un plan de capacitación genérico para formar a los empleados de Medical

Test. En ese momento, el sistema se encontraba en su etapa de análisis. Una vez

desarrollado el sistema, se pudo obtener una idea detallada de cuáles son las tareas

cuyo entendimiento requieren de una capacitación especial al personal, y

basándose en esta estructura, se diseñó un plan de capacitación más detallado.

9.6.1.1. OBJETIVO

Capacitar a los empleados del Laboratorio Clínico Medical Test para el conocimiento

y entendimiento de la herramienta SysLab y su forma de operación, de forma que

puedan ejecutar eficientemente todas las funcionalidades del programa.

9.6.1.2. ESTRATEGIAS

En cualquier tipo de formación, no existe mejor forma de aprender que la puesta en

práctica de los conocimientos adquiridos y las herramientas nuevas. Es por ello que

la capacitación para los usuarios de Medical Test se dividió en dos partes:

Demostración del entorno gráfico y funcionalidades del sistema, en

modalidad presencial.

Talleres para el manejo del sistema.

9.6.1.3. ESTRUCTURA

Tal como se mencionó en el apartado 6.2. Factibilidad operativa, las capacitación

del personal tuvo una duración de dos semanas, de lunes a viernes. Las reuniones



se llevaron a cabo una hora antes del inicio de la jornada laboral del laboratorio de

forma que no se detuviera la actividad laboral productiva en la empresa.

Debido a que el horario de las capacitaciones implicó que los empleados debían

presentarse al laboratorio una hora antes de lo habitual, se impartieron tres jornadas

de capacitación por semana, a manera de no comprometer sustancialmente el

horario de los empleados. En las tablas 13 y 14 se muestra un cronograma de las

dos semanas de capacitación.

Por otra parte, considerando también el tiempo del que disponía el grupo de

proyectistas, se acordó asistir las jornadas de capacitación en parejas, de forma que

no coincidiera con el horario académico de cada uno de ellos.

Tabla 13. Cronograma de capacitaciones (semana 1)

Tema Fecha Hora Facilitadores Participantes

Sesión introductoria: conociendo Syslab

27/10/2014 7:00 am Víctor Flamenco Josué Serpas

Todos los empleados

Sesión avanzada 1: Operaciones de administrador

29/10/2014 7:00 am Josué Serpas Kevin Gómez

Encargados de informática (administradores)

Sesión avanzada 2: Operaciones gerenciales

31/10/2014 7:00 am Kevin Gómez Víctor Flamenco

Gerencia

Tabla 14. Cronograma de capacitaciones (semana 2)

Tema Fecha Hora Facilitadores Participantes

Taller de uso de SysLab

03/11/2014 7:00 am Kevin Gómez

Víctor Flamenco

Todos los empleados

Documentación: manual de usuario y manual de sistema

05/11/2014 7:00 am Víctor Flamenco

Josué Serpas

Todos los empleados

Sesión dedicada a la resolución de dudas con respecto a SysLab

07/11/2014 7:00 am Josué Serpas

Víctor Flamenco

Todos los empleados



9.6.2. DOCUMENTACIÓN

La documentación necesaria para SysLab se compone de tres niveles.

El manual de usuario, que detalla cómo realizar cada una de las tareas posibles

en la aplicación. Se diseñó de tal forma que el usuario no pueda guiarse por sí

mismo en el entendimiento del uso de funciones de SysLab.

Posee toda la documentación necesaria para acceder al SysLab con cada uno de

los tres roles establecidos: operador, gerente, administrador y la explicación de cada

una de las actividades realizables.

El objetivo del manual es que el usuario conozca cómo preparar los datos de

entrada y cómo obtener los resultados y datos de salida; además, el manual funge

como referencia para dudas con respecto al uso del sistema.

a) Operador: se detallan los procesos de creación, edición, búsquedas y

eliminación de pacientes, doctores, empresas y sectores; el trámite de

solicitudes y el procesamiento de resultados.

b) Gerente: debido a que este rol posee privilegios en común con el rol de

operador, en esta sección solamente se detalla el proceso de generación de

nuevos reportes gerenciales, así como la impresión de los mismos.

c) Administrador: en esta sección se detallan los procesos de modificación de

parámetros del sistema, así como la administración de los usuarios y sus

roles.

El manual de sistema es una herramienta que se preparó con el objetivo de ayudar

a Medical Test a asegurar y facilitar futuras modificaciones al sistema, ya sea que

las ejecuten el mismo grupo de proyectistas u otros analistas y programadores que

el laboratorio contrate.

El manual de usuario y el manual de sistema se pueden consultar en cualquier

momento. Se encuentran almacenados en el disco de instalación del sistema. Para

poder acceder a ambos manuales, el único requisito es que la computadora en



donde se deseen consultar, tenga instalado un software lector de documentos en

formato PDF.

9.7.2.1. DOCUMENTACIÓN DEL CODIGO

El código de SysLab ha sido documentado de forma que otros programadores sean

capaces de entender la lógica utilizada para su elaboración. Debido a que el sistema

se programó siguiendo el modelo orientado a objetos, en cada una de sus clases

se ofrece documentación concisa y clara de su funcionalidad, sus atributos, métodos

y propiedades.

La figura 30 muestra un ejemplo concreto de la documentación del código un

método existente en una clase, explicando su funcionalidad y algunos rasgos; y la

figura 31 muestra un ejemplo de la documentación del código de un método de otra

clase y explica cómo se realizan ciertos cálculos matemáticos para la asignación de

variables.

La documentación del código no pretende explicar cada una de las líneas de código

desarrolladas, pues la persona que acceda a esta documentación debe poseer los

conocimientos técnicos y la experiencia necesarios para poder aplicar procesos de

reingeniería a SysLab.

Figura 30. Ejemplo 1 de la documentación de código



Figura 31. Ejemplo 2 de la documentación de código

9.7.3. PLAN DE MANTENIMIENTO

Es importante resaltar que una vez instalado el sistema en las computadoras de la

empresa Medical Test, éste no se debe descuidar. Por ello, se diseñó un plan que

define los diferentes tipos de mantenimiento que se aplicarán al sistema.

El sistema para la gestión administrativa SysLab, como cualquier otro software,

puede presentar algunos errores en el tiempo, que pueden ser provocados por

defectos en la codificación, fallos del equipo informático, mala manipulación del

sistema por parte de los usuarios, o cualquier otro fenómeno ajeno al entorno de

SysLab, como fallas en el sistema eléctrico que puedan dañar los datos del sistema.

El grupo de proyectistas, durante la entrega del sistema, ofreció al dueño del

software, es decir, la gerencia de Medical Test, una garantía para el sistema de una

duración de 4 meses. La garantía implica el aseguramiento del funcionamiento

óptimo de la herramienta entregada. Ante cualquier fallo de SysLab, Medical Test

tiene la potestad de comunicarse con el grupo de proyectistas para que ellos

solucionen cualquier inconveniente.



Como aporte adicional, durante los cuatro meses de garantía se realizarán cuatro

visitas a la empresa, una cada mes, para realizar mantenimiento preventivo sobre

el sistema administrativo. Este mantenimiento será el más usual en el Laboratorio.

Con éste, se pretende mejorar pequeñas características de SysLab sin alterar su

arquitectura. La tabla 15 muestra el cronograma de las cuatro visitas a Medical Test

para la ejecución de mantenimientos preventivos.

Tabla 15. Cronograma de ejecución de mantenimientos preventivos.

No. Visita Fecha Hora Colaboradores

1 08/12/2014 7:00 am Víctor Flamenco Kevin Gómez

2 12/01/2015 7:00 am Josué Serpas Víctor Flamenco

3 09/02/2015 7:00 am Kevin Gómez Josué Serpas

4 09/03/2015 7:00 am Víctor Flamenco Kevin Gómez

Durante estas visitas, se verificarán los siguientes componentes:

Datos de entrada en las interfaces.

Procesamiento de datos de entrada.

Muestra de datos de salida en las interfaces.

Consistencia e Integridad de los datos almacenados.

Disponibilidad de la información.

72

FUENTES DE INFORMACIÓN

PROJECT MANAGEMENT INSTITUTE, INC. Project Management Body of

Knowledge (PMBOK) – Guía de los fundamentos para la dirección de proyectos.

4ta. edición. Project Management Institute, Inc. 2008.

COMISIÓN DE REGLAMENTOS TÉCNICOS Y COMERCIALES – INDECOPI.

Normativa Técnica Peruana ISO/IEC 12207 – Procesos del ciclo de vida del

software. 2da. Edición. Perú, 2006.

INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS (IEEE)

COMPUTER SOCIETY. Guide to the Software Engineering Body of Knowledge

(SWEBOK). EEUU, 2004.

KENDALL KENETH, KENDALL JULIE. Análisis y Diseño de Sistemas. Prentice

Hall, México. 2011.

SOMMERVILLE, IAN. Ingeniería del Software. 7ma. edición. Pearson, España.

2005.

BERZAL, FERNANDO. El ciclo de vida de un sistema de información.

GLASS, ROBERT L. Facts and Fallacies of Software Engineering. Addison-

Wesley, 2003.

MCCONNELL, STEVE. Rapid Development: Taming wild software schedules.

Microsoft Press, 1996.

73

GLOSARIO DE TÉRMINOS

Análisis clínico: Se le llama comúnmente a la exploración complementaria

solicitada al laboratorio clínico por un médico para confirmar o descartar un

diagnóstico. Forma parte del proceso de atención a la salud que se apoya en

el estudio de distintas muestras biológicas mediante su análisis en laboratorio

y que brinda un resultado objetivo que puede ser tanto cuantitativo (un

número, como en el caso de la cifra de glucosa) o cualitativo (positivo o

negativo).

Desarrollo en cascada: Es el enfoque metodológico que ordena

rigurosamente las etapas del proceso para el desarrollo de software, de tal

forma que el inicio de cada etapa debe esperar a la finalización de la etapa

anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo

una revisión final, que se encarga de determinar si el proyecto está listo para

avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la

base de todos los demás modelos de ciclo de vida.

ISO: International Standarization Organization, es la entidad internacional

encargada de favorecer normas de fabricación, comercio y comunicación en

todo el mundo.

Stakeholders: Son todos los actores sociales que, producto de las

decisiones y objetivos de una empresa se pueden ver afectados, ya sea de

forma positiva o negativa.

MD5

El algoritmo MD5 es una función de cifrado tipo hash que acepta una cadena

de texto como entrada, y devuelve un número de 128 bits. Las ventajas de

este tipo de algoritmos son la imposibilidad (computacional) de reconstruir la

cadena original a partir del resultado, y también la imposibilidad de encontrar

dos cadenas de texto que generen el mismo resultado.

74

ANEXOS

Anexo 1. Roles del equipo de trabajo

Antes que nada, cabe mencionar que a pesar de que existan roles de trabajo, cada

una de las actividades es vista, asesorada y aprobada por todo el equipo por tanto

todos participan en todo, aunque uno de los integrantes tenga mayor participación

que los demás en una determinada área.

Víctor Manuel Flamenco Quijada

Programador/Base de datos, encargado de implementar los procedimientos

previamente diseñados por el equipo de trabajo, así como implementar

funciones avanzadas en las tablas de la base de datos.

Kevin Ernesto Gómez Hernández

Analista/Programador, encargado de dar un seguimiento al análisis y

posteriormente determinar observaciones a los requisitos planteados, así

como colaborar con las tareas de programación del software.

Josué Alejandro Serpas González

Analista/Base de datos, encargado de dialogar con la empresa para

determinar y recopilar los requerimientos de información, colabora con la

creación de la base de datos a nivel conceptual, lógico y físico.

75

Anexo 2. Control de versiones

Fuente de cambio

Fecha de Solicitud

de cambio

Versión Partes que cambian

Descripción del cambio Fecha de cambio

Ing. Milton Narváez

02/10/2014 2.0 Índice Corrección en la numeración de los apartados

03/10/2014


02/10/2014 2.0 Portada Título del proyecto 03/10/2014


02/10/2014 2.0 Objetivos Replantear los objetivos en función de los requerimientos del sistema

03/10/2014


02/10/2014 2.0 Factibilidad del proyecto

Separar en factibilidad técnica, económica, operativa y de fechas

05/10/2014


02/10/2014 2.0 Plantilla de control de versiones

Crear la matriz de control de versiones 05/10/2014


02/10/2014 3.0 Ventajas y desventajas de los procesos actuales

Se realizó un cuadro comparativo que permite visualizar claramente las ventajas y desventajas de los procesos actuales

06/11/2014


30/10/2014 3.0 Seguridad del sistema

Añadida información sobre la encriptación utilizada en el sistema

06/11/2014


30/10/2014 3.0 Mapa del sistema Se añadió un mapa jerárquico que describe la estructura del sistema

06/11/2014


30/10/2014 3.0 Seguridad del sistema

Se reestructuró especificando los niveles de seguridad implementados

06/11/2014


30/10/2014 3.0 Control de versiones

Formato cambiado por uno con más detalle 06/11/2014

76

Anexo 3. Ficha de solicitud de examen clínico

77

Anexo 4. Ficha de resultados de análisis clínico

78

Anexo 5. Autoevaluación individual

Estudiante: Víctor Manuel Flamenco Quijada

Criterios Calificación Observaciones

Asistencia a clases presenciales 10

Puntualidad 10

Responsabilidad 8

Respeto a ideas de los demás 9

Aportes brindados 9

Capacidad de trabajo en equipo 8

Iniciativa y creatividad 9

Promedio 9.00

Estudiante: Kevin Ernesto Gómez Hernández



Puntualidad 10

Responsabilidad 8


Aportes brindados 9



Promedio 9.14

Estudiante: Josué Alejandro Serpas González



Puntualidad 10

Responsabilidad 7


Aportes brindados 8



Promedio 8.57

Date post:	07-Sep-2018
Category:	Documents
Upload:	hadieu
View:	222 times
Download:	0 times

CÁTEDRA: INGENIERÍA DE SOFTWARE DOCENTE: … · aspectos que se especifican en la Norma ISO...

Documents