capitulo iv. diseÑo de una aplicaciÓn web para la...

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.


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.


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.


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.


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.


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.


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.

capitulo iv. diseÑo de una aplicaciÓn web para la...

Documents