Garay Gonzalez Lady Vivian A 2016

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.
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
1
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.
2
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.
3
- 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.
4
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.
5
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.
6
 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.
7
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
8
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.
9
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
10
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.
11
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
12
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

Programación por capas,http://oasis.cisc-ug.org/letzhune/Programacion%20por%20capas.doc
3
13
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
14
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/
15
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
16
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>
17
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
18
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:
19
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
20
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
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
21
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
22
1.10 CRONOGRAMA DE ACTIVIDADES
 Fecha inicio: 8 de Agosto de 2014

 Total semanas: 3 de Agosto de 2015
Figura 7.Cronograma de actividades
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 Viviana garay Tecnóloga en sistematización de datos y
master) estudiante de ingeniería en telemática.
Desarrollador Viviana Garay Tecnólogos en sistematización de datos
Jeyson Arévalo y estudiantes de ingeniería en
telemática.
Tester A. Luis Sanabria A. Tecnólogo en sistematización de
B. Camilo datos y estudiante de ingeniería en
Pinzón 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 Usuario

los Backlogs del producto
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 Líder de proyecto
etapas del proyecto
24
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 Desarrollador
desarrollo
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 Tester
Sprint de desarrollo
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.
25
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 Descargar los documentos que van a ser entregados a las
entidades internas.
radicación
Despacho Externo de Descargar los documentos que van a ser entregados a las
entidades externas.
radicación
Editar plantilla de Permitir editar planilla de radicación si no la ha recibido
la entidad a la que va dirigida.
radicación
Recibir Planilla de Recibir planillas pendientes por recibir.
proceso
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 Permitir asignar a cada uno de los usuarios responsables

del trámite los documentos recibidos
proceso
Consultar Recibidas Consultar las radicaciones recibidas.

Consultar pendientes Consultar las radicaciones pendientes.
Consulta seguimiento Realizar Seguimiento a las radicaciones.
Archivadas/Respondidas Consultar radicaciones a las cual se le han dado
respuesta.
de seguimiento
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.
26
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 Generar reporte de radicaciones realizadas.
realizadas
Reporte de Entradas x Generar reporte de radicaciones de entrada por
Documental documento.
Reporte de Generar reporte de radicaciones por dependencia
Radicaciones x destino.
dependencia destino
Reporte de radicaciones Generar reporte de radicaciones enviadas.
enviadas
27
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
28
Editar plantilla
Sprint N.5 Proceso Recibir Planilla
Asignar zona
Novedades
Reenviar
Asignar responsable
Consultar Recibidas
Consultar pendientes
Sprint N.6 Seguimiento Consulta seguimiento
Archivadas/Respondidas
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
29
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
o Consultar
o Insertar
o Borrar
o Modificar
que tenga asociados
Sprint N. 3 Nombre Radicaciones

Objetivo Administrar las opciones de las radicaciones de PQRS
Detalle de sprint
 Recibir
 Enviar
 Interna
30
 Consultar radicación
 Digitalizar
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.
que tenga asociados
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
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.
31
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.
que tenga asociados
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
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.
que tenga asociados
32
Sprint N. 6 Nombre Seguimiento

Objetivo Administrar las opciones de seguimiento de PQRS
Detalle de sprint
 Consulta seguimiento
 Archivadas/Respondidas
o Consulta seguimiento: Realizar Seguimiento a las
radicaciones.
o Archivadas/Respondidas: Consultar radicaciones a
las cual se le han dado respuesta.
que tenga asociados
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
que tenga asociados
33
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
34
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

35
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
36
 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
37
 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
Comentarios:
Revisión de diseño del sprint
Fecha: 2014-10-20
Participantes:
 Desarrollador
Comentarios:
Revisión de desarrollo finalizado
Fecha: 2014-10-27
Participantes:
 Tester
 Desarrollador
Comentarios:
Revisión de casos de prueba satisfactorios
38
Fecha: 2014-11-04
Participantes:
 Usuario
Comentarios:
Fecha: 2014-11-11
Participantes:
 Desarrollador
Comentarios:
Fecha: 2014-11-24
Participantes:
 Desarrollador
Comentarios:
Fecha: 201-12-02
Participantes:
 Usuario
 Tester
 Desarrollador
Comentarios:
Fecha: 204-12-12
Participantes:
 Usuario
Comentarios:
39
Fecha: 2014-12-17
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-01-13
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-01-20
Participantes:
 Usuario
 Tester
 Desarrollador
Comentarios:
Fecha: 2015-02-03
Participantes:
 Usuario
Comentarios:
Fecha: 2015-02-09
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-02-25
Participantes:
40
 Desarrollador
Comentarios:
Fecha: 2015-03-05
Participantes:
 Usuario
 Tester
 Desarrollador
Comentarios:
Fecha: 2015-03-11
Participantes:
 Usuario
Comentarios:
Fecha: 2015-03-16
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-04-07
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-04-15
Participantes:
 Usuario
 Tester
41
 Desarrollador
Comentarios:
Fecha: 2015-05-08
Participantes:
 Usuario
Comentarios:
Fecha: 2015-0513
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-05-28
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-06-09
Participantes:
 Usuario
 Tester
 Desarrollador
Comentarios:
42
Fecha: 2015-06-18
Participantes:
 Usuario
Comentarios:
Fecha: 2015-06-24
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-07-08
Participantes:
 Desarrollador
Comentarios:
Fecha: 2015-07-15
Participantes:
 Usuario
 Tester
 Desarrollador
Comentarios:
43
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
44
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.
45
 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.
46
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 Core central
ATA
Switch Cisco 1 por planta Cisco SF300- Distribución para cada
48P 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
47
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
48
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á
49
Figura 11. Sede Principal Bogotá (Infraestructura y Outsourcing)
Figura 12. Sede Principal Bogotá (Soporte técnico)
50
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
51
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.
52
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.
53
 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.
54
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.
55
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
Cantidad de trafico GB
45000
40000
35000
30000
25000
GB
20000
15000
10000
5000
0
1 2 3 4 5
Día
 Tasa de Transferencia: velocidad de transmisión que pasa por una línea de

telecomunicación.
56
Figura 18. Transferencia en la red
Tasa de transferencia Mbps

3500
3000
2500
2000
Mbps
1500
1000
500
0
1 2 3 4 5
Día
 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
% Utilización
1,2
0,8
% (*100)
0,6
0,4
0,2
0
1 2 3 4 5
Día
57
 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.
58
Figura 20. Despliegue en WebLogic
Figura 21. Despliegue en GlassFish
Figura 22. Despliegue en Tomcat
59
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
60
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.
61
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.
62
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.
63
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.
64
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.
65
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
66
6.3. REUNIONES PARA LA INTEGRACIÓN DEL SISTEMA
Tabla 24. Reuniones para la integración del sistema
Fecha: 2015-07-21
Participantes:
 Desarrollador
Comentarios:
Revisión de diseño de la integración
Fecha: 2015-08-03
Participantes:
 Desarrollador
Comentarios:
Revisión de la integración finalizada
Fecha: 2015-08-10
Participantes:
 Tester
 Desarrollador
Comentarios:
7. FASE DE PRUEBAS
Las pruebas se ejecutan de acuerdo al siguiente esquema de actividades.
Figura 31. Fase de pruebas
67
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 SI SI
ortografía en títulos, etiquetas,
mensajes o cualquier otro texto
2 Los campos tienen la longitud adecuada SI SI
para insertar el número de caracteres
necesarios
3 Las pantallas poseen buena SI SI
navegabilidad (navega a los campos
correctos)
4 Las pantallas de valores muestra los SI SI
registros correctamente
5 Los mensajes de error son coherentes SI SI
con el error del que se informa
6 Las formas permite insertar datos SI SI
7 Los datos fueron insertados en la(s) SI SI
tabla(s) correcta(s)
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 SI SI
navegación (cambiar de registro)
12 Los botones de la forma funcionan SI SI
correctamente
13 Cumple los criterios de aceptación SI SI
Sprint N.2 Referencias Responsable Estado

68
PRUEBAS ¿Cumple?
necesarios
correctos)
correctamente
Sprint N.3 Radicación Responsable Estado

PRUEBAS ¿Cumple?
69
necesarios
correctos)
correctamente
Sprint N.4 Despacho Responsable Estado

PRUEBAS ¿Cumple?
necesarios
correctos)
70
correctamente
Sprint N.5 Proceso Responsable Estado

PRUEBAS ¿Cumple?
necesarios
correctos)
71
correctamente
Sprint N.6 Seguimiento Responsable Estado

PRUEBAS ¿Cumple?
necesarios
correctos)
72

correctamente
Sprint N.7 Reportes Responsable Estado

PRUEBAS ¿Cumple?
necesarios
correctos)


73
correctamente
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 SI SI
correctamente en la plataforma JAVA
indiferente al sistema operativo en la que
se encuentra y en cada uno de los
servidores de aplicaciones usados
2 La conexión con BD es correcta e SI SI
indiferente al sistema operativo en el que
esta se encuentre
3 Se tiene acceso al servidor de archivos SI SI
desde la aplicación en las opciones
relacionadas
4 El tiempo de respuesta de las terminales SI SI
que acceden a la aplicación es satisfactorio,
respecto a cada una de las transacciones
5 El manejo de permisos sobre los objetos de SI SI
base de datos es correcto
6 El manejo de perfiles en la aplicación es SI SI
correcto
74
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.
75
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.
76
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
77

Garay Gonzalez Lady Vivian A 2016

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Garay Gonzalez Lady Vivian A 2016

Caricato da

Copyright:

Formati disponibili

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

LADY VIVIANA GARAY GONZALEZ

JEYSON STITH AREVALO SANDOVAL

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

LADY VIVIANA GARAY GONZALEZ

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

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

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

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

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

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

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

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

1.2 PLANTEAMIENTO DEL PROBLEMA

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

1.2.2 Formulación del Problema:

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

1.4.1 Objetivo general

1.4.2 Objetivos específicos

1.5 MARCOS DE REFERENCIA

1.5.1 Marco teórico

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

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

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

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

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

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

Los problemas de este modelo son:

Figura 1. Tendencias Actuales de las arquitecturas de sistemas WEB

Figura 2. Variante de los fabricantes de Base de Datos

D. Ventajas de los sistemas distribuidos

Con respecto a Sistemas Centralizados:

Con respecto a PCs Independientes:

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

1.6 MARCO METODOLÓGICO

1.6.1 Metodología Scrum

Figura 4. Metodología SCRUM

1.6.3.1 Product backlog

1.6.3.2 Sprint backlog

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

1.6.3.3 Burn down chart

1.7 MARCO CONCEPTUAL

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

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

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

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

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

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

Componentes de una Base de Datos

Figura 5. Componentes de una Base de Datos

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

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

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

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

1.8 MARCO LEGAL

1.9.1 Factibilidad Técnica:

- Procesador: Intel Pentium 4 o AMD Semprom.

- Memoria RAM 512 Mb.

- Disco duro 5 Gb disponibles.

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