plataforma web para la gestiÓn de la informaciÓn de

PLATAFORMA WEB PARA LA GESTIÓN DE LA INFORMACIÓN DE CONTRATOS Y PROYECTOS EN LA EMPRESA DE ACUEDUCTO,

ALCANTARILLADO Y ASEO DEL TOLIMA EDAT.

Atribución – No comercial – Sin Derivar

DAYANNA BARÓN RAMÍREZ

UNIVERSIDAD COOPERATIVA DE COLOMBIA CAMPUS IBAGUÉ ESPINAL

FACULTAD DE INGENIERÍA DE SISTEMAS IBAGUÉ

2021

PLATAFORMA WEB PARA LA GESTIÓN DE LA INFORMACIÓN DE CONTRATOS Y PROYECTOS EN LA EMPRESA DE ACUEDUCTO,

ALCANTARILLADO Y ASEO DEL TOLIMA EDAT.

DAYANNA BARÓN RAMÍREZ

Análisis sistemático de literatura

Oscar Camilo Valderrama Riveros Ingeniero Electrónico Nelly Clavijo Bustos

Ingeniera de sistemas

UNIVERSIDAD COOPERATIVA DE COLOMBIA CAMPUS IBAGUÉ ESPINAL

FACULTAD DE INGENIERÍA DE SISTEMAS IBAGUÉ

2021

3

Nota de aceptación: ____________________________ ____________________________ ____________________________ ____________________________ ____________________________ ____________________________ ____________________________ ____________________________ Firma del jurado 1 ____________________________ Firma del jurado 2 Ibagué, Tolima. 02, 09, 2021

4

Contenido INTRODUCCIÓN ................................................................................................... 7

1. DESCRIPCIÓN DEL PROBLEMA. ............................................................... 9

2. JUSTIFICACIÓN. ....................................................................................... 10

3. OBJETIVOS. .............................................................................................. 11

1.1. OBJETIVO GENERAL. 11

1.2. OBJETIVOS ESPECÍFICOS. 11

4. MARCO TEÓRICO. .................................................................................... 12

4.1. ARQUITECTURA 12

4.2. ARQUITECTURA CLIENTE SERVIDOR 12

4.3. SEGURIDAD 16

4.4. ARQUITECTURA HEXAGONAL 18

4.5. ARQUITECTURA BASADA EN COMPONENTES Y SPA’s 20

5. MARCO NORMÁTIVO ............................................................................... 21

6. MARCO INSTITUCIONAL .......................................................................... 22

7. ANTECEDENTES ...................................................................................... 23

8. METODOLOGÍA. ........................................................................................ 24

8.1. ESTRATEGIA DE DESARROLLO. 24

8.2. ANÁLISIS 24

8.3. IDENTIFICACIÓN DE LOS REQUERIMIENTOS DEL SISTEMA. 25

8.4. DEFINICIÓN DEL MODELO DE DOMINIO DE LA APLICACIÓN. 25

8.5. DIAGRAMAS DE CASOS DE USO 32

8.6. REQUISITOS DEL SISTEMA 35

8.6.1. REQUISITOS FUNCIONALES. 35

8.6.2. REQUISITOS NO FUNCIONALES. 37

8.7. TECNOLOGIAS 39

9. RESULTADOS. .......................................................................................... 41

9.1. RESULTADOS PLATAFORMA DEL LADO DEL CLIENTE: 41

9.2. RESULTADOS PLATAFORMA DEL LADO DEL SERVIDOR: 50

10. CONCLUSIONES ....................................................................................... 55

BIBLIOGRAFÍA .................................................................................................... 57

5

INDICE DE FIGURAS

Figura 1. Uso de REST en Servicios Web. ........................................................... 14

Figura 2. Estructura de endpoint para recursos o servicios de una API. .............. 15

Figura 3. Estructura endpoint incluyendo un parámetro. ...................................... 15

Figura 4. Ejemplo de JWT codificado y decodificado. .......................................... 18

Figura 5. Representación de arquitectura en capas Dirigida al Dominio. ............. 19

Figura 6. Diagrama del modelo lógico de entidad relación parte 1. ...................... 28

Figura 7. Diagrama del modelo lógico de entidad relación parte 2. ...................... 29

Figura 8. Diagrama del modelo físico de entidad relación parte 1. ....................... 30

Figura 9. Diagrama del modelo físico de entidad relación parte 2. ....................... 31

Figura 10. Diagrama de caso de uso de actores. ................................................. 32

Figura 11. Diagrama de caso de uso de ingreso al sistema. ................................ 32

Figura 12. Diagrama de caso de uso sobre los procesos del sistema. ................. 33

Figura 13. Diagrama de caso de uso sobre la gestión de proyectos. ................... 33

Figura 14. Diagrama de caso de uso sobre la gestión de contratos. .................... 34

Figura 15. Diagrama de caso de uso sobre la administración de entidades externas.............................................................................................................................. 34

Figura 16. Interfaz de ingreso al sistema, acceso autorizado. .............................. 41

Figura 17. Interfaz de ingreso al sistema, acceso no autorizado. ......................... 41

Figura 18. Interfaz datos de perfil. ........................................................................ 42

Figura 19. Interfaz home y métricas. .................................................................... 43

Figura 20. Interfaz módulo de proyectos, formulación. ......................................... 44

Figura 21. Interfaz módulo proyecto, edición. ....................................................... 44

Figura 22. Interfaz módulo proyectos, búsqueda. ................................................. 45

Figura 23. Interfaz módulo contratos, registro. ..................................................... 46

Figura 24. Interfaz módulo contratos, sección de registro, tiempos y valor. .......... 46

Figura 25. Interfaz módulo Municipios, búsqueda. ............................................... 47

Figura 26. Interfaz módulo Administración, gestión de entidades. ........................ 48

Figura 27. Interfaz módulo de Administración, entidades. .................................... 48

Figura 28. Componentes para mejorar la experiencia de usuario......................... 49

Figura 29. Interfaz página no encontrada. ............................................................ 50

Figura 30. Documentación de API a través de Swagger. ..................................... 51

Figura 31. Recursos o entidades del sistema con sus métodos http. ................... 51

Figura 32. Atributos de las entidades del sistema, entidad Contratista. ................ 52

Figura 33. Ejecución de solicitud o request a API del sistema. ............................. 52

Figura 34. Ejecución de solicitud para generación de token JWT......................... 53

Figura 35. Respuesta de API a solicitud de generación de token JWT. ............... 54

6

INDICE DE TABLAS

Tabla 1. Descripción de entidades del dominio del sistema. ................................ 25

Tabla 2. Registro de nuevo usuario. ..................................................................... 35

Tabla 3. Ingreso al sistema y cierre de sesión...................................................... 35

Tabla 4. Creación de proyecto. ............................................................................ 35

Tabla 5. Gestión de datos de proyecto. ................................................................ 36

Tabla 6. Registro de contrato. .............................................................................. 36

Tabla 7. Gestión de datos de contrato. ................................................................ 36

Tabla 8. Administración de usuarios. ................................................................... 37

Tabla 9. Administración de entidades externas a proyectos y contratos. ............. 37

Tabla 10. Rendimiento. ........................................................................................ 37

Tabla 11. Seguridad. ............................................................................................ 38

Tabla 12. Interoperabilidad. .................................................................................. 38

Tabla 13. Flexibilidad al cambio. .......................................................................... 38

Tabla 14. Escalabilidad. ....................................................................................... 39

Tabla 15. Usabilidad. ........................................................................................... 39

7

INTRODUCCIÓN Los sistemas son popularmente reconocidos dentro de la Teoría General de Sistemas como el conjunto de elementos que coexisten dinámicamente, siendo capaces de generar relaciones entre sus componentes, con el medio u otros grupos de sistemas; manteniendo durante todo el devenir de su existencia un tipo de cohesión especial que le permite caracterizarse como unidad dotada de identidad. (Ledesma, 2005). Estos más allá de la concepción popular, de programas informáticos, son unidades vivas y complejas que presentan desagregación desde lo que conocemos como el universo hasta la estructura corporal de cualquier ser biológico por microscópico que sea; por lo menos así lo planteaba el filósofo Bertalanffy en su TGS (Arnold & Osorio, 1998), aportando con ello un valioso grano de arena a lo que significaría luego de la Segunda Guerra Mundial, el nacimiento de nuevas disciplinas entre ellas la teoría de la información, mediante las cuales se empezó a difundir la aplicación de la Teoría general de sistemas (Ledesma, 2005). A este punto, tenemos que los sistemas se definen dentro de dos grupos, perceptibles o abstractos, y es el espacio dentro del cual podemos hacer claridad especial sobre el último grupo, dado que estos se encargan de ofrecernos una abstracción del mundo perceptible enriqueciendo la manera en cómo interactuamos con el conocimiento y características del entorno. Dicho lo anterior, podemos empezar a referirnos a los sistemas informáticos dada su característica de intangibilidad, como la herramienta a través de la cual se plasma algo real, no precisamente para reemplazarlo sino para hacernos a la idea de las maneras en cómo podemos organizar sus conceptos, desde una perspectiva orientada a la administración de la información, trayendo a su vez la aplicación de la teoría general y las técnicas para el modelamiento de sistemas que ayudaran en la abstracción de los procesos realizados por la entidad pública EDAT al mundo de los sistemas informáticos; definiendo para ello una serie de descomposiciones y análisis de elementos clave que consecuentemente permitan el desarrollo de un producto de software útil en la gestión de registros asociados a proyectos y contratos que hayan encargado los municipios del Tolima a esta empresa. Con dicho producto de software no se pretende modelar la manera en cómo se deban gestionar proyectos y contratos, sino, llevar los procesos específicos que realiza esta organización al manejo adecuado de la información mediante la solución tecnológica propuesta. Tampoco se pretende abarcar dentro de la definición de marcos legales para la redacción de contratos y proyectos, puesto que la herramienta se ciñe a la

8

instrucción recibida de los ejecutivos y profesionales encargados, sobre los pasos que realiza el EDAT al recibir un proyecto y gestionar los contratos de este. Durante el desarrollo del trabajo se mencionará términos específicos del tema de contratos, como de proyectos, sobre los cuales no se hará hincapié dado que el fin de este trabajo es demostrar la importancia de la implementación de software en la gestión de la información dentro de las organizaciones, teniendo como marco el modelo de negocio de la entidad EDAT. Por otra parte, aunque el proyecto de software se enfoca en la gestión de información y proyectos, este no pretende constituirse como un Sistema de gestión documental (Por sus siglas en ingles DMS) o un Gestor del ciclo de vida contractual (por sus siglas en ingles CLM) según la definición proporcionada por El Centro Europeo del Conocimiento para las Tecnologías de la Información (EKCIT, 2018).

9

1. DESCRIPCIÓN DEL PROBLEMA. En la EDAT, los registros relacionados a sus procesos son la fuente clave para conocer el estado a la fecha de las gestiones realizadas; en este punto se encuentra necesario automatizar el manejo de los datos asociados a los proyectos y contratos por municipio a su cargo; dado el hecho de que las tareas de administración de la información asociada a los procesos que tienen lugar en la gestión de proyectos y contratos se realiza de manera tradicional, aplicando el uso de hojas de Excel y documentos que según la función de cada integrante de la organización va almacenando conforme lo necesite en su equipo de cómputo, dispositivos usb o discos duros. La práctica tradicional entendida como el manejo de la información a través de herramientas convencionales para almacenar documentos de poca complejidad con un bajo grado de interacción entre sí y dinamismo escaso, dada su mínima dependencia a variables del contexto como por ejemplo el tiempo; no está bien vista desde la perspectiva de la teoría de la información, para el manejo de registros empresariales, dado el valor que puedan tener para una organización y los riesgos de entropía y alta vulnerabilidad a los que se ve expuesta (Musiño, 2010). En tal sentido administrar la información de proyectos y contratos como se describe, sabiendo el grado de complejidad, en cuanto a relaciones y de importancia, en cuanto al valor de estos registros, muestra ineficiencia, que desencadena en restar eficacia a la organización, suponiendo dejar pasar los momentos oportunos para reaccionar a ciertos escenarios, como por ejemplo el vencimiento de términos de un contrato (EKCIT, 2018). Por otra parte, y contextualizando el debido manejo de los procesos de contratación y organización de proyectos en el sector público, la cantidad de información puede conllevar a faltantes documentales a la hora de llevar a cabo una etapa de dichos procesos, al no entendimiento de términos y condiciones y tergiversación de los objetivos propuestos. De ahí que emplear un sistema de software para cubrir esta necesidad ayuda a reducir las horas de trabajo y automatizar los procesos relacionados a la gestión de contratos y a su vez de los proyectos, refiriéndonos a los contratos en primera instancia dado que se consideran el foco de acción para los proyectos, al cual se le debe dar especial atención (Nguyen , 2013)

10

2. JUSTIFICACIÓN. Según la IACCM (International Association for Contract and Commercial Management), más del 70% de las corporaciones internacionales consideraron la gestión de contratos como una "fuente importante o significativa de debilidad operativa" y esa mejora en el campo puede conducir a una mejor gestión de riesgos y reducción de costos (IACCM) Por lo cual, toda organización que dentro de su modelo de ejecución presente control y debida gestión en contratos, pueden obtener un gran número de ventajas en temas de competitividad, reducción de las horas de trabajo y automatización de procesos relacionados a la gestión de los datos sobre proyectos y contratos a cargo, ahorro, tiempo de ejecución frente a circunstancias críticas que se pueden originar por falta de un buen manejo de información. Un adecuado manejo y gestión de dicha documentación es indispensable para los actores involucrados en los procesos. Por ello, se pretende mejorar la gestión del ciclo de vida de los contratos brindando apoyo en la organización de la información de cada caso, según las funciones que sobre este deban cumplir las distintas áreas de la empresa que se vean involucradas, considerando la mejora de los aspectos administrativos y la toma de decisiones ya que se garantizaría la calidad del contenido con que se pueda disponer, asumiendo para ello el manejo de un repositorio de información centralizado, cuya información sea objetiva, veraz y oportuna, permitiendo extraer la información real que se necesita, cuando se requiera, pues de lo contrario no sería útil, (Godinez & Segura, 2011) la disponibilidad es también el motivo por el que el sistema tendrá lugar en un entorno web, ya que mediante el internet conseguimos acceso a la información desde cualquier lugar.

11

3. OBJETIVOS.

1.1. OBJETIVO GENERAL. Desarrollar un aplicativo web que permita la gestión de la información de proyectos y contratos a cargo de la Empresa de Acueducto, Alcantarillado y aseo del Tolima EDAT.

1.2. OBJETIVOS ESPECÍFICOS.

• Análisis e identificación de los requerimientos del sistema.

• Diseñar los componentes de la arquitectura de la aplicación y su interfaz gráfica.

• Evaluar el desarrollo del sistema para garantizar el acceso e ingreso de información al EDAT por cada uno de los municipios vinculados.

12

4. MARCO TEÓRICO.

4.1. ARQUITECTURA La arquitectura es crucial en la construcción de software, es la base estructural sobre la cual se construyen y representan los distintos componentes que puedan dar sentido a un modelo de negocio específico dentro de un sistema informático, considerando también el funcionamiento de cada componente y su interacción con otros; de la arquitectura definida depende en gran medida la capacidad de escalabilidad y flexibilidad de un sistema. (Castro, 2015) Hablamos de arquitectura en distintos niveles de abstracción de un sistema; a un alto nivel, se recurre al concepto de arquitectura externa desde el cual se da cabida a la estructura, comunicación y organización de varios sistemas que operan entre sí; a un nivel más detallado se menciona la arquitectura interna, que alude a la estructura y organización de sistemas individuales. (Castro, 2015) Dicho lo anterior se definen como arquitecturas de este sistema (GESCA3T), a nivel externo, cliente servidor por caracterizar la comunicación entre sistemas a través de protocolos de comunicación, y a nivel interno dos arquitecturas; del lado del servidor se define la arquitectura hexagonal, y del lado del cliente la arquitectura basada en componentes Desde ambos niveles de abstracción la arquitectura se conforma de la implementación de diversos patrones de diseño, prácticas y principios que contribuyen en la construcción de sistemas escalables.

4.2. ARQUITECTURA CLIENTE SERVIDOR Cliente Servidor es un tipo de arquitectura la cual constituye la base del funcionamiento en los modelos de aplicaciones distribuidas, esta consiste en la distribución de las responsabilidades de la aplicación, con el fin de evitar problemas de saturación del sistema, entre otros inconvenientes. En este sentido se pueden identificar dos tipos de nodos en este modelo, el Servidor, quien se encarga de proporcionar servicios como por ejemplo hacer registros en bases de datos; y el Cliente quien tiene como función general consumir los recursos expuestos por uno o más proveedores de servicios, (Marini, 2012) la forma empleada para el consumo de servicios es la utilización de un conjunto de métodos dispuestos como reglas para establecer comunicación a través del protocolo http (Protocolo de hipertexto que nos permite transmitir información a través de la World Wide Web), tales métodos son: POST, GET, PUT, DELETE los cuales equivalen respectivamente a las operaciones CRUD de bases de datos (Create, Read, Update, Delete) (Aguilar & Palacios, 2015).

13

REST, RESTFul y API REST por sus siglas en español “Transferencia de Estado Representacional” es un estilo arquitectónico en el cual se definen pautas para la definición y descripción de recursos en red (Barry, 2000 - 2021), tales recursos hacen referencia a los servicios que se exponen y consumen dentro de una arquitectura Cliente Servidor y en general los sistemas distribuidos que empleen hipermedia o el protocolo http (Fielding, 2000). Este estilo arquitectónico se aplica en la construcción de una gran variedad de API’s, por sus siglas en español “Interfaz de Programación de Aplicaciones” como se les llama a las aplicaciones que exponen servicios o recursos a través de una red, y que se pueden ocupar sin importar como funcionen internamente; teniendo así que, una API puede ser considerada REST o RESTful, cuya razón de ser es dotar a una aplicación de la más alta capacidad de integración con otras API’s o Clientes, proporcionando un conjunto de normas o restricciones para estandarizar y garantizar la facilidad de entendimiento del funcionamiento de la API entre otros beneficios. Gran parte de internet implementa este tipo de arquitectura especialmente en todo lo que respecta a los llamados Servicios Web, los cuales son a grandes rasgos la base de la computación en la nube moderna, aun así, una implementación de este tipo no está ligada a desarrollarse dentro de algún servicio de computación en la nube. A continuación, se ilustra el funcionamiento esencial del hibrido planteado entre Arquitectura Cliente Servidor y el estilo arquitectónico REST.

14

Figura 1. Uso de REST en Servicios Web.

Fuente: (Barry, 2000 - 2021) En la figura anterior se observa la estructura que da sentido a la arquitectura cliente servidor y la forma de comunicación entre los nodos conformantes, tal comunicación se lleva a cabo gracias a solicitudes y respuestas o requests y responses respectivamente. Siempre que se acceda a una URI se ejecutará una solicitud, tal solicitud va desde el nodo cliente al servidor a lo cual el servidor proporciona una respuesta; los datos involucrados en ella viajan a través de la red usualmente en formato JSON (JavaScript Object Notation). RESTful request Un RESTful request está compuesto de las siguientes partes:

• El endpoint o URI.

• El método http.

• Encabezados http.

• Cuerpo de datos.

• A continuación, se describen: El endpoint o URI: Un endpoint es una URL más, pero a diferencia de servir un sitio web, esta retorna datos en formato JSON (Chiang, 2021) cuando es ejecutada desde un navegador web o un cliente como Postman. En la siguiente figura se observa la estructura de un endpoint.

15

Figura 2. Estructura de endpoint para recursos o servicios de una API.

Fuente: Elaboración propia. Los endpoints también son conocidos como path, un path contiene un recurso único, dentro de la estructura de un endpoint se pueden incluir parámetros, por lo cual también es usual encontrar la siguiente variación en la estructura observada en la figura anterior. Figura 3. Estructura endpoint incluyendo un parámetro.

Fuente: Elaboración propia. En la figura se observa un nuevo elemento al final de la estructura, dicho elemento es un parámetro para obtener un recurso en específico, al añadir dicho parámetro el retorno del servicio cambia respecto a la primera estructura de endpoint presentada, siendo que la primera retornará un listado del recurso indicado, “Contrato” mientras que la segunda siempre deberá retornar el contrato con identificador “2”. El método http: La acción ejecutada al hacer un request depende en gran medida del verbo http que se seleccione, este se envía junto al endpoint. Los verbos http cuyo uso es más habitual son los siguientes: GET: Obtiene datos sobre el recurso solicitado. POST: Crea un recurso. PUT / PATCH: Actualiza recursos. DELETE: Elimina recursos.

16

Cuando se ejecuta un request colocando un endpoint en la barra de búsqueda de un navegador web por defecto se ejecuta un GET. Encabezados http: Los encabezados se usan para almacenar metadatos útiles al cliente como al servidor. Allí viajan elementos como tokens de autenticación, cookies, el tipo de contenido esperado, entre otros (Chiang, 2021). Cuerpo de datos: El cuerpo de datos o body data, es la información que se desea enviar al servidor desde el cliente y se envía como una cadena de datos codificada en formato JSON, el envío de datos se emplea con los métodos http POST, PUT y PATCH asociados a escritura de datos. RESTful response En una respuesta http se encuentra el código de estado dentro de un header el cual es retornado siempre y un cuerpo de datos también en formato JSON el cual no se retorna obligatoriamente. Los códigos de estado son números entre 100 y 500 cuyo propósito es informar el estado de completitud de la solicitud (Chiang, 2021). A continuación, se menciona la descripción de los códigos de estado que pueden responderse a una solicitud (Mozilla, 2005-2021):

• Respuestas informativas, para códigos del 100 al 199,

• Respuestas satisfactorias, para códigos del 200 al 299,

• Redirecciones, para códigos del 300 al 399,

• Errores de los clientes, para códigos del 400 al 499,

• y errores de los servidores, para códigos del 500 al 599.

4.3. SEGURIDAD JWT (JSON Web Tokens) Una API como se ha descrito en las secciones anteriores, puede ser fácilmente accedida, en especial si está se encuentra en internet, por ello es fundamental contar con un factor de autenticación. Un método común para implementar la seguridad de una API es JWT (JSON Web Tokens). JWT es un estándar abierto para la creación de tokens que garanticen compartir información de forma segura entre dos partes, este estándar está basado en JSON (Auth0, s.f.) y fue propuesto por la IETF (Internet Engineering Task Force) encargada de la regulación de estándares de internet, conocidos como RFC, el estándar para JWT es RFC 75191.

1 Documento para el estándar RFC 7519: https://datatracker.ietf.org/doc/html/rfc7519

17

La ventaja que nos proporciona JWT es que la información es validada y por lo tanto confiable ya que se firma digitalmente, garantizando que esta no haya sido modificada entre el emisor y el receptor. Su funcionamiento consiste en que primero el cliente debe solicitar un token de acceso y esto lo hace proporcionando un usuario y una contraseña digitados por el usuario, luego del lado del servidor se validan las credenciales y si correctas, se genera un token JWT que es retornado al cliente, una vez el cliente cuente con este token debe anexarlo en el header de cada una de las peticiones que envíe al servidor. El token tiene un tiempo limitado de validez. Un token JWT está compuesto de:

• Header: Encabezado o Header contiene el algoritmo y tipo de token.

• Payload: Es la información que queremos transmitir, típicamente los datos del usuario.

• Signature: Conformado por el header, payload y un secreto confidencial, él cual es definido dentro de la API. El header y el payload junto al secreto se codifican en un string o cadena de texto en base64.

A continuación, se muestra un token JWT codificado y decodificado, diferenciando por colores cada una de las partes que se acaban de indicar:

18

Figura 4. Ejemplo de JWT codificado y decodificado.

Fuente: (Auth0, s.f.)

4.4. ARQUITECTURA HEXAGONAL Arquitectura hexagonal es uno de los nombres que ha adoptado el enfoque DDD (Diseño Dirigido al Dominio), también ha sido denominada de Puertos y Adaptadores, así como también Arquitectura de Cebolla o Arquitectura Limpia (Smith, 2021). Dentro de tal enfoque se vela por mantener aislado el modelo de negocio de la implementación técnica, para ello se dividen determinadas responsabilidades de la solución en capas según sean las necesidades del negocio. En la siguiente figura se presenta la representación de una arquitectura en capas centrada en el dominio de la aplicación.

19

Figura 5. Representación de arquitectura en capas Dirigida al Dominio.

Fuente: Elaboración propia basada en (Smith, 2021). En la figura se aprecian ciertas divisiones, entre ellas una central la cual no tiene dependencias con las demás capas, en ella se contemplan las entidades del negocio e interfaces, en el siguiente nivel se encuentra la capa de aplicación, allí se encuentran los servicios de dominio que implementan las interfaces especificadas en el núcleo, el siguiente nivel comprende la interacción con servicios que pueden ser sustituidos en razón de la evolución de la aplicación, como lo son servidores, bases de datos y clientes ya sean web o aplicaciones móviles, estos últimos se conectan gracias a la exposición de servicios a través de una interfaz REST o cualquier otro estilo. El flujo de dependencia entre capas va desde el exterior al núcleo y no en sentido contrario (Smith, 2021). Para desarrollar aplicaciones con arquitecturas como la hexagonal, se emplean patrones de diseño como el Patrón Repositorio, Unidad de trabajo, Inyección de dependencias y en general se procura mantener los principios SOLID. “Determinadas decisiones arquitectónicas pueden condenar el futuro de grandes aplicaciones” (Microsoft Ibérica, 2010), el trabajo respecto a este tipo de arquitectura orientado al dominio es un gran avance en el intento por lidiar con el aspecto tecnológico sin arriesgar el uso de buenas prácticas cuando se necesita que los requerimientos varíen o la integración de nuevos módulos, es por ello la importancia de decidir una arquitectura para no comprometer el futuro de la aplicación.

20

4.5. ARQUITECTURA BASADA EN COMPONENTES Y SPA’s Entre los enfoques para desarrollar aplicaciones web se encuentran aquellas cuya lógica de interfaz es ejecutada desde el servidor y retornada al cliente de tal forma que, por petición o acción realizada por el usuario, se recarga toda la página en la que este se encuentre. El otro enfoque es el de las SPA (Single Page Application), las aplicaciones de una sola página son aquellas cuya lógica de interfaz se renderiza en un navegador web y tiene la capacidad de acceder a servicios de lógica de negocio invocando API’s (Smith, 2021), este tipo de aplicaciones se desempeña dentro de la dinámica de la arquitectura Cliente Servidor, haciendo las veces del Cliente; son desarrolladas en uso de Frameworks JavaScript y son la opción a elegir cuando se quiere desacoplar la lógica de interfaz de procesamientos relacionados a operaciones de bases de datos, entre otros servicios. Las SPA se construyen en una sola página sobre la cual se emplean distintas técnicas para evitar actualizar secciones de la aplicación que no lo requieran entre ellas siendo de resaltar el renderizado de elementos y secciones de la interfaz como componentes los cuales pueden ser reutilizables, permitiendo la implementación de arquitectura basada en componentes.

21

5. MARCO NORMÁTIVO La normatividad externa asociada a este proyecto se enmarca en lineamientos de software e informática definidos legalmente, como por ejemplo la ley de protección de datos (LEY ESTATUTARIA 1581, 2012), dado el caso de recopilación de datos personales de los interesados o futuros involucrados en el uso de la plataforma web, así como de los participantes en proyectos y contratos que se registren en la plataforma. También son consideradas las pautas de accesibilidad para los sitios web (NTC 5854, 2011), mediante la cual se establecen guías a tener en cuenta para facilitar el manejo de un sitio a cualquier persona sin importar sus capacidades físicas, y sin llegar a afectar su estado mental o de salud, producto del contenido que allí se pueda presentar, además de estar ligada al lineamiento legal del manual GEL, de Gobierno en Línea. Tal norma técnica está referida para Colombia, aplicando a las páginas web de las entidades públicas, sin embargo, esta se basa en las pautas de accesibilidad al contenido web que deberían ser genéricas a cualquier página web según la W3C, (WCAG, 2008).

22

6. MARCO INSTITUCIONAL

La institución de la cual se toma como base el modelo de negocio para realizar el presente trabajo se denomina EDAT (Empresa Departamental de Acueducto, Alcantarillado y Aseo del Tolima) y está encargada de gestionar en el Tolima los distintos proyectos sobre acueducto, alcantarillado y aseo que radiquen los municipios, dependiendo de sus necesidades. La EDAT S.A. E.S.P, es la empresa encargada por la Gobernación del Tolima como responsable de la gestión del Plan Departamental de Agua y saneamiento – PDAT (Acuerdo No.21, 2015), en cuyos objetivos institucionales destacan la Promoción en el corto y en el mediano plazo la transformación de los municipios y la conformación de esquemas regionales que garanticen la prestación eficiente de los servicios públicos de agua potable y saneamiento básico, también asegurar la protección y conservación de las fuentes abastecedoras de acueductos urbanos y rurales. Un punto importante dentro de la conformación del sistema de software es la identificación del grupo de dependencias organizacionales de la EDAT que dentro de este conformarían el grupo de roles de la aplicación. Se tomarán como roles de la aplicación la dependencia Gerencia, Secretaría General, encargada de la gestión de proyectos, Dirección técnica encargada del apoyo para la formulación de proyectos.

23

7. ANTECEDENTES

Para la gestión de la información empresarial a menudo suelen ocuparse herramien-tas especializadas que proporcionan beneficios como la integración de artefactos BPM para la gestión de procesos asíncronos (Pacheco Casadiego, 2017) lo cual suele resultar de suma utilidad a la hora de plasmar los protocolos que se suelan aplicar en la gestión de un proceso cualquiera que sea. También es común encon-trar el manejo de gestores documentales con el soporte suficiente para respaldar el archivo de una organización adaptándose de forma dinámica a la demanda de esta (EKCIT, 2018).

En la actualidad, muchas empresas que necesitan hacer uso de gestión de contra-tos han decidido utilizar software y no depender de la forma tradicional para ello, pero esto se observa generalmente en el núcleo de empresas privadas.

Dentro de la demanda de sistemas para administrar información de este tipo y oferta disponible en el mercado encontramos:

• Contar con la información en un solo lugar y acceder a ella de forma rápida, preservando su integridad en especial si se trata de gestión de archivos do-cumentales, algunas entidades recurren a sistemas de gestión documental (DMS, Document Management System), especializado en la gestión de sec-ciones documentales para contratos (EKCIT, 2018).

• Reguladores del trabajo en equipo que incluyen un sistema específico para la gestión del ciclo de vida del contrato (CLM, Contract Lifecycle Manage-ment) (Villanova University, 2012) , especiales para el manejo de procesos asíncronos, es decir que suceden durante distintos períodos de tiempo.

• Algunas entidades han recurrido al uso de software que permite la planifica-ción de recursos empresariales (ERP, Enterprise Resource Planning).

• También podemos encontrar sistemas (CRMS, Contract Risk Management), cuya traducción al español sería Gestión de Riesgos Contractuales que ha sido útil para aquellas multinacionales que presentan contratos que involu-cran a muchas partes en donde el incumplimiento de una de estas puede ser fatal para el desempeño de la empresa, por ello, este tipo de software (CRMS) ayuda a estimar los riesgos que surgen en las revisiones de los con-tratos y ayuda a mitigarlos.

24

8. METODOLOGÍA.

8.1. ESTRATEGIA DE DESARROLLO. Se emplea una estrategia evolutivo incremental, llevándose a cabo la división del trabajo en fases acorde a los módulos y requerimientos que contemplan la constitución del sistema. Cada uno de los módulos comprende el análisis, identificación de requisitos, construcción y prueba de estos. El primer incremento comprende el desarrollo de los requisitos del sistema para dar cumplimiento a los requisitos no funcionales, entre los cuales se contempla implementación de la arquitectura, autenticación y autorización de usuarios. El segundo incremento comprende la entrega del módulo de Proyectos. Tal desarrollo comprende las características de creación, edición consulta y la asociación de tablas tipo de las cuales depende. Por último, se entrega el módulo de Contratos, para el cual se contará con las operaciones de creación, edición, consulta, y eliminado, así también la asociación de contratistas, el detalle financiero y sección para registrar modificatorios.

8.2. ANÁLISIS Se tiene como base la abstracción de los procesos indicados por el EDAT para determinar los datos más relevantes sobre las entidades proyectos y contratos centralmente, sobre lo cual se analizan los procesos asociados al registro de ambas entidades, y se levantan los respectivos requerimientos y modelos de datos para la construcción de la base de datos. Tener claridad de las características con las que debe contar la información que se almacene es clave, y por ello se deben aplicar los debidos procesos para realizar el modelo conceptual de datos (Pacheco Casadiego, 2017), pues es de vital importancia contar con información precisa y confiable en la base de datos (Godinez & Segura, 2011). Haciéndose indispensable que los datos sean organizados y presentados de forma que puedan ser útiles para los usuarios que estudien un caso específico, pues de ello depende la transformación de los datos en información útil (Godinez & Segura, 2011), solo si esto y que los datos registrados sean reales se cumple, es posible apoyar el control y gestión a través de un sistema y sumar valor a la labor de la entidad.

25

Dentro del marco del modelo de negocio del EDAT, existen diversos interesados externos en la gestión de los procesos; los Municipios a quienes se les debe brindar información de cómo van sus encargos, así como también a otro tipo de entidades de orden Gubernamental nacional quienes se encargan de aprobar o brindar los recursos financieros que para los estudios previos, costes de formulación o de ejecución que se requieren, y a quienes también se les debe dar cuenta de los procesos cuando se presentan por ejemplo solicitudes de aprobación de proyectos. En el propósito de cumplir con una solución acertada se encuentra como esencial el análisis del modelo de negocio de la EDAT haciendo uso de los principios de relación de las entidades de un sistema acotando para este proyecto las dependencias para los subsistemas de proyectos y contratos.

8.3. IDENTIFICACIÓN DE LOS REQUERIMIENTOS DEL SISTEMA. Para dar inicio al proyecto realizando el análisis y levantamiento de requerimientos se emprende un proceso investigativo y de observación en donde se realizan reuniones con los funcionarios del EDAT para identificar los protocolos seguidos en la gestión de proyectos y contratos más allá de la manera en cómo se almacena la información. Al realizar esta fase del proyecto, se hace uso de herramientas como entrevistas, y revisión de documentos proporcionados por el EDAT. Con la información recolectada se empieza por identificar los requerimientos a través del análisis del funcionamiento de la organización, para así determinar el modelo de dominio de la aplicación, el cual se refiere al grupo de objetos o entidades del mundo real representadas en un dominio de interés (Pacheco Casadiego, 2017)

8.4. DEFINICIÓN DEL MODELO DE DOMINIO DE LA APLICACIÓN. Un modelo de dominio, es la representación de clases conceptuales de la realidad, no hace referencia a la descripción de componentes de software ni de diagramas que describan clases software, u objetos software con responsabilidades (Peñalvo & García Holgado, 2017/2018). A continuación, se listan las clases conceptuales candidatas relacionadas con los requisitos actuales en estudio las cuales se modelan en la base de datos: Tabla 1. Descripción de entidades del dominio del sistema.

26

Entidad Descripción

Proyecto Representa la abstracción de un proyecto que pueda tener a cargo la EDAT.

Tipo proyecto Son las categorizaciones que se pueden tener de un proyecto.

Tipo estado proyecto Son los tipos de estados por los que puede pasar un proyecto

Entidad financiera Son las entidades externas a la EDAT a través de las cuales se espera obtener los recursos económicos para el desarrollo de este.

Entidad revisora Se incluye dentro de entidades externas a la EDAT las cuales se encargan de determinar la viabilidad de un proyecto a través de la verificación del cumplimiento de requisitos específicos.

Modalidad presentación

Son las modalidades en las cuales un municipio puede presentar a la EDAT un proyecto, indicando si tal proyecto requiere apoyo para conseguir viabilidad o un concepto técnico.

Contrato Representa la abstracción de contratos que tenga a cargo la EDAT.

Tipo contrato Son la categorización de los contratos de la EDAT

Tipo estado contrato Son los tipos de estados por los que puede pasar un contrato

Modalidad de selección

Son los tipos de procedimientos que se pueden llevar a cabo para seleccionar un contratista

Modificatorio Son las modificaciones que se puedan aplicar sobre un contrato.

Tipo de modificatorio Representa los tipos de modificaciones que se puedan aplicar sobre un contrato.

financiación del contrato

Representa la abstracción de las entidades que asumen la financiación de un contrato.

Lugar Los sitios en donde se registrarán procesos asociados a proyectos o contratos

Tipo lugar Representa la abstracción de los tipos de lugares que se registren.

27

Contratista Representa la abstracción de una entidad o persona natural a quien se encarga la realización de una labor o servicio dentro de un contrato.

Representante legal Es una persona natural que es responsable de una entidad contratista.

supervisor Es la persona encargada de supervisar e informar actualizaciones de un contrato o proyecto.

usuario Representa la abstracción de una persona que tiene acceso a la plataforma

Rol Son los tipos de usuarios que tienen acceso al sistema.

Fuente: Elaboración propia. Con la definición del modelo de dominio de la aplicación se elabora un modelo lógico del funcionamiento de esta, insumo indispensable para la construcción de un modelo físico de datos a partir del cual se genere el script de base de datos. A continuación, se relacionan los diagramas entidad relación que modelan el dominio de la aplicación y las relaciones entre entidades:

28

Figura 6. Diagrama del modelo lógico de entidad relación parte 1.

Fuente: Elaboración propia.

29


Figura 7. Diagrama del modelo lógico de entidad relación parte 2.

30

Figura 8. Diagrama del modelo físico de entidad relación parte 1.


31

Figura 9. Diagrama del modelo físico de entidad relación parte 2.


32

8.5. DIAGRAMAS DE CASOS DE USO

Figura 10. Diagrama de caso de uso de actores.

Fuente: Elaboración propia. Figura 11. Diagrama de caso de uso de ingreso al sistema.


33

Figura 12. Diagrama de caso de uso sobre los procesos del sistema.

Fuente: Elaboración propia. Figura 13. Diagrama de caso de uso sobre la gestión de proyectos.


34

Figura 14. Diagrama de caso de uso sobre la gestión de contratos.

Fuente: Elaboración propia. Figura 15. Diagrama de caso de uso sobre la administración de entidades externas.


35

8.6. REQUISITOS DEL SISTEMA

8.6.1. REQUISITOS FUNCIONALES.

Tabla 2. Registro de nuevo usuario.

Numero de requisito RF 01

Nombre del Requisito Registro de nuevo usuario.

Tipo Funcional

Fuente del Requisito Interesados

Prioridad del Requisito Alta

Descripción del Requisito El sistema permite el registro de un nuevo usuario, acción que puede realizar únicamente un usuario administrador previamente autenticado y autorizado para ingresar al sistema.

Fuente: Elaboración propia. Tabla 3. Ingreso al sistema y cierre de sesión.


Nombre del Requisito Ingreso al sistema y cierre de sesión

Tipo Funcional



Descripción del Requisito El sistema permite el inicio de sesión a un usuario previamente registrado, así como permite el cierre de sesión luego de cierto tiempo. Ninguna característica del sistema se puede usar sin este caso de uso.

Fuente: Elaboración propia. Tabla 4. Creación de proyecto.


Nombre del Requisito Creación de proyecto

Tipo Funcional



Descripción del Requisito El sistema permite formular un proyecto indicando allí las entidades de las cuales

36

dependa para completar su descripción, por ejemplo: tipo de proyecto, modali-dad de presentación, etc.

Fuente: Elaboración propia. Tabla 5. Gestión de datos de proyecto.


Nombre del Requisito Gestión de datos de proyecto

Tipo Funcional


Prioridad del Requisito Media

Descripción del Requisito El sistema permite gestionar los datos de proyectos, a través de la actualización de su estado, la consulta, y la edición de da-tos asociados.

Fuente: Elaboración propia. Tabla 6. Registro de contrato.


Nombre del Requisito Registro de contrato

Tipo Funcional



Descripción del Requisito El sistema permite registrar un contrato indicando allí las entidades de las cuales dependa para completar su descripción, por ejemplo: tipo de contrato, modalidad de selección, contratista, etc.

Fuente: Elaboración propia. Tabla 7. Gestión de datos de contrato.


Nombre del Requisito Gestión de datos de contrato

Tipo Funcional



Descripción del Requisito El sistema permite gestionar los datos de contrato, a través de la actualización de

37

su estado, la consulta, y la edición de da-tos asociados.

Fuente: Elaboración propia. Tabla 8. Administración de usuarios.


Nombre del Requisito Administración de usuarios

Tipo Funcional



Descripción del Requisito El sistema permite administrar los datos de los usuarios vinculados al sistema, in-volucrando las operaciones creación y edición o actualización.

Fuente: Elaboración propia. Tabla 9. Administración de entidades externas a proyectos y contratos.


Nombre del Requisito Administración de tablas tipo

Tipo Funcional



Descripción del Requisito El sistema permite administrar los datos de las tablas tipo que presentan relación con proyectos y contratos, entre ellas: Ti-pos de contratos y proyectos, entidades revisoras, entidades financieras, tipos de estado etc.


8.6.2. REQUISITOS NO FUNCIONALES. Tabla 10. Rendimiento.

Numero de requisito RNF 01

Nombre del Requisito Rendimiento

Tipo No funcional o del sistema

Fuente del Requisito Arquitecto


Descripción del Requisito Garantizar la fluidez de navegación y res-puesta rápida de API.

38

Fuente: Elaboración propia. Tabla 11. Seguridad.


Nombre del Requisito Ingreso y cierre de sesión


Fuente del Requisito Arquitecto, EDAT


Descripción del Requisito El acceso al Sistema se encuentra prote-gido mediante un método de seguridad que implica la autenticación y conse-cuente autorización del uso del sistema al usuario, para así garantizar la protección de los recursos de la API y seguridad de datos.

Fuente: Elaboración propia. Tabla 12. Interoperabilidad.


Nombre del Requisito Interoperabilidad




Descripción del Requisito Las funcionalidades de los componentes son fácilmente utilizables por otros com-ponentes permitiendo la interacción en-tre estos y la facilidad para interactuar con otros recursos o API’s.

Fuente: Elaboración propia. Tabla 13. Flexibilidad al cambio.


Nombre del Requisito Flexibilidad al cambio




Descripción del Requisito El sistema es flexible al cambio, de forma que la modificación de los componentes existentes tenga baja repercusión en la

39

implementación de otras secciones y se pueda realizar de forma mantenible.

Fuente: Elaboración propia. Tabla 14. Escalabilidad.


Nombre del Requisito Escalabilidad




Descripción del Requisito El Sistema permite la implementación de nuevos componentes y módulos sin re-querir grande esfuerzo en la modifica-ción de implementaciones previas.

Fuente: Elaboración propia. Tabla 15. Usabilidad.


Nombre del Requisito Usabilidad




Descripción del Requisito El sistema proporciona la facilidad para utilizar las funcionalidades implementa-das a través de interfaces de usuario fáci-les de entender a nivel de API y de fron-tend o interfaz gráfica para el Cliente.


8.7. TECNOLOGIAS Entre las tecnologías principales para la implementación del sistema GESCA3T, lenguajes de programación y herramientas usadas acorde a la capa del proyecto encontramos: Capa Frontend o aplicación del lado Cliente:

• JavaScript. (Mozilla, 2021)

• TypeScript. (Microsoft, 2021)

40

• HTML5. (Mozilla, 2021)

• CSS3. (Mozilla, 2021)

• Framework Angular v9. (Google, 2021)

• Framework CSS PrimeNg v 9-LTS. (PrimeNg, 2021)

• Editor WebStorm. (JetBrains, 2021) Capa Backend, aplicación del lado del servidor:

• C Sharp. (Microsoft, 2021)

• .Net Core v3. (Microsoft, 2020)

• Editor Visual Studio 2019. (Microsoft, 2021)

• Cliente Postman, para ejecutar peticiones a la API construida. (Postman, 2021)

Capa de Datos:

• Motor SQL Server. (Microsoft, 2021) Herramientas CASE:

• Power Designer, para el modelado de bases de datos y generación de script. (Novalys, 2019)

• Figma, para el diseño de interfaz de usuario. (Figma, 2021)

• StarUML, para la construcción de diagramas de casos de uso. (MKLabs Co., 2021)

41

9. RESULTADOS.

Tras cumplir la fase de construcción del software diseñado se obtienen los siguientes resultados:

9.1. RESULTADOS PLATAFORMA DEL LADO DEL CLIENTE: Figura 16. Interfaz de ingreso al sistema, acceso autorizado.

Fuente: Elaboración propia. Figura 17. Interfaz de ingreso al sistema, acceso no autorizado.


42

En la pantalla de ingreso se permite a un funcionario indicar nombre de usuario y contraseña, a fin de ser autenticado en el sistema y posteriormente autorizado para acceder a las distintas funcionalidades con las que cuenta. En las imágenes se observa la retroalimentación por parte del sistema luego de validar que las credenciales son correctas a través de un componente visual denominado Toast. En el proceso de ingreso, tras un escenario exitoso el sistema genera un token JWT el cual va a usar para las posteriores interacciones con el sistema, como garantía de autorización de acceso exclusivo al usuario en sesión a recursos y características. Figura 18. Interfaz datos de perfil.

Fuente: Elaboración propia. En la imagen anterior se aprecia la interfaz desde la cual un usuario puede consultar los datos que el sistema almacena de él, además de poder realizar edición sobre los mismos en el formulario que se observa en la parte inferior.

43

Figura 19. Interfaz home y métricas.

Fuente: Elaboración propia. En esta imagen se observa el home o vista inicial con la cual se encuentra el usuario luego de iniciar sesión, allí se dispone una sección sencilla denominada Métricas en donde se muestra un resumen de la gestión respecto a proyectos llevada a la fecha, enmarcada dentro de una estructura gráfica conformada por los componentes de menú lateral, barra de navegación o miga de pan y un encabezado. A continuación, se dispone un módulo central del sistema desde el cual se realizan las operaciones para la entidad proyecto:

44

Figura 20. Interfaz módulo de proyectos, formulación.

Fuente: Elaboración propia. En la imagen se aprecian las operaciones que se pueden realizar dentro del módulo proyectos, las cuales son; poder crear un proyecto o formularlo, editarlo, realizar consultas, y actualizaciones o revisiones, cuya navegación se logra gracias a componentes radio botón. Figura 21. Interfaz módulo proyecto, edición.

45

Fuente: Elaboración propia. En la anterior imagen se observa el formulario para la edición de datos de un proyecto al cual se llega mediante una búsqueda o filtro por los atributos código o nombre. Figura 22. Interfaz módulo proyectos, búsqueda.

Fuente: Elaboración propia. La interfaz de búsqueda de proyectos contempla un filtro un poco más amplio que incluye los atributos de municipio, nombre y código; los resultados de búsqueda se arrojan dentro de tarjetas de datos las cuales indican el estado actual del proyecto. Las siguientes interfaces corresponden al módulo contratos, para el cual se dispone una navegación similar a la anterior en donde se ocupan radio botones para ingresar a la operación que el usuario requiera.

46

Figura 23. Interfaz módulo contratos, registro.

Fuente: Elaboración propia. La imagen anterior corresponde al formulario de registro de un contrato. Figura 24. Interfaz módulo contratos, sección de registro, tiempos y valor.

Fuente: Elaboración propia. Dentro del registro de un contrato se incluyen secciones para el registro de los tiempos del contrato y su precio, como se muestra en la imagen anterior.

47

Un siguiente módulo construido es el de Municipios, para este se implementa un filtro de proyectos categorizados según el municipio. Figura 25. Interfaz módulo Municipios, búsqueda.

Fuente: Elaboración propia. Se construye también el módulo de administración, desde donde se pueden realizar las operaciones CRUD para entidades tipo, por ejemplo, Tipos de proyecto de contrato, de modalidad de selección, entre otras. Y la administración de los usuarios del sistema.

48

Figura 26. Interfaz módulo Administración, gestión de entidades.

Fuente: Elaboración propia. Como se observa en la imagen en este módulo se emplea el mismo sistema de navegación de los módulos anteriores, sumado a un componente que permite contraer y extender secciones denominado acordeón como se observa en la anterior y siguiente imagen. Figura 27. Interfaz módulo de Administración, entidades.


49

Por otra parte, se destaca el diseño y construcción de componentes gráficos intuitivos que facilitan la navegación entre la plataforma, enriqueciendo la experiencia de usuario. En la siguiente captura se señala la disposición en pantalla de dos elementos, el primero un botón que permite contraer el menú lateral para ampliar un poco el espacio sobre el cual se realizan acciones. haciendo el proceso más cómodo visualmente. El otro componente señalado es una pequeña barra de navegación que permite al usuario orientarse respecto al módulo sobre el cual se encuentra y regresar fácilmente a la sección inicial o home de la plataforma. Figura 28. Componentes para mejorar la experiencia de usuario.


50

La siguiente interfaz se utiliza para dar información al usuario de que esta accediendo a una URL dentro del sitio web que no existe o esta errada, para evitar que parezca que existen escenarios no controlados. Figura 29. Interfaz página no encontrada.


9.2. RESULTADOS PLATAFORMA DEL LADO DEL SERVIDOR: Del lado servidor encontramos la API GESCA3T, esta API está documentada de forma automática gracias a la herramienta Swagger, que tras configurarla genera una interfaz gráfica que muestra cada uno de los recursos a los que tenemos acceso y los métodos http que podemos ejecutar desde allí mismo por cada entidad contemplada. La descripción dada es lo que podemos apreciar en las siguientes imágenes:

51

Figura 30. Documentación de API a través de Swagger.

Fuente: Elaboración propia. Figura 31. Recursos o entidades del sistema con sus métodos http.

Fuente: Elaboración propia. Dentro de esta interfaz Swagger generada, también se encuentra el grupo de atributos correspondientes a cada entidad de negocio con su respectivo tipo de dato, como se aprecia en la siguiente imagen para la entidad Contratista:

52

Figura 32. Atributos de las entidades del sistema, entidad Contratista.

Fuente: Elaboración propia. Tal listado de atributos presentados en la imagen es indispensable para poder acceder a los métodos http (POST, PUT) dispuestos para cualquier entidad, ya que conformaran el contenido del documento JSON usado para la comunicación con una API, por lo cual deben escribirse tal y como se muestra en el listado. La ejecución de los métodos se puede realizar directamente desde esta interfaz. Figura 33. Ejecución de solicitud o request a API del sistema.


53

Para el caso de la anterior imagen se dispone la ejecución del método POST para el recurso Usuario, es decir la creación de un nuevo usuario, para lo cual podemos observar el path de la solicitud “/api/Usuario” un Request Body, y el método http indicado. De la misma forma en la siguiente imagen se observa la preparación de un request o solicitud para generar un token JWT. Allí se aprecia el ingreso del nombre de usuario y una contraseña en el cuerpo del mensaje o Request Body, como indica la imagen. Figura 34. Ejecución de solicitud para generación de token JWT.

Fuente: Elaboración propia. La respuesta para la petición de generación de token se observa de la siguiente manera, en la figura 35 allí se encuentra un código de respuesta, para el caso fue 200 es decir que la operación fue exitosa y un response body, en el cual se retorna un token JWT y los datos del usuario que solicito el ingreso al sistema.

54

Figura 35. Respuesta de API a solicitud de generación de token JWT.


55

10. CONCLUSIONES El software es una gran abstracción de la realidad, y según las practicas que se ocupen en su ciclo de vida incluyendo planeación, análisis, diseño, construcción y puesta en producción, tal representación de una porción de la realidad, puede convertirse en un gran aliado de la labor para la cual fue pensado, permitiendo un mayor porcentaje de gobernabilidad sobre los factores involucrados en un proceso; dada la organización de los datos a través de modelos de ingeniería que mejoran la productividad de una organización. En tal sentido el impacto del desarrollo del sistema GESCA3T es considerable teniendo en cuenta que se da un paso de registrar los datos en tablas de Excel en una base de datos modelada especialmente para las necesidades, a través de una API o un cliente front-end, lo cual facilita la ejecución de labores a los funcionarios, pudiendo visualizar de manera ordenada la información, la cual además de ello adquiere un nuevo nivel de confiabilidad ya que esta se encuentra centralizada y se permite mantener en su versión más actualizada dados los casos de uso de edición y actualización pensados para el sistema. Entre otros aspectos se tiene que, en la fabricación de software es de crucial importancia distinguir que el mundo real está lleno de muchas variables las cuales ameritan tratarse de manera acotada y acorde a las prioridades del negocio y así poder simplificar la complejidad que puede representar modelar el dominio e interacción de entidades de un sistema. Según lo anterior, aún queda por analizar más a detalle este sistema, para construir por ejemplo las características que respectan al papel especifico que debe desempeñar cada rol en el sistema, es decir, detallar permisos y restricciones según el rol que desempeñan los funcionarios de la organización; la incorporación de otros módulos, como por ejemplo un módulo en donde la EDAT pueda llevar control sobre el soporte que prestan a los municipios para que formulen sus proyectos, incluyendo por ejemplo listas de chequeo, además de la administración de los ítems o parámetros de estas listas de chequeo. Por otra parte, la consideración de buenas prácticas como el desacoplamiento de la lógica de negocio de las formas específicas de realizar operaciones genéricas de software brinda claridad al panorama de crecimiento de la plataforma y a la vez de la forma en cómo se va a construir, dado que se simplifica, dando una mayor garantía del futuro que puede llegar a tener una plataforma, en términos de mantenibilidad y escalabilidad. Acorde a lo dicho, investigar y considerar los estándares de la industria en la construcción de software permite elaborar soluciones o productos de mejor calidad,

56

más compatibles y que no se vean afectados a corto plazo porque sus tecnologías de base queden obsoletas. Por lo anterior fue crucial para este proyecto definir con claridad dos aspectos, el primero los módulos de negocio a desarrollar y segundo la arquitectura de software en sus distintos niveles; de esta forma se parte con la identificación de temas cruciales en la construcción de una plataforma a la cual se le puede garantizar un futuro, en el sentido de que en su fase de soporte los distintos impactos de cambios o errores se puedan ejecutar sin tener que sacrificar módulos enteros del sistema, gracias al uso de buenas prácticas, en especial el desacople de la lógica del negocio de las implementaciones técnicas entre otras y el uso de cliente servidor. Finalmente construir software es la unión de muchos procesos de ingeniería entre los cuales es de suma importancia la habilidad de la comunicación, y en especial, cuando se construye software a la medida, en donde la interacción constante con los interesados es vital para definir la utilidad real del sistema y las expectativas que se tienen, ya que de fallar en ello pudiese darse el caso de inconformismos y que a la larga el sistema desarrollado no se use porque no funciona como se esperaba. De ahí la importancia de las estrategias que se usen para levantar requerimientos, y sobre todo el cuidado y profesionalismo por parte de la persona encargada para identificar lo que el interesado verdaderamente necesita.

57

BIBLIOGRAFÍA

Acuerdo No.21. (2015). Por medio del cual se aprueba la Modificación al Manual

Específico de funciones, requisitos y de Competencias Laborales, para la

Empresa Departamental de Acueducto Alcantarillado y Aseo del Tolima

EDAT, y se redefine su estructura Orgánica. Gobernación del Tolima.

Aguilar, P. P., & Palacios, C. Y. (2015). Propuesta de implementación de un marco

de trabajo para el desarrollo de aplicaciones Android. Proyecto Profesional.

Lima: Universidad Peruana de Ciencias Aplicadas (UPC).

Arnold, M., & Osorio, F. (1998). Introducción a los conceptos básicos de la teoría

general de sistemas. Revista de Epistemología de Ciencias Sociales, 40-49.

Auth0. (s.f.). jwt.io. Obtenido de https://jwt.io/introduction

Barry, D. K. (2000 - 2021). service-architecture. Obtenido de https://www.service-

architecture.com/articles/web-services/representational-state-transfer-

rest.html

Castro, L. (2015). Arquitectura del Software. Coruña, España: Cengage Learning

Editores. Recuperado el 22 de 06 de 2021

Chiang, B. (27 de Julio de 2021). 5 Minute Intro to REST APIs. Obtenido de newline:

https://www.newline.co/@bchiang7/5-minute-intro-to-rest-apis--b5081674

EKCIT. (24 de 04 de 2018). Tic.portal. Obtenido de https://www.ticportal.es/glosario-

tic/gestion-contratos

EKCIT. (s.f.). Tic.PORTAL. Obtenido de https://www.ticportal.es/temas/enterprise-

resource-planning/que-es-sistema-erp

Fielding, R. T. (2000). Architectural Styles and the Design of Network-based

Software Architectures. Doctoral dissertation. University of California, Irvine.

Figma. (2021). Figma. Obtenido de https://www.figma.com/

Godinez, & Segura, L. (2011). La importancia de contar con información precisa,

confiable y oportuna en las bases de datos. Revista Nacional de

Administración.

58

Google. (2021). Angular. Obtenido de https://angular.io/docs

IACCM. (s.f.). El rol del Gerente de Contratos.

JetBrains. (2021). JETBRAINS. Obtenido de https://www.jetbrains.com/es-

es/webstorm/

Ledesma, J. D. (2005).

https://books.google.es/books?id=SrlsWWdn2SIC&printsec=frontcover&hl=

es#v=onepage&q&f=false. Bogotá, Colombia: Universidad Cooperativa

(Educc). Obtenido de

https://books.google.es/books?id=SrlsWWdn2SIC&printsec=frontcover&hl=

es#v=onepage&q&f=false

LEY ESTATUTARIA 1581. (2012). Obtenido de

http://www.secretariasenado.gov.co/senado/basedoc/ley_1581_2012.html

Luján Mora, S. (03 de 04 de 2009). accesibilidadweb.es. Obtenido de

accesibilidadweb.es: http://accesibilidadweb.es/accesibilidad-web

Marini, E. (2012). El Modelo Cliente/Servidor.

Marvin R, C. K. (28 de 08 de 2018). pcmag-com. Obtenido de pcmag-com:

https://www.pcmag.com/picks/the-best-contract-management-software

Microsoft. (16 de Noviembre de 2020). Microsoft Docs. Obtenido de

https://docs.microsoft.com/es-es/dotnet/core/introduction

Microsoft. (2021). Microsoft Data platform. Obtenido de

https://www.microsoft.com/es-es/sql-server/sql-server-downloads

Microsoft. (23 de 08 de 2021). Microsoft Docs. Obtenido de

https://docs.microsoft.com/en-us/dotnet/csharp/tour-of-csharp/

Microsoft. (2021). Microsoft Visual Studio. Obtenido de

https://visualstudio.microsoft.com/es/downloads/

Microsoft. (2021). TypeScript. Obtenido de

https://www.typescriptlang.org/docs/handbook/intro.html

Microsoft Ibérica. (2010). GUÍA DE ARQUITECTURA N-CAPAS ORIENTADA AL

DOMINIO CON .NET 4.0. Krasis Consulting.

59

MKLabs Co. (2021). StarUML. Obtenido de https://staruml.io/

Mozilla. (2005-2021). MDN Web Docs. (Mozilla, Productor) Recuperado el 2021, de

https://developer.mozilla.org/es/docs/Web/HTTP/Status

Mozilla. (12 de Septiembre de 2021). MDN Web Docs. Obtenido de

https://developer.mozilla.org/es/docs/Learn/JavaScript/First_steps/What_is_

JavaScript


https://developer.mozilla.org/es/docs/Web/HTML


https://developer.mozilla.org/es/docs/Web/CSS

Musiño, C. M. (2010). El valor de la información, su administración y alcance en las

organizaciones. Revista mexicana de ciencias de la información. Vol. 1, No.

2, 10-20.

Nguyen . (2013). Contract Lifecycle Management on the sell-side : a case study in

upstream Oil and Gas industry. Lahden ammattikorkeakoulu.

Novalys. (2019). Obtenido de

https://www.powerdesigner.biz/ES/powerdesigner/probar-powerdesigner-

source_adw847a.html?gclid=Cj0KCQjwkIGKBhCxARIsAINMioKuGcysVjHrc

L3Igr03HRlsn2pXMPvmu1VYVlCqwbfD1OwsDWxCLfYaArTlEALw_wcB

NTC 5854. (2011). Accesibilidad a páginas web—Estrategia GEL. Obtenido de

https://estrategia.gobiernoenlinea.gov.co/623/w3-article-8056.html

Pacheco Casadiego, J. M. (2017). Metodología para elaborar el modelo conceptual

de datos. Ibagué, Tolima.: Ediciones Universidad Cooperativa de colombia.

Peñalvo, F. J., & García Holgado, A. (2017/2018). MODELO DE DOMINIO.

Obtenido de

https://repositorio.grial.eu/bitstream/grial/1153/1/8.%20Modelo%20de%20do

minio.pdf

Postman. (2021). Postman. Obtenido de https://www.postman.com/

PrimeNg. (2021). PRIMENG. Obtenido de https://www.primefaces.org/primeng/v9-

lts/#/

60

Smith, S. (12 de 01 de 2021). Architect Modern Web Applications with ASP.NET.

(M. Wenzel, Ed.) Obtenido de Microsoft Docs: https://docs.microsoft.com/en-

us/dotnet/architecture/modern-web-apps-azure/common-web-application-

architectures

Villanova University. (2012). The Benefits of Contract Lifecycle Management/CLM.

Obtenido de

https://web.archive.org/web/20120530040919/http://www.villanovau.com/co

ntract-lifecycle-management-benefits/

WCAG. (2008). Web Content Accessibility Guidelines (WCAG) 2.0. Obtenido de

https://www.w3.org/TR/WCAG20/

plataforma web para la gestiÓn de la informaciÓn de

Documents