DOCUMENTO DE ARQUITECTURA DE SOFTWARE SISTEMA DE …

Contrato No. 001 de 2019 – Arquitectura Empresarial Objeto del Contrato: Diseñar la arquitectura del Sistema de Información del Subsidio Familiar de

Vivienda que comprenda los componentes de oferta y demanda de subsidios de vivienda

DOCUMENTO DE ARQUITECTURA DE SOFTWARE SISTEMA DE LICENCIAS URBANISTICAS - TERRA

Marzo de 2021

BOGOTÁ D.C. - COLOMBIA

ARQUITECTURA DE SOFTWARE SISTEMA DE LICENCIAS URBANISTICAS - TERRA

DOCUMENTO DE ARQUITECTURA DE

SOFTWARE DEL SISTEMA DE LICENCIAS URBANISTICAS-TERRA

Versión 0.1

El presente documento fue diseñado para el Ministerio de Vivienda, Ciudad y Territorio – MinVivienda, por la UT FONVIVIENDA 2019 S.A.S., en virtud de la ejecución del contrato No. 001 de 2019

Página 2 de 86

CONTROL DE CAMBIOS

FECHA VERSIÓN DESCRIPCIÓN DEL CAMBIO RESPONSABLE

24/03/2021 0.1 Versión inicial del documento. UT FONVIVIENDA 2019

08/04/2021 0.2 Atención a comentarios. UT FONVIVIENDA 2019




25/5/2021 1.0 Versión aprobada UT FONVIVIENDA 2019

REFERENCIAS CONTRACTUALES DEL ENTREGABLE:

Según contrato: Documento con la arquitectura de solución TERRA con sus componentes de oferta y demanda que incluye la aplicación del marco de interoperabilidad entre el sistema y las entidades que participan en la política de vivienda: c. Documento de arquitectura de software. f. Modelo de datos. g. Modelo de despliegue. h. Modelo de contexto. k. Modelo de Acuerdos de Niveles de Servicio.

APROBACIÓN

ACCIÓN NOMBRE ROL FIRMA FECHA

Elaboro Cesar Peña Consultoría

Revisó William Palencia Gerente de Proyecto

Interventoría

Aprobó Carlos Gutiérrez

Supervisor FONVIVIENDA para el contrato 01 de 2019

Fiduciaria de Occidente y UT FONVIVIENDA 2019




Versión 0.1


Página 3 de 86

AVISO DE CONFIDENCIALIDAD

La UT FONVIVIENDA 2019 en aras de preservar la Seguridad de la Información del Ministerio de Vivienda, entrega este documento bajo la condición de confidencialidad mutua, donde las partes deben respetar la información provista. Por lo tanto, la información contenida en este documento y en los medios magnéticos entregados es de carácter reservado y sólo puede ser utilizado por el personal que EL Ministerio de Vivienda designe para su revisión, resguardo, manipulación y/o divulgación. Las normas que fundamentan el carácter reservado de la información son los artículos 72 y siguientes de la decisión del acuerdo de Cartagena 344 de 1993, el artículo 238 del Código Penal Colombiano y los artículos 16 y siguientes de la Ley 256 de 1996.




Versión 0.1


Página 4 de 86

TABLA DE CONTENIDO

Pág.

1 PRESENTACIÓN DEL DOCUMENTO ........................................................................ 8

2 INTRODUCCIÓN ........................................................................................................ 10

2.1 Propósito ...................................................................................................................... 10

2.2 Alcance ......................................................................................................................... 10

2.3 Definiciones, Acrónimos y Abreviaturas .................................................................. 11

2.4 Referencias................................................................................................................... 14

2.5 Panorama...................................................................................................................... 15

3 METAS Y RESTRICCIONES DE LA ARQUITECTURA ........................................... 15

3.1 Metas ............................................................................................................................. 16

3.2 Restricciones ............................................................................................................... 17

4 MOTIVADORES ARQUITECTURALES .................................................................... 17

4.1 MOTIVADORES DE NEGOCIO.................................................................................... 17

5 ATRIBUTOS DE CALIDAD ........................................................................................ 20

5.1 ARBOL DE UTILIDAD .................................................................................................. 21

5.1.1 Adecuación Funcional...................................................................................................... 21

5.1.2 Eficiencia De Desempeño................................................................................................ 22

5.1.3 Compatibilidad ................................................................................................................. 23

5.1.4 Usabilidad ........................................................................................................................ 24

5.1.5 Fiabilidad .......................................................................................................................... 25

5.1.6 Seguridad ......................................................................................................................... 26

5.1.7 Mantenibilidad .................................................................................................................. 27

5.1.8 Árbol de Utilidad ............................................................................................................... 28

5.2 ESCENARIOS DE CALIDAD ....................................................................................... 30

5.2.1 Escenarios de Completitud Funcional ............................................................................. 30

5.2.2 Escenarios de Pertinencia Funcional .............................................................................. 31

5.2.3 Escenarios de Capacidad ................................................................................................ 32




Versión 0.1


Página 5 de 86

5.2.4 Escenarios de Comportamiento Temporal ...................................................................... 38

5.2.5 Escenarios de Interoperabilidad ...................................................................................... 39

5.2.6 Escenarios de Protección Contra Errores ....................................................................... 40

5.2.7 Escenarios de Estética de la Interfaz .............................................................................. 41

5.2.8 Escenario de Tolerancia a Fallos .................................................................................... 41

5.2.9 Escenarios de Disponibilidad ........................................................................................... 42

5.2.10 Escenarios de Autenticidad ............................................................................................. 43

5.2.11 Escenarios de Responsabilidad ...................................................................................... 44

5.2.12 Escenarios de Integridad ................................................................................................. 45

5.2.13 Escenarios de Confidencialidad ...................................................................................... 46

5.2.14 Escenarios de Modularidad ............................................................................................. 48

5.3 ACUERDO DE NIVEL DE SERVICIOS ........................................................................ 48

6 VISTAS y MODELOS ARQUITECTÓNICOS ............................................................ 58

6.1 VISTA DE ESCENARIOS DE CASOS DE USO .......................................................... 58

6.2 VISTA LÓGICA O MODELO DE CONTEXTO ............................................................. 60

6.3 VISTA DE PROCESOS................................................................................................. 63

6.4 VISTA DE IMPLEMENTACION O COMPONENTES .................................................. 65

6.4.1 Responsabilidad de los Componentes ............................................................................ 68

6.5 VISTA DE DESPLIEGUE .............................................................................................. 73

6.6 VISTA DE INFRAESTRUCTURA ................................................................................. 75

6.6.1 Clúster de Servidores WEB ............................................................................................. 78

6.6.2 Clúster de Base de Datos ................................................................................................ 79

6.6.3 Clúster de Microservicios, ESB, BPM.............................................................................. 79

6.6.4 Dimensionamiento Base .................................................................................................. 82

7 CONCLUSIONES ....................................................................................................... 83

LISTADO DE TABLAS

Pág. Tabla 1. Definiciones ...................................................................................................................... 14




Versión 0.1


Página 6 de 86

Tabla 2. Referencias documentales .............................................................................................. 15 Tabla 3. Motivadores de Negocio .................................................................................................. 19 Tabla 4. Atributo de calidad Adecuación Funcional. ..................................................................... 22 Tabla 5. Atributo de calidad Eficiencia de Desempeño. ................................................................ 23 Tabla 6. Atributo de calidad Compatibilidad. ................................................................................. 24 Tabla 7. Atributo de calidad Usabilidad. ........................................................................................ 25 Tabla 8. Atributo de calidad Fiabilidad........................................................................................... 26 Tabla 9. Atributo de calidad Seguridad. ........................................................................................ 27 Tabla 10. Atributo de calidad Mantenibilidad................................................................................. 28 Tabla 11. Cumplimiento de decretos ............................................................................................. 31 Tabla 12. Parametrización de flujos de trabajo ............................................................................. 31 Tabla 13. Explotación de la información ........................................................................................ 32 Tabla 14. Solicitudes Concurrentes ............................................................................................... 33 Tabla 15. Carga de Documentos ................................................................................................... 33 Tabla 16. Ejecución de Reglas de Negocio................................................................................... 34 Tabla 17. Tiempos de Respuesta .................................................................................................. 35 Tabla 18. Seguimiento a Solicitudes ............................................................................................. 35 Tabla 19. Capacidad de Almacenamiento ..................................................................................... 36 Tabla 20. Usuarios con Sesión Activa ........................................................................................... 37 Tabla 21. Usuarios Concurrentes en el Sistema ........................................................................... 37 Tabla 22. Calidad de Conectividad ................................................................................................ 38 Tabla 23. Aumento de carga temporal .......................................................................................... 39 Tabla 24. Interoperabilidad del sistema ......................................................................................... 40 Tabla 25. Protección contra errores del usuario ........................................................................... 40 Tabla 26. Estética de la interfaz..................................................................................................... 41 Tabla 27. Tolerancia a fallos .......................................................................................................... 42 Tabla 28. Disponibilidad del sistema ............................................................................................. 43 Tabla 29. Verificación documentos ................................................................................................ 44 Tabla 30. Autenticación de usuarios.............................................................................................. 44 Tabla 31. Trazas de auditoria ........................................................................................................ 45 Tabla 32. Autenticación de usuarios.............................................................................................. 46 Tabla 33. Transmisión de datos de forma segura ......................................................................... 47 Tabla 34. Tratamiento de datos sensibles ..................................................................................... 47 Tabla 35. Modularidad del sistema ................................................................................................ 48 Tabla 36. Dimensionamiento base ................................................................................................ 87




Versión 0.1


Página 7 de 86

LISTADO DE ILUSTRACIONES

Pág.

Ilustración 1. Modelo de vistas “4+1” ............................................................................................... 8 Ilustración 2. Modelo de calidad ISO 25010 .................................................................................. 20 Ilustración 3. Árbol de utilidad. ....................................................................................................... 29 Ilustración 4. Diagrama de casos de uso Licencias Urbanísticas ................................................. 59 Ilustración 5. Vista lógica o contextual........................................................................................... 60 Ilustración 6. Zona de Usuarios ..................................................................................................... 61 Ilustración 7. Integración e Interoperabilidad................................................................................. 62 Ilustración 8. Aplicación web, microservicios ................................................................................ 62 Ilustración 9. Bases de datos ......................................................................................................... 63 Ilustración 10. Vista de Procesos .................................................................................................. 64 Ilustración 11. Vista de Componentes ........................................................................................... 68 Ilustración 12. Componente de Presentación................................................................................ 68 Ilustración 13. Sistema de Gestor de Procesos ............................................................................ 69 Ilustración 14. Componente Bus Empresarial ............................................................................... 70 Ilustración 15. Componente de Microservicios .............................................................................. 71 Ilustración 16. Componente Base de Datos .................................................................................. 72 Ilustración 17. Componentes de BI. ............................................................................................... 73 Ilustración 18. Diagrama de Despliegue ........................................................................................ 74 Ilustración 19. Diagrama diseño de infraestructura. ...................................................................... 75 Ilustración 20. Clúster de Almacenamiento ................................................................................... 77 Ilustración 21. Clúster de Firewall .................................................................................................. 78 Ilustración 22. Clúster de Servidores WEB ................................................................................... 78 Ilustración 23. Clúster de base de datos ....................................................................................... 80 Ilustración 24. Clúster de Microservicios ....................................................................................... 80 Ilustración 25. Clúster ESB ............................................................................................................ 81 Ilustración 26. Clúster BPM ........................................................................................................... 81 Ilustración 27. Clúster de Reportería ............................................................................................. 82 Ilustración 28. Consideraciones de Red ........................................................................................ 84 Ilustración 29. Cifras para Solicitud de licencias. .......................................................................... 83 Ilustración 30. Vista de Datos Licencias Urbanísticas .................................................................. 87




Versión 0.1


Página 8 de 86

1 PRESENTACIÓN DEL DOCUMENTO

El presente documento es el principal artefacto dentro de la solución arquitectónica del sistema. Debe determinar, a través de vistas arquitectónicas, el resultado de diferentes modelamientos encaminados a dar definiciones estrictas y de alto nivel a los aspectos estructurales de la solución arquitectónica. El documento contiene el planteamiento de varias vistas arquitectónicas, antecedidas por apartados que describen una introducción técnica y en general las metas de la arquitectura propuesta. El desarrollo o modelamiento de la arquitectura está dado por el modelo “4+1 Vistas”1.

Ilustración 1. Modelo de vistas “4+1”

Fuente: UT Fonvivienda 2019, 2020

Como aspecto fundamental y primario para gran parte de las definiciones y modelamiento, se

describe y trata el tema de atributos de calidad y sus respectivos escenarios.

Adicionalmente a las vistas clásicas en un SAD, se tiene una vista de datos, que pretende, en un

alto nivel, al igual que las otras, representar la solución a nivel de persistencia, mostrando

inicialmente las entidades persistentes de forma individual o agrupada.

1 Anexo 8-Propuesta metodológica.doc. Literal 5.4 ARQUIECTURA SOUCIÓN, “4+1 Vistas”.




Versión 0.1


Página 9 de 86

La vista lógica describe abstracciones clave, la distribución lógica de los componentes

principales de la solución. Los interesados en esta vista son principalmente los diseñadores y

desarrolladores. En general cualquier stakeholder que quiera comprender cómo las unidades

lógicas identificadas van a interactuar e identificar su ubicación.

La vista de procesos permitirá observar las definiciones del tratamiento de las peticiones a nivel

de hilos o de procesos de máquina. Los interesados principales son de infraestructura, pues esta

perspectiva es un complemento importante para la vista de despliegue.

La vista de implementación generalmente es la más extendida y utilizada para describir la

solución a una primera vez. También se utiliza para generar contexto arquitectónico y presentar

el modelo del diseño. Los interesados principalmente son los desarrolladores y arquitectos,

extendiéndose a cualquier stakeholder del dominio del sistema.

La vista de despliegue está dada para la perspectiva de infraestructura, describiendo nodos y

elementos físicos de alto nivel. Los interesados son de infraestructura y pretenden definir, a partir

de esta vista, cómo el sistema será ubicado en la arquitectura de red y lineamientos del área de

TI. En general cualquier interesado que desee conocer las decisiones de nodos físicos y sus

relaciones.

La vista de escenarios complementa a las otras vistas, está comprendida por los requerimientos de funcionalidad del sistema, identificando los escenarios principales y significativos para la arquitectura. Esta vista está apoyada por los entregables del análisis de los requerimientos. Los interesados principales son los analistas de requerimientos y en general los dueños de la funcionalidad o quien requiera referirse a las necesidades de la implementación funcional.




Versión 0.1


Página 10 de 86

2 INTRODUCCIÓN

La solución arquitectónica TERRA está enmarcada por la necesidad de un mecanismo de apoyo para las funciones de las curadurías en lo que respecta al proceso de recepción, estudio y expedición de licencias urbanísticas en el país2.

2.1 Propósito

La intención del presente documento es capturar las definiciones estructurales y decisiones arquitectónicas, que en conjunto dan como resultado el compendio de la solución técnica para el sistema de información de licencias urbanísticas TERRA. A través de la descripción de las estructuras arquitectónicas y la justificación de estas, el lector debe lograr una visión general del modelo del diseño de la arquitectura, comprendiendo los beneficios de la solución y describiendo como se debe cumplir con las necesidades de TERRA.

2.2 Alcance

El alcance del documento está definido por el tratamiento y solución de los requerimientos funcionales, no funcionales y atributos de calidad. La solución es generada utilizando un nivel de abstracción de estructuras arquitectónicas de forma clásica y visión general. Este nivel de abstracción es el que marca y/o conduce las definiciones base que se describen a través de vistas técnicas. Como parte fundamental del modelamiento realizado, las definiciones del documento deberán constituir los lineamientos para la construcción del sistema de información TERRA y ser utilizado por roles como el líder de desarrollo, líderes técnicos, desarrolladores, líder de pruebas y todo aquel que esté involucrado en el desarrollo o construcción del sistema. Las perspectivas se describirán a través de uno o varios diagramas, exponiendo el resultado de la toma de decisión y la asignación de responsabilidades a los artefactos de diseño o componentes resultado. Dentro del modelamiento de la solución, se delimita el alcance por el análisis funcional y donde toma importancia la creación de estructura del más alto nivel. La unión de todas las perspectivas constituye la solución final, complementándose entre ellas.

2 Modelo de análisis. Literal 5.1.4. Requerimientos Licencias Urbanísticas – Modelo de Análisis.docx – UT FONVIVIENDA 2019.




Versión 0.1


Página 11 de 86

2.3 Definiciones, Acrónimos y Abreviaturas

TÉRMINO DESCRIPCIÓN

Modelo de vistas 4+1

Es un modelo que genera una perspectiva o visión de un conjunto de elementos del proyecto y sus relaciones. En conjunto la relación de vistas de arquitectura representa los aspectos de diseño y da como resultado la arquitectura de solución3.

ISO 25010 Modelo ISO/IEC de calidad donde se determinan las características de calidad para tener en cuenta en productos de software4.

Arquitectura de referencia

Es una descripción genérica de los componentes de una aplicación y las relaciones entre ellos, la cual se convierte en una plantilla de solución que provee un conjunto de patrones de diseño, marcos de trabajo y vocabulario común (Ministerio de Tecnologías de la Información y las Comunicaciones, 2020).

Abstracción

La abstracción describe las características esenciales de una entidad y a la entidad como un grupo de características aisladas dentro de un contexto de dominio significativo para el negocio. Los niveles de abstracción permiten delimitar el modelamiento de las diferentes disciplinas de una metodología de desarrollo de software.

ATAM

Architecture Tradeoff Analysis Method - Método de Análisis Relación de Arquitectura: es un método de evaluación de arquitecturas de software que se enfoca en los atributos de calidad. La metodología pretende disminuir los riesgos desde etapas tempranas de la construcción de software5.

API

Del ingles: Application Programing Interface. Es un conjunto de definiciones y protocolos que se utilizan para desarrollar e integrar el software de las aplicaciones, permitiendo la comunicación entre 2 aplicaciones siguiendo un conjunto de reglas.

API REST Una API REST es una interfaz de comunicación basada en el protocolo HTTP que permite a los sistemas de información consultar, crear, editar y eliminar recursos a través de URLs.

FTP El Protocolo de transferencia de archivos es un protocolo de red para la transferencia de archivos entre sistemas conectados a una red TCP, basado en la arquitectura cliente-servidor.

FTPS

FTPS (comúnmente referido como FTP/SSL) es un nombre usado para abarcar un número de formas en las cuales el protocolo FTP puede realizar transferencias de ficheros seguras. El uso más común de FTP y SSL es: AUTH TLS o FTPS Explícito, nombrado por el comando emitido para indicar que la seguridad TLS es obligatoria.

REST La transferencia de estado representacional (en inglés representational state transfer) o REST es un estilo de arquitectura de software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año

3 Modelo de vistas 4+1. https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf. 4 ISO/IEC 25010. https://iso25000.com/index.php/normas-iso-25000/iso-25010 5 ATAM - https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513908.




Versión 0.1


Página 12 de 86


2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

Servicio de intercambio de

información

Forma en la que dos o más entidades coordinan su actuar desde el dominio político-legal, sociocultural, organizacional, semántico y técnico para garantizar que el intercambio de información entre ellas se realiza de forma legal, correcta y eficiente. (MINTIC, Portal Institucional, 2020)

Servicio WEB Un servicio web es un programa diseñado para intercambiar información entre aplicaciones, sobre una red.

HTTP

HTTP es un protocolo de transferencia de hipertexto que se usa en la Web. HTTP es una sigla que significa HyperText Transfer Protocol, o Protocolo de Transferencia de Hipertexto. Este protocolo fue desarrollado por las instituciones internacionales W3C y IETF y se usa en todo tipo de transacciones a través de Internet.

HTTPS

El Protocolo seguro de transferencia de hipertexto (en inglés, Hypertext Transfer Protocol Secure o HTTPS) es un protocolo de aplicación basado en el protocolo HTTP, destinado a la transferencia segura de datos de hipertexto, es decir, es la versión segura de HTTP.

Integración Extraer Datos de diferentes fuentes y/o procesos con el fin de convertirlos en información valiosa y fiable

Interfaz Es el artefacto que describe los servicios de intercambio de información en cuanto a sus entradas, salidas, participantes, responsabilidades y en resumen el ejercicio colaborativo que representa el servicio.

BRMs Es un subsistema de administración de reglas de negocio para poder generar desacoplamiento entre las reglas de negocio, la lógica y su codificación.

ESB Enterprise Service Bus o Bus

de Servicios Empresariales

Un ESB, o bus de servicio empresarial, es un patrón mediante el cual un componente de software centralizado realiza integraciones entre los sistemas de información y hace que esas integraciones estén disponibles como interfaces de servicio para su reutilización por parte de otros sistemas de información. (IBM, 2020).

SOA

La Arquitectura Orientada a Servicios de cliente, conocida también como SOA por sus siglas en inglés, es un concepto de arquitectura de software que define la utilización de servicios (programas o rutinas que realizan una función específica) para dar soporte a los requisitos del negocio.

X-ROAD

Es una capa de intercambio de datos distribuidos que proporciona una forma estandarizada y segura de producir y consumir servicios. Adicionalmente, garantiza la confidencialidad, integridad e interoperabilidad entre las partes de intercambio de datos.




Versión 0.1


Página 13 de 86


Interoperabilidad

• La interoperabilidad es la acción, operación y colaboración de varias entidades para intercambiar información que permita brindar servicios en línea a los ciudadanos, empresas y otras entidades mediante una sola venta de atención o un solo punto de contacto (MinTIC, 2020).

• Es “la capacidad de las organizaciones para intercambiar información y conocimiento en el marco de sus procesos de negocio para interactuar hacia objetivos mutuamente beneficiosos, con el propósito de facilitar la entrega de servicios digitales a ciudadanos, empresas y a otras entidades, mediante el intercambio de datos entre sus sistemas TIC”. Esta es la definición de Interoperabilidad acogida para el Gobierno Digital (MinTIC, 2020).

La Plataforma De Interoperabilidad

PDI

Son el conjunto de herramientas necesarias que permite que los sistemas de información del Estado se comuniquen entre sí mediante interfaces estándar de comunicación entre procesos y sistemas de información. (Ministerio de Tecnologías de la Información y las Comunicaciones, 2020).

Marco de interoperabilidad6

Es la estructura de trabajo común donde se alinean los conceptos y criterios que guían el intercambio de información. Define el conjunto de principios, recomendaciones y directrices que orientan los esfuerzos políticos, legales, organizacionales, semánticos y técnicos de las entidades, con el fin de facilitar el intercambio seguro y eficiente de información. (Ministerio de Tecnologías de la Información y las Comunicaciones, 2020).

Marco de Transformación

Digital MINTIC7

El Artículo 147 de la Ley 1955 del 2019 (Plan Nacional de Desarrollo) establece que las entidades del orden nacional deberán incluir en su plan de acción el componente de transformación digital, siguiendo los estándares que para tal efecto defina el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC). Así mismo, el CONPES 3975, que define la Política Nacional de Transformación Digital e Inteligencia Artificial, estableció una acción a cargo de la Dirección de Gobierno Digital para desarrollar los lineamientos para que las entidades públicas del orden nacional elaboren sus planes de transformación digital con el fin de que puedan enfocar sus esfuerzos en este tema. Teniendo presente el marco normativo y de política pública expuesto, MinTIC creo el Marco de Transformación Digital. (Ministerio de Tecnologías de la Información y las Comunicaciones, 2020).

Modelo de arquitectura

empresarial (MAE)

Instrumento para implementar el habilitador de Arquitectura de la Política de Gobierno Digital del Estado Colombiano, que establece el uso y aprovechamiento de las tecnologías de la información y las comunicaciones. (MinTIC 2020)8.

6 Marco de interoperabilidad MinTIC http://lenguaje.mintic.gov.co/marco-de-interoperabilidad 7 Marco de transformación digital MinTIC https://www.mintic.gov.co/portal/inicio/Sala-de-Prensa/Noticias/149186:MinTIC-publica-el-Marco-de-Transformacion-Digital-para-mejorar-la-relacion-Estado-ciudadano 8 Modelo de arquitectura empresarial MAE https://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8118.html

http://lenguaje.mintic.gov.co/marco-de-interoperabilidad

https://www.mintic.gov.co/portal/inicio/Sala-de-Prensa/Noticias/149186:MinTIC-publica-el-Marco-de-Transformacion-Digital-para-mejorar-la-relacion-Estado-ciudadano

https://www.mintic.gov.co/portal/inicio/Sala-de-Prensa/Noticias/149186:MinTIC-publica-el-Marco-de-Transformacion-Digital-para-mejorar-la-relacion-Estado-ciudadano

https://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8118.html




Versión 0.1


Página 14 de 86


Servicios de Información

Es la integración de actividades que busca satisfacer las necesidades de información de uno o más grupos de interés. Los servicios de información son las diferentes formas de brindar acceso a la información. Un servicio de información se describe a través de un contrato funcional (qué recibe como entrada y qué produce como salida) y un conjunto de acuerdos de servicio que se deben cumplir. Por ejemplo, la Unidad de la Atención y Reparación Integral a las Victimas provee un servicio web de intercambio de información sobre víctimas del conflicto armado en Colombia, entre otros.

Trámite

Conjunto de requisitos, pasos o acciones, regulados por el Estado dentro de un procedimiento administrativo misional que deben efectuar los ciudadanos ante una institución de la administración pública, o particular que ejerce funciones administrativas, para hacer efectivo un derecho o cumplir con una obligación prevista o autorizada por la ley, cuyo resultado es un producto o servicio (MinTIC, 2020).

Metadato Son datos sobre los datos. Los metadatos articulan un contexto para determinados objetos de interés (recursos), en forma de descripción de recursos.

Tabla 1. Definiciones Fuente: UT Fonvivienda 2019, 2021

2.4 Referencias

Se utilizan como referencia los siguientes documentos:

DOCUMENTO REFERENCIA

Glosario de términos SILCU-GLOS_Glosario.xlsx

Catálogo de actores MVCT – Modelo de Análisis.docx

Modelo de análisis Arquitectura Referencia.docx

Arquitectura de referencia SAW FONVIVIENDA.docx

SAW Documento ADD.docx

https://minviviendagovco-my.sharepoint.com/:w:/g/personal/consultoria_sisfv_minvivienda_gov_co/Eex4Fm3u2-tIpPPSF4m4PScBHogGN2GQoLo0cYILMsVCtA?e=mZCmHp

https://minviviendagovco-my.sharepoint.com/:w:/g/personal/consultoria_sisfv_minvivienda_gov_co/Edfl3MBHBUNHjYcKnX3U2PYBdX2IgnC_PcMOYnXdQqBYxw?e=khlizx

https://minviviendagovco-my.sharepoint.com/:w:/g/personal/consultoria_sisfv_minvivienda_gov_co/EQJpkTDxoGhPlpo_4knXNz0BuWmcak0kO0ZoftxEZZee0g?e=UITUMH

https://minviviendagovco-my.sharepoint.com/:w:/g/personal/consultoria_sisfv_minvivienda_gov_co/EYUQt6oi2-hOhGdp4g6PC-gBH5wD3BePUsvvK1W7a-mfOQ?e=grjaIN




Versión 0.1


Página 15 de 86

DOCUMENTO REFERENCIA

ADD MVCT – Modelo de Análisis.docx

DECRETO 1077 de 2015 Decreto 1077 del 26 de mayo del 2015.pdf

Tabla 2. Referencias documentales


2.5 Panorama

Este documento hace referencia al modelo de análisis para utilizar las definiciones y modelamiento realizado a los requerimientos funcionales. Se realiza una introducción donde se especifican las vistas a utilizar y luego se nombran las metas y restricciones, tomando como base lo identificado en la arquitectura empresarial y reuniones con interesados. A continuación, se describen los motivadores arquitecturales y se hace el manejo de los atributos de calidad con sus escenarios, que guiarán las decisiones durante la descripción de la solución arquitectónica. Las perspectivas de arquitectura serán diagramadas a través de las siguientes vistas:

• Vista de escenarios o casos de uso.

• Vista lógica o modelo de contexto.

• Vista de procesos.

• Vista de implementación y componentes.

• Vista de despliegue.

• Vista de conectividad.

• Vista de datos. Se finaliza con un apartado de conclusiones sobre el modelamiento de la solución, sus características y visión para su implementación.

3 METAS Y RESTRICCIONES DE LA ARQUITECTURA

A continuación, se muestran las metas y restricciones identificadas para el Sistema de Información de Licencias Urbanísticas - TERRA. Este apartado permite resumir de forma técnica las condiciones sobre las cuales se realiza el modelamiento de la solución y se ha de tener en cuenta las directrices de las definiciones de la Arquitectura Empresarial.

https://minviviendagovco-my.sharepoint.com/:w:/g/personal/consultoria_sisfv_minvivienda_gov_co/Eex4Fm3u2-tIpPPSF4m4PScBHogGN2GQoLo0cYILMsVCtA?e=mZCmHp




Versión 0.1


Página 16 de 86

3.1 Metas

• Diseñar la arquitectura para el Sistema de Información de Licencias Urbanísticas y Construcción (TERRA) que permita cumplir con la construcción de una plataforma con información territorial estandarizada y actualizada que apoye los procesos de planeación y ordenamiento del territorio de los municipios del país y la creación de una ventanilla única transaccional para la realización de trámites para la obtención de licencias urbanísticas en todas sus modalidades, con información certificada, que permita reducir tiempos y costos asociados a los tramites del sector construcción en el licenciamiento9.

• Proveer un sistema de información acorde con las necesidades de MVCT para soportar los requerimientos funcionales modelados a través del análisis y especificación de casos de uso para las licencias urbanísticas10.

• Mantener los datos e información del sistema centralizada, evitando duplicación de datos o entidades entre repositorios o subsistemas. Se necesita tener una sola fuente lógica de información para ser consultada y explotada por los diferentes actores11.

• Aumentar la confiabilidad, agilidad y eficiencia del uso de la información, generando mecanismos para el análisis y consolidación de los datos y evitando la utilización de archivos locales para su manejo12.

• Asignar las debidas responsabilidades a los artefactos de software que apoyan el modelo de TERRA, para establecer un domino de información para el gobierno de los datos de lo relacionado a licencias urbanísticas.

• Tener la capacidad de generar trazas de auditoría acordes con las necesidades del negocio, como también la posibilidad de hacer seguimiento sobre las acciones y eventos funcionales de los procesos del negocio.

• Responder ante un aumento repentino de la demanda, principalmente hacia los trámites y servicios de cara a usuarios finales.

• Asegurar que TERRA pueda desplegarse en una plataforma de alta disponibilidad y que pueda tener un crecimiento horizontal ante la alta demanda.

• Identificar las necesidades base de los recursos tecnológicos para soportar la ejecución, procesamiento, desempeño y eficiencia de TERRA.

• Permitir el modelamiento y manejo de procesos de negocio a través de herramientas tecnológicas integradas en la solución de TERRA13.

• Generar la capacidad de integración con aplicaciones internas o con entidades externas utilizando los estándares y lineamientos del MinTIC.

• Contener la estrategia de integración e intercambio de información para TERRA, entregando servicios digitales a los ciudadanos, constructoras y curadurías.

• Estandarizar el manejo de la documentación de TERRA, a través de la exposición de servicios únicos y la utilización de un componente tecnológico que permita el correcto

9 Alcance funcional - terminos_de_referencia_arquitectura_empresarial.pdf 10 Modelo de análisis. MVCT – Modelo de Análisis.docx – UT FONVIVIENDA 2019. 11 Arquitectura de datos – Literal 4.2, SAW FONVIVIENDA.docx 12 Arquitectura de datos – Literal 4.2, SAW FONVIVIENDA.docx 13 Arquitectura de negocio – Literal 4.1, SAW FONVIVIENDA.docx




Versión 0.1


Página 17 de 86

guardado y custodia documental durante el tiempo que la norma establezca14.

• Aportar en la transformación digital del estado colombiano, a través de la generación de servicios de confianza y calidad, decisiones basadas en datos y territorios y ciudades inteligentes a través de las TIC, cumpliendo con las políticas de gobierno digital.

3.2 Restricciones

• La arquitectura de referencia establece un marco para el presente diseño de arquitectura. Describe los patrones arquitectónicos, sus componentes y relaciones. Lo anterior constituye un cúmulo de características dispuestas al presente ejercicio15.

• Capacidades no soportadas por Ministerio y que deban ser resueltas para la viabilidad del proyecto. Estas capacidades se pueden presentar finalmente como brechas identificadas en la Arquitectura Empresarial.

• El establecimiento de una metodología de desarrollo a nivel del Ministerio puede influir de forma positiva ante las percepciones y el cumplimiento de las expectativas en cuanto a las arquitecturas de software. En este momento no se cuenta con una metodología de desarrollo propia.

• Las capacidades de recursos, infraestructura está delimitado por lo encontrado y planteado en la arquitectura empresarial. El diseño de la arquitectura de TERRA genera bases en cuanto a necesidades y lineamientos, pero no se limita en este sentido16.

• A nivel de Arquitectura Empresarial en su dominio de Arquitectura de Sistemas de Información, se presentan los componentes físicos de aplicación propuestos con intención que a futuro se defina sobre estos conceptos17.

• El Decreto 1077 del 26 de mayo del 2015 se debe tener muy presente en todo momento puesto que contiene la forma en que se hace el proceso de licenciamiento urbanístico y no se puede cambiar su esencia.

4 MOTIVADORES ARQUITECTURALES

4.1 MOTIVADORES DE NEGOCIO

Los motivadores de negocio que se presentan, son beneficios concretos que TERRA pretende generar a los procesos y operación en la recepción, el análisis y la generación del acto administrativo para las solicitudes de licencia urbanística. Estos motivadores entran en relación directamente con la funcionalidad identificada o vista de casos de uso y también pueden tener relación con los atributos de calidad. Los motivadores de negocio, a nivel de la arquitectura de aplicación, tienen como intención un futuro cumplimiento para cuando la solución este en producción y basados en ese resultado se

14 Decreto 1077 del 26 de Mayo del 2015. 15 Arquitectura de referencia MCVT – Arquitectura referencia.docx 16 Arquitectura de tecnología – Catálogo de Componentes físicos de tecnología – Documento ADD.docx 17 Arquitectura de Sistemas de Información – SISFV – Documento ADD.docx




Versión 0.1


Página 18 de 86

puede trazar un Roadmap o actividades de mantenimiento y estabilización del sistema cuando se encuentre en fase de monitoreo y mantenimiento de software. Se presenta un resumen de los principales motivadores de negocio, descritos en el documento SAW en Arquitectura Empresarial. De igual forma el desarrollo del dominio de negocio18, presenta el contexto completo de los motivadores y es complemento estratégico y funcional19.

MOTIVADOR DESCRIPCIÓN

Objetivos de Desarrollo sostenible

Objetivos mundiales para el desarrollo sostenible, adoptados en el 2015 por los estados miembros de la Organización de las Naciones Unidas. ODS 11 Ciudades y comunidades sostenibles: consideran necesario mejorar la seguridad y sostenibilidad de las ciudades, cuya realización implica la garantía del acceso a viviendas seguras y asequibles, el mejoramiento de los asentamientos marginales, inversiones en transporte público, la creación de áreas públicas verdes y el mejoramiento de la planificación y la gestión urbana de manera que sea participativa e inclusiva

Plan Nacional de Desarrollo 2018 – 2022

El Plan Nacional de Desarrollo denominado “Pacto por Colombia, Pacto por la Equidad” definido para el periodo 2018 – 2022; es la hoja de ruta que establece los objetivos de gobierno, fijando las estrategias, los objetivos y las metas del cuatrienio. Se plantea la equidad es un pacto para ampliar y equilibrar las oportunidades de desarrollo de todas las familias colombianas. El Plan Nacional de Desarrollo 2018 – 2022 “Pacto por Colombia, Pacto por la equidad” estipula en su capítulo VII el Pacto por la transformación digital en Colombia: gobierno, empresas y hogares conectados con la era del conocimiento, el cual traza el camino para que las tecnologías de la información y las comunicaciones habiliten la agregación de valor transversal en la economía, generen nuevos negocios y sean la puerta de entrada a la industria 4.0.

Plan sectorial – Planeación en cascada

Teniendo en cuenta el concepto de planeación en cascada, establecido en la circular No. 001 de 2018, el cual tiene como propósito que, al final del Gobierno, los cumplimientos de las metas estratégicas institucionales aporten al cumplimiento de las metas sectoriales, y el conjunto de estas permita el cumplimiento de las metas de Gobierno establecidas en el PND 2018-2022 Pacto por Colombia, pacto por la equidad, el MVCT realizó un ejercicio de planeación estratégica atendiendo el concepto de alineación nacional e institucional

Plan Estratégico Institucional 2019 – 2022

En este plan estratégico se definen 4 dimensiones, tres (3) enfocadas en la construcción de un mejor hábitat para los colombianos, como son: a) desarrollo urbano y territorial, b) vivienda y c) agua potable y saneamiento básico; y una dimensión institucional de orden transversal, orientada al fortalecimiento de la gestión del MVCT.

18 Arquitectura de Negocio – SISFV – Documento ADD.docx 19 Motivadores de Negocio – SAW FONVIVIENDA.docx




Versión 0.1


Página 19 de 86

MOTIVADOR DESCRIPCIÓN

Se describe la dimensión de vivienda, esta dimensión contempla los indicadores formulados en el marco de las políticas y programas de vivienda definidas por el Gobierno Nacional, que permiten facilitar el acceso de los hogares de menores ingresos a los subsidios y créditos de vivienda en el país.

Plan Estratégico de Tecnologías de la

Información (PETI) 2018-2022

El PETI se encuentra articulado con el PND, el Plan Estratégico del Sector y el Plan Estratégico Institucional del MVCT conforme a lo previsto en el artículo 29 de la Ley 152 de 1994, con los Objetivos de Desarrollo Sostenible (ODS) 2030 y con el Modelo Integrado de Planeación y Gestión (MIPG Versión 2), que da los parámetros para la planeación y gestión pública conforme a la aplicación del Decreto Único Reglamentario del Sector de Función Pública 1083 de 2015 y del Decreto 612 de 2018 (Por el cual se fijan directrices para la integración de los planes institucionales y estratégicos al Plan de Acción por parte de las entidades del Estado), “en lo relacionado con la definición de los lineamientos para el fortalecimiento institucional en materia de tecnologías de la información y las comunicaciones”.

Tabla 3. Motivadores de Negocio





Versión 0.1


Página 20 de 86

5 ATRIBUTOS DE CALIDAD

En esta sección se hace referencia a los requerimientos no funcionales descritos en el documento análisis MVCT - Modelo de Análisis.docx20, enlazándolos con la definición de los atributos de calidad. La definición y estructura de los atributos de calidad a utilizar es la planteada por el estándar ISO/IEC 2501021.

Ilustración 2. Modelo de calidad ISO 25010

Fuente: https://iso25000.com/index.php/normas-iso-25000/iso-25010 Para TERRA, se definen los siguientes atributos de calidad a tener en cuenta:

▪ Adecuación Funcional: Representa la capacidad del producto de software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas, cuando el producto se usa en las condiciones especificadas.

▪ Eficiencia de desempeño: Este atributo representa el desempeño relativo a la cantidad de recursos utilizados bajo determinadas condiciones.

▪ Compatibilidad: Capacidad de dos o más sistemas o componentes para intercambiar

información y/o llevar a cabo sus funciones requeridas cuando comparten el mismo entorno hardware o software.

▪ Usabilidad: Capacidad del producto software para ser entendido, aprendido, usado y

resultar atractivo para el usuario, cuando se usa bajo determinadas condiciones.

▪ Fiabilidad: Capacidad de un sistema o componente para desempeñar las funciones

20 5.2 REQUERIMIENTOS NO FUNCIONALES – Documento MVCT – Modelo de Análisis. UTFONVIVIENDA 2019. 21 https://iso25000.com/index.php/normas-iso-25000/iso-25010




Versión 0.1


Página 21 de 86

especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados.

▪ Seguridad: Capacidad de protección de la información y los datos de manera que personas o sistemas no autorizados no puedan leerlos o modificarlos.

▪ Mantenibilidad: Este atributo representa la capacidad del producto software para ser

modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas.

5.1 ARBOL DE UTILIDAD

El Árbol de utilidad describe de forma gráfica, una estructura de los atributos de calidad y como estos se aplican para el desarrollo de los escenarios de calidad. Gráficamente se puede observar cuales atributos son las más requeridos para la solución. A través del árbol de utilidad se muestra mayor detalle sobre la definición de los atributos de calidad, en sus sub-características y la relación con los requerimientos no funcionales. Se muestra el modelamiento realizado para determinar cómo se empieza a plantear la solución de los requerimientos no funcionales, estandarizándolos con las definiciones de los atributos de calidad y dando una prioridad inicial a estos. Por cada uno de los atributos de calidad, se relacionan uno o varios requerimientos no funcionales y su descripción modelada según corresponda con la tipificación del atributo. Para cada una de las sub-características, se hace explicita su definición según el estándar de la ISO, su utilidad y/o consideración dentro del contexto de TERRA. A continuación, se describen los atributos de calidad con sus sub-características y la relación con los requerimientos no funcionales. La descripción de los requerimientos no funcionales se da por su aparición dentro de la disciplina de requerimientos y la intención es describirlos como fueron identificados desde los casos de uso, entrevistas con los usuarios etc., para ser fieles con la necesidad y luego darles desarrollo técnico dentro de los escenarios.

5.1.1 Adecuación Funcional

En el tratamiento de la Adecuación Funcional, se utilizan 2 sub-características. Completitud Funcional: Grado en el cual el conjunto de funcionalidades cubre todas las tareas y los objetivos del usuario especificados. Aquí se suma otro de los objetivos del proyecto en cuanto a la completitud de los requerimientos, pero en específico, con la concordancia de los estipulados por las condiciones de la ley por la cual se rigen los procesos funcionales.




Versión 0.1


Página 22 de 86

Pertinencia Funcional: Capacidad del producto software para proporcionar un conjunto apropiado de funciones para tareas y objetivos de usuario especificados. En esta sub-característica se ubican exigencias específicas como explotación de la información, generación de alertas y el manejo de flujos de trabajo.

Atributo de Calidad Adecuación Funcional

Característica ID-RNF Descripción Priorida

d

Completitud Funcional

NFR-13

El sistema debe apoyar el cumplimiento de la normatividad vigente procurando utilizar una estrategia de parametrización que permita ajustarse a los cambios de la política de vivienda.

Alta

Pertinencia Funcional

NFR-14

El sistema debe generar alertas o notificaciones en las diferentes etapas de los procesos que así lo requieran, con mensajes claros y precisos para el entendimiento del usuario.

Media

Tabla 4. Atributo de calidad Adecuación Funcional.


5.1.2 Eficiencia De Desempeño

La eficiencia de desempeño para el caso de nuestro modelamiento y análisis está dada por 2 sub-características: Capacidad: Grado en que los límites máximos de un parámetro de un producto o sistema de software cumplen con los requisitos. Dada esta sub-característica, es la más utilizada dentro de la definición del futuro comportamiento requerido del sistema. Para TERRA se destacan cifras o volumetrías con respecto a los usuarios concurrentes o activos, tiempos de respuesta y capacidades como ejecución de validaciones y persistencia. Comportamiento temporal: Los tiempos de respuesta y procesamiento y las ratios de throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas en relación con un banco de pruebas (benchmark) establecido. Para esta sub-característica se tiene en cuenta el desempeño del sistema durante la variación de las condiciones de comunicación o calidad de comunicación por el internet y el aumento de carga en determinas funcionalidades o condiciones de utilización.




Versión 0.1


Página 23 de 86

La siguiente tabla describe para la Eficiencia de Desempeño sus sub-características y los requerimientos no funcionales relacionados.

Atributo de Calidad Eficiencia de Desempeño


d

Capacidad

NFR-1

El sistema debe permitir la carga de hasta 250 MB de documentación por usuario. El sistema debe estar en la capacidad de recibir alrededor de 185 solicitudes por día. Soportar picos de hasta 5000 solicitudes en un día

Alta

NFR-9

El sistema debe tener la capacidad de seguir funcionando correctamente cuando aumente el pico de solicitudes y/o transacciones (5000).

Alta

NFR-17

El sistema debe contar con un análisis de capacidad (infraestructura tecnológica)

Media

NFR-18

El sistema debe soportar para el proceso de licencias urbanísticas el ingreso de por lo menos 1.250 usuarios diarios.

Alta

NFR-20 El sistema debe soportar para el subsidio familiar de vivienda el ingreso y utilización de sus funcionalidades por los menos 1000 usuarios concurrentes.

Alta

Comportamiento temporal

NFR-4

Dado que el sistema será utilizado en todo el territorio colombiano y que la conectividad puede tener variaciones en su calidad, el sistema deberá tener esto en cuenta para su correcto funcionamiento.

Media

NFR-6

El sistema debe responder en tiempos no mayores de 5 segundos por petición para transacciones como consultas simples o registro de información básica desde la interfaz web bajo un tráfico esperado o condiciones normales

Media

Tabla 5. Atributo de calidad Eficiencia de Desempeño.


5.1.3 Compatibilidad

De la característica de Compatibilidad, para TERRA se enfatizará en la siguiente sub-característica.




Versión 0.1


Página 24 de 86

Interoperabilidad: Capacidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada. Como parte de los objetivos principales del proyecto, el concepto de interoperabilidad utilizado en las definiciones de la arquitectura empresarial y al nivel de abstracción de la arquitectura presente, se convierte en la necesidad de integración estandarizada. Esta interoperabilidad cobra importancia según el negocio, con entidades externas y entorno a esta definición se realiza la estandarización a través del marco de referencia de integración e intercambio de información. La siguiente tabla describe para la Compatibilidad sus sub-características y los requerimientos no funcionales relacionados.

Atributo de Calidad Compatibilidad


d

Interoperabilidad

NFR-14 El sistema debe tener estructura por módulos independientes para que sus funcionalidades e interoperabilidad puedan ser utilizada a conveniencia.

Alta

Tabla 6. Atributo de calidad Compatibilidad.


5.1.4 Usabilidad

Para la Usabilidad se utilizan dos sub-características. Protección contra errores de usuario: Capacidad del sistema para proteger a los usuarios de hacer errores. Todos los datos que se ingresen al sistema por parte del usuario y donde se obtenga como resultado un error, deberá ser un mensaje formateado y controlado. Estética de la interfaz de usuario: Capacidad de la interfaz de usuario de agradar y satisfacer la interacción con el usuario. Se necesita que la interfaz sea amigable y responda a una estandarización del diseño. La siguiente tabla describe para la Usabilidad sus sub-características y los requerimientos no funcionales relacionados.




Versión 0.1


Página 25 de 86

Atributo de Calidad Usabilidad


d

Protección contra errores de usuario

NFR-7

El sistema debe hacer manejo de excepciones, permitiendo que el usuario pueda continuar con su uso y se generen los mensajes en pantalla adecuados, dando un tratamiento en donde el usuario pueda continuar con otras funcionalidades y de igual forma, debe existir un log de aplicaciones, donde se registren errores y eventos.

Media

NFR-11

El sistema debe responder ante datos erróneos ingresados por el usuario, validando los tipos de datos de entrada y utilizando datos predefinidos para que el usuario seleccione.

Media

Estética de la interfaz de usuario

NFR-16 El sistema debe cumplir con la normatividad y políticas vigentes, definidas por MINTIC.

Media

NFR-19

El SISFV debe poseer una interfaz de usuarios intuitiva y de fácil compresión al usuario final, con acceso a ayuda en línea (Norma NTC 5854). Se desarrollarán pantallas gráficas de acuerdo con la imagen corporativa y los estándares para el desarrollo del MVCT. Teniendo en cuenta una vista con la información pública y otra con la información interna o por rol de usuario.

Tabla 7. Atributo de calidad Usabilidad.


5.1.5 Fiabilidad

En lo referente en la Fiabilidad, para el sistema se identifican las siguientes sub-características. Tolerancia a Fallos: Capacidad del sistema o componente para operar según lo previsto en presencia de fallos hardware o software. Si se da un fallo en el sistema, este debe tener la capacidad de seguir funcionando en las funcionalidades determinadas, dadas múltiples solicitudes por día. Disponibilidad: Capacidad del sistema o componente de estar operativo y accesible para su uso cuando se requiere. El requerimiento no funcional relacionado a esta sub-característica, está plasmado según su descubrimiento. Es de aclarar que, en el escenario de atributo correspondiente, se sugiere una disponibilidad diferente dado a su viabilidad y por consiguiente posibles costos asociados. De




Versión 0.1


Página 26 de 86

igual forma en la vista de despliegue, se presenta una estrategia para el tratamiento de alta disponibilidad. La siguiente tabla describe para la Fiabilidad sus sub-características y los requerimientos no funcionales relacionados.

Atributo de Calidad Fiabilidad


d

Tolerancia a Fallos

NFR-3

Independencia entre servicios o componentes del sistema ante caídas o fallos. Si hay un fallo por ejemplo en el cargue de documentos, se puedan seguir utilizando las funcionalidades de solicitud o reportes.

Alta

Disponibilidad NFR-10 El sistema se debe diseñar y desarrollar para responder a una disponibilidad mínima mensual del 99.5%

Media

Tabla 8. Atributo de calidad Fiabilidad.


5.1.6 Seguridad

A esta característica se le dará mayor énfasis para el modelamiento de la solución, de manera que se utilizaran 4 de sus sub-características. Autenticidad: Capacidad de demostrar la identidad de un sujeto o un recurso. Es importante para TERRA validar la procedencia y autoría de los documentos que se aportan al proceso, e identificar a que flujo funcional o trámite pertenecen. Esta autenticidad debe realizarse en la funcionalidad dispuesta en el sistema de forma manual y/o automática. Por otro lado, también se identifica la necesidad de la autenticación de los usuarios finales y por consiguiente su autorización. Responsabilidad: Capacidad de rastrear de forma inequívoca las acciones de una entidad. Esta característica se centra en nuestro caso, en la auditoría que se deberá hacer sobre las acciones identificadas en los requerimientos. Integridad: Capacidad del sistema o componente para prevenir accesos o modificaciones no autorizados a datos o programas de ordenador.




Versión 0.1


Página 27 de 86

Es fundamental que, según las características de los procesos, se puedan mantener los registros e información de forma íntegra en el sistema, guardando versionamiento de los documentos si es necesario. Confidencialidad: Capacidad de protección contra el acceso de datos e información no autorizados, ya sea accidentalmente o deliberadamente. En esta sub-característica se trata de la transmisión de datos y su protección cuando ya están persistidos, por lo tanto, se deben identificar los datos sensibles según ley y darles tratamiento.

Atributo de Calidad Seguridad


d

Autenticidad NFR-2

Los usuarios deben autenticarse y autorizarse ante el sistema con o sin registro previo y aprobación del MCVT, dependiendo de su rol, para poder acceder a sus funcionalidades y tener permisos solo a lo que se determine.

Alta

Responsabilidad NFR-5

Contar con la trazabilidad de las diferentes acciones que realizan los actores sobre el sistema, permitiendo el registro y guardado de manera inalterable la auditoria de cada una de las etapas de los procesos.

Media

Integridad NFR-8 Garantizar la integridad de la información Alta

Confidencialidad

NFR-12 El acceso web y uso de servicios web debe hacer uso de protocolos de comunicación seguros como https

Alta

NFR-16 El sistema debe cumplir con la normatividad y políticas vigentes, definidas por MINTIC.

Alta

Tabla 9. Atributo de calidad Seguridad.


5.1.7 Mantenibilidad

Para el atributo de Mantenibilidad se maneja una sub-característica. Modularidad: Capacidad de un sistema o programa de ordenador (compuesto de componentes discretos) que permite que un cambio en un componente tenga un impacto mínimo de los demás.




Versión 0.1


Página 28 de 86

La exigencia de este atributo radica en la definición de divisiones lógicas, que se deben alinear en general con las estructuras arquitectónicas.

Atributo de Calidad Mantenibilidad


d

Modularidad NFR-14 El sistema debe tener estructura por módulos independientes para que sus funcionalidades e interoperabilidad pueda ser utilizada a conveniencia.

Media

Tabla 10. Atributo de calidad Mantenibilidad.


5.1.8 Árbol de Utilidad

Con la información presentada en las anteriores tablas se define el árbol de calidad con la tipificación de atributos de calidad seleccionados.




Versión 0.1


Página 29 de 86

Ilustración 3. Árbol de utilidad. Fuente: UT Fonvivienda 2019, 2020




Versión 0.1


Página 30 de 86

5.2 ESCENARIOS DE CALIDAD

Dado el árbol de utilidad, a continuación, se definen los escenarios donde se tratan cada uno de

los atributos de calidad, relacionados a los requerimientos no funcionales levantados durante la

fase de requerimiento.

A continuación, se establecen los escenarios de calidad derivados de los requerimientos no

funcionales y su tipificación con los atributos de calidad. Los escenarios de calidad están descritos

según ATAM (Architecture Tradeoff Analysis Method - Método de Análisis Relación de

Arquitectura). Se utiliza el paso de ATAM en el que se realiza la identificación del árbol de

atributos para tener un enfoque en el comportamiento requerido y calidad del sistema a construir.

De esta manera se logra disminuir los riesgos asociados a las diferentes características que debe

tener el sistema.

La exigencia en la medida de estos escenarios debe corresponder a la practicidad más que a la

teoría, puesto que se debe tener presente el esfuerzo requerido para la implementación de la

arquitectura y también el requerido para realizar su comprobación.

El planteamiento o descripción de los escenarios, incluye una característica que es la Descripción. Este atributo se utilizará para adicionar al escenario, cualquier tipo de aclaración, puntualización o definición, relacionada con la ejecución de la Medida.

5.2.1 Escenarios de Completitud Funcional

ESCENARIO 22 Cumplimiento de decretos

Atributo de Calidad

Adecuación funcional – completitud funcional.

Preocupación El sistema debe representar y cumplir funcionalmente con los decretos de ley correspondientes, relacionados con las políticas de vivienda soportadas por el sistema.

Prioridad Alta

Dificultad de Implementarlo

Media

Fuente Externa al sistema

Estimulo Las funcionalidades responden a requerimientos de ley.

Artefacto Sistema

Ambiente Producción

Respuesta El sistema representa lo requerido por la ley.




Versión 0.1


Página 31 de 86

ESCENARIO 22 Cumplimiento de decretos

Medida El sistema cumple con lo estipulado en los decretos de ley que rigen las funciones del Ministerio de Vivienda.

Descripción N/A.

Tabla 11. Cumplimiento de decretos Fuente: UT Fonvivienda 2019, 2021

ESCENARIO 23 Parametrización de flujos de trabajo

Atributo de Calidad

Adecuación funcional – completitud funcional.

Preocupación Si los decretos de ley, en los que están basados algunas funcionalidades del sistema, cambian, el sistema debe seguir cumpliendo con el decreto, permitiendo hacer las modificaciones necesarias.

Prioridad Alta


Alta


Estimulo Los decretos de ley que rigen algunas funcionalidades cambian.

Artefacto Sistema


Respuesta El sistema debe permitir que, a través de configuración o parametrización, se modifiquen las funcionalidades que implementan los decretos de ley.

Medida El sistema puede ser modificable para cumplir con cambios en flujos de trabajo o procesos del negocio.

Descripción

- Se debe determinar la parametrización que tendrán los flujos de trabajo. - No todas las modificaciones a los decretos podrían ser configurables o parametrizables. - Se debe tener en cuenta que las modificaciones de ley pueden representar cambio en

las reglas de negocio.

Tabla 12. Parametrización de flujos de trabajo Fuente: UT Fonvivienda 2019, 2021

5.2.2 Escenarios de Pertinencia Funcional




Versión 0.1


Página 32 de 86

ESCENARIO 24 Explotación de la información

Atributo de Calidad

Adecuación funcional – pertinencia funcional.

Preocupación La centralización de la información en el sistema debe permitir que los usuarios puedan realizar consultas dinámicas.

Prioridad Alta


Alta

Fuente Externa al sistema – usuarios del sistema

Estímulo Los usuarios consultan información del sistema.

Artefacto Sistema


Respuesta El sistema permite configurar consultas con filtros personalizados.

Medida El sistema permite la configuración de la consulta que se quiere realizar.

Descripción - Se debe tener en cuenta que la información del sistema debe estar estructurada. - La capacidad de explotación de la información dependerá del modelo entidad relación,

su modelamiento y la herramienta o módulo que se utilice para tal fin.

Tabla 13. Explotación de la información


5.2.3 Escenarios de Capacidad

ESCENARIO 04 Solicitudes Concurrentes

Atributo de Calidad

Eficiencia de Desempeño - Capacidad.

Preocupación Alta concurrencia en casos de uso de recibo de solicitudes de licencias urbanísticas. Las solicitudes se entienden como el envío o diligenciamiento de formularios que incluyen anexos como PDFs y que no se reciben masivamente.

Prioridad Alta


Baja

Fuente Externa al sistema – usuario final




Versión 0.1


Página 33 de 86

ESCENARIO 04 Solicitudes Concurrentes

Estímulo Ingreso de solicitudes o diligenciamiento de formularios por parte de varios usuarios del sistema

Artefacto Módulo ingreso de solicitudes


Respuesta El sistema registra las solicitudes ingresadas y permite finalizar correctamente la funcionalidad ejecutada por el usuario final.

Medida El 100% de las solicitudes son procesadas correctamente por el sistema al hacer 125 solicitudes por hora.

Descripción Se debe considerar no solo el esfuerzo concurrente (utilización de recursos necesarios) sino también las sesiones activas de usuarios durante la solicitud y el manejo de memoria que se podría requerir.

Tabla 14. Solicitudes Concurrentes


ESCENARIO 05 Carga de Documentos

Atributo de Calidad


Concern En el ingreso de solicitudes es necesario el cargue de documentos anexos que son pre-requisitos de negocio.

Prioridad Alta


Media


Estímulo Cargue de documentos durante las solicitudes.

Artefacto Módulo ingreso de solicitudes


Respuesta El sistema permite el cargue de anexos en formato PDF e imagen correctamente.

Medida El máximo peso de un archivo o anexo a cargar es de 250M.

Descripción N/A

Tabla 15. Carga de Documentos





Versión 0.1


Página 34 de 86

ESCENARIO 06 Ejecución de Reglas de Negocio

Atributo de Calidad


Concern La validación o ejecución de reglas de negocio en determinadas funcionalidades, puede llegar a ser demandante para el sistema y sobre todo si hay concurrencia sobre estas funcionalidades.

Prioridad Media


Media


Estímulo Ingreso de solicitudes por parte de varios usuarios del sistema

Artefacto Motor de reglas – Lógica de validación.


Respuesta El sistema debe ejecutar de forma correcta las reglas de negocio configuradas para una funcionalidad específica, mientras hay concurrencia en dicha funcionalidad.

Medida El 100% de las reglas de negocio son ejecutadas de forma correcta y sin degradación de tiempos. El sistema debe responder correctamente a la ejecución de 2 validaciones por segundo, durante 10 segundos.

Descripción Se debe identificar la regla de negocio o validación en el ingreso de solicitudes que sea la más exigente en cuanto procesamiento para corroborar el escenario.

Tabla 16. Ejecución de Reglas de Negocio


ESCENARIO 07 Tiempos de Respuesta

Atributo de Calidad


Concern

Los tiempos de respuesta del sistema deben estar acordes a las necesidades y promedios para una aplicación web. Estos tiempos pueden estar dados por la sumatoria de la respuesta en las diferentes capas del sistema o componentes utilizados para cumplir con una funcionalidad específica.

Prioridad Media


Alta


Estímulo Ejecución de consulta común en el sistema o registro de información básico (CRUD).

Artefacto Sistema.




Versión 0.1


Página 35 de 86

ESCENARIO 07 Tiempos de Respuesta


Respuesta El sistema responde en tiempos aceptables a las peticiones de un usuario final.

Medida

- Para el estímulo que pasa por todas las capas o componentes necesarios del sistema, el tiempo total no debe ser mayor a 5 segundos.

- Para transacciones (CRUD) simples en la base de datos desde capa de negocio o componente de impedancia relacional, el tiempo no debe ser mayor a 1 segundo.

- Para el consumo de un servicio web, sin tener en cuenta el proceso fuera del sistema, el tiempo no debe ser mayor a 1 segundo.

- Para el despliegue de una página web el tiempo no debe ser mayor a 2 segundos. - Para la atención de una transacción en la capa de negocio, no debe ser mayor a 2

segundos.

Descripción El sistema debe responder sobre los tiempos que tiene control, tomando como base operaciones o transacciones comunes donde esta tipificación este dada por las características de la mayoría de las funcionalidades.

Tabla 17. Tiempos de Respuesta


ESCENARIO 08 Seguimiento a Solicitudes

Atributo de Calidad


Concern Las solicitudes que ingresen a TERRA, se les debe poder hacer seguimiento y por consiguiente surtir el o los procesos definidos.

Prioridad Alta


Bajo


Estímulo Ejecución de funcionalidades sobre las solicitudes de licencias urbanísticas.

Artefacto Sistema.


Respuesta El sistema permite ejecutar las funcionalidades a todas las solicitudes de licencia urbanística, dentro de los procesos definidos.

Medida El sistema debe poder responder funcionalmente a un promedio de 10.000 solicitudes de licencia urbanística.

Descripción Se debe tener en cuenta los recursos necesarios para soportar este escenario, como lo es la base de datos.

Tabla 18. Seguimiento a Solicitudes




Versión 0.1


Página 36 de 86


ESCENARIO 09 Capacidad de Almacenamiento

Atributo de Calidad


Concern El sistema tendrá que guardar documentación de todos los procesos o flujos de trabajo.

Prioridad Alta


Media


Estímulo Ejecución de funcionalidades del sistema.

Artefacto Sistema.


Respuesta El sistema permite guardar y en general administrar según las funcionalidades, los documentos necesarios y su retención.

Medida El sistema debe tener la capacidad de mantener y persistir 90.000 documentos digitales por año.

Descripción Se debe identificar, para la validación de este escenario, los documentos representativos (los más comunes) que se guardarán y cuál componente tendrá la responsabilidad.

Tabla 19. Capacidad de Almacenamiento


ESCENARIO 10 Usuarios con Sesión Activa

Atributo de Calidad


Concern El sistema podrá ser utilizado aproximadamente por 250.000 usuarios en sus diferentes funcionalidades.

Prioridad Media


Media



Artefacto Sistema.




Versión 0.1


Página 37 de 86

ESCENARIO 10 Usuarios con Sesión Activa


Respuesta El sistema permite que los usuarios tengan una sesión activa mientras estén ejecutando alguna funcionalidad.

Medida El sistema debe soportar 1250 usuarios con sesión activa durante un día.

Descripción Para las funcionalidades del módulo de licencias urbanísticas los usuarios estimados son de 1250. El sistema deberá manejar una estrategia de caducidad de sesiones.

Tabla 20. Usuarios con Sesión Activa


ESCENARIO 11 Usuarios Concurrentes en el Sistema

Atributo de Calidad


Concern La concurrencia de usuarios estará dada por el máximo de usuarios que podrán ser aproximadamente 200.000.

Prioridad Media


Alta


Estímulo Ejecución de funcionalidades, sobre todo el diligenciamiento de formularios para la postulación y consultas permitidas a la ciudadanía.

Artefacto Sistema.


Respuesta El sistema permite que los usuarios realicen las funcionalidades expuestas por el sistema.

Medida El sistema debe soportar un máximo aproximado de 250 usuarios concurrentes.

Descripción N/A.

Tabla 21. Usuarios Concurrentes en el Sistema





Versión 0.1


Página 38 de 86

5.2.4 Escenarios de Comportamiento Temporal

ESCENARIO 12 Calidad de Conectividad

Atributo de Calidad

Eficiencia de Desempeño – Comportamiento Temporal.

Concern Los usuarios podrán presentar variaciones en la calidad de su conectividad y comunicación por internet, dado que será utilizado en todo el territorio Colombiano.

Prioridad Media


Alta



Artefacto Sistema.


Respuesta Los usuarios pueden ejecutar las funcionalidades requeridas, desde cualquier parte del territorio Colombiano, a través de diferentes medios de acceso a internet.

Medida El sistema debe tener la capacidad de reaccionar ante condiciones de baja calidad en conexión a internet dadas por conexiones 3g o menores, o con un ancho de banda igual o menor de 5Mb, haciendo guardados parciales y la granularidad de los servicios funcionales

Descripción Este escenario no contempla el funcionamiento del sistema sin acceso a internet.

Tabla 22. Calidad de Conectividad


ESCENARIO 13 Aumento de carga temporal

Atributo de Calidad

Eficiencia de desempeño – Comportamiento temporal.

Concern El sistema podrá tener aumentos momentáneos e inesperados de transacciones, que se presenten como picos de carga.

Prioridad Media


Media






Versión 0.1


Página 39 de 86

ESCENARIO 13 Aumento de carga temporal

Artefacto Sistema.


Respuesta Los usuarios pueden ejecutar las funcionalidades requeridas correctamente.

Medida El sistema debe poder responder con un 30% más de carga del comportamiento promedio.

Descripción

Se puede establecer para la validación de este escenario, una carga promedio basada en pruebas de estrés con las funcionalidades que más sean frecuentes. La capacidad de crecimiento horizontal automático o elasticidad en los recursos utilizados puede ser definida tomando como base necesidades de carga mínimas.

Tabla 23. Aumento de carga temporal


5.2.5 Escenarios de Interoperabilidad

ESCENARIO 14 Interoperabilidad del sistema

Atributo de Calidad

Compatibilidad – interoperabilidad.

Concern El sistema debe poder exponer servicios de integración estándar para que las funcionalidades sean beneficiadas con información de actores externos y de la misma forma poder enviar información a estos actores.

Prioridad Media


Media

Fuente Externa al sistema – Entidades externas

Estímulo Obtención de información de otras entidades y envío de información.

Artefacto Sistema


Respuesta El sistema se integra con otras entidades o sistemas para el intercambio de información.

Medida Ante una necesidad de intercambio de información el sistema debe proveer los mecanismos suficientes y estándares al 100% de las entidades que lo puedan utilizar.




Versión 0.1


Página 40 de 86

ESCENARIO 14 Interoperabilidad del sistema

Descripción Se podrían dar varios tipos de mecanismos de integración, dependiendo de las posibilidades de las entidades externas.

Tabla 24. Interoperabilidad del sistema


5.2.6 Escenarios de Protección Contra Errores

ESCENARIO 15 Protección contra errores del usuario

Atributo de Calidad

Usabilidad – protección contra errores.

Concern

La utilización del sistema por parte de los usuarios finales puede generar errores por una mala utilización de sus funcionalidades en el ingreso de la información. También los usuarios finales deben recibir los errores formateados de forma que se entienda lo ocurrido y lo que se puede hacer. La norma NTC 5854 para el nivel AA se debe cumplir con respecto a los requisitos de accesibilidad para las páginas web22.

Prioridad Baja


Media

Fuente Externa al sistema – usuarios finales

Estímulo Ingreso de información por parte del usuario final y generación de un error interno del sistema.

Artefacto Sistema


Respuesta

Ante un error interno, el sistema muestra al usuario final el error formateado de forma entendible. Al ingresar información por parte de un usuario, el sistema utiliza datos predefinidos, combos desplegables, listas predefinidas para que el usuario ingrese la menor cantidad de información digitada posible.

Medida

El sistema despliega información predefinida para los formularios de ingreso de información y formatos e implementar controles en el ingreso de datos, para el manejo de la calidad de la información y ante un error interno, muestra un mensaje formateado para el usuario, teniendo en cuenta lo respectivo a la norma NTC 5854.

Descripción

- Los mensajes de error presentados al usuario final deben ser entendibles y no técnicos. - La validación de la información ingresada por el usuario debe responder según

estrategia de validación. - Se debe tener en cuenta, en lo referente al control y visualización de errores, la norma

NTC 5854 en el nivel AA. Tabla 25. Protección contra errores del usuario

22 Norma NTC 5854. https://www.libano-tolima.gov.co/Transparencia/PublishingImages/Paginas/Modelo-Integrado-de-Planeacion-y-Gestion-/DOCUMENTO%20DE%20%20CONSULTA-%20NORMA%20%20NTC%205854.pdf




Versión 0.1


Página 41 de 86


5.2.7 Escenarios de Estética de la Interfaz

ESCENARIO 16 Estética de la interfaz

Atributo de Calidad

Usabilidad – estética de la interfaz.

Concern El sistema debe tener una interfaz acorde a los lineamientos del Ministerio23 y ser de fácil utilización. La norma NTC 5854 para el nivel AA se debe cumplir con respecto a los requisitos de accesibilidad para las páginas web.

Prioridad Baja


Media

Fuente Externa al sistema – usuarios finales

Estímulo Utilización de las funcionalidades del sistema.

Artefacto Sistema


Respuesta El sistema tiene un diseño gráfico basado en un kit de interface gráfica y cumple con lineamientos básicos de usabilidad.

Medida Utilización de un kit de diseño gráfico y principios básicos de usabilidad para la interface gráfica.

Descripción - Se debe tener en cuenta, en lo referente al control y visualización de errores, la norma

NTC 5854 en el nivel AA.

Tabla 26. Estética de la interfaz


5.2.8 Escenario de Tolerancia a Fallos

ESCENARIO 17 Tolerancia a fallos

Atributo de Calidad

Fiabilidad – tolerancia a fallos.

Concern Podrán ocurrir fallas en el sistema, debido a picos de carga o concurrencia, fallas de infraestructura o de los componentes de software, que podrían tener impacto negativo, dadas fechas determinadas y afectar la prestación del servicio.

23 https://www.gov.co/files/KITUI.pdf




Versión 0.1


Página 42 de 86

Prioridad Alta


Media


Estímulo Utilización de las funcionalidades que tengan vigencias de solicitud o trámites que puedan generar picos de carga o utilización y/o afectar un nodo físico.

Artefacto Sistema


Respuesta El sistema debe seguir funcionando ante una falla de hardware, dando la posibilidad al usuario de seguir utilizando funcionalidades del sistema.

Medida El sistema, luego de presentarse una falla de hardware, se debe poder recuperar y volver a permitir que el usuario utilice las funcionalidades, en máximo media hora luego de la falla presentada.

Descripción Al presentarse la falla, el tiempo para que el sistema se recupere, puede depender de estrategias de alta disponibilidad, por lo tanto, debe ser racional en cuanto a recursos.

Tabla 27. Tolerancia a fallos


5.2.9 Escenarios de Disponibilidad

ESCENARIO 18 Disponibilidad del sistema

Atributo de Calidad

Fiabilidad – disponibilidad.

Concern El sistema debe cumplir con una disponibilidad de cara las necesidades de utilización de este y de acuerdo con unos horarios dispuestos por negocio.

Prioridad Media


Alta


Estímulo Utilización de una funcionalidad del sistema en un horario establecido.

Artefacto Sistema





Versión 0.1


Página 43 de 86

ESCENARIO 18 Disponibilidad del sistema

Respuesta El sistema está disponible para que un usuario utilice sus funcionalidades.

Medida El sistema debe estar disponible las 24 horas del día, los 7 días de la semana, todos los días del año, con un porcentaje de disponibilidad del 99.5%.

Descripción

Pueden establecerse periodos de inactividad del sistema para mantenimiento o despliegue de nuevas versiones de software, si fuera necesario. Este escenario no comprende definiciones de continuidad del negocio. La disponibilidad del sistema debe estar basada en una estrategia de alta disponibilidad teniendo en cuenta la capacidad de infraestructura.

Tabla 28. Disponibilidad del sistema


5.2.10 Escenarios de Autenticidad

ESCENARIO 19 Verificación documentos

Atributo de Calidad

Seguridad – Autenticidad.

Concern Para las solicitudes donde el usuario final o beneficiario debe entregar documentos anexos, se debe validar su autenticidad a través de firma digital cuando se tengan las condiciones y/o el usuario entregue el documento firmado.

Prioridad Alta


Alta


Estímulo Validación de documentos anexos o pre requisitos en una solicitud.

Artefacto Módulo de ingreso de solicitudes.


Respuesta El sistema puede realizar la verificación de una firma digital y confirmar la autenticidad de un documento.

Medida El sistema validará un documento por su firma digital y dará un resultado de éxito o fracaso.

Descripción Este escenario corresponde a cuando se requiere validar la autenticidad de un documento entregado por un usuario final en formato digital.




Versión 0.1


Página 44 de 86

Tabla 29. Verificación documentos


ESCENARIO 20 Autenticación de usuarios

Atributo de Calidad

Seguridad – Autenticidad.

Concern La utilización del sistema será por usuarios creados y para que un actor pueda acceder al sistema debe estar debidamente autenticado y cumplir con políticas RBAC para el manejo de roles y permisos.

Prioridad Alta


Media


Estímulo Un usuario quiere ejecutar una funcionalidad en el sistema.

Artefacto Módulo de autenticación o ingreso al sistema.


Respuesta El usuario ingresa sus credenciales de autenticación, el sistema las valida y les da autorización a unas funcionalidades específicas para el usuario.

Medida Ningún usuario puede ingresar al sistema o ejecutar funcionalidades sin que este registrado en el sistema, según las credenciales, el sistema otorgará los permisos.

Descripción Pueden existir funcionalidades del sistema que sean públicas y no necesite que el usuario se autentique. Estas funcionalidades deben estar específicamente identificadas.

Tabla 30. Autenticación de usuarios


5.2.11 Escenarios de Responsabilidad

ESCENARIO 21 Trazas de auditoria

Atributo de Calidad

Seguridad – responsabilidad.




Versión 0.1


Página 45 de 86

ESCENARIO 21 Trazas de auditoria

Concern Dada la normatividad y las funcionalidades del sistema, sobre todo las que son parte o conforman flujos de trabajo o procesos, se debe poder hacer seguimiento a las acciones que realizan los actores y que exista un modelo de auditoría.

Prioridad Alta


Media


Estímulo Utilización de las funcionalidades del sistema.

Artefacto Sistema


Respuesta Se puede consultar las trazas de auditoría definidas y configuradas.

Medida El sistema debe permitir el registro y consulta del 100% de la auditoría de las funcionalidades establecidas, configuradas y codificadas.

Descripción N/A.

Tabla 31. Trazas de auditoria


5.2.12 Escenarios de Integridad


Atributo de Calidad

Seguridad – integridad.

Concern Se deban mantener los documentos que son requisitos para los diferentes trámites y flujos funcionales, inmutables, así se reemplacen funcionalmente o se actualicen, deben quedar las versiones anteriores.

Prioridad Media


Media


Estímulo Ingreso de los documentos que son requisitos para los trámites.




Versión 0.1


Página 46 de 86


Artefacto Sistema


Respuesta El sistema guarda todos los documentos especificados de forma inalterable.

Medida Al 100% deben permanecer los documentos que han sido guardados, es decir, sin alterar y se debe proveer una forma técnica para comprobar en el tiempo que esos documentos no han sido modificados.

Descripción

- Se debe tener determinado en qué funcionalidades y qué documentos son los que se deben mantener con versiones o inalterables según el escenario.

- El sistema puede tener un mecanismo para la verificación de la integridad del documento.

Tabla 32. Autenticación de usuarios


5.2.13 Escenarios de Confidencialidad

ESCENARIO 23 Transmisión de datos de forma segura

Atributo de Calidad

Seguridad – confidencialidad.

Concern El sistema por ser una plataforma web, transmitirá datos sensibles a través de internet.

Prioridad Alta


Baja

Fuente Externa al sistema – comunicación por internet

Estimulo Transmisión de datos sensibles durante la ejecución de las funcionalidades.

Artefacto Sistema – protocolo de comunicación


Respuesta El sistema transmite los datos sensibles con seguridad a través de internet usando protocolo HTTPS y SFTP.

Medida Durante la transmisión de datos sensibles, el 0% de estos datos, aunque la transmisión sea interceptada y los datos sean capturados, son legibles.




Versión 0.1


Página 47 de 86

ESCENARIO 23 Transmisión de datos de forma segura

Descripción Este escenario puede validarse utilizando herramientas para ver el tráfico en una red y verificar el protocolo HTTPS y SFTP.

Tabla 33. Transmisión de datos de forma segura


ESCENARIO 24 Tratamiento de datos sensibles

Atributo de Calidad

Seguridad – confidencialidad.

Concern Alguna de la información que se manejará dentro del sistema, es según normatividad, sensible y por lo tanto confidencial.

Prioridad Alta


Baja


Estímulo Registro o consulta de información confidencial.

Artefacto Sistema


Respuesta El sistema guarda los datos confidenciales de forma segura y los pueden consultar de forma legible solo los usuarios con los respectivos permisos.

Medida El 100% de los datos confidenciales, son ilegibles para las personas o actores a los que no se les ha otorgado los permisos correspondientes.

Descripción

- El sistema debe guardar los datos que se determinen de forma ilegible en la base de datos, pueden estar encriptados u ofuscados.

- El sistema debe permitir solo a los usuarios con permisos la lectura o consulta de los datos confidenciales, ni siquiera los administradores del sistema o infraestructura, sin los permisos adecuados, deben poder consultarlos.

- Se debe determinar con anterioridad de la validación, qué datos son confidenciales y se les dará el tratamiento planteado en el escenario.

- Se debe tener en cuenta los reportes, la estructura datamart y cualquier explotación de datos que se haga a través del sistema.

Tabla 34. Tratamiento de datos sensibles





Versión 0.1


Página 48 de 86

5.2.14 Escenarios de Modularidad

ESCENARIO 25 Modularidad del sistema

Atributo de Calidad

Mantenibilidad - modularidad.

Concern El sistema debe mostrar las funcionalidades en módulos lógicos que dividan sus opciones según los requerimientos.

Prioridad Media


Alta


Estímulo Presentación de las funcionalidades por módulos.

Artefacto Sistema


Respuesta El sistema presenta las opciones a los usuarios por módulos.

Medida El sistema permite poner en funcionamientos las funcionalidades por los módulos que se requiera.

Descripción - Los módulos serán divisiones lógicas.

Tabla 35. Modularidad del sistema


5.3 ACUERDO DE NIVEL DE SERVICIOS

La siguiente ilustración presenta los componentes del modelo de acuerdo de niveles de servicio

de SISFV:




Versión 0.1


Página 49 de 86

Ilustración 1. Modelo de acuerdo de servicios SISFV


Los componentes del modelo de acuerdo de niveles de servicio de SISFV son los siguientes:

• Catálogo de actores25: Listado de actores de SISFV, cuenta con la descripción y tipo de

cada actor.

• Catálogo de servicios de TI de MVCT: Documento con el listado de servicios de tecnología

que ofrece el área de Informática de MVCT a las otras áreas.

• Proceso de Gestión de Tecnologías de la Información y las Comunicaciones:

Procedimiento GSI-P-03 Gestión de incidentes y/o requerimientos técnicos para

disponibilidad de servicio.pdf26: Documento que contiene la descripción de las actividades

del procedimiento de gestión de incidentes y/o requerimientos técnicos.

Los niveles de soporte para el servicio de SISFV son los propuestos en el procedimiento GSI-P-

03:

• Soporte de primer nivel – agente nivel 1.: Se categorizan como casos que requieren




Versión 0.1


Página 50 de 86

soporte de primer nivel cualquier solicitud de soporte técnico o funcional de las

aplicaciones, validación de acceso, que pueda ser solucionado en primera instancia por

la Mesa de Servicio; para estos casos la mesa de servicio recepcionará, clasificará y dará

solución al caso.

• Soporte de segundo nivel – especialista nivel 2: Se categorizan como casos que requieren

de soporte de segundo nivel cualquiera que no pueda ser solucionado por el Agente de

Nivel 1 y que requiera ser escalado a otro equipo de trabajo para su tratamiento.

• Soporte de tercer nivel – especialista nivel 3: Se categorizan como casos que requieren

de soporte de tercer nivel cualquiera que no pueda ser solucionado por los niveles

anteriores o equipo de trabajo al que fue escalado para dar una solución interna en el

MVCT, el requerimiento es escalado a un proveedor externo para ser solucionado, el cual

debe ser monitoreado por el responsable que asignó el escalamiento que lo tenga

asignado.

Se propone agregar al catálogo de servicios de TI de MVCT el Servicio de SISFV con los

siguientes atributos:

• Tipo: Servicio de Negocio.

• Categoría: Sistemas de información.

• Acceso: https://www.minvivienda.gov.co.

• Responsable: GSTAI.

• Descripción: La solución arquitectónica del SISFV está enmarcada por la necesidad de

un mecanismo de apoyo para las funciones de FONVIVIENDA en lo que respecta a sus

componentes de oferta y demanda para el subsidio familiar de vivienda27.

• Alcance del servicio: Administrar y soportar todos los componentes de SISFV.

• Disponibilidad del sistema: El sistema debe estar disponible las 24 horas del día, los 7

días de la semana, todos los días del año, con un porcentaje de disponibilidad del 99.5%.

• Horario prestación del servicio: El servicio se presta de forma continua (7x24).

• Contacto de Soporte:

o Soporte al Servicio Telefónico: Ext. 3405.

https://www.minvivienda.gov.co/




Versión 0.1


Página 51 de 86

o Email: [email protected].

o Horario: lunes a viernes de 8:00 AM a 6:00 PM.

El servicio SISFV contemplará los siguientes sub-servicios:

• Gestión de usuarios de SISFV.

• Apoyo y soporte funcional de SISFV.

• Solicitud de información de SISFV.

• Gestión de incidentes de SISFV.

A continuación, presentaremos cada sub-servicio con sus correspondientes acuerdos de niveles

de servicio:

Gestión de usuarios:

- Objetivo: Prestar el servicio de creación, actualización, consulta y recuperación de

contraseñas de los usuarios de SISFV.

- Alcance: Incluye la creación, actualización, consulta y recuperación de contraseña de

los usuarios de SISFV.

- Responsable: soporte de primer Nivel- Agente Nivel 1 de la mesa de servicios de

MVCT. Usuarios objetivo: Catálogo de actores.

- Documentos de Referencia: Manual funcional SISFV.

- Horario: lunes a viernes de 8:00 AM a 6:00 PM.

- Canal: Mesa de servicio http://aranda/usdkv8.

- Métrica:

o Tiempo de Atención: 4 Horas hábiles.

o Tiempo de Respuesta: 8 Horas hábiles.

- Indicador 1: Cantidad de solicitudes atendidas satisfactoriamente/ Cantidad de

solicitudes recibidas.

mailto:[email protected]

http://aranda/usdkv8




Versión 0.1


Página 52 de 86

- Objetivo del indicador 1: 100% de cumplimiento.

- Indicador 2: Cantidad de solicitudes atendidas satisfactoriamente en el tiempo de

respuesta/ Cantidad de solicitudes recibidas.

- Objetivo del indicador 2: 100% de cumplimiento.

- Tiempos de excepción:

- Errores en la funcionalidad del sistema o indisponibilidad de este o alguna de sus funcionalidades.

- Aprobaciones necesarias por fuera del flujo.

Apoyo y soporte funcional de SISFV

• Objetivo: Prestar el servicio de apoyo o soporte de las funcionalidades de SISFV a los

usuarios.

• Alcance: Apoyo funcional a los usuarios de SISFV, las funciones de SISFV se encuentran

documentadas en el Manual de funcional SISFV, algunos ejemplos son: creación de

usuarios, cambio de contraseña, registro de solicitud de subsidio.

• Responsable: soporte de primer Nivel- Agente Nivel 1 de la mesa de servicios de

MVCT.

• Usuarios objetivo: Catálogo de actores[4].

• Documentos de Referencia: Manual funcional SISFV.

• Horario: lunes a viernes de 8:00 AM a 6:00 PM

• Canal: Mesa de servicio http://aranda/usdkv8, Chat y vía telefónica.

• Métrica:

o Tiempo de Atención: 4 Horas hábiles.

o Tiempo de Respuesta: 8 Horas hábiles.

• Indicador 1: Cantidad de solicitudes atendidas satisfactoriamente/ Cantidad de

https://word-edit.officeapps.live.com/we/wordeditorframe.aspx?ui=es%2DES&rs=es%2DES&wopisrc=https%3A%2F%2Fminviviendagovco-my.sharepoint.com%2Fpersonal%2Fconsultoria_sisfv_minvivienda_gov_co%2F_vti_bin%2Fwopi.ashx%2Ffiles%2F8c7b832ccdb94aca98fc138199245d6d&wdenableroaming=1&mscc=0&wdodb=1&hid=C554C59F-E039-0000-9EE2-BE6DF084BF5C&wdorigin=Other&jsapi=1&jsapiver=v1&newsession=1&corrid=a8eab23b-e736-49ab-8fce-2e0a0be02c30&usid=a8eab23b-e736-49ab-8fce-2e0a0be02c30&sftc=1&mtf=1&instantedit=1&wopicomplete=1&wdredirectionreason=Unified_SingleFlush&rct=Medium&ctp=LeastProtected#_ftn4





Versión 0.1


Página 53 de 86


• Objetivo del indicador 1: 100% de cumplimiento.

• Indicador 2: Cantidad de solicitudes atendidas satisfactoriamente en los tiempos de

respuesta establecidos/ Cantidad de solicitudes recibidas.



- Errores en la funcionalidad del sistema o indisponibilidad de este o alguna de sus funcionalidades.

- Indisponibilidad de la base de conocimiento.

Solicitud de información de SISFV

• Objetivo: Prestar el servicio de recolectar y procesar información de SISFV como

reportes, auditorías, tableros de control, históricos y registros.

• Alcance: Solicitudes de información almacenada o procesada en SISFV.

• Responsable: Soporte de segundo nivel – especialista nivel 2: Administrador de SISFV.

• Usuarios objetivo: Catálogo de actores.

• Documentos de Referencia: Manual técnico SISFV.

• Horario: lunes a viernes de 8:00 AM a 6:00 PM.

• Canal: Mesa de servicio http://aranda/usdkv8, Chat y vía telefónica.

• Métrica:

o Tiempo de Atención: 4 Horas .hábiles.

o Tiempo de Respuesta: 24 Horas .hábiles.

• Indicador 1: Cantidad de solicitudes atendidas satisfactoriamente/ Cantidad de







Versión 0.1


Página 54 de 86

• Indicador 2: Cantidad de solicitudes atendidas satisfactoriamente en los tiempos de

respuesta establecidos/ Cantidad de solicitudes recibidas.



- Indisponibilidad de las fuentes de información.

Gestión de incidentes:

• Objetivo: Soportar el servicio de gestión de incidentes de las funcionalidades y

componentes de SISFV.

• Alcance: Soporte de incidentes de SISFV.

• Responsable: Soporte de segundo nivel – especialista nivel 2: Administrador de

SISFV.

• Usuarios objetivo: Catálogo de actores.

• Documentos de Referencia: Manual técnico SISFV.

• Horario: 24 horas al día por 7dias a la semana.

• Canal: Mesa de servicio http://aranda/usdkv8

• Indicador 1: Cantidad de incidentes atendidos satisfactoriamente / Cantidad de

incidentes recibidos.


• Indicador 2: Cantidad de incidentes atendidos satisfactoriamente en los tiempos de

respuesta establecidos/ Cantidad de incidentes recibidos.


• Indicador 3: Cantidad de incidentes atendidos: Prioridad 1-Critica en los tiempos de

atención de respuesta previstos/ Cantidad de incides recibidos Prioridad 1-Critica.





Versión 0.1


Página 55 de 86


• Indicador 4: Cantidad de incidentes atendidos: Prioridad 2-Alta en los tiempos de

atención de respuesta previstos/ Cantidad de incides recibidos Prioridad 1-Alta.


• Indicador 5: Cantidad de incidentes atendidos: Prioridad 3-Media en los tiempos de

atención de respuesta previstos/ Cantidad de incides recibidos Prioridad 3-Media.


• Indicador 6: Cantidad de incidentes atendidos: Prioridad 4-Baja en los tiempos de

atención de respuesta previstos/ Cantidad de incides recibidos Prioridad 3-baja.


• Métrica:

Tabla 1 Métricas ANS Gestión de incidentes


Prioridad Descripción Tiempo de Atención - Horas calendario

Tiempo de Respuesta

Prioridad 1 - Critica

Indisponibilidad total del servicio. No se puede ingresar a SISFV

30 min (Corridos desde el momento de registrar la consulta o incidente).

4 hrs (Corridos desde el momento de registrar la consulta o incidente).

Prioridad 2 - Alta

Indisponibilidad de uno o más componentes de SISFV28, genera indisponibilidad parcial del servicio de SISFV, se puede ingresar a SISFV, pero uno o más funcionalidades no están disponibles. .






Versión 0.1


Página 56 de 86

Prioridad 3 - Media

Indisponibilidad de uno o más componentes de SISFV, que no genera indisponibilidad del servicio SISFV . se puede ingresar a SISFV, pero uno o más componentes generan mensajes de error y permiten continuar en SISFV.



Prioridad 4 - Baja

Funcionalidades de SISFV con errores cosméticos errores cosméticos o interfaz gráfica.

90 min (Corridos desde el momento de registrar la consulta o incidente)

48 hrs (Corridos desde el momento de registrar la consulta o incidente)


- Indisponibilidad de componentes o infraestructura fuera del control del proveedor como

canales de comunicación, etc.

Soporte de tercer nivel – especialista nivel 3

En los casos donde los componentes de SISFV presenten indisponibilidad o errores y estos no

puedan ser resueltos por el administrador de SISFV debido a que estos componentes son

provistos por terceros, deberá escalar al Soporte de tercer nivel – especialista nivel 3: Proveedor

del componente. Se recomienda una vez finalizado el desarrollo de SISFV, generar acuerdos de

niveles de servicio con los proveedores o fabricantes de los siguientes componentes de SISFV:

• Bizagi. • Servidores de aplicaciones. • Servidores web. • Bus de servicios empresariales. • Motor de reglas de negocio. • Base de datos. • Bodega de datos




Versión 0.1


Página 57 de 86

• Herramientas de BI y Analítica. • Sistemas operativos.

Los acuerdos con estos proveedores se deben diligenciar en el formato: “GTI-F-08 Acuerdo de

nivel de servicio soporte técnico” del proceso “Gestión de tecnologías de la información y las

comunicaciones”.




Versión 0.1


Página 58 de 86

6 VISTAS Y MODELOS ARQUITECTÓNICOS

Las siguientes perspectivas arquitectónicas representan el modelamiento de la solución arquitectónica y describen de forma de diagramas, diferentes puntos de vista acordes a la metodología 4+1. Cada una de estas vistas contiene las decisiones estructurales en forma de componentes y sus relaciones y están delimitadas por la arquitectura de referencia del MVCT. A continuación, se presentan las vistas arquitectónicas.

6.1 VISTA DE ESCENARIOS DE CASOS DE USO

Esta vista muestra parte del modelamiento de casos de uso que representa la funcionalidad central y más significativa del sistema, generando el contexto funcional que une las demás vistas. Los casos de uso describen los retos arquitectónicos relevantes para las decisiones de diseño de la arquitectura del sistema.

Uno de los escenarios para el diseño de la arquitectura esta dado por los casos de uso del licenciamiento urbanístico. Con el fin de identificar las funcionalidades se propone:

1. Diligenciamiento e impresión del Formulario Único Nacional (FUN) para la solicitud de

licencias urbanísticas en cualquiera de sus modalidades. Teniendo esta posibilidad, el sistema expondría este servicio a una gran cantidad de usuario finales que convierten a esta funcionalidad y al cargue de documentos en las más exigentes en cuanto a concurrencia.

2. Los servicios de administración de la solicitud, dentro de los cuales está la consulta del

estado de la solicitud, las consultas de solicitudes y licencias que pueden realizar los ciudadanos, registrados y no registrados en TERRA, las consultas y cambios que realizan internamente en las curadurías, esto representa un reto para el sistema al tener en cuenta la posible cantidad de transacciones que se pueden llegar a dar.




Versión 0.1


Página 59 de 86

Ilustración 4. Diagrama de casos de uso Licencias Urbanísticas




Versión 0.1


Página 60 de 86


6.2 VISTA LÓGICA O MODELO DE CONTEXTO

Esta vista representa la descripción de los componentes lógicos y sus relaciones. Se definen los componentes con sus responsabilidades y posibilidades de comunicación de alto nivel. A continuación, se presenta el diagrama lógico que contiene las decisiones base para el diseño de la arquitectura de TERRA.

Ilustración 5. Vista lógica o contextual Fuente: UT Fonvivienda 2019, 2020

La vista nos muestra las agrupaciones de componentes lógicos a nivel de capas o zonas de utilización. El usuario final podrá tener acceso a los trámites y/o diferentes opciones del sistema a través de la SEDE ELECTRÓNICA y el Portal único del estado colombiano tal como se definen




Versión 0.1


Página 61 de 86

en la arquitectura de referencia para los lineamientos de trámites y estándares para el portal gov.co24. Desde la SEDE ELECTRÓNICA se va a tener acceso, al componente de los tableros de control y reportes del SISFV que realiza explotación de datos. También desde la SEDE ELECTRÓNICA se tendrá acceso al Frontend, componente de aplicación web y a la parte gráfica expuesta por el gestor de procesos.

Ilustración 6. Zona de Usuarios Fuente: UT Fonvivienda 2019, 2020

Se identifica una capa de integración que está dada principalmente por el bus empresarial y que se convierte en la columna vertebral de la solución. A través del bus se tendrá integración con las entidades externas utilizando X-ROAD o permitiendo la conexión directa desde y hacia otras entidades según las necesidades del negocio. A través de este componente de integración se tiene relación con el BRMs, la posibilidad de la autenticación con el LDAP y con el sistema de gestión documental. El bus empresarial tendrá como apoyo una capa para el manejo de la lógica del negocio.

24 Arquitectura de referencia MCVT – Arquitectura referencia.docx




Versión 0.1


Página 62 de 86

Ilustración 7. Integración e Interoperabilidad


Se identifica dentro del diseño de la arquitectura, una capa de integración que está conformada principalmente por el bus empresarial y que se convierte en la columna vertebral de la solución. A través del bus se tendrá integración con las entidades externas utilizando X-ROAD o permitiendo la conexión directa desde y hacia otras entidades según necesidades del negocio. A través de este componente de integración, el bus empresarial tiene la posibilidad de la utilización del BRMs, obteniendo la capacidad de desacople de las reglas de negocio. A través del bus empresarial, se expone un servicio de autenticación que va contra el LDAP. A nivel de esta capa de integración el bus empresarial tiene conexión con el sistema de gestión documental con lo cual tendrá servicios que resuelvan esta integración. El bus empresarial tendrá como apoyo una capa para el manejo de la lógica del negocio, que expondrá servicios web o APIs que el bus administrará.

Ilustración 8. Aplicación web, microservicios





Versión 0.1


Página 63 de 86

A nivel de persistencia se definen dos repositorios, uno para centralizar toda la información del sistema y que se considera una base de datos transaccional. A través de un componente intermedio se hace traslado de información de la base de datos transaccional, transformándola y cargándola en una base de datos con una estructura para la explotación de datos.

Ilustración 9. Bases de datos


6.3 VISTA DE PROCESOS

En el siguiente diagrama podemos ver, en un momento dado de tiempo, las transacciones a nivel de peticiones, que se pueden dar en el sistema y como estas peticiones se distribuirán y atenderán. En esta vista se puede observar y definir las necesidades de la atención de los hilos y los posibles momentos dentro de la distribución de la arquitectura.




Versión 0.1


Página 64 de 86

Ilustración 10. Vista de Procesos Fuente: UT Fonvivienda 2019, 2020

Inicialmente se tiene la posibilidad que se arranquen varias peticiones de parte del usuario final,

en la capa web a través de un browser. Dado lo anterior, nuestro Frontend, recibirá tantas

peticiones como usuarios finales ingresen o interactúen con el sistema, por consiguiente, podría

estar expuesto a una alta carga en un momento dado.

Desde el Frontend, las transacciones pueden ir hacia varios componentes según la necesidad de

atención de la petición. Se prevé que la transaccionalidad hacia el BPMs será menor que hacia

el bus de servicios. Podrán existir peticiones que lleguen al BPMs y se resuelvan o utilicen al bus

de servicios para ser resueltas, por lo tanto, se identifica la mayor carga a nivel de transacciones

o peticiones en el bus de servicios.

El bus de servicios puede recibir una petición y que esta se descomponga en varias peticiones

hacia la capa lógica de negocio. El bus es un sistema que soporta gran carga transaccional y está

preparado para ir hacia varias fuentes.

En nuestro caso específico, los microservicios recibirán las peticiones del bus de servicios y ejecutarán la lógica de negocio con la disponibilidad de la base de datos. Este componente suele ser el que más consuma en tiempo de procesamiento y se adiciona que va a tener IO con la base de datos. Finalmente, con las condiciones anteriores, se identifican el componente de Frontend como de

alta transaccionalidad y que por su naturaleza expone la capa de presentación. También el bus




Versión 0.1


Página 65 de 86

de servicio va a tener una alta carga transaccional, pero su naturaleza es la del manejo de

servicios de forma ágil, por último, el componente de negocio o microservicios tendrá que

responder a toda la transaccionalidad y persistir en la base datos utilizando la mayor capacidad

de procesamiento y consumo de recursos en el tiempo.

6.4 VISTA DE IMPLEMENTACION O COMPONENTES

La vista de implementación se representa con un diagrama de capas con sus respectivos componentes, la interrelación de cada uno de estos, su asignación de responsabilidades y los lineamientos por cada uno de ellos. La capa de presentación o Frontend, está conformada por un componente que constituye las vistas de una aplicación web. A esta capa se ingresa a través de un browser y las peticiones deben pasar por un firewall. El balanceador permite que esta capa sea susceptible de crecer horizontalmente y se puede comunicar con el gestor de procesos, pasando la información suficiente para que este siga con el flujo funcional. También se puede comunicar con el bus de servicios e incluso podría ir directamente a los microservicios. En determinado caso funcional donde el usuario final sea masivo, donde sean servicios directos al ciudadano, esta capa de presentación debe implementar el servicio y exponerlo como aplicación web, o por lo menos iniciar el proceso a través de una interface gráfica y pasar el control a las capas subyacentes. En esta capa también está lógicamente el componente de BI que permitirá la exposición de reportes, cuadros de control o lo que sea necesario para la lograr la explotación ellos datos, sobre una estructura de bodega de datos. Este componente se relaciona de forma directa con la estructura mencionada. La capa de integración o de servicios, está conformada por dos componentes principales. Primero se define el bus de servicios que se convierte en la columna vertebral de la arquitectura y que reside en esta capa, integrando la capa de presentación con la capa de negocio. El bus de servicio tiene la posibilidad de utilizar el componente X-ROAD para asegurar la interoperabilidad con entidades externas según estándares, sin limitar esta integración de forma directa y con seguridad propia. Como segundo componente, está el BMPs o gestor de procesos quien podrá exponer una interfaz gráfica para la exposición de servicios que representa una actividad dentro de un proceso de negocio o por el disparo de un evento, controlar el flujo de actividades del proceso. El gestor de procesos, para sus múltiples actividades, se apoyará en los servicios expuestos por el bus empresarial y sólo a través de este podrá tener relación con la capa de negocio.




Versión 0.1


Página 66 de 86




Versión 0.1


Página 67 de 86




Versión 0.1


Página 68 de 86

Ilustración 11. Vista de Componentes Fuente: UT Fonvivienda 2019, 2020

La capa de negocio o Backend está compuesta por un API REST, expuesta por microservicios que ejecutan la lógica de negocio necesaria. Los microservicios tienen la capacidad de ser escalados horizontalmente, por lo tanto, la capa debe estar balanceada y concretamente los servicios que estén expuestos. En esta capa se ubican lógicamente, el sistema de gestión documental y el motor de reglas que estarán dispuestos para la utilización por parte de los microservicios y de la capa de integración por parte del bus de servicios. La capa de persistencia está compuesta por la base de datos a la que se tiene acceso desde la capa de negocio o microservicios. Esta capa se modela dependiendo de las necesidades de los microservicios y se pretende que inicialmente este compuesta por una única instancia con estrategia de alta disponibilidad. También se encuentra en esta capa un componente de BI, en el cual se pretende tener una estructura o bodega de datos para la explotación de la información que llega desde la base de datos central.

6.4.1 Responsabilidad de los Componentes

A continuación, se describen los componentes principales desde la asignación de sus responsabilidades.

6.4.1.1 Componente de Presentación

Ilustración 12. Componente de Presentación




Versión 0.1


Página 69 de 86


El componente de presentación tiene la responsabilidad de exponer las vistas gráficas hacia los usuarios finales. Debe estar implementado en un framework cuya arquitectura de la aplicación sea de tipo híbrida, es decir, que permita la generación de versiones de esta para Android, IOS y PWA bajo la misma base de código fuente. Generalmente este código fuente tiene como base frameworks javascript como Angularjs, React o Vuejs, sin embargo, se puede proponer frameworks en otra tecnología que permita el despliegue multiplataforma. Este componente responderá a la mayor concurrencia cuando sea utilizado por la ciudadanía si se permite que se diligencien formularios y se impriman o en las consultas del estado de los procesos funcionales.

6.4.1.2 Sistema Gestor de Procesos

Ilustración 13. Sistema de Gestor de Procesos


Este componente tiene la responsabilidad de permitir la configuración de los procesos de negocio y por su naturaleza sólo tendrá responsabilidades de este tipo. Se identifica la necesidad de que en fase de construcción se haga el debido modelamiento de los procesos, asegurando la implementación del negocio. Este componente se encargará de dar flexibilidad al flujo de actividades, permitiendo la eliminación o adición de pasos o actividades en el flujo funcional. Se debe tener en cuenta que la estructura del proceso residirá en este componente y la implementación debe ser guiada por el modelamiento realizado en la disciplina de requerimientos. Aunque este componente tiene su propia base de datos, el dominio de datos del negocio, no se guardará en está. Se guardarán los datos relevantes o metadatos asociados al proceso y que permitan el monitoreo de las instancias de los procesos en tiempo real. Si es estrictamente necesario guardar datos de negocio, estos tendrán que enviarse hacia la base de datos centralizada, por ejemplo, donde coincida el estado de una actividad con el estado de una entidad de negocio.




Versión 0.1


Página 70 de 86

El componente podrá exponer interfaz gráfica para los usuarios internos, tratando de que las funcionalidades que implemente, no sean altamente transaccionales y correspondan al paso a paso de un flujo de actividades donde hay intervención humana.

6.4.1.3 Bus de Servicio Empresarial

Ilustración 14. Componente Bus Empresarial


El bus de servicios empresarial es la pieza central del diseño de la arquitectura del sistema TERRA. Pretende generar desacoplamiento entre las capas y componentes, comportándose como un interlocutor desde la capa de presentación, hacia el backend. El bus tiene la responsabilidad de exponer los servicios de los microservicios, facilitando su reúso y exposición. Se sugiere utilizar el patrón API Gateway para el tratamiento del consumo indirecto de los servicios de la capa de negocio. La composición de servicios será una responsabilidad del bus, con la cual se debe definir la granularidad de los servicios y su beneficio hacia las capas superiores y el componente gestor de procesos. A través de este componente, se tendrá acceso o se logrará la integración con el sistema de gestión documental y el LDAP. Los servicios de seguridad de autenticación se expondrán desde el componente y a partir de esta implementación, se asegurarán los servicios de la capa de negocio. El bus también se puede utilizar para la comunicación entre microservicios si se hace necesario el desacoplamiento y para mantener un orden de consumo. La integración con entidades externas será responsabilidad del componente y se da la posibilidad de que otros sistemas del Ministerio también puedan integrarse logrando beneficios a nivel de negocio. El aseguramiento de los servicios de integración se dará por el bus y se podrá aprovechar las características de monitoreo y logs que este provee. Este componente debe generar flexibilidad en cuanto a la modificación de los servicios compuestos y la generación de un orden a través de la orquestación, la administración de las transacciones y mapeo de servicios.




Versión 0.1


Página 71 de 86

Adicionalmente el bus tendrá la responsabilidad de manejar comunicación asíncrona, donde a

través de una cola de mensajes, los subscriptores puedan consumirlos y generar la lógica

deseada en la capa de negocio.

6.4.1.4 Microservicios

Ilustración 15. Componente de Microservicios

Fuente: UT Fonvivienda 2019, 2020 El componente de microservicios representa la capa de negocio o backend y tiene la responsabilidad de implementar la lógica de negocio. Estos microservicios tienen características de aislamiento y exponen servicios REST. La implementación de la lógica de negocio se sugiere sea orientada a objetos y por esto el modelo de datos está representado a nivel de clases. Durante la codificación de la lógica de negocio, se debe utilizar el motor de reglas para la implementación de las reglas de negocio y así poder abstraer en algún nivel las reglas de la codificación y también se da la posibilidad de la implementación de reglas de negocio con alto nivel de dificultad. Los microservicios deben utilizar el principio de la abstracción, ser cohesivos y altamente desacoplados, para que puedan reflejar el negocio y ser flexibles ante nuevos requerimientos y modificaciones de lo existente. Los microservicios conforman el backend y por ser consumidor de recursos y tener el mayor procesamiento en el tiempo, se deberá poder escalar horizontalmente para cumplir necesidades puntuales o especificas a nivel de concurrencia o procesamiento. Este componente tendrá la responsabilidad de la persistencia y la administración de los datos gestionando el acceso a la base de datos centralizada. Al utilizar el paradigma de orientación a




Versión 0.1


Página 72 de 86

objetos, se debe garantizar que la persistencia según el modelo de datos corresponda a las entidades del negocio.

6.4.1.5 Base de datos

Ilustración 16. Componente Base de Datos

Fuente: UT Fonvivienda 2019, 2020 La base de datos centralizará toda la información del sistema TERRA, deberá contar con una estrategia de alta disponibilidad y responder a las necesidades transaccionales, para la cual se considera un clúster. La base de datos es de tipo relacional y a través del paso y transformación de los datos, se abastecerá una estructura de BI para ser explotada. De esta forma la base de datos será totalmente transaccional y la explotación de datos se realizará en otra instancia con otra estructura de datos.

6.4.1.6 BI

Para la explotación de datos, se plantea un componente de BI, el cual está constituido por una capa de presentación donde se implementarán los reportes o necesidades de exploración de la información y una estructura de bodega de datos para liberar a la base de datos transaccional de cargas que no sean responsabilidad de ella.




Versión 0.1


Página 73 de 86

Ilustración 17. Componentes de BI.

Fuente: UT Fonvivienda 2019, 2020 Los datos que se reciban en la base de datos centralizada deben ser trasladados a la estructura de las bodegas de datos haciéndose las transformaciones necesarias para que alimente de forma correcta la bodega.

6.5 VISTA DE DESPLIEGUE

A través de esta vista se realiza la abstracción a nivel de componentes de software, de los nodos necesarios para el despliegue de TERRA.




Versión 0.1


Página 74 de 86

Ilustración 18. Diagrama de Despliegue

Fuente: UT Fonvivienda 2019, 2020 Se identifican los diferentes componentes cada uno con su estrategia de alta disponibilidad, a través de la implementación de 2 nodos por cada componente. Se determina también la utilización de un firewall y balanceadores para el crecimiento horizontal. Comentado [JL1]: @John Carlos Cardenas por favor

revisar que falta el componente de presentación en SAD de TERRA

mailto:[email protected]




Versión 0.1


Página 75 de 86

6.6 VISTA DE INFRAESTRUCTURA

En esta vista se define los requisitos de diseño de infraestructura básicos para desplegar el SISFV. A nivel de diseño contempla las siguientes características:

Ilustración 19. Diagrama diseño de infraestructura.





Versión 0.1


Página 76 de 86

Escalabilidad Horizontal: Se estima que la carga de trabajo puede aumentar en el tiempo a un volumen con el que desplegar los servicios en máquinas individuales se vuelve inviable, por costos o disponibilidad de hardware, por esta razón desde la arquitectura de software e infraestructura se usan las mejores prácticas del mercado para promover crecimiento virtualmente infinito, añadiendo pequeñas máquinas a medida que la operación demande más poder de cómputo. Tolerancia a Fallos: Ningún elemento del sistema individualmente, por ejemplo, un servidor de aplicaciones o un servidor de bases de datos debe ser capaz de detener la operación por un fallo en su operación, a esto llamamos un Single Point of Failure. El presente diseño evita que cualquier componente se vuelva tan crítico como para que sea capaz de detener la plataforma si llega a fallar. Balanceo de Cargas: En algunos casos, las cargas de trabajo se procesan con mejor desempeño si estas se dividen entre varios servidores, sobre todo cuando hay un potencial de centenas de miles de peticiones concurrentes en procesamiento, ya que según el sistema operativo, puede llegar a existir límites de cantidad de hilos o procesos por usuario y estos límites tienen su razón de ser, la cantidad de núcleos de procesador disponibles en un único sistema puede influir en la capacidad de dicho sistema para procesar miles de hilos concurrentemente y esta cantidad de núcleos físicos tiene un límite que se delimita por la tecnología disponible en el mercado y por el costo de procesadores con más de 12 núcleos, por esta razón consideramos el balanceo de cargas como una característica de diseño imprescindible para garantizar una operación fluida de los aplicativos desplegados con un costo que represente de forma justa el valor generado. Recuperación ante Desastres: El presente diseño no incluye un plan de recuperación ante desastres, pero contempla la posibilidad de implementarlo sin muchos pasos adicionales. En la descripción de la vista se encuentra un apartado para dejar el camino claramente delineado. Redes de Datos Tolerantes a Fallos: El presente diseño incluye las características mínimas de diseño de la red hasta capa de red, pasando por L1 tipos de enlaces recomendados, L2 redundancia y tolerancia a fallos y L3 enrutamiento entre VLANs. En el diseño se propone el uso de una VLAN con su bloque IP para cada clúster, esto permitirá una administración más intuitiva y un control de acceso más predecible y nemotécnico por parte de los ingenieros que interactúan con los sistemas para administración de despliegues y escalado en máquinas de cada clúster. Por supuesto también es viable mantener una única VLAN para todos los servidores en todos los clústeres, pero creemos que dificultará la administración para los encargados del manejo del software. También existirá una VLAN para el curso del tráfico de almacenamiento desde el clúster de almacenamiento hasta los servidores de aplicaciones que procesan negocio y que necesitan




Versión 0.1


Página 77 de 86

tener un sistema de archivos común para documentos y otros archivos, esta red se propone como una única VLAN accesible desde los servidores virtuales, en este caso no se propone una VLAN por cada clúster, pero si es importante evitar mezclar el tráfico de datos de aplicaciones con el tráfico de almacenamiento, para evitar cuellos de botella, por esta razón no se optó por la filosofía de red convergente, para evitar que un error de configuración de calidad de servicio afecte el desempeño del sistema y además para evitar compartir interfaces de red de datos de aplicación y almacenamiento. Para las definiciones de la vista, asumimos el uso del esquema propuesto con una VLAN por clúster. Recuperación Ante Desastres: En caso de querer desplegar una solución de recuperación ante desastres, todos los servidores deberán ser máquinas virtuales y todos los hipervisor deberán contar con acceso a la VLAN del clúster de almacenamiento en un EtherChannel independiente del tráfico de datos de aplicación y sistema de archivos compartido para obtener acceso IP independiente y completo al clúster de almacenamiento y así usar unidades Block Storage del clúster de almacenamiento para las máquinas virtuales. Licenciamiento de Herramientas Propuestas: Todas las herramientas propuestas en esta vista cuentan con versión OpenSource de acceso libre sin costo para entornos en producción, algunas son un estándar de factor en la industria como lo son: Apache HTTP Server, NGINX, HA Proxy, Ceph, etc. Clústeres: Para el despliegue de las aplicaciones se requiere una serie de subsistemas o clústeres con funciones independientes pero que interactúan con el resto de los clústeres. A continuación, se listan dichos subsistemas que han sido descritos en las vistas anteriores:

• Clúster de Almacenamiento

• Clúster del Firewall

• Clúster de Servidores WEB

• Clúster de Bases de Datos

• Clúster de Microservicios

• Clúster BPM

• Clúster ESB

• Clúster de Reportería




Versión 0.1


Página 78 de 86

6.6.1 Clúster de Servidores WEB

Ilustración 20. Clúster de Servidores WEB

Fuente: UT Fonvivienda 2019, 2020 Este clúster cuenta con dos elementos, el balanceador y los nodos HTTP. Los balanceadores constan de dos servidores de balanceo, se sugiere HA Proxy por su flexibilidad para balancear tráfico HTTP con estrategias como round robín y leastconn, así como el balanceo basado en condiciones de URI. Los nodos HTTP serán servidores HTTP, se sugiere el uso de Apache HTTP Server o NGINX. Se sugiere que los archivos de configuración, tanto de los balanceadores como de los nodos HTTP, así como el contenido estático estén en el sistema de archivos compartidos del clúster de almacenamiento para replicar los cambios en todos los nodos de forma ágil y evitar problemas por la falta de consistencia en la configuración o el contenido.




Versión 0.1


Página 79 de 86

6.6.2 Clúster de Base de Datos

El Ministerio de Vivienda cuenta con un cluster RAC de Oracle y un ambiente productivo SQL Server stand alone en proceso de análisis e implementación de AlwaysOn. Se debe analizar la necesidad de la implementación de clúster activo-activo que permita la exposición de un puerto para dirigir las sentencias transaccionales a los dos nodos dispuestos para transacción y otro puerto para dirigir las sentencias al nodo dispuesto para reportería. El uso de la capa de aplicación/servicios/integración debe contemplar el uso de alguno de estos dos motores de base de datos en un esquema de alta disponibilidad. De igual forma y alineado con el diseño, el uso de la bodega de datos tiene como fin la construcción de los modelos requeridos y de datamarts para el uso y aprovechamiento de los datos por medio de la plataforma de BI de la entidad.

6.6.3 Clúster de Microservicios, ESB, BPM

Estos cuatro clústeres tienen mucho en común: todos proporcionan sus servicios por medio de interfaz HTTP o TCP. Todos deben poder ver en todos sus nodos, el sistema de archivos compartidos del sistema. Todos balancean su carga a través de un balanceador como HA Proxy. En todos, el esquema de balanceo funciona perfecto ya que se distribuirán peticiones sin sesión. En los tres casos se desplegará dos balanceadores en clúster activo/pasivo; se recomienda HA Proxy para lograrlo, cada nodo tendrá sus servidores de aplicaciones y tendrá montado los sistemas de archivos compartidos del clúster de almacenamiento para archivos de configuración, despliegues y documentos de la operación.




Versión 0.1


Página 80 de 86

Ilustración 21. Clúster de Microservicios

Fuente: UT Fonvivienda 2019, 2020 En los nodos del clúster se desplegará el servidor de aplicaciones de su preferencia para los microservicios, pueden ser HTTP o TCP (caso WebSockets)




Versión 0.1


Página 81 de 86

Ilustración 22. Clúster ESB Fuente: UT Fonvivienda 2019, 2020

En los nodos del clúster se desplegará el servidor de aplicaciones de su preferencia o el que requiera el proveedor de Enterprise Service Bus que se use.

Ilustración 23. Clúster BPM

Fuente: UT Fonvivienda 2019, 2020 En los nodos del clúster se desplegará el servidor de aplicaciones de su preferencia o el que requiera el proveedor de motor de reglas de negocio que se use.




Versión 0.1


Página 82 de 86

Ilustración 24. Clúster de Reportería


En los nodos del clúster se desplegará el servidor de reportería que se desee, solo debe tenerse en cuenta la compatibilidad del sistema de archivos compartido en caso de necesitarse para este clúster. Adicional a lo anterior, se debe considerar que la entidad actualmente cuenta con el motor de procesos Bizagi (BPMS), el cual está desplegado en una máquina virtual sobre un cluster de Vmware, es decir aprovecha las características de alta disponibilidad de la capa de virtualización, a nivel de la capa de aplicación/procesos no se cuenta con un mecanismo de HA. Para el caso de los microservicios se debe contemplar la posibilidad del despliegue en la plataforma de orquestación de contenedores al igual que el caso del ESB y el BRMS.

6.6.4 Dimensionamiento Base

A continuación, se presenta el listado de servidores con la definición de los recursos necesarios para soportar las necesidades de TERRA, en un contexto de alto nivel que pretende dar una visión sobre las necesidades de infraestructura. Las siguientes cifras se definieron y se estimaron en reuniones con el negocio para poder tener cifras derivadas de las necesidades del negocio y que representan un escenario posible sobre la futura utilización del sistema.




Versión 0.1


Página 83 de 86

Ilustración 25. Cifras para Solicitud de licencias.

Fuente: UT Fonvivienda 2019, 2020 Las cifras anteriores se obtienen en relación con las posibles solicitudes de licencias urbanísticas. Se determina número de usuarios para los entes territoriales, curadurías, vecinos y otros. Adicionalmente se estima un número de solicitudes por año que implican la utilización por parte de los constructores de la funcionalidad.

7 CONCLUSIONES

El diseño de arquitectura para TERRA contiene aspectos derivados de la arquitectura de referencia, como la orientación a servicios. Los componentes definidos permitirán a futuro evolucionar hacia una arquitectura SOA. Es importante que el modelamiento de los procesos en fase de implementación en el gestor de procesos sea consciente de las capacidades de los componentes y por lo tanto de las capas de software y sus responsabilidades.

Número de usuarios x año




Versión 0.1


Página 84 de 86

Es una arquitectura altamente distribuida, en la cual se debe prestar atención a cada uno de los componentes, por tener más puntos potenciales de falla. Del mismo modo genera beneficios en cuanto a la tolerancia a fallos y la correcta separación de responsabilidades. El bus de servicios genera un desacoplamiento entre capas y aunque se convierte en un punto de alta transaccionalidad, permite la abstracción y dependencia entre componentes, su utilización y exposición de funciones. Los microservicios, aunque no tienen aislamiento a nivel de la persistencia, pueden a futuro implementarlo, teniendo en cuenta el comportamiento en producción y las necesidades del negocio en determinadas funcionalidades. La identificación del comportamiento de los microservicios permitirá el refactor de estos para poder escalar o dar más recursos. El diseño de la arquitectura planteada es producto de las posibilidades de utilización, y en cuanto a carga se identifica un número de usuarios potenciales dados por la ciudadanía, esto hace que el sistema deba desde el comienzo estar preparado para su operación en circunstancias de alta concurrencia. De acuerdo con las definiciones y modelamiento representado en las vistas 4+1 y en sí la solución arquitectónica y el alineamiento con la directriz presidencial 03 del 15 de marzo de 202125, para los lineamientos en el uso de servicios en la nube, inteligencia artificial, seguridad digital y gestión de datos, se plantean las siguientes recomendaciones para la implementación de la arquitectura del SISFV como resultado del presente proyecto:

• Se deben tener en cuenta que los lineamientos de transformación Digital en el estado colombiano, exige a las entidades generar un valor público, entre otros con la adopción de tecnologías que permitan responder de forma rápida y efectiva a las necesidades de los usuarios o grupos de interés, mediante productos digitales. La transformación digital ha afectado significativamente la manera en que las entidades del estado colombiano entregan activos, procurando que la implementación de cambios en sus productos y servicios, sean ágiles.

• Al analizar el modelo de operación que habilita la gestión de la política de vivienda del

MVCT donde los procesos del negocio y niveles subsecuentes deberán estar orquestados de forma ordenada, integrada y lógica, teniendo en cuenta la necesidad del negocio de adoptar los principios de flexibilidad, escalabilidad, disponibilidad y seguridad en la implementación de sus procesos, según lo expuesto en el diseño de la solución arquitectónica para facilitar el desarrollo e implementación de funcionalidades independientes y modulares; que al integrarlas permitan llevar a cabo las mismas actividades y misionalidad de cada proceso, así mismo, que faciliten la implementación

25 https://dapre.presidencia.gov.co/normativa/normativa/DIRECTIVA%20PRESIDENCIAL%2003%20DEL%2015%20DE%20MARZO%20DE%202021.pdf




Versión 0.1


Página 85 de 86

de cambios requeridos en los procesos de forma ágil, reduciendo el riesgo de afectar todo el negocio por la falla o modificación de algún componente.

• Se debe responder oportunamente a los requerimientos normativos, políticos y sociales,

permitiendo que la entidad cuente con la capacidad de desplegar con rapidez la actualización o implementación de nuevos procesos soportados por el sistema como parte de su evolución hacia la transformación digital, haciendo uso de los microservicios conceptualmente definidos que dividan funcionalidades o retos complejos en componentes organizados, desacoplados, con funciones delimitadas y cohesivas, con una implementación, modificación y escalamiento ágil e independiente, que en conjunto ejecuten la lógica del negocio y que además faciliten la integración de los procesos con otros sistemas de información a futuro.

• Soportando en el resultado del diseño de la arquitectura de solución, se plantea sobre las

diferentes vistas de “El Sistema de Información Transaccional (Terra)”, la recomendación que en la fase de implementación se apliquen el concepto emergente de “aplicaciones modernas”, las cuales permitirá implementar una arquitectura de componentes implementados con:

- Componentes escalables que aumentan sus capacidades y respuesta en la medida

de las necesidades, optimizando los recursos de inversión bajo el modelo de pago por uso y capacidad.

- Flexibilidad entendida como la capacidad que los diferentes artefactos de software,

implementados en microservicios, puedan adaptarse a tecnologías híbridas, además de disminuir sus capacidades de procesamiento y el uso de recursos, en la medida de las necesidades y comportamiento del SISFV en producción.

- Disponibilidad: alta disponibilidad de operación, que, en una arquitectura de

microservicios, serán administrado por el proveedor tecnológico, generando en cuanto a la descarga de los costos y requerimiento operaciones de infraestructura y soporte.

- Seguridad, a través de microservicios de gestión de acceso y usuarios, la seguridad y

gestión de esta, crea una organización de fácil administración para la Entidad en la operación de los sistemas de información. De otra parte, las arquitecturas de microservicios tienen un gran impacto en la Entidad sobre el cómo almacena y administran datos. De esta forma las aplicaciones modernas se crean con almacenes de datos desacoplados y cada uno de ellos forma parte de un solo microservicio.

• Sobre la anterior recomendación, cabe resaltar que la implementación de sistemas de información basada en el concepto de aplicaciones modernas, se logran bajo los ecosistemas de microservicios, los cuales cumplen con estos beneficios a través de los hoy grandes proveedores tecnológicos como son: Microsoft Azure, Amazon – AWS, IBM, Cloud – Google y Alibaba-Cloud, de los cuales hoy ofrecen estas tecnologías y conceptos




Versión 0.1


Página 86 de 86

a través de los acuerdos marco de precios de Colombia Compra eficiente. Para concluir, la Implementación de “El Sistema de Información Transaccional (Terra)”, bajo el concepto de “aplicaciones modernas” soportada sobre microservicios en la nube, le permitirá a la Entidad contar con Sistema de información altamente eficiente, flexible, escalable, seguro y con un alto costo/beneficio.

Documents

DOCUMENTO DE ARQUITECTURA DE SOFTWARE SISTEMA DE …