You are on page 1of 56

CAPITULO III: MODELADO DEL SISTEMA

III
INTRODUCCIN.

En el presente capitulo nombrado Modelado del Sistema, se dar ha conocer cul es
la metodologa y desarrollo de un sistema como primer punto, en este punto cabe
mencionar el ciclo de vida de los sistemas y las fases del modelo.

Se detalla los diferentes estudios de factibilidad que presenta el proyecto, como
tambin los requerimientos del sistema: las entradas y salidas, procesos, recursos y
control de procesos.

La estructura, la cual contiene diagramas de flujo de datos y los diagramas de
entidad relacin actuales y propuestos.

Se da ha conocer la propuesta funcional del sistema la cual conlleva ha demostrar
la propuesta de distribucin del software, la oficina central, diseo de pantallas
(descritas). El diseo estndar y las pantallas de reportes.

Los diccionarios de datos con sus respectivos diccionarios de tablas y datos.

Y por ltimo se detallan los niveles de seguridad del Sistema SSP v1.0.

77
3.1 MTODOLOGIA DE DESARROLLO DE UN SISTEMA.
En la actualidad para muchas organizaciones, los sistemas de informacin basados
en computadoras son el corazn de las actividades cotidianas y objeto de gran
consideracin en la tomas de decisiones, las empresas consideran con mucho
cuidado las capacidades de sus sistemas de informacin cuando deciden ingresar o
no en nuevos mercados.
Al establecer los sistemas de informacin basados en computadoras deben tener la
certeza de que se logren dos objetivos principales: Que sea un sistema correcto y
que este correcto el sistema. Ningn sistema que deje satisfacer ambos objetivos
ser completamente til para la gerencia u organizacin.

Si los dispositivos de un sistema de informacin no se adaptan a sus clientes, no
lograr sus objetivos potenciales. Al mismo tiempo, an cuando se identifiquen
precisamente las necesidades del usuario, un sistema de informacin va a tener un
valor nico si funciona en forma adecuada.

Los informes y las salidas producidas por el sistema deben ser precisos, confiables y
completos. La funcin del anlisis puede ser dar soporte a las actividades de un
negocio o desarrollar un producto que pueda venderse para generar beneficios.

El mtodo de ciclo de vida para el desarrollo de sistemas es el conjunto de
actividades que los analistas, diseadores y usuarios realizan para desarrollar e
implantar un sistema de informacin. Para tal fin se detallar el sistema de Desarrollo
Iterativo e incluyendo la ingeniera Web (iWeb) para tal uso.



78
3.1.1 MODELO DEL CICLO DE VIDA ITERATIVO
Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento
secuencial de un sistema a travs de mltiples ciclos de desarrollo de anlisis,
diseo, implementacin y pruebas.
El sistema crece al incorporar nuevas funciones en cada ciclo de desarrollo. Tras
una fase preliminar de planeacin y especificacin, el desarrollo pasa a la fase de
construccin a travs de una serie de ciclos de desarrollo.
En cada ciclo se aborda un conjunto relativamente pequeo de requerimientos,
pasando por el anlisis, el diseo, la construccin y las pruebas. El sistema va
creciendo con cada ciclo que concluye.
Esto constata con el ciclo de vida en cascada, en el cual las actividades (anlisis y
diseo, entre otras) se llevan a cabo una vez con todos los requerimientos del
sistema.
Entre las ventajas del desarrollo iterativo figuran las siguientes:
La complejidad nunca resulta abrumadora.
Se produce retroalimentacin en una etapa temprana, porque la
implementacin se efecta rpidamente con una parte pequea del sistema.

3.1.2 Fijacin de la duracin de un ciclo de desarrollo
Una estrategia muy til en los ciclos de desarrollo consiste en limitarlo a un marco
temporal, esto es, un lapso rgidamente fijo, digamos cuatro semanas. Todo el
trabajo a de concluirse en ese lapso.

3.1.3 Casos de uso y los ciclos iterativos de desarrollo
Un caso de uso es una descripcin narrativa de un proceso de dominio.
Los ciclos iterativos de desarrollo se organizan a partir de los requerimientos del caso
de uso.
Dicho de otra manera, se asigna un ciclo de desarrollo para implementar uno o ms
casos de uso o bien sus versiones simplificadas para el desarrollo del sistema.

79

3.1.4 Clasificacin de los casos de uso
Deberan clasificarse los casos de uso, y los que ocupen los niveles ms altos
habran de abordarse en los ciclos inciales de desarrollo. La estrategia general
consiste en seleccionar los casos que influyen profundamente en la arquitectura
bsica, dando soporte al dominio y a las capas de servicios de alto nivel o los que
presentan el mximo riesgo
4
.

3.2 INGENIERA WEB
A manera de introduccin en la ingeniera Web, pocos pueden discutir que Internet y
la World-Wide Web estn cambiando nuestras vidas. Cada da es comn que se
realice en diversas tareas dentro de esta misma. Se realizan conectados de
ordenador e Internet lgicamente. Es as que durante los ltimos aos se ha insistido
al crecimiento vertiginoso del desarrollo, uso de aplicaciones y sistemas Web cada
vez ms complejos y sofisticados.
3.2.1 Que es la ingeniera Web.
Como el proyecto a desarrollar se hace uso de tecnologa Web ASP.NET a
continuacin se detallan conceptos importantes a tener en cuenta.
Ingeniera Web es la creacin y utilizacin de sonido cientfico, la ingeniera y
gestin, principios, disciplina y enfoques sistemticos para el xito de desarrollo,
despliegue y mantenimiento de la alta calidad de sistemas y aplicaciones basadas en
la Web.
5


4
Craig Larman, UML y Patrones Una Introduccin al Analisis y Diseo Orientados a Objetos y al
Proceso Unificado, 2 Edicin, pagina 46.
5
Roger S. Pressman, Ingenieria de Software Un Enfoque Prtico, 5 Edicin, pagina 522.

80
3.2.2 Procesos de ingeniera Web
La inmediatez y la evolucin continan dictando un modelo de proceso incremental
e interactivo que elabora versiones de WebApps muy rpidamente. La naturaleza
intensiva de red de las aplicaciones en este dominio sugiere una poblacin de
usuarios diversa (exigiendo especialmente la obtencin y modelado de requisitos), y
una arquitectura de aplicacin que puede ser altamente especializada (Realizando
de esta manera exigencias en el diseo). Dado que las WebApps suelen ser
controladas por el contenido haciendo hincapi en la esttica, es probable que las
actividades de desarrollo paralelas se planifiquen dentro del proceso IWeb y
necesiten un equipo de personas tanto tcnicas como no (por ejemplo, redactores
publicitarios, diseadores grficos).

Las actividades que forman parte del proceso son:
Formulacin: Identifica objetivos y establece el alcance de la primera
entrega.
Planificacin: genera la estimacin del coste general del proyecto, la
evaluacin de riesgos y el calendario del desarrollo y fechas de entrega.
Anlisis: Especifica los requerimientos e identifica el contenido.
Modelizacin: Se compone de dos secuencias paralelas de tareas. Una
consiste en el diseo y produccin de contenido que forma parte de la
aplicacin. La otra, en el diseo de la arquitectura, navegacin e interfaz del
usuario.

Es importante destacar la importancia del diseo de la interfaz. Independientemente
del valor del contenido y servicios prestados, una buena interfaz mejora la
percepcin que el usuario tiene de estos.
Test: Busca errores a todos los niveles: contenido, funcional, navegacional
rendimiento etc. El hecho de que las aplicaciones residan en la red, y que
inter-operen en plataformas muy distintas, hace que el proceso de test sea

81
especialmente difcil. Finalmente, el resultado es sometido a la evaluacin del
cliente.
3.3 ESTUDIO DE FACTIBILIDAD.
En un proyecto de desarrollo de software es necesario evaluar la viabilidad previa del
mismo, este consta de tres estudios: factibilidad tcnica, econmica y operacional.
Los estudios antes mencionados, dan la pauta para continuar el proyecto hasta su
culminacin; ya que indican si los recursos que se necesitan son accesibles o
pueden adquirirse.
3.3.1 FACTIBILIDAD TCNICA.
En este estudio, se analiza lo que ser prctico o razonable de implantar, se toman
en cuenta los recursos de: hardware, software y humanos necesarios para que el
sistema funcione.
Una de las cuestiones principales, para que el sistema sea viable tcnicamente es
verificar o corroborar si se dispone en la actualidad de la tecnologa necesaria.
El Departamento de Atencin al Cliente cuenta con la infraestructura computacional
requerida para que el sistema sea instalado para su posterior uso. A continuacin se
detalla el inventario de hardware y software existente:

3.3.1.1 Servidor de aplicaciones:
Especificaciones
Procesador Pentium Xeon 2GHz
Memoria 2.4 GB
Disco duro de 80GB
Hardware
Tarjeta de red 1GB
Software
Windows 2000 Server.
MySQL
Apache
Informix
Cuadro 3.1. Especificaciones tcnicas del servidor.

82

3.3.1.2 Computadoras.
Especificaciones
Procesador Pentium IV 2.2 Ghz y 1.99 Ghz
Memorias de 376 y 512 MB
Disco duro 80 GB
Hardware
Tarjeta de red integradas 10/100 Mb/s
Sistema operativo Windows XP Profesional.
Microsoft Office 2003 Software
Internet Explorer 7 y Firefox 2.1
Cuadro 3.1. Especificaciones tcnicas de las computadoras.

La infraestructura de red, esta conformada por un conmutador LAN principal y cuatro
de acceso, adems la red esta segmentada de forma lgica por medio de VLANs.
La institucin cuenta en la actualidad con una variedad de aplicaciones en diversas
tecnologas (comerciales y abiertas) propias de cada departamento, as como de
varios gestores de bases de datos, adems de personal dedicado a la programacin
y mantenimiento de dichas aplicaciones.

3.3.1.3 Tecnologas en uso.
Especificaciones
Visual Studio 2005
IIS
Informix
Comercial.
SQL Server 2005

Apache
PHP Abierta.
My SQL.

Cuadro 2.3. Tecnologas en uso en la institucin.

83
A continuacin se detallan los requerimientos mnimos en hardware y software
necesarios para el desarrollo del sistema:

3.3.1.4 Servidor de aplicaciones.
Especificaciones
Procesador Pentium Xeon 2GHz
Memoria 2.4 GB
Disco duro de 80GB
Hardware
Tarjeta de red 1GB

Windows 2000 Server.
IIS 5.1 o superior Software
SQL Server 2005 Express Edition o superior

Cuadro 3.3. Especificaciones mnimas Servidor.


3.3.1.5 Requerimientos Tcnicos Mnimos de Computadoras.

Especificaciones
Procesador Pentium Dual Core 2GHz
Memoria 1 GB
Disco duro de 80GB
Hardware
Tarjeta de red 1GB

Windows XP Profesional.

Software

Cuadro 3.5. Requerimientos mnimos computadoras clientes.

84
3.3.2 FACTIBILIDAD ECONOMICA

La viabilidad econmica es una medida de la eficacia de los costes y beneficios
asociados al proyecto o a la solucin, los costes de un sistema pueden estar
inmersos en el desarrollo o en el funcionamiento del mismo.
En cuanto al costo de desarrollo se toman en cuenta el del personal, el uso
informtico, curso de formacin, costo de suministros o equipos y cualquier nuevo
equipo informtico o software.

Recursos Humanos
Descripcin del
Recurso
Cantidad
Duracin
(Das)
Horas
de
Trabajo
por da
Total de
Horas
Proyect
o
Costo
por
Hora
Costo
Total
Asesor 1 -- -- 40 $ 8.50 $ 340.00
Investigadores 3 90 2 180 $5.00 $2700.00
Programadores 3 90 4 360 $6.00 $6480.00
TOTAL $9520.00
Tabla3.1. Costo de Recursos Humanos.
Tabla 3.2. Costo de Recursos Tecnolgicos.
Recursos Tecnolgicos
Descripcin del
Recurso
Cantidad
Duracin
(Das)
Horas
de
Trabajo
por da
Total de
Horas
Proyecto
Costo
por
Hora
Costo
Total
Internet 1 176 4 704 $ 0.60 $ 422.40
Impresor 1 -- -- 20 $3.00 $60.00
Computadoras 2 176 4 704 $1.50 $1056.00
TOTAL $1538.40

85

Recursos Materiales
Descripcin del
Recurso
Cantidad Costo
Unitario
Costo
Total
Papel (resmas) 5 $3.00 $15.00
CDS Grabables 30 $0.25 $7.50
Tinta Impresor Negra 4 $10.00 $40.00
Tinta Impresor Color 4 $10.00 $40.00
Empastado 3 $12.50 $37.50
Anillado 3 $2.00 $6.00
Fotocopias -- $0.02 $10.00
Memoria USB 3 $20.00 $60.00
TOTAL $216
Tabla 3.3. Costo de Recursos Materiales.

Resumen
Descripcin del
Recurso
Costo del
Recurso
Recursos Humanos $ 9,520.00
Recursos
Tecnolgicos
$ 1,538.40
Recursos Materiales $ 216.00
Sub-Total $ 11,274.40
Imprevistos (10%) $ 1,127.44
COSTO TOTAL $ 12,401.84
Tabla 3.4. Resumen de Costo Totales.






86
Los costos totales que se mencionan en el cuadro resumen (tabla 3.4) representan
una medida del desembolso econmico que la institucin tendra que efectuar para
la realizacin del sistema informtico, pero que no se efectuara; ya que dicho
proyecto ser parte del trabajo de grado.
3.3.2.1 Beneficios Esperados.
La culminacin del proyecto propuesto, presenta una serie de beneficios, entre los
cuales se detallan los siguientes:

Aprovechamiento de los recursos econmicos, materiales, humanos y
tecnolgicos que posee la institucin.
El Departamento de Atencin al Cliente, ahorrara el cien por ciento de los
costos del proyecto, ya que el software se desarrollar en plataformas de uso
en la actualidad, evitando as, gastos de licencias o compra de equipos.
El anlisis y diseo del sistema est libre de gastos, por ser un trabajo de
graduacin elaborado por estudiantes de la Universidad Francisco Gavidia.
Automatizacin del proceso de firma de sobrevivencias para el Departamento
de Atencin al Cliente.
Elaboracin de informes electrnicos e impresos sobre el trmite de los
pensionados.
Mayor agilidad y accesibilidad en la obtencin de informacin y realizacin de
procesos, para los Ejecutivos y Supervisores de Atencin al Cliente.

3.3.3 FACTIBILIDAD OPERACIONAL
Este estudio mide la urgencia del problema y la aceptabilidad de la solucin
dependiendo del recurso humano disponible para el proyecto. Dicha factibilidad mide
dos aspectos a considerar:




87
1. La necesidad de resolver el problema y la funcionalidad de la solucin pensada
para el problema.

2. La opinin de los usuarios finales del sistema a desarrollar y de las jefaturas sobre
la solucin al problema del Departamento de Atencin al Cliente. En este caso los
empleados que sern los usuarios del sistema a desarrollar han expresado la
necesidad de un sistema informtico para la mejora en el proceso actual de toma de
informacin, por lo que se tiene una excelente aceptacin y oportunidad para que el
sistema llegue a ser utilizado. Igual opinin manifestaron las jefaturas en cuanto a los
reportes que pueden ser generados y el impacto en la reduccin del costo
operacional en el proceso.

3.4 REQUERIMIENTOS DEL SISTEMA
Para que el sistema llegue a ser usado por el Departamento de Atencin al Cliente
existe una serie de requerimientos que el mismo debe de cumplir:

1. Debe poder manejar varios tipos de usuarios, entre ellos Ejecutivos de
Atencin al Cliente, Supervisores y personal de la UPISSS, quienes tienen
que ser identificados y manejados segn sus privilegios.
2. El sistema debe ser capaz de manejar varios usuarios conectados
simultneamente y poder llevar registro de dichos accesos.
3. Se debe poder generar reportes en lnea, en formatos del tipo: Microsoft
Excel, PDF.
4. Debe contar con una interfaz amigable, para uso de los usuarios finales.Los
reportes se deben procesar con las generalidades de cada pensionado,
capturando datos ingresados por el usuario, tales como: nombre, nmero de
afiliacin, DUI, NIT y fotografa.
5. El programa debe comprobar si un pensionado ya ha realizado el trmite de
firma en la fecha correspondiente.

88
6. Debe llevar un control de las incidencias, en cuanto a problemas que se
generen y por cual no se pueda realizar el proceso de firma de sobrevivencias.

3.5 ENTRADAS Y SALIDAS.
Todo sistema del mundo real necesita de insumos o entradas para ser procesadas
con la finalidad de entregar un producto o salida y los sistemas informticos no son
la excepcin.
A continuacin se detallan las principales entradas y salidas para el sistema de toma
de firma de Sobrevivencias para los pensionados del ISSS (SSP v.1.0):

3.5.1 Entradas:
Nmero de afiliacin del pensionado: este consta de una serie numrica de nueve
dgitos, en el cual se puede verificar el ao de nacimiento de la persona y adems
su estatus de pensionado del ISSS y fecha de resolucin de pensin.
Numero de DUI: este cdigo representa otra forma de identificar a un pensionado de
forma univoca.
Numero de Empleado ISSS: es un nmero del tipo alfanumrico, conformado por la
inicial del primer apellido, seguido de cuatro dgitos, con este cdigo se identifica al
empleado que efecta el trmite de firma de Sobrevivencia.
Cdigo de Centro de Atencin Mdica (CAM): es un cdigo numrico que se
utiliza para verificar en qu Punto Seguro se ha efectuado el proceso de firma de
Sobrevivencia.





89
3.5.2 Salidas:
Datos del pensionado: nombre, NIT, nmero de expediente, fecha de resolucin de
pensin, fotografa, apoderado, mes prximo de realizacin de trmite, telfonos,
direccin, municipio, departamento.
Estadsticas de Pensionado por Centro de Atencin Medica: cantidad de
pensionados atendidos, cdigo de centro de atencin medica, ubicacin.
Estadsticas de trmites efectuado por Ejecutivos de Punto Seguro: cantidad de
procesos de recepcin de firma de sobrevivencias, atendidos por fecha, numero de
empleado ISSS, cdigo de Centro de Atencin Mdica (CAM).
Histrico semestral del proceso de recepcin: fecha de realizacin de proceso,
cdigo de empleado, cdigo de centro de atencin medica donde se realizo el
tramite, cdigo de pensionado, nombre y direccin, fecha de resolucin de pensin.

3.6 PROCESOS.
El proceso principal est conformado por el ingreso y verificacin del nmero de
afiliacin del pensionado, cotejando los datos de este en la tabla de catalogo; con
ello el ejecutivo de Punto Seguro reducir el tiempo del trmite de un promedio de 10
a 20 minutos a un mximo de 5 minutos de espera, debido a que el programa
mostrar automticamente toda la informacin referente al mismo. En caso de que el
pensionado haya realizado el trmite en algn otro Centro de Atencin Mdica que
cuente con Punto Seguro se proceder a generar o rechazar el proceso toma de
firma de sobrevivencia, dependiendo de la verificacin antes expuesta, esto ayudar
a que no exista duplicidad de la informacin.

Si el pensionado posee un apoderado legal para emitir la firma de sobrevivencia, ya
sea por motivo de viaje o enfermedad, se digitar en el sistema el nmero de
afiliacin de pensionado y se verificar si efectivamente existe un apoderado para
realizar el trmite; ya que se consultara la tabla que contiene informacin sobre los
apoderados que estn registrados por pensionado. Caso contrario se contactar al

90
pensionado telefnicamente por medio de Contacto Seguro para informarle y
solventar el inconveniente.

De ser generado el proceso, el ejecutivo debe ingresar el cdigo de empleado para
autenticar y responsabilizarse de cada trmite que realice, esto con la finalidad de
dar mayor credibilidad a la emisin de la firma y como comprobante de futuros
inconvenientes.


91
3.6.1 Diagramas de Procesos Actuales:

FIGURA 3.1. Diagrama de flujo de proceso actual colaborados - UPISSS

92
Inicio
Entrega
de reportes por
correo electrnico
Revision de
Informacin
Datos Correctos
Rechazar reporte
Comparar reporte
electrnico contra
fsico de cada CAM
por parte de
supervisor ATC
Aceptacin de reporte
electrnico y fsico por
parte de supervisor
ATC
Entrega de reporte
fsico de
sobrevivencias a
Colaborador ATC
fin
Firma de recibido por
parte de Colaborador
ATC
NO
SI
Pgina 1
PROCESO ACTUAL DE FIRMA DE SOBREVIVENCIAS EJECUTIVO ATC - SUPERVISOR ATC

FIGURA 3.2. Diagrama de flujo de proceso actual Ejecutivo ATC Supervisor ATC.

93

FIGURA 3.3. Diagrama de flujo de proceso actual Pensionado Ejecutivo ATC.

94

FIGURA 3.4. Diagrama de flujo de proceso actual Supervisor Colaborador. ATC.

95
3.6.2 Diagramas de Procesos Propuestos:

FIGURA 3.5. Diagrama de flujo de proceso propuesto firma de sobrevivencia ejecutivo supervisor
(ATC) con ejecutivo UPISSS.

96

FIGURA 3.6. Diagrama de flujo de proceso propuesto firma de sobrevivencia pensionado Ejecutivo
ATC.

97
3.6.3 CONTROL DE BITACORA
Se har uso de una tabla de bitcora, en cual se llevara informacin sobre los
accesos efectuados por los diferentes usuarios del sistema, se registrara la URL del
sistema que accedi, la fecha y hora.
Adems cada tabla del tipo maestro llevar dos campos del tipo fecha, uno para la
fecha de creacin de registro y otro para la fecha de modificacin.

3.7 ESTRUCTURA
A continuacin se presentan diversos diagramas: de flujo de datos, entidad relacin
que ayudan a identificar de mejor manera los requerimientos solicitados que debe
tener el aplicativo, as como ha determinar la lgica del negocio a implementarse en
la misma.

98
3.7.1 DIAGRAMA DEL MODELADO DEL SISTEMA

FIGURA 3.7. Diagrama de Modelado de Sistema.

99

3.7.2 DIAGRAMA DE FLUJO DE DATOS ACTUAL

FIGURA 3.8. Diagrama de flujo de Datos del Sistema Actual.

100

FIGURA 3.9. Diagrama de flujo de Datos Entidad Pensionado.


FIGURA 3.10. Diagrama de flujo de Datos de Ejecutivo de Atencin al Cliente.

101


FIGURA 3.11. Diagrama de flujo de Datos de Supervisor Atencin al Cliente

FIGURA 3.12. Diagrama de flujo de Datos de Colaborador Atencin al Cliente.

102

FIGURA 3.13. Diagrama de flujo de Datos de Ejecutivo UPISSS


103
3.7.3 DIAGRAMA DE FLUJO DE DATOS FUTURO

FIGURA 3.14. Diagrama de flujo de Datos nivel 0 del Sistema Propuesto

FIGURA 3.15. Diagrama de flujo de Datos de Pensionado.

104

FIGURA 3.16. Diagrama de flujo de Datos de Ejecutivo de Atencin al Cliente.

FIGURA 3.17. Diagrama de flujo de Datos de Supervisor de Atencin al Cliente.

105

FIGURA 3.18. Diagrama de flujo de Datos de Ejecutivo UPISSS.



106
3.7.4 DIAGRAMA ENTIDAD RELACIN FISICO




FIGURA 3.19. Diagrama Entidad-Relacin Fsico.


107
3.7.5 DIAGRAMA ENTIDAD RELACIN LOGICO

tbencuestas
idencuesta
tbanuncios
idanuncio
tbpreguntas_encuesta
idpregunta
tbmunicipios
idmunicipio
tbusuarios_sistema
idusuario
tbapoderados
idapoderado
tbreportes_generados
idreporte_generado
tbobservaciones
idobservacion
tbpensionados
idpensionado
tbrespuestas_encuesta
idrespuesta
tbbitacora_acceso
idbitacora_acceso
tbvisitas_pensionados
idvisitas_pensionado
tbtipo_pensiones
idtipo_pension
tbtipos_usuarios
idtipo_usuario
tbubicaciones
idubicacion
tbdepartamentos
iddepartamento

FIGURA 3.20. Diagrama Entidad-Relacin lgico.




108
3.8 PROPUESTA FUNCIONAL DEL SISTEMA
En esta seccin se trata de determinar los forma en que el sistema debe de
comportase de manera que satisfaga las expectativas de los usuarios.
3.8.1 PROPUESTA DE DISTRIBUCION DE HARDWARE
3.8.1.1 OFICINA CENTRAL
En cuanto a la oficina central, se ha considerado la distribucin que tendra el
servidor de aplicaciones y el de base de datos, dentro del segmento de red principal
y los diferentes centros de atencin medica que se encuentran en redes lgicamente
diferentes por cuestiones administrativas y de seguridad de la institucin como se
puede apreciar en el diagrama siguiente.


FIGURA 3.21. Propuesta de Distribucin de Hardware. Oficina Central.
3.8.2 CASOS DE USO
Una tcnica utilizada para estudiar los requerimientos y las responsabilidades del
sistema es la utilizacin de casos de uso, a continuacin se detallan las principales
actividades para el mismo:

109
TABLA 3.5. Caso de Uso Firma de Sobrevivencia.
IDENTIFICACIN DE CASO DE USO
ID:
UC1
Versin:
1.0
Nombre:
Toma de Firma de Sobrevivencia.
Actor Principal: Ejecutivo de Atencin al Cliente.
Precondiciones: El ejecutivo de identifica y autentifica en el sistema.
Escenario principal de xito: Se extiende la autentica al pensionado.
Accin del Actor (o intencin) Responsabilidad del Sistema
1. El ejecutivo ingresa cualquiera de
los siguientes documentos: DUI,
Numero de Tarjeta del ISSS, NIT.
3. El ejecutivo ingresa la siguiente
informacin para el apoderado
legal del pensionado: DUI, NIT o
Tarjeta del ISSS.
5. El ejecutivo certifica la identidad
del pensionado, mediante la
fotografa desplegada por el
sistema y procede a generar la
impresin de la autentica para
firma de ambos.
2. El sistema valida, la existencia del
pensionado en su base de datos y
despliega la informacin personal
del mismo, de lo contrario crea
nuevo registro para el pensionado.
4. El sistema valida, la existencia del
apoderado legal y despliega la
informacin del mismo, de lo
contrario pide datos para crear
nuevo registro de apoderado.
6. El sistema, registra la fecha actual,
la ubicacin y la identidad de
ejecutivo y pensionado y guarda la
fecha de la prxima cita del
pensionado.
Diagrama:


110
IDENTIFICACIN DE CASO DE USO
ID:
UC2
Versin:
1.0
Nombre:
Generacin de Encuesta de Servicio.
Actor Principal: Supervisor de Atencin al Cliente.
Precondiciones: El Supervisor se registra y autentica en el sistema.
Escenario principal de xito: Se genera encuesta de satisfaccin al cliente por
medio de muestreo para que los ejecutivos de atencin al cliente puedan pasar a
los pensionados cuando estos realizan el trmite de firma de sobrevivencia. Esto
con la finalidad de evaluar la aceptacin del servicio brindado.
Accin del Actor (o intencin) Responsabilidad del Sistema
1. El supervisor ingresa a la
opcin de generacin de
encuesta de satisfaccin
para elaborar dicho
instrumento.
3. Una vez generada la
encuesta, el Supervisor
avisa a los Ejecutivos de
Atencin al Cliente, que
tienen habilitada una
nueva encuesta para que
puedan usarla.
5. El ejecutivo procede a
tomar la encuesta y llenar
las opciones con las
respuestas
proporcionadas por el
pensionado.
7. El supervisor genera los
reportes de las encuestas
de satisfaccin de servicio.
2. El sistema genera un ID para la nueva
encuesta y solicita el numero de preguntas
que contendr la encuesta y la fecha para la
misma.
4. El sistema presenta, las encuestas
disponibles por fecha.
6. El sistema guarda las respuestas para cada
encuesta publicada y tabula la informacin de
las mismas.
Diagrama:


111
3.8.3 DISEO DE PANTALLAS
El aplicativo contar con un estndar en cuanto a las pantallas, este consta de tres
reas principales: una cabecera, barra de opciones, rea de trabajo y un pie de
pgina.
Para el rea de cabecera se presentarn los siguientes elementos: logo de la
institucin justificado a la izquierda, nombre del aplicativo, nombre del usuario
conectado, link para salir del aplicativo.
El rea de detalle est destinada al ingreso, salida de informacin, contar con
objetos del tipo pestaas para evitar el uso de varias ventanas y dar al usuario una
sensacin de ms naturalidad con los formularios de ingreso y de consultas del
aplicativo.

LOGO Nombre del Sistema


Usuarios conectado: XXXX Salir

Inicio Pensionados Reportes Administracin Ayuda
Detalle:











Versin del Sistema.
Fecha



FIGURA 3.22. Diseo de Pantallas.
Opciones
Cabecera
Pie
Detalle

112
3.8.4 DISEO ESTANDAR
En esta seccin se presentan los estndares utilizados para el desarrollo del
aplicativo en cuanto a la programacin, objetos de base de datos e interfaz grfica.

3.8.4.1 Nombres de tablas:
Nombre nemotcnico de dieciocho caracteres en minsculas utilizando
abreviaciones en las palabras que describen lo que contiene la tabla. Estas
palabras estarn separadas por un guin y precedido de las letras tb.
Ejemplo: tb_ubicaciones.

3.8.4.2 Nombre de vistas:
Nombre nemotcnico de diecinueve caracteres en letras minsculas.
El nombre siempre comenzara con la letra v seguida de un guin bajo.
La palabras Irn separadas por un guin bajo.
Ejemplo: v_reportes_pensionados

3.8.4.3 Nombres de campos:
Nombre nemotcnico de diez y nueve caracteres en letras minsculas.
Las palabras irn separadas por guin bajo.
Ejemplo: numero_expediente.

3.8.4.4 Nombre de procedimientos almacenados:
Este tipo de objetos se clasifican en dos grandes grupos, dependiendo de la funcin
que realizan: modificar datos o ingresar datos.
Nombre nemotcnico de diez y nueve caracteres en letras minsculas.
El nombre ira precedido por las letras sp y a continuacin el nombre de la
funcionalidad que realiza (modificar, ingresar) las palabras Irn separadas por
guin bajo.

113
Ejemplo:
sp_ingresa_usuarios
sp_modicar_pensionado

3.8.5 Estndar para la codificacin:
Se usara el estndar de codificacin Camel para codificacin de los programas, el
cual consiste en utilizar minsculas para la primera palabra del identificador y
maysculas para la siguiente.
Ejemplo: cmdAceptar, lblTutulo.
Cada programa ira comentado con la informacin de la fecha de modificacin,
objetivo, entrada y salida del mismo.

3.8.6 Estndar para los mensajes de usuario:
Todo sistema de informacin debe presentar mensajes al usuario, mensajes que le
permitan decidir sobre que accin realizar ante una situacin determinada: error en
alguna operacin, informacin adicional, advertencia y mensajes de preguntas. El
manejo de mensajes se realizar por medio de cuadros de dilogos, auxiliados por la
tecnologa AJAX, una lista de caractersticas a continuacin:

114

Tipo de mensaje Icono Descripcin
De advertencia.


Un mensaje de este
tipo indica aviso al
usuario con la accin
que acaba de realizar.
De avisos
personalizados por el
Administrador.




Son mensajes que se
muestran en el
aplicativo y su funcin
es de carcter
informativo.
De pregunta

Presenta una nota o
informacin
relacionada con la
accin que esta
realizando o acaba de
ejecutar.
Flotantes

Se activan cuando el
usuario pasa el
puntero sobre objeto y
tienen con finalidad,
describir la
funcionalidad del
mismo.
TABLA 3.7. Mensajes Estndares para los Usuarios.
En los mensajes de usuarios se presentarn las siguientes opciones de seleccin:
Aceptar.
Aceptar y Cancelar.
Si, No y Cancelar.
S y No

115
3.9 PANTALLAS DE REPORTE
El sistema tendr una variedad de reportes a generar, pero el principal es el de
autentica, el cual es generado para verificar la existencia del pensionado y proceder
al trmite de pensin para el mismo, el sistema debe presentar un modelo parecido
al siguiente esquema:

FIGURA 3.23. Pantalla de Reporte.
.

116
3.10 DICCIONARIO DE DATOS
En esta seccin se encuentra la informacin, correspondiente o los objetos que
conforman la base de datos del sistema SSP v 1.0, con sus respectivas definiciones.

3.10.1 DICCIONARIO DE TABLAS

Nombre de la Tabla: tbanuncios
Cdigo: Anuncios
Tipo: Maestro
Descripcin: Guarda los anuncios generados por el administrador del Sistema
y que son presentados por el Sistema, para ser visto por los
Usuarios.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo de Anuncios idanuncio

Int X X X
Asunto del Anuncio asunto Varchar X
Mensaje del Anuncio mensaje
Text
X
Fecha de
Publicacin del
Anuncio fecha_publicacion DateTime
X
Fecha de expiracin
del anuncio fecha_expiracion DateTime
X


117

Nombre de la Tabla: tbapoderados
Cdigo: Apoderados
Tipo: Maestro
Descripcin: Guarda informacin de los apoderados legales de los
pensionados, para realizar tramites en lugar del Pensionado.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo del
apoderado idapoderado Int
X X X
Cdigo del
pensionado idpensionado Int
X X X
Nombre del
apoderado nombre VarChar(50)
X
Apellidos del
apoderado apellidos VarChar(50)
X
DUI del apoderado
dui VarChar(50)
X
Nit del apoderdo
nit VarChar(50)
X
Telefono del
apoderado telefono VarChar(50)
X
Parentesco del
apoderado con el
pensionado parentesco VarChar(50)

Direccin del
apoderado direccion VarChar(150)
X
Muestra si el
apoderado esta
activo o inactivo estatus VarChar (50)
X
Fecha de emisin de
firma fecha_registro DateTime
X
Imagen escaneada
del poder legal documento_scan VarChar (50)



118


Nombre de la Tabla: tbbitcora_de_accesos_al_sistema
Cdigo: bitcora _ acceso
Tipo: Detalle
Descripcin: Guarda informacin sobre los accesos de los usuarios a las
diferentes opciones del aplicativo.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo del acceso
idbitacora_acceso Int
X X X
Identificacin del
usuario del sistema login VarChar
X
Indica la ltima fecha
de acceso al sistema fecha_acceso DateTime
X
Indica el estado del
usuario del sistema en_linea TinyInt
X
Registra la ltima
direccin efectuada
en el aplicativo ultimo_url VarChar
X
Direccin IP de la
computadora utilizada
que acceda al
sistema ip_host VarChar
X
Controla la cantidad
de ingresos al
sistema contador_visitas Int
X
Cdigo del usuario
idusuario Int
X X




Nombre de la Tabla: tbdepartamentos
Cdigo: Departamentos
Tipo: Maestro
Descripcin: Guarda informacin de los diferentes departamentos de El
Salvador, para ser utilizados las direcciones de los Puntos
Seguros, Pensionados.
Lista de Atributos

119
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Identificacin del
departamento iddepartamento Int
X X
Nombre del
departamento nombre_depto VarChar(50)
X


Nombre de la Tabla: tbencuesta_de_satisfaccin_de_servicios
Cdigo: Encuesta
Tipo: Maestro
Descripcin: Guarda informacin acerca de las diferentes encuestas de
satisfaccin del servicio realizadas a los pensionados.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo de
identificacin de la
encuesta Idencuesta Int
X X X
Verifica el nombre de
encuesta de
satisfaccin realizada nombre_encuesta VarChar
X
Indica fecha de
realizacin de
encuesta de
satisfaccin fecha_creacion DateTime
X
Verifica el estado de
la encuesta de
satisfaccin estatus Char
X

Nombre de la Tabla: tbmunicipios
Cdigo: Municipios
Tipo: Maestro
Descripcin: Guarda informacin de los municipios de los diferentes
departamentos, de ubicaron del pensionado.
Lista de Atributos

120
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo del municipio idmunicipio Int X X X
Cdigo del
departamento iddepartamento Int
X X X
Nombre del
municipio en
cuestin nombre_municipio VarChar(50)
X

Nombre de la Tabla: tbinformacin_de_los_pensionados
Cdigo: Pensionados
Tipo: Maestro
Descripcin: Guarda toda la informacin de los Pensionados.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo del
pensionado idpensionado Int

Cdigo tipo de
pensin del
pensionado idtipo_pension Int

Cdigo del municipio
del pensionado idmunicipio Int

Cdigo del
departamento del
pensionado iddepartamento Int

Nombre del
pensionado nombre
VarChar
(50)

Apellidos del
pensionado apellidos
VarChar
(50)

Fecha de nacimiento
del pensionado fecha_nacimiento DateTime

DUI del pensionado dui VarChar

121
(10)
NIT del pensionado
nit
VarChar
(16)

Numero de afiliacin
al ISSS, del
pensionado numero_afiliacion
VarChar
(15)

Numero de
expediente del
pensioado numero_expediente
VarChar
(15)

Fecha en que se
jubilo el pensionado fecha_jubiliacion DateTime

Telefono de residecia
del pensionado telefono_fijo
VarChar
(9)

Telefono celular del
pensionado telefono_movil
VarChar
(9)

Correo electronico
del pensionado email
VarChar
(50)

Direccion de
residencia del
pensionado direccion
VarChar
(150)

Fecha en que se
registro el
pensionado fecha_registro DateTime

Estatus del
pensionado si esta
activo o pasivo estatus Char (1)




Nombre de la Tabla: tbpreguntas_de_encuestas_realizadas
Cdigo: preguntas_encuestas
Tipo: Detalle
Descripcin: Guarda informacin acerca de las diferentes preguntas que se
formulan en la encuesta.

122
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo de
identificacin de
preguntas idpregunta Int
X X X
Cdigo de
identificacin de la
encuesta idencuesta Int
X X X
Indica el tipo de
pregunta formulada en
la encuesta pregunta
VarChar
(150)
X

Nombre de la Tabla: tbrespuestas_a_preguntas_de_encuestas_realizadas
Cdigo: respuestas_encuesta
Tipo: Detalle
Descripcin: Guarda informacin sobre las diferentes respuestas a las
preguntas de la encuesta realizada.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo de
identificacin de
respuestas idrespuesta Int
X X X
Cdigo de
identificacin de
preguntas idpregunta Int
X X X
Cdigo de
identificacin de
encuestas idencuesta Int
X X X
Identifica la respuesta a
la pregunta de la
encuesta respuesta VarChar
X
Contabiliza las
respuestas generadas
por pregunta de cada
encuesta contador Int
X





123
Nombre de la Tabla: tbtipos_de_usuarios_manejados_por_el_sistema
Cdigo: tipos_usuarios
Tipo: Maestro
Descripcin: Guarda informacin de los diferentes rolles manejados por el
sistema.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo del tipo de
usuario idtipo_usuario Int
X X X
Nombre del roll para
el tipo de usuario. nombre_tipo VarChar
X


Nombre de la Tabla: tbusuarios_del_sistema
Cdigo: usuarios_sistema
Tipo: Maestro
Descripcin: Guarda informacin de los diferentes tipos de usuarios
manejados por el sistema.
Lista de Atributos
Llave
Nombre

Nemotcnico

Tipo
PK FK

I

M
Cdigo del usuario
Idusuario Int
X X X
Cdigo del tipo de
roll del usuario idtipo_usuario Int
X X X
Nombre en el
sistema para el
usuario Login VarChar
X X X
Clave encriptado
para el usuario del
sistema Clave VarChar
X
Nombre del usuario
Nombre VarChar
X
Apellidos del usuario
apellidos VarChar
X
Documento nico de
identidad del usuario dui VarChar
X
Fecha de expiracin
del DUI fecha_exp_dui DateTime
X

124
Municipio de
expedicin de DUI. municipio_exp_dui VarChar
X
Numero de afiliacin
del ISSS numero_afiliacion VarChar
X
Cdigo de ubicacin
del usuario. idubicacion Int
X X
Fecha de creacin
de registro fecha_registro DateTime
X
Fecha de
modificacin de
registro fecha_modificacion DateTime
X
Estatus del usuario
estatus Char
X


125
3.10.2 DICCIONARIO DE DATOS
Tabla Columna Tipo Formato Requerido PK FK
idanuncio Int 9999999 Si PK
asunto VarChar (150) X(150) Si
mensaje Text X(231)
fecha_publicacion DateTime DD/MM/AAAA Si
tbanuncios
fecha_expiracion DateTime DD/MM/AAAA Si

Tabla Columna Tipo Formato Requerido PK FK
idapoderado Int 9999999 Si PK
idpensionado Int 9999999 Si FK
nombre VarChar (50) X(50) Si
apellidos VarChar (50) X(50) Si
dui VarChar (50) 99999999-9 Si
nit VarChar (50)
9999-999999-
999-9 Si
telefono VarChar (50) 9999-9999 No
parentesco VarChar (50) X(50) No
direccion VarChar (150) X(50) No
estatus VarChar (50) X(50) Si
fecha_registro DateTime DD/MM/AAAA Si
tbapoderados
documento_scan VarChar (50) X(50) No

Tabla Columna Tipo Formato Requerido PK FK
idbitacora_acceso Int 99999999 Si PK
login
VarChar
(15) X(15) Si
fecha_acceso DateTime DD/MM/AAAA Si
en_linea TinyInt 999 Si
ultimo_url
VarChar
(100) X(100) Si
ip_host
VarChar
(15)
999.999.999.9
99 Si
tbbitacora_acceso
contador_visitas Int 999999 Si


126
Tabla Columna Tipo Formato Requerido PK FK
iddepartamento Int 999 Si PK
tbdepartamentos
nombre_depto VarChar (50) X(50) Si

Tabla Columna Tipo Formato Requerido PK FK
idencuesta Int 99999 Si PK
nombre_encuesta VarChar (50) X(50) Si
fecha_creacion DateTime DD/MM/AAAA Si
tbencuestas
estatus Char (1) X(1) Si

Tabla Columna Tipo Formato Requerido PK FK
idmunicipio Int 999 Si PK
iddepartamento Int 999 Si FK tbmunicipios
nombre_municipi
o VarChar (50) X(50) Si

Tabla Columna Tipo Formato Requerido PK FK
idobservacion Int 999999 Si PK
idvisitas_pensionado Int 999999 Si FK
descripcion Text X(350) Si
fecha_registro DateTime DD/MM/AAAA Si
tbobservaciones
documento_scan VarChar (20) X(20) No

Tabla Columna Tipo Formato Requerido PK FK
idpensionado Int 999999 Si PK
idtipo_pension Int 99 Si FK
idmunicipio Int 999 Si FK
iddepartamento Int 999 Si FK
nombre VarChar (50) X(50) Si
apellidos VarChar (50) X(50) Si
fecha_nacimiento DateTime DD/MM/AAAA Si
dui VarChar (10)
9999-999999-
999-9 Si
tbpensionados

nit VarChar (16)
9999-999999-
999-9 Si

127
numero_afiliacion VarChar (15) 999999999 Si
numero_expediente VarChar (15) X(15) Si
fecha_jubiliacion DateTime DD/MM/AAAA Si
telefono_fijo VarChar (9) 9999-9999 Si
telefono_movil VarChar (9) 9999-9999 Si
email VarChar (50) X(50) Si
direccion VarChar (150) X(50) Si
fecha_registro DateTime DD/MM/AAAA Si
estatus Char (1) X(1) Si
fotografia VarChar (20) X(20) Si

Tabla Columna Tipo Formato Requerido PK FK
idpregunta Int 9999 Si PK
idencuesta Int 9999 Si FK tbpreguntas_encuesta
pregunta VarChar (150) X(150) Si

Tabla Columna Tipo Formato Requerido PK FK
idtipo_pension Int 99 Si PK
tbtipo_pensiones
nombre_tipo VarChar (50) X(50) Si

Tabla Columna Tipo Formato Requerido PK FK
tbtipos_usuarios idtipo_usuario Int 999999 Si PK
tbtipos_usuarios nombre_tipo VarChar (50) X(50) Si

Tabla Columna Tipo Formato Requerido PK FK
idreporte_generado Int 999999 Si PK
idusuario_genera Int 999999 Si FK
idusuario_cam Int 999999 Si FK
idubicacion Int 9999 Si FK
fecha_reporte DateTime DD/MM/AAAA Si
fecha_generacion DateTime DD/MM/AAAA Si
tbreportes_generados

comentarios VarChar (255) X(255) Si

Tabla Columna Tipo Formato Requerido PK FK
tbrespuestas_encuesta idrespuesta Int 9999 Si PK

128
idpregunta Int 9999 Si FK
idencuesta Int 9999 Si FK
respuesta VarChar (50) X(50) Si
contador Int 999999 Si

Tabla Columna Tipo Formato Requerido PK FK
idtipo_usuario Int 999999 Si PK tbtipos_usuarios
nombre_tipo VarChar (50) X(50) Si

Tabla Columna Tipo Formato Requerido PK FK
idubicacion Int 9999 Si PK
cam VarChar (50) X(50) Si
horario VarChar (20) X(20) No
direccion VarChar (150) X(150) Si
iddepartamento Int 999 Si FK
idmunicipio Int 999 Si FK
telefono VarChar (9) 9999-9999 No
tbubicaciones

fax VarChar (9) 9999-9999 No

Tabla Columna Tipo Formato Requerido PK FK
idusuario Int 999999 Si PK
idtipo_usuario Int 999999 Si FK
login VarChar (15) X(15) Si
clave VarChar (15) X(15) Si
nombre VarChar (50) X(50) Si
apellidos VarChar (50) X(50) Si
dui VarChar (10)
9999-999999-
999-9 Si
fecha_exp_dui DateTime DD/MM/AAAA Si
municipio_exp_dui VarChar (50) X(50) Si
numero_afiliacion VarChar (15) X(15) Si
idubicacion Int 9999 Si FK
fecha_registro DateTime DD/MM/AAAA Si
fecha_modificacion DateTime DD/MM/AAAA Si
tbusuarios_sistema
estatus Char (1) X(1) Si


129
Tabla Columna Tipo Formato Requerido PK FK
idvisitas_pensionado Int 999999 Si FK
idubicacion Int 999 Si FK
idusuario Int 999999 Si FK
idpensionado Int 999999 Si FK
fecha_atencion DateTime DD/MM/AAAA Si
codigo_atencion VarChar (4) X(4) Si
tbvisitas_pensionados
fecha_prox_atencion DateTime DD/MM/AAAA Si

Tabla Columna Tipo Formato Requerido
PK
FK
idhistorial Int 999999 Si PK
anho Int 9999 Si
idvisitas_pensionado Int 999999 Si FK
idubicacion Int 999 Si FK
idusuario Int 999999 Si FK
idpensionado Int 999999 Si FK
fecha_atencion DateTime DD/MM/AAAA Si
codigo_atencion
VarChar
(50) X(50) Si
tbvisitas_pensionados_historial
fecha_prox_atencion DateTime DD/MM/AAAA Si










130

3.11 NIVELES DE SEGURIDAD DEL SISTEMA
La seguridad en una aplicacin es un factor importante hoy en da y se presenta en
todos los niveles, desde la programacin hasta el hardware, para este trabajo se
aplicar a la programacin, mediante el uso de funciones hash para encriptar las
contraseas de los usuarios en los campos de la base de datos.
El proceso a seguir para la autentificacin y autorizacin de usuarios, es mediante el
esquema de formularios ASP.NET contra tablas de SQL Server 2005, donde las
tablas manejan las informacin de los diferentes roles aceptados por el sistema, ya
que la base de datos maneja un esquema mixto de autentificacin, (Windows o SQL
Server).

You might also like