construcci on de un sistema de administraci on de documentos...

Construccion de un sistema deadministracion de documentos

mediante el uso de metodologıasagiles, para organizar los archivos

fısicos y digitales en CyzaOutsourcing S.A.

Jhon Jairo Roldan Caballero

Jorge Emilio Araque Gonzalez

Universidad Distrital Francisco Jose de Caldas

Especializacion en Ingenierıa de Software

Ciudad, Colombia

2016

Construccion de un sistema deadministracion de documentos

mediante el uso de metodologıasagiles, para organizar los archivos

fısicos y digitales en CyzaOutsourcing S.A.

Jhon Jairo Roldan Caballero

Jorge Emilio Araque Gonzalez

Trabajo de grado presentada(o) como requisito parcial para optar al tıtulo de:

Especialista en Ingenierıa de Software

Director(a):

Ingeniera Lilian Astrid Bejarano

Revisor(a):

Ph.D Edgar Jacinto Rincon

Universidad Distrital Francisco Jose de Caldas

Especializacion en Ingenierıa de Software

Ciudad, Colombia

2016

iv

Agradecimientos

A mi madre, fuente de apoyo constante e incondicional en toda mi vida y mas aun, en mis

duros anos de carrera y formacion profesional. Sin tu ayuda, cuidados, educacion y formacion

en valores, no me hubiera sido posible alcanzar logro alguno durante toda mi trayectoria

profesional y personal. A mi esposa amada, gracias por tu paciencia, comprension y apoyo

durante este trayecto; hoy hemos alcanzado un triunfo mas, por que los dos somos uno y

mis logros son los tuyos. A los docentes que me impartieron catedra durante el ultimo ano,

gracias por su esfuerzo y dedicacion, gracias por entregar oportunidades de vida a traves

de la educacion. Su paciencia y esmero en su labor son fuente de inspiracion y un referente

personal para ayudar a construir una mejor sociedad (JJRC).

Contenido

Agradecimientos IV

PARTE I 1

Introduccion 2

1. CONTEXTUALIZACION DEL PROYECTO 3

1.1. ESTUDIO DEL PROBLEMA DEL PROYECTO . . . . . . . . . . . . . . . 3

1.1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2. Formulacion del problema . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.3. Sistematizacion del problema . . . . . . . . . . . . . . . . . . . . . . 4

1.2. OBJETIVOS DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. JUSTIFICACION DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1. Justificacion practica . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. HIPOTESIS DE TRABAJO . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5. MARCO DE REFERENCIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.6. METODOLOGIA DE LA INGENIERIA . . . . . . . . . . . . . . . . . . . . 20

1.6.1. Programacion Extrema . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.7. ASPECTOS METODOLOGICOS . . . . . . . . . . . . . . . . . . . . . . . . 27

1.7.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.7.2. Metodo de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.7.3. Fuentes y tecnicas para la recoleccion de la informacion . . . . . . . . 27

1.7.4. Tratamiento de la informacion . . . . . . . . . . . . . . . . . . . . . . 28

1.8. ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS . . . . . . . 28

1.8.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.8.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.8.3. Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

PARTE II 3

vi Contenido

2. DESARROLLO DEL PROYECTO 31

2.1. Fase de levantamiento de datos . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.1. Identificacion de interesados . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.2. Historias de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.3. Levantamiento de requerimientos . . . . . . . . . . . . . . . . . . . . 36

2.2. Fase de planeacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2.1. Arquitectura empresarial . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.2.2. Capa de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.2.3. Capa de aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.4. Capa de infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.2.5. Capa de motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.2.6. Conclusion del proceso de arquitectura empresarial . . . . . . . . . . 46

2.2.7. Plan de proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . 46

2.2.8. Plan de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.2.9. Plan de Control de Cambios . . . . . . . . . . . . . . . . . . . . . . . 48

2.2.10. Plan de Cierre de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . 48

2.2.11. Estructura de Desglose de Trabajo (EDT) . . . . . . . . . . . . . . . 49

2.3. Fase de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.3.1. Modificacion modulo de control de acceso . . . . . . . . . . . . . . . . 51

2.4. Fase de Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.4.1. Historial de cambios . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

PARTE III 51

3. CIERRE DE LA INVESTIGACION 66

3.1. Resultados alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3. Prospectiva del trabajo de grado . . . . . . . . . . . . . . . . . . . . . . . . . 68

A. Anexo: Documentos de Requerimientos 70

A.0.1. Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . . . . 70

A.0.2. Requerimientos no funcionales . . . . . . . . . . . . . . . . . . . . . . 75

Bibliografıa 76

Lista de Tablas

2-1. Listado de interesados Sistema de Gestion Documental . . . . . . . . . . . . 31

2-2. Historia de Usuario DD-HU-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 32






2-8. Tabla de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2-9. Tabla de historial de cambios . . . . . . . . . . . . . . . . . . . . . . . . . . 65

A-1. Requerimiento REQ-FNC-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 70









A-10.Requerimiento REQ-NFN-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A-11.Requerimiento REQ-NFN-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Lista de Figuras

1-1. Diagrama de arquitectura de la aplicacion . . . . . . . . . . . . . . . . . . . 12

1-2. Diagrama logico de la capa de presentacion . . . . . . . . . . . . . . . . . . . 13

1-3. Representacion grafica de un namespace . . . . . . . . . . . . . . . . . . . . 14

1-4. Representacion grafica capa de negocio . . . . . . . . . . . . . . . . . . . . . 15

1-5. Esquema de Enterprise Library . . . . . . . . . . . . . . . . . . . . . . . . . 16

1-6. Entidad de negocio y mapeo . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1-7. Diagrama fısico de red y componentes de la aplicacion . . . . . . . . . . . . . 18

2-1. Punto de vista de proceso de negocio . . . . . . . . . . . . . . . . . . . . . . 39

2-2. Punto de vista de comportamiento de aplicacion . . . . . . . . . . . . . . . . 40

2-3. Punto de vista de uso de aplicacion . . . . . . . . . . . . . . . . . . . . . . . 42

2-4. Punto de vista de infraestructura . . . . . . . . . . . . . . . . . . . . . . . . 43

2-5. Punto de vista de capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2-6. Punto de vista de motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2-7. Diagrama de Representacion del proceso de desarrollo . . . . . . . . . . . . . 47

2-8. Estructura de desglose de trabajo propuesta . . . . . . . . . . . . . . . . . . 50

2-9. Enumeracion de modulos (codigo fuente) . . . . . . . . . . . . . . . . . . . . 51

2-10.Modulo de configuracion de procesos . . . . . . . . . . . . . . . . . . . . . . 53

2-11.Modulo de configuracion de subprocesos . . . . . . . . . . . . . . . . . . . . 54

2-12.Modulo de configuracion de actividades . . . . . . . . . . . . . . . . . . . . . 55

2-13.Pagina de seleccion de procesos y subprocesos . . . . . . . . . . . . . . . . . 56

2-14.Pagina de visualizacion de detalle de subproceso . . . . . . . . . . . . . . . . 56

2-15.Modulo de configuracion para registros documentales . . . . . . . . . . . . . 57

2-16.Modulo para configuracion de bitacoras . . . . . . . . . . . . . . . . . . . . . 58

2-17.Modulo de solicitud de consecutivos . . . . . . . . . . . . . . . . . . . . . . . 59

2-18.Modulo de cargue de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2-19.Modulo de especificacion de relaciones . . . . . . . . . . . . . . . . . . . . . 60

2-20.Modulo de versionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2-21.Retorno de uno de las operaciones del servicio web (JSON) . . . . . . . . . . 61

2-22.Modulo de consulta web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2-23.Aplicacion para moviles Android (Autenticacion y configuracion) . . . . . . . 63

2 Lista de Figuras

Introduccion

Hoy por hoy las empresas independientemente de su tipo tienen unos procesos definidos

que son tan complejos como la empresa lo requiera, estos se pueden agrupar en: procesos

operativos, administrativos, financieros, tecnologicos o de calidad segun las necesidades de

la companıa. Estos a su vez van a generar un recurso tanto o mas importante que los mismos

procesos: la documentacion. Los documentos se producen como elementos resultantes de eje-

cutar los procesos que la empresa ha definido. Tambien se pueden evidenciar en forma de

manuales que deben seguirse para cumplir una actividad o tambien son la evidencia tangible

del resultado de la ejecucion de las tareas realizadas. Los documentos pueden ser fısicos o

digitales, algunos de ellos pueden contener una firma digital que le dara la misma validez

legal que como si fuera impreso y firmado en tinta.

Conociendo la importancia de salvaguardar la informacion generada en sus procesos, Cyza

Outsourcing es una empresa joven que entiende la necesidad de tener un Sistema de Adminis-

tracion de Documentos no existente actualmente que le permita llevar control, seguimiento,

gestion y custodia de todo material fısico y digital producido al interior de la companıa y

se hace mas necesario en una etapa donde la empresa esta comenzando a integrar procesos.

Recientemente se ha dado forma a la Intranet que puede ser consultada de manera trans-

versal por cada dependencia pero ahora se quiere integrar un sistema que se encargue de

la manipulacion de la documentacion que cada area genera diariamente. Identificando esta

necesidad se pretende llevar a cabo el proceso necesario para construir el Sistema de Admi-

nistracion de Documentos para Cyza Outsourcing S.A.

1. CONTEXTUALIZACION DEL

PROYECTO

1.1. ESTUDIO DEL PROBLEMA DEL PROYECTO

1.1.1. Planteamiento del problema

Actualmente, la companıa Cyza Outsourcing S.A. esta experimentando una etapa de creci-

miento en todos los ambitos, debido a la expansion de sus actividades economicas. Durante

esta expansion, la gerencia decidio adoptar un sistema de gestion de calidad, el cual estable-

ce que se debe generar evidencia de las actividades descritas en el mismo. Dicha evidencia

se debe plasmar en los formatos de documentacion, los cuales son generados en forma de

archivos de computadora por los usuarios responsables de cada proceso. Es comun que estos

archivos sean difıciles de encontrar cuando se los requiere; tambien es habitual que estos se

encuentren almacenados en los computadores de cada usuario de forma local, haciendo difıcil

que esten disponibles para otros usuarios en determinados momentos.

Esta situacion, puede ser atribuida a la falta de lineamientos para el manejo de estos ar-

chivos por parte del departamento de calidad y de tecnologıa respectivamente; ademas de

la ausencia de herramientas informaticas dispuestas por la companıa para realizar tal labor.

Dicha situacion es corregida de manera temporal cuando se aproxima la auditorıa externa

cada ano, sin embargo, una vez esta finaliza y con el pasar del tiempo, el estado de desorga-

nizacion de los archivos que contienen los registros documentales vuelve a imperar.

Una alternativa propuesta para la solucion de este problema es la implementacion de un

modulo en la ya existente aplicacion de Intranet de la companıa, el cual permita cargar estos

archivos de forma facil al tiempo que permita llevar la trazabilidad de los mismos, mante-

nerlos bajo custodia y controlar su acceso, ası como permitir que puedan ser visualizados

desde cualquier computador conectado a la red de la companıa.

4 1 CONTEXTUALIZACION DEL PROYECTO

1.1.2. Formulacion del problema

¿Como desarrollar un Sistema de Administracion de Documentos que permita almacenar,

indexar y llevar la trazabilidad de los registros documentales exigidos por el sistema de

gestion de calidad y generados por los empleados de Cyza Outsourcing S.A.?

1.1.3. Sistematizacion del problema

¿Que metodologıa permite desarrollar de forma agil y en un menor tiempo la solucion de

software encaminada a la implementacion del Sistema de Administracion de Documentos?

¿Que plataforma de desarrollo es la correcta para realizar el diseno de una herramienta

informatica que ha sido sugerida como medio para almacenar, indexar y llevar la trazabilidad

de los archivos generados en Cyza Outsourcing?

1.2. OBJETIVOS DEL PROYECTO

1.2.1. Objetivo general

Desarrollar una herramienta de software que implemente las principales caracterısticas de

un Sistema de Administracion de Documentos, mediante el uso de metodologıas agiles, pa-

ra apoyar la gestion del ciclo de vida de los registros documentales en Cyza Outsourcing S.A.

1.2.2. Objetivos especıficos

Definir los requerimientos funcionales y no funcionales para la construccion del sistema

de administracion de documentos empleado los formatos definidos por el area de tec-

nologıa Cyza Outsourcing S.A., con el fin de estimar el tiempo y los recursos necesarios

para el desarrollo.

Seleccionar una metodologıa de desarrollo, por medio del analisis de los modelos agiles

que existen en la actualidad, que permita desarrollar el sistema de administracion de

documentos de forma rapida y eficiente acorde con los recursos dispuestos por Cyza

Outsourcing S.A. para tal fin.

Determinar la plataforma de desarrollo que debera ser empleada para la implementa-

cion del sistema de administracion de documentos mediante el analisis de las aplica-

ciones existentes y los lineamientos de desarrollo de Cyza Outsourcing S.A. con el fin

de garantizar la compatibilidad con los sistemas actuales.

1.3 JUSTIFICACION DEL PROYECTO 5

1.3. JUSTIFICACION DEL PROYECTO

1.3.1. Justificacion practica

La informacion se ha convertido en un recurso muy valioso para cualquier companıa. Gran-

des cantidades de informacion son generadas anualmente a tal punto que se convierten en

la historia clınica de la empresa pudiendo conocer a traves de esta informacion su esencia

misma.

Sin embargo, para que dicha informacion tenga algun significado, esta debe tener un con-

texto y debe poder ser buscada y consultada. Es en esta instancia en donde se percibe una

oportunidad de mejora dentro de la companıa, ya que la informacion actualmente carece de

contexto por encontrarse fragmentada en multiples equipos informaticos, lo cual a su vez

dificulta su busqueda y por consiguiente impide que pueda ser consultada por quien pudiese

necesitarla. Adicionalmente esta condicion de fragmentacion evidencia un estado de vulne-

rabilidad al encontrarse tan dispersa.

Al ser evidente la existencia de dicha problematica que podrıa acarrear serios problemas a

la empresa en un corto plazo, se requiere desarrollar una aplicacion informatica que permita

optimizar el proceso de generacion y almacenamiento de documentos ofreciendo un mecanis-

mo simple de carga, indexado y consulta porque se ha entendido que la informacion es un

recurso muy valioso para cualquier companıa y es imperativo salvaguardarlo y preservarlo;

colocando ası al alcance de quien lo requiera y lo tenga permitido, las evidencias de las ac-

tividades desarrolladas en los procesos operativos de Cyza Outsourcing S.A.

1.4. HIPOTESIS DE TRABAJO

Si se construye una herramienta de software capaz de administrar y controlar los recursos

documentales tanto fısicos como digitales que se generan durante los procesos internos a

nivel tecnico, gerencial u operativo, mejorara significativamente el control y la trazabilidad

de los mismos procesos ocurridos al interior de Cyza Outsourcing, garantizando el manejo

adecuado de la informacion como recurso intelectual y ademas incubando un soporte histori-

co que hara las veces de base teorica a las futuras tareas y actividades que al interior de la

companıa se desarrollen.


1.5. MARCO DE REFERENCIA

1.5.1. Marco Teorico

A continuacion se presenta la base teorica sobre la cual se desarrolla el tema de los sistemas

de administracion de documentos y algunos autores que explican el origen de este tipo de

sistemas ası como las necesidades que se pretenden suplir. Adicionalmente se da una breve

descripcion de las caracterısticas que tienen este tipo de sistemas y los aspectos que debe

cumplir.

Antecedentes

La concepcion de sistema de gestion de documentos proviene de un concepto mas antiguo

denominado Sistemas Archivısticos que en terminos generales se define como:[15]

“conjunto de normas e instituciones que participan en la direccion, seguimiento, coor-

dinacion e inspeccion de los programas para la conservacion, tratamiento y difusion del

Patrimonio Documental. Componen el sistema archivıstico los archivos, los servicios ar-

chivısticos, la administracion de archivos, la legislacion archivıstica y el personal”.

Los sistemas archivısticos estan mas enfocados a garantizar la preservacion de los archivos

con una contextualizacion historica y patrimonial que dan origen a los grandes Sistemas

Nacionales de Archivos presentes como una institucion de gobierno donde se concentran do-

cumentos de gran relevancia para una nacion. Son calificados como meta sistemas de archivos

y para conservar su integridad se definen como elementos basicos del sistema “el principio

de respeto a la procedencia” y el “ciclo vital de los documentos” respaldados por una admi-

nistracion que se encarga de su gestion y planificacion, los servicios tecnicos que le sirven de

apoyo, la normativa legal y reglamentaria que lo regula y como aspectos complementarios

las instalaciones, el personal, los medios tecnicos y tecnologicos.

Como una particularizacion se describe la teorıa de la gestion de los documentos administra-

tivos [20] como una necesidad de satisfacer en primer lugar las necesidades de la administra-

cion, dando preferencia al cuadro de clasificacion sobre otros sistemas administrativos como

el inventario de documentos dando como premisa que la preservacion de los documentos con

valor permanente es la consecuencia y no el objetivo, de un sistema de gestion de documentos

administrativos.

1.5 MARCO DE REFERENCIA 7

Definicion de un Sistema de Administracion de Documentos

Un Sistema de Administracion de Documentos (o DMS, termino en ingles por Document

Management System) es un software que es utilizado para rastrear y almacenar documentos

fısicos, documentos electronicos o documentos digitalizados, ası como para la correcta distri-

bucion de los mismos en la organizacion. Este tipo de sistema busca apoyar otras areas como

la gestion documental o los procesos de calidad de la empresa, y estan presentes en el ciclo

de vida de los documentos, desde la creacion y captura, revision y versionamiento, pasando

por la edicion y publicacion y finalizando por el uso o eliminacion durante el periodo de vida

que tiene el documento dentro de la empresa.

El exito de un Sistema de Administracion de Documentos esta en su diseno, debido a que

un mal diseno no favorece a ninguna busqueda y no distribuye la informacion a todos los

niveles de la organizacion [3]. Estos sistemas son de mucha ayuda ya que le ahorra tiempo

y recursos a las empresas en materia de costos de papelerıa y almacenamiento de documen-

tos, sin mencionar la gran contribucion que prestan cuando se realizan las auditorıas en la

empresa.

Beneficios de la gestion de documentos de archivo.

La gestion de documentos de archivo regula las practicas efectuadas tanto por los responsa-

bles de su gestion como por cualquier otra persona que cree o use documentos en el ejercicio

de sus actividades. La gestion de documentos en una organizacion incluye:

El establecimiento de polıticas y normas.

La asignacion de responsabilidad y competencias.

La fijacion y promulgacion de procedimientos y directrices.

La presentacion de servicios relacionados con su gestion y uso.

El diseno, la implementacion y la administracion de sistemas especializados.

La integracion y gestion de documentos en los sistemas y procesos de negocio de la

organizacion.

Es importante reconocer que los documentos de archivo constituyen un preciado recurso y

un importante activo de la organizacion y por tal motivo es prescindible la adopcion de un

criterio sistematico de la gestion de documento para las organizaciones a la hora de proteger

y preservar los documentos como evidencia de sus actos. Un sistema de administracion de


documentos se convierte en una fuente de informacion sobre las actividades de la organiza-

cion que puede servir de apoyo a posteriores actividades y toma de decisiones.

Los documentos permiten a las organizaciones:

Realizar sus actividades de una manera ordenada, eficaz y responsable.

Presentar servicios de un modo coherente y justo.

Respaldar y documentar la creacion de polıticas y la toma de decisiones de gestion.

Proporcionar coherencia, continuidad y productividad a la gestion y a la administra-

cion.

Facilitar la ejecucion eficaz de actividades en el centro de la organizacion.

Garantizar continuidad en caso de catastrofe.

Cumplir con los requisitos legislativos y normativos, incluidas las actividades archivısti-

cas, las fiscalizadoras y las de supervision.

Proporcionar proteccion y apoyo en los litigios, incluyendo la gestion de riesgos en

relacion con la existencia o ausencia de evidencias en las actividades realizadas por la

organizacion.

Proteger los intereses de la organizacion y los derechos de los empleados, los clientes y

las partes interesadas presentes y futuras.

Apoyar y documentar las actividades de investigacion y desarrollo presentes y futuras,

las realizaciones y los resultados, ası como la investigacion archivıstica.

Proporcionar evidencias acerca de las actividades personales, culturales y de las orga-

nizaciones.

Establecer una identidad personal, cultural y de la organizacion.

Mantener una memoria corporativa, personal y colectiva.

Caracterısticas de un documento

Ademas de su contenido, el documento deberıa incluir los metadatos necesarios para do-

cumentar una determinada operacion, o estar permanentemente ligado o asociado a dichos

metadatos. Las polıticas, practicas y procedimientos de gestion de documentos deberıan pro-

ducir documentos fidedignos que reunan las siguientes caracterısticas.


Autenticidad

Se dice que un documento es autentico si se puede probar que es lo que afirma ser, que ha

sido creado o enviado por la persona que afirma que lo ha creado y que ha sido creado y

enviado en el momento que se firma. Para garantizar la autenticidad de los documentos,

las organizaciones deben implantar y documentar polıticas y procedimientos para el control

de la creacion, recepcion, transmision, mantenimiento y disposicion de los documentos de

manera que se asegure que los creadores de los mismos esten autorizados e identificados

y que los documentos esten protegidos frente a cualquier adicion, supresion, modificacion,

utilizacion u ocultacion no autorizadas.

Fiabilidad

Un documento es fiable cuando su contenido es considerado una representacion completa y

precisa de las operaciones, las actividades o los hechos de los que da testimonio y al que

se puede recurrir en el curso de posteriores operaciones o actividades. Debe ser creado en

el momento, o poco despues, en que tiene lugar la operacion o actividad que reflejan, por

individuos que dispongan de un conocimiento directo de los hechos o automaticamente por

los instrumentos que se usen para realizar las operaciones.

Integridad

Hace referencia a su caracter completo e inalterado y es necesario que un documento este

protegido contra modificaciones no autorizadas. Las polıticas y los procedimientos de gestion

de documentos deberıan especificar que adiciones o anotaciones pueden realizarse en un do-

cumento despues de su creacion, en que circunstancias pueden autorizarse dichas adiciones

o anotaciones y quien esta autorizado para llevarlas a cabo. Cualquier anotacion, adicion o

supresion autorizada que se realice en un documento deberıa indicarse de forma explıcita y

dejar traza.

Disponibilidad

Un documento utilizable es aquel que puede ser localizado, recuperado, presentado e in-

terpretado. Su presentacion deberıa mostrar la actividad u operacion que lo produjo. Las

indicaciones sobre el contexto de los documentos deberıan contener la informacion necesaria

para la comprension de las operaciones que los crearon y usaron. Deberıa ser posible identifi-

car un documento en el contexto amplio de las actividades y las funciones de la organizacion.

Se deberıan mantener los vınculos existentes entre los documentos que reflejan una secuencia


de actividades.

Caracterısticas de un sistema de administracion de documentos

Para dar una descripcion que abarque rasgos basicos con los que debe contar un sistema de

administracion de documentos se lista las siguientes caracterısticas:

Fiabilidad

Cualquier sistema de gestion de documentos deberıa funcionar de modo regular y continuo

mediante procedimientos fiables de modo que logre incorporar de forma rutinaria todos los

documentos ligados a las actividades de la organizacion que se contempla en el sistema,

organizarlos de modo que reflejen los procesos de negocio de su creador, protegerlos frente

a una modificacion o disposicion no autorizadas y proporcionar un acceso facil a todos los

documentos pertinentes y a sus metadatos.

Un sistema de administracion de archivos deberıa ser sensible a los cambios operados en las

necesidades de la organizacion. A su vez, las modificaciones que se produzcan en el sistema

no deberıan repercutir en las caracterısticas de los documentos.

Integridad

Es necesario aplicar medidas para controlar el acceso, la identificacion del usuario, la des-

truccion autorizada y la seguridad, con la finalidad de evitar el acceso, la destruccion, la

modificacion o la eliminacion no autorizados. Estas medidas de control pueden formar parte

del sistema o ser externas al mismo. Si se trata de documentos electronicos de archivo, la

organizacion puede necesitar probar que la actualizacion, el mantenimiento habitual o cual-

quier fallo de funcionamiento del sistema no afectan a la integridad de los documentos.

Conformidad

Un sistema de administracion de documentos deberıan cumplir con todos los requisitos de-

rivados de las actividades propias de la organizacion, de su entorno normativo y de las

expectativas de la sociedad. El personal que crea los documentos deberıa saber como afectan

estos requisitos a las acciones que realizan. La conformidad del sistema de administracion de

documentos deberıa evaluarse periodicamente y se deben conservar los resultados de dichas

evaluaciones con fines testimoniales.


Caracter Sistemico

Los documentos se deben crear, conservar y gestionar sistemicamente. La creacion y el man-

tenimiento de documentos se deben sistematizar mediante el diseno y funcionamiento tanto

de sistemas de gestion de documentos como de otros sistemas de gestion.

1.5.2. Marco Conceptual

A continuacion sera realizada una descripcion de los procedimientos y teorıas que se preten-

den emplear durante la etapa de desarrollo del software propuesto para Cyza Outsourcing

S.A., incluyendo los componentes y la arquitectura que seran incorporados en la solucion

planteada. Durante esta descripcion tambien seran incluidos elementos que forman parte de

herramientas, lineamientos, manuales y buenas practicas que la companıa ha acunado para

las herramientas informaticas desarrolladas por el personal perteneciente al area de desa-

rrollo, y que deben ser incluidas de forma obligatoria debido a que estas forman parte de

procesos ya establecidos, y que, en algunos casos pertenecen al manual de procesos interno

de la companıa.

El sistema de administracion de documentos de Cyza Outsourcing S.A. sera desarrollado

haciendo uso de la tecnologıa .Net Framework, orientada a proveer un entorno de desarrollo

unico y que permita la integracion de aplicaciones existentes de manera facil y sencilla ha-

ciendo uso de estandares ampliamente probados como HTTP, RPC, XML y servicios web,

entre otros, al tiempo que ofrece seguridad y facilidad para la realizacion de despliegues,

versionado del mismo y administracion del codigo fuente mediante multiples herramientas

como lo es TeamFoundation Server, basada en interacciones colaborativas entre los miembros

que forman parte del ciclo de desarrollo.[24]

Arquitectura con n-capas

Para poder cumplir con los requerimientos internos de la companıa que obedecen a modula-

ridad, facilidad de mantenimiento y escalabilidad de la aplicacion se pretende implementar

una arquitectura multicapas o n capas 1. Estas aplicaciones son comunmente conocidas co-

mo “aplicaciones multicap” o “aplicaciones multinivel”, y tienen como finalidad segmentar el

procesamiento de datos en niveles especializados e independientes entre sı. Si bien, las capas

de una aplicacion no estan definidas per se, existen cuatro tipos que son implementadas en

la mayorıa de aplicaciones:

1Microsoft Corporation. Informacion general sobre aplicaciones de datos con n capas. En

https://msdn.microsoft.com/es-es/library/bb384398.aspx


Capa de presentacion

Capa de negocio

Capa de acceso a datos

Capa de definicion de entidades de negocio

La gran ventaja que ofrece este modelo es que las capas agrupan paquetes de clases altamente

especializadas que se encargan de labores especıficas al ambito para el cual fueron creadas.

Esto permite que su desarrollo sea independiente de las demas capas, fomentando ası la

programacion paralela y disminuyendo los tiempos de desarrollo. Al tener la independencia

mencionada, cada capa es facilmente extensible sin que los cambios realizados afecten ne-

cesariamente las demas capas, lo que permite tambien, incorporar componentes de terceros

(APIs, SDK, componentes COM, llamados remotos) con poco esfuerzo y un impacto mınimo

sobre la solucion completa. Bajo este modelo, cada capa de la aplicacion es representada por

un producto concreto que se genera como resultado de la compilacion, pudiendo este ser:

una biblioteca de clases, un archivo ejecutable WIN32, una aplicacion web winforms o MVC,

etc.

Figura 1-1.: Diagrama de arquitectura de la aplicacion

Fuente: Autorıa propia

Capa de presentacion

En esta capa tendra lugar la interaccion de los usuarios con la aplicacion. Las aplicaciones

deben exponer una interfaz que le permita a sus usuarios finales interactuar con la misma;


las herramientas que se pueden emplear para el diseno son diversas: VisualStudio, Visual

WebMatrix, Microsoft Blend, Mono.Net, etc. Asimismo, se pueden utilizar plataformas de

desarrollo diferentes a las pertenecientes a Microsoft: Node.js, Angular, Bootstrap, PHP,

HTML, etc. Esta capa es comunmente conocida como el FrontEnd.

Es importante que cada componente de esta capa cumpla con los lineamientos exigidos por

la companıa. Por lo tanto, se debe guardar coherencia con el aspecto visual con relacion a

las aplicaciones que ya se encuentran en produccion, igualmente, se debe conservar el mismo

estilo de codificacion que se ha venido empleando por el area de desarrollo. Para esto ultimo,

es necesario implementar paginas maestras que deberan contener la logica transversal a las

demas paginas (autenticacion, autorizacion, construccion de menus). Estas a su vez deberan

contener sub paginas que expandiran la funcionalidad de sus contenedores, sin embargo,

dicha expansion se realizara con miras a especializar cada componente, esto es, separar las

responsabilidades.

Figura 1-2.: Diagrama logico de la capa de presentacion


Las interfaces de usuario de la capa de presentacion estan compuestas por variados elementos

que estan disenados para que el usuario pueda interactuar de forma sencilla con la aplica-

cion: cajas de texto, listas desplegables, botones, hipervınculos, listas de seleccion multiple y

sencilla, etc. (Shepherd, 2015) [5]. La tecnologıa ASP.Net permite manipular estos controles

mediante codigo JavaScript, ademas de lenguajes compilados como C Sharp, C++ o VB

desde archivos denominados CodeBehind que estan presentes en cada subpagina. Durante


la ejecucion del programa, estos controles son renderizados en forma de HTML para que

cualquier browser pueda interpretarlos y representarlos en pantalla. Esta capa ademas de

realizar la representacion grafica de la informacion y permitir al usuario interactuar con la

misma, tendra la responsabilidad de realizar la validacion inicial de la informacion capturada

en cuanto a formato de esta y obligatoriedad.

Capa de negocio

La capa de negocio es el sitio en donde se procesan las peticiones recibidas mediante la capa

de presentacion, se realiza la implementacion de las reglas de negocio y se realizan valida-

ciones inherentes a la misma sobre los datos o estados de un objeto determinado.

Esta capa es generada comunmente para aplicaciones ASP.Net, como una biblioteca de cla-

ses (archivo dll), que contendra en su interior un numero determinado de clases agrupadas

logicamente y dependiendo de su proposito en espacios de nombres (namespaces) 2. Durante

la fase de diseno se debe determinar cuales de estas clases tendran una visibilidad publica y

cuales no, teniendo en cuenta el principio de ocultacion [4], y siempre con miras a proteger

las funcionalidades necesarias para garantizar el correcto funcionamiento de la aplicacion y

de la proteccion de la informacion procesada por esta.

Figura 1-3.: Representacion grafica de un namespace

Fuente: Microsoft Corp

Como se menciono anteriormente, la capa de presentacion tendra la responsabilidad inicial

sobre la validacion, sin embargo, en la capa de negocio se realiza una segunda validacion

siendo la informacion sujeta a distintas verificaciones relacionadas con la logica del negocio.

Para mencionar un ejemplo: para un simulador de credito la capa de presentacion deberıa

2Espacios de nombres (Namespaces) consultado en: https://msdn.microsoft.com/en-

us/library/ms973231.aspx


capturar el monto del credito y validar que sea numerico para luego entregarlo a la capa

de negocio, la cual deberıa verificar si esta cifra es positiva (no se puede pedir prestado

una cantidad negativa) o si la cantidad supera un monto determinado (se tiene una cuantıa

mınima para un prestamo), siendo estas validaciones inherentes a la logica de la operacion

o reglas determinadas de la companıa.

La capa de negocio tambien estara en la capacidad de comunicarse con la capa de datos,

permitiendo esto atender peticiones que soliciten la extraccion de determinada informacion

o el almacenamiento de la misma en el repositorio de datos de la aplicacion.

Figura 1-4.: Representacion grafica capa de negocio


Capa de datos

La capa de datos de la aplicacion contiene una coleccion de clases que permiten a la aplica-

cion interactuar con el repositorio de informacion. En esta se encapsulan todos los metodos o

funcionalidades necesarias para establecer conexiones, extraer, actualizar, insertar y eliminar

informacion.

Dado que en Cyza Outsourcing S.A. se cuenta con multiples licencias el motor de base de

datos SQL Server, este debera ser empleado como repositorio de la informacion, por lo cual

tambien se empleara una librerıa de terceros provista por Microsoft y llamada Enterprise


Library , la cual facilita el proceso de codificacion, ya que contiene de forma implıcita imple-

mentaciones rutinarias como lo son apertura y cerrado de conexiones, liberacion de memoria,

etc. Dado que en Cyza Outsourcing S.A. se cuenta con multiples licencias el motor de base

de datos SQL Server, este debera ser empleado como repositorio de la informacion, por lo

cual tambien se empleara una librerıa de terceros provista por Microsoft y llamada Enter-

prise Library 3 , la cual facilita el proceso de codificacion, ya que contiene de forma implıcita

implementaciones rutinarias como lo son apertura y cerrado de conexiones, liberacion de

memoria, etc.

Figura 1-5.: Esquema de Enterprise Library

Fuente: Microsoft Corp

Adicionalmente a la Enterprise Library, se debera emplear ADO.Net (ActiveX Data Objects

.Net), el cual esta compuesto por un conjunto de clases que permiten el acceso a datos rela-

cionales, orıgenes de datos XML, orıgenes de datos SQL y proveedores de datos de terceros

[17]. ADO.Net sera empleado para todo lo relacionado con la generacion de reportes o de

consultas que requieran procesamiento masivo de informacion, debido a su capacidad para

el manejo de procesamiento por lotes pequenos de informacion mediante el objeto SQLDa-

taReader. 4

3MSDN-Microsoft. Enterprise Library. Disponible en: http://msdn.microsoft.com/en-

us/library/ff632023.aspx4MSDN-Microsoft, SQLDataReader disponible en: https://msdn.microsoft.com/es-

es/library/system.data.sqlclient.sqldatareader(v=vs.110).aspx


Figura 1-6.: Entidad de negocio y mapeo


El empleo de entidades de negocio supone varias ventajas. Ademas de la estandarizacion de

los contenedores empleados para transportar la informacion entre las capas, las entidades de

negocio son objetos mas optimos en terminos de uso de memoria que los DataTable o Data-

Set comunmente empleados. Tambien permiten su eventual serializacion para emplearlos en

la comunicacion mediante web sevices, bien sea empleando el lenguaje XML o la notacion

JSON, dotando a la aplicacion de manera implıcita de la capacidad de ser interoperable con

otros sistemas si es requerido.

Arquitectura fısica de la aplicacion

Para poner en marcha la aplicacion se requerira emplear de la infraestructura fısica dispuesta

por la companıa para alojar aplicaciones web, para lo cual se sugiere el siguiente esquema:


Figura 1-7.: Diagrama fısico de red y componentes de la aplicacion


Actualmente, en el segmento de servidores de Cyza Outsourcing S.A. existen multiples equi-

pos con funciones especıficas; para la puesta en marcha de la aplicacion se requieren emplear:

1. El servidor de aplicaciones, el cual sera encargado de hospedar la aplicacion y permitir

que esta se pueda acceder haciendo uso de un navegador, ademas de permitir exponer

el/los servicios web necesarios para interoperar con otros sistemas.

2. El servidor de directorio activo, el cual aloja el listado de empleados y colaboradores

de la companıa, y encapsula la funcionalidad de autenticacion. Es necesario realizar

este proceso haciendo uso de las credenciales del directorio activo, toda vez que los

lineamientos de desarrollo exigen la implementacion de un unico inicio de sesion o SSO

(Single SignOn).

3. El servidor de bases de datos, quien se encarga de hospedar una instancia de SQL

Server y aloja las distintas bases de datos empleadas por las aplicaciones desarrolladas

al interior de la companıa.

El servidor de aplicaciones esta disponible para todos los usuarios que se encuentren en la

red interna de la companıa. Para todos los usuarios que requieran acceder desde instancias

externas, el acceso sera realizado mediante una IP publica o el subdominio de aplicaciones.


Esto requerira que absolutamente todas las peticiones pasen a traves del firewall de la com-

panıa, el cual se encargara de filtrar todas aquellas que sean invalidas.

ASP.Net

Es una plataforma que incorpora una serie de caracterısticas y utilidades para disenar apli-

caciones Web como formularios Web o servicios Web.

Los formularios Web se utilizan para crear aplicaciones en las cuales la interfaz primaria de

usuario es un explorador. Entre ellas se incluyen las aplicaciones que se ponen a disposi-

cion del publico a traves de la red. Una caracterıstica importante es que no hay costos de

distribucion, puesto que los usuarios tienen ya instalada la unica parte de la aplicacion que

necesitan: el browser.

Las aplicaciones de formularios Web son por definicion independientes de la plataforma; es

decir, los usuarios pueden interactuar con la aplicacion independientemente del tipo de ex-

plorador que tengan, e incluso, del tipo de equipo que utilicen. [5]

Visual Studio

Visual Studio es un conjunto completo de herramientas de desarrollo para construir aplicacio-

nes Web, servicios Web, aplicaciones Windows o de escritorio y aplicaciones para dispositivos

moviles. El entorno de desarrollo integrado que ofrece esta plataforma como todas sus he-

rramientas y con la biblioteca de clases .NET Framework, es compartido en su totalidad por

Visual Basic, Visual C++, y Visual C Sharp, permitiendo ası crear con facilidad soluciones

en las que intervengan varios lenguajes y en las que el diseno se realiza separadamente res-

pecto a la programacion.

Servidor de Aplicaciones

Es un software que proporciona aplicaciones a los equipos o dispositivos cliente, por lo ge-

neral a traves de internet y utilizando el protocolo http. Los servidores de aplicaciones se

distinguen de los servidores web por el uso extensivo de contenido dinamico y por su fre-

cuente integracion con base de datos.

Un servidor de aplicaciones es un producto basado en un componente que se encuentra en

el plano intermedio de la arquitectura central de un servidor. Proporciona servicios “midd-

leware” es decir, trabaja con un intermediario para la seguridad y el mantenimiento ademas


de proveer el servicio a datos.

Servidor de directorio activo

Active Directory (AD) o Directorio Activo son los terminos que utiliza Microsoft para refe-

rirse a su implementacion de servicio de directorio en una red distribuida de computadores.

Utiliza distintos protocolos, principalmente LDAP, DNS, DHCP y Kerberos.

De forma sencilla se puede decir que es un servicio establecido en uno o varios servidores en

donde se crean objetos tales como usuarios, equipos o grupos, con el objetivo de administrar

los inicios de sesion en los equipos conectados a la red, ası como tambien la administracion

de polıticas en toda la red.

Active Directory permite a los administradores establecer polıticas a nivel de empresa, des-

plegar programas en muchos ordenadores y aplicar actualizaciones crıticas a una organizacion

entera. Un directorio activo almacena informacion de una organizacion en una base de datos

central, organizada y accesible. Pueden encontrarse desde directorios con cientos de objetos

para una red pequena hasta directorios con millones de objetos. 5

Web Service

Los Servicios web amplıan la infraestructura de la World Wide Web al proporcionar los

medios para que el software se pueda conectar con otras aplicaciones de software. Las aplica-

ciones acceden a los servicios Web a traves de protocolos omnipresentes en la web y formatos

de datos como HTTP, XML y SOAP, sin necesidad de preocuparse acerca de la implemen-

tacion explicita de cada servicio Web 6. Los servicios web combinan los mejores aspectos del

desarrollo basado en componentes y la Web, y son la piedra angular de cualquier proyecto

que requiera realizar intercambio de datos entre distintas aplicaciones o plataformas.

1.6. METODOLOGIA DE LA INGENIERIA

1.6.1. Programacion Extrema

La Programacion Extrema (XP) forma parte del movimiento de desarrollo agil de software

que se basa en la adaptabilidad de cualquier cambio como medio para aumentar las posibi-

5Wikipedia. Directorio activo. Consultado en: https://es.wikipedia.org/wiki/Active Directory6Web Services, consultado en: https://msdn.microsoft.com/en-us/library/ms950421.aspx

1.6 METODOLOGIA DE LA INGENIERIA 21

lidades de exito de un proyecto y que tiene como premisas los siguientes aspectos [2]:

Los individuos y sus interacciones son mas importantes que los procesos y las herra-

mientas.

El software que funciona es mas importante que la documentacion exhaustiva.

La colaboracion con el cliente en lugar de la negociacion de contratos.

La buena disposicion ante el cambio en lugar de seguir un plan cerrado.

La Programacion Extrema es un enfoque que ha adoptado practicas de desarrollo de software

ya existentes en otras metodologıas de desarrollo y las ha llevado al extremo. Un ejemplo de

ello es la retroalimentacion que es importante para los programadores, analistas, disenadores,

usuarios y computadores. Ası que la programacion extrema usa ciclos de retroalimentacion

cada vez mas rapidos e intensos, que proporcionan mas informacion. Este enfoque de pro-

gramacion intenta definir un plan global del sistema, desarrollar y liberar rapidamente el

software y posteriormente revisarlo de forma continua para incorporarle caracterısticas adi-

cionales. [13].

La implementacion de cada uno de los principios y valores que esta metodologıa sugiere

sera descrita a continuacion queriendo explicarse el como sera puesto en practica para ob-

tener los mejores resultados durante todo el desarrollo del proyecto en Cyza Outsourcing S.A.

Valores de la Programacion Extrema

Debido a que frecuentemente existe una tension entre lo que los disenadores hacen a corto

plazo y lo que es comercialmente deseable a largo plazo es importante ser consciente de apoyar

los valores que formaran una base colaborativa en un proyecto de software. Tales valores son:

Comunicacion: Los proyectos de los sistemas que requieren una actualizacion constante

y un diseno tecnico, son especialmente propensos a errores por falta de comunicacion. Si

se suman problemas tıpicos como fechas de entrega ajustadas, uso de jerga especializada

y la muy comun concepcion de que los programadores son poco comunicativos con las

personas, entonces hay serias posibilidades de fallar en este ambito. Para ello ya se

aplica en el area de desarrollo la practica de reuniones cortas y periodicas de alrededor

de 15 minutos para resolver dudas e inquietudes entre los miembros del equipo y el

director de desarrollo y para enterarse de los avances del proyecto.


Simpleza: Es un pensamiento que implica no abrumarse por la aparente complejidad de

la tarea. Consiste en comenzar por el elemento mas sencillo y a partir de allı construir

el requerimiento con sus caracterısticas adicionales, pero para ello se debe tener claro

el enfoque referente a las metas del proyecto.

Retroalimentacion: Ocurre cuando existe un prototipo que es evaluado por los clientes

y principales interesados en ese desarrollo. Una retroalimentacion crıtica viene de los

clientes que comparan la meta del plan con el progreso que se ha tenido. De esta

manera la retroalimentacion ayuda a los programadores a hacer los ajustes necesarios

para orientar el software al resultado esperado.

Valentıa: Este valor se rige por un nivel de confianza propio y a su vez existente en el

equipo de desarrollo. Es no tener miedo a empezar de nuevo si es necesario, teniendo

la perspicacia de reconocer ese momento ayudandose del instinto. Para Kendall (1995)

[9] “La valentıa es un valor de alto riesgo y de alta recompensa que anima a la expe-

rimentacion que el equipo puede tomar de una forma mas rapida e innovadora para

lograr su meta”[13].

Principios basicos de la Programacion Extrema

Se trata de doce principios agrupados en cuatro grandes categorıas ası [13]:

Retroalimentacion a escala fina.

El principio de pruebas: Se debe establecer un periodo de pruebas de aceptacion del

programa comunmente denominado “periodo de caja negra” donde se definiran las

entradas al sistema y los resultados esperados de estas entradas. El area de desarrollo

cuenta con la participacion de una ingeniera con el rol de “Encargada de Pruebas”

(tester) y esta en la capacidad de realizar las pruebas unitarias que pretenden medir

el funcionamiento puntual de una parte de la aplicacion.

Proceso de planificacion: en esta fase el cliente tendra que escribir sus necesidades,

definiendo las actividades que realizara el sistema. Se creara un documento llamado

“Historias del Usuario” (UserStories) que conformaran el “Plan de Liberacion”, el cual

define los tiempos de entrega de la aplicacion para recibir retroalimentacion por parte

del usuario.

El cliente en el sitio: tendra la potestad de determinar los requerimientos, definir las

funcionalidades, senalar las prioridades y responder a las preguntas de los programado-

res. Esta fuerte interaccion con el programador disminuye el tiempo de comunicacion

y la cantidad de documentacion, junto con los altos costes que su creacion generan.

Para Cyza el principal cliente sera el representante del area que hara un fuerte uso del


sistema de control de inventarios que para este caso se trata del area de infraestructura

quienes son los que actualmente llevan a cabo el levantamiento de inventario sobre los

equipos de la companıa.

Programacion en parejas: Este principio requiere que los programadores que sigan

esta metodologıa escriban su codigo en parejas, compartiendo una sola maquina para

promover el trabajo en equipo y el incremento de la calidad en el codigo.

Esta practica ayuda a reducir el porcentaje de errores que se producen al codificar ya que

tal revision es realizada por las dos personas que estan trabajando sobre el mismo codigo

y promueve la difusion de la funcionalidad completa del software a mas de un miembro del

equipo evitando dependencia a una sola persona y la privatizacion del codigo.

Para cumplir con la condicion de trabajo en parejas se debera contar con la participacion de

los dos proponentes del anteproyecto en todas las actividades y fases del proyecto, adicional-

mente se propone someter la codificacion a un procedimiento ya existente en la empresa y es

el de publicar a un servidor de control de versiones (SVN) el proyecto que se va a realizar,

permitiendo el acceso a este repositorio por otros miembros del departamento. Puntualmen-

te el jefe del area de desarrollo tendra acceso como lıder del grupo y al realizar un rol de

“Coach” (Entrenador del proyecto) estara en la obligacion de conocer los aspectos relevantes

del aplicativo y su funcionamiento, esto con el fin de poder generar las directrices apropiadas

durante todo el ciclo de desarrollo. Otro rol que podra actuar como colaborador en este

aspecto sera el “tester” a quien podra indicarsele el comportamiento de la funcionalidad que

esta a punto de probar. Como el area de desarrollo de Cyza es pequeno es comun que los

companeros de codificacion conozcan funcionalidades, estandares de codificacion en comun e

inclusive se relaten experiencias de codificado que otro miembro del grupo haya experimen-

tado en sus proyectos para ser retroalimentado al grupo.

Proceso continuo en lugar de por lotes

Integracion continua: permite al equipo hacer un rapido progreso implementando las

nuevas caracterısticas del software. En lugar de crear “builds” (versiones) estables

de acuerdo a un cronograma establecido, los equipos de programadores XP pueden

reunir su codigo y reconstruir el sistema varias veces al dıa. El entorno de trabajo de

VisualStudio.Net facilita la realizacion de este ejercicio ya que su Framework incluye

un Servidor de Aplicaciones virtual que permite compilar y ejecutar el aplicativo en

tiempo real para lograr visualizar los avances obtenidos.

Refactorizacion: permite mejorar el diseno del sistema a traves de todo el proceso

de desarrollo. Los programadores evaluan continuamente el diseno y re codifican lo


necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio

mediante la minimizacion del codigo duplicado e ineficiente.

Entregas pequenas: sugiere colocar un sistema sencillo en produccion rapidamente para

actualizarse de forma rapida y constante permitiendo que el verdadero valor de negocio

del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar de las

2 o 3 semanas como maximo. Para ello el area de desarrollo dispone de un servidor

virtualizado de pruebas y con las caracterısticas que pudiera compartir un ambiente

real de produccion en cuanto a configuracion y garantıa de requerimientos para la

publicacion de la version. Este servidor no cubrira aspectos puntuales de accesibilidad

como concurrencia o altos recursos ya que solo se pretende evaluar la funcionalidad del

desarrollo de software publicado.

Entendimiento compartido

Diseno simple: se basa en la filosofıa de que el mayor valor de los negocios es entregado

por el programa mas sencillo que cumpla los requerimientos. Simple Design se enfoca

en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni mas ni

menos.

Metafora: es desarrollada por los programadores al inicio del proyecto, define una

historia de como funciona el sistema completo. XP estimula historias que son breves

descripciones de un trabajo de un sistema.

Propiedad colectiva del codigo: un codigo con propiedad compartida. Nadie es el pro-

pietario de nada, todos son el propietario de todo. Este metodo evita hacer lo que

hacen los metodos tradicionales en los que un simple programador posee un conjunto

de codigo y solo el conoce su funcionamiento.

Estandar de codificacion: define la propiedad del codigo compartido ası como las reglas

para escribir y documentar el codigo y la comunicacion entre diferentes piezas del

mismo, desarrolladas por diferentes equipos. Los programadores las han de seguir de

tal manera que el codigo en el sistema se vea como si hubiera estado escrito por una

sola persona.

Bienestar del programador

La semana de 40 horas: la programacion extrema sostiene que los programadores can-

sados escriben codigo de menor calidad. Minimizar las horas extras y mantener los

programadores frescos generara codigo de mayor calidad. Esta es una premisa que se

cumple a cabalidad en Cyza Outsourcing. Si por alguna razon no se completo una

tarea para el mismo dıa entonces sera resuelto al dıa siguiente y ası evitar sobrecargar

el estado anımico y fısico del programador.


Roles dentro de la programacion extrema

El cliente

Es el responsable de conducir el proyecto. Toma decisiones de negocio y debe entender los

cambios del mismo a lo largo del tiempo: identifica si una historia tiene el mismo valor ahora

que cuando se identifico.

Derechos:

Cambiar el alcance del proyecto para hacer frente a los cambios en la planificacion.

Determinar que funcionalidades seran las siguientes en implementarse.

Medir el progreso del proyecto en cualquier momento, lanzando las pruebas de acep-

tacion.

Detener el proyecto en cualquier momento sin perder la inversion realizada, mantenien-

do en produccion un producto estable y continuar planificando otras funcionalidades

mas importantes.

Responsabilidades:

Confiar en las decisiones tecnicas de los desarrolladores.

Analizar los riesgos correctamente.

Seleccionar las historias que aportan mas valor para cada iteracion.

Definir las historias de usuario de forma precisa, permitiendo a los desarrolladores

realizar estimaciones precisas.

Participar en el equipo ofreciendo directrices y feedback tan pronto y preciso como sea

posible.

El programador

Una vez que se han comprendido las historias de usuario, la metodologıa XP adjudica a los

programadores la responsabilidad de tomar decisiones tecnicas. Los desarrolladores estiman

el tiempo que les va a tomar cada historia y transforman las historias de usuario en codigo.

Derechos:


Estimacion de su propio trabajo, teniendo autoridad para tomar decisiones tecnicas.

Delimitar el trabajo responsabilizandose de aquellas tareas que van a ser capaces de

llevar a cabo.

Implementar la funcionalidad que cubre las necesidades del cliente.

No tomar decisiones de negocio.

Responsabilidades:

Seguir las directrices del equipo.

Desarrollar las funcionalidades realmente necesarias.

Establecer una comunicacion fluida con el cliente.

El probador

Es el encargado de las pruebas y ayuda al cliente a definir y escribir las pruebas de aceptacion

de las historias de usuario. Este rol en un equipo XP tambien es responsable de realizar test

periodicamente e informar los resultados al equipo.

El entrenador

Su papel es guiar y orientar al equipo y su objetivo es que el equipo comprenda las directri-

ces de XP. No se trata de que sean solo lecciones teoricas sino que debe conocer el aspecto

practico de la metodologıa para ofrecer ejemplos y proponer ideas que permitan mejorar.

El encargado del seguimiento

Hace el seguimiento de acuerdo a la planificacion. La metrica mas importante para XP es la

velocidad del equipo que se define como el tiempo ideal estimado para las tareas frente al

tiempo real dedicado. Esta metrica ayuda a determinar si el proyecto esta dentro del tiempo

de la iteracion. Este rol puede ser tomado por el Coach.

El gestor

Es la persona que tiene la idea general del proyecto y esta familiarizado con su estado. El

cliente puede asumir este papel.

1.7 ASPECTOS METODOLOGICOS 27

1.7. ASPECTOS METODOLOGICOS

1.7.1. Tipo de estudio

Se determina que el tipo de estudio corresponde a uno de tipo descriptivo habiendo iden-

tificado que hay toda una teorıa que soporta el concepto de los sistemas de administracion

de documentos y que lleva a esta investigacion a centrarse en la problematica puntual que

enfoca a Cyza Outsourcing en la adopcion e implementacion de este tipo de sistema para

resolver un problema existente que es el de la dispersion y falta de control sobre la creacion

y manipulacion de documentos resultantes de los procesos operativos que se llevan a cabo

dentro de la empresa.

1.7.2. Metodo de investigacion

La manera en que sera abordado el problema implica la identificacion del problema de forma

general conociendo que dicho problema es la ausencia de un sistema que administre las fuen-

tes de informacion y los documentos resultantes de cada proceso operativo. Una vez teniendo

conocimiento de esta falencia se procede a determinar los procesos mas puntuales y detalla-

dos que se ven afectados por la falta del sistema en cuestion. Por ultimo se especifica una

solucion que resuelve gradualmente la administracion documental desde una vista integral

en el aspecto organizacional hasta llegar a los procesos mas puntuales de cada operacion.

Habiendo descrito lo anterior se concluye que el metodo de investigacion sera de caracter

deductivo.

1.7.3. Fuentes y tecnicas para la recoleccion de la informacion

Fuentes primarias

Para poder implementar el sistema de administracion de documentos en Cyza Outsourcing

se debe hacer uso importante de fuentes primarias como las proporcionadas por toda perso-

na que haga parte de la organizacion y que genere documentacion propia de sus actividades

diarias. Para entender las necesidades que se quieren suplir sera necesario obtener informa-

cion a partir de entrevistas y cuestionarios con los responsables e implicados en los procesos

donde se tenga informacion de primera mano que describa puntualmente la manera en que

se produce la documentacion complementaria en cada area y cada departamento.


Fuentes Secundarias

De forma complementaria para lograr desarrollar el sistema de administracion de documen-

tos se hara uso de material descrito como fuentes secundarias para ser usadas como apoyo

al diseno y construccion del sistema objetivo. Algunas de las fuentes secundarias son:

Normatividad ISO (ISO 15489) sobre Sistemas de Administracion de Documentos

Documentacion de ASP.NET y aplicaciones Web.

Documentacion de aplicaciones desarrolladas en Android.

Guıa para la construccion de Aplicaciones y Servicios Web seguros

Normatividad ISO (ISO 9001) para entender los Sistemas de Gestion de Calidad.

1.7.4. Tratamiento de la informacion

La orientacion que tendra el desarrollo del proyecto estara marcado por los procedimientos

que son comunes en el desarrollo de software. En una primera instancia se hara el levanta-

miento de requerimientos necesario para obtener toda la informacion que permita recopilar

las necesidades que los usuarios describen por medio de las entrevistas. Toda informacion

obtenida sera manejada y plasmada en los formatos de entrevistas para luego ser estudiados

y detallados en los documentos de levantamiento de requerimientos. Posteriormente la inter-

pretacion de los requerimientos se transformara en funcionalidades de la aplicacion pasando

por una etapa de diseno que describe la manera en que sera construido el sistema. La fase de

implementacion llevara a cabo el desarrollo de la solucion y como etapa final se encontrara

la entrega que tendra toda documentacion referente a los manuales de usuario y manuales

tecnicos.

1.8. ALCANCES, LIMITACIONES Y RESULTADOS

ESPERADOS

1.8.1. Alcances

Este proyecto tiene como finalidad la construccion de un sistema de administracion de do-

cumentos funcional, que satisfaga las necesidades expuestas por Cyza Outsourcing S.A. en

cuanto al almacenamiento y consulta de los documentos que se generan internamente. El

sistema estara compuesto por dos grandes componentes: la aplicacion principal, que debera

ser totalmente web y la aplicacion de consulta movil, la cual debera ser implementada para

1.8 ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS 29

tecnologıas moviles.

Para la aplicacion principal se realizara la implementacion de las siguientes caracterısticas:

1. Autenticacion y autorizacion de usuarios

2. Configuracion de registros documentales

3. Carga de documentos y generacion de consecutivos

4. Actualizacion y versionamiento de documentos

5. Consulta de documentos

Para la aplicacion de consulta movil se implementaran las siguientes caracterısticas:

1. Autenticacion de usuarios

2. Consulta de documentos

La aplicacion web debera ser desplegada en los servidores de la companıa, y tendra que

estar disponible para ser accedida mediante una URL (Uniform Resource Locator) desde el

internet y desde la red interna de la companıa. En cuanto a la aplicacion movil, esta debera

ser implementada para dispositivos Android.

1.8.2. Limitaciones

La aplicacion web que se implementara permitira el almacenamiento de la documentacion

guardando la trazabilidad de fechas y responsables junto con los metadatos respectivos mas

no permitira la creacion de los documentos en la aplicacion misma, por lo que estara limita-

da al cargue y almacenamiento de documentos ya hechos por los usuarios de manera local

mediante algun procesador de texto.

Por su parte la aplicacion movil manejara un perfil orientado a la consulta de los documentos

previamente almacenados desde la aplicacion web a manera de visualizador. No contara con

la posibilidad de realizar actualizaciones a los registros existentes. Esta aplicacion debera

ser desarrollada para el ecosistema movil de Android; no tendra version para iOS ni para

windowsPhone, dado que no hay personal con dichas competencias dentro de la companıa.

Una vez finalizado el desarrollo se desplegara mediante archivos apk y no en la Google Play

Store, dado que la companıa no posee una cuenta de publicador en Play Services.


1.8.3. Resultados esperados

Los resultados que se esperan con el desarrollo del sistema de administracion de documentos

son los siguientes:

1. Proporcionar un mecanismo para almacenar de forma segura actas, manuales o cual-

quier otro recurso documental que sea generado dentro de la empresa.

2. Ordenar los documentos por actividades, de acuerdo con lo definido en el sistema de

gestion de calidad adoptado por la companıa.

3. Indexar los documentos almacenados en el sistema de gestion de documentos, permi-

tiendo realizar a los usuarios de la aplicacion busquedas de manera rapida y sencilla.

4. Permitir llevar la trazabilidad de los documentos de la companıa, permitiendo saber

la fecha y el nombre de la persona que realizo el cargue inicial o una actualizacion

posterior.

5. Permitir llevar el historial de versiones de cada documento, haciendo posible consultar

cualquier version del mismo en cualquier momento.

6. Proveer un esquema de autorizacion que solo permita consultar los documentos almace-

nados en el sistema a los usuarios que tengan los permisos necesarios para visualizarlos.

7. Entregar una aplicacion con buenas practicas de seguridad que garantice que los do-

cumentos almacenados en el sistema solamente puedan ser consultados a traves de la

aplicacion, esto mediante el cifrado de los mismos.

2. DESARROLLO DEL PROYECTO

2.1. Fase de levantamiento de datos

Se identifican los actores principales para definir las necesidades y requerimientos que desean

que el software satisfaga, todas estas solicitudes son llevadas a papel en un formato de “his-

torias de usuario”. De este proceso se genera documentacion de requerimientos, casos de uso

y se establece cronograma de actividades y desglose de trabajo (EDT).

2.1.1. Identificacion de interesados

Se enlistan las personas que estan en potestad para determinar requerimientos, definir las

funcionalidades, senalar las prioridades y responder a las preguntas del programador.

Tabla 2-1.: Listado de interesados Sistema de Gestion Documental

Nombres Organizacion Cargo Rol Proyecto Influencia

Leandro Ovalle Cyza Gerente Cliente, Tracker, Big Boss Muy Alta

Miguel Fajardo Cyza Calidad Cliente, Auditor interno Alta

Jhon Roldan Cyza Desarrollador Rol de Programador, coach Alta

Jorge Araque Cyza Desarrollador Rol de Programador, tester Media

Interventor Bureau Veritas Certificador Auditor externo Muy Alta

2.1.2. Historias de usuarios

Se realiza entrevista a los interesados del proyecto y se toman los datos de los requerimien-

tos en el formato “Historias de usuario”[14] utilizando un lenguaje comun y escribiendo

literalmente las ideas expresadas por los interesados. La informacion anotada se muestra a

continuacion.

32 2 DESARROLLO DEL PROYECTO

Tabla 2-2.: Historia de Usuario DD-HU-01

HISTORIA DE USUARIO

ID: DD-HU-01 PRIORIDAD EN NEGOCIO: Muy Alta

NOMBRE: Definicion y Creacion de un Sistema de Gestion Documental

USUARIO: Leandro Ovalle CARGO: Gerente

DESARROLLADORES ENCARGADOS: Jhon Roldan y Jorge Araque

DESCRIPCION:

Gerencia entiende la necesidad de tener un software capaz de gestionar y controlar los procesos

que se realizan en cada una de las dependencias de la empresa. Para ello requiere de una

aplicacion web que permita almacenar todo elemento documental que haya surgido de la

realizacion de una tarea especıfica en cada area de la empresa. Esta informacion debe poder

ser consultada para efectos de presentar informe ante las entidades certificadoras que realicen

auditoria externa con el fin de validar la Certificacion de Calidad ISO 9001 para Sistemas de

Gestion de Calidad. Es necesario que ademas este disponible en un escenario de acceso desde

fuera de la empresa para que los documentos almacenados que se encuentren en el software

puedan ser consultados y revisados desde cualquier lugar fuera de la companıa pero es

importante que no cualquier persona pueda llegar a ellos. Por lo tanto es importante que la

aplicacion exija comprobacion de un usuario previamente registrado en la aplicacion. Ademas

es importante que se pueda administrar el acceso a cada usuario permitiendo tener visible

unicamente la informacion que para el es importante que sera la relacionada con el area de la

empresa a la que pertenece. A su vez habran usuarios con mayor acceso como lo es la gerencia

y la coordinacion de calidad que podra visualizar la documentacion de las demas areas de la

empresa. Sin embargo estas personas no necesitan tener potestad de modificar el material

documental de otras areas, solo las propias.

OBSERVACIONES: El gerente se reune con el equipo de desarrollo y comenta su necesidad

de cara a mantener la certificacion de calidad otorgada en el ano 2015.

2.1 Fase de levantamiento de datos 33


HISTORIA DE USUARIO

ID: DD-HU-02 PRIORIDAD EN NEGOCIO: Alta

NOMBRE: Cumplimiento de los estandares de calidad

USUARIO: Gerencia y Calidad CARGO: Gerencia y Calida


DESCRIPCION:

La Alta Gerencia y la direccion de Calidad hace seguimiento exhaustivo del futuro software

porque debe asegurarse de que el uso de la aplicacion cumpla con las condiciones necesarias

conforme a los lineamientos de Control de Calidad. La alta gerencia requiere que el

Sistema de Gestion Documental sea capaz de estructurar cada area como un proceso

que debe tener una descripcion clara de lo que se realiza allı. A su vez se puede ramificar en

varios subprocesos que deben contener unos objetivos, un alcance, una referencia normativa,

un glosario de terminos, un componente de responsabilidades. Finalmente cada subproceso

puede definir varias actividades que deben estar soportadas con un soporte documental, para

el caso de Cyza puede ser un documento con consecutivo o una bitacora que evidencie la

realizacion de determinada actividad. Tanto el documento con consecutivo como el registro

en bitacora deben contener una fecha de creacion, un responsable de la actividad y su

correspondiente descripcion de la actividad realizada. El objetivo de implementar bitacoras

es suplir la necesidad de documentar una actividad pero evitando generar todo un documento

fısico para las tareas sımples

OBSERVACIONES: Lo descrito aquı es un consenso entre la Alta Gerencia conformado por

el Gerente en cabeza, las direcciones y la asesorıa de Certificacion de Calidad. Por eso no se

definen nombres propios como autores de este requerimiento.



HISTORIA DE USUARIO

ID: DD-HU-03 PRIORIDAD EN NEGOCIO: Muy Alta

NOMBRE: Identificacion y soporte documental de los procesos por areas

USUARIO: Miguel Fajardo CARGO: Coordinador de Calidad


DESCRIPCION:

Se requiere que cada una de las areas de la companıa defina los formatos de documentacion

relacionados en su respectiva dependencia donde puedan quedar evidenciados los procesos

que al interior de cada dependencia se realizan. Es importante que cada coordinador defina

un flujo de actividades que describa las tareas hechas en su dependencia y que sea de

conocimiento de todos los miembros del equipo.

OBSERVACIONES: Cada departamento tiene la libertad de definir y describir los procesos

realizados en cada una de ellas. Lo importante es que conozcan dicho proceso.


HISTORIA DE USUARIO


NOMBRE: Consulta mediante dispositivos moviles

USUARIO: Jhon Roldan CARGO: Desarrollador Coach


DESCRIPCION:

Para agregar un componente de accesibilidad a la informacion y consulta, se requiere realizar

un desarrollo para dispositivos moviles que permita acceder al sistema de gestion documental

desde un smartphone para efectos de consulta de documentos sin posibilidad de modificacion

con su respectivo proceso de autenticacion de usuarios.

OBSERVACIONES: El desarrollo contempla unicamente terminales Android.



HISTORIA DE USUARIO


NOMBRE: Trazabilidad de tareas.

USUARIO: Interventor CARGO: Auditor externo de calidad


DESCRIPCION:

Todo proceso documentado en la empresa debe tener un consecutivo que lo diferencie de otro

documento sımil. Dicho documento debe tener un autor identificable y una fecha de

generacion. En caso de una auditorıa si se exije la presentacion de un documento que soporte

la tarea en revision, este soporte documental debe ser presentado ya sea fısicamente o como

un registro valido en un sistema de software.

OBSERVACIONES: Las sugerencias descritas aquı fueron realizadas durante una jornada de

auditorıa externa.


HISTORIA DE USUARIO


NOMBRE: Control de cambios en los documentos

USUARIO: Interventor CARGO: Auditor externo de calidad


DESCRIPCION:

Todo material documental generado en una organizacion es valioso, por tal motivo es de vital

importancia conservar todos y cada uno de ellos incluso si en el proceso hay modificaciones

de los mismos. Para ello se requiere realizar un control de versiones sobre los soportes a nivel

documental que se generen sobre las actividades de cada departamento. En caso de ser pedida

una version previa al documento, dicha version debe existir y ser proporcionada.

OBSERVACIONES: Las sugerencias descritas aquı fueron realizadas durante una jornada de

auditorıa externa.


2.1.3. Levantamiento de requerimientos

Una vez realizada la captura documental de las necesidades e intereses de las personas im-

plicadas en el proyecto mediante el uso de historias de usuario, lo que sigue es formalizar y

definir los requerimientos resultantes de la etapa de escucha. Para lo cual se tiene en cuenta

una de las definiciones de un requerimiento como “Una condicion o necesidad de un usuario

para resolver un problema o alcanzar un objetivo”.[1]

La ingenierıa de requerimientos es una extensa disciplina que estudia tecnicas y procedi-

mientos para obtener e interpretar las necesidades de las personas interesadas. En general

existen diversas tecnicas para este fin pero en este proyecto particular se decide implemen-

tar la tecnica de historias de usuario. Lo que viene a continuacion es tomar cada historia y

obtener de allı toda informacion relevante para el desarrollo de futuro software y a su vez

identificar si se trata de un requerimiento funcional o un requerimiento no funcional. Los

requerimientos funcionales son aquellos que definen las funciones que la aplicacion sera capaz

de realizar, describe las transformaciones que el sistema hara sobre las entradas para obtener

sus respectivas salidas mientras que los requerimientos no funcionales son caracterısticas de

orden cualitativo que representan las limitaciones del sistema, como la capacidad, el rendi-

miento en terminos de tiempo, la calidad ya sea de la informacion o de los procesos que se

realizan dentro del software, la seguridad de la informacion o la accesibilidad.

Los requerimientos deben cumplir las siguientes caracterısticas:[1]

Especificado por escrito: Como todo contrato o acuerdo entre dos partes debe tener un

soporte fısico debidamente diligenciado.

Verificable: Si un requerimiento no se puede comprobar, entonces ¿como se sabe si se

cumplio con el o no?

Conciso: Un requerimiento es conciso si es facil de leer y entender. Su redaccion debe

ser simple y clara para aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento esta completo si no necesita ampliar detalles en su redac-

cion, es decir, si se proporciona la informacion suficiente para su comprension.

Consistente: Un requerimiento es consistente si no es contradictorio con otro requeri-

miento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacion. El

lenguaje usado en su definicion, no debe causar confusiones al lector.


Tabla de requerimientos

El resultado del ejercicio de interpretacion de las historias de usuario arroja como resultado

la generacion de documentos de requerimientos que describen de forma concisa la funcionali-

dad que espera ser cubierta por el analista y que de ser aprobado llegara a conformar parte de

las caracterısticas del software en construccion. La siguiente tabla resume los requerimientos

levantados que se encuentran en el Anexo A del presente documento.

Tabla 2-8.: Tabla de requerimientos

CONSECUTIVO SOLICITANTE DESCRIPCION

REQ-FNC-01 Leandro Ovalle Creacion de un Sistema de Gestion Documental.

REQ-FNC-02 Leandro Ovalle Construccion de un modulo de registro de usuarios.

REQ-FNC-03 Leandro Ovalle Modulo de gestion y administracion de usuarios.

REQ-FNC-04 Leandro Ovalle Modulo de creacion de procesos.

REQ-FNC-05 Leandro Ovalle Modulo de creacion de subprocesos.

REQ-FNC-06 Leandro Ovalle Modulo de creacion de actividades.

REQ-FNC-07 Miguel Fajardo Modulo de cargue de archivos.

REQ-FNC-08 Interventor Modulo de versionamiento de documentos.

REQ-FNC-09 Jhon Roldan Componente de consulta para dispositivos moviles.

REQ-NFN-01 Jhon Roldan Componente de cifrado para asegurar documentos.

REQ-NFN-02 Jhon Roldan Uso de plantillas de visualizacion de la companıa.


2.2. Fase de planeacion

Para desarrollar la etapa de planeacion se hace uso de la teorıa de la Arquitectura Empre-

sarial como instrumento de analisis que permita describir en diferentes niveles la proyeccion

que tendra el Sistema de Gestion de Documentos dentro de la companıa. Aunque la concep-

cion de Arquitectura Empresarial no fue prevista durante la primera fase de este proyecto,

se adopta esta metodologıa como herramienta de apoyo para manifestar los componentes de

software y hardware, el componente motivacional que impulsa a la realizacion de la solucion

que sera construida y los componentes organizacionales que estaran implicados en el proceso.

2.2.1. Arquitectura empresarial

”La Arquitectura Empresarial es una metodologıa que, basada en una vision integral de las

organizaciones (...) permite alinear procesos, datos, aplicaciones e infraestructura tecnologi-

ca con los objetivos estrategicos del negocio o con la razon de ser de las entidades. (...)

Su principal objetivo es garantizar la correcta alineacion de la tecnologıa y los procesos de

negocio en una organizacion, con el proposito de alcanzar el cumplimiento de sus objetivos

estrategicos”[6].

Teniendo en cuenta la anterior definicion, la arquitectura empresarial provee un mecanismo

ideal para identificar los multiples factores que pueden tener incidencia durante un proceso

de cambio que pueda acontecer al interior de la companıa, permitiendo que estos puedan ser

categorizados y tenidos en cuenta durante la fase de transicion e implantacion del mismo, lo

que permite:

Garantizar que todos los elementos y recursos que se encuentran en las areas y pro-

cesos afectados por la implantacion de un cambio determinado se integren de forma

homogenea.

Poder realizar una mesura inicial estimada del impacto causado en actores y procesos

que tienen lugar en la companıa.

Determinar quienes seran los actores involucrados.

Identificar las funciones de aplicacion requeridas para la implantacion de la nueva

solucion.

Identificar los recursos de infraestructura necesarios para el eventual despliegue de la

solucion.

Durante el analisis de arquitectura empresarial, se tuvieron en cuenta multiples capas (ne-

gocio, aplicacion, infraestructura, motivacional), en donde, para cada una se definieron unos

2.2 Fase de planeacion 39

determinados puntos de vista, en los cuales se reflejaron las preocupaciones de cada uno de

los implicados y participantes en el proceso de diseno y construccion de la solucion aquı

propuesta[8].

2.2.2. Capa de negocio

Punto de vista de proceso de negocio Este punto de vista se encarga de mostrar los

principales procesos de negocio en conjunto con las interacciones con roles, servicios, eventos

y objetos[10].

Figura 2-1.: Punto de vista de proceso de negocio


En este punto de vista se indica que el proceso que intentara apoyar la solucion propuesta es el

de almacenamiento de registros documentales; mostrando los eventos que lo desencadenan,

ası como los roles y actores que intervendran, ası en conjunto con la localizacion de los

mismos. Tambien se denota, de forma implıcita que la solucion propuesta solo sera aplicable

a los empleados de la companıa.


2.2.3. Capa de aplicacion

Punto de vista de comportamiento de aplicacion El punto de vista de comportamiento

de la aplicacion describe el comportamiento interno de una aplicacion, y es usado principal-

mente para disenar su comportamiento principal[9].

Figura 2-2.: Punto de vista de comportamiento de aplicacion


En este punto de vista se pueden ver las funciones y los modulos propuestos para la cons-

truccion de la aplicacion y su interaccion entre sı:

Funcion de consulta: Permite consultar los registros documentales almacenados en la

aplicacion (siempre y cuando tenga privilegios suficientes para realizar tal accion).

• Modulo de consulta web: Permitira consultar los registros documentales mediante

una pagina web determinada que sera alojada en los servidores de la companıa

• Modulo de consulta movil: Permitira consultar los registros documentales me-

diante un smartphone (con sistema operativo Android) empleando una aplicacion

construida para tal fin.

Funcion de almacenamiento de registros documentales: Permitira a los usuarios alma-

cenar un registro documental en el repositorio de documentos.


• Entregar numero consecutivo: Generara un numero unico y con la nomenclatura

especificada para el registro documental que se desea almacenar. Este consecutivo

servira para identificar el registro de manera unica e inequıvoca en el sistema.

• Entregar plantilla o formato: Entregara al usuario la plantilla definida para el

registro documental especificado. Esta plantilla debera ser llenada por el usuario

con informacion especifica de la operacion.

• Almacenar archivo: Permitira al usuario cargar la plantilla diligenciada que le fue

entregada mediante la funcion Entregar plantilla o formato.

• Agregar relaciones: Permitira al usuario relacionar el registro documental que esta

cargando con otros registros documentales ya existentes, ademas de proporcionar

un campo que permita incluir informacion para determinar la naturaleza de la

relacion.

• Versionar registro: Permitira conservar la trazabilidad de un registro documental,

almacenando la version que va a ser reemplazada con la mas actual y generando un

numero consecutivo de versionamiento, ası como informacion que permita rastrear

la fecha y el usuario encargado de almacenarla en el sistema.

Funcion de autenticacion y autorizacion: Estas funciones emplearan el modulo de con-

trol de acceso, y se encargarian de permitir el acceso de un usuario al sistema, y

posteriormente, determinarıan si este cuenta con los privilegios suficientes para poder

acceder al repositorio de documentos.

Funcion de cifrado de registros documentales: Esta funcion empleara el modulo de

seguridad y permite aplicar un algoritmo de cifrado a los registros documentales para

asegurar la privacidad de la informacion una vez que esta se encuentre almacenada en

la base de datos. Esta funcion se incluye como respuesta a los analisis derivados del

estudio del anexo A de la norma ISO 27001[22].

Funcion de configuracion: Esta funcion usa el modulo de configuracion para permitir

al usuario administrador del sistema configurar los parametros del mismo. Estos pa-

rametros afectaran la informacion mostrada del sistema de gestion de calidad y sus

elementos, ası como de los registros documentales almacenados.


Punto de vista de uso de aplicacion El punto de vista de uso de la aplicacion se describe

como se utilizan las aplicaciones para soportar uno o mas procesos de negocio, y la forma en

que son utilizados por otras aplicaciones [9].

Figura 2-3.: Punto de vista de uso de aplicacion


Luego de haber analizado las necesidades establecidas por los participantes, se muestran

como los servicios expuestos por diferentes componentes de la aplicacion apoyan el proceso

de negocio: Construccion de una herramienta para administrar registros documentales. Este

diagrama es de alto nivel, por cuanto no esta enfocado a mostrar aspectos tecnicos, sino a

ilustrar el apoyo de la herramienta planteada a un proceso especifico.


2.2.4. Capa de infraestructura

Punto de vista de infraestructura Contiene el software y los elementos de la infraestruc-

tura fısica que apoyan a la capa de aplicaciones, como dispositivos fısicos, redes o sistemas

de software (sistemas operativos, bases de datos y middleware, etc.)[25].

Figura 2-4.: Punto de vista de infraestructura


La solucion que se pretende desarrollar debera acoplarse a la infraestructura de hardware

existente, esto implica que la companıa no realizara desembolso alguno para la adquisicion o

aprovisionamiento de activos de tecnologıas de la informacion adicionales a los ya existentes;

es por esto que los elementos mostrados en el punto de vista corresponden a los ya presentes

en la actualidad que se encuentran en funcionamiento al interior de la companıa.

La aplicacion sera alojada en un servidor virtual de aplicaciones (Windows server 2008R2),

el cual a su vez empleara IIS (Internet Information Services) para responder las peticiones

realizadas a la aplicacion, El mecanismo de virtualizacion empleado por el host para dicha

maquina virtual es Hyper-V y el sistema operativo es Windows Server 2008R2.

La base de datos sera alojada en un servidor que cuenta con un sistema operativo Windows

Server 2008R2 y SQL Server 2008R2 como motor de base de datos.


En el apartado de redes y comunicacion, los servidores anteriormente mencionados se en-

cuentran en una zona desmilitarizada (DMZ), protegidos por un firewall, el cual permite el

acceso hasta el servidor de aplicaciones por el puerto 443 mediante protocolo SSL. Al interior

de la companıa, la aplicacion podra ser accedida por cualquier usuario sin problema alguno,

esto siempre y cuando cuente con privilegios para utilizar la aplicacion.

Punto de vista de capas El punto de vista en capas muestra multiples imagenes de dis-

tintas capas y aspectos de una arquitectura empresarial en un unico diagrama. Hay dos

categorıas de capas, capas de negocios y capas de servicios. Las capas son el resultado de

la utilizacion de la relacion agrupacion para una particion natural de todo el conjunto de

objetos y relaciones que pertenecen a un modelo [9].

Figura 2-5.: Punto de vista de capas



En el modelo de capas expuesto, se muestran los principales elementos de la aplicacion en

cada capa (negocio, componentes de la aplicacion e infraestructura) y las interacciones que

tienen lugar entre ellos. Este punto de vista tiene como finalidad mostrar una vision general

e integral de la aplicacion, que permita a quien la revise comprender el planteamiento de la

misma, ası como identificar sus componentes.

2.2.5. Capa de motivacion

Punto de vista de motivacion El punto de vista de motivacion permite al disenador o

analista modelar el aspecto de motivacion, sin centrarse en determinados elementos dentro

de este aspecto. Por ejemplo, este punto de vista se puede utilizar para presentar una vision

completa o parcial del aspecto la motivacion por los stakeholders relacionados, sus objeti-

vos principales, los principios que se aplican, y los principales requerimientos de servicios,

procesos, aplicaciones y objetos [12].

Figura 2-6.: Punto de vista de motivacion


En el punto de vista de motivacion se muestran los elementos que generaron la necesidad de

la aplicacion planteada en este documento:

El ente auditor que se encargo de realizar la revision del sistema de gestion de calidad de

la companıa genero una observacion en la ultima revision, debido al manejo inadecuado

de los registros documentales. Dicha observacion debe ser solventada en la siguiente

revision, so pena de que la certificacion de calidad sea revocada.


Por otro lado, y como paso inicial para la preparacion hacia la certificacion de seguridad

de la informacion ISO 27001, se decidio iniciar con la implementacion de algunos de

los controles ubicados en el anexo A. Sin embargo, esta actividad fue voluntaria, por

lo que no hay consecuencias derivadas de la no implementacion.

Dado que la iniciativa fue impulsada por el area de calidad (con la aprobacion y el apoyo

de la gerencia), es el coordinador de auditorıa el principal interesado en el desarrollo de la

aplicacion.

2.2.6. Conclusion del proceso de arquitectura empresarial

Una vez realizada la arquitectura empresarial de la companıa, se pudo obtener una vision

estandarizada de algunos procesos de vital importancia para la misma, al mismo tiempo que

se identificaron los requerimientos de software necesarios para suplir una necesidad especifica:

1. Suministrar una herramienta informatica que permita realizar una gestion adecuada de

los registros documentales generados durante el desarrollo de los procesos operativos

de la companıa.

2. Apoyar mediante herramientas informaticas el proceso de auditorıa y de calidad de

la companıa, contribuyendo asi a su optimizacion y expansion al interior de todas las

areas.

3. Iniciar la revision y/o implementacion de controles que permitan asegurar los activos

de informacion de la companıa.

La creacion de la aplicacion aquı propuesta pretende ayudar a la companıa a sostener la

certificacion de calidad obtenida, resarciendo la observacion generada en la ultima auditorıa

externa; al mismo tiempo que emprende una accion de mejora que deberıa propender en

mejoras en los procesos de comunicacion y divulgacion de informacion en las distintas areas

de la companıa. Por otro lado, es un primer acercamiento con miras a la obtencion de otros

tipos de certificacion, en aras de proveer elementos diferenciadores en el mercado con res-

pecto a los demas competidores.

2.2.7. Plan de proceso de desarrollo

Para el desarrollo se utiliza el metodo de programacion extrema utilizando prototipo co-

rregido sobre el proyecto base incluyendo modulos y tareas simplificadas que puedan ser

elaboradas puntualmente y de manera posterior ser integradas al proyecto. La secuencia de

desarrollo se presenta a continuacion:


Figura 2-7.: Diagrama de Representacion del proceso de desarrollo


2.2.8. Plan de Pruebas

El proceso de pruebas se divide en pruebas unitarias, pruebas de integracion y pruebas de

aceptacion todas realizadas mediante el metodo de caja negra.

Pruebas Unitarias

Se realizan pruebas al codigo resultado de cada ciclo de desarrollo y definiendo la aceptacion

funcional y ası proceder a indexar al prototipo base del proyecto. Estas pruebas no requieren

registro y el tecnico de desarrollo es el encargado de realizarlas.


Pruebas de Integracion

Se realizan pruebas de funcionalidad del prototipo base del proyecto cada vez que se integra

una funcionalidad o modulo, definiendola aceptacion funcional integral en el prototipo base

del proyecto. Se diligencia formato de “Formato de Pruebas de software” (Anexo DD-FPS).

Pruebas de Aceptacion

Se realizan pruebas del prototipo base de proyecto integrado en su totalidad para verificar

la funcionalidad del programa en general y su aceptacion y posterior implementacion a pro-

ductivo. El proyecto base deja de ser prototipo y pasa a ser el software como tal, Sistema

de Gestion de Inventarios. Se diligencia formato de “Formato de Pruebas de Aceptacion”

(Anexo DD-FPA).

2.2.9. Plan de Control de Cambios

Despues de realizar las pruebas, los codigos que no cumplen con los objetivos funcionales, se

procede a realizar los cambios requeridos.

Si la solicitud de cambio se origina de una prueba unitaria, se realiza recodificacion inme-

diata y se vuelve hacer la prueba, se itera cuantas veces sea necesario hasta alcanzar los

requerimientos funcionales requeridos.

En el caso de generar requerimiento de cambio a partir de una prueba integral o de acepta-

cion, se debe verificar la documentacion diligenciada en los formatos de pruebas de software

y proceder a realizar re codificacion y cambios en el prototipo. Estos cambios son docu-

mentados en el documento “Formato de control de cambios de software” (Anexo DD-FCC).

Luego se vuelve a realizar pruebas.

2.2.10. Plan de Cierre de Proyecto

Superada la fase de pruebas, se realiza la entrega del Sistema de Gestion Documental a Cyza

por medio digital, con los respectivos manuales de administracion y de usuario. Todo queda

oficializado en documento debidamente firmado, mediante el formato “Acta de Entrega de

Satisfaccion” (DD-AES).


2.2.11. Estructura de Desglose de Trabajo (EDT)

Segun La Guıa del PMBOK[19], “la Estructura de Desglose del Trabajo (EDT)[18] es una

descomposicion jerarquica, orientada al producto entregable del trabajo que sera ejecutado

por el equipo del proyecto, para lograr los objetivos del proyecto y crear los productos en-

tregables requeridos”.

El logro de los objetivos del proyecto requiere de una EDT que defina todos los esfuerzos

requeridos, la asignacion de las responsabilidades a un elemento definido de la organizacion

y que a partir de la EDT se establezca un cronograma y presupuesto adecuado para la rea-

lizacion de los trabajos.

La EDT organiza y define el alcance total del proyecto y representa el trabajo especificado en

la declaracion del alcance del proyecto aprobada y vigente. El trabajo planificado esta con-

tenido en el nivel mas bajo de los componentes de la EDT, denominados paquetes de trabajo.

Un paquete de trabajo puede ser programado, monitoreado, controlado, y su costo puede

ser estimado. En el contexto de la EDT, trabajo se refiere a los productos o entregables del

proyecto, que son el resultado del esfuerzo realizado, y no el esfuerzo en sı mismo.


Figura 2-8.: Estructura de desglose de trabajo propuesta


2.3 Fase de ejecucion 51

2.3. Fase de ejecucion

2.3.1. Modificacion modulo de control de acceso

Creacion de nuevos modulos en base de datos

El modulo de control de acceso de la aplicacion de Intranet ofrece funcionalidades que ya

se han empleado en entornos de produccion, y por lo tanto se encuentran probadas y do-

cumentadas. Haciendo uso del principio de reutilizacion de codigo, se aprovecharon dichas

funcionalidades para incorporarlas en el nuevo proceso de codificacion. Se modificaron las

estructuras, repositorios. listas y los procedimientos almacenados que correspondıan a dicho

modulo. Los siguientes elementos fueron alterados:

1. Tabla Modulos en la base de datos, en donde se agregan los nuevos modulos que va a

contener la aplicacion destinados a exponer las distintas funcionalidades que se planean

agregar. La actividad fue finalizada dentro de los tiempos establecidos para la misma.

2. Enumeracion Modulos en la capa de negocio, en donde se representan mediante cons-

tantes los modulos de la aplicacion insertos en la base de datos, que luego seran ma-

peados hacia una lista de control de acceso. La actividad fue finalizada dentro de los

tiempos establecidos para la misma.

Figura 2-9.: Enumeracion de modulos (codigo fuente)


3. Se modifica el componente validador de listas de control de acceso para aceptar los

modulos nuevos creados en la aplicacion, definiendo las secuencias de autorizacion

(para la autenticacion no se realizaron modificaciones) que permitirıan tener acceso a

los modulos nuevos. La actividad fue finalizada dentro de los tiempos establecidos para

la misma.


Construccion del modulo de seguridad

Teniendo en cuenta que en el diseno de la aplicacion se incluyeron algunos de los controles

mencionados en el anexo A de la norma ISO 27001, se realiza una implementacion del algo-

ritmo de cifrado AES-128 [23] para realizar proteger de lecturas no autorizadas los archivos

que contienen la informacion de los registros documentales. Al ser un algoritmo de cifrado

simetrico, una parte de la llave se mantiene estatica, mientras la otra, es dinamica acorde a

ciertos parametros, por lo que, la clave de de-cifrado cambia para cada registro documental.

1. Creacion de clases para cifrado AES128, se genero una clase interna (solo accesible

para las clases del ensamblado de negocio), la cual se encarga de procesar los archivos

a nivel de bytes mediante un cifrado AES-128 CBC y una clave que es generada de

forma dinamica e individual para cada archivo.

2. Creacion de clases para decifrado AES128, se genero una clase interna (solo accesible

para las clases del ensamblado de negocio), la cual se encarga de procesar los archivos

a nivel de bytes y calcular la llave de de-cifrado, la cual sera empleada para reversar

las operaciones realizadas y permitir que el contenido de los archivos pueda ser leıdo

nuevamente.

La clave debe ser, en parte, dinamica por motivos de seguridad. Es por esto que una mitad

de la misma se incluira en el codigo fuente (debido a que AES es un algoritmo de cifrado

simetrico), mientras que la otra debera ser derivada de un parametro variable que sera

calculado en la parte del cliente y del servidor mediante la implementacion de un algoritmo

para tal fin.

Construccion de modulos de configuracion

La aplicacion debe permitir configurar los diferentes componentes que la integran, con la

finalidad de que la informacion almacenada y representada en la misma, ası como las funcio-

nalidades implementadas correspondan a las necesidades y requerimientos de los usuarios,

y que modele a cabalidad los procesos de la companıa que sean incluidos en esta. Debido a

esto se deben implementar los mecanismos necesarios que le permitan a los administradores

del sistema configurar de manera rapida y simple los diferentes modulos que forman parte

de la solucion.

1. Creacion del modulo de configuracion de procesos: Este modulo permite configurar

los principales procesos del sistema de gestion de calidad que seran mostrados en la

aplicacion. Basicamente permite indicar el nombre de los principales procesos de la

companıa en conjunto con una descripcion de los mismos. Esta funcion es meramente

informativa y corresponde a la necesidad de (segun las normas establecidas por la

certificacion ISO9001) de permitir a los usuarios consultar dicha informacion de manera

rapida y sencilla.


Figura 2-10.: Modulo de configuracion de procesos


2. Creacion del modulo de configuracion de subprocesos: Segun el sistema de gestion de

calidad definido por la companıa, un proceso es compuesto a su vez por multiples

subprocesos, los cuales se enfocan en actividades propias del proceso para el cual son

definidos. Al igual que los procesos, los subprocesos fueron incluidos debido a que la

informacion contenida en los mismos debe estar disponible para todo el personal, y

aunque la principal funcion de estos dentro de la aplicacion tambien es informativa,

los subprocesos estan compuestos por muchos mas elementos en comparacion con los

procesos:

a) Version: es un numero que permite identificar el numero de la revision del sub-

proceso. Este numero cambia de forma automatica cada vez que se modifica un

elemento que compone el subproceso.

b) Proceso asociado: El cual permite indicar a que proceso esta asociado el subpro-

ceso. Por ejemplo, el subproceso de desarrollo debe estar asociado al proceso de

gestion tecnologica.

c) Responsables del subproceso: Aquı se especifican los cargos (no personas) que son

responsables del subproceso que esta siendo definido. Un subproceso puede ser

responsabilidad de multiples cargos.

d) Objetivos: Esta seccion es donde deberan ser definidos el o los objetivos de un

subproceso.

e) Alcance: Aquiı se indican los limites del subproceso. Se debe especificar claramente

hasta donde se espera que este deba llegar.


f ) Referencias normativas: si existen estandares, normas o legislaciones especiales a

las que un determinado subproceso se encuentre ligado, estas deben ser referen-

ciadas en esta seccion.

g) Glosario: aquı se enumeran las palabras o terminos de caracter tecnico (en conjun-

to con su definicion) y que sean referenciados de forma constante en el subproceso,

con la finalidad de que la informacion contenida acerca de este sea comprensible

para quien la lee.

Figura 2-11.: Modulo de configuracion de subprocesos


3. Creacion del modulo de configuracion de actividades: Los subprocesos son divididos

en actividades, representando estas la mınima unidad que compone los procesos acor-

de al sistema de gestion de calidad definido dentro de la companıa. Las actividades

comprenden todas aquellas labores, oficios o tareas que los empleados de la companıa

desarrollan en el dıa a dıa, y para las cuales, se debe dejar evidencia acerca de su eje-

cucion. Dicha evidencia no depende de forma exclusiva de los trabajadores (pudiendo

esta ser responsabilidad de los coordinadores) y que es posible almacenar en forma de

documento (registro documental) o dentro de una bitacora (entrada en la bitacora).

Para las actividades se definen los siguientes campos:

a) Un archivo adjunto: que corresponde a una imagen que ilustre o explique de forma

grafica los aspectos mas relevantes de la actividad. Normalmente se trata de un

flujograma.

b) El nombre de la actividad: el cual sera usado para que los usuarios identifiquen

de manera rapida dicha actividad.


c) Descripcion de la actividad: en donde se describira minuciosamente todos los

aspectos que corresponden a dicha actividad, de forma tal, que pueda ser com-

prendida facilmente por el lector.

Figura 2-12.: Modulo de configuracion de actividades


4. Creacion de la pagina de visualizacion del sistema de gestion de calidad: Es necesario

que la informacion suministrada en los modulos de configuracion que fueron desarro-

llados anteriormente pueda ser visualizada por todos los empleados vinculados a la

companıa. Por esta razon, es necesaria una pagina que se encargue de compilar los

contenidos y mostrarlos de forma ordenada al lector. La pagina de visualizacion de

contenidos del sistema de gestion de calidad estara dividida en dos partes:

a) Procesos y subprocesos: En donde se deberan mostrar los procesos y su descrip-

cion, ademas de sumarizar los subprocesos contenidos en cada proceso.


Figura 2-13.: Pagina de seleccion de procesos y subprocesos


b) Subproceso y actividades: En donde se mostrara el detalle del subproceso (En

esta pagina se muestra la version, objetivo(s), glosario de terminos, responsables,

diagramas de flujo, etc.) en conjunto con todas las actividades que componen el

subproceso y los registros documentales que deben ser registrados como evidencia

de su cumplimiento.

Figura 2-14.: Pagina de visualizacion de detalle de subproceso



c) Creacion de la pagina de configuracion de registros documentales: Cada subproce-

so puede contener una o mas actividades, y cada una de estas actividades a su vez

puede contener registros documentales o entradas en la bitacora como evidencias

de su ejecucion. Es por esto que es necesario un modulo en el cual se puedan con-

figurar cada uno de los registros documentales mencionados anteriormente, para

lo cual:

1) Proceso, subproceso y actividad: Son tres listas desplegables cuyos valores

se encuentran enlazados entre si, que sirven para indicar la pertenencia del

registro documental que se esta definiendo.

2) Tipo de registro: Permite indicar si el registro documental que se esta defi-

niendo se trata de un documento o una entrada en la bitacora; cada una de

estas opciones tiene caracterısticas propias.

3) Nombre: Permite al usuario identificar mediante un nombre al registro do-

cumental que se esta definiendo. Esto solo aplica para los registros de tipo

Registro documental.

4) Nomenclatura: Permite configurar como seran entregados los consecutivos de

los documentos pertenecientes al registro documental que esta siendo definido.

Esto solo aplica para los registros de tipo Registro documental.

5) Plantilla registro: Permite cargar un documento que podra ser descargado y

usado como plantilla para todos los registros pertenecientes al registro docu-

mental que esta siendo configurado. Esto solo aplica para los registros de tipo

Registro documental.

Figura 2-15.: Modulo de configuracion para registros documentales


6) Bitacora: Listado desplegable con las bitacoras activas en la aplicacion. Per-

mite vincular una bitacora con un registro documental, para el caso en el


que un documento no sea requerido. Solo aplica cuando el tipo de registro

seleccionado sea Bitacora.

Figura 2-16.: Modulo de configuracion para bitacoras


5. Creacion de modulos web de almacenamiento: Una de las funciones principales definida

para la implementacion en curso es la de cargue de archivos o registros documentales.

Esta funcion permite a un usuario cargar un archivo que sirve como evidencia de

la ejecucion de una actividad o salida de la misma, almacenandola en el sistema de

manera segura y haciendo que esta este disponible para quien lo requiera dentro de la

companıa. Dentro de la estructura de desglose de trabajo definida, la construccion de

los modulos encargados de implementar esta funcion fueron divididos en cuatro partes:

a) Modulo de solicitud de consecutivo: Las evidencias que son almacenadas como re-

gistros documentales deben poder ser identificadas mediante un consecutivo que

es conformado mediante una nomenclatura determinada, esto permite su indexa-

cion y consulta en situaciones posteriores. Se debe garantizar que el consecutivo

generado es unico e irrepetible, de forma tal que este consecutivo pueda ser em-

pleado como un identificador inequıvoco en futuras referencias dentro de otros

documentos.


Figura 2-17.: Modulo de solicitud de consecutivos


b) Modulo de cargue de archivo: Luego de tener el numero consecutivo, el usuario de-

be descargar y diligenciar la plantilla entregada en el paso anterior, completando

la informacion solicitada para luego proceder a guardarla en el sistema de admi-

nistracion de documentos. Una vez cargado el registro documental, este no podra

ser eliminado; sin embargo, nuevas versiones del mismo podran ser cargadas, para

las cuales el sistema conservara un registro historico ordenado cronologicamente,

al tiempo que versionara automaticamente el registro documental. Se permite el

cargue de multiples archivos debido a que algunos tipos registros documentales

son compuestos por mas de un archivo.

Figura 2-18.: Modulo de cargue de archivos



c) Modulo de especificacion de relaciones: Algunos registros documentales se en-

cuentran vinculados, debido a esto, es necesario poder identificar dichas relacio-

nes cuando se realice alguna consulta. Para solucionar este requerimiento, se crea

una interfaz que permite seleccionar varios registros documentales y agregar una

observacion, en donde se indica la relacion que ambos poseen, por ejemplo: una

propuesta comercial que el cliente autoriza, puede dar lugar a un levantamiento de

requerimientos, razon por la cual la relacion entre los dos registros documentales

debe poder mostrarse de manera explicita.

Figura 2-19.: Modulo de de especificacion de relaciones


d) Creacion del modulo de versionamiento: El sistema de administracion de docu-

mentos funge como en repositorio historico, es por eso que la opcion de eliminacion

de registros documentales no esta implementada, y no se planea hacerlo en itera-

ciones futuras. Es por esto, que se implemento un control de cambios, el cual se

encarga de almacenar un historico de versiones de cada registro documental, lo

que permite que una ”fotografıa”de este sea mostrada en un instante cronologi-

co determinado, llevando ası la trazabilidad y el numero de cambios (versiones)

realizados.


Figura 2-20.: Modulo de versionamiento


6. Construccion de los modulos de consulta: La informacion almacenada en el sistema

de administracion de documentos empleando los modulos mencionados en el numeral

cinco, debe poder ser consultada por los usuarios mediante algun tipo de mecanismo;

teniendo esto presente, se desarrollaron multiples opciones para facilitar las consultas

al sistema:

a) Servicios web JSON: Un servicio web fue desarrollado empleando el protocolo

REST (se decidio optar por este protocolo debido a que representa multiples

ventajas como menor cantidad de datos generados en la trama, compatibilidad y

facilidad de implementacion)[11]. Este servicio permite que otras aplicaciones se

integren con el API (Interfaz de programacion de aplicaciones) [16] de consulta

de los servicios. Provee mecanismos para autenticacion, autorizacion y busqueda

de informacion.

Figura 2-21.: Retorno de uno de las operaciones del servicio web (JSON)


b) Modulo de consulta web: Se creo una pagina web en la cual se permite la bus-


queda de registros documentales mediante el numero de consecutivo (o una parte

de el). Los resultados seran desplegados en una rejilla, en donde se mostrara la

informacion mas relevante (quien lo cargo en el sistema, cuando, la cantidad de

versiones) y se permitira descargar el/los documentos que conforman el registro

documental.

Figura 2-22.: Modulo de consulta web


c) Modulo de consulta movil: Se creo una aplicacion para Android, la cual emplea

los servicios mencionados en el literal a. Esta aplicacion permite a los usuarios que

cuenten con dispositivos con sistema operativo Android 4.0 o superior, consultar

los registros documentales almacenados en el sistema.


Figura 2-23.: Aplicacion para moviles Android (Autenticacion y configuracion)



2.4. Fase de Control

Esta etapa se caracteriza por gestionar y controlar los procedimientos realizados durante

la fase de ejecucion y es habitual que esta etapa avance a la par con los procedimientos

realizados durante el desarrollo de la solucion de software. A medida que se avanza en las

tareas de codificacion van surgiendo diversas tareas de correccion y modificacion sobre las

funcionalidades que se liberan de la aplicacion. Como se describe en la fase de planeacion,

la implementacion de cambios se realiza a partir de ciclos pequenos que el mismo desarro-

llador ira corrigiendo en la misma medida que dichas funciones susceptibles de modificacion

van surgiendo. Esto con el fin de agilizar las tareas de correccion y codificacion para evitar

extender los cambios con procedimientos que entorpezcan la tarea de implementacion. Dada

la naturaleza del proyecto en curso y sumado a la metodologıa de desarrollo implementada

muchos de los cambios son atendidos de manera inmediata a partir de micro ciclos de codi-

ficacion.

2.4.1. Historial de cambios

Para llevar trazabilidad sobre las modificaciones realizadas durante la construccion del soft-

ware se ha diligenciado un historial de cambios que representa las modificaciones mas repre-

sentativas a lo largo de su codificacion, permitiendo llevar un seguimiento a algunos de los

cambios que pudieran tener mayor impacto en la aplicacion y que se consideran relevantes

durante el mismo avance del proyecto. Este historial permite tener presente la modificacion o

correccion de alguna funcionalidad que mas adelante pudiera influir de manera crıtica sobre

los modulos que aun no se hayan construido.

Los responsables de alimentar este historial son los encargados del desarrollo de la aplica-

cion y el cliente directo, recordando un principio de la programacion extrema, los equipos de

trabajo estan conformados por los desarrolladores en conjunto con el cliente, tratese de un

cliente externo o un cliente interno, quien a su vez sera la persona que haga uso de la aplica-

cion. Tomando en cuenta esta aclaracion, tanto el rol de programador como el de cliente son

los personajes que pueden desencadenar una solicitud de cambio, pero sera el desarrollador

quien evolucione su gestion y realice un micro ciclo en el proceso de codificacion.

2.4 Fase de Control 65

Tabla 2-9.: Tabla de historial de cambios

HISTORIAL DE CAMBIOS

MODULO DESCRIPCION RESPONS.

Modulo de

seguridad

En un principio se estimo usar el algoritmo de cifrado AES128

como algoritmo para generar claves de cifrado. Pero al tratarse

de un metodo de clave simetrica, se procede a hacer tratamiento

sobre el algoritmo para utilizar un componente estatico con otro

componente que permita dinamizar el cifrado de forma dinamica.

Jhon Roldan

Modulo de

configuracion

Se tenıa un modulo que gestionara procesos, subprocesos y

actividades desde un mismo frontal, pero dada la complejidad de

cada uno de estos componentes se requirio implementar una vista

por cada uno de estos elementos para facilitar su configuracion.

Jorge Araque

Modulo de

configuracion

Por solicitud del departamento de calidad se incluye en el modulo

de configuracion de sub procesos un apartado para incluir la

definicion de un glosario que permita describir conceptos, frases

y terminos tecnicos que sean susceptibles de ser resaltados.

Jhon Roldan

Modulo de

almacenamie

En el modulo de cargue de archivo se requiere ampliar el tope

maximo del tamano del documento para permitir archivos con

peso hasta de 20 megabytes.

Jorge Araque

Modulo de

visualizacion

Originalmente se visualizaba en una misma pagina la informacion

de Proceso con la informacion de los Sub procesos. Para aligerar

la carga visual y proporcionar mayor orden en la distribucion de

la pagina, se realiza un cambio que permita visualizar en un

frontal independiente de visualizacion.

Jorge Araque

Modulo de

cargue de

archivo

Se requiere proporcionar un vınculo que permita el acceso a los

formatos de documentacion. Estos formatos deben estar sin

diligenciar. El mismo frontal debe proporcionar el numero del

consecutivo que debe pertenecer al proximo documento a subir.

Jhon Roldan

Modulo de

versionamiento

Se requiere que la aplicacion restrinja la subida de un archivo en

calidad de nueva version siempre y cuando ya se encuentre alma-

cenado el documento original en la aplicacion

Jhon Roldan

3. CIERRE DE LA INVESTIGACION

3.1. Resultados alcanzados

Luego de implementar la fase de ejecucion y abordar los aspectos planteados durante la etapa

preliminar abarcada en el anteproyecto se listan los siguientes aspectos como producto de

los resultados alcanzados al finalizar la construccion del software propuesto.

1. Por medio de la implementacion del algoritmo de cifrado de clave simetrica AES128

sumado a un componente de generacion de clave aleatoria se proporciona un mecanis-

mo seguro para el almacenamiento de documentos como actas, manuales, formatos y

cualquier otro tipo de recurso documental que sea generado al interior de la empresa.

2. La aplicacion permite incluir actividades como el elemento mas granular dentro de

un proceso, dicha actividad define un procedimiento especıfico que a su vez debe estar

soportado por un documento que evidencie su procedimiento asociado. De esta manera

cada documento se puede ordenar por actividades segun los lineamientos del Sistema

de Gestion de Calidad.

3. Para agilizar los procesos de busqueda se incluyen estructuras de indexacion permi-

tiendo busquedas mas eficientes tanto desde la interfaz web como la realizada desde

dispositivos moviles.

4. Cada proceso de subida de un documento en el sistema implica que sea realizado por

un usuario autenticado en la aplicacion, al momento de efectuarse el cargue se captura

la fecha del sistema y toda esta informacion permite llevar la trazabilidad de quien

realiza la alimentacion del sistema y cuando lo hace.

5. Para poder realizar el cargue de la segunda version de un documento dado, el sistema

exige relacionar el documento original al cual se le ha generado dicha version. Esto

garantiza primero que no se suban versionamientos aislados y segundo que exista un

historial que represente la evolucion de un documento al estar enlazados los archivos

originales con sus respectivas versiones.

6. El Sistema de Administracion de Documentos tiene un frontal dedicado a la crea-

cion de procesos que representan un area especıfica de la empresa. Cada proceso es

3.2 Conclusiones 67

administrable para permitir o denegar ciertas acciones como la visualizacion o la mo-

dificacion de la informacion contenida en cada proceso, de esta manera se garantiza

que los documentos puedan ser visibles para los usuarios que esten autorizados para

su visualizacion.

7. Todo recurso documental que se genere como producto de una actividad dentro de la

companıa es apto para ser cargado en el Sistema de Administracion de Documentos y

ası evitar guardar la informacion en una carpeta compartida posiblemente publica que

expone la integridad de la informacion. Mediante el uso de los algoritmos de cifrado

implementados en la aplicacion se garantiza que no es posible acceder a los archivos

desde otro medio que no sea a traves del Sistema de Administracion de Documentos.

3.2. Conclusiones

La creacion de un sistema de administracion de documentos permite que todas las areas in-

volucradas en los procesos productivos de una companıa puedan organizar de forma logica y

segura los registros, evidencias o salidas de su proceso productivo, lo que facilita los procesos

de consulta de informacion, de auditorıa y de seguimiento; al tiempo que agiliza y centraliza

algunos procesos de comunicacion entre diferentes actores que toman parte durante el desa-

rrollo del objeto de la companıa.

Teniendo como eje central del proceso de desarrollo la implementacion de las principales

caracterısticas de un sistema de administracion de documentos, ası como la adecuacion de

dichas caracterısticas a las polıticas internas establecidas (sistema de gestion de calidad), se

integraron funcionalidades de seguridad que garantizan la integridad de los contenidos alma-

cenados en el mismo (cifrado AES 128 dinamico), ası como de su autenticidad (verificacion

de sumas CRC 32 para cada registro), lo que le da la certeza a quienes emplean el sistema

de que la custodia de los documentos se realizara de una forma adecuada y de acuerdo a

las exigencias de la companıa. Por otro lado, los documentos se hicieron disponibles para

los usuarios que ası los requieran, todo esto mediante multiples mecanismos de consulta, en

donde se ya se puede acceder a cerca de 400 registros documentales (de 1091 disponibles a

la fecha) que se encontraban dispersos en varios equipos de computo de distintos empleados;

esto se traduce en aproximadamente 800 MB de informacion que anteriormente solo podıan

ser accedidos por sus propietarios.

Para la definicion de requerimientos funcionales y no funcionales se aplicaron tecnicas de

recoleccion de informacion que permitieron tener un acercamiento con el cliente a tal nivel

que admitiera el uso de lenguaje comun para que pudieran describir de una forma coloquial

sus intereses, preocupaciones y motivaciones frente a las necesidades que el software pretende

cubrir. Se implemento el uso de Historias de Usuario como herramienta de recoleccion de

68 3 CIERRE DE LA INVESTIGACION

requerimientos y se programaron reuniones en calidad de entrevista para que cada uno de los

clientes interesados presentara sus inquietudes y expresara sus necesidades frente al software.

Se eligio una metodologıa de desarrollo agil para la construccion del software propuesto da-

das las condiciones de tiempo estimadas para el cumplimiento del proyecto. Una metodologıa

agil se focaliza de forma importante en ciclos de desarrollo cortos, caracterıstica muy util pa-

ra proyectos con cronogramas tan ajustados. Puntualmente se eligio la metodologıa Xtreme

Programming por encima de otras metodologıas como Scrum, Lean o RUP por tratarse de

una metodologıa que se adapta mejor a los recursos dispuestos para este proyecto y poder

aplicar varias de los principios de XP como la retroalimentacion a escala fina, la programa-

cion en parejas, las reuniones cortas, o el entendimiento compartido.

Una vez finalizada la implementacion del sistema y realizado un corto seguimiento, se puede

evidenciar la dependencia que posee Cyza Outsourcing en torno a la informacion consignada

en medios electronicos, y comunmente la falta de polıticas y de lineamientos que contribuyan

al correcto manejo de estos cuando su volumen empieza a marcar una tendencia incremental.

Un sistema que se encargue de administrar este tipo de activos de informacion facilita el

seguimiento de las actividades realizadas, al tiempo que permite a las personas que laboran

en la companıa emplear menos tiempo realizando busquedas, mientras que paralelamente

se mitiga el riesgo de perdida y uso no autorizado de la informacion, lo que deriva en una

mejor productividad y una optimizacion en los procesos de comunicacion interna, debido a

la implementacion de mecanismos mas sencillos para compartir informacion.

3.3. Prospectiva del trabajo de grado

La companıa almacenara todos los registros documentales que aun no se han cargado

en el sistema de administracion de documentos, lo cual requerira de un esfuerzo man-

comunado entre las distintas areas que conforman la companıa. Para esto se fijo como

fecha limite la proxima auditorıa externa que sera realizada por el ente certificador

(febrero de 2017).

Dado que los registros documentales obedecen a plantillas preestablecidas, que son

definidas por coordinadores, directores o el area de calidad, se planea hacer un mo-

dulo que permita a un usuario, mediante el sistema, definir las plantillas para que los

documentos sean generados automaticamente capturando la informacion desde formu-

larios web. Esto derivarıa en una reduccion de costos, dado que no seria requerido

software ofimatico; salvo por los coordinadores y directores, lo que se reflejarıa en una

menor cantidad de licencias necesarias para la operacion. Dentro de los primeros acer-

camientos, se evalua usar el procesador OpenSource de LATEX, como mecanismo para

la generacion de los registros documentales.

3.3 Prospectiva del trabajo de grado 69

Acorde a una de las principales leyes colombianas de regulacion de mensajes electroni-

cos, se debera garantizar el no repudio de la informacion contenida en un archivo;

convirtiendo a algunos tipos de registros documentales en elementos con validez jurıdi-

ca ante el estado colombiano [7]. Para esto seran adquiridas firmas digitales para ciertos

usuarios, a los que tambien les seran asignados tokens (generadores de claves de un uni-

co uso [21]). Dado que se contempla generar archivos PDF mediante Latex, estos seran

firmados de manera digital por la persona que se encargue de crearlos y de cargarlos

en el sistema. El uso de este mecanismo no sera extendido a todos los usuarios, sin

embargo, tampoco sera opcional cuando sea requerido. Se evaluara si ciertos registros

documentales tambien requieren una estampa cronologica [4].

A. Anexo: Documentos de

Requerimientos

Los siguientes formatos corresponden a los documentos de requerimientos generados tras

analizar las historias de usuario resultantes de cada entrevista con las personas implicadas

en la concepcion del Sistema de Gestion Documental.

A.0.1. Requerimientos Funcionales

Tabla A-1.: Requerimiento REQ-FNC-01

REQ-FNC-01

Tipo Requerimiento Nueva Funcionalidad

Descripcion:

Construir una aplicacion Web que tenga acceso a traves de Internet de

tal forma que una vez sea digitada la URL del sitio web, se presente

la ventana de inicio de la aplicacion desde cualquier parte.

Solicitante: Leandro Ovalle Entrevistador: Jhon Roldan

Fecha Creacion Abril 20 de 2016

Actor Desarrollador

Precondiciones: Un servidor con salida a internet, IIS y .Net Framework.

Pos condiciones: La construccion de una aplicacion web con acceso desde Internet

Entradas: Digitacion de la URL de acceso desde un navegador web.

Restricciones El acceso al sitio web debe tener una unica direccion URL

Salidas: Cargue y visualizacion de la ventana de acceso a la aplicacion.

71


REQ-FNC-02


Descripcion:

El Sistema de Gestion Documental debe contar con un sistema que permita

el registro de usuarios de tal manera que solo puedan ingresar los usuarios

que hayan sido debidamente validados por la aplicacion.



Actor Administrador de la aplicacion

Precondiciones: Sistema de Autenticacion de Usuario Directorio Activo/Propietario

Pos condiciones: Acceso a la aplicacion para usuarios autenticados.

Entradas: Usuario y contrasena

Restricciones Si el usuario no existe o la contrasena no corresponde aparecera un mensaje

Salidas: Acceso a la aplicacion y a los modulos autorizados para su perfil.


REQ-FNC-03


Descripcion:

El Sistema de Gestion Documental debe estar en la capacidad de tener un

modulo con la funcionalidad de gestionar los usuarios de tal manera que les

permita acceder o denegar el acceso a ciertos modulos de la aplicacion.




Precondiciones: La existencia de un frontal de configuracion de usuarios. Usuarios creados.

Pos condiciones: Cada usuario tendra acceso a algunos modulos y restriccion en otros.

Entradas: El usuario que desea ser gestionado para configurar su accesibilidad.

Restricciones Quien puede gestionar accesos sobre un usuario debe ser administrador.

Salidas: El usuario gestionado solo podra visualizar los modulos permitidos.

72 A Anexo: Documentos de Requerimientos


REQ-FNC-04


Descripcion:

El Sistema de Gestion Documental tendra una estructura de jerarquıa

que permita definir un modulo principal que aborde los procesos. Cada

proceso representa una funcion general y unica en la empresa. Por

ejemplo la Gestion Financiera, o la Gestion Tecnologica. Debe contar

con una descripcion clara.

Solicitante: Leandro Ovalle Entrevistador: Jorge Araque

Fecha Creacion Mayo 12 de 2016


Precondiciones: Acceso al modulo de creacion de procesos.

Pos condiciones: Se creara un proceso perfectamente definido y unico.

Entradas: Nombre del proceso, descripcion del proceso

Restricciones No debe existir un proceso igual al que se va a crear

Salidas: Un proceso creado y listo para ser visualizado.


REQ-FNC-05


Descripcion:

El Sistema de Gestion Documental contendra una estructura de jerarquıa

que permita crear un subproceso que dependa uniprocedentemente de un

proceso y que dentro defina un objetivo, un alcance, una referencia

normativa, un glosario de terminos y un componente de

responsabilidades.




Precondiciones: Acceso al modulo de creacion de subprocesos.

Pos condiciones: Se creara un subproceso

Entradas:Nombre del subproceso, objetivo, alcance, referencia normativa, glosario

y un responsable

Restricciones Debe pertenecer a un proceso previamente creado.

Salidas: Nuevo subproceso que forma parte de un proceso principal.

73


REQ-FNC-06


Descripcion:

El Sistema de Gestion Documental debe permitir la creacion subordinada

de actividades. Las actividades son procedimientos especıficos que

ocurren dentro de un supbroceso y puede haber mas de una actividad por

cada subproceso. La actividad tiene un nombre, una descripcion de lo

que realiza y finalmente un soporte a manera de registro que puede ser

un documento o una entrada digital en bitacora.




Precondiciones: Acceso al modulo de creacion de actividades.

Pos condiciones: Nueva actividad que hace parte de un subproceso.

Entradas:Nombre de la actividad, descripcion de la actividad y definicion del tipo

de registro que va a emplear.

Restricciones Debe existir un subproceso para poder crear la actividad.

Salidas:Una actividad creada y lista para ser ejecutada por las personas que

pertenecenn al subproceso que contiene dicha actividad.


REQ-FNC-07


Descripcion:

El Sistema de Gestion Documental debe permitir el cargue de archivos

para dar soporte a una actividad. Es importante que el software pueda

proporcionar una plantilla con el consecutivo que le corresponda para

llevar continuidad en la documentacion.

Solicitante: Miguel Fajardo Entrevistador: Jorge Araque


Actor Usuario Autorizado

Precondiciones: Acceso al modulo cargue de archivo

Pos condiciones: El archivo se encontrara subido en el sistema.

Entradas: El diligenciamiento previo del archivo a subir.

Restricciones Si se genera la tarea pero no se sube el archivo se crea una alerta.

Salidas: En la aplicacion se crea un link para poder descargar el archivo subido

74 A Anexo: Documentos de Requerimientos


REQ-FNC-08


Descripcion:

El Sistema de Gestion Documental debe contar con un modulo de

versionamiento que lleve trazabilidad de cada documento subido al

sistema. Si una nueva version es cargada, debe quedar claro cual es el

documento que se esta modificando y permitir ver documentos anteriores.

Solicitante: Auditor Externo Entrevistador: Jorge Araque



Precondiciones: Permiso para visualizacion de archivos cargados

Pos condiciones: Consulta de historial de versiones de un documento especıfico.

Entradas: Navegacion hacia el documento a consultar.

Restricciones El documento solo puede ser consultado mas no reemplazado.

Salidas: Visualizacion del documento.


REQ-FNC-09


Descripcion:

El Sistema de Gestion Documental debe permitir la consulta mediante

el uso de dispositivos moviles del tal manera que permita visualizar

la documentacion de un proceso especıfico.

Solicitante: Jhon Roldan Entrevistador: Jorge Araque



Precondiciones: Acceso desde un smartphone.

Pos condiciones: Visualizacion de docuementos en el sistema de gestion documental.

Entradas: Credenciales de acceso, identificacion del documento a buscar.

Restricciones Acceso desde equipos con Android, acceso a internet.

Salidas: Visualizacion en la pantalla del documento buscado.

75

A.0.2. Requerimientos no funcionales

Tabla A-10.: Requerimiento REQ-NFN-01

REQ-NFN-01

Tipo Requerimiento Componente de Seguridad

Descripcion:

Se debe garantizar la integridad de la informacion contenida en el

Sistema de Gestion Documental, para lo cual se requiere del uso de un

componente de seguridad que permita cifrar los documentos que se

requieran subir al aplicativo. La funcion de cifrado y descrifrado debe

ser controlada unicamente por la aplicacion.



Tabla A-11.: Requerimiento REQ-NFN-02

REQ-NFN-02

Tipo Requerimiento Visualizacion

Descripcion:

Como elemento de estandarizacion se solicita uniformidad en el aspecto

visual de la aplicacion conforme a las plantillas empleadas en los

desarrollos de aplicaciones dentro de la companıa.



Bibliografıa

[1] Arias Chaves, Michael: La ingenierıa de requerimientos y su importancia en el desa-

rrollo de proyectos de software. En: InterSedes 6 (2011), Nr. 10

[2] Beck, Kent: Programming Explained: Embrace Chance. Boston : Adisson Wesley, 1999

[3] Bertalanffy, L.: Tendencias en la Teorıa General de Sistemas. Madrid : Alianza

Universidad, 2014

[4] de comercio de Bogota, Camara: Firma digital y estampado cronologico.

http://www.ccb.org.co/Inscripciones-y-renovaciones/Registro-Unico-de-Proponentes/

Tramites-virtuales-del-Registro-Unico-de-Proponentes/Firma-digital-y-estampado-cronologico.

– visto el 30-Sept-2016

[5] Ceballos, F.J.: Enciclopedia de Microsoft Visual C Sharp. Madrid : Alfaomega, 2006

[6] de Colombia, Ministerio T.: Arquitectura empresarial: El cambio hacia un gobierno

integrado. En: Revista CIO@gov 2 (2013), p. 26

[7] COLOMBIA, REPAsBLICA D.: LEY 527 DE 1999. https://www.cancilleria.gov.co/

sites/default/files/tramites servicios/apostilla legalizacion/archivos/ley 527 1999.pdf.

1999. – visto el 30-Sept-2016

[8] Cooper-Bland, Chris: Views and Viewpoints.

http://iasaglobal.org/itabok/capability-descriptions/views-and-viewpoints/. 2014.


[9] Cooper-Bland, Chris: ArchiMate Viewpoint Set. http://iasaglobal.org/itabok3 0/

views-and-viewpoints/views-viewpoints-3-0-archimate/. 2016. – visto el 19-Sept-2016

[10] Hugo ter Doest, Maria-Eugenia I.: Viewpoints Functionality and Exam-

ples. https://fenix.tecnico.ulisboa.pt/downloadFile/3779571440459/Archimate-

ViewPointsFunctionalitiesAndExamples.pdf. 2004. – visto el 19-Sept-2016

[11] Fielding, Roy T.: Representational State Transfer (REST). https://www.ics.uci.edu/∼fielding/pubs/dissertation/rest arch style.htm. 2000. – visto el 26-Sept-2016

Bibliografıa 77

[12] Group, The O.: Archimate R©, 2.1 Specification. http://pubs.opengroup.org/

architecture/archimate2-doc/chap10.html# Toc371945276. 2013. – visto el 19-Sept-

2016

[13] Kendall, Kenneth E.: Analisis y Diseno de Sistemas. Mexico : Prentice Hall, 1995

[14] Letelier, Patricio: Metodologıas agiles para el desarrollo de software: eXtreme Pro-

gramming (XP). (2006)

[15] Llans0, Joaquim.: Sistemas Archivısticos y Modelos de Gestion de Documentos en el

Ambito Internacional. En: Revista Codice 2 (2006), p. 13–45

[16] Maddox, Sarah: Application Programming Interfaces (APIS). http://summit.stc.org/

responsive/summit2014.htm#!Documents/applicationprogramminginterfacesapis.htm.

2014. – visto el 28-Sept-2016

[17] Miller, James S.: The Common Language Infrastructure Annotated Standard. Boston

: Adisson Wesley, 2004

[18] Palomares Chust, Alberto: Estructura de desglose del trabajo (EDT). (2011)

[19] PMBoK, A: Guide to the project Management body of knowledge. En: Project Ma-

nagement Institute, Pennsylvania USA (2000)

[20] Roberge, Michael. La gestion de l information administrative: aplication globale,

systemique et systematique. 1992

[21] Shokotko, Denis: One-Time Passwords: Generation Algorithms and Over-

view of the Main Types of Tokens. https://www.protectimus.com/blog/

otp-generation-algorithms-and-token-types/. 2015. – visto el 30-Sept-2016

[22] for Standardization, International O.: ISO 27001 Controls and Ob-

jectives. http://gender.govmu.org/English/Documents/activities/gender%20infsys/

AnnexIX1302.pdf. 2013. – visto el 19-Sept-2016

[23] of Standards, National I. ; (NIST), Technology: ADVANCED ENCRYPTION

STANDARD (AES). http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. 2001.


[24] Steven St, Jean ; Brady, Damian. ; Blankenship, Ed.: Professional Team Foun-

dation Server 2013. Indiana : John Wiley & Sons Inc, 1978

[25] Veeraragaloo, Maganathin M.: Archimate Viewpoints.

http://es.slideshare.net/MVeeraragaloo/archimate-viewpoints. 2010. – visto el

19-Sept-2016