SISTEMA DISTRIBUIDO HETEROGÉNEO PARA LA GESTIÓN DE...

SISTEMA DISTRIBUIDO HETEROGÉNEO PARA LA GESTIÓN DE PQRS EN ENTIDADES

PÚBLICAS

LADY VIVIANA GARAY GONZALEZ

JEYSON STITH AREVALO SANDOVAL

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLOGICA

INGENIERIA EN TELEMATICA

BOGOTA D.C

2015


PÚBLICAS

LADY VIVIANA GARAY GONZALEZ

JEYSON STITH AREVALO SANDOVAL

Documentación proyecto de grado para optar al título:

Ingeniero en telemática

MODALIDAD DE PROYECTOS DE INNOVACIÓN Y DESARROLLO TECNOLÓGICO

Tutor.

Rocío Rodríguez Guerrero

Ingeniero de Sistemas

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

FACULTAD TECNOLOGICA

INGENIERÍA EN TELEMÁTICA

BOGOTA D.C

2015

CONTENIDO

Pág

1. FASE DE PLANIFICACIÓN ..............................................................................................................1

1.1 TEMA ..............................................................................................................................................1

1.2 PLANTEAMIENTO DEL PROBLEMA .................................................................................................1

1.2.1 Descripción:.................................................................................................................................1

1.2.2 Formulación del Problema: .........................................................................................................2

1.3 JUSTIFICACIÓN ...............................................................................................................................2

1.4 OBJETIVOS ......................................................................................................................................3

1.4.1 Objetivo general ..........................................................................................................................3

1.4.2 Objetivos específicos ..................................................................................................................3

1.5 MARCOS DE REFERENCIA ...............................................................................................................4

1.5.1 Marco teórico ..............................................................................................................................4

1.6 MARCO METODOLÓGICO ........................................................................................................... 10

1.6.1 Metodología Scrum .................................................................................................................. 10

1.6.2 Características .......................................................................................................................... 11

1.6.3 Documentos ............................................................................................................................. 12

1.6.3.1 Product backlog .................................................................................................................... 12

1.6.3.2 Sprint backlog ....................................................................................................................... 12

1.6.3.3 Burn down chart ................................................................................................................... 12

1.7 MARCO CONCEPTUAL ................................................................................................................. 12

1.8 MARCO LEGAL ............................................................................................................................. 19

1.9 FACTIBILIDAD .............................................................................................................................. 19

1.9.1 Factibilidad Técnica: ................................................................................................................. 19

1.9.1.1 Hardware: ............................................................................................................................. 19

1.9.1.2 Software: ............................................................................................................................... 20

1.9.2 Factibilidad operativa: ............................................................................................................. 20

1.9.3 Factibilidad económica: ........................................................................................................... 20

1.10 CRONOGRAMA DE ACTIVIDADES .............................................................................................. 23

2. FASE DE DEFINICIÓN ..................................................................................................................... 24

2.1 DEFINICIÓN ................................................................................................................................. 24

2.1.1 Identificación de roles .............................................................................................................. 24

2.1.2 Lista preliminar de actividades por rol..................................................................................... 24

2.1.3 Lista preliminar de Backlogs de producto ................................................................................ 25

2.1.4 Backlogs de producto por sprints de desarrollo ...................................................................... 28

2.2 DEFINICIÓN DEL SPRINT NÚMERO 1 ........................................................................................... 29







3. FASE DE DISEÑO ............................................................................................................................ 34

3.1 DISEÑO DE DESARROLLO DEL SPRINT NÚMERO 1 ...................................................................... 34







4 FASE DE DESARROLLO .................................................................................................................... 38

4.1 RESUMEN DE REUNIONES SPRINT NÚMERO 1 ........................................................................... 38







5. FASE DE PLANIFICACIÓN DE INFRAESTRUCTURA .......................................................................... 44

5.1. DISEÑO LÓGICO DE LA RED ........................................................................................................ 44

5.1.1. Diseño de la topología de la red ............................................................................................. 44

5.1.2. Diseño modelo asignación de dirección. ................................................................................ 44

5.1.3. Protocolos. .............................................................................................................................. 45

5.1.4. Estrategia de seguridad de la red. .......................................................................................... 45

5.1.5. Estrategia de gestión de la red. .............................................................................................. 46

5.2. DISEÑO FÍSICO DE LA RED .......................................................................................................... 47

6. FASE DE INTEGRACIÓN DEL SISTEMA ........................................................................................... 49

6.1. INFRAESTRUCTURA PARA EL PROTOTIPO DEL SISTEMA ............................................................ 49

6.1.1. Sucursales y espacios físicos ................................................................................................... 49

6.1.2 Cableado: ................................................................................................................................. 51

6.1.3 Seguridad: ................................................................................................................................ 52

6.1.4. Sesgos tecnológicos: ............................................................................................................... 52

6.1.5. Análisis y exigencias técnicas. ................................................................................................. 53

6.1.6. Caracterización del tráfico de la red ....................................................................................... 55

6.1.7. Servicios .................................................................................................................................. 58

6.2. MODELO DE LA INTEGRACIÓN DEL SISTEMA ............................................................................. 61

6.3. REUNIONES PARA LA INTEGRACIÓN DEL SISTEMA .................................................................... 67

7. FASE DE PRUEBAS ......................................................................................................................... 67

7.1 PRUEBAS DEL SPRINT NÚMERO 1 ............................................................................................... 68







7.8 PRUEBAS DE LA INTEGRACIÓN DEL SISTEMA ............................................................................. 74

8. CONCLUSIONES ............................................................................................................................. 75

9. RECOMENDACIONES ..................................................................................................................... 76

10. FUENTES DE INFORMACIÓN ....................................................................................................... 77

LISTA DE TABLAS

Pág

Tabla 1. Recursos Factibilidad Económica ........................................................................................ 20

Tabla 2. Identificación de roles ......................................................................................................... 24

Tabla 3 .Lista preliminar de actividades por rol ................................................................................ 24

Tabla 4. Backlogs de producto .......................................................................................................... 25

Tabla 5 .Backlogs de producto por sprints de desarrollo ................................................................. 28

Tabla 6. Definición sprint Número 1 ................................................................................................. 29

Tabla 7. Definición del sprint Número 2 ........................................................................................... 30



Tabla 10. Definición del sprint Número 5 ......................................................................................... 32



Tabla 13. Resumen de reuniones Número 1..................................................................................... 38







Tabla 20. Asignación de direcciones IP ............................................................................................. 45

Tabla 21. Dispositivos........................................................................................................................ 47

Tabla 22. Cableado ............................................................................................................................ 47

Tabla 23. Hardware para la infraestructura de red .......................................................................... 48

Tabla 24. Reuniones para la integración del sistema ....................................................................... 67

Tabla 25. Pruebas del sprint Número 1 ............................................................................................ 68







Tabla 32. Pruebas de la integración del sistema ............................................................................... 74

LISTA DE FIGURAS

Pág

Figura 1. Tendencias Actuales de las arquitecturas de sistemas WEB ................................................8

Figura 2. Variante de los fabricantes de Base de Datos .......................................................................8

Figura 3. Variante de los fabricantes de pasarelas ..............................................................................9

Figura 4. Metodología SCRUM .......................................................................................................... 10

Figura 5. Componentes de una Base de Datos ................................................................................. 16

Figura 6. Representación de gestión de PQR .................................................................................... 18

Figura 7.Cronograma de actividades ................................................................................................ 23

Figura 8. Diseño de topología de red ................................................................................................ 44

Figura 9. Diseño de seguridad en la red ............................................................................................ 46

Figura 10. Sede Administrativa Bogotá ............................................................................................. 49

Figura 11. Sede Principal Bogotá (Infraestructura y Outsourcing) ................................................... 50

Figura 12. Sede Principal Bogotá (Soporte técnico) .......................................................................... 50

Figura 13. Sede de Producto Bogotá ................................................................................................. 51

Figura 14. Diagrama de red sede principal ....................................................................................... 51

Figura 15. Seguridad en la red .......................................................................................................... 52

Figura 16.Disponibilidad de la red .................................................................................................... 55

Figura 17. Tráfico en la red ............................................................................................................... 56

Figura 18. Transferencia en la red .................................................................................................... 57

Figura 19. Tráfico en la red ............................................................................................................... 57

Figura 20. Despliegue en WebLogic .................................................................................................. 59

Figura 21. Despliegue en GlassFish ................................................................................................... 59

Figura 22. Despliegue en Tomcat ...................................................................................................... 59

Figura 23. Servidor de base de datos ................................................................................................ 60

Figura 24. Servidor de archivos ......................................................................................................... 61

Figura 25. Modelo base de datos ...................................................................................................... 62

Figura 26. Diagrama de implementación .......................................................................................... 63

Figura 27. Diagrama de componentes .............................................................................................. 64

Figura 28. Diagrama de integración .................................................................................................. 65

Figura 29. Acceso al sistema ............................................................................................................. 66

Figura 30. Prototipo de aplicación .................................................................................................... 66

Figura 31. Fase de pruebas ............................................................................................................... 67

LISTA DE ANEXOS

Anexo A. Documentación proyecto de grado (En medio magnético).

Anexo B. Manual de usuario (En medio magnético).

Anexo C. Aplicación PQRS1.0 (En medio magnético).

Anexo D. Articulo IEEE Proyecto de grado (En medio magnético).

RESUMEN

Este documento presenta los diferentes procesos integrados para desarrollar un sistema distribuido

heterogéneo para la gestión de peticiones, quejas, reclamos y solicitudes en entidades públicas,

cuyo objetivo principal está encaminado esencialmente a mejorar el control, seguimiento e

integración de los procesos dedicados a gestionar trámites de peticiones, quejas, reclamos y

solicitudes.

El trabajo está fundamentado e implementado con programación en lenguaje web de JAVA,

apoyada en bases de datos ORACLE, la implementación se realiza de acuerdo con la metodología

Scrum que se enfoca en la gestión de sistemas complejos.

Este producto busca optimizar y administrar el trámite de las peticiones, quejas y reclamos que

aplica tanto a personas de una misma organización como a personas externas que ejercen en

entidades públicas aportando un nuevo enfoque tecnológico para la realización de los procesos

que lo contemplan.

ABSTRACT

This document presents different integrated processes to develop a distributed system for

managing heterogeneous requests, complaints, claims and requests for a public agency whose

main objective is aimed essentially at improving the control, monitoring and integration of processes

dedicated to managing Check-in requests, complaints, claims and requests.

The work is founded and implemented in web programming language JAVA, ORACLE database,

the implementation is carried out according to the Scrum methodology that focuses on the

management of complex systems.

This product seeks to optimize and manage the processing of petitions and complaints that applies

to people from the same organization and external persons exercising public entities providing a

new technological approach for the realization of the processes contemplate.

INTRODUCCIÓN

Las oportunidades para el trámite de correspondencia interna y externa para las organizaciones

son múltiples, la principal es la oportunidad de brindar productividad ofreciendo facilidades de

comunicación entre las entidades, hacia los diferentes usuarios que interactúan con ellas, en el

ejercicio de las actividades y servicios que se implementan.

La optimización y organización del proceso dedicadas a realizar trámites de peticiones, quejas,

reclamos y solicitudes (PQRS) son una oportunidad de aligerar la estructura de costos, para

permitir una mayor agilidad y control sobre los gastos de las empresas y mejorar en el flujo de los

servicios ofrecidos. La solución informática requiere el control de los procesos de gestión de PQRS

como: recepción, distribución, trámite, organización, consulta, conservación y disposición final.

Teniendo en cuenta la importancia que tiene la gestión de los servicios ofrecidos en un proceso de

PQRS en una entidad, es importante contemplar una solución tecnológica con las alternativas que

brindan las tecnologías informáticas y telemáticas, que permitan facilitar procesos como:

organización - gestión en la radicación, despacho y seguimiento de PQRS, fácil acceso a la

información, clasificación de acuerdo a dependencias, seccionales o cualquier tipo de distribución

organizacional en las entidades.

Luego de realizar y analizar las tecnologías existentes en el mercado, se expresa la necesidad de

adaptar soluciones desarrolladas a la medida de las organizaciones y sus necesidades.

Este proyecto requiere implementar soluciones de acuerdo a unos lineamientos generales que

establezcan un estándar para entidades públicas, bajo tecnología web, que logren garantizar la

portabilidad entre diferentes sistemas operativos y servidores de aplicaciones, facilitando

independencia y flexibilidad a la hora de elegir hardware y software que suplan mecanismos

manuales usados en las entidades, centrados en la radicación, el despacho y el seguimiento de los

PQRS que se presenten; todo lo anterior no implica ningún tipo de transferencia monetaria o

realización de documentos oficiales para presentarla a otras entidades.

La realización del trabajo se hizo teniendo en cuenta la metodología de desarrollo utilizada, con

enfoque en una fase de análisis de necesidades para posteriormente realizar el diseño adecuado

del sistema, que se implementara basado en las etapas previstas y finalmente realizar las pruebas

pertinentes.

1


PÚBLICAS

1. FASE DE PLANIFICACIÓN

1.1 TEMA

Realización de un sistema para registrar y administrar todas las peticiones, quejas y reclamos, que

aplica tanto a solicitudes de personas externas como a funcionarios de la misma organización. El

sistema puede funcionar en forma distribuida para que todos los funcionarios de la organización

accedan desde su propio PC y diligencien la petición. El sistema genera dinámicamente todos

aquellos reportes estadísticos, control de tiempos de respuesta, asignación de quejas y reclamos,

tipos de peticiones y estados de avance.

1.2 PLANTEAMIENTO DEL PROBLEMA

1.2.1 Descripción:

En una organización es fundamental garantizar la satisfacción del cliente con la capacidad para

gestionar los procesos que le competen y que presentan las dependencias que la conforman.

Es por ello que el proceso de operación a plantear está enfocado con el fin de atender

oportunamente el trámite de las peticiones, quejas y reclamos tanto de funcionarios internos como

funcionarios externos que ejercen en entidades públicas los cuales tienen el derecho de manifestar

de manera respetuosa su inconformidad por el servicio prestado. El proceso Inicia con la recepción

de la petición por parte del funcionario encargado de la oficina de correspondencia puede ser

escrito o verbal; el análisis del motivo, todas las peticiones, quejas y reclamos quedarán

registradas en el formato “Registro y Control de Peticiones, Quejas, Reclamos” y se direcciona

según la dependencia que Corresponda; la dependencia realiza el traslado al funcionario a quien

está dirigida la petición; el trámite de la respuesta, dentro de un término no mayor a 8 días se

informa al funcionario solicitante sobre la gestión cumplida. Si la PQR no contiene la información

necesaria para su adecuado tratamiento, se le informa al funcionario solicitante de manera escrita

por una sola vez para que aporte la información complementaria en un término no mayor de 15

días. La Dependencia correspondiente dará respuesta por escrito al funcionario que presentó la

PQR, Informando las medidas tomadas por la dependencia y los resultados obtenidos. Esta

2

respuesta se enviará a la dirección suministrada por el funcionario solicitante a través de los datos

que se suministren en el formato. Cuando no es posible resolver o contestar la petición en dicho

plazo, se le informa al interesado, expresando los motivos de la demora y señalando a la vez la

fecha en que se resolverá y dará respuesta; y por último el seguimiento a la calidad de la respuesta

a través de un informe cualitativo y cuantitativo de las PQR que revelen la eficiencia de los

funcionarios y dependencias encargadas de resolver los casos de peticiones, quejas y reclamos.

En una organización la calidad y brindar el cumplimiento de respuesta de una queja no puede

admitir retrasos, y tampoco la insatisfacción del solicitante que requiere una solución oportuna.

En el proceso descrito pueden ocurrir retrasos que afectan los tiempos de respuesta del servicio e

incluso costos de traslado de material físico entre una y otra entidad. Ya que si no se garantiza un

debido control desde la recepción hasta el trámite de respuesta de peticiones, quejas y reclamos

en el tiempo oportuno, los funcionarios pueden presentar retrasos para responder las solicitudes,

debido a que tienen un menor tiempo para atenderlas si no recibieron la solicitud inmediatamente o

simplemente desconocen los tiempos debidos para dar respuesta y cumplimiento debido.

Ante tal situación planteada, como posible solución es la de ofrecer el mejoramiento del proceso

peticiones, quejas y reclamos que se lleva actualmente acabo en las entidades públicas con la

automatización de un Sistema distribuido de Correspondencia la gestión y radicación de

solicitudes.

En el cual, se logre solventar los inconvenientes que se presentan; como lo es en algunos casos el

retraso en la entrega de la correspondencia y las demoras de respuesta de la solicitudes. Así como

para tener una mayor demanda de peticiones lo que va a permitir brindar una mejor organización

del proceso y tener un mejor seguimiento de este, para la toma de decisiones.

1.2.2 Formulación del Problema:

¿La construcción de un sistema distribuido agiliza los tiempos de respuesta de una petición, queja

o un reclamo en una entidad pública?

1.3 JUSTIFICACIÓN

La creación de un sistema en cualquier empresa es importante, toda organización requiere de

algún mecanismo que relaciones sus actividades y procesos.

3

Agilizar la respuesta en la comunicación entre dependencias de una radicación de petición, queja o

reclamo, a través del sistema de gestión de PQR los funcionarios de las dependencias podrá

ofrecer una pronta respuesta a las solicitudes radicadas, ya que esto requiere integrar los

diferentes procesos y que todos se puedan ver como si fueran uno solo. Por ejemplo si un jefe de

una organización quiere generar estadísticas para mejoras de atención al cliente, puede ver todas

las quejas más frecuentes, debido al proceso de integración y a un sistema distribuido heterogéneo

que quiere decir que cuenta con características físicas y operativas, distintas entre sí.

Enfocándonos en la Universidad Distrital, sería ideal tener un sistema que ayude y satisfaga

necesidades tanto básicas como algunas más complejas que permita tener fácil acceso a la

información y así mismo a su manipulación; para esto se ha propuesto desarrollar un sistema

distribuido que brinde un ambiente agradable, sencillo y de completa seguridad para la realización

de procesos en la organización

1.4 OBJETIVOS

1.4.1 Objetivo general

Construir un sistema distribuido heterogéneo para entidades públicas que gestionen las Peticiones,

Quejas y Reclamos (PQR) permitiendo realizar su seguimiento desde la radicación hasta la

respuesta.

1.4.2 Objetivos específicos

- Analizar los requerimientos para el desarrollo de todos los componentes del sistema

distribuido.

- Diseñar los módulos según reglas de negocio que involucran formatos, informes y

estadísticas para los procesos de peticiones, quejas, reclamos y solicitudes los cuales

componen los elementos del sistema.

- Desarrollar el software que gestione los procesos involucrados desde la recepción hasta la

respuesta de PQRs y la base de datos que administre la información de funcionarios

internos y externos, así como de solicitudes, peticiones, quejas y reclamos, para la gestión

de PQRs.

- Planificar la infraestructura necesaria para la implementación del sistema de acuerdo a la

entidad donde se probara.

4

- Integrar todos los componentes del sistema con la infraestructura suministrada para el

prototipo planteado.

- Probar la funcionalidad de cada componente para evidenciar las debilidades y ajustes que

se deben realizar a cada uno de ellos.

1.5 MARCOS DE REFERENCIA

1.5.1 Marco teórico

Las principales áreas que debería englobar un sistema de este tipo para que se pueda considerar

como un elemento definitorio en la modernización de una organización.

Digitalización e indexación de documentos: la digitalización o el almacenamiento digital de

cualquier documento es sólo el primer paso. Cualquier sistema de este tipo debe contar con

algún método de referenciación o indexación (automático o no), que nos permita luego ser

capaces de encontrar la documentación que necesitamos sin grandes esfuerzos.

Enlace con el sistema de gestión: aunque no es un requisito imprescindible, si pensamos que

la mayor parte de los documentos que manejamos en la empresa están relacionados de una

u otra forma con su gestión (facturas, contratos, pedidos, etc.), integrar la gestión documental

dentro de nuestro sistema de gestión empresarial puede suponer un gran ahorro de tiempo

en la catalogación de los documentos. Cada fichero estará relacionado con uno o varios

datos que debemos introducir en nuestro sistema de gestión. Integrando ambos nos

ahorramos duplicar el trabajo y facilitamos la búsqueda de información, puesto que la

efectuaremos desde la misma aplicación con la que gestionamos nuestra compañía.

Flujos de trabajo: cuando un papel entra en la empresa no suele estarse quieto. De

facturación a contabilidad, de ahí a gerencia para su revisión, de gerencia al departamento

técnico. Los papeles pasan por muchas manos. Si el sistema de gestión documental es capaz

de manejar estos flujos de trabajo (por sí mismo, mediante el software de gestión de la

empresa o mediante otra aplicación) todo ese vaivén de documentación se puede reducir al

mínimo o eliminar completamente. Si os suena esta situación, seguro que apreciaréis la

mejora productiva que puede suponer.

Estos son a grandes rasgos los puntos que me parecen clave en un sistema de este tipo, cuanto

más integrado esté en nuestra organización y sus procesos productivos, más rendimiento

obtendremos de él.

5

Según el planteamiento que se hace en la Ley General de Archivos de Colombia, la Gestión de

PQR es un “Conjunto de actividades administrativas y técnicas tendientes a la planificación,

manejo y organización de la documentación producida y recibida por las entidades, desde su

origen hasta su destino final, con el objeto de facilitar su utilización y conservación” Ahora podemos

decir, tomando las ideas anteriores, que la gestión de PQR consiste, en el tratamiento y

conservación que se les da a los documentos, desde el principio de su ciclo de vida, es decir, la

producción del mismo, hasta su eliminación o conservación permanente después de haberse

solucionado el requerimiento original, todo esto siguiendo las diversas etapas que constituyen el

ciclo de vida de los documentos, y por supuesto respetando el principio de orden original y el

principio de procedencia.

Para cualquier organización la gestión de PQR por medio de un sistema es un gran reto, que tarde

o temprano tendrán que enfrentar, a menos que quieran ser organizaciones obsoletas y poco

actualizadas. Es un reto difícil, ya que es necesario realizar tareas como auditoria de información y

gestión electrónica de documentos, entre otras, para lo cual muy pocas personas están

capacitadas.

Muchos autores, entre ellos, Doyle Murielle y Myriam Mejía estan de acuerdo en que la gestión de

PQRy la gestión de documentos fue concebida en Estados Unidos, alrededor de la década de los

50, fue muy aceptada dentro de ese país y fue reconocida de forma oficial a mediados del siglo XX.

Esta gestión revolucionó toda la práctica archivística que se venía realizando hasta entonces, ya

que introduce el ciclo vital de los documentos de lo cual no se conocía hasta ese momento,

demostrando una interconexión entre las diversas etapas o procedimientos que se aplican a los

archivos personales o institucionales que requieren un tratamiento y una respuesta.

Para implementar la gestión de PQR dentro de cualquier organización es necesario contar con un

programa de gestión documental que nos permita lograr la transición sin mayores dificultades, para

los empleados, y para la organización.

Es decir, un programa de gestión documental puede ser entendido como un conjunto de

instrucciones que se les indican a cada departamento dentro de la organización, estas

instrucciones están relacionadas con la correcta implementación de las operaciones archivísticas

que se realicen en cada departamento, con el fin, que en líneas generales se manejen los

documentos de igual forma en los diferentes departamentos, facilitando así la gestión de PQR

dentro de la organización.

6

Al implementar o elaborar un programa de gestión documental orientado a PRQ se buscan

alcanzar una serie de objetivos entre los que se pueden mencionar:

Tener en cuenta la importancia que tiene los documentos de archivos dentro de cualquier

institución pública o privada.

Buscar la racionalización y control de la producción documental, basándose en los

procedimientos archivísticos, con el fin de evitar la producción de documentos innecesarios

o que documentos que no lo ameriten sean conservados por más tiempo del necesario o el

reglamentario.

Hacer una reglamentación en cuanto al tipo de materiales y soportes de calidad que se

empleen, todo en busca de la preservación del medio ambiente.

Permitir la recuperación de información de una forma mucho más rápida, efectiva y exacta.

Lograr que los archivos sean vistos dentro y fuera de la organización como verdaderas

unidades de información útiles no solo para la administración sino también para la cultura.

El concepto de "Sistemas Distribuidos" se ha popularizado tanto en la actualidad y tiene como

ámbito de estudio las redes como por ejemplo: Internet, redes de teléfonos móviles, redes

corporativas, redes de empresas, etc.

A. Definición:

Sistemas cuyos componentes hardware y software, que están en ordenadores conectados en red,

se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un

objetivo. Se establece la comunicación mediante un protocolo prefijado por un esquema cliente-

servidor.

B. Características:

Concurrencia. Esta característica de los sistemas distribuidos permite que

los recursos disponibles en la red puedan ser utilizados simultáneamente por los usuarios

y/o agentes que interactúan en la red.

Carencia de reloj global. Las coordinaciones para la transferencia de mensajes entre los

diferentes componentes para la realización de una tarea, no tienen una temporización

general, está más bien distribuida a los componentes.

http://www.monografias.com/trabajos10/teca/teca.shtml

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/Computacion/Internet/

http://www.monografias.com/trabajos11/empre/empre.shtml

http://www.monografias.com/Computacion/Hardware/

http://www.monografias.com/Computacion/Software/

http://www.monografias.com/Computacion/Redes/

http://www.monografias.com/trabajos4/acciones/acciones.shtml

http://www.monografias.com/trabajos12/fundteo/fundteo.shtml

http://www.monografias.com/trabajos12/mncerem/mncerem.shtml

http://www.monografias.com/trabajos11/sercli/sercli.shtml

http://www.monografias.com/trabajos12/rete/rete.shtml

http://www.monografias.com/trabajos4/refrec/refrec.shtml

7

Fallos independientes de los componentes. Cada componente del sistema puede fallar

independientemente, con lo cual los demás pueden continuar ejecutando sus acciones.

Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto

continua trabajando.

C. Evolución:

Procesamiento central (Host): Uno de los primeros modelos de ordenadores interconectados,

llamados centralizados, donde todo el procesamiento de la organización se llevaba a cabo en una

sola computadora, normalmente un Mainframe, y los usuarios empleaban sencillos ordenadores

personales.

Los problemas de este modelo son:

Cuando la carga de procesamiento aumentaba se tenía que cambiar el hardware del

Mainframe, lo cual es más costoso que añadir más computadores

personales clientes o servidores que aumenten las capacidades.

El otro problema que surgió son las modernas interfaces gráficas de usuario, las cuales

podían conllevar a un gran aumento de tráfico en los medios de comunicación y por

consiguiente podían colapsar.

Grupo de Servidores: Otro modelo que entró a competir con el anterior, también un tanto

centralizado, son un grupo de ordenadores actuando como servidores, normalmente de archivos o

de impresión, poco inteligentes para un número de Minicomputadores que hacen el procesamiento

conectados a una red de área local.

Los problemas de este modelo son:

Podría generarse una saturación de los medios de comunicación entre los servidores poco

inteligentes y los minicomputadores, por ejemplo cuando se solicitan archivos grades por

varios clientes a la vez, podían disminuir en gran medida la velocidad de transmisión

de información.

La Computación Cliente Servidor.- Este modelo, que predomina en la actualidad, permite

descentralizar el procesamiento y recursos, sobre todo, de cada uno de los servicios y de

la visualización de la Interfaz Gráfica de Usuario. Esto hace que ciertos servidores estén

dedicados solo a una aplicación determinada y por lo tanto ejecutarla en forma eficiente.

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos6/napro/napro.shtml

http://www.monografias.com/trabajos15/computadoras/computadoras.shtml

http://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtml#PLANT

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos11/sercli/sercli.shtml

http://www.monografias.com/trabajos12/rete/rete.shtml

http://www.monografias.com/trabajos11/estadi/estadi.shtml#METODOS

http://www.monografias.com/trabajos14/medios-comunicacion/medios-comunicacion.shtml

http://www.monografias.com/trabajos14/dinamica-grupos/dinamica-grupos.shtml

http://www.monografias.com/trabajos7/arch/arch.shtml

http://www.monografias.com/Computacion/Redes/

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos14/verific-servicios/verific-servicios.shtml

8

En la actualidad la aplicación de sistemas informáticos basados en Internet, es una herramienta

fundamental para las organizaciones que desean tener cierta presencia competitiva.

Las tecnologías inalámbricas, en los últimos años, están alcanzando la madurez necesaria para

permitir el acceso a una red, sin la necesidad de la utilización de los cables tradicionales de

conexión. Caso particular de los sistemas Cliente-Servidor con representación remota. En donde

se dispone de un protocolo estándar: HTTP y un Middleware denominado WebServer.

Figura 1. Tendencias Actuales de las arquitecturas de sistemas WEB

Figura 2. Variante de los fabricantes de Base de Datos

http://www.monografias.com/trabajos11/wind/wind2.shtml

9

Figura 3. Variante de los fabricantes de pasarelas

D. Ventajas de los sistemas distribuidos

Con respecto a Sistemas Centralizados:

Una de las ventajas de los sistemas distribuidos es la economía, pues es mucho más

barato, añadir servidores y clientes cuando se requiere aumentar la potencia de

procesamiento.

El trabajo en conjunto. Por ejemplo: en una fábrica de ensamblado, los robots tienen sus

CPUs diferentes y realizan acciones en conjunto, dirigidos por un sistema distribuido.

Tienen una mayor confiabilidad. Al estar distribuida la carga de trabajo en muchas

máquinas la falla de una de ellas no afecta a las demás, el sistema sobrevive como un

todo.

Capacidad de crecimiento incremental. Se puede añadir procesadores al sistema

incrementando su potencia en forma gradual según sus necesidades.

Con respecto a PCs Independientes:

Se pueden compartir recursos, como programas y periféricos, muy costosos. Ejemplo:

Impresora Láser, dispositivos de almacenamiento masivo, etc.

Al compartir recursos, satisfacen las necesidades de muchos usuarios a la vez. Ejemplo:

Sistemas de reservas de aerolíneas.

Se logra una mejor comunicación entre las personas. Ejemplo: el correo electrónico.

Tienen mayor flexibilidad, la carga de trabajo se puede distribuir entre diferentes

ordenadores.

http://www.monografias.com/trabajos5/sisope/sisope.shtml

http://www.monografias.com/trabajos5/losperif/losperif.shtml

http://www.monografias.com/trabajos/laser/laser.shtml

10

E. Desventajas de los sistemas distribuidos

El principal problema es el software, es el diseño, implantación y uso del software distribuido, pues

presenta numerosos inconvenientes. Los principales interrogantes son los siguientes:

¿Qué tipo de S. O., lenguaje de programación y aplicaciones son adecuados para estos

sistemas?

¿Cuánto deben saber los usuarios de la distribución?

¿Qué tanto debe hacer el sistema y qué tanto deben hacer los usuarios?

La respuesta a estos interrogantes no es uniforme entre los especialistas, pues existe una

gran diversidad de criterios y de interpretaciones al respecto.

Otro problema tiene que ver con las redes de comunicación. Por ejemplo: Perdida de

mensajes, saturación en el tráfico, etc.

Un problema que puede surgir al compartir datos es la seguridad de los mismos.

En general se considera que las ventajas superan a las desventajas, si estas últimas se

administran seriamente.

1.6 MARCO METODOLÓGICO

1.6.1 Metodología Scrum

1Es un marco de trabajo para la gestión y desarrollo de sistemas basada en un proceso iterativo e

incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.

Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser

utilizado en una aproximación de gestión de sistemas más complejos.

Figura 4. Metodología SCRUM

1Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams

http://www.monografias.com/trabajos13/diseprod/diseprod.shtml

http://www.monografias.com/trabajos11/travent/travent.shtml

http://es.wikipedia.org/wiki/Desarrollo_de_software

http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente

http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente

http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software

11

1.6.2 Características

SCRUM es un modelo de referencia que define un conjunto de prácticas y roles, y que puede

tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un

proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja

de forma similar al director de proyecto, el ProductOwner, que representa a

los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores.

Scrum permite la creación de equipos auto-organizados impulsando la localización de todos los

miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados

en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden

cambiar de idea sobre lo que quieren y necesitan y que los desafíos impredecibles no pueden ser

fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una

aproximación pragmática, aceptando que el problema no puede ser completamente entendido o

definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder

a requisitos emergentes.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde

notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de

Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

12

1.6.3 Documentos

1.6.3.1 Product backlog

El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones

genéricas de todos los requerimientos, funcionalidades deseables, etc. priorizadas según su

retorno sobre la inversión (ROI). Es el qué va a ser construido. Es abierto y solo puede ser

modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos, tanto del

valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product

owner a ajustar la línea temporal (KEV) y, de manera limitada, la prioridad de las diferentes tareas.

Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menor tiempo

de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto.

1.6.3.2 Sprint backlog

El sprint backlog es un documento detallado donde se describe el cómo el equipo va a

implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna

tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en

otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los

miembros del equipo del modo que les parezca oportuno.

1.6.3.3 Burn down chart

La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en

el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte

los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es

que esta línea sea descendente hasta llegar al eje horizontal, momento en el cual el proyecto se ha

terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el

proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados

segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en

algunos tramos.

1.7 MARCO CONCEPTUAL

http://es.wikipedia.org/wiki/Retorno_de_la_inversi%C3%B3n

http://es.wikipedia.org/wiki/Retorno_de_la_inversi%C3%B3n

http://es.wikipedia.org/wiki/Burn_down_chart

13

A. Programación Multicapas.2 La programación en múltiples capas es la técnica más efectiva

en aplicaciones empresariales, debido a la fácil administración que implica el dividir los

componentes de la aplicación en capas y la rapidez que esto implica en programas

orientados a Cliente-Servidor. Esta arquitectura consiste en dividir los componentes

primarios de la aplicación, programarlos por separado y después unirlos en tiempo de

ejecución.

Se presentan tres capas que las podemos denominar como: Presentación, Reglas del Negocio y

Acceso a Datos (presentación, persistencia, lógica):

Presentación:

En esta capa se diseña todo lo que constituye la interfaz gráfica y la interacción del

usuario con el software.

Reglas del Negocio:

Son todas las subrutinas creadas con el propósito de regular alguna acción del

usuario. Por ejemplo, en una aplicación bancaria una regla del negocio podría ser que

el cliente no debe retirar por taquilla más de U.S. $10.000 y en caso de una petición de

este tipo se genere un error.

Acceso a Datos:

En esta capa programamos todo lo que tiene que ver con el acceso a la base de datos.

Esta capa queda encargada de tomar la información de la base de datos dada una

petición de la capa de Reglas del Negocio, que a su vez es generada por la capa de

presentación.

B. Arquitectura multinivel.3Es un estilo de programación en la que el objetivo primordial es la

separación de la lógica de negocios de la lógica de diseño, un ejemplo básico de esto es

separar la capa de datos de la capa de presentación al usuario.

La ventaja principal de este estilo, es que el desarrollo se puede llevar a cabo en varios niveles y

en caso de algún cambio sólo se ataca al nivel requerido sin tener que revisar entre código

mezclado. Un buen ejemplo de este método de programación seria: Modelo de interconexión de

sistemas abiertos.

Capa de presentación: es la que ve el usuario, presenta el sistema al usuario, le

comunica la información y captura la información del usuario dando un mínimo de

2Introducción a la programación Multicapas, http://www.elguille.info/colabora/puntoNET/jevergara_Multitier.htm

3Programación por capas,http://oasis.cisc-ug.org/letzhune/Programacion%20por%20capas.doc

http://oasis.cisc-ug.org/letzhune/cisc/tutoriales/tercero/Programacion%20por%20capas.doc

14

proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Esta

capa se comunica únicamente con la capa de negocio.

Capa de negocio: es donde residen los programas que se ejecutan, recibiendo las

peticiones del usuario y enviando las respuestas tras el proceso. Se denomina capa de

negocio (e incluso de lógica del negocio) pues es aquí donde se establecen todas las

reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para

recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al

gestor de base de datos para almacenar o recuperar datos de él.

Capa de datos: es donde residen los datos. Está formada por uno o más gestor de

bases de datos que realiza todo el almacenamiento de datos, reciben solicitudes de

almacenamiento o recuperación de información desde la capa de negocio.

El modelo MVC: 4El modelo con mayor auge en la actualidad es el modelo MVC. Sobre

este modelo existe una serie de implementaciones como Ruby onRails o Cake PHP. La

ventaja fundamental del modelo es la separación de la lógica de programación en tres

partes: Modelo, Vista y Controlador.

Según experiencias de programadores que han utilizado este modelo de desarrollo, el mismo se

adapta perfectamente para proyectos pequeños, pero a medida que la complejidad del proyecto se

incrementa, cada vez es más difícil llevar una integración perfecta sin afectar las demás

estructuras.

Puede resultar bastante complicado seguir con el desarrollo de una aplicación con un nivel de

complejidad mayor, sino contamos con la adecuada experiencia en el manejo del concepto.

En lo particular, veo un serio problema en esta situación, además de que el uso del modelo,

utilizando cualquier tecnología como Ruby onRails u otros frameworks de desarrollo, hasta por

completo nuestro proyecto a tal o cual tecnología.

Esto puede ser un serio problema, si contamos con que la tendencia de nuevas herramientas

mucho más fáciles de utilizar, están siendo desarrolladas continuamente y sus variantes son

implementadas, como paquetes independientes de cualquier plataforma.

C. Herramientas de desarrollo. Framework: 5Plataforma, entorno, marco de trabajo. Desde el

punto de vista del desarrollo de software.

4 Desarrollo multinivel para aplicaciones basadas en el web,http://www.maestrosdelweb.com/editorial/desarrollo-multinivel-

para-aplicaciones-basadas-en-el-web/

5Definición de Framework, http://www.alegsa.com.ar/Dic/framework.php

15

Es una estructura de soporte definida, en la cual otro proyecto de software puede ser organizado y

desarrollado.

Los frameworks suelen incluir: Soporte de programas. Bibliotecas. Lenguaje de scripting.

Software para desarrollar y unir diferentes componentes de un proyecto de desarrollo de

programas.

Los frameworks permiten: Facilitar el desarrollo de software. Evitar los detalles

de bajo nivel, permitiendo concentrar más esfuerzo y tiempo en identificar los

requerimientos de software.

Lenguaje De Programación: 6 Un lenguaje de programación es un idioma artificial

diseñado para expresar computaciones que pueden ser llevadas a cabo por máquinas

como las computadoras. Pueden usarse para crear programas que controlen el

comportamiento físico y lógico de una máquina, para expresar algoritmos con precisión, o

como modo de comunicación humana.

Los lenguajes de programación son herramientas que nos permiten crear programas y

software. Entre ellos tenemos Delphi, Visual Basic, Pascal, Java, entre otros. Una

computadora funciona bajo control de un programa el cual debe estar almacenado en la

unidad de memoria; tales como el disco duro. Los lenguajes de programación de una

computadora en particular se conocen como código de máquinas o lenguaje de máquinas.

Estos lenguajes codificados en una computadora específica no podrán ser ejecutados en

otra computadora diferente.

Para que estos programas funcionen para diferentes computadoras hay que realizar una

versión para cada una de ellas, lo que implica el aumento del costo de desarrollo. Por otra

parte, los lenguajes de programación en código de máquina son verdaderamente difíciles

de entender para una persona, ya que están compuestos de códigos numéricos sin sentido

nemotécnico. Los lenguajes de programación facilitan la tarea de programación, ya que

disponen de formas adecuadas que permiten ser leídas y escritas por personas, a su vez

resultan independientes del modelo de computador a utilizar. Los lenguajes de

programación representan en forma simbólica y en manera de un texto los códigos que

podrán ser leídos por una persona.

6 Programación Multinivel, http://julianavetecsisdatos.blogspot.com/

16

D. Base de datos.7Es un sistema que almacena datos que están relacionados. Es un

repositorio en donde guardamos información integrada que podemos almacenar y

recuperar. Un conjunto de información almacenada en memoria auxiliar que permite acceso

directo y un conjunto de programas que manipulan esos datos

Componentes de una Base de Datos

Hardware: constituido por dispositivo de almacenamiento como discos, tambores,

cintas, etc.

Software: que es el DBMS o Sistema Administrador de Base de Datos.

Datos: los cuales están almacenados de acuerdo a la estructura externa y van a ser

procesados para convertirse en información.

Figura 5. Componentes de una Base de Datos

E. Sistema distribuido de archivos. 8El sistema distribuido de archivos permite a los programas

almacenar y acceder a archivos remotos del mismo modo que si fueran locales, permitiendo

a los usuarios que accedan archivos desde cualquier computador.

7Marlon Ruiz, Enlace del artículo, http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml

8 Sistema Distribuido de archivos, http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/SISTAR02.html

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/SISTAR02.html

17

Un servidor de archivos es un proceso que se ejecuta en alguna máquina y ayuda a implantar el

servicio de archivo. Un sistema puede tener uno o varios servidores de archivos, cada uno de los

cuales ofrece un servicio de archivos distintos.

Los clientes no deben conocer el número de servidores de archivos, su posición o función. Todo lo

que saben es que al llamar los procedimientos especificados en servicio de archivos, el trabajo

necesario se lleva a cabo de alguna manera y se obtienen los resultados pedidos. Los clientes ni

siquiera deben saber que el servicio de archivos es distribuido. Lo ideal es que se vea como un

sistema de archivos normal de un procesador.

F. Documento.9El Consejo Nacional de Archivos define documento como: "Toda expresión

testimonial de las actividades del hombre, de los grupos humanos y de las instituciones en

cualquier lenguaje y en cualquier tipo de formato o soporte material." Según el artículo 251

del Código de Procedimiento Civil “Son documentos los escritos, impresos, planos, dibujos,

cuadros fotografías, cintas cinematográficas, discos, grabaciones magnetofónicas,

radiografías, talones, contraseñas, cupones, etiquetas, sellos y, en general, todo objeto

mueble que tenga carácter representativo o declarativo, y las inscripciones en lápidas,

monumentos, edificios o similares.”

G. Archivo. El Reglamento General de Archivos establecido por el Archivo General de la

Nación, el cual expresa que: "Archivo es uno o más conjuntos de documentos sea cual sea

su fecha, su forma y soporte material, acumulados en un proceso natural por una persona o

institución pública o privada en el transcurso de su gestión, conservados, respetando aquel

orden para servir como testimonio o información para la persona o Institución que los

produce, para los ciudadanos o para servir de fuente de historia".

H. Gestión Documental.10El Archivo General de la Nación en la Ley 594 de 2000 define

Gestión Documental como “Conjunto de actividades administrativas y técnicas tendientes a

la planificación, manejo y organización de la documentación producida y recibida por las

entidades, desde su rigen hasta su destino final con el objeto de facilitar su utilización y

conservación”.

Por otro lado la ISO (Organización Internacional para la Estandarización) define Gestión

Documental como Disciplina encargada del control eficiente y sistemático de la creación,

9CONSEJO NACIONAL DE ARCHIVOS. Instructivo de organización básica y Gestión de Archivos Administrativos. Quito.

2005. p.47 [EN LINEA]. [consultado May 2008]. Disponible en: http://www.coalicionacceso.org/docs/archivos.pdf

10PEIS, Eduardo; RUIZ RODRÍGUEZ, Antonio A. EL archivo como sistema de información. p.2. [EN LINEA]. [consultado 9

Nov. 2007]. Disponible en: <www.ugr.es/~epeis/docencia/archivistica/ruiz3.doc>

http://www.coalicionacceso.org/docs/archivos.pdf

http://www.ugr.es/~epeis/docencia/archivistica/ruiz3.doc

18

recepción, mantenimiento, uso y eliminación de records, incluyendo el proceso de captura y

mantenimiento de las evidencias e informaciones acerca de actividades de negocio y

transacciones en la forma de records. Trabajo de Grado de Paola y Diego Angarita C.

Así mismo el Consejo Internacional de Archivos define Gestión Documental como “área de gestión

administrativa general relativa a conseguir economía y eficacia en la creación, mantenimiento, uso

y disposición de los documentos”.

En resumen Gestión de PQR significa planeación, control, dirección, organización, entrenamiento,

organización, promoción y otras actividades de gerencia que involucran la creación documental, su

mantenimiento, uso y disposición en orden de archivar adecuada y propiadamente la

documentación basándose en las políticas y reglamentación gubernamental.

La Universidad Inernacional de Andalucia representa la definición de Gestión de PQR con el

siguiente gráfico:

Figura 6. Representación de gestión de PQR

I. Ciclo de vida de los documentos. El ciclo de vida de los documentos establece que el

documento como organismo vivo, se crea o se recibe, se establece su forma física (papel,

electrónico, magnético, fotográfico etc.) y el contenido informativo. Los documentos

19

después se utilizan y mantienen. Se indizan, revisan, re archivan, reorganizan y cumplen

con su tiempo de función su edad aumenta gradualmente con sus valores.

1.8 MARCO LEGAL

La gestión documental para procesos de PQR comprende los aspectos de origen, creación y

diseño de formatos y documentos, conforme al desarrollo de las funciones propias de cada entidad

o dependencia y la normalización su gestión.

Ley 43 de 1913. Sobre el uso de tinta indeleble para documentos oficiales.

Ley 527 de 1999 Artículo 7. Sobre mensajes de datos y firmas digitales.

Código Penal Artículos 218 a 228. Sobre las disposiciones relacionadas con falsificación

de los documentos públicos.

Artículo 231. Sobre reconocimiento y copia de objetos y documentos.

Código de Procedimiento Penal Artículo 261. Sobre el valor probatorio de documento

público. Artículos 262 a 263. Sobre valor probatorio de documento privado.

Código de Comercio

Artículo 48. Conformidad de libros y papeles del comerciante a las normas comerciales -

medios para el asiento de operaciones.

Artículo 51. Comprobantes y correspondencia como parte integral de la contabilidad.

Artículo 54. Obligatoriedad de conservar la correspondencia comercial.

Decreto 2649 de 1993 Por el cual se reglamenta la Contabilidad en General y se expiden

los principios o normas de contabilidad generalmente aceptados en Colombia.

Artículo 123. Soportes contables Decreto 1584 de 1994 Documentación indispensable

Registro

Proponentes Cámaras de Comercio.

Decreto 2150 de 1995 Artículos 11, 12, 23 y 24. Uso de formatos únicos.

1.9 FACTIBILIDAD

1.9.1 Factibilidad Técnica:

1.9.1.1 Hardware:

Para el proyecto planteado necesitaremos una serie de recursos hardware que faciliten la rapidez y

la amplitud de almacenamiento; Los recursos del equipo que se desean son:

20

Recursos mínimos:

- Procesador: Intel Pentium 4 o AMD Semprom.

- Memoria RAM 512 Mb.

- Disco duro 5 Gb disponibles.

Recursos recomendados:

- Procesador: Intel Dual Core 2 Duo o AMD Athlom X2.

- Memoria RAM 1 Gb.

- Disco duro 10 Gb disponibles.

Recursos de intranet suministrados por la empresa.

1.9.1.2 Software:

El proyecto a realizar requiere de una serie de conocimientos especializados en bases de datos y

programación en java, Se usara software especializado para programación, los motores para

programar son:

- Netbeans (Java).

- Oracle (PL/SQL).

1.9.2 Factibilidad operativa:

El proyecto cuenta con el soporte del tutor de la universidad DISTRITAL FRANCISCO JOSE DE

CALDAS – FACULTAD TECNOLOGICA.

Además cuenta con la asesoría e un auxiliar de gerencia y área de licitaciones de la empresa C&C

GALU CONSTRUCCIONES Y CONSULTORIAS S.A.S. que proporcionara la información e

instrucciones necesarias sobre el manejo del negocio.

1.9.3 Factibilidad económica:

Tabla 1. Recursos Factibilidad Económica

21

TOTAL: 10.250.000

Papelería:

Estudiante = $120.000

Universidad = $50.000

Empresa = $50.000

TOTAL = $220.000

Hardware:

Estudiante = $1.500.000

Universidad = $0

Empresa = $1.500.000

TOTAL = $3.000.000

Telecomunicaciones:

Estudiante = internet + telefonía celular + telefonía local=$200.000+$180.000+$160.000=$540.000

Universidad = $0

Empresa = internet + telefonía celular + telefonía local = $100.000+$90.000+$80.000=$270.000

TOTAL = $810.000

Elemento Estudiante ($) Universidad ($)

Papelería 120.000 50.000

Hardware 2.500.000

Telecomunicaciones 540.000

Tutores 1.060.000

Asesores 500.000

Mano de obra 5.280.000

Bibliografía 500.000

Transportes 700.000

TOTAL C/U 8.640.000 1.610.000

22

Tutores (Ingeniera Rocio Rodríguez):

Estudiante = $0

Universidad = horas semanales * semanas * valor hora = 4 * 26,5 * $10.000 = $1.060.000

Empresa = $0

TOTAL = $1.060.000

Mano de obra (Viviana Garay y Jeyson Arévalo)

Estudiante = horas diarias * días * valor hora= 2 * 132 * $10.000 = $5.280.000

Universidad = $0

Empresa = $0

TOTAL = $5.280.000

Bibliografía:

Estudiante = $0

Universidad = $500.000

Empresa = $0

TOTAL = $500.000

Transportes:

Estudiante = $700.000

Universidad = $0

Empresa = $0

TOTAL = $700.000

Total:

Estudiante = 8.140.000

Universidad = $1.610.000

Empresa = $2.880.000

TOTAL = $12.630.000

1.10 CRONOGRAMA DE ACTIVIDADES

Fecha inicio: 8 de Agosto de 2014

Total semanas: 3 de Agosto de 2015 Figura 7.Cronograma de actividades

24

2. FASE DE DEFINICIÓN

2.1 DEFINICIÓN

2.1.1 Identificación de roles

Tabla 2. Identificación de roles

ROL RESPONSABLE DESCRIPCION

Usuario (Product owner) Eliana Guerrero Analista de software, labora en empresa

que presta servicios para la gestión de

PQRS, con conocimiento sobre el

proceso a realizar en el proyecto.

Lider de proyecto (Scrum

master)

Viviana garay Tecnóloga en sistematización de datos y

estudiante de ingeniería en telemática.

Desarrollador Viviana Garay

Jeyson Arévalo

Tecnólogos en sistematización de datos

y estudiantes de ingeniería en

telemática.

Tester A. Luis Sanabria

B. Camilo

Pinzón

A. Tecnólogo en sistematización de

datos y estudiante de ingeniería en

telemática.

B. Ingeniero de Sistemas.

2.1.2 Lista preliminar de actividades por rol

Tabla 3 .Lista preliminar de actividades por rol

Informar y colaborar con la elaboración de

los Backlogs del producto

Usuario

Solucionar inquietudes sobre el debido

proceso funcional del producto

Apoyar la elaboración de los casos de

prueba para el producto

Realizar seguimiento a cada una de las

etapas del proyecto

Líder de proyecto

25

Asignar tiempos de diseño, pruebas y

construcción a cada Sprint de desarrollo

Asignar actividades y tareas a cada

miembro del proyecto

Verificar permanentemente el estado de

las actividades y tareas programadas

Convocar y orientas las reuniones del

proyecto

Realizar el análisis para cada Sprint de

desarrollo

Desarrollador

Realizar el diseño de cada Sprint de

desarrollo

Realizar el desarrollo de cada Sprint

Realizar las pruebas de construcción para

cada Sprint de desarrollo

Realizar la integración de cada

componente del sistema

Realizar las pruebas funcionales de cada

Sprint de desarrollo

Tester

2.1.3 Lista preliminar de Backlogs de producto

Tabla 4. Backlogs de producto

Nombre Descripción

Recibir radicación Crear la recepción del documento a radicar.

Enviar radicación Crear las radicaciones correspondientes al documento que se va a enviar.

Interna radicación Gestionar el manejo de las radicaciones internas a nivel de la entidad.

Consultar radicación Consultar y realizar seguimiento a las radicaciones.

Digitalizar radicación Permitir anexar documentos a las radicaciones.

26

Planilla recolección Permitir realizar la recolección de los documentos que se van a entregar.

Autorecolección (Rad) Permitirla recopilación de lo radicado hasta el momento de realizar la auto recolección.

Autorecolección (Dep) Permitirla recopilación de lo radicado por dependencia hasta el momento de realizar la autorecolección.

Despacho Interno de

radicación

Descargar los documentos que van a ser entregados a las entidades internas.

Despacho Externo de

radicación

Descargar los documentos que van a ser entregados a las entidades externas.

Editar plantilla de

radicación

Permitir editar planilla de radicación si no la ha recibido la entidad a la que va dirigida.

Recibir Planilla de

proceso

Recibir planillas pendientes por recibir.

Asignar zona Asignar zona antes de realizar el despacho externo.

Novedades proceso Permite registrar el motivo de los rechazos de las radicaciones.

Reenviar proceso Permitir trasladar un documento de la dependencia destino hacia otra dependencia

Asignar responsable de

proceso

Permitir asignar a cada uno de los usuarios responsables del trámite los documentos recibidos

Consultar Recibidas Consultar las radicaciones recibidas.

Consultar pendientes Consultar las radicaciones pendientes.

Consulta seguimiento Realizar Seguimiento a las radicaciones.

Archivadas/Respondidas

de seguimiento

Consultar radicaciones a las cual se le han dado respuesta.

Perfiles Permitir habilitar permisos de actualización y accesos a la aplicación

Usuarios Gestionar en el sistema los datos personales de quien tiene acceso al aplicativo y la relación de usuario por dependencia que motiva la queja o reclamo.

Dependencia Gestionar las dependencias de la entidad de una entidad.

Seccional Gestionar las seccionales de la empresa.

Entidad externa Gestionar las entidades externas a las que se dirigen las radicaciones de salida.

27

Cambiar contraseña Gestionar el cambio de contraseña al usuario que ingresa al aplicativo para mayor seguridad.

Tipo usuarios Gestionar tipos de usuarios que operan en la entidad.

Tipo identificación Gestionar nuevos tipos de identificación de usuarios.

Tipo radicación Gestionar nuevos tipos de identificación de usuarios.

Tipo planilla Gestionar los tipos de radicación.

Tipo documental Gestionar los tipos documentales de una entidad.

Tipo de Envío/Recibo Gestionar los tipos de los medios de envió y recibido.

Tipo de tramite/Acción Gestionar los tipos de trámite de la radicación.

Prioridad Gestionar los tipos de prioridades de la radicación.

Actividad Gestionar actividades realizadas al momento de realizar la radicación.

Zonas Gestionar las zonas a las que se dirige las radicaciones de salida.

Novedades Gestionar las novedades que se presentan al momento de la respuesta de la radicación.

Países Gestionar países que definen el origen de las entidades.

Departamentos Gestionar los Departamentos de cada país de origen.

Municipios Gestionar los municipios de cada departamento de origen.

Reporte de radicaciones

realizadas

Generar reporte de radicaciones realizadas.

Reporte de Entradas x

Documental

Generar reporte de radicaciones de entrada por

documento.

Reporte de

Radicaciones x

dependencia destino

Generar reporte de radicaciones por dependencia

destino.

Reporte de radicaciones

enviadas

Generar reporte de radicaciones enviadas.

28

2.1.4 Backlogs de producto por sprints de desarrollo

Tabla 5 .Backlogs de producto por sprints de desarrollo

Sprint N.1 Mantenimiento Perfiles

Usuarios

Dependencia

Seccional

Entidad externa

Cambiar contraseña

Sprint N.2 Referencias Tipo usuarios

Tipo identificación

Tipo radicación

Tipo planilla

Tipo documental

Tipo de Envío/Recibo

Tipo de tramite/Acción

Prioridad

Actividad

Zonas

Novedades

Países

Departamentos

Municipios

Sprint N.3 Radicación Recibir

Enviar

Interna

Consultar radicación

Digitalizar

Sprint N.4 Despacho Planilla recolección

Autorecoleccion (Rad)

Autorecoleccion (Dep)

Despacho Interno

Despacho Externo

29

Editar plantilla

Sprint N.5 Proceso Recibir Planilla

Asignar zona

Novedades

Reenviar

Asignar responsable

Consultar Recibidas

Consultar pendientes

Sprint N.6 Seguimiento Consulta seguimiento


Sprint N.7 Reportes Radicaciones realizadas

Entradas x Documental

Rad x Dep Destino

Enviadas

2.2 DEFINICIÓN DEL SPRINT NÚMERO 1

Tabla 6. Definición sprint Número 1

Sprint N. 1 Nombre Mantenimiento

Objetivo Administrar y realizar mantenimiento de los parámetros del sistema

Detalle de sprint

Crear las pantallas que permitan administrar las siguientes opciones:

Perfiles

Usuarios

Dependencia

Seccional

Entidad externa

Cambiar contraseña

Criterios de aceptación

Debe existir una pantalla para cada opción

En cada pantalla se debe permitir: o Consultar o Insertar o Borrar o Modificar

Cada opción debe poderse administrar solo para los perfiles que tenga asociados

30


Tabla 7. Definición del sprint Número 2

Sprint N. 2 Nombre Referencias

Objetivo Administrar las opciones de referencia del sistema

Detalle de sprint


Tipo usuarios

Tipo identificación

Tipo radicación

Tipo planilla

Tipo documental

Tipo de Envío/Recibo

Tipo de tramite/Acción

Prioridad

Actividad

Zonas

Novedades

Países

Departamentos

Municipios



En cada pantalla se debe permitir: o Consultar o Insertar o Borrar o Modificar




Sprint N. 3 Nombre Radicaciones

Objetivo Administrar las opciones de las radicaciones de PQRS

Detalle de sprint


Recibir

Enviar

Interna

31

Consultar radicación

Digitalizar



En cada pantalla se debe permitir: o Recibir: Crear la recepción del documento a radicar. o Enviar: Crear las radicaciones correspondiente al

documento que se va a enviar. o Interna: Gestionar el manejo de las radicaciones

internas a nivel de la entidad. o Consultar radicación: Consultar y realizar

seguimiento a las radicaciones. o Digitalizar: Permitir anexar documentos a las

radicaciones.




Sprint N. 4 Nombre Despacho

Objetivo Administrar las opciones de despacho de PQRS

Detalle de sprint


Planilla recolección

Autorecoleccion (Rad)

Autorecoleccion (Dep)

Despacho Interno

Despacho Externo

Editar plantilla



En cada pantalla se debe permitir: o Planilla recolección: Permitir realizar la recolección

de los documentos que se van a entregar. o Autorecoleccion (Rad): Permitir la recopilación de lo

radicado hasta el momento de realizar la autorecoleccion.

o Autorecoleccion (Dep): Permitir la recopilación de lo radicado por dependencia hasta el momento de realizar la autorecoleccion.

o Despacho Interno: Descargar los documentos que van a ser entregados a las entidades internas.

32

o Despacho Externo: Descargar los documentos que van a ser entregados a las entidades externas.

o Editar plantilla: Permitir editar planilla de radicación si no la ha recibido la entidad a la que va dirigida.




Sprint N. 5 Nombre Proceso

Objetivo Administrar las opciones del proceso de PQRS

Detalle de sprint


Recibir Planilla

Asignar zona

Novedades

Reenviar

Asignar responsable

Consultar Recibidas

Consultar pendientes



En cada pantalla se debe permitir: o Recibir Planilla: Recibir planillas pendientes por

recibir. o Asignar zona: Asignar zona antes de realizar el

despacho externo. o Novedades: Permite registrar el motivo de los

rechazos de las radicaciones. o Reenviar: Permitir trasladar un documento de la

dependencia destino hacia otra dependencia o Asignar responsable: Permitir asignar a cada uno de

los funcionarios responsables del trámite los documentos recibidos

o Consultar Recibidas: Consultar las radicaciones recibidas.

o Consultar pendientes: Consultar las radicaciones pendientes.


33



Sprint N. 6 Nombre Seguimiento

Objetivo Administrar las opciones de seguimiento de PQRS

Detalle de sprint


Consulta seguimiento




En cada pantalla se debe permitir: o Consulta seguimiento: Realizar Seguimiento a las

radicaciones. o Archivadas/Respondidas: Consultar radicaciones a

las cual se le han dado respuesta.




Sprint N. 7 Nombre Reportes

Objetivo Generación de los reportes de PQRS

Detalle de sprint


Radicaciones realizadas

Entradas x Documental

Rad x Dep Destino

Enviadas



Se deben generar los reportes con la información requerida para:

o Radicaciones realizadas o Radicaciones de entrada por documento o Radicaciones por dependencia destino o Radicaciones enviadas


34

3. FASE DE DISEÑO

3.1 DISEÑO DE DESARROLLO DEL SPRINT NÚMERO 1

Base de datos

- Se requiere la creación de un repositorio para gestionar la información de cada una de las

siguientes opciones:

o Perfiles

o Usuarios

o Dependencia

o Seccional

o Entidad externa

o Cambiar contraseña

Transacciones

- Se requiere la construcción de una pantalla por cada una de las opciones, con los

siguientes diseños:

o Perfiles

o Usuarios

o Dependencia

o Seccional

o Entidad externa

o Cambiar contraseña


Base de datos

- Se requiere la creación de un repositorio para gestionar la información de las siguientes

opciones:

o Tipo usuarios

o Tipo identificación

o Tipo radicación

o Tipo planilla

o Tipo documental

35

o Tipo de Envío/Recibo

o Tipo de tramite/Acción

o Prioridad

o Actividad

o Zonas

o Novedades

o Países

o Departamentos

o Municipios

Transacciones



o Tipo usuarios

o Tipo identificación

o Tipo radicación

o Tipo planilla

o Tipo documental

o Tipo de Envío/Recibo

o Tipo de tramite/Acción

o Prioridad

o Actividad

o Zonas

o Novedades

o Países

o Departamentos

o Municipios


Base de datos



36

o Recibir

o Enviar

o Interna

o Consultar radicación

o Digitalizar

Transacciones



o Recibir

o Enviar

o Interna

o Consultar radicación

o Digitalizar


Base de datos



o Planilla recolección

o Autorecoleccion (Rad)

o Autorecoleccion (Dep)

o Despacho Interno

o Despacho Externo

o Editar plantilla

Transacciones



o Planilla recolección o Autorecoleccion (Rad) o Autorecoleccion (Dep) o Despacho Interno o Despacho Externo o Editar plantilla

37


Base de datos



o Recibir Planilla o Asignar zona o Novedades o Reenviar o Asignar responsable o Consultar Recibidas o Consultar pendientes

Transacciones



o Recibir Planilla o Asignar zona o Novedades o Reenviar o Asignar responsable o Consultar Recibidas y pendientes


Base de datos



o Consulta seguimiento o Archivadas/Respondidas

Transacciones



o Consulta seguimiento

o Archivadas/Respondidas

38


Transacciones

- Se requiere la construcción de un reporte por cada una de las opciones, con el siguiente

diseño:

4 FASE DE DESARROLLO

4.1 RESUMEN DE REUNIONES SPRINT NÚMERO 1

Tabla 13. Resumen de reuniones Número 1

Fecha: 2014-09-30

Participantes:

Usuario

Líder de proyecto

Comentarios:

Definición de Sprint

Fecha: 2014-10-06

Participantes:

Desarrollador

Líder de proyecto

Comentarios:

Revisión de diseño del sprint

Fecha: 2014-10-20

Participantes:

Desarrollador

Líder de proyecto

Comentarios:

Revisión de desarrollo finalizado

Fecha: 2014-10-27

Participantes:

Tester

Desarrollador

Líder de proyecto

Comentarios:

Revisión de casos de prueba satisfactorios

39



Fecha: 2014-11-04

Participantes:

Usuario

Líder de proyecto

Comentarios:


Fecha: 2014-11-11

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2014-11-24

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 201-12-02

Participantes:

Usuario

Tester

Desarrollador

Líder de proyecto

Comentarios:




Fecha: 204-12-12

Participantes:

Usuario

Líder de proyecto

Comentarios:


40

Fecha: 2014-12-17

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-01-13

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-01-20

Participantes:

Usuario

Tester

Desarrollador

Líder de proyecto

Comentarios:




Fecha: 2015-02-03

Participantes:

Usuario

Líder de proyecto

Comentarios:


Fecha: 2015-02-09

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-02-25

Participantes:

41

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-03-05

Participantes:

Usuario

Tester

Desarrollador

Líder de proyecto

Comentarios:




Fecha: 2015-03-11

Participantes:

Usuario

Líder de proyecto

Comentarios:


Fecha: 2015-03-16

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-04-07

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-04-15

Participantes:

Usuario

Tester

42

Desarrollador

Líder de proyecto

Comentarios:




Fecha: 2015-05-08

Participantes:

Usuario

Líder de proyecto

Comentarios:


Fecha: 2015-0513

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-05-28

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-06-09

Participantes:

Usuario

Tester

Desarrollador

Líder de proyecto

Comentarios:


43



Fecha: 2015-06-18

Participantes:

Usuario

Líder de proyecto

Comentarios:


Fecha: 2015-06-24

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-07-08

Participantes:

Desarrollador

Líder de proyecto

Comentarios:


Fecha: 2015-07-15

Participantes:

Usuario

Tester

Desarrollador

Líder de proyecto

Comentarios:


44

5. FASE DE PLANIFICACIÓN DE INFRAESTRUCTURA

5.1. DISEÑO LÓGICO DE LA RED

5.1.1. Diseño de la topología de la red

Modelo Jerárquico:

El esquema está compuesto por tres capas (Core, Distribución y Acceso). Se usara una capa de

distribución para cada planta de las diferentes sedes, el esquema debe implementarse de la misma

manera en todas las sedes.

Figura 8. Diseño de topología de red

5.1.2. Diseño modelo asignación de dirección.

En cada sede se debe implementar el siguiente modelo de asignación de dirección:

Direccionamiento IP clase C

Net Principal: 192.168.0.1

Mascara: 255.255.255.0

45

Tabla 20. Asignación de direcciones IP

subred Dirección Máscara Mascara Rango asignable Broadcast

A 192.168.0.0 / 26 255.255.255.192 192.168.0.1 - 192.168.0.62 192.168.0.63

B 192.168.0.64 / 26 255.255.255.192 192.168.0.65 - 192.168.0.126 192.168.0.127

C 192.168.0.128 / 26 255.255.255.192 192.168.0.129 - 192.168.0.190 192.168.0.191

D 192.168.0.192 / 26 255.255.255.192 192.168.0.193 - 192.168.0.254 192.168.0.255

NOTA: Los computadores portátiles tendrán IP dinámica.

5.1.3. Protocolos.

Dentro de los protocolos de enrutamiento existentes, se decide usar EIGRP, debido a que este es

propiedad de Cisco, y esta es la marca elegida de los equipos activos en red dentro del diseño

propuesto.

Este protocolo tiene las siguientes tablas:

Tabla de vecinos: enumera los routers inmediatamente siguientes desde el punto actual.

Tabla de topología: enumera las tablas de vecinos recibidas de los routers inmediatamente

siguientes.

Tabla de encaminamiento: contiene la ruta más óptima entre el origen y el destino para

transmitir datos.

Dentro de EIGRP se utiliza un protocolo llamado RTP, que dentro de la capa de transporte de OSI

se encarga de entregar de manera secuencial y ordenada los paquetes a los vecinos adscritos a la

tabla de vecinos.

5.1.4. Estrategia de seguridad de la red.

En el modelo de seguridad se delimitan las zonas públicas y protegidas de la siguiente manera:

Zona Pública, Cada sede se conecta remotamente a la sede principal. Se realiza conexión

mediante los firewall de cada uno.

Zona desmilitarizada, se encuentran un router que conectan la zona pública hacia el firewall y

obtener acceso a la zona protegida; igualmente se conecta a los servidores Web, y el de

Proxy, se debe estudiar la posibilidad de adicionar redundancia de firewalls.

46

Zona protegida, Existe acceso privado a los diferentes servidores: Aplicaciones, BD, Archivos.

Además de los switches que distribuyen a las estaciones de la red con acceso a los equipos de

la sede principal.

Figura 9. Diseño de seguridad en la red

5.1.5. Estrategia de gestión de la red.

Se implementaran herramientas de Cisco para gestionar dicho esquema ya que los dispositivos

que se utilizaran son de dicho proveedor. La suite de herramientas es CiscoWorks, los siguientes

son los módulos para las diferentes áreas de gestión:

CiscoWorksDeviceFaultAdministrator: Detección de fallos en los dispositivos.

CiscoWorks Campus Administrator: Administra las capas física y lógica de la red, las

VLAN, y el mapeo de la topología.

CiscoWorksResource Manager Esentials: Realiza un inventario de los dispositivos

existentes en la topología de la entidad.

CiscoWorksInternetwork Performance Monitor: Realiza un análisis del tráfico de red y

almacena un consolidado histórico de los problemas de tráfico y conectividad de la misma.

CiscoWorksCiscoView: Visualiza cada equipo activo en red, y sus parámetros, para

configurarlos, sin configurar el dispositivo por aparte.

CiscoWorksHealth and Utilization Monitor: Verifica la salud y el estado de integridad de los

dispositivos utilizados y el nivel de utilización de los recursos utilizados del sistema.

47

Como son muchas estaciones de usuario final existente, se debe centralizar el soporte remoto para

cada una. Se propone instalar algún software para realizar el soporte remoto en cada estación.

Se deben incluir las políticas de seguridad orientadas al usuario final, para garantizar integridad y

seguridad en la estructura de la red y la información.

Mantener un tráfico buena calidad y sin paquetes responsables de congestionar la red, se debe

restringir el acceso a sitios que no estén en el contexto laboral de la empresa (redes sociales, chat

y comercio).

En cuanto a los medios de almacenamiento externos, es importante que los equipos tengan

restricción para realizar copias, para prevenir que la información la manipulen personas no

autorizadas o indebidas.

5.2. DISEÑO FÍSICO DE LA RED

Los siguientes equipos hardware son los requeridos en cada sede de la entidad para la

infraestructura de red LAN

Tabla 21. Dispositivos

Tipo de equipo Cantidad Modelo Comentarios

Router Cisco 1 Cisco SPA122 ATA

Core central

Switch Cisco 1 por planta Cisco SF300-48P

Distribución para cada segmento

Switch Cisco 1 por sección 4500 Acceso cada estación

El siguiente es el cableado requerido para cada sede de la entidad.

Tabla 22. Cableado

N° DESCRIPCION

Subsistema de Puestos de Trabajo y Cableado Horizontal

1 Suministro e instalación de Cable FTP Cat 6A

2 Suministro e instalación de Tomas RJ 45 Cat. 6A con su respectivaFacePlate

48

3 Suministro e Instalación de PatchCord de 3 m Cat 6A

Subsistema de Administración

1 Suministro e Instalación de Patch Panel de 48 Puertos Cat. 6 A

3 Suministro e instalación de PatchCord de 1 m

4 Suministro e Instalación de Organizadores Horizontales

5 Suministro e Instalación de Organizadores Verticales

6 Gabinete de 1.80 m con multitoma, ventiladores

7 Adecuación gabinetes de comunicaciones existentes

8 Sistema de bonding/grounding

9 Sistema de ventilación centros de cableado

Backbone de datos

1 Suministro e instalación de Cable STP Cat 6A

2 Suministro e Instalación de Patch Panel de 48 Puertos Cat. 6 A

Ducteria Y Canaletas

1 Suministro e instalación de Canaleta 12 x 5 Con División,

2 Suministro e instalación de Bandeja Portacables 20x8 con división.

3 Troqueles de datos

4 Troqueles eléctricos

5 Suministro e Instalación de Tubería EMT de 2" Con Accesorios.

6 Otros , obras civiles menores

Marcación y certificación

1 Marcaciones, Puntos de red, eléctricos, tableros y gabinetes.

2 Certificación de puntos

Los siguientes equipos hardware son los requeridos en cada sede de la entidad para la

infraestructura de red WAN

Tabla 23. Hardware para la infraestructura de red

Tipo de equipo Cantidad Modelo Comentarios

Router Cisco 1 Cisco SPA122 ATA

Firewall 1 Sede Principal y Sedes externas

49

6. FASE DE INTEGRACIÓN DEL SISTEMA

6.1. INFRAESTRUCTURA PARA EL PROTOTIPO DEL SISTEMA

El prototipo del sistema se implementara en la empresa SQLSOFTWARE Ltda. , que ha permitido

el uso de sus recursos para realizar la implementación y las pruebas pertinentes al proyecto.

6.1.1. Sucursales y espacios físicos

Figura 10. Sede Administrativa Bogotá

50

Figura 11. Sede Principal Bogotá (Infraestructura y Outsourcing)

Figura 12. Sede Principal Bogotá (Soporte técnico)

51

Figura 13. Sede de Producto Bogotá

6.1.2 Cableado:

Diagrama de red de la sede principal de SQLSOFTWARE, dividido en 3 capas: core, distribución y

acceso.

Figura 14. Diagrama de red sede principal

52

6.1.3 Seguridad:

Zona Pública, el departamento de producto se conecta remotamente a la sede principal.

Zona desmilitarizada, se encuentran un router que conectan la zona pública hacia el firewall y

obtener acceso a la zona protegida; igualmente se conecta a los servidores Web, y el de

Proxy.

Zona protegida, se encuentran los diferentes servidores: Aplicaciones, BD, Archivos. Además

de los switches que distribuyen a las estaciones de la red.

Figura 15. Seguridad en la red

6.1.4. Sesgos tecnológicos:

Los sesgos de la empresa en cuanto a equipos se inclina hacia la marca de equipos electrónicos

DELL, adicionalmente los dispositivos de red son CISCO.

Los mayores sesgos a nivel de software es que se maneja únicamente sistemas operativos

Windows (Server 2008, Server 2013, Windows 7), utilizando así mismo productos Microsoft.

53

6.1.5. Análisis y exigencias técnicas.

Internet: La empresa SQLSOFTWARE tiene dos servicios independientes uno del proveedor Claro

y uno de contingencia del proveedor UNE, Claro provee el servicio de correo corporativo.

Through: Para tener claridad en el tráfico de datos y algunos conceptos referentes de la red se

usamos la aplicación wireshark que permitire visualizar en diferentes esquemas la información, por

medio de tablas y graficas se realizara el sondeo de estadísticas pertinentes.

Eficiencia: En la implementación se pretende aumentar la cantidad de datos transmitidos por

paquetes y directamente en la red interna, lo cual permitirá un mayor tráfico de información usando

la menor cantidad de recursos y así mejorar la eficiencia en general.

Lantency: Durante la implementación se reduce el retardo producido por la demora en

la propagación y transmisión de paquetes, para mejorar el rendimiento del sistema implementado.

Response: Se garantiza que el lapso de tiempo que transcurre entre que un usuario hace una

petición a la red y la información pedida es recibida por éste debe ser consistente indistintamente

al tráfico que posea la red.

Escalabilidad: La red soporta el cambio y adición de usuarios que la acceden de acuerdo al

crecimiento corporativo sin presentar problemas de rendimiento. La capacidad de expansión en un

entorno de producción se integra sin problemas.

Características:

Rendimiento constante durante los picos de tráfico

Alta disponibilidad de los sistemas.

Escalabilidad y capacidad de expansión.

Gestión: Se tiene control sobre:

Administración del Desempeño.

Administración de Fallas

Administración de la Configuración.

54

Administración de la Seguridad.

Administración de la Contabilidad.

Seguridad: Validar el mecanismo de seguridad para la protección de la red, para no poner la

empresa en algún riesgo.

Políticas de Seguridad: Dados los riesgos en cuanto a seguridad se determinaran las políticas de

seguridad a implementar. Las políticas necesarias en el diseño de la red son:

Políticas de uso aceptable.

Políticas de cuentas de usuario.

Políticas de configuración de routers.

Políticas de listas de acceso.

Políticas de acceso remoto.

Políticas de contraseñas.

Políticas de respaldos.

Cada política y procedimiento debe tener una sección que defina su aplicabilidad.

Las políticas de información definen qué información es confidencial y cual es de

dominio público dentro de la organización, y cómo debe estar protegida esta misma.

Esta política está construida para cubrir toda la información de la organización.

Las políticas de uso de las computadoras extienden la ley en lo que respecta a quién

puede utilizar los sistemas de cómputo y cómo pueden ser utilizados.

Las políticas de uso de Internet y correo electrónico se incluyen con frecuencia en la

política más general del uso de las computadoras. La empresa debe dar conectividad a

Internet a sus empleados para que éstos puedan realizar sus labores con mayor

eficacia pero debe tener una aplicación que controle el tráfico de los empleados hacia

internet.

Disponibilidad: Reporte generado con el departamento de infraestructura posterior a la

implementación del sistema.

55

Figura 16.Disponibilidad de la red

6.1.6. Caracterización del tráfico de la red

Se utilizó la herramienta Wireshark para realizar el análisis de protocolos y ver todo el tráfico que

pasa a través de la red.

El monitoreo del tráfico se realizó durante un período de 5 días posteriores a la implementación del

sistema en jornada laboral, en horario comprendido desde las 8:30am hasta las 5:00 de la tarde.

El Anexo contiene la evidencia del análisis realizado, imágenes del tráfico promedio en

determinados periodos de tiempo durante el día.

56

El desempeño de la red se caracterizó utilizando los siguientes parámetros:

Cantidad de Tráfico: cantidad de información promedio que se transfiere a través del canal

de comunicación.

Figura 17. Tráfico en la red

Tasa de Transferencia: velocidad de transmisión que pasa por una línea de

telecomunicación.

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

1 2 3 4 5

GB

Día

Cantidad de trafico GB

57

Figura 18. Transferencia en la red

Porcentaje de Utilización: relación entre de tráfico medido al tráfico máximo que el puerto

puede administrar.

Figura 19. Tráfico en la red

0

500

1000

1500

2000

2500

3000

3500

1 2 3 4 5

Mb

ps

Día

Tasa de transferencia Mbps

0

0,2

0,4

0,6

0,8

1

1,2

1 2 3 4 5

% (

*10

0)

Día

% Utilización

58

El flujo de tráfico es más intenso durante la tarde, es mayor el flujo de datos en los

protocolos HTTP y TCP.

Se observan picos y variaciones en diversas horas del día, especialmente en el mediodía

y en horas de la tarde.

Las gráficas muestran estabilidad para los protocolos analizados (ARP, TCP, UDP, HTTP,

ETHERNET BROADCAST).

Se evidenció que la red es óptima debido a que el porcentaje de utilización no supera el

35%, lo que significa que la red no presenta ningún tipo de problema potencial que pudiese

afectar el tráfico, por lo tanto es una red estable, es decir se mantiene operativa,

independientemente de la cantidad de usuarios conectado a la misma.

El monitoreo continuo del tráfico de datos permite realizar una evaluación apropiada del

comportamiento de la red en tiempo real. Entre los parámetros recomendados para evaluar

están la cantidad de tráfico, la tasa de transmisión y el porcentaje de utilización. En

particular, la medición del tráfico en una red LAN.

De acuerdo al análisis de la medición del tráfico realizada, se recomienda para el

mejoramiento y mantenimiento de la red implementar una optimización de hardware y

cableado conservando parcialmente la estructura de la red, para mantener la estabilidad

mejorando su rendimiento.

6.1.7. Servicios

El sistema distribuido se compone por tres servidores:

Servidor de aplicaciones: Se despliega el componente de aplicación PQRS_1.0.war en los

servidores destinados para este propósito.

59

Figura 20. Despliegue en WebLogic

Figura 21. Despliegue en GlassFish

Figura 22. Despliegue en Tomcat

60

Servidor de base de datos: Se debe almacenar el componente de base de datos PQRS en el

servidor.

Figura 23. Servidor de base de datos

Servidor de archivos: Se deben almacenar los archivos digitalizados desde el componente de

aplicación en el componente PQRS_archivos

61

Figura 24. Servidor de archivos

Los servidores tendrán conexión permanente por medio de la red LAN suministrada para la

implementación del Sistema distribuido heterogéneo para la gestión de PQRS en entidades

públicas, se deben implementar mecanismos de seguridad para la autenticación y establecimiento

de sesiones entre cada uno de los componentes del sistema.

6.2. MODELO DE LA INTEGRACIÓN DEL SISTEMA

- Modelo de base de datos

En el diagrama de base de datos, se encuentra la estructura entidad relación para la

implementación del Sistema distribuido heterogéneo para la gestión de PQRS en entidades

públicas, como se muestra en la siguiente figura.

62

Figura 25. Modelo base de datos

- Diagrama de implementación

El en diagrama de implementación, se encuentra la interacción entre cada uno de los servidores

utilizados en el Sistema distribuido heterogéneo para la gestión de PQRS en entidades públicas,

como se muestra en la siguiente figura.

63

Figura 26. Diagrama de implementación

- Diagrama de componentes

En el diagrama de componentes, se encuentra cómo está estructurado el Sistema distribuido

heterogéneo para la gestión de PQRS en entidades públicas y la relación de cada uno de sus

componentes, como se muestra en la siguiente figura.

64

Figura 27. Diagrama de componentes

- Diagrama de integración

En el diagrama de integración, se encuentra la relación general de cada uno de los componentes

que interactúan en el Sistema distribuido heterogéneo para la gestión de PQRS en entidades

públicas, como se muestra en la siguiente figura.

65

Figura 28. Diagrama de integración

- Acceso al sistema y conexión Aplicación – BD

La pantalla de acceso al sistema y conexión de la aplicación es la ventana inicial del sistema y

permite el acceso y conexión de los usuarios que interactúan en el Sistema distribuido

heterogéneo para la gestión de PQRS en entidades públicas.

66

Figura 29. Acceso al sistema

- Prototipo de aplicación

Este diagrama de prototipo de aplicación es la plantilla principal utilizada en la implementación del

Sistema distribuido heterogéneo para la gestión de PQRS en entidades públicas.

Figura 30. Prototipo de aplicación

67

6.3. REUNIONES PARA LA INTEGRACIÓN DEL SISTEMA

Tabla 24. Reuniones para la integración del sistema

Fecha: 2015-07-21

Participantes:

Desarrollador

Líder de proyecto

Comentarios:

Revisión de diseño de la integración

Fecha: 2015-08-03

Participantes:

Desarrollador

Líder de proyecto

Comentarios:

Revisión de la integración finalizada

Fecha: 2015-08-10

Participantes:

Tester

Desarrollador

Líder de proyecto

Comentarios:


7. FASE DE PRUEBAS

Las pruebas se ejecutan de acuerdo al siguiente esquema de actividades.

Figura 31. Fase de pruebas

68

7.1 PRUEBAS DEL SPRINT NÚMERO 1

Tabla 25. Pruebas del sprint Número 1

Sprint N.1 Mantenimiento Responsable Estado

Pruebas de construcción Desarrollador OK

Prueba funcionales Tester OK

Pruebas de usuario (Criterios de aceptación) Usuario OK

PRUEBAS ¿Cumple?

Unitarias Funcionales

1 Las pantallas no tienen errores de ortografía en títulos, etiquetas, mensajes o cualquier otro texto

SI SI

2 Los campos tienen la longitud adecuada para insertar el número de caracteres necesarios

SI SI

3 Las pantallas poseen buena navegabilidad (navega a los campos correctos)

SI SI

4 Las pantallas de valores muestra los registros correctamente

SI SI

5 Los mensajes de error son coherentes con el error del que se informa

SI SI

6 Las formas permite insertar datos SI SI

7 Los datos fueron insertados en la(s) tabla(s) correcta(s)

SI SI

8 Las formas permite consultar registros SI SI

9 Las formas permite modificar registros SI SI

10 Las formas permite eliminar registros SI SI

11 Los bloques multiregistro permiten navegación (cambiar de registro)

SI SI

12 Los botones de la forma funcionan correctamente

SI SI

13 Cumple los criterios de aceptación SI SI



Sprint N.2 Referencias Responsable Estado


69



PRUEBAS ¿Cumple?



SI SI


SI SI


SI SI


SI SI


SI SI



SI SI





SI SI


SI SI




Sprint N.3 Radicación Responsable Estado




PRUEBAS ¿Cumple?



SI SI

70


SI SI


SI SI


SI SI


SI SI



SI SI





SI SI


SI SI




Sprint N.4 Despacho Responsable Estado




PRUEBAS ¿Cumple?



SI SI


SI SI


SI SI

71


SI SI


SI SI



SI SI





SI SI


SI SI




Sprint N.5 Proceso Responsable Estado




PRUEBAS ¿Cumple?



SI SI


SI SI


SI SI


SI SI


SI SI


7 Los datos fueron insertados en la(s) SI SI

72

tabla(s) correcta(s)





SI SI


SI SI




Sprint N.6 Seguimiento Responsable Estado




PRUEBAS ¿Cumple?



SI SI


SI SI


SI SI


SI SI


SI SI



SI SI




11 Los bloques multiregistro permiten SI SI

73

navegación (cambiar de registro)


SI SI




Sprint N.7 Reportes Responsable Estado




PRUEBAS ¿Cumple?



SI SI


SI SI


SI SI


SI SI


SI SI



SI SI





SI SI

74


SI SI


7.8 PRUEBAS DE LA INTEGRACIÓN DEL SISTEMA

Tabla 32. Pruebas de la integración del sistema

Sprint N.8 Integración del sistema Responsable Estado



PRUEBAS ¿Cumple?

Construcción Funcionales

1 La aplicación despliega y funciona correctamente en la plataforma JAVA indiferente al sistema operativo en la que se encuentra y en cada uno de los servidores de aplicaciones usados

SI SI

2 La conexión con BD es correcta e indiferente al sistema operativo en el que esta se encuentre

SI SI

3 Se tiene acceso al servidor de archivos desde la aplicación en las opciones relacionadas

SI SI

4 El tiempo de respuesta de las terminales que acceden a la aplicación es satisfactorio, respecto a cada una de las transacciones

SI SI

5 El manejo de permisos sobre los objetos de base de datos es correcto

SI SI

6 El manejo de perfiles en la aplicación es correcto

SI SI

75

8. CONCLUSIONES

El desarrollo del proyecto ha mostrado que a partir de las orientaciones y recursos disponibles, un

grupo de estudiantes con un buen nivel de formación, altamente motivados, trabajando de forma

coordinada y colaborativa, un grupo de docentes capacitados y con la experiencia para apoyar el

proceso, se logra generar los suficientes mecanismos para apoyarse mutuamente y llevar a cabo el

proyecto de manera exitosa.

La culminación del proyecto demuestra que bajo una metodología ágil, se contribuye a la

comprensión de un diseño base y la organizaron de tiempo que es pertinente para la realización de

una construcción que cumpla con las necesidades requeridas en cada backlog y su clasificación en

sprints altamente relacionados.

La experiencia muestra que para la construcción de cada uno de los módulos y cada componente

del sistema distribuido se exponen los conocimientos que se adquirieron en diferentes asignaturas

cursadas en el transcurso de la carrera, igualmente incentivó a la investigación para desarrollar

aspectos en los cuales no se tenía la experiencia necesaria para el desarrollo de determinados

componentes.

La implementación de un sistema distribuido garantiza una mejor organización, relación, validación

y seguridad en el manejo de la información contenida en los procesos de PQRS.

El Sistema Distribuido Heterogéneo Para La Gestión De PQRS En Entidades Públicas aportara

gran cantidad de beneficios a las entidades que requieren una modernización en su proceso,

teniendo un ambiente tecnológico y ante todo efectivo, seguro y óptimo.

76

9. RECOMENDACIONES

Es importante capacitar a cada uno de los usuarios del “Sistema Distribuido Heterogéneo Para La

Gestión De PQRS En Entidades Públicas”, de tal manera que se haga un buen uso de cada

componente del garantizando un servicio de calidad y oportuno.

Se deben programar jornadas periódicas de actualización de datos, esencialmente en lo que tiene

que ver con la información paramétrica, considerando los nuevos usuarios y el cambio de roles que

tienen los existentes.

Referente a la información, debe ser administrada en cada entidad por alguna autoridad de área,

departamento o sección y se recomienda que ésta sea revisada continuamente de manera que se

pueda garantizar un excelente servicio y una información actual y confiable.

Un aspecto importante va dirigido a sus futuros desarrolladores, de ser requerida la realización de

cambios o la ampliación del alcance del “Sistema Distribuido Heterogéneo Para La Gestión De

PQRS En Entidades Públicas” continuar con la utilización de los estándares de diseños que fueron

implementados en el desarrollo inicial, dejar evidencia de los cambios realizados y generar una

nueva versión para garantizar el correcto funcionamiento acorde a cada entrega del producto.

77

10. FUENTES DE INFORMACIÓN

- Rising, L., Janoff. The Scrum Software Development Process For Small Teams. 2000.

- Fernández Gil, Paloma. Manual de Organización de Archivos de Gestión en las Oficinas Municipales.

Granada: CEMCI, 1999.

- INSTITUTO COLOMBIANO DE NORMAS TECNICAS Y CERTIFICACIÓN. Sistema de Gestión de la

Calidad NTCGP 1000:2009. Bogotá D.C. El Instituto. 2009

- Archivo General de la Nación. Manual para la implementación de un programa de gestión

documental. Bogotá, 2014. Disponible en:

http://www.archivogeneral.gov.co/sites/all/themes/nevia/PDF/SINAE/Productos%20SINAE%202013/P

GD2.pdf

- Vásquez, Manuel. Manual de Selección Documental. Santafé de Bogotá: Archivo General de la

Nación de la Republica de Colombia, 1995.

- Roger S. Presuman. Ingeniería de Software. Séptima Edición. McGraw-Hill Interamericana. Madrid.

2014.

- George Coulouris, Jean Dollimore, Tim Kindberg y Gordon Blair. Sistemas Distribuidos, conceptos y

diseño. Quinta edición. Addison Wesley. 2011

- Procedimiento para recibir, tramitar y resolver peticiones, quejas y reclamos. 2013. Disponible en:

http://sig.ucaldas.edu.co/gestionDocumental/vistaDetalleProcedimiento.php

- Tanenbaum, Andrew S. Redes de computadoras. Quinta edición. Pearson. 2012

- Documentación Oracle, http://www.oracle.com/technetwork/es/documentation/index.html

- Documentación GlassFish, https://glassfish.java.net/es/public/devindex.html

- Documentación WebLogic,

http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.html

- Documentación Tomcat , http://tomcat.apache.org/tomcat-7.0-doc/

- Documentación Wireshark, https://www.wireshark.org/docs/

- Documentación Availability Report, https://docs.newrelic.com/docs/apm/reports/other-

performance-analysis/availability-report

http://www.monografias.com/trabajos14/historiaingenieria/historiaingenieria.shtml

http://www.monografias.com/trabajos901/nuevas-tecnologias-edicion-montaje/nuevas-tecnologias-edicion-montaje.shtml

http://www.monografias.com/trabajos901/historia-madrid/historia-madrid.shtml

SISTEMA DISTRIBUIDO HETEROGÉNEO PARA LA GESTIÓN DE...

Documents

Transcript of SISTEMA DISTRIBUIDO HETEROGÉNEO PARA LA GESTIÓN DE...