Contrato No. 001 de 2019 – Arquitectura Empresarial

DOCUMENTO DE ARQUITECTURA DE SOFTWARE SISTEMA DE SUBSIDIO FAMILIAR DE VIVIENDA SISFV

Mayo de 2021 BOGOTÁ D.C. - COLOMBIA

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

CONTROL DE CAMBIOS

FECHA

VERSIÓN

DESCRIPCIÓN DEL CAMBIO

RESPONSABLE

23/03/2021

0.1

Versión inicial del documento

UT FONVIVIENDA 2019

8/04/2021

0.2

Atención a comentarios.

UT FONVIVIENDA 2019

19/04/2021

0.3

Atención a comentarios.

UT FONVIVIENDA 2019

29/04/2021

0.4

Atención a comentarios.

UT FONVIVIENDA 2019

19/05/2021

0.5

Atención a comentarios.

UT FONVIVIENDA 2019

20/05/2021

1.0

Versión aprobada

UT FONVIVIENDA 2019

REFERENCIAS CONTRACTUALES DEL ENTREGABLE:

Según contrato: Documento con la arquitectura de solución del SISFV 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	UT FONVIVIENDA 2019	Consultoría
Revisó	Xxxxxxx Xxxxxxxx	Gerente de Proyecto Interventoría
Aprobó	Xxxxxx Xxxxxxxxx	Supervisor FONVIVIENDA para el contrato 01 de 2019 Fiduciaria de Occidente y UT FONVIVIENDA 2019

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

TABLA DE CONTENIDO

Pág.

1 PRESENTACIÓN DEL DOCUMENTO

85

LISTADO DE TABLAS

Pág.

Tabla 1. Definiciones 15

Tabla 2. Atributo de calidad Eficiencia de Desempeño 23

Tabla 3. Atributo de calidad Seguridad 25

Tabla 4. Atributo de calidad Fiabilidad 26

Tabla 5. Atributo de calidad Compatibilidad 26

Tabla 6. Atributo de calidad Usabilidad 27

Tabla 7. Atributo de calidad Adecuación Funcional 28

Tabla 8. Atributo de calidad Mantenibilidad 29

Tabla 9. Dimensionamiento base opción 1 96

Tabla 10. Dimensionamiento base opción 2 97

LISTADO DE ILUSTRACIONES

Pág.

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

Ilustración 2. Referencias documentales 15

Ilustración 3. Modelo de calidad ISO 25010 21

Ilustración 4. Árbol de utilidad 30

Ilustración 5. Diagrama de casos de uso Asignación de Subsidios 59

Ilustración 6. Diagrama de casos de uso Transversales 60

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

Ilustración 8. Vista lógica o Contextual 63

Ilustración 9. Zona de usuarios. 64

Ilustración 10. Integración e Interoperabilidad 65

Ilustración 11. Aplicación web, microservicios 65

Ilustración 12. Base de datos y Data Mart 66

Ilustración 13. Vista de Procesos 67

Ilustración 14. Vista de Componentes 71

Ilustración 15. Componente de Presentación 71

Ilustración 16. Sistema Gestor de Procesos 72

Ilustración 17. Componente Bus Empresarial 73

Ilustración 18. Componente de Microservicios 74

Ilustración 19. Componente Base de Datos 75

Ilustración 20. Componentes de BI 76

Ilustración 21. Diagrama de Despliegue 78

Ilustración 22. Diagrama diseño de infraestructura 80

Ilustración 23. Cluster de Almacenamiento 83

Ilustración 24. Cluster de Firewall 84

Ilustración 25. Clúster de Servidores WEB 79

Ilustración 26. Clúster de base de datos 87

Ilustración 27. Clúster de Microservicios 81

Ilustración 28.Cluster ESB 82

Ilustración 29. Clúster BPM 83

Ilustración 30. Consideraciones de Red 93

Ilustración 31. Cifras para postulaciones. 84

Ilustración 32. Cifras para Solicitud de licencias. 85

Ilustración 33. Diagrama de Datos Elegibilidad de proyectos 98

Ilustración 34. Diagrama de Datos Incumplimientos 99

Ilustración 35. Diagrama de Datos Oferentes 100

Ilustración 36. Diagrama de Datos PostVenta 101

Ilustración 37. Diagrama de Datos Promoción y Acompañamiento 102

Ilustración 38. de Datos Supervisión y Seguimiento a PV 103

Ilustración 39. Diagrama de Datos Asignación de Subsidio 104

Ilustración 40. Diagrama de Datos Asignación de Vivienda Rural 105

Ilustración 41. Diagrama de Datos Autorización Abono CAP 106

Ilustración 42. Diagrama de Datos Autorización Cuenta CAP 107

Ilustración 43. diagrama de Datos Distribución de Recursos SFV 108

Ilustración 44. Diagrama de Datos Movilización SFV 109

Ilustración 45. Diagrama de Datos Pago SFV MCY 110

Ilustración 46. Diagrama de Datos Proceso fiduciario 111

Ilustración 47. Diagrama de Datos Cancelación gravámenes 112

Ilustración 48. Vista de Datos Cesión bienes vocación público 113

Ilustración 49. Vista de Datos Cesión título gratuito 114

Ilustración 50. Vista de Datos Enajenación bienes ocupados por instituciones religiosas 115

Ilustración 51. Vista de Datos Identificación bienes inmuebles 116

Ilustración 52. Vista de Datos Promoción y acompañamiento titulación 117

Ilustración 53. Vista de Datos Transferencia de dominio bienes inmuebles 118

Ilustración 54. Vista de Datos Licencias Urbanísticas 119

1 PRESENTACIÓN DEL DOCUMENTO ‌

El presente documento es el principal artefacto dentro de la solución arquitectónica del sistema. Determina, 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.

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

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 y entidades, mostrando inicialmente las entidades persistentes de forma individual o agrupada.

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 por 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 interesado 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, como el sistema será ubicado en la arquitectura de red y lineamientos del área de TI. En general cualquier stakeholder 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 stakeholders principales son los analistas de requerimientos y en general los dueños de la funcionalidad o quien necesite referirse a las necesidades de la implementación funcional.

2 INTRODUCCIÓ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 vivienda2.

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 subsidio familiar de vivienda SISFV.

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 las razones con que se cumplen las necesidades del SISFV.

2.2. Alcance ‌

El alcance del documento está definido por el tratamiento y solución de los requerimientos funcionales y no funcionales. La solución es generada utilizando un nivel de abstracción de estructuras arquitectónicas de forma clásica. 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 SISFV y ser utilizado por roles como arquitecto, 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 vistas arquitectónicas 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 vistas arquitectónicas constituye la solución final, complementándose entre ellas.

2.3. Definiciones, Acrónimos y Abreviaturas ‌

2 Modelo de análisis. MVCT – Modelo de Análisis.docx – UT FONVIVIENDA 2019.

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, xxxxxx 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

Xxx xxxxxx: 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 2000, en una tesis doctoral sobre la web escrita por Xxx Xxxxxxxx, uno de los

principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

3 Modelo de vistas 4+1. xxxxx://xxx.xx.xxx.xx/xxxxxxx/xxxxxxxx/xxxxxx/0x0xxxx-xxxxxxxxxxxx.xxx.

4 ISO/IEC 25010. xxxxx://xxx00000.xxx/xxxxx.xxx/xxxxxx-xxx-00000/xxx-00000

5 ATAM - xxxxx://xxxxxxxxx.xxx.xxx.xxx/xxxxxxx/xxxxx-xxxx.xxx?xxxxxxxx000000.

TÉRMINO

DESCRIPCIÓN

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.

TÉRMINO	DESCRIPCIÓN
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).
Xxxxx 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 Xxxxx de interoperabilidad MinTIC xxxx://xxxxxxxx.xxxxxx.xxx.xx/xxxxx-xx-xxxxxxxxxxxxxxxxx

7 Xxxxx de transformación digital MinTIC xxxxx://xxx.xxxxxx.xxx.xx/xxxxxx/xxxxxx/Xxxx-xx-Xxxxxx/Xxxxxxxx/000000:XxxXXX-xxxxxxx-xx- Marco-de-Transformacion-Digital-para-mejorar-la-relacion-Estado-ciudadano

8 Modelo de arquitectura empresarial MAE xxxxx://xxx.xxxxxx.xxx.xx/xxxxxxxxxxxxxx/000/x0-xxxxxxxxxxxxx-0000.xxxx

TÉRMINO	DESCRIPCIÓN
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

SISFV-GLOS-TRAN_Glosario.xlsx

Catálogo de actores

SISFV-CACT-TRAN_CatalogoActores.xlsx

Modelo de análisis

MVCT – Modelo de Análisis.docx

Arquitectura de referencia

Arquitectura Referencia.docx

SAW

SAW FONVIVIENDA.docx

ADD

Documento ADD.docx

Ilustración 2. Referencias documentales

Fuente: UT Fonvivienda 2019, 2021

2.5. Panorama ‌

El presente documento hace referencia al modelo de análisis para utilizar las definiciones y modelamiento realizado a los requerimientos funcionales.

Se realiza en el presente documento 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 stakeholders.

A continuación, se describen los motivadores arquitecturales y se describen los atributos de calidad con sus escenarios, que guiarán las decisiones durante la descripción de la solución arquitectónica.

Las vistas arquitectónicas serán diagramadas de la siguiente forma:

• 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 Subsidio Familiar de Vivienda. Este apartado permite resumir de forma técnica las condiciones sobre las cuales se realiza el modelamiento de la solución y se debe tener en cuenta las directrices de las definiciones de la Arquitectura Empresarial.

3.1. Metas ‌

• Diseñar la arquitectura para el Sistema de Información del Subsidio Familiar de Vivienda (SISFV) en sus componentes de oferta y demanda para vivienda urbana y rural en los sectores público y privado incluyendo los procesos que lo soportan9.

• Proveer un sistema de información acorde con las necesidades de FONVIVIENDA para soportar los requerimientos funcionales modelados a través del análisis y especificación de casos de uso10.

• Mantener los datos e información del sistema centralizada, evitando duplicación de datos o entidades entre repositorios o subsistemas. Logrando 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 del SISFV, para establecer un domino de información.

• 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 o ciudadanía.

• Asegurar que el SISFV 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 del SISFV.

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

• 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 el SISFV,

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, SWA FONVIVIENDA.docx

12 Arquitectura de datos – Literal 4.2, SWA FONVIVIENDA.docx

13 Arquitectura de negocio – Literal 4.1, SWA FONVIVIENDA.docx

entregando servicios digitales a los ciudadanos, empresas y a otras entidades14.

• Estandarizar el manejo de la documentación del SISFV, a través de la exposición de servicios únicos y la utilización de un componente tecnológico que permita el correcto guardado y custodia documental15.

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 ejercicio y principios que rigen la arquitectura16.

• Capacidades no soportadas por Ministerio y que deban ser resueltas para la viabilidad del proyecto. Estas capacidades se presentan 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 a nivel de infraestructura, está delimitado por lo encontrado y planteado en la arquitectura empresarial. El diseño de la arquitectura del SISFV genera bases en cuanto a necesidades y lineamientos, pero no se limita en este sentido17.

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

14 Estrategia de integración e intercambio de información para el SISFV – Marco Referencia Integración e Intercambio de Información.docx

15 Arquitectura de aplicaciones – Literal 4.3, SWA FONVIVIENDA.docx

16 Arquitectura de referencia MCVT – Arquitectura referencia.docx

17 Arquitectura de tecnología – Catálogo de Componentes físicos de tecnología – Documento ADD.docx

18 Arquitectura de Sistemas de Información – SISFV – Documento ADD.docx

4 MOTIVADORES ARQUITECTURALES ‌

4.1. Motivadores de Negocio ‌

Los motivadores de negocio que se presentan, son beneficios concretos que el SISFV pretende generar a los procesos y operación en la administración del subsidio familiar de vivienda. Estos motivadores entran en relación directa con la funcionalidad identificada o vista de casos de uso y también pueden tener relación con los requerimientos no funcionales.

Los motivadores de negocio, tienen como intención un futuro cumplimiento de la solución en producción y basados en el resultado de la aplicación, se puede trazar un roadmap o actividades de mantenimiento y estabilización del sistema cuando se encuentre en fase de monitoreo y mantenimiento de software.

A continuación, se presenta un resumen de los principales motivadores de negocio, descritos en el documento SAW de la Arquitectura Empresarial. De igual forma, el desarrollo del dominio de negocio19, presenta el contexto completo de los motivadores y es complemento estratégico y funcional20 para lo definido en el SAW.

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: considera 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 xx xxxx 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

19 Arquitectura de Negocio – SISFV – Documento ADD.docx

20 Motivadores de negocio – SAW FONVIVIENDA.docx

MOTIVADOR

DESCRIPCIÓN

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.

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

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.docx21, 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 2501022.

Ilustración 3. Modelo de calidad ISO 25010

Fuente: xxxxx://xxx00000.xxx/xxxxx.xxx/xxxxxx-xxx-00000/xxx-00000

Para el SISFV, se definen los siguientes atributos de calidad para tener en cuenta:

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

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

▪ Fiabilidad: Capacidad de un sistema o componente para desempeñar las funciones especificadas, cuando se usa bajo unas condiciones y periodo de tiempo determinados.

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

21 5.2 REQUERIMIENTOS NO FUNCIONALES – Documento MVCT – Modelo de Análisis. UTFONVIVIENDA 2019.

22 xxxxx://xxx00000.xxx/xxxxx.xxx/xxxxxx-xxx-00000/xxx-00000

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

▪ Mantenibilidad: Este atributo representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas.

5.1. Árbol 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 los 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 define según el estándar de la ISO, su utilidad y/o consideración dentro del contexto del SISFV.

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. Eficiencia de Desempeño ‌

La eficiencia de desempeño, para el caso de nuestro modelamiento de la solución del sistema y análisis está dado 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 relevante dentro de la definición del futuro comportamiento requerido del sistema.

Para el SISFV se estimaron cifras o volumetrías con respecto a los usuarios concurrentes o activos y capacidades como ejecución de validaciones y persistencia.

Comportamiento temporal: Los tiempos de respuesta, procesamiento y los ratios de tráfico (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 determinadas funcionalidades o condiciones de utilización.

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

Característica

ID-RNF

Descripción

Prioridad

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 2. Atributo de calidad Eficiencia de Desempeño.

Fuente: UT Fonvivienda 2019, 2020

5.1.2. Seguridad ‌

A esta característica se le dará mayor énfasis para el modelamiento de la solución, de manera que se utilizarán 4 de sus sub-características.

Autenticidad: Capacidad de demostrar la identidad de un sujeto o un recurso. Es importante para el SISFV 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 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.

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 accidental o deliberadamente.

En esta sub-característica, se contempla 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.

La siguiente tabla describe para Seguridad sus sub-características y los requerimientos no funcionales relacionados.

Atributo de Calidad

Seguridad

Característica

ID-RNF

Descripción

Prioridad

Autenticidad

NFR-2

Los usuarios deben autenticarse y autorizarse ante el sistema con o sin registro previo y aprobación del MCVT,

Alta

		dependiendo de su rol, para poder acceder a sus funcionalidades y tener permisos solo a lo que se determine.
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
Confidencialidad	NFR-16	El sistema debe cumplir con la normatividad y políticas vigentes, definidas por MINTIC.	Alta

Tabla 3. Atributo de calidad Seguridad.

Fuente: UT Fonvivienda 2019, 2020

5.1.3. Fiabilidad ‌

En lo referente a 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 operando 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 el levantamiento de información. 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 igual forma en la vista de despliegue, se presenta una topología 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

Característica

ID-RNF

Descripción

Prioridad

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 4. Atributo de calidad Fiabilidad.

Fuente: UT Fonvivienda 2019, 2020

5.1.4. Compatibilidad ‌

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

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, donde la solución debe exponer diferentes interfaces.

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

Característica

ID-RNF

Descripción

Prioridad

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 5. Atributo de calidad Compatibilidad.

Fuente: UT Fonvivienda 2019, 2020

5.1.5. Usabilidad ‌

Para el atributo de Usabilidad se consideran dos sub-características.

Protección contra errores de usuario: Capacidad del sistema para proteger a los usuarios de hacer errores. Cuando se ingresen datos al sistema por parte del usuario y se obtenga como resultado un error, se presentará un mensaje formateado, explicando el error y la posible solución.

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.

Atributo de Calidad

Usabilidad

Característica

ID-RNF

Descripción

Prioridad

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 6. Atributo de calidad Usabilidad.

Fuente: UT Fonvivienda 2019, 2020

5.1.6. 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 estipulado por las condiciones de la ley por la cual se rigen los procesos funcionales.

Pertinencia Funcional: Capacidad del producto de 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.

La siguiente tabla describe para la Adecuación Funcional sus sub-características y los requerimientos no funcionales relacionados.

Atributo de Calidad

Adecuación Funcional

Característica

ID-RNF

Descripción

Prioridad

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 7. Atributo de calidad Adecuación Funcional.

Fuente: UT Fonvivienda 2019, 2020

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.

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.

La siguiente tabla describe para Mantenibilidad sus sub-características y los requerimientos no funcionales relacionados.

Atributo de Calidad

Mantenibilidad

Característica

ID-RNF

Descripción

Prioridad

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 8. Atributo de calidad Mantenibilidad.

Fuente: UT Fonvivienda 2019, 2020

5.1.8. Árbol de utilidad ‌

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

Ilustración 4. Árbol de utilidad.

Fuente: UT Fonvivienda 2019, 2020

Comentado [JL1]: @Xxxxxx Xxxxx Xxxxxxx Xxxxxx por favor validar

5.1.9. Escenarios de Calidad‌

Comentado [JG2R1]: Se ajustan los atributos de calidad de acuerdo a los cambio en los requerimientos no funcionales

Incluir una descripción breve para que sirven y como se deben utilizar estos escenarios

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. . Los escenarios de calidad están descritos según XXXX (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.1.9.1. Escenarios de Capacidad ‌

ESCENARIO 1	Solicitudes concurrentes
Atributo de Calidad	Eficiencia de desempeño - Capacidad.
Preocupación	Alta concurrencia en casos de uso de recibo de solicitudes como postulación de subsidios y solicitud de licencias urbanísticas. Las solicitudes se entienden como el envío o diligenciamiento de formularios que pueden incluir anexos como PDFs y que no se reciben masivamente.
Prioridad	Alta
Dificultad de Implementarlo	Baja
Fuente	Externa al sistema – usuario final
Estímulo	Ingreso de solicitudes o diligenciamiento de formularios para postulación por parte de varios usuarios del sistema
Artefacto	Módulo ingreso de solicitudes
Ambiente	Producción

ESCENARIO 1

Solicitudes concurrentes

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

ESCENARIO 2	Carga de documentos
Atributo de Calidad	Eficiencia de desempeño - Capacidad.
Preocupación	En el ingreso de solicitudes puede ser necesario el cargue de documentos anexos que son pre requisitos en el proceso de negocio.
Prioridad	Alta
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estímulo	Cargue de documentos durante las solicitudes.
Artefacto	Módulo ingreso de solicitudes
Ambiente	Producción
Respuesta	El sistema permite el cargue de anexos correctamente.
Medida	El máximo peso de un archivo o anexo a cargar es de 250M.
Descripción	N/A

ESCENARIO 3

Ejecución de reglas de negocio

Atributo de Calidad

Eficiencia de desempeño - Capacidad.

Preocupación

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.

ESCENARIO 3	Ejecución de reglas de negocio
Prioridad	Media
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estímulo	Ingreso de solicitudes por parte de varios usuarios del sistema
Artefacto	Motor de reglas – Lógica de validación.
Ambiente	Producció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. Las validaciones de seguridad como si es un archivo ejecutable se deben realizar por el componente de la capa de presentación de cargue.

ESCENARIO 4	Tiempos de respuesta
Atributo de Calidad	Eficiencia de desempeño - Capacidad.
Preocupación	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
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema – usuario final
Estímulo	Ejecución de consulta común en el sistema o registro de información básico (CRUD),
Artefacto	Sistema.
Ambiente	Producción
Respuesta	El sistema responde en tiempos aceptables a las peticiones de un usuario final.

ESCENARIO 4

Tiempos de respuesta

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 y tomando como base operaciones o transacciones comunes donde esta tipificación este dada por las características de la mayoría de las funcionalidades.

ESCENARIO 5	Seguimiento a Hogares
Atributo de Calidad	Eficiencia de desempeño - Capacidad.
Preocupación	Los posibles hogares que reciban subsidios por convocatoria, se les debe poder hacer seguimiento y por consiguiente surtir el o los procesos definidos.
Prioridad	Alta
Dificultad de Implementarlo	Bajo
Fuente	Externa al sistema – usuario final
Estímulo	Ejecución de funcionalidades sobre los hogares con beneficios.
Artefacto	Sistema.
Ambiente	Producción
Respuesta	El sistema permite ejecutar las funcionalidades a todos los hogares beneficiados por una convocatoria, dentro de los procesos definidos.
Medida	El sistema debe poder responder funcionalmente a un promedio de 100.000 hogares beneficiados por convocatoria por año.
Descripción	Se debe tener en cuenta los recursos necesarios para soportar este escenario, como lo es la base de datos.

ESCENARIO 6	Capacidad de almacenamiento
Atributo de Calidad	Eficiencia de desempeño - Capacidad.
Preocupación	El sistema tendrá que guardar documentación de todos los procesos o flujos de trabajo.
Prioridad	Alta
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estímulo	Ejecución de funcionalidades del sistema.
Artefacto	Sistema.
Ambiente	Producción
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.

ESCENARIO 7	Usuarios con sesión activa
Atributo de Calidad	Eficiencia de desempeño - Capacidad.
Preocupación	El sistema podrá ser utilizado aproximadamente por 300.000 usuarios en sus diferentes funcionalidades por año.
Prioridad	Media
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estímulo	Ejecución de funcionalidades del sistema.
Artefacto	Sistema.
Ambiente	Producción
Respuesta	El sistema permite que los usuarios tengan una sesión activa mientras estén ejecutando alguna funcionalidad.

ESCENARIO 7

Usuarios con sesión activa

Medida

El sistema debe soportar 6250 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 y para los otros módulos del SISFV 5000.

El sistema deberá manejar una estrategia de caducidad de sesiones.

ESCENARIO 8	Usuarios concurrentes en el sistema
Atributo de Calidad	Eficiencia de desempeño - Capacidad.
Preocupación	La concurrencia de usuarios estará dada por el máximo de usuarios que podrán ser aproximadamente 300.000 en un año.
Prioridad	Media
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema – usuario final
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.
Ambiente	Producción
Respuesta	El sistema permite que los usuarios realicen las funcionalidades expuestas por el sistema.
Medida	El sistema debe soportar un máximo aproximado de 450 usuarios concurrentes por segundo.
Descripción	N/A.

5.1.9.2. Escenarios de Comportamiento temporal ‌

ESCENARIO 9

Calidad de conectividad

Atributo de Calidad

Eficiencia de desempeño – Comportamiento temporal.

Preocupación

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

Prioridad	Media
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema – usuario final
Estímulo	Ejecución de funcionalidades del sistema.
Artefacto	Sistema.
Ambiente	Producción
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 xx xxxxx 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.

ESCENARIO 10	Aumento de carga temporal
Atributo de Calidad	Eficiencia de desempeño – Comportamiento temporal.
Preocupación	El sistema podrá tener aumentos momentáneos e inesperados de transacciones, que se presenten como picos de carga.
Prioridad	Media
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estímulo	Ejecución de funcionalidades del sistema.
Artefacto	Sistema.
Ambiente	Producción
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.

5.1.9.3. Escenarios de Autenticidad ‌

ESCENARIO 11	Verificación documentos
Atributo de Calidad	Seguridad – Autenticidad.
Preocupación	Para las solicitudes donde el usuario final o beneficiario debe entregar documentos anexos, se debe validar su autenticidad a través de firma digital emitida por una CA, cuando se tengan las condiciones y/o el usuario entregue el documento firmado.
Prioridad	Alta
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema – usuario final
Estímulo	Validación de documentos anexos o pre-requisitos en una solicitud.
Artefacto	Módulo de ingreso de solicitudes.
Ambiente	Producción
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.

ESCENARIO 12	Autenticación de usuarios
Atributo de Calidad	Seguridad – Autenticidad.
Preocupación.	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
Dificultad de Implementarlo	Media

Fuente	Externa al sistema – usuario final
Estímulo	Un usuario quiere ejecutar una funcionalidad en el sistema.
Artefacto	Módulo de autenticación o ingreso al sistema.
Ambiente	Producción
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.

5.1.9.4. Escenarios de responsabilidad ‌

ESCENARIO 13	Trazas de auditoria
Atributo de Calidad	Seguridad – responsabilidad.
Preocupación	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
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estímulo	Utilización de las funcionalidades del sistema.
Artefacto	Sistema
Ambiente	Producción
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.

5.1.9.5. Escenarios de integridad ‌

ESCENARIO 14	Autenticación de usuarios
Atributo de Calidad	Seguridad – integridad.
Preocupación	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
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estímulo	Ingreso de los documentos que son requisitos para los trámites.
Artefacto	Sistema
Ambiente	Producción
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.

5.1.9.6. Escenarios de confidencialidad ‌

ESCENARIO 15	Transmisión de datos de forma segura
Atributo de Calidad	Seguridad – confidencialidad.

Preocupación	El sistema por ser una plataforma web, transmitirá datos sensibles a través de internet.
Prioridad	Alta
Dificultad de Implementarlo	Baja
Fuente	Externa al sistema – comunicación por internet
Estímulo	Transmisión de datos sensibles durante la ejecución de las funcionalidades.
Artefacto	Sistema – protocolo de comunicación
Ambiente	Producció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, deben ser legibles.
Descripción	Este escenario puede validarse utilizando herramientas para ver el tráfico en una red y verificar el protocolo HTTPS y SFTP.

ESCENARIO 16	Tratamiento de datos sensibles
Atributo de Calidad	Seguridad – confidencialidad.
Preocupación	Alguna de la información que se manejará dentro del sistema, es según normatividad, sensible y por lo tanto confidencial.
Prioridad	Alta
Dificultad de Implementarlo	Baja
Fuente	Externa al sistema – usuario final
Estimulo	Registro o consulta de información confidencial.
Artefacto	Sistema
Ambiente	Producción
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.

5.1.9.7. Escenarios de tolerancia a fallos ‌

ESCENARIO 17	Tolerancia a fallos
Atributo de Calidad	Fiabilidad – tolerancia a fallos.
Preocupación	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.
Prioridad	Alta
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuario final
Estimulo	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
Ambiente	Producción
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.

5.1.9.8. Escenarios de disponibilidad ‌

ESCENARIO 18	Disponibilidad del sistema
Atributo de Calidad	Fiabilidad – disponibilidad.
Preocupación	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
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema – usuario final
Estímulo	Utilización de una funcionalidad del sistema en un horario establecido.
Artefacto	Sistema
Ambiente	Producción
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.

5.1.9.9. Escenarios de interoperabilidad ‌

ESCENARIO 19	Interoperabilidad del sistema
Atributo de Calidad	Compatibilidad – interoperabilidad.
Preocupación	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

Dificultad de Implementarlo	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
Ambiente	Producción
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.
Descripción	Se podrían dar varios tipos de mecanismos de integración, dependiendo de las posibilidades de las entidades externas.

5.1.9.10. Escenarios de protección contra errores ‌

ESCENARIO 20	Protección contra errores del usuario
Atributo de Calidad	Usabilidad – protección contra errores.
Preocupación	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 web23.
Prioridad	Baja
Dificultad de Implementarlo	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
Ambiente	Producción
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.

23 Norma NTC 5854. xxxxx://xxx.xxxxxx-xxxxxx.xxx.xx/Xxxxxxxxxxxxx/XxxxxxxxxxXxxxxx/Xxxxxxx/Xxxxxx-Xxxxxxxxx-xx-Xxxxxxxxxx-x- Gestion-/DOCUMENTO%20DE%20%20CONSULTA-%20NORMA%20%20NTC%205854.pdf

ESCENARIO 20

Protección contra errores del usuario

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.

5.1.9.11. Escenarios de estética de la interfaz ‌

ESCENARIO 21	Estética de la interfaz
Atributo de Calidad	Usabilidad – estética de la interfaz.
Preocupación	El sistema debe tener una interfaz acorde a los lineamientos del Ministerio24 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
Dificultad de Implementarlo	Media
Fuente	Externa al sistema – usuarios finales
Estímulo	Utilización de las funcionalidades del sistema.
Artefacto	Sistema
Ambiente	Producción
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.

24 xxxxx://xxx.xxx.xx/xxxxx/XXXXX.xxx

5.1.9.12. 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 xx xxx 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 xx xxx.
Artefacto	Sistema
Ambiente	Producción
Respuesta	El sistema representa lo requerido por la ley.
Medida	El sistema cumple con lo estipulado en los decretos xx xxx que rigen las funciones del Ministerio de Vivienda.
Descripción	N/A.

ESCENARIO 23	Parametrización de flujos de trabajo
Atributo de Calidad	Adecuación funcional – completitud funcional.
Preocupación	Si los decretos xx xxx, 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
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema
Estimulo	Los decretos xx xxx que rigen algunas funcionalidades cambian.
Artefacto	Sistema
Ambiente	Producción

Respuesta

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

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 xx xxx pueden representar cambio en las reglas de negocio.

5.1.9.13. Escenarios de completitud funcional ‌

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
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema – usuarios del sistema
Estímulo	Los usuarios consultan información del sistema.
Artefacto	Sistema
Ambiente	Producción
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.

5.1.9.14. Escenarios de Modularidad ‌

ESCENARIO 25	Modularidad del sistema
Atributo de Calidad	Mantenibilidad - modularidad.
Preocupación	El sistema debe mostrar las funcionalidades en módulos lógicos que dividan sus opciones según los requerimientos.
Prioridad	Media
Dificultad de Implementarlo	Alta
Fuente	Externa al sistema
Estímulo	Presentación de las funcionalidades por módulos.
Artefacto	Sistema
Ambiente	Producción
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.

5.1.10. Modelo de cuerdo de Niveles de Servicios ‌

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

Ilustración 1. Modelo de acuerdo de servicios SISFV

Fuente: UT Fonvivienda 2019, 2020

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

• Catálogo de actores25: Listado de actores de XXXXX, 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

25 Ver catálogo de actores de SISFV en: xxxxx://xxxxxxxxxxxxxxxx- xx.xxxxxxxxxx.xxx/personal/consultoria_sisfv_minvivienda_gov_co/_layouts/15/Doc.aspx?sourcedoc=%7 B8DB17E72-8821-43E6-9893-AF169BBA6C40%7D&file=SISFV-CACT- TRAN_CatalogoActores.xlsx&action=default&mobileredirect=true&CT=1620084075784&OR=ItemsView

26 Ver procedimiento en xxxxx://xxx.xxxxxxxxxxx.xxx.xx/xxxxxxx-xxxxxxxxx-xx- gestion/mapa-de-procesos/gestion-de-tecnologias-de-la-informacion-y-las- comunicaciones

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 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 Xxxxx 0 y que requiera ser escalado a otro equipo de trabajo para su tratamiento.

• Soporte de tercer nivel – especialista nivel : 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: xxxxx://xxx.xxxxxxxxxxx.xxx.xx.

• 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

27 Modelo de análisis. MVCT – Modelo de Análisis.docx – UT FONVIVIENDA 2019.

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.

o Email: xxxxxxx@xxxxxxxxxxx.xxx.xx.

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 Xxxxx 0 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 xxxx://xxxxxx/xxxxx0.

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

• 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 Xxxxx 0 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 xxxx://xxxxxx/xxxxx0, 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 solicitudes recibidas.

• Objetivo del indicador 1: 100% de cumplimiento.

• Indicador 2: Cantidad de solicitudes atendidas satisfactoriamente en los tiempos de respuesta establecidos/ 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.

- 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 xxxx://xxxxxx/xxxxx0, 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 solicitudes recibidas.

• Objetivo del indicador 1: 100% de cumplimiento.

• Indicador 2: Cantidad de solicitudes atendidas satisfactoriamente en los tiempos de respuesta establecidos/ Cantidad de solicitudes recibidas.

• Objetivo del indicador 2: 100% de cumplimiento.

• Tiempos de excepción:

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

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

• Canal: Mesa de servicio xxxx://xxxxxx/xxxxx0

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

• Objetivo del indicador 1: 100% de cumplimiento.

• Indicador 2: Cantidad de incidentes atendidos satisfactoriamente en los tiempos de respuesta establecidos/ Cantidad de incidentes recibidos.

• Objetivo del indicador 2: 100% de cumplimiento.

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

• Objetivo del indicador 3: 100% de cumplimiento.

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

• Objetivo del indicador 4: 100% de cumplimiento.

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

• Objetivo del indicador 5: 100% de cumplimiento.

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

• Objetivo del indicador 6: 100% de cumplimiento.

• Métrica:

Tabla 1 Métricas ANS Gestión de incidentes

Fuente: UT Fonvivienda 2019, 2020

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

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

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

28 Ver Vista de Componentes SISFV

de SISFV, se puede ingresar a SISFV, pero uno o más funcionalidades no

están disponibles.

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

(Corridos desde el momento de registrar la consulta

o incidente).

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

Prioridad 4 - Baja

Funcionalidades de SISFV con 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)

• Tiempos de excepción:

- 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

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

Comentado [JL3]: @Xxxxxx Xxxxx Xxxxxxx Xxxxxx por favor ajustar - actualizar los diagramas

6. VISTAS Y MODELOS ARQUITECTÓNICOS‌

Las siguientes perspectivas arquitectónicas, representan el modelamiento de la solución arquitectónica y se describen en 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 Ministerio.

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 representan 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 de asignación de subsidio. Dentro de estos casos de uso, se encuentran las siguientes funcionalidades:

• Administración de Postulación.

• Diligenciamiento de formulario.

• Consulta estado de postulación.

El manejo de la postulación se realiza de varias formas, dependiendo del actor que ejecute esta funcionalidad o caso de uso. Para el diseño de la arquitectura se tiene en cuenta la asignación del permiso respectivo a los ciudadanos, para el diligenciamiento e impresión del formulario de postulación al subsidio. Teniendo esta posibilidad, el sistema expondría este servicio a una gran cantidad de usuario finales, que, dependiendo de los programas y fechas del negocio, convierten a esta funcionalidad en una de las más exigentes en cuanto a concurrencia.

También se exponen los servicios de administración de la postulación, dentro de los cuales está la consulta del estado de la postulación y que en general, las consultas que pueden realizar los ciudadanos representan un reto para el sistema al tener en cuenta la posible cantidad de transacciones que se pueden llegar a dar.

En términos generales existe la administración de entidades claves del negocio que para el sistema son CRUDs, pero están dentro de un contexto de procesos. La funcionalidad del SISFV se divide principalmente de actividades que pueden tratar transaccionalmente sin manejo de

estados o sesiones complicadas, o sea que pueden manejarse sin estado y las que deben estructurase y modelarse como procesos.

En el siguiente diagrama se presenta el modelamiento a nivel de los casos de uso de asignación de subsidios, donde se presentan la mayoría de los escenarios mencionados anteriormente.

Ilustración 5. Diagrama de casos de uso Asignación de Subsidios

Fuente: UT Fonvivienda 2019, 2020

Otro aspecto predominante para lograr la implementación de la lógica del negocio y cumplir con los requerimientos funcionales es la alta parametrización. Dado que la premisa a nivel funcional es poder crear programas desde cero, se hace necesario que el modelamiento este alrededor de la estrategia de parametrización y generalización.

Dada la alta parametrización planteada, el siguiente diagrama muestra el modelamiento de los casos de uso transversales que apoyan esta parametrización.

Ilustración 6. Diagrama de casos de uso Transversales

Fuente: UT Fonvivienda 2019, 2020

En el modelo de análisis, se encontraron los patrones funcionales y se generalizó para poder identificar los casos de uso para soportar los requerimientos de parametrización. Para lo anterior se creó un grupo de casos de uso transversales que conforman el core del SISFV para cumplir con la flexibilidad en los procesos y tener una base de características administrables a través de la configuración, como por ejemplo la creación de un programa.

Uno de los escenarios para el diseño de la arquitectura esta dado por los casos de uso del licenciamiento urbanístico. Dentro de estos casos de uso, se encuentran las siguientes funcionalidades:

Para el diseño de la arquitectura se tiene en cuenta:

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.

El siguiente diagrama muestra un consolidado de los casos de uso del módulo de licencias urbanísticas donde se resaltan las funcionalidades descritas anteriormente.

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

Fuente: UT Fonvivienda 2019, 2020

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 del SISFV y que tiene relación con las decisiones o lineamientos de la arquitectura de referencia29.

Ilustración 8. 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 en la arquitectura de referencia para los lineamientos de trámites y estándares para el portal gov.co30.

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 9. Zona de usuarios.

Fuente: UT Fonvivienda 2019, 2020

A través del Portal xxx.xx se puede dar acceso, al FrontEnd que es el componente de aplicación web.

Ilustración 10. Integración e Interoperabilidad.

Fuente: UT Fonvivienda 2019, 2020

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 11. Aplicación web, microservicios

Fuente: UT Fonvivienda 2019, 2020

En el componente de Aplicación web, microservicios, se abstrae el Frontend y los microservicios. La capa de negocio, conformada por microservicios no rigurosos, realizan la persistencia de los datos. Ningún otro componente transaccional tiene acceso a la persistencia.

Ilustración 12. Base de datos y Data Mart.

Fuente: UT Fonvivienda 2019, 2020

En la capa de persistencia se definen dos repositorios, uno para centralizar toda la información del sistema y que se considera una base de datos transaccional y para el otro, 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 datos31.

6.3. Vista de procesos ‌

En el siguiente diagrama podemos ver, en un momento dado en el tiempo, peticiones que nacen en el Browser, representado al interior del sistema transacciones, y como estas transacciones se distribuirán y atenderán.

31 Literal 4.1. Vista arquitectura referencia para inteligencia de negocios bi y analítica - Arquitectura de referencia MCVT – Arquitectura referencia.docx

En esta vista se puede observar las necesidades de la atención de hilos y los posibles momentos dentro de la distribución de la arquitectura y como los componentes reciben y despachan las peticiones.

Ilustración 13. Vista de Procesos

Fuente: UT Fonvivienda 2019, 2020

Como primera medida se tiene la posibilidad que se inicien 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.

El componente FrontEnd se ejecuta sobre un servidor web que administra y permite la transaccionalidad.

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. El componente corre sobre un servidor de aplicaciones que puede estar embebido para cumplir con definiciones de independencia de los microservicios.

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 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 de datos utilizando la mayor capacidad de procesamiento y consumo de recursos en el tiempo.

6.4. Vista de implementación o componentes ‌

La vista de implementación se representa con un diagrama de capas con sus componentes respectivos y se muestra la interrelación de cada uno de estos. Los componentes definidos tienen su asignación de responsabilidades y cumplen lineamientos por cada uno de ellos. Para esta vista se usó el patrón modelo-vista-control MVC32.

La capa de presentación o FrontEnd, está conformada por un componente que está conformado por 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. Adicionalmente se comunica 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, aunque el lineamiento consiste en que todas las peticiones que van hacia la capa de negocio pasen por el bus de servicios.

En determinado caso funcional donde el usuario final utilice una funcionalidad de forma masiva, donde sean servicios utilizados directamente por el ciudadano, esta capa de presentación debe implementar el servicio y exponerlo como aplicación web, o tener la capacidad de iniciar el proceso a través de una interface gráfica y pasar el control a las capas subyacentes.

32 Ver los 5 patrones esenciales de arquitectura de software en xxxxx://xxx.xxxxxx.xxx/xxxxxxxxx/0-xxxxxxxxx-xxxxxxxx-xxxxxxxx - architecture

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 de los datos, que estarán sobre una estructura de bodega de datos. Este componente se relaciona o se comunica de forma directa con la estructura mencionada.

La capa de integración o de servicios, está conformada por dos componentes principales. Primero está 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 servicios tiene la posibilidad de utilizar el componente XROAD para asegurar la interoperabilidad con entidades externas de acuerdo con lo establecido en el marco de interoperabilidad del estado33, sin limitar esta integración de forma directa y con seguridad propia del bus de servicios.

La configuración de la seguridad de Xroad permite el aseguramiento del canal de comunicación, la entrada a los servicios, la autenticación con manejo de certificados y su validación en capa de presentación.

Como segundo componente, está el BPMS o gestor de procesos quien podrá exponer servicios a través de sus capacidades, representando una actividad dentro de un proceso de negocio o iniciando un proceso por el disparo de un evento, controlando el flujo de actividades del proceso. El BPMS también tiene la capacidad de exponer interfaz gráfica constituida por formularios dentro del modelamiento natural de los procesos.

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. El gestor de procesos se debe encargar de manejar el flujo de actividades y todos los temas de la metadata de los procesos y el monitoreo de las instancias de estos.

El siguiente diagrama muestra los componentes del sistema agrupados por capas.

33 Xxxxx de interoperabilidad MinTIC xxxx://xxxxxxxx.xxxxxx.xxx.xx/xxxxx-xx-xxxxxxxxxxxxxxxxx

Ilustración 14. 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 para poder generar el crecimiento requerido sobre los servicios expuestos y que se requiera según comportamiento.

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 esté 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 y características generales.

Comentado [JG5R4]: Se ajusta el componente de presentación

Comentado [JL4]: @Xxxxxx Xxxxx Xxxxxxx Xxxxxx Por favor ajustar

6.4.1.1. Componente de Presentación‌

Ilustración 15. Componente de Presentación

Fuente: UT Fonvivienda 2019, 2020

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 16. Sistema Gestor de Procesos

Fuente: UT Fonvivienda 2019, 2020

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 el modelamiento debe ser guiado por el modelamiento realizado en la disciplina de requerimientos.

Aunque este componente tiene su propia base de datos, el dominio de datos del negocio representados por las entidades derivadas del modelamiento realizado en la disciplina de requerimientos, 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.

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 Servicios Empresarial

Ilustración 17. Componente Bus Empresarial

Fuente: UT Fonvivienda 2019, 2020

El bus de servicios empresarial es la pieza central del diseño de la arquitectura del sistema SISFV. 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. La utilización del patrón API Gateway se vuelve fundamental para el tratamiento del consumo de los servicios de la capa de negocio a través del bus empresarial.

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 este 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, para mantener un orden de consumo.

La integración con entidades externas será responsabilidad de este componente y se plantea una interoperabilidad estandarizada para 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.

Adicionalmente el bus tendrá la responsabilidad de manejar comunicación asíncrona, donde a través de una cola de mensajes o componente de gestor de eventos34, los subscriptores puedan consumirlos y generar la lógica deseada en la capa de negocio.

6.4.1.4. Microservicios

Ilustración 18. 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. Aunque no son conceptualmente rigurosos, estos microservicios tienen características de aislamiento y exponen servicios REST, compartiendo una misma base de datos.

La implementación de la lógica de negocio se sugiere sea utilizado el paradigma de desarrollo el orientado 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.

34 Ver Documento de Arquitectura de Referencia SISFV, FONVIVIENDA 2019.

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 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 19. Componente Base de Datos

Fuente: UT Fonvivienda 2019, 2020

La base de datos centralizará toda la información del sistema SISFV, deberá tener 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 ser 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.

Ilustración 20. Componentes de BI.

Fuente: UT Fonvivienda 2019, 2020

Los datos que se reciban en la base de datos centralizada deben ser trasladados a través de un componente ETL a la estructura de las bodegas de datos haciéndose las transformaciones necesarias para que alimente de forma correcta la bodega.

Respecto a la bodega de datos, se propone crear un Data Mart para los reportes y tableros de control de SISFV.

6.4.1.7 Gestor Documental GESDOC

El gestor documental de MVTC es GESDOC, los componentes de microservicios y el motor de procesos presentes en SISFV, usaran el gestor documental a través del bus de servicios

empresariales ESB, para crear, actualizar, consultar y firmar digitalmente todos los documentos. Se usará el gestor documental mediante servicios web y el uso especifico de GESDOC se encuentra documentado en los casos de uso de SISFV que utilizan documentos.

6.4.1.8 Motor de reglas de negocio

El motor de reglas de negocio es para proporcionar a SISFV el desacoplamiento de las reglas de negocio, las reglas de negocio se expondrán mediante servicios web y estas serán usadas por los microservicios y el motor de procesos de negocio.

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

Ilustración 21. 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 varios nodos por cada componente. Se determina también la utilización de un firewall y balanceadores para el crecimiento horizontal.

6.6. Vistas de Infraestructura ‌

6.6.1. Clúster de servidores WEB ‌

Ilustración 22. 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 HAProxy por su flexibilidad para balancear tráfico HTTP con estrategias como roundrobin 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.

Comentado [JL6]: @Xxxxx Xxxxxxxxx Xxxx Xxxxxx por favor ajustar

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 y BPM ‌

Estos tres 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 HAProxy. En todos, el esquema de balanceo distribuirá peticiones sin sesión.

La arquitectura no requiere sesiones HTTP que deban ser mantenidas y además distribuidas entre los nodos, en términos generales, la capa cliente usará a la infraestructura como un conjunto de APIs.

En los tres casos se desplegará dos balanceadores en clúster activo/pasivo; se recomienda HAProxy para lograrlo, cada nodo tendrá su servidor de aplicaciones.

Ilustración 23. 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). Se usa la definición de clúster como conjunto de servidores o servicios que ponen sus recursos a disposición de un servicio común y que funcionan como uno. En este caso y efectivamente aplica para todos los clústeres, cada uno es la combinación de varias instancias del mismo servicio, balanceado por medio de un balanceador HAProxy (propuesto). Adicionalmente, bajo el mismo balanceo, se ubicará un nodo para el servidor del BRM, con la intención que se beneficie de un crecimiento horizontal si se requiere.

Ilustración 24.Cluster 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.

Se especifican 3 nodos para obtener las siguientes características de diseño:

1. Proporcionar alta disponibilidad y tolerancia a fallos.

2. Dar respuesta adecuada y de calidad en tiempos al volumen de peticiones

3. Proporcionar escalabilidad horizontal

Se puede utilizar un esquema en que el motor ESB use una única instancia, pero en ese caso se debe proporcionar alta disponibilidad a nivel de virtualización, sin embargo, se debe considerar lo siguiente:

1. Si el hypervisor deja de estar disponible de forma indefinida para migrar data, no habrá forma de mover los datos de la VM, así que la alta disponibilidad estará limitada a ciertos escenarios.

2. Debe estimarse cuidadosamente la capacidad de ese único nodo ya que se busca atender 450 usuarios concurrentes.

3. La escalabilidad estará limitada a ser vertical.

Ilustración 25. Clúster BPM

Fuente: UT Fonvivienda 2019, 2020

Comentado [JL7]: @Xxxxx Xxxxxxxxx Xxxx Xxxxxx por favor ajustar

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.

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 del SISFV, 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.

Ilustración 26. Cifras para postulaciones.

Número de usuarios x año

Fuente: UT Fonvivienda 2019, 2020

Las cifras anteriores se obtienen como resultado de la estimación de las posibles postulaciones al subsidio familiar de vivienda. Se determina el número de usuarios para las cajas de compensación, entes territoriales, bancos y usuarios internos del ministerio de vivienda. Adicionalmente se estima un número de usuarios que podrían diligenciar el formulario de postulación en línea que sería una funcionalidad expuesta a la ciudadanía.

Ilustración 27. Cifras para Solicitud de licencias.

Número de usuarios x año

Fuente: UT Fonvivienda 2019, 2020

Las cifras anteriores se obtienen como resultado de la estimación de las posibles solicitudes de licencias urbanísticas. Se determina el 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 el SISFV 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.

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 xx xxxxx. 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 xx xxxxx de 202135, 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

https://xxxxx.xxxxxxxxxxx.xxx.xx/normativa/normativa/DIRECTIVA%20PRESIDENCIAL%2003%20DEL%2015%20DE%20MARZO% 20DE%202021.pdf

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 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 del Sistema de Información del Subsidio Familiar de Vivienda – SISFV” y del “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 a través de los acuerdos marco de precios de Colombia Compra eficiente.

Para concluir, la Implementación del Sistema de Información del Subsidio Familiar de Vivienda – SISFV” y del “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.

Document Metadata

Table of Contents

Contrato No. 001 de 2019 – Arquitectura Empresarial

Document Metadata

Contrato No. 001 de 2019 – Arquitectura Empresarial

DOCUMENTO DE ARQUITECTURA DE SOFTWARE SISTEMA DE SUBSIDIO FAMILIAR DE VIVIENDA SISFV

TABLA DE CONTENIDO

9

11

17

19

21

58

85

LISTADO DE TABLAS

LISTADO DE ILUSTRACIONES

1 PRESENTACIÓN DEL DOCUMENTO‌

2 INTRODUCCIÓN‌

3 METAS Y RESTRICCIONES DE LA ARQUITECTURA‌

4 MOTIVADORES ARQUITECTURALES‌

5 ATRIBUTOS DE CALIDAD‌

7. CONCLUSIONES‌

Document Metadata

1 PRESENTACIÓN DEL DOCUMENTO ‌

2 INTRODUCCIÓN ‌

3 METAS Y RESTRICCIONES DE LA ARQUITECTURA ‌

4 MOTIVADORES ARQUITECTURALES ‌

5 ATRIBUTOS DE CALIDAD ‌

7. CONCLUSIONES ‌