71
CAPITULO IV. DISEÑO DE UNA APLICACIÓN WEB PARA LA ADMINISTRACIÒN DE SERVICIOS Y ACTIVIDADES DEL MINISTERIO
COM-VIDA DE LA IGLESIA BAUTISTA MIRAMONTE DE SAN SALVADOR.
1. GENERALIDADES.
En el contenido de este capítulo se presenta la propuesta para el diseño y
desarrollo de un sistema para la administración de los servicios y actividades
del ministerio COM-VIDA de La Iglesia Bautista Miramonte. Actualmente la
administración y control de la información del Ministerio es controlada de
forma manual, por lo que se considera que un buen diseño del sistema, les
permitirá aprovechar los avances tecnológicos mejorando así los procesos que
involucra la administración de sus servicios y actividades a la vez optimizando
sus recursos económicos, materiales y humanos que necesitan para poder
seguir desarrollándose y evolucionando de acuerdo a su demanda.
Con el diseño de un sistema se pretende que esta entidad posea la
información de cada uno de sus programas de servicio social de forma
ordenada, actualizada y disponible en todo momento para satisfacer de
manera oportuna la demanda de información por parte de los diferentes
usuarios ya sean estos pertenecientes al ministerio o sean usuarios externos.
72
2. OBJETIVOS. 2.1 Objetivo General Diseñar una Aplicación Web para la administración de los servicios y actividades
del ministerio COM-VIDA, que ayude a realizar de manera eficiente los procesos
de creación, consulta y actualización de la información de dicho ministerio.
2.2 Objetivos Específicos
a) Crear interfaces amigables que faciliten a los usuarios el manejo y utilidad
de la Aplicación Web.
b) Ofrecer a los programas de servicio del ministerio una herramienta que les
ayude a ejecutar los procesos de control y manejo de información de forma
ágil y oportuna.
c) Estructurar una base de datos que sea adecuada para almacenar de forma
eficiente la información que sea procesada por el ministerio COM-VIDA en
sus servicios y actividades.
d) Establecer una metodología capaz de asignar los permisos necesarios a
cada perfiles de usuarios que se defina, que garanticen la integridad y
seguridad de la información procesada en la Aplicación Web.
e) Proporcionar una herramienta que genere reportes que sean útiles para el
análisis y control de la información del ministerio.
73
3. JUSTIFICACIÓN DE LA PROPUESTA DE SOLUCIÓN.
Actualmente las instituciones sin fines de lucro que se dedican a brindar ayuda
social están en constante crecimiento y se ven en la necesidad de evolucionar en
el tipo administración para la información que requieren llevar a cabo en cada una
de sus actividades, por lo cual obtienen tecnología que les permita el control y
manejo de la información.
Al igual que otras instituciones, Ministerio COM-VIDA tiene la necesidad de
mejorar la administración de los procesos que realizan en sus servicios sociales y
actividades ya que actualmente se controlan de forma manual, con frecuencia se
generan inconvenientes al momento de solicitar información referente a los
programas de servicios, es por lo que se propone el “Diseño de un Aplicación Web
para la Administración de los Servicios y Actividades”, que se adecue a los
requerimientos señalados por los usuarios que utilizaran el sistema;
proporcionando así una herramienta tecnológica capaz de agilizar los procesos
ayudando a reducir los tiempos de respuestas, toma de decisiones y en la
maximización de los recursos disponibles materiales como humano.
4. MÉTODO CICLO DE VIDA PARA DESARROLLO DE SISTEMAS.
En este método de desarrollo de sistemas, conlleva un conjunto de actividades
que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un
sistema de información.
El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:
1. Investigación Preliminar: Es la solicitud por parte de las personas, para
recibir ayuda de un sistema de información. Esta fase tiene como objetivo la
consecución y recopilación de necesidades de las personas para quienes
74
se creara la aplicación donde se ven reflejados los requerimientos y
funcionalidades que ofrecerá al usuario el sistema a desarrollar.
2. Determinación de los requerimientos del sistema: El aspecto
fundamental del análisis de sistemas es comprender todas las facetas
importantes de la parte de la empresa, se deben de estudiar los procesos
de la empresa u organización
3. Diseño del sistema: Es donde se producen los detalles que establecen la
forma en la que el sistema cumplirá con los requerimientos identificados
durante la fase de análisis, llamada también esta etapa como diseño físico.
4. Desarrollo del software: Aquí se inicia la codificación de los algoritmos y
estructuras de datos, definidos en las etapas anteriores.
5. Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea
de manera experimental para asegurarse de que el software no tenga fallas,
es decir, que funciona de acuerdo con las especificaciones y en la forma en
que los usuarios esperan que lo haga. Se alimentan como entradas de
datos de prueba para su procesamiento y después se examinan los
resultados.
6. Implantación y evaluación: La implantación es el proceso de verificar e
instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y
construir todos los archivos de datos necesarios para utilizarla.
75
5. INVESTIGACIÓN PRELIMINAR.
5.1 Planteamiento del Problema. A medida que el Ministerio COM-VIDA ha incrementado su población de
atención, también ha aumentado la manipulación de información y de los
procesos. Como ejemplo se puede mencionar el proceso para el control de
información de los servidores, actualmente no existe un software que agilice
dicho proceso y otros. Por esta razón nació la inquietud de implementar un
software que les permita obtener y manejar la información de sus servicios y
actividades en una forma confiable y oportuna, ya que en este momento se
encuentra en una forma manual lo que conlleva a ocasionar retrasos y hasta
repetición en los procesos.
Se realizó la investigación y un análisis de la situación actual con el objetivo de
determinar la necesidad de diseñar una Aplicación Web para la administración
de los servicios y actividades que se desarrollan en el Ministerio COM-VIDA. A
través de reuniones con el personal involucrado en el Ministerio COM-VIDA se
solicito información respecto a los servicios y actividades que se llevan a cabo
y los procesos que se realizan.
Planteamiento del problema por diagrama de Causa y Efecto.
Dibujo 1 Diagrama de Causa y Efecto
EFECTO Realización de aplicación
web para un mejor control de la información
Materiales Seguridad
Personal Tiempo
CAUSAFalta de administracion en
servicios y actividades
Falta de recursos
Dificultad en recoleccion de
insumos
Falla en distribución oportuna
Fácil Manipulación de informacion
Perdida de Información
Control de Información
Atraso en la búsqueda de información
Recolección de recursos
Descoordinación de las actividadesProblemas de
comunicación
Inexistencia de bases de datos
Ambigüedad en la informacion
Falta de control en la ubicacion
76
5.2 Identificación de Alternativas de Solución.
Método de la caja negra.
Para demostrar el planteamiento del problema y las alternativas de solución se
utilizará el método de la Caja Negra demostrando las desventajas del Sistema
actual (Comportamiento A) versus las ventajas del Sistema propuesto
(Comportamiento B).
1. No se puede obtener oportunamente la información de los servicios y actividades a realizar o realizadas ya que no se lleva un control formal de la información.
1. Con la Aplicación Web se tendrá la capacidad de satisfacer oportunamente la solicitud de la información de los servicios y actividades a realizar o realizadas por el Ministerio.
2. No hay facilidad para la obtención y control de información de los registros de los servidores, beneficiarios y donantes ya que el control se realiza de forma física.
2. La Aplicación Web facilitara el control y manejo de expedientes de los servidores, beneficiario y donantes, facilitando la administración de la información de interés para los usuarios.
3. Atrasos en la creación de reportes debido a la dificultad en la obtención de información.
3. Generación de reportes en el tiempo requerido, ya que la información será accesible.
4. Perdida de información de procesos ya realizados, ya que su almacenamiento es físico.
4. La Aplicación Web, facilitara el almacenamiento de la información de los procesos ejecutados.
Tabla 1 Método de Caja Negra
PROCESO
Comportamiento A Comportamiento B
77
6. FACTIBILIDAD DE LA PROPUESTA DE SOLUCIÓN. 6.1 Factibilidad Operativa. Actualmente Ministerio COM-VIDA no cuenta con ninguna herramienta
informática que ayude en la administración de sus servicios y actividades; por
otra parte los usuarios involucrados en el proyecto, desde su inicio han
mostrado total aceptación y cooperación, ya que lo consideran una necesidad
y una oportunidad para mejorar el desarrollo de los programas del Ministerio.
Igualmente los usuarios poseen estudios superiores o educación media, y
poseen algún grado de conocimiento en el uso de equipos informáticos,
software e Internet. Por lo que la creación de la Aplicación Web es factible
operacionalmente.
La Aplicación Web como herramienta informática permitirá los siguientes
beneficios: a. Acceso a información de los servicios del Ministerio COM-VIDA y cada
uno de sus programas.
b. Acceso a información de las actividades a desarrollar por cada
programa de servicio del Ministerio.
c. Control sobre la información de los servidores, beneficiarios y donantes
en de los servicio del Ministerio.
d. Capacidad de realizar actualizaciones sobre la información de los
servicios y actividades del Ministerio.
e. Generación de Reportes de manera oportuna y confiable.
78
6.2 Factibilidad Técnica. 6.2.1 Requerimientos de Hardware.
Requerimientos Mínimos de Hardware.
Descripción Server Estación de trabajo
Procesador Intel Pentium IV Pentium III
Velocidad 2.4 GHz. 750 MHz.
Memoria Principal 1 GB. 256 MB
Disco Duro 120 GB 20 GB
Tarjeta de Red 100/1000 Mbps. 10/100 Mbps.
Monitor SVGA 15” SVGA 15”
Quemador CD/DVD 52x32x52x16 N/N
Escáner -------- El utilizado en COM-VIDA.
Impresor -------- El utilizado en COM-VIDA.
Tabla 2 Requerimiento de Hardware
6.2.2 Requerimientos de Software.
a) Selección de Base de Datos: SQL Server Express Edition 2005.
SQL Server Express cumple con dos usos especiales.
1. Un producto de server y más concretamente un server Web o un server de
base de datos.
79
2. un almacén de datos de cliente local en que el acceso a los datos de la
aplicación no depende de la red.
SQL Server Express utiliza el mismo motor de base de datos confiable y de
alto rendimiento que el resto de las versiones de SQL Server 2005. Asimismo,
utiliza las mismas API de acceso a datos que ADO.NET, SQL Native Client y
T-SQL. La diferencia con las ediciones de SQL Server 2005 radican en:
Falta de compatibilidad con características empresariales
Limite de un CPU
Límite de 1 GB de memoria para el grupo de búferes
Bases de datos con un tamaño máximo de 4 GB
Algunas características como “Cerrar Automáticamente” y “Copiar Bases de
Datos” como archivos están habilitadas de forma predeterminada en SQL
Server Express.
La escalabilidad se facilita, en caso de ser necesaria dado que las
aplicaciones Express funcionan perfectamente con las versiones Workgroup,
Standard y Enterprise de SQL Server 2005. La descarga en Internet permite
una implementación gratuita, rápida y fácil.
Los tres escenarios principales de uso de SQL Server Express son:
1. Desarrolladores no profesionales que crean aplicaciones Web.
2. Proveedores de software independientes que redistribuyen SQL Server
Express como un server de baja disponibilidad o un almacén de datos de
cliente.
3. Desarrolladores aficionados que crean aplicaciones cliente y server.
80
SQL Server Express ofrece una plataforma de base de datos fácil de utilizar y
confiable.
b) Lenguaje de Programación: ASP. NET.
Microsoft Visual Studio es un entorno de desarrollo integrado (IDE) para
sistemas Windows. Soporta varios lenguajes de programación como Visual
C++, Visual C#, Visual J#, Visual Basic .NET y ASP.NET.
A través de Visual Studio se pueden crear aplicaciones, sitios y aplicaciones
web, así como servicios web en cualquier entorno que soporte la plataforma
.NET
Visual Studio 2005 se empezó a comercializar a partir del 4 de Octubre de
2005 y en castellano salió hasta el 4 de Febrero de 2006, desde esa fecha la
actualización más importante que recibieron los lenguajes de programación
fue la inclusión de tipos genéricos, similares en muchos aspectos a las
plantillas de C#. Con esto se consigue encontrar muchos más errores en la
compilación en vez de en tiempo de ejecución, incitando a usar
comprobaciones estrictas en áreas donde antes no era posible.
Otro factor que se ha incluido en Visual Estudio 2005 es un diseñador de
implantación, que permite que el diseño de la aplicación sea validado antes de
su implantación. También se incluye un entorno para publicación web y
pruebas de carga para comprobar el rendimiento de los programas bajo varias
condiciones de carga.
ASP.NET es un Framework para aplicaciones web desarrollado y
comercializado por Microsoft. Es usado para construir sitios web dinámicos,
aplicaciones web y servicios web XML.
Apareció en enero de 2002 con la version 1.0 del .NET Framework, y es la
tecnología sucesora de la tecnología Active Server Pages (ASP). ASP.NET
81
está construido sobre el Commo Language Runtime, permitiendo a los
programadores escribir código ASP.NET usando cualquier lenguaje admitido
por el .NET Framework.
Microsoft introdujo la tecnología llamada Active Server Pages en diciembre de
1996, es parte del Internet Information Server (IIS) desde la versión 3.0 y es
una tecnología de páginas activas que permite el uso de diferentes scripts y
componentes en conjunto con el tradicional HTML para mostrar páginas
generadas dinámicamente. La definición contextual de Microsoft es que "Las
Active Server Pages son un ambiente de aplicación abierto y gratuito en el que
se puede combinar código HTML, scripts y componentes ActiveX del server
para crear soluciones dinámicas y poderosas para el web".
c) Componentes principales de asp.net.
1. Páginas. Las páginas de ASP.NET, o "web forms" (formularios web), son el principal
medio de construcción para el desarrollo de aplicaciones web. Los formularios
web están contenidos en archivos con una extensión ASPX; estos archivos
típicamente contienen etiquetas HTML o XHTML estático y también etiquetas
definiendo Controles Web que se procesan del lado del server y Controles de
Usuario donde los desarrolladores colocan todo el código estático y dinámico
requerido por la página web.
2. El modelo Code-behind. Para una programación dinámica se recomienda se use el modelo code-
behind, o de respaldo, que coloca el código en un archivo separado o en una
etiqueta de script especialmente diseñada.
82
Los nombres de los archivos code-behind están basados en el nombre del
archivo ASPX tales como MiPagina.aspx.cs o MiPagina.aspx.vb (esta práctica
se realiza automáticamente en Microsoft Visual Studio y otras interfaces de
desarrollo). Cuando se usa este estilo de programación, el desarrollador
escribe el código correspondiente a diferentes eventos, como la carga de la
página, o el clic en un control, en vez de un recorrido lineal a través del
documento.
El modelo code-behind de ASP.NET marca la separación del ASP clásico y
alienta a los desarrolladores a construir aplicaciones con la idea de
presentación y contenido separados en mente: esto permite a un diseñador
web, enfocarse en la creación del diseño con menos posibilidades de alterar el
código de programación mientras lo hace.
3. Controles de usuario. ASP.NET permite la creación de componentes reutilizables a través de la
creación de Controles de Usuario (User Controls). Un control de usuario sigue
la misma estructura que un formulario web, excepto que los controles derivan
de la clase System.Web.UI.UserControl, y son almacenados en archivos
ASCX. Como los archivos ASPX, un ASCX contiene etiquetas HTML o
XHTML, además de etiquetas para definir controles web y otros controles de
usuario. También pueden usar el modelo code-behind.
Los programadores pueden agregar sus propias propiedades y métodos, y
manejadores de eventos.
4. Administración del estado. Las aplicaciones ASP.NET son alojadas en un server web y se tiene acceso a
ellas mediante el protocolo sin estado HTTP, que no guarda ninguna
información sobre conexiones anteriores. Por lo tanto, si la aplicación requiere
interacción entre conexiones, tiene que implementar su propia administración
83
del estado. A continuación se detallan las formas en las que se puede llevar a
cabo la administración del estado en las aplicaciones ASP.NET.
a. Estado de la Aplicación: El estado de la aplicación (Application state) es
una colección de variables definidas por el usuario que son compartidas
por todas las invocaciones de una aplicación ASP.NET. Estos son
establecidas e inicializadas cuando el evento Application_OnStart se
dispara en la carga de la primera instancia de las aplicaciones y están
disponible hasta que la última instancia termina. Las variables de estado de
la aplicación son identificadas por nombres.
b. Estado de la sesión: El estado de la sesión (Session state) es una
colección de variables definidas por el usuario, las cuales persisten
durante la sesión de un usuario. Estas variables son únicas para
diferentes instancias de una sesión de usuario, y son accedidas usando la
colección Session. Las variables de sesión pueden ser preparadas para
ser automáticamente destruidas después de un determinado tiempo de
inactividad, incluso si la sesión no ha terminado. Del lado del cliente, una
sesión de usuario es identificada por una cookie o codificando el ID de la
sesión en la misma URL ASP.NET proporciona tres modos de persistencia
para variables de sesión:
InProc: Las variables de sesión son mantenidas dentro del proceso, sin
embargo, en este modo, las variables son destruidas cuando el proceso
ASP.NET es reciclado o terminado. Método utilizado en esta Aplicación.
StateServer: En este modo, ASP.NET ejecuta un servicio de Windows
separado que mantiene las variables de estado. Como esta
administración de estado ocurre fuera del proceso ASP.NET, tiene un
impacto negativo en el rendimiento, pero permite a múltiples instancias
84
de ASP.NET compartir el mismo estado del server, permitiendo que una
aplicación ASP.NET pueda tener su carga balanceada y escalada en
múltiples servidores. También, como el servicio de administración del
estado se ejecuta independiente de ASP.NET, las variables pueden
persistir a través de las finalizaciones del proceso ASP.NET.
SqlServer: En este modo, las variables de estado son almacenadas en
un server de base de datos, accesible usando SQL. Las variables de
sesión pueden persistir a través de finalizaciones de procesos también
en este modo.
5. Estado de la vista.
El estado de la vista (View State), es el mecanismo de administración de
estado a nivel de página, que es utilizado por las páginas HTML generadas
por las aplicaciones ASP.NET, para mantener el estado de los controles de los
formularios web y los widgets. El estado de los controles es codificado y
enviado al server en cada envió del formulario en un campo oculto conocido
como VIEWSTATE. El server envía de regreso las variables para que cuando
la página sea redibujada de nuevo, los controles volverán a su último estado.
Del lado del server, la aplicación puede cambiar el estado de la vista, si los
resultados del procesamiento actualizan el estado de cualquier control. El
estado de los controles individuales son decodificados en el server, y están
disponibles para su uso en ASP.NET usando la colección VIEWSTATE.
6. Motor de Plantillas. El concepto de página maestra (Master Page) permite el desarrollo de páginas
basado en plantillas web. Una aplicación web puede tener una o más paginas
maestras, las cuales pueden ser anidadas.
Las plantillas maestras contienen controles contenedores, llamados
ContentPlaceHolders para indicar donde ira el contenido dinámico, además de
85
HTML y JavaScript que será compartido a través de las paginas hijas. Las
paginas hijas también usan esos controles ContentPlaceHolder, que deben ser
relacionados con el ContentPlaceHolder de la pagina maestra. El resto de la
página está definido por las partes compartidas de la página maestra. Todo el
lenguaje de marcado y controles de server en la página de contenido deben
ser colocadas dentro del control ContentPlaceHolder.
Cuando una solicitud es hecha por una página de contenido, ASP.NET mezcla
la salida de la página de contenido con la salida de la página maestra, y envía
el resultado al usuario.
La página maestra permanece completamente accesible a la página del
contenido. Esto significa que en la página de contenidos se puede manipular
como realizar cambios en los encabezados, títulos, con dibujar la cache, etc.
Si la pagina maestra expone propiedades públicas o métodos, el contenido de
la página puede utilizar estos también.
7. Estructura de Directorios. En general, la estructura de directorios de ASP.NET puede ser determinada
por las preferencias del desarrollador. Existen algunos pocos nombres de
directorios reservados, sin embargo el sitio puede expandirse a cualquier
número de directorios.
Servidor de aplicaciones Web: Internet Information Server (IIS).
IIS, componente incluido en el sistema operativo de Windows desde la
versión XP Profesional, que funciona como server de aplicaciones Web.
86
6.3 Factibilidad Financiera. El diseño y desarrollo de la Aplicación no requiere de un desembolso de efectivo.
No existen costos de adquisición de licencias de software a corto plazo, ya que se
utilizara una base de datos de distribución gratuita al igual que el lenguaje de
programación que es facilitado por Microsoft a través de instituciones educativas
de forma gratuita en concepto de donación para el aprendizaje de los lenguajes
de programación. Para la implementación de la solución, según lo dialogado con
los representantes de COM-VIDA se llevara a cabo el arrendamiento de un
servidor, este deberá incluir los permisos de las licencias necesarias para la
ejecución de la aplicación.
En conclusión, se determina que la propuesta de solución es factible de forma
operativa, técnica y financiera; por lo que, la realización de la misma puede
ejecutarse contribuyendo a un ahorro en sus recursos y ayudando en la
administración de los servicios y actividades del Ministerio COM-VIDA.
7. DETERMINACIÓN DE REQUERIMIENTOS.
7.1 Requerimientos funcionales. Los requerimientos funcionales definen, el comportamiento interno del
software como cálculos, detalles técnicos, manipulación de datos y otras
funcionalidades específicas que muestran cómo los casos de uso serán
llevados a la práctica. Esta información se utiliza para ayudar a entender por
qué el requerimiento es necesario, y seguir al mismo durante el desarrollo del
producto.
El núcleo del requerimiento es la descripción del comportamiento requerido,
que debe ser clara y concisa. Este comportamiento puede provenir de reglas
87
organizacionales o del negocio, o ser descubiertas por interacción con
usuarios.
Para determinar los requerimientos funcionales de este proyecto se han
utilizado técnicas especializadas como los Casos de Uso y Diagrama de flujos
de datos, que permiten visualizar los procesos de una forma grafica y
estructurada.
Los símbolos básicos usados en los Diagrama de flujos de datos son los
siguientes:
SIMBOLO DESCRIPCIÓN
Inicio o finalización: Se utiliza para indicar el comienzo y finalización del proceso.
Flujo de Datos: movimiento en determinada dirección, desde un origen hacia un destino en forma de documentos.
Conector de Página: Indica que el flujo de datos continúa en la siguiente página del diagrama.
Proceso: Indica que se introduce información o se ejecuta algún proceso en el sistema.
Toma de Decisión: Se ejecuta una toma de decisión dentro del proceso.
Entrada de datos: Indican los valores que deberá recibir el proceso.
Desplegado de información: Se utiliza para mostrar un resultado, representando la solución al problema
Actividad.: Describe las funciones que desempeñan las personas involucradas en el proceso.
Tabla 3. Diagrama de Flujos
88
Los símbolos básicos utilizados para la diagramación de los Casos de Uso:
SÍMBOLO DESCRIPCIÓN
Usuario Final: representa los usuarios finales y el rol que tendrán en la aplicación web.
Delegación: señala la delegación que le será asignada según su rol de usuario.
Permisos otorgados: contiene el permiso otorgado para la manipulación de la Aplicación Web según su rol determinado.
Tabla 4. Diagrama de Casos de Uso
89
7.2 Diagrama Caso de Uso para la administración de los Servicios y actividades del Ministerio COM-VIDA.
Coordinador General.
Dibujo 2 Casos de usos. Coordinador General
90
Secretaria.
Dibujo 3. Casos de uso. Secretaria
Creación de expediente de donante
Modificación de expediente de donante
Eliminación de expedientes de donante
Consultar documentos digitalizados
Creación de expediente de servidor
Modificación de expediente de servidor
Eliminación de expedíente te de servidor
Secretaria
Creación de expedientes de beneficiario
Modificación de expediente beneficiario
Eliminación de expediente de beneficiario
91
Líder.
Dibujo 4 Líder
92
Servidor.
Dibujo 5. Servidor
93
7.2.1 Procesos Actuales en los Servicios y Actividades del Ministerio COM-VIDA. A continuación se describen los procesos actuales utilizados en la
administración de los servicios y actividades del Ministerio COM-VIDA.
Proceso 1. Creación de nuevo programa de Servicio
Proceso 1. Procesos Actuales en los Servicios y Actividades del Ministerio COMVIDA
94
Proceso 2. Planificación de Actividades por Programa
Proceso 2. Planificación de Actividades por Programa
Proceso 3. Creación de Expedientes de Servidores
Proceso 3. Creación de expedientes de servidores
95
Proceso 4. Creación de expediente de beneficiaros
Proceso 4. Creación de expedientes de beneficiarios
Proceso 5. Creación de expedientes de donantes.
Proceso 5. Creación de expedientes de donantes
C re a c ió n d e e x p e d ie n te d e
b e n e f ic ia r io
R e c e p c ió n d e s o lic itu d d e b e n e f ic ia r io
In g re s o d e d a to s e n h o ja d e
b e n e f ic ia r io
C re a c ió n d e e x p e d ie n te d e b e n e fic ia r io
F in
I n i c i o c r e a c i ó n d e e x p e d i e n t e d e d o n a n t e s
A c e p t a c i o n d e d o n a c i o n
R e c e p c i ó n d e d o c u m e n t a c i ó n
I n g r e s o d e d a t o s d e d o n a n t e s
C r e a c i ó n d e e x p e d i e n t e
F i n
96
7.2.2 Propuesta para Procesos Automatizados en los Servicios y Actividades del Ministerio COM-VIDA.
Proceso 1. Creación de nuevo programa de Servicio en el sistema propuesto.
Proceso Propuesto 1. Creación de Nuevo Programa de Servicio en El Sistema Propuesto
97
Proceso 2. Ingreso de Actividades por Programa en el sistema propuesto.
Proceso Propuesto 2. Ingreso de Actividades por Programa en el sistema propuesto
In ic io d e In g r e s o d e A c t iv id a d e s
In g r e s o d e d a to s d e a c t iv id a d e s
A s ig n a c ió n d e P r o g r a m a
In g r e s o d e a r c h iv o s a d ju n to s d e
A c t iv id a d
S o lic itu d d e r e p o r te d e a c t iv id a d e e s
R e p o r te d e a c t iv id a d e s
f in
C r e a c ió n d e E x p e d ie n te d e A c t iv id a d e s
S i N o
98
Proceso 3. Creación de Expedientes de Servidores en el sistema propuesto.
Proceso Propuesto 3. Creación de Expedientes de Servidores en el sistema propuesto.
C re a c io n d e E x p e d ie n te d e S e rv id o r
In g re s o d e d a to s d e s e rv id o r
F in
S o lic itu d d e re p o r te
E x p e d ie n te d e s e rv id o r
C re a c ió n d e E x p e d ie n te d e S e rv id o r
C a rg o d e S e rv id o r E x is te n te
A s ig n a c ió n d e c a rg o
C re a c ió n d e C a rg o
A s ig n a c ió n d e P e rm is o s a l C a rg o
S i N o
99
7.2.3 Procesos que deben incluirse en la Aplicación. 1. Alta, Baja y Cambio en nuevo programa de servicio.
2. Alta, Baja y Cambio de expedientes de servidores.
3. Alta, Baja y Cambio de expedientes de beneficiados.
4. Alta, Baja y Cambio de expedientes de donantes.
5. Ingreso de información de Actividades de programas.
6. Selección de niveles de permisos para los usuarios.
Reportes. La Aplicación debe ser capaz de generar los siguientes reportes:
1. Programas de Servicio.
2. Expediente de servidor.
3. Servidores por programas.
4. Expediente de beneficiario.
5. Beneficiarios por programas.
6. Información de Actividades.
7. Expediente de donante.
7.3 Requerimientos No Funcionales. Los requerimientos no funcionales definen la restricción a los servicios o
funciones ofrecidos por el sistema, a demás de describir restricciones que limitan
las elecciones para construir una solución.
Lo que hace no funcional el servicio ofrecido por el sistema, es el control sobre las
donaciones del Ministerio ya que este proceso conllevan un estudio adicional,
donde los usuarios utilizan criterios de evaluación según se considere necesario;
tales como:
Evaluar criterios para la aceptación de donaciones como: tipo de donación,
condiciones del donante, calidad de la donación.
100
Criterios para la distribución de los donativos entre los programas.
Por lo que el aplicativo administrara datos de identificación de los donantes al
Ministerio. (Carta de acuerdo de Requerimientos Establecidos, Anexo 5)
8 DIAGRAMA JERÁRQUICO (DIAGRAMA HIPO)
El diagrama HIPO son las siglas que significan (más) entrada / proceso /salida.
Estas siglas fundamentan una descripción y una ayuda de memoria sobre lo que
trata esta técnica.
Es jerárquica debido a el sistema de programación completo consiste de
subsistema más pequeños. Esta técnica, además de dar soporte a un enfoque de
diseño de arriba hacia abajo, también reduce la complejidad percibida del sistema,
debido a la facilidad de manejar los subcomponentes por separado1.
A continuación se muestra la gráfica del sistema principal sobre la captura de
datos.
1 Kendall & Kendall, Análisis y Diseño de sistemas, Tercera Edición
101
Diagrama Jerárquico de Sistema.
Dibujo 6. Diagrama HIPO
102
9 Diseño de Base de Datos. 9.1 Diagrama Entidad Relación.
Dibujo 7. Diagrama Entidad Relación
tbActividadescodA ct
nombreA ct
codPrg
fechaEjecucionA ct
lugarA ct
horaA ct
descripcionA ct
cantidadBeneficiariosA ct
cantidadServ idoresA ct
estadoA ct
fechaA gregadaA ct
observ acionesA ct
tbAsignacionesProgramascodA sigPrg
codPrg
codBen
tbCargoscodC ar
nombreC ar
descripcionC ar
tbDepartamentoscodDpt
nombreDpt
tbDonantescodDonante
codTipoDon
nombreDon
apellidosDon
direccionDon
telefonoDon
faxDon
emailDon
giroDon
observ acionesDon
estadoDon
nitDon
codDpt
tbProgramascodPrg
nombrePrg
fechaInicioPrg
fechaF inalPrg
descripcionPrg
estadoPrg
tbServidorescodSrv
nombreSrv
apellidosSrv
usuarioSrv
clav eSrv
fechaNacimientoSrv
direccionSrv
telefonoC asaSrv
telefonoO ficinaSrv
telefonoC elularSrv
profesionSrv
ocupacionSrv
lugarTrabajoSrv
email1Srv
email2Srv
estadoSrv
tbAsignacionesDonantescodA signacionDonantes
codPrg
codDon
tbTipoDonantescodTipoDon
nombreTipoDon
descripcionDon
tbAsignacionesPrgSrvcodA signacion
codPrg
codSrv
tbAdjuntosActividadescodA djuntoA ctiv idad
codA ctiv idad
urlA djunto
v isible
tbImgActividadescodImg
codA ct
urlImg
desImg
tipoImg
tbTipoBeneficiarioscodTipo
nombreTipo
tbBeneficiarioscodBen
nombreBen
direccionBen
fechaNacimientoBen
telefonoBen
nitBen
duiBen
numeroRegistroBen
codDpt
observ acion
estadoBen
codTipoBen
nombreC ontacto
direccionC ontacto
tbLogscodLog
codSrv
accion
fecha
tbAsignacionPermisoscodSrv
codC argo
tbPermisoscodC argo
consultaLocalidades
editaLocalidades
consultaC argos
editaC argos
consultaProgramas
editaProgramas
consultaServ idores
editaServ idores
consultaA ctiv idades
editaA ctiv idades
consultaDonantes
editaDonantes
consultaBeneficiarios
editaBeneficiarios
editaPortada
respaldos
editaNoticias
editaPermisos
asignaPermisos
103
9.2 Estructura de Tablas. Tabla: tbActividades
Llave primaria: codAct
Descripción: En esta tabla se almacenarán las actividades que realiza el ministerio
Campo Tipo de Datos
Descripción
codAct Int Código de la actividad
nombreAct varchar(25) Se escribirá un nombre que identifique la actividad.
codPrg numeric(18, 0) Código del programa al que pertenece la actividad que se está realizando.
fechaEjecucionAct datetime Fecha de ejecución de la actividad.
lugarAct varchar(40) El lugar donde se llevará a cabo la actividad.
horaAct datetime La hora a la que se realiza la actividad.
descripcionAct text Una breve descripción de lo que consiste la actividad.
cantidadBeneficiariosAct numeric(18, 0) La cantidad de beneficiarios con dicha actividad.
cantidadServidoresAct numeric(18, 0) Cantidad de servidores que estarán atendiendo la actividad.
estadoAct varchar(1) Marcará si la actividad está activa o no.
fechaAgregadaAct datetime La fecha en la que hemos agregado la actividad.
observacionesAct text Son observaciones adicionales de la actividad.
Tabla: tbDonantes
Llave primaria: codDonante
104
Descripción: Esta tabla llevará un registro de los donantes, tanto naturales como
jurídicos.
Campo Tipo de de Datos
Descripción
codDonante Intg Almacenará un código único para cada donante.
codTipoDon numeric(18, 0)
Almacenará el tipo de donante que es.
nombreDon varchar(40) Almacenará los nombres del donante.
apellidosDon varchar(40) Almacenará los apellidos del donante en caso de aplicar.
direccionDon text Contendrá la dirección del donante.
telefonoDon varchar(16) Almacena el número de teléfono del donante, pude incluir la extensión y código de área de ser necesario.
faxDon varchar(16) Almacenará el fax del donante en caso de haber.
emailDon varchar(50) Almacena el mail del donante en caso de existir.
giroDon varchar(30) Almacenará el giro del donante en caso de aplicar.
observacionesDon text Almacena alguna observación del donante.
estadoDon varchar(1) Almacenará si está activo o no el donante.
Tabla: tbCargos
Llave Principal: codCar
Descripción: Esta tabla contendrá los cargos que pueden tener los servidores.
Campo Tipo de Datos
Descripción
codCar Int Código único para los cargos
105
nombreCar varchar(25) Nombre del cargo
descripcionCar text Descripción de los cargos
Tabla: tbProgramas
Llave Principal: codPrg
Descripción: La tabla llevará el control de los programas que se desarrollan en el
ministerio COMVIDA.
Campo Tipo de Datos
Descripción
codPrg Int Código único del programa.
nombrePrg varchar(25) Nombre del programa a realizar o que se está realizando.
fechaInicioPrg Datetime (8)
Fecha de inicio de la ejecución del programa.
fechaFinalPrg Datetime (8)
La fecha en la que se estima que se finalice el proyecto.
descripcionPrg text Descripción del programa
estadoPrg varchar(1) Estado del programa si está activo o no.
Tabla: tbDepartamentos
Llave Principal: codDpt
Descripción: En esta tabla se almacenarán los departamentos en los que tiene
cobertura el ministerio.
Campo Tipo de Datos Descripción
codDpt Int Código único del departamento
nombreDpt varchar(25) Nombre del departamento
Tabla: tbServidores
106
Llave Principal: codSrv
Descripción: Esta es la tabla que nos almacenará todos los datos de los servidores,
así como también contiene los permisos que se le asignará a cada uno de los
usuarios, esto es porque los permisos no dependerán del cargo que ocupe el
servidor, sino que dependerán de los privilegios concedidos a su usuario por medio
del administrador.
Campo Tipo de Datos Descripción
codSrv Int Código único del servidor
nombreSrv varchar(40) Nombres del servidor
apellidosSrv varchar(40) Apellidos del servidor
usuarioSrv varchar(20) Usuario con el que se logrará loguear el servidor, puede ser muy diferente al nombre del servidor.
claveSrv varchar(100) Clave para lograr entrar al sistema. Esta clave se encontrará encriptada en la base de datos.
codCar numeric(18, 0) Código del cargo que desempeña el servidor.
fechaNacimientoSrv Datetime Fecha de nacimiento del servidor.
direccionSrv Text Dirección del servidor.
telefonoCasaSrv varchar(8) Teléfono de la casa del servidor
telefonoOficinaSrv varchar(20) Teléfono de la oficina del servidor si aplica. Se puede incluir la extensión dentro de este campo
telefonoCelularSrv varchar(8) Teléfono celular del servidor.
profesionSrv varchar(25) Profesión u oficio del servidor.
ocupacionSrv varchar(30) La ocupación del servidor
lugarTrabajoSrv varchar(30) Nombre del lugar de trabajo del servidor.
email1Srv varchar(50) Dirección de correo electrónico del servidor
107
email2Srv varchar(50) Dirección de correo del servidor.
estadoSrv varchar(1) Estado que nos indica si el servidor está activo o no.
permitirModificarActividad
varchar(1) Permitirá realizar cambios en la tabla de actividades.
permitirModificarDonantes
varchar(1) Permitirá realizar cambios en la tabla de donantes.
permitirModificarProgramas
varchar(1) Permitirá hacer cambios en la tabla de programas.
permitirModificarBeneficiarios
varchar(1) Permitirá hacer cambios en la tabla de beneficiarios.
controlTotal varchar(1) Permitirá tener el control total dentro del sistema. Este es el permiso que otorga todos los privilegios a un servidor.
Tabla: tbAsignacionesProgramas
Llave Principal: codAsigPrg
Descripción: En esta tabla se relacionará los programas con los beneficiarios, se
hace de esta forma porque un programa tiene muchos beneficiarios, pero también un
beneficiario puede tener muchos programas que lo beneficien.
Campo Tipo de Datos Descripción
codAsigPrg Int Código único de la asignación.
codPrg numeric(18, 0) Código del programa que estamos relacionando.
codBen numeric(18, 0) Código del beneficiario que estamos relacionando.
Tabla: tbAsignacionDonantes
Llave Principal: codAsiganciónDonantes
108
Descripción: Esta tabla también relaciona los programas con cada uno de los
donantes, ya que un programa puede darse gracias a muchos donantes y un
donante puede auspiciar a muchos programas.
Campo Tipo de datos
Descripción
codAsignacionDonantes Int Código único para la asignación.
codPrg numeric(18, 0)
Código del programa beneficiario.
codDon numeric(18, 0)
Código del donante para el programa
Tabla: tbTipoDonantes
Llave Principal: codTipoDon
Descripción: Esta tabla me almacena el tipo de donante que existe.
Campo Tipo de Datos
Descripción
codTipoDon Int Código único del tipo de donantes.
nombreTipoDon varchar(15) Nombre del tipo de donantes.
Tabla: tbTipoBeneficiarios
Llave Principal: codTipoBene
Descripción: Esta tabla almacena el tipo de beneficiario que existe.
Campo Tipo de Datos
Descripción
codTipoBene Int Código único del tipo de donantes.
nombreTipoBene varchar(15) Nombre del tipo de donantes.
Tabla: tbAsignacionesPrgSrv
Llave Principal: codAsignacion
109
Descripción: En esta tabla se relacionará los programas con los servidores, se hace
de esta forma porque un programa puede contener muchos servidores, pero también
un servidor debe pertenecer a un programa.
Campo Tipo de Datos Descripción
codAsignacion Int Código único de la asignación.
codPrg numeric(18, 0) Código del programa que estamos relacionando.
codSrv numeric(18, 0) Código del servidor que estamos relacionando.
Tabla: tbImagesActividades
Llave Principal: codImg
Descripción: En esta tabla se contendrá la información de los eventos relacionados
de las Imágenes con las tablas de la base de datos del sistema.
Campo Tipo de Datos Descripción
codImg Int Código único de la Imagen.
codRef numeric(18, 0) Código de la referencia del evento que estará relacionando.
UrlImg Varchar (100) Será la dirección URL la cual tendrá asignada la imagen.
Tabla: tbAdjuntosActividades
Llave Principal: codAdjuntoActividades
Descripción: En esta tabla se contendrá la información de los eventos relacionados
de los archivos adjuntos que estén relacionados a la tabla tbAtividades. Puesto que
cada Archivo adjunto debe pertenecer a una actividad y cada actividad puede
contener uno o más Archivos Adjuntos.
Campo Tipo de Datos
Descripción
110
codAdjuntoActividad Int Código único del Archivo Adjunto.
codActividad numeric(18, 0)
Código de la actividad que estará relacionando.
UrlAdjunto varchar(100) Será la dirección URL la cual tendrá asignada el Archivo Adjunto.
visible varchar(1) Estado que me indica si el archivo Adjunto está visible o no.
Tabla: tbConf
Llave Principal: codConf
Descripción: En esta tabla se contendrá la información de lo que se mostrara en la
parte pública de la aplicación como información general del Ministerio COMVIDA.
Campo Tipo de Datos Descripción
codConf Int Código único.
Mision varchar(40) Para mostrar texto de misión de COM-VIDA
Vision varchar(40) Para mostrar texto de visión de COM-VIDA
TextoPortada varchar(40) Mostrará texto en la página principal.
ImgPortada varchar(40) Mostrará imagen en la página principal.
historia varchar(40) Para mostrar texto de la historia de COM-VIDA
contactos varchar(40) Para ingresar información de los contactos en COM-VIDA
TbLogs
Llave Principal: codLog
111
Descripción: En esta tabla se contendrá la información del historial de los
movimientos que realicen los usuarios registrados dentro del sistema.
Campo Tipo de Datos Descripción
codLog Int (4) Código único.
codSrv Int (4) Código de servidor
acción Integre (16,0) Descripción de la acción realizada por el usuario.
fecha Datatime (8´) Fecha en que se realizó la acción.
TbNoticias
Llave Principal: codNoticias
Descripción: En esta tabla se contendrá la información de lo que se mostrara en la parte
pública de la aplicación como información de “Noticias” del Ministerio COMVIDA.
Campo Tipo de Datos
Descripción
codNoticia Int Código único.
encabezadoNoticia
varchar(40) Para ingresar el tema de la noticia.
contenidoNoticia txt Mostrará el contenido de la noticia.
fechaNoticia Varchar (12) Fecha en que se ingresa la noticia.
estadoNoticias Varchar (1) Estado de la noticia.
TbPermisos
Llave Principal: codPermisos
Descripción: En esta tabla se contendrá los permisos otorgados a los cargos creados
por el administrador
Campo Tipo de Datos
Descripción
112
codcargo Int Código único.
consultaLocalidad
varchar(1) Permiso para consultar localidad
editaLocalidades varchar(1) Permiso para editar localidades
consultaCargos varchar(1) Permiso para consulta cargos
editaCargos varchar(1) Permiso para editar cargos
consultaPrograma
varchar(1) Permiso para consulta programa
editaPrograma varchar(1) Permiso para editar programa
consultaServidores
varchar(1) Permiso para consultar servidores
editaServidores varchar(1) Permiso para editar servidores
consultaActividades
varchar(1) Permiso para consultar actividades
editaActividades varchar(1) Permiso para editar actividades
consultaDonantes
varchar(1) Permiso para consultar donantes
editaDonantes varchar(1) Permiso para editar donantes
consultaBeneficiarios
varchar(1) Permiso para consulta beneficiarios
editaBeneficiarios varchar(1) Permiso para editar beneficiarios
editaPortada varchar(1) Permiso para editar portada
respaldos varchar(1) Permiso para respaldos
editaPermisos varchar(1) Permiso para editar permisos
asignaPermisos varchar(1) Permiso para asignar permisos
113
9.3 Diseño de Pantallas. En el diseño y creación de las pantallas para la aplicación se utilizaran dos
conceptos de diseño que permitirá realizar interfaces de forma estándar y amigable
a los usuarios, estas dos definiciones son: Diseño de Master Pages en ASP. NET y
Hojas de estilo en cascada (CSS); que a continuación se describen.
Diseño de Master Pages en ASP. NET. Las Master Pages o Páginas Maestras nos permiten el diseño de una página
web. Una Master Page es una página que contiene marcas y controles que
deben ser compartidas a través de páginas múltiples de un sitio. Por ejemplo, si
todas las páginas deben tener los mismos banners de cabecera y pie de página
o el mismo menú de navegación, podemos definir esto en una Master Page una
vez, de forma que todas las páginas asociadas a dicha Master Page heredarán
estos elementos comunes. La ventaja de definir la cabecera, el pie de página y la
navegación en una Master Page es que estos elementos sólo tendrán que ser
definidos una vez, en lugar de muchas veces y en código duplicado en las
diferentes páginas del sitio2.
Las hojas de estilo en cascada (Cascading Style Sheets, CSS) Lenguaje formal usado para definir la presentación de un documento
estructurado escrito en HTML o XML. La idea que se encuentra detrás del
desarrollo de CSS es separar la estructura o estilo de un documento en su
presentación. La información de estilo puede ser adjuntada tanto como un
documento separado o en el mismo documento HTML.
CSS proporciona tres caminos diferentes para aplicar las reglas de estilo a una
página Web:
2 http://www.es-asp.net/tutoriales-asp-net/tutorial-61-84/creacion-de-un-diseno-mediante-master-pages.aspx
114
1. Una hoja de estilo externa, que es una hoja de estilo que está
almacenada en un archivo diferente al archivo donde se almacena el código
HTML de la página Web. Esta es la manera de programar más potente,
porque separa completamente las reglas de formateo para la página HTML
de la estructura básica de la página.
2. Una hoja de estilo interna, que es una hoja de estilo que está incrustada
dentro de un documento HTML. De esta manera se obtiene el beneficio de
separar la información del estilo, del código HTML propiamente dicho. Se
puede optar por copiar la hoja de estilo incrustada de una página a otra.
3. Un estilo en línea, que es un método para insertar el lenguaje de estilo de
página, directamente, dentro de una etiqueta HTML. Esta manera de
proceder no es excesivamente adecuada. El incrustar la descripción del
formateo dentro del documento de la página Web, a nivel de código se
convierte en una tarea larga, tediosa y poco elegante de resolver el
problema de la programación de la página. Este modo de trabajo se podría
usar de manera ocasional si se pretende aplicar un formateo con prisa, al
vuelo. No es todo lo claro, o estructurado, que debería ser, pero funciona.
Las ventajas de utilizar CSS son:
Control centralizado de la presentación de un sitio web completo con lo que
se agiliza de forma considerable la actualización del mismo.
Los Navegadores permiten a los usuarios especificar su propia hoja de estilo
local que será aplicada a un sitio web, con lo que aumenta considerablemente
la accesibilidad.
Una página puede disponer de diferentes hojas de estilo según el dispositivo
que la muestre o incluso a elección del usuario.
115
El documento HTML en sí mismo es más claro de entender y se consigue
reducir considerablemente su tamaño (siempre y cuando no se utilice estilo
en línea).
10 Diseño de las Pantallas de la Aplicación.
Pantalla de entrada principal. Esta será la pantalla principal desde la cual se tendrá acceso a las opciones de la
aplicación que serán ejecutadas en el área de trabajo.
Esta formada por:
Un banner color azul cielo con el logo del Ministerio COM-VIDA a lado
izquierdo y.
Una Mapa del Sitio a lado izquierdo, que indicara la ubicación del usuario
dentro del sistema. Y a lado derecho se mostrara el nombre del usuario
registrado.
A lado izquierdo de la pantalla se encuentra el Menú del sitio público donde
cualquier usuario podrá observar la información general del ministerio. Bajo
este, se encuentra el un contenedor dinámico de las actividades del ministerio
visible al publico general. Y en la parte inferior se encontrara el Menú de
Mantenimiento de la Aplicación que solo será visible para los usuario
registrados.
En la parte centro-derecha se utilizara como área de trabajo en la cual serán
desplegadas las pantallas operativas del sistema.
En la parte inferior de la pantalla se mostrara la información general de la
Iglesia Bautista Miramonte.
Fondo de la pantalla color celeste.
116
Dibujo 8. Pantalla Entrada Principal
Pantalla inicio de sesión de usuario registrado. Esta pantalla permitirá el ingreso a los usuario registrados, al menú mantenimiento de la
Aplicación Web para que puedan administrar la información correspondiente al
ministerio COM-VIDA.
L o g o C O M - V ID A B A N N E R
M a p a d e l S i t io
I n fo r m a c ió n Ig le s ia B a u t is ta M ir a m o n te
Á r e a d e T r a b a jo
Im a g e n
L O G IN
M e n ú d e S i t io W e b P u b l ic o
M e n ú d e M a n t e n im ie n to la A p l ic a c ió n .
C o n t e n e d o r D in á m ic o d e A c t iv id a d e s
117
Dibujo 9. Pantalla inicio de sesión de usuario registrado.
Pantalla Principal de Mantenimientos. Las características y apariencia de esta pantalla se mantendrán iguales a la pantalla
principal. En el área de trabajo es donde se realizaran los procesos del sistema.
Botón “Buscar” permitirá la búsqueda y consulta de registros en la base de datos. Si se
selecciona el botón “Editar”, el sistema enviará automáticamente a la página donde se
podrá editar cada uno de los campos, el botón “Eliminar”, este eliminará el registro de la
118
base de datos. En el caso del botón “Nuevo”, lo enviara a la pantalla para ingreso de
datos con los campos en blanco para que agregue un nuevo registro a la base de
datos.
El menú de mantenimiento, estará visible sólo para usuarios registrados en el sistema.
Dibujo 10. Pantalla Principal de Mantenimientos.
Pantalla de ingreso de datos. Las características y apariencia de esta pantalla se mantendrán igual para todos los
mantenimientos de la Aplicación.
Al seleccionar el botón “Nuevo” el sistema enviara directamente a la pantalla donde
aparecerán de lado izquierdo los campos solicitados y a lado derecho las casillas en
blanco para hacer el registro de los datos. En caso de seleccionar el botón “Editar” las
casillas de los registros aparecerán disponibles para poder hacer las modificaciones
necesarias. El botón “Guardar” guardara los registros nuevos y las modificaciones. El
119
botón “Descartar” no guardara cambios y redireccionará a la pantalla principal de
mantenimiento.
Dibujo 11. Pantalla de ingreso de datos.
11 Niveles de Seguridad. Al hablar de seguridad de datos y registros dentro de las Aplicaciones, es normal
mencionar de llaves de encriptación y algunos términos como algoritmos simétricos,
asimétricos y Hash.
La llave de encriptación es una serie de carácteres, de determinado largo, que se
utiliza para encriptar y desencriptar la información que se quiere proteger. El largo
de la llave depende del algoritmo. Existen llaves privadas y públicas; que se pueden
utilizar en escenarios diferentes dependiendo del tipo de necesidad de seguridad
que necesitemos aplicar:
Escenario 1: Encriptación simétrica
120
Escenario 2: Encriptación asimétrica
Escenario 3: Hash de información
1. Encriptación Simétrica.
Si se necesita almacenar información crítica que deberá descifrarse, y solo
una persona hará todo el proceso; por lo que no habrá nadie más quien tenga
acceso a la llave con que se encriptará y desencriptará la información,
hablamos de Encriptación Simétrica.
Dentro de los algoritmos de encriptación simétrica podemos encontrar los
siguientes:
DES (Digital Encryption Standard)
3DES (Three DES o Triple DES)
IDEA (International Data Encryption Algorithm
AES (Advanced Encryption Standard)
2. Encriptación Asimétrica La encriptación asimétrica permite que dos personas puedan enviarse
información encriptada, sin necesidad de compartir la llave de encriptación.
Se utiliza una llave pública para encriptar el texto y una llave privada para
desencriptar.
Los algoritmos de encriptación asimétrica más conocidos son:
RSA (Rivest, Shamir, Adleman).
Diffie-Hellman (& Merkle)
ECC (Elliptical Curve Cryptography)
3. Hash. Estos son algoritmos del tipo de los que se conocen como de sólo ida, ya que
no es posible desencriptar lo que se ha encriptado.
La utilidad de estos algoritmos se puede evidenciar claramente en casos
como:
121
1. Cuando está dirigido a proteger información muy valiosa encriptando el
contenido; por ejemplo el almacenamiento de contraseñas. Las
contraseñas de cualquier sistema jamás debieran poder desencriptarse; de
lo contrario, el riesgo es que alguien conozca la llave y tenga acceso a todo
el sistema.
Para determinar si la contraseña entregada es valida, se encripta la
contraseña entregada y se compara el resultado de la encriptación con la
contraseña previamente almacenada.
2. Cuando se busca validar y que no se modifique la información que se está
enviando desde un lugar a otro. Si se desea enviar un bloque de datos y se
quiere estar seguro de que nadie lo ha modificado durante el camino, lo
que se hace es enviar el bloque de información sin encriptar y además se
envía un Hash/Digest de este mismo bloque de datos. Entonces, nuestro
receptor al tener la información sin encriptar, le aplica un Hash y con el
mismo criterio explicado anteriormente se, determina si ambos bloques son
iguales. Los algoritmos para hacer Hash mas conocidos son los siguientes:
Tabla 4. Algoritmos Hash
Algoritmo Tamaño del Hash (bits)
MD5 128
SHA-1 160
SHA-256 256
SHA-384 384
SHA-512 512
122
La robustez de un algoritmo de Hash es comparable a la mitad del largo del
resultado en bits. Entonces, pensar que con MD5 se está seguro puede ser
un error. SHA-256 es el indicado para obtener seguridad de 128 bits.
Dentro de esta Aplicación Web el nivel de seguridad a utilizar será
Encriptación Hash, específicamente SHA-256, ya que el objetivo es que la
accesibilidad y manipulación de la información solo sea exclusivo para
Usuarios de sesión que utilizaran una contraseña para el ingreso a la
Aplicación.