universidad don bosco facultad de ingenierÍa … · antes de abordar el análisis de los...

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, 08 DE OCTUBRE DE 2014

ÍNDICE

1. Antecedentes del Proyecto .................................................................................... 2

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

3. Objetivos del proyecto ............................................................................................ 5

3.1. General ................................................................................................................ 5

3.2. Específicos .......................................................................................................... 5

4. Análisis de requerimientos ..................................................................................... 6

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

4.2. Obtención de requisitos .......................................................................... 8

4.3. Elaboración de requisitos ........................................................................ 9

4.4. Negociación de requisitos ...................................................................... 10

4.5. Perspectiva del producto - Interface de Usuario .................................... 10

4.6. Características de usuarios .................................................................... 14

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

6. Factibilidad del proyecto........................................................................................ 18

6.1. Factibilidad técnica ................................................................................. 18

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

6.3 Económica .............................................................................................. 20

6.4 Fechas ..................................................................................................... 20

7. Situación Actual ..................................................................................................... 22

7.1 Funcionamiento del sistema actual ..................................................................... 22

7.2 Descripción del entorno....................................................................................... 22

7.3 Procedimientos .................................................................................................... 23

7.4 Usuarios involucrados ......................................................................................... 24

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

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

8. Diseño del sistema ................................................................................................ 26

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

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

8.3. Modelado de objetos con UML (aplicación) ....................................................... 29

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

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

8.6. Desarrollo de Prototipo....................................................................................... 34

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

8.8. Base de datos (Descripción, Estructura y Entidad – Relación)......................... 37

8.9. Diccionario de datos ........................................................................................... 38

8.10. Seguridad del sistema (claves de acceso, roles de usuario, privilegios) ........ 40

7. Fuentes de información ......................................................................................... 41

8. Glosario de términos ............................................................................................. 42

9. Anexos ................................................................................................................... 43

9.1. Roles del Equipo de proyecto................................................................. 43

9.2. Control de versiones ............................................................................... 44

9.2 Documentos utilizados en la empresa ................................................... 45

INTRODUCCIÓN

En el presente documento, se aborda en detalle la fase inicial de análisis para el

desarrollo de un software de control para una empresa de laboratorio clínico Medical

Test, especificando cada uno de los apartados que se ven implicados en el

levantamiento de los requerimientos del software, tomando como base 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.

Antes de abordar el análisis de los requerimientos, se detallan los antecedentes del

proyecto, generando así un punto de partida con las experiencias que ha tenido la

empresa a lo largo de sus actividades. Posteriormente, se establece el planteamiento

del problema a resolver, dónde se abordan las diversas dificultades y deficiencias

que presenta la empresa, principalmente en su organización y definición de sus

procedimientos, consecuentemente se plantea de manera general la ventaja

competitiva que aportará el sistema.

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.

Además del planteamiento inicial de las funciones y requerimientos del sistema, se

aborda la factibilidad el mismo, principalmente en el aspecto operativo y de tiempo,

determinando la viabilidad del mismo.

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

2 CAPÍTULO 1. ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE.

CAPÍTULO 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 (PLANTEAMIENTO DEL PROBLEMA)

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

Desarrollar e implementar un sistema informático de gestión administrativa que

permita manejar una serie de controles y solicitudes procesados automáticamente,

y un conjunto de 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 propone 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 puede 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 (Técnicas de investigación)

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 está dando 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.

Actualmente se están realizando retroalimentaciones de los requerimientos con el

cliente. En ellas, se recopilan las dudas que puedan surgirle al cliente y se resuelven

en el momento, y además, se recopilan las observaciones que el cliente realiza al

prototipo y mientras sea posible, se incorporan mejoras que satisfagan al cliente.

Este mecanismo de cambios en requerimientos se plantea 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 está desarrollando en el software. Cabe mencionar

que esto se realiza 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, es analizada

para determinar el impacto de ésta en el ambiente operacional de la empresa, esto

se realiza con el objetivo de evitar que el cumplimiento de un requisito, genere

conflicto con otra tarea que realice la empresa. Esto se realiza siguiendo 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, se ha determinado que los requisitos

del software por parte de los involucrados son los 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.

Realizar 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.

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



4.6 Características de usuarios

Entre los requisitos del software, se establece un apartado de privilegios de usuario,

permitiendo así un nivel de seguridad en cuanto a la manipulación de la información

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

de cada empleado, por tanto, existirán 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. Podrá 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, está habilitado para generar reportes de

ingresos por ventas y llevar un control de caja general con la ayuda del

sistema.

Administrador: sumando las funciones del administrador, tiene la capacidad

de eliminar documentos de manera permanente, con un debido registro de

dicha operación. Por otra parte, 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 está utilizando en el desarrollo del proyecto es el

modelo en cascada, tal como se muestra en la figura 8, con el objetivo que en cada

fase los componentes logren desarrollarse lo más que se pueda, manteniendo así un

mejor orden en el desarrollo del proyecto en sí.

Figura 8. Fases del modelo en cascada

A continuación se detalla el ciclo de vida que se está implementando en el desarrollo

del sistema:

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

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 está ocupando 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 sea más rápido y que se tenga una visión

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

Al finalizar el desarrollo de cada módulo se realiza 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 completará 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 realiza 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 estimará 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 del proyecto

6.1 Factibilidad Técnica

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

requiere un equipo de programadores con conocimientos técnicos de nivel

intermedio avanzado en el lenguaje de programación Microsoft Visual C#, así como

un IDE, en específico Microsoft Visual Studio 2012.

Así también, se requiere la implementación de un sistema gestor de base datos para

desarrollar el sistema, en específico se requiere Microsoft SQL Server 2012. La

ejecución del software requiere de un ambiente de trabajo Windows con

compatibilidad desde Windows 7 y sucesores. El correcto funcionamiento del

sistema requiere que se implemente en un equipo con especificaciones técnicas de

gama media baja, es decir, un computador básico con 1 GB de RAM, procesador de

1.5 Ghz y espacio de almacenamiento de 10 GB mínimo. No se requiere conexión a

internet, ni la compra de licencias, sin embargo, algunas de las funciones del

programa como el envío de resultados por correo electrónico si requieren de

conexión a internet, la cual no necesariamente debe ser fija, es decir, puede ser

esporádica.



6.2 Factibilidad Operativa

En cuanto a la factibilidad operativa, se tiene en cuenta que las personas que trabajan

en la clínica serán capacitadas para que hagan un uso correcto de la aplicación, las

capacitaciones se harán divididas para que la clínica pueda funcionar con sus labores

y así no interrumpir las actividades de trabajo, en el diseño del sistema se ha tratado

de elaborarlo lo más agradable posible para que el usuario pueda hacer un uso

correcto y eficiente.

6.3 Factibilidad Económica

En la factibilidad económica, no se poseerán gastos previos para la elaboración del

sistema, eso quita la limitante de la inversión inicial para su diseño y desarrollo,

tomando en cuenta que las herramientas de desarrollo que se utilizaran serán las

versiones Express que posee Microsoft como: Microsoft SQL Server 2012 Express

como herramienta para el diseño de la base de datos y Microsoft Visual Studio

Express 2012 como IDE para la elaboración del software, una tabla que refleja los

gastos es la siguiente:

N° Descripción Cantidad Precio

Unitario

Precio Total

1 Microsoft SQL Server

Express 2012

1 $0.00 $0.00

2 Microsoft Visual Studio

Express 2012

1 $0.00 $0.00

6.4 Factibilidad de Fechas

(Ver página siguiente)



CRONOGRAMA DE TRABAJO

DESCRIPCIÓN DE LA ACTIVIDAD Responsable

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 Ernesto Gómez

Hernández

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 Manuel Flamenco

Quijada

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

solicitudes de los clientes, hasta la entrega de resultados.


Hernández

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 Manuel Flamenco

Quijada

Josué Alejandro Serpas

González



CRONOGRAMA DE TRABAJO

DESCRIPCIÓN DE LA ACTIVIDAD Responsable SEMANAS

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

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


Hernández

Víctor Manuel

Flamenco Quijada


González

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.


González

Víctor Manuel

Flamenco Quijada

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.


Hernández


González


22 CAPÍTULO 2. DISEÑO DEL SISTEMA

CAPÍTULO 2. DISEÑO DEL SISTEMA

7. Situación actual.

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.

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.

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, dato 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.

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

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.

El diagrama de la figura 9 muestra las operaciones generales que puede ejecutar

cada uno de los actores en el sistema. Luego, en la figura 10 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 9. Diagrama de clases del sistema



Figura 10. 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 cinco secciones que representan cada una de las

agrupaciones de tareas relacionadas dentro de los procesos administrativos del

software de gestión administrativa SysLab. Las cinco secciones se detallan en el

siguiente listado:

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 1. 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 1. Detalle de las pantallas principales 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


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


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



8.8 Base de datos

A continuación, en la figura 11 se presenta el esquema del diagrama de entidad relación que se ha estructurado y modelado para el funcionamiento del sistema.

Figura 11. Diagrama Entidad-Relación Conceptual



8.9 Diccionario de datos

BACILOSCOPIA NOMBRE DESCRIPCIÓN

FECHA_ING Fecha de ingreso del registro

FECHA_MOD Fecha de modificación del registro MUESTRA Tipo muestra

RESULTADO Resultado del análisis

DOCTOR NOMBRE

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

DIRECCION Ubicación

EMPRESA NOMBRE 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 DEPARTAMENTO Departamento donde está ubicada

SECTOR Sector de comercio TELEFONO Teléfono de contacto

EXTENSION

FAX ISSS

NIT EMAIL Correo electrónico donde serán enviados los

resultados

CONTACTO_NOMBRE Contacto directo entre el laboratorio y la empresa CONTACTO_TELEFONO



EXAMEN NOMBRE DESCRIPCIÓN

NOMBRE Nombre completo y único de examen clínico

DESCRIPCION Descripción general del examen

PACIENTE NOMBRE 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 NOMBRE DESCRIPCIÓN

NOMBRE Nombre del sector en la empresa DESCRIPCION Descripción del sector

SOLICITUD_ANALISIS NOMBRE 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

El sistema contará 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,

en éste sentido para validar los privilegios de los usuarios, además de clasificar los

usuarios.

También se realizará una clasificación de todas las funciones que posee el sistema,

de tal manera que en el funcionamiento interno del software, luego de 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.



FUENTES DE INFORMACIÓN

A. BIBLIOGRAFIA

PMBOK – Guía de los fundamentos para la dirección de proyectos – Cuarta

edición

Norma ISO 12207 – Procesos del ciclo de vida del software – Normativa

técnica peruana 2006

KENDALL KENETH, KENDALL JULIE. Análisis y Diseño de Sistemas. Prentice

Hall, México. 2011.



8. 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.



9. ANEXOS

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.



Control de versiones

Versión Item Aspecto

cambiado

Persona que

solicitó el cambio

2.0 Índice Corrección en la

numeración de los

apartados

Ing. Milton

Narváez

2.0 Portada Título del

proyecto

Ing. Milton

Narváez

2.0 Objetivos Replantear los

objetivos en

función de los

requerimientos

del sistema

Ing. Milton

Narváez

2.0 Factibilidad del

proyecto

Separar en

factibilidad

técnica,

económica,

operativa y de

fechas

Ing. Milton

Narváez

2.0 Plantilla de control

de versiones

Crear la matriz de

control de

versiones

Ing. Milton

Narváez



A continuación, se muestra los dos documentos más utilizados por la empresa, en

los cuales se basará el programa para los datos de entrada y salida.



AUTOEVALUACIÓN INDIVIDUAL

Estudiante: Víctor Manuel Flamenco Quijada

Criterios Calificación Observaciones

Asistencia a clases

presenciales 10

Puntualidad 9

Responsabilidad 10

Respeto a ideas de los

demás 10

Aportes brindados 9

Capacidad de trabajo en

equipo 9.5

Iniciativa y creatividad 9

9.5

Estudiante: Kevin Ernesto Gómez Hernández


Asistencia a clases

presenciales 10

Puntualidad 9

Responsabilidad 8.5


demás 10

Aportes brindados 9


equipo 9.5


9.14

Estudiante: Josué Alejandro Serpas González


Asistencia a clases

presenciales 10

Puntualidad 9

Responsabilidad 8


demás 10

Aportes brindados 9.5


equipo 9.5


9.29

universidad don bosco facultad de ingenierÍa … · antes de abordar el análisis de los...

Documents