Documento de Estándares y Ciclo de Vida de Los Sistemas de Información

Página 1 de 132
Documento de estándares y ciclo de vida de los sistemas de información

VERSIÓN 4
PORTADA
HISTORIAL DEL DOCUMENTO
ELABORACIÓN O MODIFICACIÓN REVISIÓN APROBACIÓN MODIFICACIÓN

Vers.
NOMBRE Y NOMBRE Y
FECHA FECHA FECHA
NOMBRE Y CARGO CARGO CARGO
0 Fabián Eduardo 03/02/2011 Lyda Zoraida Lyda Zoraida 31/05/201 Lanzamiento

Salgado C Huertas B. Huertas B. 0
(Arquitecto Gestión (Líder Gestión de (Líder Gestión de
de la Demanda) la Demanda) la Demanda)
1 José A. Mejia 05/05/2015 Lyda Zoraida Lyda Zoraida Actualización
Sanchez Huertas B. Huertas B. lineamientos
(Arquitecto Gestión (Líder Gestión de (Líder Gestión de gráficos,
de la Demanda) la Demanda) la Demanda) desarrollo .net

Sanchez Huertas B. Huertas B. lineamientos,
(Arquitecto Gestión (Líder Gestión de (Líder Gestión de acerca de
de la Demanda) la Demanda) la Demanda) desarrollo

Sanchez Huertas B. Huertas B. lineamientos, de
(Arquitecto AAS.) (Gerente AAS) (Gerente AAS) seguridad,
derivados de
estudio de
vulnerabilidades
4 José A. Mejia 28/07/2017 Lyda Zoraida Lyda Zoraida Definición de
Sanchez Huertas B. Huertas B. componentes,
(Arquitecto AAS.) (Gerente AAS) (Gerente AAS) componentes
permitidos, y
proceso para
gestión de
componentes
LISTA DE DISTRIBUCIÓN
No. CARGO PROCESO AL QUE PERTENECE
CONSULTE EL LISTADO MAESTRO

VERIFIQUE QUE ESTA ES LA EDICIÓN CORRECTA ANTES DE UTILIZAR EL DOCUMENTO
Página 2 de 132
VERSIÓN 4
1 Usuarios líderes de Aplicación Procesos Consorcio

2 Colaborador Apoyo Operativo Gestión de la demanda Gestión de la Demanda
Desarrolladores de Software Gestión de Demanda Tecnología de Información
3
Coordinador outsourcing Outsourcing de Desarrollo
4 Planificadores Gestión de la Demanda
1. OBJETIVO
Definir un marco regulatorio de carácter obligatorio, para la gestión del portafolio de servicios 1 relacionados con la creación o el mantenimiento
de software, del equipo de gestión de la demanda.
Con el pleno convencimiento, de que todos los paradigmas metodológicos, y especialmente los relacionados con tecnologías de información,
sufren de una veloz evolución y dinámica, se validará permanentemente la vigencia de los mismos, mediante un enfoque de mejoramiento
continuo, soportado por una continua revisión y búsqueda de fuentes externas de referencia.
La correcta búsqueda y adopción de procedimientos, será determinante en la condición final del servicio entregado, y por ende, en la calidad
de los Sistemas de Información, que apoyan las labores cotidianas de nuestra organización.
2. ALCANCE
Las definiciones incluidas en este documento abarcan, todos los sistemas de información desarrollados en Consorcio, directamente o a
través de la modalidad de tercerización, y para sistemas de información adquiridos, aunque para estos últimos, solamente en los aspectos
donde sea posible aplicarlo con el fin de apoyar la calidad del sistema de información finalmente implementado.
1 ITIL1 ITIL® 2011 Edition – A Pocket Guide – Jan van Bon a.o.

Página 3 de 132
VERSIÓN 4
CONTENIDO
1. ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN ........................................................... 8
1.1. DEFINICIÓN CONCEPTUAL.......................................................................................................... 8
1.2. MODELAMIENTO ........................................................................................................................... 9
1.2.1. Tipos de Diagrama UML: ................................................................................................................ 9
2. ARQUITECTURA DE LOS SISTEMAS DE INFORMACIÓN ....................................................... 12
2.1. ARQUITECTURA DE SOFTWARE .............................................................................................. 13
2.1.1. Aplicaciones de Escritorio: ............................................................................................................ 13
2.1.2. Aplicaciones ABS .......................................................................................................................... 13
2.1.3. Componentes o Ensamblados ...................................................................................................... 14
2.1.4. Componentes de Extracción Transformación y Carga. ................................................................ 14
2.1.5. Aplicaciones WEB ......................................................................................................................... 14
2.1.6. Componentes de Bus de Servicio. ............................................................................................... 15
2.2. ARQUITECTURA DE SEGURIDAD ............................................................................................. 16
2.2.1. Acceso a Bases de Datos ............................................................................................................. 16
2.2.2. Aplicaciones de escritorio: ............................................................................................................ 16
2.2.3. Aplicaciones y servicios WEB: ...................................................................................................... 17
2.2.4. Aplicaciones ABS: ......................................................................................................................... 19
2.3. ARQUITECTURA DE BASE DE DATOS ..................................................................................... 20
3. ESTÁNDARES DE DESARROLLO DE SISTEMAS DE INFORMACIÓN.................................... 21
3.1. REGULACIONES BÁSICAS GENERALES DE LAS APLICACIONES ........................................ 21
3.1.1. Modelo De Datos .......................................................................................................................... 21
3.1.2. Modelo De Datos para servicios web ........................................................................................... 21
3.1.3. Formato de datos .......................................................................................................................... 22
3.1.4. Parametrización de Unidades de Solución Lógica (Aplicaciones, servicios, componentes etc.) 22
3.1.5. Sistema Operativo......................................................................................................................... 22
3.1.6. Implementación ............................................................................................................................. 22
3.1.7. Desarrollo Módulos Genéricos, Librerías Y Componentes .......................................................... 23
3.2. ESTÁNDARES PROGRAMACIÓN .............................................................................................. 24
3.2.1. Generalidades ............................................................................................................................... 24
3.2.2. Nombramiento de Variables ......................................................................................................... 25
3.2.3. Nombres de Controles, Formularios, Módulos y Funciones ........................................................ 26
3.2.4. Utilización de componentes .......................................................................................................... 27
3.2.5. Documentación de fuentes ........................................................................................................... 28
3.2.6. Manejo de clases .......................................................................................................................... 28
3.2.7. Acceso a las bases de datos ........................................................................................................ 28
3.2.8. Gestión de Errores ........................................................................................................................ 29
3.3. ESTÁNDARES DE INTERFAZ GRÁFICA PARA APLICACIONES DE ESCRITORIO ............... 33
3.3.1. Barras de Menú............................................................................................................................. 33
3.3.2. Barras de Herramientas. ............................................................................................................... 33

Página 4 de 132
VERSIÓN 4
3.3.3. Ventanas. ...................................................................................................................................... 33

3.3.4. Mensajes Emergentes. ................................................................................................................. 34
3.3.5. Campos. ........................................................................................................................................ 35
3.3.6. Operación mediante Teclas de función. ....................................................................................... 36
3.3.7. Operación basada en dispositivo mouse. ..................................................................................... 36
3.3.8. Distribución Espacial (Alineación, Agrupación y Espaciado). ...................................................... 37
3.3.9. Estilos de letra. .............................................................................................................................. 37
3.3.10. Apariencia General y Percepción de Usuario (Look & feel) ......................................................... 38
3.4. ESTÁNDARES DE INTERFAZ GRÁFICA PARA APLICACIONES WEB. ................................... 39
3.4.1. Paleta Cromática........................................................................................................................... 39
3.4.2. Tipografía ...................................................................................................................................... 39
3.4.3. Nombramiento de elementos gráficos .......................................................................................... 40
3.4.4. Documentación Integrada (comentarios)...................................................................................... 41
3.4.5. Diseño WEB Adaptativo (responsivo) ........................................................................................... 41
3.4.6. Presentación de Etiquetas HTML ASPX/ASMX ........................................................................... 42
3.4.7. Encabezado .................................................................................................................................. 42
3.4.8. Formularios. .................................................................................................................................. 43
3.4.9. Elementos de Documento ............................................................................................................. 45
3.4.10. Marcos (Frames/Panel) ................................................................................................................ 45
3.4.11. Títulos y Subtítulos........................................................................................................................ 46
3.4.12. Etiquetas y Campos de Texto ....................................................................................................... 46
3.4.13. Gestión visual de controles de tipo botón de comando. ............................................................... 47
3.4.14. Gestión visual de controles de tipo Fecha (“MonthCalendar”). .................................................... 47
3.4.15. Gestión visual de GRIDS. ............................................................................................................. 47
3.4.16. Modelo de página para despliegue de mensajes de la aplicación ............................................... 48
3.4.17. Páginas básicas: ........................................................................................................................... 49
3.5. ESTÁNDARES DE BASES DE DATOS ....................................................................................... 62
3.5.1. Nombres de tablas ........................................................................................................................ 62
3.5.2. Nombres de campos ..................................................................................................................... 62
3.5.3. Nombres de índices ...................................................................................................................... 62
3.5.4. Nombres de procedimientos ......................................................................................................... 63
3.5.5. Nombres de vistas ........................................................................................................................ 63
3.5.6. Nombres de ETLs y Jobs .............................................................................................................. 63
3.5.7. Diccionario de base de datos........................................................................................................ 63
3.5.8. ETL’s ............................................................................................................................................. 64
3.6. LOG DE AUDITORIA DE APLICACIONES O SERVICIOS ......................................................... 72
3.6.1. Creación de tabla Principal para registro del Log ......................................................................... 72
3.6.2. Creación de tabla de Histórico para registro del Log ................................................................... 73
3.6.3. Creación Procedimiento almacenado ........................................................................................... 73
3.6.4. Actualización FrameWrokNet2 Versión 2.0.0.113 en la Aplicación o Servicio ............................ 75
3.6.5. Implementación en la Aplicación o Servicio ................................................................................. 75
3.6.6. Consumo WSeguridad Método RegistrarLog ............................................................................... 77
4. USO ADECUADO DE COMPONENTES DE TERCEROS (APIS, LIBRERÍAS, NUGGETS, PLUGINS) 77
4.1. NuGets .......................................................................................................................................... 79
4.2. API’S ............................................................................................................................................. 79
4.3. DLL’S............................................................................................................................................. 80
4.4. PLUGINS ...................................................................................................................................... 80
4.5. Componentes permitidos en la organización: .............................................................................. 81

Página 5 de 132
VERSIÓN 4
5. ESTANDARES DE INFRAESTRUCTURA, ADMINISTRACIÓN Y OPERACIÓN DE LOS SISTEMAS DE INFORMACIÓN 81

5.1. Estándar en la Infraestructura de Redes ...................................................................................... 82
6. ESQUEMA DE SEGURIDAD PARA LOS SISTEMAS DE INFORMACIÓN ................................ 84
6.1. Seguridad estaciones y/o portátiles .............................................................................................. 84
6.2. Seguridad en la BDs. .................................................................................................................... 84
6.3. Seguridad en el acceso a Windows .............................................................................................. 85
6.4. Seguridad en el acceso a los aplicativos ...................................................................................... 85
6.5. Seguridad en el acceso y/o actualización de los directorios de los instaladores ......................... 85
7. CENTRALIZACIÓN DE OBJETOS DE DESARROLLO Y CONSOLIDACIÓN DE BASES DE DATOS 86
7.1. Centralización de objetos de desarrollo........................................................................................ 86
7.1.1. Objetivo ......................................................................................................................................... 86
7.1.2. Consideraciones ........................................................................................................................... 86
7.1.3. Manejo de Versiones .................................................................................................................... 87
7.2. Definiciones de Uso de TFS ......................................................................................................... 90
7.2.1. Objetivo ......................................................................................................................................... 90
7.2.2. Acerca de TFS .............................................................................................................................. 90
7.2.3. Estructura y contenido .................................................................................................................. 91
7.2.4. Asignación de la cuenta y permisos de la cuenta. ....................................................................... 93
7.2.5. Recomendaciones de Uso ............................................................................................................ 93
7.2.6. Malas Prácticas ............................................................................................................................. 94
7.2.7. Vínculos de TFS con otros Software ............................................................................................ 94
7.3. Consolidación de bases de datos ................................................................................................. 94
8. ESTRUCTURACIÓN AMBIENTE DE DESARROLLO, PRUEBAS Y PRODUCCIÓN ................ 96
8.1. Plataforma Cliente/Servidor e Intranet .......................................................................................... 96
8.1.1. Ambiente de desarrollo ................................................................................................................. 96
8.1.2. Ambiente de pruebas .................................................................................................................... 96
8.1.3. Ambiente de producción ............................................................................................................... 97
8.2. Plataforma De Desarrollo ABS ( Enterprise Application Environment) ........................................ 97
8.2.1. Ambiente De Desarrollo: ............................................................................................................... 97
8.2.2. Ambiente De Pruebas: .................................................................................................................. 99
8.2.3. Paso A Producción:..................................................................................................................... 100
9. PROTOCOLO DE TRASLADO A PRODUCCIÓN DE SISTEMAS DE INFORMACIÓN Y ACTUALIZACIONES 101
9.1. Protocolo Preliminar .................................................................................................................... 101
9.1.1. Protocolo Preliminar pruebas...................................................................................................... 101
9.2. Solicitud Salida Producción Nuevo Aplicativo ............................................................................ 101
9.3. Solicitud Modificación Versión Aplicativo en Producción ........................................................... 101
9.4. Solicitud Instalación Aplicativos .................................................................................................. 101
9.5. Repositorio Único de Instaladores .............................................................................................. 102
9.5.1. Características ............................................................................................................................ 102
9.5.2. Control de Acceso ....................................................................................................................... 103
9.5.3. Manejo de Históricos................................................................................................................... 104
9.6. Manual Técnico – Capítulo Proceso Instalación ........................................................................ 104
9.7. Programa Instalación .................................................................................................................. 105
9.7.1. Características ............................................................................................................................ 105
9.7.2. Herramientas Generación Instaladores ...................................................................................... 105
9.7.3. Pruebas de Instaladores ............................................................................................................. 106
9.8. Archivos Maestro ........................................................................................................................ 106
9.8.1. Inventario de máquinas y software ............................................................................................. 106

Página 6 de 132
VERSIÓN 4
9.8.2. Inventario de Aplicaciones y Responsables ............................................................................... 106

9.8.3. Inventario de Instalaciones en equipos clientes ......................................................................... 107
9.9. Manejo de Versiones .................................................................................................................. 107
9.10. Buenas y malas prácticas ........................................................................................................... 107
9.10.1. Malas Prácticas ........................................................................................................................... 107
10. COMPROMISO FRENTE A LA ADECUADA UTILIZACIÓN DE LOS RECURSOS, DESEMPEÑO Y TIEMPOS DE RESPUESTA EN
LOS SISTEMAS DE INFORMACIÓN ........................................................................................................ 108
11. DOCUMENTACIÓN INTEGRAL DE LOS SISTEMAS DE INFORMACIÓN .............................. 109
11.1. Guía de Interacción de Usuario con el Sistema ......................................................................... 109
11.1.1. Contenido de la Guía de Interacción de Usuario con el Sistema ............................................... 109
11.1.2. Indicaciones para la elaboración de la Guía de Interacción de Usuario con el Sistema ........... 109
11.1.3. Manuales Sistemas de Información adquiridos externamente................................................... 109
11.1.4. Acceso y consulta del manual de usuario. ................................................................................. 110
11.1.5. Esquema de almacenamiento .................................................................................................... 110
11.1.6. Políticas de actualización Guía de Interacción ........................................................................... 110
11.2. Documentación Técnica del Sistema ......................................................................................... 110
11.2.1. Contenido del Manual Técnico del Sistema ............................................................................... 110
12. INTEGRADOR DE SISTEMAS - ISICOM................................................................................... 111
12.1. Arquitectura ISICOM ................................................................................................................... 111
13. LISTA DE CHEQUEO EN APLICACIONES .NET ...................................................................... 113
13.1. Diseño ......................................................................................................................................... 113
13.1.1. Patrónes de diseño: .................................................................................................................... 113
13.1.2. Aprovechamiento adecuado del cache:...................................................................................... 113
13.1.3. Separación de responsabilidades: .............................................................................................. 113
13.1.4. No utilización de direcciones IP ó nombres de equipos de los clientes. .................................... 113
13.2. Presentación ............................................................................................................................... 113
13.2.1. Diseño gráfico: ............................................................................................................................ 113
13.3. Implementación ........................................................................................................................... 114
13.3.1. Validación de tipos de datos/formato: ......................................................................................... 114
13.3.2. No duplicidad de código: ............................................................................................................. 114
13.3.3. No utilizar OCX ni componentes COM : ..................................................................................... 114
13.3.4. Interfaces comunes: .................................................................................................................... 114
13.3.5. Manejo de excepciones: ............................................................................................................. 114
13.3.6. Captura y propagación de las excepciones: ............................................................................... 115
13.3.7. Registro de excepciones: ............................................................................................................ 115
13.3.8. Manejo de variables y conversiones: .......................................................................................... 115
13.3.9. Utilización de cadenas: ............................................................................................................... 115
13.3.10. Comentarios relevantes: ............................................................................................................. 115
13.3.11. Estructuras heredades de VB6: .................................................................................................. 116
13.3.12. Compilación estricta y explícita:.................................................................................................. 116
13.4. Base de datos ............................................................................................................................. 116
13.4.1. Utilización de la clase cDatos del framework: ............................................................................ 116
13.4.2. Sentencias SQL en el código:..................................................................................................... 116
13.4.3. SQL dinámico en los procedimientos almacenados:.................................................................. 116
13.4.4. Manejo y contexto de los errores en base de datos: .................................................................. 116
13.4.5. Estándares de nomenclatura de Bases de Datos: ..................................................................... 117
13.4.6. Definición de cadenas de conexión: ........................................................................................... 117
13.4.7. Planes de ejecución .................................................................................................................... 117

Página 7 de 132
VERSIÓN 4
13.5. Seguridad .................................................................................................................................... 117

13.5.1. Protección del archivo de configuración ante cualquier modificación: ....................................... 117
13.5.2. Datos de usuarios y/o contraseñas explicitas en el código: ....................................................... 117
13.5.3. Algoritmos de encripción implementados: .................................................................................. 117
13.5.4. Adopción de Adminus: ................................................................................................................ 117
13.5.5. Utilización de los providers del framework: ................................................................................ 118
13.5.6. Acceso a servicios Web a través del framewok: ........................................................................ 118
13.5.7. ViewState protegido: ................................................................................................................... 118
13.6. Procedimiento de Test ................................................................................................................ 118
13.7. Configuración .............................................................................................................................. 118
13.7.1. Definición de cadenas de conexión: ........................................................................................... 118
13.7.2. Verificación de que el valor de un parámetro de configuración no se ha definido: .................... 119
13.7.3. Utilización del código de aplicación: ........................................................................................... 119
13.7.4. Rutas de archivos: ...................................................................................................................... 119
13.7.5. Administración del estado de sesión: ......................................................................................... 119
13.7.6. Opción de compilación para depuración: ................................................................................... 119
13.7.7. Opción de trace ........................................................................................................................... 119
13.7.8. Llaves en el web.config ............................................................................................................... 119
13.7.9. Llaves comentariadas en el web.config ...................................................................................... 119
13.8. Instaladores ................................................................................................................................. 119
13.8.1. Nombre del instalador ................................................................................................................. 120
13.8.2. Assemblies en el GAC ................................................................................................................ 120
13.9. Auditoría ...................................................................................................................................... 121
13.10. Reportes / Impresión ................................................................................................................... 121
13.10.1. Reportes ...................................................................................................................................... 121
13.11. Documentación ........................................................................................................................... 121
13.12. Fuentes ....................................................................................................................................... 122
13.13. Otros............................................................................................................................................ 122
13.13.1. Lenguaje de Desarrollo ............................................................................................................... 122
13.14. Servicios Web ............................................................................................................................. 122
13.14.1. Seguimiento ................................................................................................................................ 122
13.14.2. Respuestas erradas .................................................................................................................... 122
14. ARQUITECTURA DE LOS SISTEMAS DE INFORMACIÓN ..................................................... 123
14.1. Arquitectura de referencia para aplicaciones y servicios ........................................................... 123
14.1.1. Aplicaciones ................................................................................................................................ 124
14.1.2. Web Services .............................................................................................................................. 124
14.1.3. Web Service Conector ................................................................................................................ 125
14.1.4. Assembly ..................................................................................................................................... 125
14.1.5. Bases de datos ........................................................................................................................... 125
14.2. Implementación de aplicaciones .NET ....................................................................................... 125
14.3. Implementación de web services ................................................................................................ 127
14.4. Arquitectura de seguridad ........................................................................................................... 128
15. CONTROLES DE CAMBIOS EN LAS APLICACIONES ............................................................ 130
15.1. RollBack de las aplicaciones ...................................................................................................... 130
15.1.1. Instaladores de aplicaciones, servicios, Etls y Reportes (*.rdl) ................................................. 130
15.1.2. Objetos de base de datos ........................................................................................................... 131

Página 8 de 132
VERSIÓN 4
1. ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN
1.1. DEFINICIÓN CONCEPTUAL
Tienen como propósito establecer y definir el propósito del requerimiento, incluyendo el porqué de la necesidad, y las características de alto
nivel que el usuario, espera encontrar en el producto entregado. Precede y abarca el proceso de ingeniería de requerimientos. Su objetivo es
crear una descripción de alto nivel, que presenta de manera clara el propósito del requerimiento, incluso para clientes que no tengan
conocimientos técnicos 2.
Tomado de Ingeniería de software, Addison Wesley Ian Sommerville 2015.
2 Ingeniería de software, Addison Wesley Ian Sommerville 2015.

Página 9 de 132
VERSIÓN 4
1.2. MODELAMIENTO
Consiste en desarrollar modelos abstractos de un sistema, en donde cada modelo presenta una perspectiva diferente de dicho sistema, la
notación a utilizar en los modelos será Unified Modeling Language (UML) 3.
El objetivo final del modelamiento, es permitir que los analistas entiendan la funcionalidad del sistema, los modelos permiten a los clientes
entender que es lo que van a recibir.
1.2.1. Tipos de Diagrama UML:
1.2.1.1. Modelos De Contexto
• Diagramas de Actividad: Los cuales exhiben las actividades involucradas en un proceso, incluyendo procesos tecnológicos.
3 https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado
Página 10 de 132
VERSIÓN 4
1.2.1.2. Modelos De Interacción
• Diagramas de Casos de Uso, expresan la relación entre un sistema y su entorno.
• Diagramas de secuencia, representan las interacciones entre los actores y el sistema y entre los componentes del sistema

Página 11 de 132
VERSIÓN 4
1.2.1.3. Modelos Estructurales
• Diagramas de Clases: Exhiben las clases de objetos en un sistema y las relaciones entre esas clases.
MODELOS DE COMPORTAMIENTO
Diagramas de Estado, representan la manera cómo reacciona el sistema ante eventos internos y externos.
MODELOS ORIENTADOS A EVENTOS

Página 12 de 132
VERSIÓN 4
2. ARQUITECTURA DE LOS SISTEMAS DE INFORMACIÓN
La arquitectura contempla todos los aspectos necesarios para la gestión del servicio de sistemas de información, así como la interrelación entre
dichos aspectos y el negocio, adicionalmente debe ofrecer una guía para el diseño y evolución del servicio 4, teniendo en cuenta los siguientes
aspectos:
La arquitectura de sistemas de información, adoptada por Consorcio es un modelo distribuido estructurado en capas, lo cual abarca todos los
aspectos de las unidades de solución lógica, inclusive aspectos tales como seguridad, escalabilidad, disponibilidad y mantenibilidad, entre
otras5. Todo esfuerzo de desarrollo, debe basarse en este enfoque, el cual permitirá una gran flexibilidad incluso para la adopción de nuevos
enfoques tecnológicos.
Tomado de https://msdn.microsoft.com/es-es/library/ms954595.aspx
4 ITIL1 ITIL® 2011 Edition – A Pocket Guide – Jan van Bon a.o.
Página 13 de 132
VERSIÓN 4
2.1. ARQUITECTURA DE SOFTWARE
Define los componentes de software que conforman un sistema de información, y las relaciones entre dichos componentes, abarca tanto
definiciones funcionales como no funcionales, tales como temas de seguridad, comunicación entre componentes, formato de datos, conexión
y consumo de fuentes de datos, entre otros 6.
Toda funcionalidad desarrollada en Consorcio, deberá respetar el patrón arquitectónico “MVC”, en donde la capa de datos, está separada de
la interfaz de usuario y de la capa de reglas de negocio i, las plataformas disponibles para implementación, se encuentran circunscritas a los
siguientes modelos arquitectónicos:
2.1.1. Aplicaciones de Escritorio:
Incluidas dentro de los sistemas de tipo distribuido, corresponde a herramientas de software que ofrecen al usuario una interacción amigable y
cómoda, aunque la característica más importante es que su implementación se realiza en el dispositivo del cliente, un entorno de escritorio por
lo general consiste de iconos, ventanas, barras de herramientas, carpetas, y fondos de pantalla.
Como política general de Consorcio, son desarrollados utilizando herramientas Microsoft, su capa de datos debe basarse en SQL Server.
2.1.2. Aplicaciones ABS
Agile Business Suite es un entorno de desarrollo orientado a modelos, creado por Unisys, destinado a soportar soluciones de misión crítica,
compuesto por una capa de desarrollador y una de Runtime para cada una de las dos plataformas compatibles, ClearPath MCP y Windows ii.
La capa de datos en la actualidad corresponde a una implementación Microsoft SQL Server, en el gestor de aplicaciones, se encuentra el nivel
de negocio, el cual traduce los desarrollos ABS en componentes de negocio e interfaces gráficas accesibles vía browser. Consta de SERVIDOR
SQL SERVER, SERVIDOR IIS y GESTOR DE APLICACIONES ABS por parte del servidor y CLIENTES LIVIANOS.

Página 14 de 132
VERSIÓN 4
2.1.3. Componentes o Ensamblados
Como norma general en Consorcio, estos componentes deben ser elaborados utilizando herramientas Microsoft, se denomina ensamblado a
toda lógica compilada en un archivo de tipo EXE o DLL conformada por código CIL, y ejecutada por el CLR.
La lógica podría incluir cuantas clases y namespaces se requieran, de igual manera puede invocar otros componentes o ensamblados.
Para definir el entorno de ejecución de los ensamblados, se pueden involucrar decoradores como: COM+, DCOM, Remoting iii.
Si se requiere una capa de datos, la misma deberá estar implementada utilizando la plataforma SQL Server de Microsoft.
2.1.4. Componentes de Extracción Transformación y Carga.
Debido al propósito exclusivo de estos componentes, estarán ubicados dentro del nivel de gestión de datos estándar de Consorcio, es decir
Microsoft SQL Server, se encargan del transporte masivo de información desde un formato y plataforma origen, hacia una plataforma y formato
destino.
Dada su funcionalidad de gestión masiva, la ejecución de estos componentes es por lo general nocturna para procesos BATCH.
La implementación y ejecución de estos componentes, solamente realizarse en SSIS (sql server information services).
2.1.5. Aplicaciones WEB
La principal característica de una aplicación web, es que la lógica se encuentra del lado del servidor, no del cliente. Dicha lógica puede
comprender varias capas diferentes, como datos y presentación. Ofrecen al usuario una interacción amigable y cómoda, por lo general consiste
de iconos, ventanas, barras de herramientas, carpetas, y fondos de pantalla.
Como política general de Consorcio, son desarrollados utilizando herramientas Microsoft, su capa de datos debe basarse en SQL Server.
Deben permitir fácil navegabilidad desde los browser predominantes en el mercado, actualmente (internet explorer, Chrome, Firefox, Safari).

Página 15 de 132
VERSIÓN 4
2.1.6. Componentes de Bus de Servicio.
Debido al propósito exclusivo de estos componentes, estarán ubicados dentro de la capa de transporte de datos estándar de Consorcio, es
decir la plataforma de Bus Empresarial de Servicios TIBCO, se encargan de labores de reutilización y composición de código, transporte y
transformación de información.
En Consorcio, la plataforma ESB está siendo utilizada en el despliegue de servicios web, en la modalidad de “Publicación”, y la implementación
de agentes, dedicados a la automatización de labores repetitivas de gestión de información.

Página 16 de 132
VERSIÓN 4
2.2. ARQUITECTURA DE SEGURIDAD
Consorcio cuenta con una plataforma general centralizada y transversal a todas las soluciones, de obligatoria implementación, cuya finalidad
es la administración y la operación, de los requerimientos de seguridad para cada tipo de consumidor:
a) Aplicaciones y servicios que consumen bases de datos.

b) Aplicaciones que consumen otras aplicaciones.
c) Aplicaciones que consumen servicios.
d) Servicios que consumen otros servicios.
e) Usuarios que utilizan aplicaciones.
En los casos anteriores, se debe seguir un conjunto de requisitos de parametrización, e integración del componente FRAMEWORKNET2, el
cual fue desarrollado en Consorcio, implementando tecnología de Microsoft .Net, con el fin de facilitar las labores de autenticación y autorización,
de toda unidad de solución lógica 7 de Consorcio.
2.2.1. Acceso a Bases de Datos
Toda unidad de solución lógica que requiera acceso a las bases de datos de Consorcio, deberá contar con una gestión previa de nivel de
seguridad y acceso, la herramienta utilizada para realizar dicha gestión es ADMINUS, en cabeza del proceso denominado “Gestión de
Identidad”, la capa encargada al interior de cada unidad de solución lógica, de procesar el acceso a base de datos es el componente
FRAMEWORKNET2.DLL.
Como resultado de lo anterior, ninguna unidad de solución lógica, podrá incluir parámetros de credenciales, ni cadenas de conexión, en archivos
locales de configuración (WEB.CONFIG, APP.CONFIG, APLICACIÓN.INI), ni en tablas de bases de datos.
2.2.2. Aplicaciones de escritorio:
Para implementar el modelo de seguridad de Consorcio, se debe involucrar el componente FRAMEWORKNET2, los niveles de autorización
así como los usuarios autenticados, deberán ser previamente definidos en la aplicación ADMINUS.
7 aplicación, servicio web, componente

Página 17 de 132
VERSIÓN 4
2.2.3. Aplicaciones y servicios WEB:
Para implementar el modelo de seguridad de Consorcio, se debe involucrar el componente FRAMEWORKNET2, los niveles de autorización
así como los usuarios autenticados, deberán ser previamente definidos en la aplicación ADMINUS.
Cualquier aplicación o servicio web implementado en la DMZ, deberá utilizar el protocolo seguro de transferencia de hipertexto (HTTPS), y
adicionalmente deberá incluir certificados web, para soporte de transacciones seguras, respetando y aplicando las políticas para acceso a las
capas subyacentes de datos (servicios web y bases de datos).
Algunas aplicaciones o servicios web, pueden requerir del consumo de otros servicios web, para lo cual también se debe involucrar el modelo
de gestión de seguridad ADMINUS, el cual incluye funcionalidades para facilitar dichos accesos.
8
2.2.3.1. Utilización de COOKIES.
La implementación del mecanismo de sesión basado en cookies ofrece múltiples características de seguridad, que pueden ser aprovechadas
mediante los atributos que ofrecen dichas COOKIES para proteger el intercambio de información de identificación de la sesión:
1. Atributo “Secure”
Este atributo indica a los navegadores que la cookie solo puede ser enviada a través de una conexión HTTPS cifrada (SSL / TLS).
En CONSORCIO, dicho mecanismo de protección es obligatorio, para aquellas implementaciones extranet, con el fin de evitar la divulgación
de la ID de sesión a través de ataques de tipo MitM (man-in-the-Middle), lo anterior asegura que un atacante no puede simplemente capturar
el identificador de sesión de tráfico desde su navegador web.
Adicionalmente, obliga a que la aplicación web utilice únicamente protocolo HTTPS para comunicación (incluso en los casos en los que el
puerto TCP: 80, esté cerrado en el host de aplicaciones web).
2. Atributo “HttpOnly”
8 https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Cookies

Página 18 de 132
VERSIÓN 4
Este atributo instruye a los navegadores para no permitir que las secuencias de comandos (por ejemplo JavaScript o VBScript) tengan la
capacidad de acceder a las cookies a través del objeto DOM document.cookie. Esta protección de ID de sesión es obligatoria para evitar
el robo de ID de sesión a través de ataques XSS.
3. Atributos dominio y la ruta (Domain and Path)

El atributo " Domain", instruye a los navegadores de Internet para enviar la cookie, únicamente al dominio y subdominios especificados.
Si este atributo no se establece, la cookie se envía por defecto únicamente al servidor de origen.
El atributo cookie " Path" indica a los navegadores que deben enviar la cookie solamente dentro del directorio o subdirectorios especificados
en la aplicación web, si este atributo no se establece, el comportamiento por defecto, es que la cookie se envía únicamente al directorio (o
ruta) del recurso solicitado.
Estableciendo un valor demasiado permisivo para el atributo " Domain", tal como "ejemplo.com", permite que un atacante lance ataques
contra los identificadores de sesión (COOKIES) entre diferentes servidores y aplicaciones web del mismo dominio, a través del subdominio.
Se debe tener en cuenta que en el caso contrario no se debe establecer (restringiendo la cookie sólo para el servidor de origen).
Además, no se recomienda mezclar aplicaciones web con diferentes niveles de seguridad dentro del mismo dominio, ya que las
vulnerabilidades, al interior de cualquiera de las aplicaciones web, permitirían a un atacante establecer el identificador de sesión de las
demás aplicaciones, lo cual es una técnica que se puede utilizar en los ataques de fijación de sesión.
Aunque el atributo de "Path" permite el aislamiento de los identificadores de sesión entre diferentes aplicaciones web utilizando diferentes
caminos en el mismo host, se recomienda no ejecutar diferentes aplicaciones web (en especial de diferentes niveles de seguridad o ámbitos)
en el mismo host.
4. Atributos Caduca y Max-Edad (Expire, Max-Age)

Es obligatorio, hacer uso de los tipos de cookie “no persistentes” (o de sesión), para la gestión de sesiones, a fin de que el identificador de
sesión no se quede en la memoria caché del cliente Web durante largos períodos de tiempo, en donde un atacante puede obtenerlo.
Tener en cuenta que el atributo "max-age" tiene preferencia sobre "Expire", y puede convertir una cookie en persistente, como
consecuencia el navegador almacenará en el disco duro hasta que alcance la fecha de caducidad.

Página 19 de 132
VERSIÓN 4
Lineamientos generales para CONSORCIO.

• Asegúrese de que la información sensible, que deba incluirse en una Cookie, no sea persistente, adicionalmente debe estar cifrada.
• Utilizar la propiedad “Secure” permite evitar la transmisión accidental de información de una manera no segura.
• Determinar todas las transiciones de estado en el código de la aplicación, para poder controlar eficazmente las COOKIES.
• Definir todas las cookies utilizadas por la aplicación, su nombre y porqué son necesarias, dicha información deberá quedar consignada
en el instructivo técnico de la aplicación.
• Las COOKIES son vulnerables a los ataques de suplantación de DNS / secuestro / intoxicación, un atacante puede manipular la
resolución de DNS para forzar al navegador web, a que revele el identificador de sesión de un host o dominio dado.
• Si desea acceder a mayor información acerca de la prevención de trucos, consulte la hoja de Prevención de trucos OWASP-
PREVENCIÓN DE TRUCOS.
2.2.4. Aplicaciones ABS:
La plataforma ABS, efectúa mediante un modelo propio denominado Gestor de Aplicaciones ABS, la administración y operación de niveles de
autenticación y autorización, consta de un módulo de seguridad para AF y otro para ALDH, los cuales son los encargados de operar el acceso
a cualquier lógica, y a la base de datos.

Página 20 de 132
VERSIÓN 4
2.3. ARQUITECTURA DE BASE DE DATOS
Como se ha indicado anteriormente, La plataforma estándar para implementación de modelos y componentes de base de datos en Consorcio,
es Microsoft SQL Server, basada en una arquitectura centralizada en cuanto a operación y administración.
En cumplimiento de la política para implementación, en lo relacionado con capas bajamente acopladas, las operaciones deN acceso a datos,
desde cualquier tipo de unidad de solución lógica, se debe efectuar mediante el ensamblado FRAMEWORKNET2.DLL, disponible en
SharePoint.
Con el fin de optimizar el desempeño y utilización de los recursos de base de datos, se deben implementar objetos que permitan una compilación
efectiva y aplicación de planes de ejecución, por parte de los motores de base de datos, como en el caso de los procedimientos almacenados.
No está permitida la implementación de instrucciones TRANSACT-SQL dinámicas, ni objetos LINKEDSERVER.
No está permitida la implementación de TRIGGERS, cualquier excepción a esta directiva, deberá ser consultada con el planificador de negocio
asignado.
El tiempo de respuesta para transacciones de consulta, no podrá superar los 1000 milisegundos (1 segundo), y para transacciones de
actualización de información, no se podrán superar los 2000 milisegundos (2 segundos).

Página 21 de 132
VERSIÓN 4
3. ESTÁNDARES DE DESARROLLO DE SISTEMAS DE INFORMACIÓN
3.1. REGULACIONES BÁSICAS GENERALES DE LAS APLICACIONES
La plataforma encargada del versionamiento y repositorio de fuentes en Consorcio es Microsoft TFS, en dicha plataforma se encuentra
disponible un proyecto plantilla, el cual puede ser descargado y utilizado como guía de los nuevos esfuerzos de desarrollo que la organización
requiera.
La ruta de acceso a dicho proyecto es $/ESTANDARES_GD/Source/MAIN/Produccion/EstandarWeb.
3.1.1. Modelo De Datos
Toda implementación debe basarse en un modelo de capas, de ser posible aplicando el enfoque modelo–vista–controlador (MVC), el cual es
un patrón para arquitectura de software en el cual los datos y la lógica de negocio de una aplicación se hallan separados de la interfaz de
usuario y del módulo encargado de gestionar los eventos y las comunicaciones.
Toda implementación debe ser independiente de los formatos regionales de la máquina local en la cual está instalado:
• El formato fecha, a utilizar será AAAA/MM/DD

• El formato hora, a utilizar será HH:MM:SS.CS
• El formato moneda, a utilizar será pesos colombianos, a menos que las necesidades del negocio requieran la aplicación de otro
formato.
3.1.2. Modelo De Datos para servicios web
Solamente se permiten tipos de dato nativo para el i/o de servicios web, en el documento de políticas SOA de consorcio, se puede encontrar
mayor información de los formatos permitidos.

Página 22 de 132
VERSIÓN 4
3.1.3. Formato de datos
• Se recomienda utilización del estándar de codificación de texto ISO-8859-19, principalmente.

• Los archivos para almacenamiento temporal de datos deberán ser de tipo plano, separados por caracteres, se sugiere el carácter
pipe |.
3.1.4. Parametrización de Unidades de Solución Lógica (Aplicaciones, servicios, componentes etc.)
No se permite el “quemado” de datos 10, las aplicaciones deben adoptar mecanismos de consulta de los archivos app.config o web.config,
según sea pertinente, para administración de toda aquella información de configuración que cada implementación requiere.
La capa de conexión a base de datos, es administrada por el componente de seguridad de consorcio FRAMEWORKNET2, el cual se encarga
de gestionar también el consumo de los dispositivos SQL de datos, por lo tanto en dichos archivos tampoco se debe incluir información de
cadenas de conexión, tampoco se deben incluir credenciales de acceso, a menos que dicha información esté encriptada.
En caso de que se modifique alguno de los parámetros que conforman las cadenas de conexión, (Cambio de nombres a servidores, cambio de
cuentas de usuario, etc.) es responsabilidad del equipo de Operaciones y Soporte el actualizar dicha información en la plataforma “Adminus”.
3.1.5. Sistema Operativo
Dando alcance a lo establecido por la política de seguridad, ninguna unidad lógica de solución podrá hacer escritura, ni almacenar información
en el registro de Windows, aunque sí, es permitido consultar los parámetros existentes.
3.1.6. Implementación
9 http://www.iso.org/iso/catalogue_detail?csnumber=28245
10 https://es.wikipedia.org/wiki/Hard_code

Página 23 de 132
VERSIÓN 4
Es responsabilidad de todo líder de aplicación, mantener actualizadas las unidades de solución lógica bajo su responsabilidad, con las últimas
versiones de las librerías de uso general. Ejemplo: FRAMEWORKNET2.
La herramienta definida para la construcción de reportes es Microsoft Reporting Services.
Toda unidad de solución lógica, debe incluir una funcionalidad intuitiva y de fácil acceso, destinada a la auto-validación de disponibilidad,
también denominada “Módulo de Test”, las características de dicho módulo se describen con mayor detalle en el punto Procedimiento de Test,
el cual será explorado más adelante.
3.1.7. Desarrollo Módulos Genéricos, Librerías Y Componentes
Las librerías de uso general deben estar debidamente documentadas explicando su propósito, funciones, parámetros de entrada y salida, etc.
El documento debe reposar en TFS, según los lineamientos establecidos en el documento de políticas TFS.
El desarrollo de librerías de uso general debe ser controlado por un ingeniero de desarrollo encargado de mantener el control de los códigos
fuentes en TFS y otorgar acceso solo a los ingenieros de desarrollo que vayan a modificarlas siempre bajo el modelo de control de versiones
de TFS.
Una vez liberada una nueva versión de un módulo genérico se establecerá un tiempo límite para que todas las aplicaciones que hacen uso de
dicho módulo actualicen a la nueva versión

Página 24 de 132
VERSIÓN 4
3.2. ESTÁNDARES PROGRAMACIÓN
3.2.1. Generalidades
El lenguaje de programación utilizado oficialmente en los esfuerzos de desarrollo en Consorcio es Visual Basic.
Todos los módulos dedicados al mantenimiento de datos deben incluir específicamente los botones “Nuevo”, “Modificar”, “Buscar”, “Eliminar”,
“Salir”, implementando un enfoque CRUD11, se sugiere implementar las herramientas ofrecidas en .NET, en este caso la interfaz IUpdatable.
Los botones de minimizar, maximizar y cerrar de las formas deben estar ocultos. Esto quiere decir que una ventana se puede abrir o cerrar sólo
a través de opciones de navegación en el sistema.
Todas las formas deben ser modales (no permitir abrir otras sin haber cerrado la actual).
Siempre que el sistema esté procesando, se debe modificar la apariencia del cursor.
Utilizar Option Explicit para evitar el manejo de tipo Variant, se debe evitar el uso de variables globales.
No utilizar tildes, Ñs, ni caracteres difíciles de ubicar en otros idiomas para la denominación de cualquier objeto
• Las consultas masivas de información se hacen utilizando ListViews e incluyendo criterios de búsqueda.
11 http://blogs.microsoft.co.il/gilf/2008/08/31/how-to-perform-crud-operations-in-adonet-data-services-with-custom-provider/

Página 25 de 132
VERSIÓN 4
3.2.2. Nombramiento de Variables
No utilizar tildes, Ñs, ni caracteres difíciles de ubicar en otros idiomas, el nombre de la variable consta de dos partes principales:
Tipo + Nombre Variable
Nombre de la variable
Tipo de dato
La identificación del Tipo de Dato que maneja la variable se hará utilizando un prefijo de tres letras así:
TIPO DE DATO / OBJETO PREFIJO

Integer Int
Long Lng
Single Sng
Double Dbl
Bolean Bln
String Str
Date Dat
Variant Var
Definido por el usuario Usr
rdoResulset – Recordset Rs
Conexión Cn
Item Itm
Columnheader Clm
Para el Nombre de la Variable se debe utilizar la primera letra de cada palabra en mayúscula y el resto en minúscula.
Ejemplo: strCodigoUsuario variable texto del Código del usuario

Página 26 de 132
VERSIÓN 4
RsEmpresa variable de tipo recordset para Empresas

dblValorTotal variable doble que guarda el Valor Total
3.2.3. Nombres de Controles, Formularios, Módulos y Funciones
Utilizar los mnemónicos para los nombres de controles y formas con notación polaca. Por ejemplo:
CONTROL / OBJETO PREFIJO

Check Box Chk
Combo Box Cbo
Command Button Cmd
Directory List Box Dir
Drive List Box Drv
File List Box Fil
Form Frm
Frame Fra
Image Img
Label Lbl
List Box Lst
List View Lvw
Menú Mnu
Option Button Opt
Picture Box Pic

Página 27 de 132
VERSIÓN 4
Shape Shp
Text Box Txt
Timer Tmr
Tree View Tvw
Los nombres de los formularios y módulos deben coincidir en la propiedad Name y el nombre con que se guarda el archivo.
La estructura para la definición de nombres de formularios y módulos es:
Nombre forma FrmNombreForma

Nombre módulo ModNombreModulo
Nombre Clase clsNombre
significativo de la función de la clase
Para el nombre de la forma y módulo se utiliza notación polaca, la primera letra de cada palabra significativa en mayúscula y el resto
en minúscula.
Ejemplo:
Objeto Nombre Archivo

Formulario frmConsultaEmpresas frmConsultaEmpresas.frm
frmMantenimientoEmpresas frmMantenimientoEmpresas.frm
Módulo ModImpresion modImpresion.bas
Clase clsDatosUsuario clsDatosUsuario.cls
3.2.4. Utilización de componentes

Ver Uso adecuado de componentes de terceros (APIs, Frameworks, Librerías, Nuggets y Plugins)

Página 28 de 132
VERSIÓN 4
3.2.5. Documentación de fuentes
La lógica de los formularios debe ir documentada en la medida que se requiera especificar validaciones, condiciones especiales, modificaciones
en comentarios, procesos importantes, etc., de manera que cualquier ingeniero pueda comprender la ejecución de la misma.
En las funciones de módulos y las generales de cada formulario se debe indicar:

Autor
Ultima fecha de modificación
Propósito
Parámetros y Salidas
3.2.6. Manejo de clases
Las clases tienen un tratamiento especial, debido a que son la base para el desarrollo Orientado por Objetos. Es por eso que se deben tener
en cuenta las siguientes consideraciones:
Las propiedades nunca se definen como variables públicas directamente. Se deben definir utilizando las propiedades para tal fin PROPERTY
GET, PROPERTY SET Y PROPERTY LET. Internamente a la clase se manejan variables locales sobre las cuales se efectúan todas las
operaciones. Esta variable local se transfiere a la propiedad PROPERTY GET cuando es requerida, y las propiedades PROPERTY SET y
PROPERTY LET transfieren los datos recibidos a la variable local.
Los proyectos de tipo ACTIVEX DLL deben, después de ser generado por primera vez el DLL, tener COMPATIBILIDAD DE PROYECTO, hasta
que éste se encuentre en estado avanzado. Cuando la interfaz (propiedades y métodos) está definida totalmente, debe tener COMPATIBILIDAD
BINARIA con el dll.
3.2.7. Acceso a las bases de datos
Conexión
Se debe utilizar las funciones del frameworknet2.
Procesos

Página 29 de 132
VERSIÓN 4
Implementar el uso Stored Procedures que permitan mejorar tiempos de respuesta siempre que sea posible. Por ejemplo en procesos repetitivos
de búsqueda, actualización e inserción de registros.
Todos los manejos y consultas de información se harán con las estructuras SQL Estandar.
3.2.8. Gestión de Errores

Toda unidad de solución lógica (aplicación, servicio, componente) deberá incluir en su arquitectura (capa transversal de utilitarios), un
mecanismo para el registro, almacenamiento y consulta (autorizada) de la información de errores, en donde se especifique:
1. Id de tipo numérico identity, asignado al error.
2. Fecha y hora exacta de aparición del error.
3. Módulo de la aplicación en la que se presentó el error. En los servicios web, se deberá incluir información de la operación web, afectada.
4. En los servicios web, se deberá incluir la dirección IP consumidora.
5. En los servicios web, se deberá incluir la implementación XML (datos y estructura) de entrada.
6. Respuesta del sistema/mensaje de error, incluyendo el “stack trace” completo sin truncamientos.
Por razones de seguridad, la información de error retornada por el sistema, no deberá ser visible para el usuario final, razón por la cual se
deberá categorizar la presentación de información, de la siguiente manera:
1. Para errores funcionales (de negocio) se presenta la información completa.
2. Para errores no funcionales, se deberá presentar una ventana, informando que un error se ha presentado, pero sin desplegar
información técnica del mismo, en lugar de ello se desplegará el id asignado al error:
El Id desplegado, permitirá al personal autorizado consultar la información del error presentado, y tomar las medidas pertinentes.
3.2.8.1. Manejo de log de errores mediante FRAMEWORKNET2

Página 30 de 132
VERSIÓN 4
Para implementaciones web, se deberá consumir la clase del componente CLogError del componente estándar FRAMEWORKNET2, en cuyo
método construct se deben incluir los siguientes objetos:
• El objeto descriptor del error, de tipo Exception.
• El objeto descriptor del estado de la sesión HttpSessionState.
• El objeto descriptor del request realizado HttpRequest.
Dependiendo de las necesidades transaccionales o de operación, el mecanismo de almacenamiento, podrá estar basado en dispositivo de
base de datos, archivos secuenciales, o en el log de eventos local, lo cual se deberá indicar en el WEB.CONFIG de la aplicación, en el área
AppSettings, de la siguiente manera:
• Variable "ErrorLoggingLogToEventLog" valor TRUE

• Variable " ErrorLoggingLogToFile" valor TRUE
• Variable "ErrorLoggingLogToDB" valor TRUE
Solo una de las variables podrá contener el valor TRUE.
Finalmente, se invoca el método LogError, el cual se encargará de almacenar la información de error.
3.2.8.2. Estándar para despliegue de errores.
Dentro de cada proyecto WEB, el despliegue de errores, deberá basarse en el estándar estructurado para CONSORCIO, en la plataforma TFS,
en la ruta $/ESTANDARES_GD/Source/DEV/Integrador/EstandarWeb, se encuentra un proyecto web plantilla, que puede ser integrado a
cualquier proyecto.

Página 31 de 132
VERSIÓN 4
En dicho proyecto, se puede encontrar la página para despliegue de errores “frmError.aspx”, dicha página permite visualizar los mensajes de
error, mediante la utilización de la variable de sesión Session("errmsg"), en la cual se debe almacenar el contenido del mensaje de error a
desplegar.
3.2.8.3. Utilización del bloque TRY-CATCH (control de errores)
Coloque las secciones del código que pueden producir excepciones en un bloque Try y el código que controla excepciones en un bloque Catch.
El bloque Catch es una serie de instrucciones que comienzan con la palabra clave catch seguida por un tipo de excepción y la acción que se
debe tomar.
La utilización del bloque try-catch es obligatoria, todo error debe ser atrapado y gestionado, de acuerdo con los estándares establecidos.

Página 32 de 132
VERSIÓN 4
3.2.8.4. Propagación de errores (control de errores)
Para propagación de errores, cada capa debe incluir un mecanismo para propagación de instancias del objeto System.exception, nativo del
framework de .net.
La gestión, despliegue o administración de errores estará basada en System.exception.
3.2.8.5. Base de Conocimiento
Se debe incluir en la documentación técnica, Descripción general y detallada de los mensajes de error que se presentan en el aplicativo y la
explicación de la causa y acción para corregirlo. Los errores deben estar codificados mediante la siguiente estructura:
xxxxxxx-yyy-Mensaje de error
xxxxxxx: Código de la aplicación

yyy: Consecutivo por aplicación:
Mensaje de error: Mensaje breve sobre el error presentado
Acción a seguir Breve descripción de la solución al problema.
Ejemplo:
SW-PR-01-001 Error número 001 de la aplicación “Autorización Servicios médicos ambulatorios” (SW-PR-01).
Mensaje de error: Error en la digitación del doc.identificación.
Acción a seguir: Digite letras, comas, puntos y caracteres especiales el doc.identidad.

Página 33 de 132
VERSIÓN 4
3.3. ESTÁNDARES DE INTERFAZ GRÁFICA PARA APLICACIONES DE ESCRITORIO
3.3.1. Barras de Menú.

Conjunto de opciones basadas principalmente en texto, que exponen y brindan acceso directo a funcionalidades disponibles en un sistema. La
barra de menú se sitúa en la parte superior de la ventana, bajo el título.
3.3.2. Barras de Herramientas.

Conjunto de opciones basadas principalmente en elementos iconográficos, que facilitan la ejecución de operaciones en la ventana que se
encuentra activa. Las barras de herramientas generalmente contienen las funciones más usadas por el usuario.
3.3.3. Ventanas.
Se denomina ventana a un área delimitada rectangularmente en pantalla, destinada al despliegue de características visuales que faciliten
interacción entre la funcionalidad y el usuario. Sus características principales son:
• Deben aparecer centradas en la pantalla.

• No deben permitir ampliación o reducción en tiempo de ejecución.
• El título de la ventana principal debe llevar el nombre de la entidad y el proceso de negocio correspondiente.
• La operación de la ventana debe realizarse de izquierda a derecha y de arriba abajo. Para desplazarse entre los campos de dicha
ventana, se debe implementar lógica basada en la tecla de tabulación.
• En la barra de estado se debe desplegar el usuario, la fecha y hora.
Tipos de Ventana.
De acuerdo con el tipo de información gestionada, y la funcionalidad de la ventana se tendrán características especiales. A continuación se
presentan prototipos para cada una de ellas:
Ventana De visualización y consulta de múltiples registros:

Página 34 de 132
VERSIÓN 4
• Deben utilizar controles y lógicas definidas para el diseño y manejo estándar de la funciones básicas dentro del formulario.
• El texto desplegado en los botones de mantenimiento deben siempre corresponder con las operaciones: Nuevo, Eliminar, Modificar,
Buscar, Imprimir, Grabar, Cancelar y Salir.
• El contenido de los registros resultado de las consultas masivas de información, se debe desplegar utilizando controles “ListView” e
incluyendo criterios de búsqueda.
De ingreso de información o consulta de un registro:
• Deben utilizar controles y lógicas definidas para el diseño y manejo estándar de la funciones básicas dentro del formulario.
3.3.4. Mensajes Emergentes.
Información que el sistema entrega al usuario, relativa a las actividades que se están realizando.
• La ventana de los mensajes debe aparecer centrada respecto al área de trabajo del usuario y llevar el título correspondiente al tipo de
mensaje
• Los mensajes son justificados a la izquierda en el área de mensajes.
• Usar frases cortas.
• Todos los mensajes deben ser en español y deben presentar un icono de representación de acuerdo con el tipo de mensaje.
Página 35 de 132
VERSIÓN 4
• Toda acción que ejecute el sistema debe ser informada al usuario a través del uso de mensajes. No se debe dar nada por sentado.
• El mensaje siempre debe ir acompañado de los botones de acción necesarios para procesar la decisión del usuario con el que
interactúa.
Los mensajes pueden ser de cinco tipos:
Tipo Mensaje Caso de Uso Icono Botones

Cuando ocurre un evento inesperado pero
Advertencia Exclamación Aceptar
puede continuar la ejecución
Cuando es necesario hacer saber al usuario
un suceso que no cambia el curso de la
Información Información Aceptar
aplicación en ese momento pero podría ser
relevante posteriormente.
Cuando es necesario verificar con el usuario Si
Confirmación interrogación
si una acción debe ser realizada o no No
Cuando ocurre un evento inesperado que no
permite continuar la ejecución normal. Se
Error Error Crítico Aceptar
utilizará el título de “Error” con el icono de
mensaje crítico y el botón de Aceptar
Cuando alguna operación que se iba a
Error Base de Datos ejecutar sobre la base de datos no se pudo Error Crítico Aceptar
realizar exitosamente
3.3.5. Campos.
Área de una ventana, destinada a la recepción de información, proveniente del usuario. Con el fin de facilitar el proceso de ingreso de
información, se puede hacer uso de una amplia variedad de componentes denominados controles, los cuales abordan la tarea de gestión de la
información, a través de diversas estrategias, como listas de selección múltiple o sencilla, controles de especificación excluyente o cooperante,
texto libre, texto formateado, etc.
• Campos para gestión de fechas: Independiente del control de información utilizado, el formato de fecha a aplicar, deberá estar basado
en la configuración europea (aaaammdd), sin separadores. La gestión de ingreso de información, Se debe utilizar control de Windows
MONTH-CALENDAR. No se recomiendan los controles de enmascaramiento.

Página 36 de 132
VERSIÓN 4
• Campos de valor numérico: Los valores numéricos deberán estar alineados a la derecha, incluyendo siempre los signos
correspondientes según su funcionalidad, para pesos ($), porcentajes (%), o contabilidad (C/D). Cuando se requieran separadores de
miles se debe utilizar el carácter coma (,), y finalmente el separador de decimales será caracterizado mediante el carácter punto (.).
456,879
$ 456,879
79 %
• Campos Deshabilitados: Son aquellos campos, bloqueados para interacción cuyas letras son de color gris, siendo generalmente
resultado de una consulta.
En todo momento el aspecto predominante debe ser el estándar del sistema operativo Windows. No se deben aplicar estilos (colores, tamaños
ni controles) diferentes a los observados en las interfaces gráficas estándar.
3.3.6. Operación mediante Teclas de función.

Combinaciones especiales de teclas que se usan para activar rápidamente una opción dentro del sistema.
3.3.7. Operación basada en dispositivo mouse.

Se debe mantener un comportamiento estándar de los componentes de la aplicación, para generar una percepción de integralidad y
consistencia en el usuario, esto incluye el uso de botones del mouse y el despliegue de información gráfica, desencadenado como respuesta
a los estímulos externos.
Seleccionar una opción, ventana, icono, o control, significa situar el puntero del mouse directamente encima de uno de estos elementos y
accionar una o dos veces alguna de las teclas del mouse, o girar la rueda de dicho dispositivo.
De acuerdo con la información gráfica desplegada, el indicador permite de manera fácil, determinar el estado actual de la aplicación:
Indicador Significado
Permite al usuario interacción con cualquiera de los elementos ubicados en la
Flecha
pantalla incluyendo opciones de menú, y operación de ventanas
Indica que el sistema se encuentra en modalidad de edición de texto, a la espera
Cursor
del ingreso de información.

Página 37 de 132
VERSIÓN 4
El sistema se encuentra a la espera de que la ejecución de un proceso finalice.
Reloj de arena En esta modalidad temporal, el usuario experimentará una disponibilidad

reducida a nula por parte del sistema.
3.3.8. Distribución Espacial (Alineación, Agrupación y Espaciado).
Se refiere a la disposición visual de los elementos que se incluyeron en una ventana, una adecuada distribución favorece de manera equilibrada,
la usabilidad y la estética. Específicamente, define la manera como se deben posicionar los elementos activos y pasivos de una interfaz gráfica
de usuario, con respecto a otros elementos y a la ventana que los contiene, por ejemplo las etiquetas y su visualización con respecto al control
texto que definen, pero también con respecto a la ventana en la cual está ubicada dicha etiqueta, dos elementos relevantes en este aspecto
son la alineación y el espaciado.
El contenido de los controles de tipo etiqueta o “label”, se alineará a la derecha y se adicionará siempre un carácter espacio, seguido del
carácter dos puntos (:).
Los cuadros de texto o “textbox”, deberán alinearse principalmente a la izquierda, pero las condiciones del tipo de dato administrado, podrán
variar este lineamiento.
Finalmente, si las necesidades del negocio imponen establecer un criterio de agrupación, entre algunos de los elementos que están contenidos
en una ventana, se deberá utilizar un control “PANEL” el cual incluirá en la esquina superior izquierda, un título que ilustre el criterio definido
para el grupo de controles que lo componen.
3.3.9. Estilos de letra.
El color de fuente a aplicar, en todos los controles es el negro (#000000), de igual manera el tamaño a aplicar es 8 y la fuente estándar es “Ms
Sans Serif”. El texto de los controles de tipo botón “Command Button”, incluirá una letra inicial en mayúscula, si se requiere, dicha letra cumplirá

Página 38 de 132
VERSIÓN 4
la función de acceso directo, al ser combinada con alguna de las teclas de función especial (Ctrl o Alt), en cuyo caso dicha letra aparecerá
subrayada.
3.3.10. Apariencia General y Percepción de Usuario (Look & feel)
Las ventanas deben ofrecer un aspecto y funcionalidad, basados en el estándar del sistema operativo Windows, con el fin de permitir que
cualquier usuario familiarizado con dicho sistema operativo, pueda interactuar de manera natural con las aplicaciones desarrolladas. Un ejemplo
TIPO es el “look&feel” ofrecido por el explorador de Windows:

Página 39 de 132
VERSIÓN 4
3.4. ESTÁNDARES DE INTERFAZ GRÁFICA PARA APLICACIONES WEB.
3.4.1. Paleta Cromática
Los valores para la paleta cromática son definidos por el proceso de planeación de negocio, para los cuales se maneja
el siguiente esquema de colores:
Hexa = FDF5F2 Hexa = F4F5F9 Hexa = 003366 Hexa = FFFFFF Hexa = C0C0C0
R=253 R=244 R=221 R=255 R=192
G=245 G=245 G=51 G=255 G=192
B=242 B=249 B=102 B=255 B=192
Hexa = F7D3BA Hexa = E0EBF4

R=247 R=224
G=211 G=235
B=186 B=244
3.4.2. Tipografía
La fuente a utilizar en las GUI12 es VERDANA, es importante tener en cuenta que no en todos los clientes puede estar
disponible dicha fuente, por lo tanto se debe utilizar la familia de fuentes ARIAL HELVETICA VERDANA, con el fin de
evitar errores en el look&feel por ausencia de la fuente principal.
12 https://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario
Página 40 de 132
VERSIÓN 4
Comprende las etiquetas, campos de texto, información de grids y botones.

3.4.3. Nombramiento de elementos gráficos
El proceso para nombrar elementos gráficos, utilizados en las aplicaciones Web, debe aplicar la estructura “xxxNombre.ext”, en donde:
Corresponde a uno de los prefijos definidos en la tabla que se presenta a

Xxx
continuación.
Nombre Nombre nemotécnico asignado al elemento gráfico de acuerdo a su finalidad
Ext Corresponde a la extensión propia del formato del elemento gráfico.
TIPO DE
DESCRIPCIÓN PREFIJO EJEMPLO
ELEMENTO
Banners Elementos gráficos utilizados como banners. bnr bnrCasa.jpg
Botones Elementos gráficos utilizados como botones. btn btnEnviar.gif
Elementos gráficos utilizados como fondos de
Fondos bkg bkgAzul.gif
página o de tabla.
Elementos gráficos que despliegan
Íconos ico icoCasa.gif
información iconográfica.
Se aplica, en forma genérica, a aquellas
Imagen imágenes que no se ubican en ninguna de las img imgglobo.jpg
otras categorías.
Logo Elementos gráficos que representan logotipos. log logEmpresa.gif
Elementos gráficos que representan algún tipo
Mapas map mapMundo.gif
de mapa.
Elementos gráficos que hacen parte de los
Menús mnu mnuInicio.gif
menús de la aplicación.
Títulos Elementos gráficos que actúan como títulos. tit titInicial.jpg
Se aplica en forma genérica a aquellos
Vídeo archivos en formato de vídeo utilizados en la vid vidInfo.avi
aplicación.

Página 41 de 132
VERSIÓN 4
3.4.4. Documentación Integrada (comentarios)
Las páginas HTML deberán contar con un bloque de información inicial que permita identificar claramente la finalidad de la página dentro de la
Aplicación Web, es posible que por necesidades propias de la aplicación no se requiera documentación de algunas páginas, dicho bloque de
información debe estar estructurado de la siguiente manera:

En el espacio “MODIFICACIONES” se debe incluir:

• Ver.: es la versión del archivo HTML –ASPX/ASMX asociada con la modificación.
• Fecha: fecha en la que se realizó la modificación.
• Autor - Empresa: nombre completo de la persona que realizó la modificación, acompañado de la identificación de la Empresa a la que
se encuentra asociada la persona.
• Descripción: descripción general de los cambios realizados.
3.4.5. Diseño WEB Adaptativo (responsivo)
El diseño web adaptable o adaptativo, conocido por las siglas RWD inglés (Responsive Web Design), es un enfoque para el diseño y desarrollo
de soluciones WEB, que tiene como objetivo de manera totalmente automatizada, adaptar visualmente las páginas web al dispositivo que se
Página 42 de 132
VERSIÓN 4
esté utilizando para visualizarlas. Las soluciones tecnológicas implementadas en Consorcio, se deben adaptar a multitud de tipos de dispositivos
como tabletas, teléfonos inteligentes, libros electrónicos, portátiles, PC, etcétera.
Independientemente de la arquitectura de dicho dispositivo tamaño de pantalla, resolución, potencia de CPU, capacidad de memoria, la
plataforma utilizada pretende que con un solo diseño web, se tenga una visualización adecuada en cualquier dispositivo.
Para su implementación, se sugiere utilizar la plataforma BOOTSTRAP 13.
3.4.6. Presentación de Etiquetas HTML ASPX/ASMX
Aunque no se considera conveniente definir una regla rígida de presentación de las etiquetas HTML, se recomienda que su presentación sea
uniforme en todo el sistema.
La Se incluyó el framework bootstrap
Las etiquetas HTML pueden ser presentadas en mayúsculas en toda la aplicación o en minúsculas, pero se espera que se tenga uniformidad
en el sistema.
Es importante considerar que algunas herramientas de desarrollo generan las etiquetas HTML en un formato específico.
3.4.7. Encabezado
El “code behind” de las páginas HTML ASPX/ASMX, debe ceñirse a las definiciones establecidas por el World Wide Web Consortium (W3C) iv,
un encabezado típico incluiria la siguiente estructura básica:
<HEAD>
<TITLE>Título de la página</TITLE>
<META NAME="AUTHOR" CONTENT="ConsorcioSalud">
<LINK REL="stylesheet" HREF=" [Ruta]/Archivo .CSS" TYPE="text/css">
</HEAD>
Los encabezados de las páginas ASPX/ASMX, incluyen información adicional, relativa a las características ambientales de las páginas
gestionadas.
13 https://github.com/twbs/bootstrap

Página 43 de 132
VERSIÓN 4
<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="FrmMenu.aspx.vb" Inherits="SICU.UI.FrmMenu"

%>
Adicional a estos elementos es posible incluir en el encabezado otros elementos que sean necesarios para el correcto funcionamiento de la
Aplicación Web, dichos elementos deben cumplir con los requisitos de seguridad de la organización.
3.4.8. Formularios.
Elemento de abstracción y agrupación de funcionalidad, se define como la sección de un documento que incluye contenido normal, elementos
especiales denominados controles, y las etiquetas de dichos controles v. Los usuarios normalmente diligencian los campos de un formulario
modificando los controles que contiene, puede ser introduciendo texto o seleccionando elementos del menú, de manera previa al envió de dicho
formulario a una entidad destinada al procesamiento de la información entregada (por ejemplo, en un servidor Web, un servidor de correo, etc)
vi.
TIPO DE
ELEMENTO
La etiqueta FORM crea un formulario o forma en
un documento HTML. La forma puede contener
elementos de interfaz tales como: cajas de texto,
Form frm frmLogin
botones, listas de selección. Estos elementos
permiten al usuario ingresar texto y seleccionar
opciones.
A continuación se indican los elementos que deben estar incluidos siempre dentro de las etiquetas <FORM>...</FORM>
3.4.8.1. Elementos INPUT
La etiqueta INPUT define un elemento de forma en el que el Usuario puede ingresar información. El atributo TYPE determina el tipo del elemento
de forma así:
TIPO DE ELEMENTO DESCRIPCIÓN PREFIJO EJEMPLO

Ubica un botón en una forma HTML. Se puede usar código JavaScript
Button btn btnCerrar
para definir una acción para el botón.
Ubica en una forma HTML un elemento que actúa como un interruptor,
Checkbox chk chkTipo1
permitiendo al Usuario activarlo o desactivarlo.

Página 44 de 132
VERSIÓN 4

Ubica en una forma HTML un elemento, similar a una caja de texto, que
permite al usuario proporcionar la ruta y nombre de un archivo. Cuando
File/FileUploas fil filArchivo1
la forma es enviada, el contenido del archivo indicado es enviado al
servidor con los otros datos de la forma.
Especifica un elemento de texto invisible. Un elemento hidden es utilizado
Hidden/HiddenField h hUsuario
para pasar información al servidor cuando una forma es enviada.
Ubica una imagen, que actúa como un botón personalizado, en una forma
Image HTML. Cuando el Usuario hace clic en un elemento IMAGE, la forma es img imgAceptar
enviada al servidor.
Ubica una caja de texto en una forma HTML. Cada carácter ingresado en
Password la caja de texto es mostrado como un carácter similar a * o como puntos pwd pwdClave
negros para ocultar el valor ingresado.
Ubica un botón de opción en una forma HTML. Los elementos de este
Radio /RadioButton tipo pueden ser agrupados en conjuntos, y solamente un (1) botón por rbtn rbtnOpcion
conjunto puede ser seleccionado.
Ubica un botón de reinicio (reset) en una forma HTML. Cuando un
btnLimpiar
Reset Usuarios hace clic sobre este botón todos los elementos en la forma son btn btnCancelar
puestos en sus valores por defecto. btnCerrar
Ubica, en una forma HTML, un botón que permite efectuar el envío de los
BTNENVIAR
Submit btn
datos de todos los elementos de la forma. btnAceptar
Ubica una caja de texto de una línea en una forma HTML. Esta caja de
txtDireccion
Text/TextBox txt
texto le permite al Usuario ingresar texto. txtInfo
3.4.8.2. Elementos de propósito especial
Estos elementos también deben estar incluidos dentro de las etiquetas <FORM>...</FORM>

La etiqueta SELECT define una lista de selección en una forma HTML. Una lista de selección
Select despliega una lista de opciones de las que el usuario puede seleccionar un ítem. La lista de
ListBox lst lstTipo
selección puede permitir la elección de varios elementos al tiempo haciendo uso del atributo
DropDownList
MULTIPLE.

Página 45 de 132
VERSIÓN 4

La etiqueta OPTION especifica una opción en una lista de selección. Esta etiqueta se utiliza dentro
de las etiquetas SELECT. Cuando la forma que contiene la lista de selección es enviada al
No tiene
Option servidor, el par de valores nombre/valor es enviado por cada una de las opciones seleccionadas propiedad
RadioButtonList
en la lista. El valor de una opción es el contenido del atributo VALUE, si lo tiene definido, de otra NAME
forma, es el texto que sigue a la etiqueta OPTION.

La etiqueta TEXTAREA define una caja de texto con múltiples líneas en una forma HTML. Un txtObserva
Textarea
txt txtDes
TextBox área de texto permite al Usuario ingresar palabras, frases o números.
txtNombre
3.4.9. Elementos de Documento

TIPO DE
ELEMENTO
El elemento anchor corresponde a un enlace que hace referencia a un punto dentro del mismo documento
HTML. El elemento anchor se define haciendo uso de la etiqueta <A>, para la cual se asigna un valor al ancRefe
Anchor anc
ancName
atributo NAME.
La etiqueta IMG especifica la imagen que será mostrada en un documento HTML. En el atributo NAME de
este elemento se especifica un nombre que podrá ser utilizado para hacer referencia a la imagen desde
imgIdea
Image funciones JavaScript. img
imgLogo
NOTA: sólo se debe adicionar el atributo NAME a las imágenes cuando éstas deban ser referenciadas desde funciones
JavaScript.
La etiqueta AREA describe un área individual en un mapa de imagen. Un mapa de imagen puede contener
varias áreas sensibles al ratón y cada área puede tener asociado un destino diferente.
Area imaCuadro
ima
Panel El atributo NAME especifica un nombre que podrá ser utilizado desde JavaScript para referenciar el Objeto imaCirculo
AREA.
Map La etiqueta MAP contiene información acerca de las áreas activas en un mapa de imagen.Un mapa de map mapPrincip
al
imagen es una gráfica que puede ser dividida en múltiples áreas y cada una de éstas puede apuntar a
mapPais
diferentes direcciones web.
3.4.10. Marcos (Frames/Panel)
El nombre de los marcos o paneles específicos definidos dentro de los archivos de Frames deben incluir el prefijo fra, o pan como se muestra
a continuación:

Página 46 de 132
VERSIÓN 4
<HTML>
<HEAD> <TITLE>Marco Simple</TITLE></HEAD>
<FRAMESET COLS="20%,80%" BORDER=10>

<FRAME SRC="marco1.htm" NAME="fraSuperior">
<FRAME SRC="marco2.htm" NAME="fraInferior">
<NOFRAMES>El Navegador no soporta marcos.</NOFRAMES>
</FRAMESET>
</HTML>
3.4.11. Títulos y Subtítulos
Los títulos estarán alienados a la izquierda del contenedor, con un margen superior e inferior serán de 5px. La tipografía tendrá un tamaño de
12pt y de color #003366.
Los subtítulos estarán alienados a la izquierda del contenedor de los formularios, con un margen superior e inferior serán de 5 px y un margen
izquierdo de 25px. La tipografía tendrá un tamaño de 10pt en Bold y de color #003366.
3.4.12. Etiquetas y Campos de Texto
Las etiquetas para los campos, tendrán un cuarto de la totalidad del ancho del formulario, el texto estará alienado a la izquierda con un margen
izquierdo de 25px, el superior y el margen inferior serán de 5px y no tendrá un margen derecho.
La tipografía tendrá un tamaño de 8pt en Verdana y de color #000000..
Los campos de texto tendrán un cuarto de la totalidad del ancho del formulario, el texto estará alienado a la izquierda con un margen izquierdo
y derecho de 29px, el superior y el margen inferior serán de 5px. La tipografía tendrá un tamaño de 14px verdana y de color #000000.

Página 47 de 132
VERSIÓN 4
3.4.13. Gestión visual de controles de tipo botón de comando.
Los controles de tipo “botón de comando”, se deben ubicar en la parte inferior derecha de la página, en cuanto a su configuración visual, se
deben aplicar las siguientes definiciones:
• Grises : Los que están por fuera de la aplicación
• Verdes: Los que ejecutan una funcionalidad Ejemplo: Enviar, Aceptar, Nuevo, Siguiente, Guardar
• Azules : Limpiar, Imprimir , Retirar
• Rojos: Cancelar, Terminar, Finalizar
• Naranjas: Modificar, Más información, Generar Archivo, Incumplida
En el caso de Consultar se debe utilizar es Enviar o Aceptar porque el consultar es la funcionalidad de la página o ventana.
3.4.14. Gestión visual de controles de tipo Fecha (“MonthCalendar”).
La implementación de funcionalidad para gestión de fechas, debe incluir un control cuadro de texto cuya objetivo será el de almacenar y
desplegar visualmente la fecha seleccionada, sumado a un control “MonthCalendar” el cual presentará una interfaz gráfica de usuario, que
facilitará la selección de fechas por parte del usuario, a continuación se representa el modelo indicado:
3.4.15. Gestión visual de GRIDS.

Página 48 de 132
VERSIÓN 4
Las tablas de consulta tendrán un encabezado de color # F7D3BA con texto de color #000000, el texto estará siempre centrado en el espacio
el ancho será asignado dependiendo de la cantidad de información de la columnas y sus filas.
Las filas tendrán una configuración visual tipo “Cebra”, en donde se aplicará el color de fondo # FDF5F2 para las filas pares y # F4F5F9 para
las impares, con el texto centrado de color gris #000000 en Verdana de 10pt de tamaño.
3.4.16. Modelo de página para despliegue de mensajes de la aplicación
La siguiente será la distribución de los elementos al interior de la página:
• Título de la página <title>Mensajes / Transacciones </title>

• Mensajes: Nombre del módulo
• Transacciones: Nombre de la aplicación

Página 49 de 132
VERSIÓN 4
Despliegue de mensajes relacionados con los campos obligatorios
3.4.17. Páginas básicas:
Con el fin de facilitar el proceso de estandarización de las aplicaciones de la organización, se han dispuesto plantillas, en la plataforma TFS,
en la capeta denominada Estandares_GD, la cual incluye la totalidad de los elementos necesarios para implementar un sitio web básico,
incluyendo visualización gráfica y de estilos.
3.4.17.1. Página de Inicio de Sesión (Login)

Página 50 de 132
VERSIÓN 4
A continuación se presenta el modelo que se debe implementar en todas las aplicaciones para la página de inicio de sesión.
Explicación de la página de inicio de sesión.
1. Cabecera de página: Imagen corporativa.

2. Formulario de autenticación: Alineación: centrado
Ancho: 550px
Alto: 150px
Tipo de letra: Verdana
NO debe tener: botón cancelar ni casilla para recordar datos de autenticación.
3. 2a Parte de bienvenida: Se presentan cuatro filas de texto

- Aviso de bienvenida: 12px
- Nombre largo de la aplicación: 12px

Página 51 de 132
VERSIÓN 4
- Instrucción de digitar usuario y clave: 11px

- Instrucción de dar clic en el botón de inicio: 11px
4. 2b Parte de autenticación: Fondo: #f5f6fa

Borde: #cccccc
Letra: 12px
5. 2c Imagen: Nombre corto de la aplicación
3.4.17.2. Página de cambio de clave
• Título de la página
• Cambio de clave: Nombre del módulo
3.4.17.3. Modelo de página principal de la aplicación.
Básicamente es un “frame”, compuesto de 3 ventanas, es decir un encabezado ubicado encima de dos columnas, una de dichas columnas
cumple la funcionalidad de árbol de menú, y la otra columna es el cuerpo principal de operación de la aplicación:

Página 52 de 132
VERSIÓN 4
• Título de la página
• Bienvenida: Nombre del módulo

Página 53 de 132
VERSIÓN 4

Página 54 de 132
VERSIÓN 4
3.4.17.4. Modelo de página funcional
• Título de la página <title>Clave Empresas / Transacciones </title>

• Clave Empresas: Nombre del módulo
• Transacciones : Nombre de la aplicación

Página 55 de 132
VERSIÓN 4
Ejemplos de otras páginas funcionales

Página 56 de 132
VERSIÓN 4

Página 57 de 132
VERSIÓN 4
Modelo de página para salida correcta del sistema con la opción de inicio sesión.

Página 58 de 132
VERSIÓN 4
3.4.17.5. Modelo de operación para páginas de Test.
Consideraciones generales:
La funcionalidad de test, debe permitir de manera eficaz verificar la disponibilidad, de todos los recursos que una aplicación requiere para operar
correctamente, incluso para operadores que no estén familiarizados con dicha aplicación (Por esta razón debe ser posible acceder a la página
SIN requerir autenticación en la aplicación), estos recursos pueden ser: accesos a la base de datos, acceso a servicios de integración (Web
Services), acceso a rutas físicas en servidores, acceso a ETLs, componentes, o permisos. Adicionalmente la funcionalidad de test puede usarse
en otro momento para detectar fallas de la aplicación por alguno de sus componentes asociados.
• La página de test debe seguir el estándar gráfico

• Debe mostrar la fecha y hora del test
• Debe evidenciar retorno de datos en los recursos que consulta
• No mostrar información confidencial ni documentos de tipo Pdf Generados.
• Debe incluir el test de todos los componentes que requiere la aplicación para operar, esto significa que si la aplicación o el servicio
utilizan n tipos de consultas diferentes TODAS se deben probar incluso si son del mismo entorno.
• La funcionalidad de test se debe implementar en todo tipo de aplicación, incluyendo Web Services, aplicaciones Web o aplicaciones
de escritorio, para ello se debe constituir una página denominada “Test.aspx” que cuente con la funcionalidad.
• Si es pertinente, la página de test puede incluir otros tipos de prueba como accesos mínimos, accesos críticos, acceso a recursos
externos, inclusive recursos sin los cuales la aplicación puede funcionar, o aquellos que no necesariamente son producto de la
instalación de la aplicación. Todo lo anterior debe quedar completamente claro y detallado en la página de test, de lo contrario se podría
asumir, que todo lo que se halla incluido en la página es de carácter crítico para la aplicación, y podrá convertirse en un factor causal
de devolución de la instalación.
• La página de test debe mantenerse actualizada todo el tiempo conforme avanza el desarrollo, ejemplo: si en algún momento la
aplicación requiere un nuevo componente, recurso o conexión, debe reflejarse una validación adicional en la página de test reflejando
que se puede verificar desde esta página el acceso y funcionalidad del nuevo recurso requerido

Página 59 de 132
VERSIÓN 4
Ejemplo : Modelo de validación de acceso a la Base de Datos
Si la aplicación requiere para su normal operación, acceso a bases de datos, el módulo de test debe permitir establecer una conexión, realizar
una consulta y retornar algunos registros. Un procedimiento de test válido para verificar tanto lectura como escritura puede ser registrar el
acceso del usuario que ingresa a la aplicación en una tabla de auditoría y mostrar el resultado del ingreso en la pantalla, a continuación se
presenta un ejemplo:
Donde se verifica que se registró en el Log la transacción 4394713 en el momento de hacer el test de la aplicación

Página 60 de 132
VERSIÓN 4
Ejemplo : Validación de Acceso a Servicios de Integración (componentes publicados como servicios)
Si la aplicación requiere acceso a servicios de interoperabilidad, es necesario que por cada servicio que se usa, se implemente un escenario
de validación de disponibilidad, si las condiciones imperantes lo permiten, se deben utilizar interfaces que permitan que el usuario simule un
proceso normal de consumo, ingresando parámetros al servicio evaluado y analizando las características de la respuesta obtenida:
Cuando se presenten situaciones en las que la complejidad del servicio evaluado impide este tipo de prueba, se puede omitir el ingreso de los
datos por parte del usuario, pero la herramienta de test deberá asumir dicha tarea, desplegando el contenido de la respuesta obtenida.
Ejemplo : Validación Acceso a rutas físicas en disco u otros accesos que necesite la aplicación
El acceso a otros recursos que no necesariamente retornen información se debe verificar también, un ejemplo de cómo se debe abordar dicho
escenario, podría ser el siguiente:

Página 61 de 132
VERSIÓN 4
Ejemplo de una página de Test Completa que realiza diferentes verificaciones:

Página 62 de 132
VERSIÓN 4
3.5. ESTÁNDARES DE BASES DE DATOS
Gracias a las características de las bases de datos actuales, la longitud de los nombres de los objetos de las mismas no son una limitante, por
lo tanto podemos definir completamente los nombres sin utilizar abreviaturas.
Todos los objetos de las bases de datos se deben identificar de acuerdo con la siguiente estructura:
xx: Tipo de objeto ( tb, sp, vw , fn )

YYY: Prefijo del módulo ó aplicación (LAB, SOR, USS, ORB, ORN, etc.)
Nombre: Nombre del objeto.
3.5.1. Nombres de tablas
Los nombres de las tablas deben ser en singular. Ejemplo: tb_LAB_USUARIO y no Usuarios
Los nombres de las tablas deben ser en mayúsculas en caso de que sean compuestas, se separan por UNDERSCORE ( _ ). Ej:
tb_LAB_TIPO_IDENTIFICACION
3.5.2. Nombres de campos
Los nombres de los campos deben ser en mayúsculas en caso de que sean compuestos, se separan por UNDERSCORE ( _ ). Ej:
IDENTIFICACION_USUARIO
Ejemplo: Para la tabla tb_LAB_USUARIO tenemos los siguientes campos:
CODIGO_USUARIO
DESCRIPCION_USUARIO
CODIGO_TIPO_IDENTIFICACION (referencia a la llave primaria de la tabla Tipo_Identificacion)
3.5.3. Nombres de índices
Se utiliza notación polaca, la primera letra de cada palabra significativa en mayúscula y el resto en minúscula. En caso de ser nombres
compuestos se separan por el carácter underscore ( _ ).

Página 63 de 132
VERSIÓN 4
3.5.4. Nombres de procedimientos
Todas llevan el prefijo sp_ y el prefijo del módulo ó aplicación
Ejemplo: sp_LAB_Busca_Afiliados
3.5.5. Nombres de vistas
Todas llevan el prefijo vw_ y el prefijo del módulo ó aplicación
Ejemplo: vw_LAB_Busca_Afiliados
3.5.6. Nombres de ETLs y Jobs
Se utilizará la siguiente máscara para establecer el nombre de JOBs y ETLs :
AAAA-BBB-CCC-DDD-XXXXXXXXXXXXXXXX
En donde :
AAAA : Sigla de la aplicación asociada con el proceso de acuerdo con las siglas establecidas en el portafolio de aplicaciones
BBB : Tipo de Objeto, (JOB o ETL)
CCC : Periodicidad (Cada cuanto se debe ejecutar), para este caso solo son permitidos los siguientes
DIA : Diario
SEM : Semanal
MEN : Mensual
QUI : Quincenal
PDE : Por Demanda
DDD : Sigla del proceso al que corresponde la ejecución del Job o la ETL, estos se encuentran en el archivo Procesos.xlsx
XXX : Descripción del proceso que ejecuta el Job o la ETL
Ejemplo :
RCLI-JOB-MEN-IAF-Proceso de Afiliación Masiva
3.5.7. Diccionario de base de datos
Herramientas para la generación automática

Página 64 de 132
VERSIÓN 4
Para cada una de las entidades que conforman la base de datos se debe documentar la identificación de los campos teniendo en cuenta :
Nombre
Descripción
Tipo
Tamaño
Si es requerido u obligatorio
Si hace parte de la llave primaria
Reglas de validación
Valor por defecto del campo, en caso de tenerlo
3.5.8. ETL’s
Con el fin de mantener un desarrollo y paso a producción unificado y estandarizado de ETL’s, se han definido los primeros estándares y una
guía de las mejores prácticas que deben ser tenidas en cuenta en su totalidad para lograr los pasos a producción de ETL’s. Las ETL’s (y DTS’s,
ya en proceso de desmonte) permiten mover datos desde múltiples fuentes, transformarlos, y cargarlos en otra base de datos, o en otro sistema
para apoyar un proceso de negocio. En el último año se ha visto un crecimiento de estos componentes que en muchos casos no han sido
visibles para Procesamiento de Datos, lo cual impacta en los tiempos de ejecución de los procesos ya programados, pero que han estado
asociados a la necesidad de mejorar tiempos de proceso de generación de información. Estos desarrollos deben estar enmarcados en nuestra
metodología de desarrollo de Software y deben cumplir con cada uno de las fases, de tal forma que se garantice un producto de calidad y
propendan la integridad, estabilidad y tiempos de respuesta de los sistemas de información.
Se define la presente política para el desarrollo y construcción de DTS, ETL´s, como parte del proceso de aseguramiento de la calidad del
software.
3.5.8.1. Políticas y mejores prácticas para la aprobación de etl’s:
La construcción de uno de estos componentes debe estar soportada en un requerimiento por parte de un usuario líder de aplicaciones (ULA) y
aprobado por el Planificador respectivo y deben responder de manera adecuada a la planificación, arquitectura, infraestructura y sistemas de
información.
El análisis del requerimiento debe ser realizado junto con el ULA para determinar el alcance real del requerimiento, contemplar si está asociado
a uno ya existente, si realmente la información no la suple el sistema de información, su criticidad, la periodicidad, los tamaños de las salidas,
la dependencia de otros procesos antes o después de su ejecución, propendiendo por tener la mínima cantidad de los mismos para cada
sistema de información.
El diseño y construcción debe seguir las fases de la metodología de construcción de Software y aplicar las mejores prácticas, que garanticen
un adecuado desempeño y uso de recursos de los servidores y redes de datos, especialmente en lo relacionada a la construcción de sentencias
SQL, donde garanticemos sentencias bien estructuradas.
Los componentes deben obedecer a las prácticas definidas y adoptadas para el manejo de la arquitectura empresarial de la organización de
acuerdo con las especificaciones particulares de cada sistema de información.
Dichos componentes deben ser administrados dentro del ciclo de vida de los sistemas de información con los responsables, el objeto, la
documentación, la identificación de la versión, modelo de datos al cual está asociado, las fuentes de datos, las cadenas de conexión y todo
aquello que se considere pertinente para garantizar la consistencia, confiabilidad, seguridad y administración de los mismos en producción.

Página 65 de 132
VERSIÓN 4
Todos los nombres usados para los componentes deben ser auto- documentados, que indiquen su relación con los sistemas de información a
que pertenecen, a que versión corresponde del sistema de información y del modelo de datos al igual que las salidas generadas.
Los componentes deben estar asociados de manera integral a repositorio de control de versiones (TFS), administración de cambios,
administración de liberaciones, catalogaciones, ítem de configuración y pasos a producción.
En el repositorio de Control de Versiones habrá una carpeta para el manejo de estos Componentes, y una única carpeta para mantener un
Inventario y la documentación correspondiente.
Cada componente evitará al máximo que se tengan más de un Base de Datos como fuente y especialmente si dichas fuentes residen en
servidores independientes que se vean afectados por condiciones de red y conectividad.
Se deben considerar todos los elementos de seguridad que permitan manejar la autenticación, el programa o usuario autorizado para su
ejecución, que su contenido en lo posible este encriptada y que no sea de fácil legibilidad para quien lo obtenga y que sea fácilmente identificable
a que aplicación pertenece por su definición de nombre.
Todo componente debe pasar por rigurosas pruebas de calidad, unitarias, funcionales, no funcionales y de desempeño que propendan la
integridad, estabilidad y tiempos de respuesta de los sistemas de información.
Los componentes en sus fases de análisis y diseño deben contemplar otros que ya existan para hacer un adecuada optimización de los mismos,
propendiendo por tener la mínima cantidad de los mismos para cada sistema de información.
El uso de dichos componentes estará limitado a consulta y extracción de información de las bases de datos para otras fuentes o procesos.
3.5.8.2. Políticas y mejores prácticas para la creación y el desarrollo de etl’s:
Inicialmente, para cada ETL se creará un directorio que contendrá el proyecto, la solución y el archivo dtsx, todos con el mismo nombre.
Crear Las ETL’s con nombres descriptivos cortos que permitan o identificar su funcionalidad o el aplicativo al que pertenece o el proceso al que
pertenece.

Página 66 de 132
VERSIÓN 4
La ETL debe tener un cuadro de diálogo donde se incluya lo siguiente:

Página 67 de 132
VERSIÓN 4
Cada vez que se realice una modificación al ETL se debe adicionar quién lo modifica, fecha de modificación y descripción de la modificación.
Debe incluirse toda la información necesaria que permita identificar la funcionalidad, a quién pertenece y cuál es el proceso usuario del ETL.
Defina en las propiedades del ETL el nivel de aislamiento a “ReadUncomitted”:
Las conexiones usadas dentro del ETL deben tener como nombre la base de datos que use o el nombre del archivo que generan:
Evitar nombres como estos:

Página 68 de 132
VERSIÓN 4
No crear varias conexiones al mismo origen o destino de datos (definir una sola):
Cada uno de los controles del ETL debe tener un nombre descriptivo así (ver el nombre de cada control):

Página 69 de 132
VERSIÓN 4
Evitar esto (ver los nombres de cada control, no es claro que operación se realiza en cada uno de ellos):

Página 70 de 132
VERSIÓN 4
Dentro de los scripts sql no ejecutar comandos de sistema como DBCC, SHRINK, BACKUP LOG, etc…
Los scripts SQL deben en su mayoría usar los campos que tengan creados índices a fin de agilizar el proceso. Si no existen índices sobre estos
campos, debe evaluarse la posibilidad de crearlos.
Los componentes no pueden ser programas o segmentos representativos de lógica de negocio, o lógica de integración, o lógica de presentación,
sino que debe obedecer a esquemas muy sencillos de extracción de datos y a lo sumo transformación para otras fuentes.
Los set de datos que se usen deben ser lo más pequeños posibles o de lo contrario manejar grupos de datos.
Eliminar cualquier conexión, control o cualquier otro objeto que no se esté usando dentro del ETL.
Cada ETL debe tener configurado un archivo txt de registro donde se guardará información de la ejecución del mismo cada vez que se invoque
(este servirá para control y seguimiento de ejecución y errores de ejecución que se presenten en el mismo, por ahora sólo se marcarán las
opciones OnError, OnInformation, OnProgress y OnTaskFailed):
En la plataforma de desarrollo deben realizarse todas las pruebas necesarias emulando al máximo la plataforma productiva en donde se
ejecutará el ETL.

Página 71 de 132
VERSIÓN 4
3.5.8.3. Políticas y mejores prácticas para el uso de tablas temporales
Cuando en el desarrollo de la ETL se requiera el uso de tablas temporales físicas, se debe tener en cuenta que ello involucra la utilización de
la base de datos compartida “TEMPDB”, y adicionalmente cuando se involucra el manejo de grandes volúmenes de datos, por lo tanto se debe
tener en cuenta:
▪ Si las tablas temporales tienen un gran tamaño (superior a 2000 registros) y sobre estas se pretende realizar lecturas y actualizaciones,
se deben definir los índices necesarios para la ejecución de estos procesos de manera óptima.
Justificación: Disminuir al máximo la necesidad de que el motor SQL se vea obligado a implementar procesos TABLE SCAN para
gestión de las estructuras temporales.
▪ Si sobre las estructuras temporales se pretende insertar un elevado volumen de datos, el flujo de proceso que se debe seguir es:
primero crear las tablas temporales, segundo insertar los datos a trabajar y finalmente crear los índices que serán requeridos para
optimizar las tareas de lectura y actualización sobre dichas tablas.
Justificación: Cuando se crean índices en tablas vacías, y posteriormente se realizan cargas masivas, el motor SQL se ve obligado a
insertar los datos en las tablas y adicionalmente en cada uno de los índices, originando un gran número de tareas de escritura en los
discos de la TEMPDB, provocando adicionalmente que estos se fragmenten, impactando tiempos de respuesta y elevando la cantidad
de recursos de procesador, disco y memoria que deben ser utilizados.
▪ Si la interacción con tablas temporales se realiza desde procedimientos almacenados, dichos procedimientos no deben incluir en su
lógica el esquema de “opciones multiples”, en donde cada opción tiene alguna funcionalidad o tipo de consulta diferente.
Justificación: La diversidad de opciones dentro de un procedimiento almacenado puede ocasionar que el plan de ejecución definido
por el motor SQL, para aplicar en una tarea, no esté correctamente optimizado para ser aplicado en tiempo de ejecución de dicha tarea.
▪ Si en el diseño de la ETL se requiere implementar el uso de hilos de procesamiento los cuales escriben en tablas temporales, se debe
asegurar que diferentes hilos no realicen tareas de escritura sobre la misma tabla, en su lugar cada hilo deberá interactuar con su
propia tabla temporal y posteriormente se debe unificar la información.
Justificación: cuando existen varios hilos escribiendo data en un mismo objeto, se pueden generar bloqueos, eventos “deadlock” y
cuellos de botella en el flujo de procesamiento de la ETL.
3.5.8.4. Políticas y mejores prácticas para el paso a producción de ETL’s:
Tener en cuenta las políticas generales del proceso de paso a producción ya definidas (los formatos y las fechas siguen igual).
El desarrollador entrega el archivo dtsx que corresponde al ETL (tal y como se ha venido realizando hasta hoy).
Las ETL’s deben estar creados en la plataforma de desarrollo correspondiente; antes de pasar a producción se ejecutarán estos ETL’s’ para
verificar lo necesario.
Dentro del campo observaciones de los formatos, deben especificarse los siguientes datos:
Versión del ETL en TFS.
Descripción de la funcionalidad.

Página 72 de 132
VERSIÓN 4
Aplicación o sistema de información al que pertenece.

Proceso y nombre de usuario final.
Base de Datos y tablas que usa (también cualquier otro objeto de bd que use).
Pre-requisitos de ejecución.
Descripción de salidas y tamaños aproximados.
Tiempo de ejecución en ambientes de desarrollo y pruebas (anexar el detalle la ventana “Execution Results” después de la ejecución del ETL
o el archivo txt de log):
Cambios a realizar en las conexiones a servidores.
Cambios a realizar en las conexiones de archivos de entrada y/o salidas.
Cambios a realizar en cualquier otro tipo de conexión usada dentro del ETL.
Cambios a realizar en cada uno de los scripts (sobre todo en los que se refiere a cambiar nombres de servidor).
Cambios a realizar en las variables locales, variables de entorno, archivos de log, o cualquier otro tipo de control.
Cambios a realizar en cualquier otro control dentro del ETL.
Hora y fecha “sugerida” para la ejecución del ETL. La ejecución del ETL se pactará con Procesamiento de Datos para definir niveles de acuerdo
de servicio.
No se realizarán cambios en ningún componente del ETL si no vienen especificados en el formato; esto a fin de garantizar la integralidad de la
funcionalidad del ETL.
Las ETL’s no serán entregados para el manejo directo de usuarios o clientes de los sistemas de información como parte de la funcionalidad
estándar, sino que será de manejo de Procesamiento de Datos.
Las ETL’s no serán programados de forma automática por tareas del motor o del sistema operativo, a no ser, que obedezca a un manejo de
automatización por herramientas de manejo de procesos que administre Procesamiento de Datos.
NOTA: Todas estas políticas aplican también al entorno de desarrollo y producción propio y aplicable de DTS’s en SQL Server 2000.
3.6. LOG DE AUDITORIA DE APLICACIONES O SERVICIOS
Para todas las aplicaciones y servicios se debe tener el log de auditoria, para logs de las aplicaciones de consorcio se implementó en el
FramewortNet2.dll una función para el registro del log de auditoria, el log es guardado en una tabla que se crea en la base de datos propia de
la aplicación.
El proceso de invocación de la librería y la creación de tablas para el registro del log se describen a continuación:
3.6.1. Creación de tabla Principal para registro del Log
Se debe crear la tabla LogAplicacion en la base de datos principal de la aplicación o servicio, esta tabla guarda el log que se registra durante
el día, el script de creación de la tabla es:
CREATE TABLE [dbo].[LogAplicacion](

Página 73 de 132
VERSIÓN 4
[ID] [bigint] IDENTITY(1,1) NOT NULL,

[IdAppRegistraEvento] [varchar](50) NULL,
[IdAplicacion] [varchar](50) NULL,
[IP] [varchar](16) NULL,
[HoraInicial] [datetime] NULL,
[HoraFinal] [datetime] NULL,
[Operacion] [varchar](50) NULL,
[Opcion] [varchar](5) NULL,
[DatosEntrada] [text] NULL,
[DatosSalida] [text] NULL,
[Usuario] [varchar](50) NULL,
[Servidor] [varchar](50) NULL,
[DatosAdicionales] [text] NULL,
CONSTRAINT [PK_LogApp] PRIMARY KEY CLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
END
GO
3.6.2. Creación de tabla de Histórico para registro del Log
La tabla que va crear en el siguiente script es utilizada para realizar el volcado de datos de la tabla LogAplicacion a la tabla de histórico. La
tabla se va a llamar LogAplicacion_Historico, el script de creación es:
CREATE TABLE [dbo].[LogAplicacion_Historico](

[ID] [bigint] NULL,
[IdAppRegistraEvento] [varchar](50) NULL,
[IdAplicacion] [varchar](50) NULL,
[IP] [varchar](16) NULL,
[HoraInicial] [datetime] NULL,
[HoraFinal] [datetime] NULL,
[Operacion] [varchar](50) NULL,
[Opcion] [varchar](5) NULL,
[DatosEntrada] [text] NULL,
[DatosSalida] [text] NULL,
[Usuario] [varchar](50) NULL,
[Servidor] [varchar](50) NULL,
[DatosAdicionales] [text] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
3.6.3. Creación Procedimiento almacenado
Para el registro del log de auditoria se utiliza el procedimiento almacenado seg_sp_LogAplicacion, este procedimiento se debe crear en la base
de datos principal de la aplicación o el servicio.

Página 74 de 132
VERSIÓN 4
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[seg_sp_LogAplicacion]') AND type in

(N'P', N'PC'))
DROP PROCEDURE [dbo].[seg_sp_LogAplicacion]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[seg_sp_LogAplicacion]') AND type in
(N'P', N'PC'))
BEGIN
EXEC dbo.sp_executesql @statement = N'CREATE PROCEDURE [dbo].[seg_sp_LogAplicacion] AS'
END
GO
ALTER PROCEDURE [dbo].[seg_sp_LogAplicacion]

@IdAppRegistraEvento VARCHAR(50) = NULL,
@IdAplicacion VARCHAR(50) = NULL,
@IP VARCHAR(16) = NULL,
@HoraInicial DATETIME = NULL,
@HoraFinal DATETIME = NULL,
@Operacion VARCHAR(50) = NULL,
@Opcion VARCHAR(5) = NULL,
@DatosEntrada TEXT = NULL,
@DatosSalida TEXT = NULL,
@Usuario VARCHAR(50) = NULL,
@Servidor VARCHAR(50) = NULL,
@DatosAdicionales TEXT = NULL,
@OpcionMetodo INT = NULL
as
if @OpcionMetodo = 1
BEGIN
INSERT INTO [dbo].[LogAplicacion]
([IdAppRegistraEvento]
,[IdAplicacion]
,[IP]
,[HoraInicial]
,[HoraFinal]
,[Operacion]
,[Opcion]
,[DatosEntrada]
,[DatosSalida]
,[Usuario]
,[Servidor]
,[DatosAdicionales])

Página 75 de 132
VERSIÓN 4
VALUES
(@IdAppRegistraEvento,
@IdAplicacion,
@IP,
@HoraInicial,
@HoraFinal,
@Operacion,
@Opcion,
@DatosEntrada,
@DatosSalida,
@Usuario,
@Servidor,
@DatosAdicionales)
END
3.6.4. Actualización FrameWrokNet2 Versión 2.0.0.113 en la Aplicación o Servicio
El primer paso a realizar, corresponde a la actualización de la versión de la dll de FrameWorkNet2:

• Remover la referencia de todos los proyectos involucrados a la librería FrameWorkNet2.dll.
• Adicionar la referencia, a la nueva librería FrameWorkNet2.dll.
• Compilar la solución y verificar que no existan errores relacionados a las funciones de la librería.
3.6.5. Implementación en la Aplicación o Servicio
Para realizar la implementación para el registro del log de auditoria en las aplicaciones o servicios se debe realizar:
3.6.5.1 Configuración Endpoint Web.Config
Para realizar la invocación desde el FrameworkNet2 debe adicionar en el Web.Config de la aplicación o del servicio las siguientes líneas:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ISEG"/>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://172.18.167.93/WSEGURIDAD/SEG/SEG.svc/Soap" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISEG" contract="WSeguridadSEG.ISEG" name="BasicHttpBinding_ISEG"/>

Página 76 de 132
VERSIÓN 4
</client>
</system.serviceModel>
De acuerdo al ambiente en el cual está la aplicación o el servicio se debe cambiar en el endpoint address la dirección IP
“172.18.167.93“.
3.6.5.2. Invocación FrameworkNet2 RegistrarLog
La función para el registro del log de auditoria se llama RegistrarLog, está definida en la librería FrameworkNet para instanciarla
se deben tener los siguientes datos:
IdAppRegistraEvento: Código de la aplicación que genera el registro o que consume el servicio.
IdAplicacion: Para servicios de integración es el código de aplicación que consume el servicio.
HoraInicial: Fecha y hora inicial de la transacción. Formato yyyy-MM-dd HH:mm:ss.fff.
HoraFinal: Fecha y hora final de la transacción. Formato yyyy-MM-dd HH:mm:ss.fff.
Operacion: Operación / Evento. Descripción del evento registrado, para servicios de integración es el nombre del método.
Para eventos de aplicación puede ser un texto definido o la funcionalidad de la pantalla o botón.
Opcion: Para servicios de integración número opción de la operación. Para eventos de aplicación no aplica.
DatosEntrada: Datos de Entrada / Estado Anterior. Para servicios de integración es la trama de entrada del servicio, para
transacciones ejecutadas por un usuario es el estado de la pantalla en formato XML.
DatosSalida: Datos de Salida / Estado nuevo / Mensaje de Error. Para servicios de integración es la trama de respuesta, Para
transacciones ejecutadas por un usuario es el estado de la pantalla en formato XML. Para excepciones es el mensaje de error
o el Stack Trace de la transacción.
Usuario: Para transacciones ejecutadas por un usuario, es el usuario que realiza la transacción, para servicios de integración
puede ser la cédula del afiliado.
DatosAdicionales: Datos adicionales para registrar en el log.
Ejemplo:
Dim objLog As clsLogRegistro = New clsLogRegistro()

Página 77 de 132
VERSIÓN 4
objLog.RegistrarLog(ConfigKey.ProjectID, ConfigKey.ProjectID, DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff"),

DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff"), "Actualización Datos", "", ex.Message, ex.StackTrace, "983562514",
ex.StackTrace)
3.6.6. Consumo WSeguridad Método RegistrarLog
Para las aplicaciones que no utilizan el FrameworkNet2 pueden utilizar el método RegistrarLog del servicio WSeguridad/SEG/SEG.svc o
WSeguridad/SEG/SEGRest.svc.
Los campos de entrada y salida se encuentran definidos en la hoja del servicio “FOR-GTI-023-HOJA_DE_VIDA_SERVICIO_WSEGURIDAD”.
4. Uso adecuado de componentes de terceros (APIs, Librerías, Nuggets, Plugins)
Un componente de software es el elemento, al interior de un sistema de software que ofrece un conjunto de servicios, o funcionalidades, a
través de interfaces definidas, y que tiene por objetivo, el desarrollo ágil de aplicaciones mediante la aportación de librerías y/o funcionalidades
ya creadas para que ser usadas directamente.
El enfoque que se debe aplicar, cuando se piensa en implementar un componente, es “en que porcentaje facilita que nuestra operación, se
centre en los verdaderos problemas de atención efectiva, de las necesidades del cliente, evitando que nos preocupemos por
implementar funcionalidades que son de uso común en muchas aplicaciones”, como podría ser el proceso de login de usuarios o
establecer la conexión con la base de datos. Por tanto, cuando usamos componentes, nuestros esfuerzos han de centrarse en el cliente,
mientras podemos delegar en dichos objetos, la gestión de los detalles “menores” ya que seguramente el componente nos dará una solución
para ellos.
Se debe realizar un proceso de análisis de implementación de componentes, muy cuidadoso, no se recomienda una adopción a la ligera, ya
que pueden incorporar diversos riesgos14, para la plataforma general de Consorcio, dicho análisis deberá incluir:
1. Verificación Operacional, analizar las interacciones de los componentes operativos, tales como las rutinas de invocación, entre componentes
internos y externos, verificación de las llamadas a rutinas entrantes y salientes.
14 https://search.proquest.com/docview/220260935/fulltext/AF0D9B922AD4437PQ/66?accountid=143348#center

Página 78 de 132
VERSIÓN 4
2. Verificación de desempeño, Análisis tanto unitario como integral, del desempeño, necesidades de información y de infraestructura para cada
ambiente, en cada una de las rutinas a consumir, incluyendo velocidad promedio, máxima velocidad y mínima velocidad.
3. Verificación de estados, Analiza los estados de objetos o data en un componente, es muy útil en escenarios de prueba de caja negra, para
establecer el comportamiento de objetos o datos públicos visibles de los componentes.
4. Verificación de registros de eventos y de las secuencias que ocurren en los componentes, lo cual provee una herramienta sistémica, muy
efectiva y útil para análisis de entornos operativos
5. Verificación de registros de error, análisis de los mecanismos para registro de mensajes de error generados por el componente, incluyendo
tanto mensajes de falla, como de procesamientos relacionados.
6. Análisis de los esquemas de licenciamiento ofrecidos, así como análisis del fabricante en sí.
7. Verificación de panorama de riesgos para la organización, en cuanto a eventos de pérdida de información, malware, o fallas del componente,
así como el análisis de cumplimiento de los lineamientos establecidos en las políticas de seguridad de Consorcio.
8. Verificación de compatibilidad con la plataforma instalada de Consorcio tanto a nivel software (sistema operativo, otros componentes) como
de hardware.
9. Análisis de los mecanismos de implementación o instalación, análisis de componentes adicionales requeridos, y su compatibilidad con la
plataforma ya instalada.
10. Análisis de los mecanismos de consumo o utilización de los componentes, navegadores compatibles requeridos.
11. Análisis de características de reusabilidad, intercambiabilidad, definición de interfaces, cohesividad.
12. Contar con la aprobación de los arquitectos de proyectos o de gestión de la demanda, y del comité de seguridad de la organización, lo
anterior no excluye que adicionalmente para las fases de implementación, se cuente con la aprobación de los arquitectos de OPSTI.
Los resultados del análisis, se deben incorporar en el documento de análisis y diseño de la aplicación, siempre de manera previa al comienzo
de las actividades de desarrollo de la funcionalidad, de manera que no podrá aprobarse al finalizar etapas de desarrollo o de pruebas, ya que

Página 79 de 132
VERSIÓN 4
de otra forma, podría ocasionar re trabajos debidos a la no aprobación de la ingeniería en desarrollo, en caso de no ser aprobado el uso del
componente.
4.1. NuGets
NuGet es un gestor de paquetes gratuito y de código abierto para la plataforma de desarrollo de Microsoft (antes conocido como NuPack),
desde su introducción en 2010, NuGet se ha convertido en un ecosistema más amplio de herramientas y servicios, se distribuye como una
extensión de Visual Studio.
A partir de la versión de Visual Studio 2012, NuGet viene preinstalado por defecto, también se integra con SharpDevelop, pudiendo ser
utilizados desde la línea de comandos y automatización mediante scripts.
Cuando se incluyan en un desarrollo de Consorcio, se deberá incluir el documento técnico de la aplicación, con la información detallada de
cada uno de los Nugets utilizados, el fabricante, versión utilizada, y esquema de licenciamiento. Únicamente se utilizarán Nugets autorizados
por Consorcio, independiente de que requieran o no licenciamiento.
4.2. API’S
El término API se refiere a una INTERFAZ DE PROGRAMACIÓN DE APLICACIONES, o en pocas palabras, una API es una “llave de acceso”,
para funciones que permiten utilizar un servicio web provisto por un tercero, dentro de una aplicación web propia, de manera segura.
En ocasiones el proceso de contratación de algunas API’s de alcance jurídico (como los bancarios) requieren de la intervención del
representante legal de CONSORCIO.
Ejemplos de API´s:
• Google Maps a través de su acceso a “API” nos permite acceder a datos e información útil sobre mapas, y permitir búsquedas o acceso
a funciones personalizadas, desde nuestra propia aplicación.
• Twitter ha autorizado el desarrollo de un elevado número de sistemas alternativos y servicios web que operan a través de su API.

Página 80 de 132
VERSIÓN 4
• Facebook Connect, “cede” a través del API ciertos datos para registrar automáticamente usuarios en otros sitios web, dándole a los
clientes la posibilidad de registrarse y loguearse, en otras aplicaciones, con sus propias cuentas de Facebook.
• Paypal con su “API” nos permite realizar operaciones de pago electrónico usando nuestro propio sistema web, sin necesidad de
acceder/operar en la web de Paypal
4.3. DLL’S 15
Una biblioteca de enlace dinámico o más comúnmente DLL (por su sigla en inglés dynamic-link library), es el término asignado a un conjunto
de archivos de código ejecutable, que se consumen bajo demanda de un programa mediante el sistema operativo.
Su alcance es exclusivo de los sistemas operativos Windows siendo ".dll" la extensión con la que se identifican estos ficheros, aunque el
concepto existe en prácticamente todos los sistemas operativos modernos.
4.4. PLUGINS16
Un complemento o plug-in es una aplicación (o programa informático) que se relaciona con otra para agregar una función nueva y generalmente
especializada. Esta aplicación adicional es ejecutada por la aplicación principal, un complemento y un plug-in se diferencian en que los plug-in
son desarrollados por empresas reconocidas en el mercado, e incluyen un certificado de seguridad, por su parte, los complementos pueden
ser desarrollados y distribuidos por cualquier desarrollador.
Algunos tipos de aplicaciones que suelen incluir complementos son:

• Navegadores: En ocasiones requiere ciertos complementos, que amplían las funciones de las páginas web para acceder a
contenidos interactivos, o multimedia.
15 https://es.wikipedia.org/wiki/Biblioteca_de_enlace_din%C3%A1mico
16 https://es.wikipedia.org/wiki/Complemento_(inform%C3%A1tica)
Página 81 de 132
VERSIÓN 4
• Reproductores de audio: Permiten instalar complementos para reproducir formatos no soportados, o gestionar efectos de sonido,
video, o animaciones.
• Sistemas de administración de contenidos: Cambios en apariencia, modificar el contenido páginas web.
4.5. Componentes permitidos en la organización:
Los componentes que actualmente están aprobados para utilización en los desarrollos de la organización son:
COMPONENTE DESCRIPCIÓN ESTADO

Es una técnica de desarrollo web para crear aplicaciones
AJAX Autorizado.
interactivas.
En proceso de desmontaje, en su
CRYSTAL REPORTS Generador de reportes y archivos pdf. reemplazo se debe utilizar la
plataforma “Reporting Services”
JAVAVM Framework, motor para aplicaciones JAVA Autorizado.
FRAMEWORK .NET Framework, motor para aplicaciones .NET Autorizado.
ADOBE ACROBAT READER Acceso a documentos PDF Autorizado.
POLTFSCONSORCIO.DLL Politica de gestión de fuentes TFS, creada en CONSORCIO Autorizado.
SKYPE Componente para gestión de comunicaciones Bajo autorización de GTI.
FRAMEWORKNET2.DLL Framework de seguridad de CONSORCIO. Autorizado.
5. Estandares de infraestructura, administración y operación de los sistemas de información
Inicialmente es importante definir que es un sistema abierto.
Según ISO un sistema abierto es “todo sistema informático capaz de interconectarse con otros de acuerdo con unas normas establecidas”.
Para X/OPEN se trata de “entornos diseñados e implantados de acuerdo con normas ampliamente divulgadas y básicamente independientes
de los fabricantes”.
Otra definición de una comisión internacional es: “Sistemas abiertos son aquellos sistemas y componentes que pueden ser especificados y
adquiridos de fuentes distintas en un mercado competitivo.

Página 82 de 132
VERSIÓN 4
Las especificaciones de los sistemas abiertos deber ser controladas por organizaciones internacionales de normalización o, al menos, por un
especificador tan independiente como sea posible en un amplio grado de aceptación en el mercado. Una especificación de sistema abierto no
debe ser propiedad de un único suministrador y debe estar disponible sin coste”.
Finalmente para el Gartner Group: “los sistemas abiertos son aquellos cuyas especificaciones están aprobadas, publicadas y respaldadas por
organismos independientes de normalización como por ejemplo ISO, POSIX, X/OPEN, etc.
Características Generales:
Todas las definiciones anteriores coinciden en que un sistema abierto debe cumplir las siguientes características de:
Interoperabilidad: Posibilidad de enlazar computadores y sistemas diferentes para trabajar conjuntamente dando la sensación de un único
sistema.
Portabilidad: Posibilidad de que una misma aplicación pueda funcionar en distintas plataformas físicas.
Crecimiento o Escalabilidad: posibilidad de aumentar la potencia de la aplicación con solo aumentar la potencia de la plataforma física en la
que se ejecuta.
Los beneficios que proporcionan los sistemas abiertos a distribuidores, desarrolladores, compradores y usuarios se centran en:
Elección de la plataforma física: Los conceptos de portabilidad y escalabilidad de los sistemas abiertos permiten la elección de diferentes
plataformas físicas en lugar de permanecer ligados a arquitecturas de un único fabricante. Esto permite personalizar las ofertas y servicios a
precios competitivos. Las plataformas de sistemas abiertos pueden incluir equipos portátiles notebooks, computadores personales de
sobremesa, estaciones de trabajo, servidores con multiproceso simétrico (SMP), computadores con proceso paralelo o tecnologías basadas en
Internet.
Elección de los equipos físicos auxiliares y periféricos Los sistemas abiertos amplían la elección del usuario tanto en los tipos de periféricos
disponibles (fax/módem, tarjetas de sonido, lectores CD-ROM, impresoras, etc.), como en el número y variedad de productos dentro de cada
categoría. Esto se debe a que la interoperabilidad y las APIs garantizan que los periféricos que soporten un sistema abierto serán compatibles
con un gran conjunto de plataformas físicas. De esta forma, los usuarios pueden reducir su riesgo e incertidumbre cuando eligen productos que
son compatibles.
Elección de equipos lógicos Un entorno que permite que las aplicaciones corran en distintas plataformas físicas proporciona las máximas
ventajas. La utilización de interfaces de usuario comunes entre plataformas permite reducir el tiempo de aprendizaje y los costos, y proporciona
una mejora de la productividad del usuario.
Elección en precio Los sistemas abiertos fomentan la competencia de precios al atraer mayor número de compradores y vendedores al mercado.
Los usuarios pueden tomar su decisión seleccionando el precio y las características que desean.
Elección de perspectivas de futuro Los sistemas abiertos proporcionan un mayor número de posibilidades de elección para el futuro.
Proporcionan un grado de flexibilidad razonable y una migración sencilla a las distintas tecnologías según se van haciendo disponibles.
5.1. Estándar en la Infraestructura de Redes
La topología de red de la solución está definida por el modelo de seguridad. En este modelo se distinguen tres niveles. La red perimetral, la
cual abarca las redes públicas. La red DMZ o zona desmilitarizada, la cual está ubicada entre el perímetro y los sistemas internos. Esta red
ofrece en general dos tipos de servicios, los servicios Web, generalmente asociados al protocolo HTTP/HTTPS y los servicios de nombres
asociados al servicio DNS. Los servicios ubicados en esta red se pueden comunicar con los sistemas internos. Por último está la red interna,

Página 83 de 132
VERSIÓN 4
en donde se encuentran los sistemas internos y las subredes de usuarios internos. En esta red se encuentra la información sensible del negocio,
las bases de datos, los sistemas Host, y otros recursos.

Página 84 de 132
VERSIÓN 4
6. Esquema de seguridad para los sistemas de información
Una gran amenaza para las organizaciones son los empleados insatisfechos, los hackers maliciosos, muchas veces las mismas empresas o
los gerentes de informática mal informados.
La falta de seguridad en el tejido mismo de las compañías es, con frecuencia una receta catastrófica. Con múltiples puntos de entrada y
consecuencias como sabotaje, robos de datos o virus, se deben aplicar medidas de seguridad en múltiples niveles y puntos, y de diferentes
maneras.
Aunque el lugar donde las comunicaciones y datos corporativos son más vulnerables es en los portátiles de empleados y los computadores de
escritorio, lo primero que se debe hacer es identificar los huecos ya que la mitad de la batalla se gana al saber en qué puntos se debe aplicar
las medidas de seguridad.
Algo de suma importancia a nivel general es que debe estar seguro que el software antivirus esté siempre actualizado con el parche mas
reciente. También se debe verificar que el sistema operativo Windows no contenga algún archivo desconocido que se pueda activar durante el
arranque del sistema.
La medida de seguridad más simple y a la vez la más olvidada para los computadores de escritorio y portátiles es la definición de contraseñas
y mas contraseñas. Existen muchos programas en el mercado con los que los hackers cuentan para cumplir con sus cometidos en materia de
descifrar contraseñas. Es por esto que además de desactivar los archivos compartidos en Microsoft NetBIOS, la mejor defensa contra el
descifrado de las contraseñas es asegurar que estas sean robustas, a partir de los siguientes lineamientos:
Deberán tener de 8 a 16 caracteres de longitud

Deberán ser una mezcla de caracteres alfabéticos y no alfabéticos
No deberán tener espacios en blanco, signos de igual o de exclamación
No deben derivarse de una sola palabra del diccionario
No se deben derivar de su nombre o de los nombres de ningún pariente o mascota
No se deben derivar de su número de teléfono, número de identificación o fecha de nacimiento
No se deben derivar del nombre de las bases de datos o de los servidores en que estas se encuentran
6.1. Seguridad estaciones y/o portátiles
Aplique medidas físicas de seguridad para prevenir robos, tales como candados con cadenas y alarmas para detección de movimientos.
Recuérdese que en caso de robo de dispositivos físicos, los archivos confidenciales se pueden penetrar con solo descifrar el código de ingreso
al sistema operativo windows. Se recomienda usar contraseñas robustas para protegerse contra ataques o accesos indebidos. Otras medidas
que se deben tener en cuenta son:
Use una contraseña de carga (bootup o BIOS)

Use NT File Systems (NTFS) para volúmenes de disco y Microsoft Encripting File Systemas para Windows 2000 y XP
Use seguridad local en Windows 2000 y XP y controle las políticas de contraseñas, así como las políticas de auditoría para el computador.
Para archivos extremadamente confidenciales, utilice software de encripción comenrcial, para codificar archivos o discos duros completos en
computadores portátiles o asistentes digitales.
Defina políticas de respaldo periódico de los datos de sus servidores, PCs de escritorio fijos y portátiles.
6.2. Seguridad en la BDs.
Definir quienes deben acceder las diferentes tablas y objetos en las BDs y con que privilegios
Definir las opciones válidas para que los usuarios se conecten a las BDs

Página 85 de 132
VERSIÓN 4
No asignar permisos de modificación, inserción, borrado y/o truncates a ningún usuario en las BDs de producción para accesos directos.
Cualquier actualización se hace a través de reportes previamente autorizados
Defina un esquema y políticas de creación y cambios dinámicos de passwords y claves de acceso a las Bds
6.3. Seguridad en el acceso a Windows
Se deben definir usuarios específicos para acceso a Windows y eliminar la utilización de usuarios genéricos para acceder en algunas estaciones
lo cual complica el buen funcionamiento de cualquier esquema de seguridad implantado.
En lo posible es necesario no hacer uso del registro del sistema para almacenar rutas o cadenas de conexión ya que esto obliga a la asignación
de privilegios administrativos a los usuarios sobre la máquina. Esto puede ser reemplazado por ejemplo por la creación de un archivo de texto
en el que se almacenen los strings encriptados.
6.4. Seguridad en el acceso a los aplicativos
Existe un componente que permite (mediante su referenciación en cada proyecto) el manejo de todo el esquema de seguridad en cuanto a
privilegios de acceso a cada uno de los aplicativos a nivel de formas y controles definiendo perfiles individuales y perfiles de grupo. Este módulo
que se debe adicionar obligatoriamente a cada proyecto se llama ServidorOLE e implica la adición a la BD del aplicativo unas tablas
correspondientes a la seguridad
Se debe optimizar el módulo de seguridad y asignar formalmente a un ingeniero para que este elabore los ajustes de mantenimiento que se
requieran con oportunidad.
6.5. Seguridad en el acceso y/o actualización de los directorios de los instaladores
Asignar privilegios de solo lectura al personal de soporte y de lectura/escritura al ingeniero encargado del aplicativo sobre los directorios en los
que reposan los instaladores.
A pesar que los archivos instaladores del aplicativo deben incluir todas las librerías, componentes y procedimientos necesarios para la
instalación completa del software, se requiere que los ingenieros de soporte tengan claridad sobre posibles utilitarios adicionales o versiones
de archivos del sistema operativo que en varios casos dan al traste con el proceso de instalación.

Página 86 de 132
VERSIÓN 4
7. Centralización de objetos de desarrollo y consolidación de bases de datos
Dentro de la realización de actividades diarias de la Gerencia de Sistemas se encuentran la generación de nuevos objetos de desarrollo y
nuevas bases de datos que permitan cumplir con los compromisos adquiridos con todas las demás áreas de la empresa en lo que a necesidades
informáticas se refiere. Dentro de este proceso y presionados por la urgencia con que estos proyectos se deben llevar a cabo, en la mayoría
de las ocasiones se opta por crear objetos de desarrollo y bases de datos (aunque en menor escala) específicos para cada nuevo Sistema de
Información, lo que al final se traduce en duplicación de esfuerzos no sólo en tiempo de programación sino de administración (ya que se crean
dos ó más veces objetos que realizan la misma funcionalidad, se crean bases de datos de tamaños comparativamente pequeños, bases de
datos que se usan para realizar procesos específicos con un periodicidad poco frecuente, se crean objetos y bases de datos cuyo uso es muy
reducido, etc.). Por todo lo anterior se hace necesario plantear una estrategia que permita además reducir el tiempo y los costos en la creación
de proyectos informáticos, basados en la centralización tanto de objetos de desarrollo como de bases de datos, pero sobre todo apuntando al
objetivo final de la centralización de la información.
7.1. Centralización de objetos de desarrollo
Dentro de este tópico se definen como objetos de desarrollo todos aquellos elementos que formen parte de un Sistema de Información y que
provean una funcionalidad definida dentro del mismo, partiendo de los fuentes, scripts e incluyendo además DLL’s, OCX’s, instaladores,
archivos de inicialización (ini), etc.
7.1.1. Objetivo
Facilitar el proceso de concepción de nuevos Sistemas de Información, basados en usar objetos de desarrollo ya creados que provean la
funcionalidad requerida y que de no existir se les adicione nueva ó más funcionalidad evitando completamente eliminar la funcionalidad ya
definida, incluyendo además los objetos de base de datos en una base de datos ya creada que permita maximizar el uso de la plataforma de
hardware actual.
7.1.2. Consideraciones
Para la centralización de los objetos de desarrollo (fuentes, scripts, DLL’s, OCX’s, todo tipo de documentación, instaladores, etc.) se usará el
aplicativo “TFS”
Todos los objetos de desarrollo que se definan, deben contar como mínimo con una descripción detallada de su funcionalidad, forma de trabajo,
uso, ubicación y todos los demás detalles que el ingeniero de desarrollo considere importantes dar a conocer. Deben además, documentarse
siempre todos los cambios que sobre un componente de desarrollo específico se realice sin importar el impacto que sobre su funcionalidad se
produzca.
La documentación de un objeto nuevo debe incluir la forma en que debe matricularse ya sea en el cliente o en el servidor (en el caso de un
DLL un OCX o un componente).
La documentación debe incluir una descripción general de su funcionamiento, es decir, forma de invocarlo, parámetros de entrada, descripción
general del proceso interno que realiza, salidas producidas, etc.
Manejo de Versiones. (versión o release). Debe definirse que tipo de modificaciones se consideran como cambio de versión y cuáles otros
como cambios de release, teniendo en cuenta la complejidad de las modificaciones y la funcionalidad que se ve afectada o la funcionalidad
adicional que se alcanza.
Se deben definir la forma y los subprocesos que se deben llevar a cabo para actividades tales como reglas o normas a tener en cuenta en la
creación de un objeto de desarrollo, proceso para la lectura de una tabla en una base de datos, proceso para llevara a cabo una actualización
de una base de datos, etc.
Definir la arquitectura de las aplicaciones que se construirán en la empresa (expresada en niveles). Actualmente la arquitectura de las
aplicaciones la define el ingeniero de desarrollo encargado del proyecto y esta decisión no está basada en una política de la Gerencia. Como
es imposible enmarcar todos los proyectos dentro de una sola arquitectura, como mínimo deben existir unos parámetros basados en las

Página 87 de 132
VERSIÓN 4
necesidades a satisfacer y en la plataforma tecnológica actual, que permitan definir sobre que arquitectura debe desarrollarse la nueva
aplicación.
Definir las herramientas de desarrollo que se usarán para desarrollar y concebir nuevos sistemas de información. En el caso de lenguajes
informáticos nuevos debe considerarse la necesidad o no de una capacitación previa para disminuir al máximo o eliminar los retrasos en las
fechas pactadas.
En cuanto a las pruebas, todo cambio de un objeto de producción o la inclusión de uno nuevo, debe haber pasado por un proceso de pruebas
definido con anterioridad donde se defina explícitamente el objetivo que se busca.
Centralizar la administración tanto en desarrollo como en producción. Se establece que todos los cambios que se deban realizar sobre la
plataforma de desarrollo, deben ir soportados por la documentación de las pruebas realizadas sobre la plataforma de prueba así mismo se
establece que toda modificación o cambio sobre la plataforma de producción debe ser realizada únicamente por el proceso de Mantener y
Operar Tecnología de Información, previa solicitud hecha por el ingeniero de desarrollo utilizando los formatos establecidos
Dentro de la centralización de los objetos de desarrollo, en lo referente a interfaz de usuario, todas deben cumplir con el estándar de diseño
definido (tipos de ventanas, fondos, colores, botones, etc.)
7.1.3. Manejo de Versiones
7.1.3.1. Aplicaciones Windows
En la herramienta de desarrollo Visual Basic puede tener un manejo automático de número de la versión mediante la opción del menú
PROJECT- PROJECT PROPERTIES- en la que se despliega una ventana con múltiples opciones entre las cuales seleccionamos la carpeta
MAKE, como observamos en el siguiente gráfico:
Debemos seleccionar siempre la opción AutoIncrement, con la cual, cada vez que se compile y genere un ejecutable, Visual Basic
automáticamente aumentará en 1 el número de REVISION.
Debido al volumen y forma de trabajo de nuestras aplicaciones, no manejaremos la casilla MINOR, y únicamente cuando los cambios sean
sustanciales, se cambiará (manualmente) la casilla MAJOR, reiniciando en 0 la casilla de REVISION.
Este número de versión debe ser consistente con una acción de CHECK IN (PROTEGER) en TFS, etiquetado con el número de versión
generado por Visual Basic, como se observa en la siguiente gráfica:

Página 88 de 132
VERSIÓN 4
Adicionalmente, este número de versión debe estar indicado en los documentos de control de cambio de aplicaciones, con el fin de tener el
registro de esta versión en los formatos de actualización y salida a producción.
Para observar la versión de un ejecutable, simplemente con la opción propiedades (menu contextual con click derecho) del archivo ejecutable
se puede observar la siguiente información:

Página 89 de 132
VERSIÓN 4
7.1.3.2. Aplicaciones WEB/INTRANET/INTERNET
Inicialmente el manejo de estas aplicaciones se realizará por medio del explorer de TFS, mediante el cual se etiquetará con el número de
versión la acción de CHECK IN efectuada sobre un grupo de archivos que en conjunto forman un sitio web.

Página 90 de 132
VERSIÓN 4
7.2. Definiciones de Uso de TFS
7.2.1. Objetivo
Estructurar un esquema documental para el respaldo de la información y soporte metodológico de la gestión de Construcción de Software en
el ciclo de vida de los sistemas de información.
Las presentes políticas establecen los lineamientos generales a seguir para acceso y uso de TFS. Todos los usuarios del TFS deben acoger y
aceptar las presentes condiciones y políticas de uso.
7.2.2. Acerca de TFS

Página 91 de 132
VERSIÓN 4
TFS es un sistema de control de versiones para proyectos de equipo y proyectos individuales.

Se puede integrar TFS al entorno de desarrollo integrado (IDE) de Visual Studio .NET como proveedor de control de código fuente. Si bien se
han solucionado algunos errores, esta versión difiere poco de la versión original de TFS. Para obtener más información sobre esta versión, vea
el archivo Léame de TFS.
7.2.3. Estructura y contenido
La información contenida en la base de datos de TFS ha sido estructura de la siguiente forma
Proyectos y Carpetas de Trabajo
A nivel de raíz encontramos los principales temas sobre los cuales se ha definido se requiere control de versiones, tales como
Calidad
Productos
Proyectos
Para cada uno de los temas de la raíz se han establecido las carpetas de trabajo según su naturaleza. En el caso de Productos y Proyectos se
tiene una subcarpeta por cada código de producto o aplicación de acuerdo con el Portafolio de Aplicaciones de Negocio.
Dentro de las carpetas de trabajo se recomienda en lo posible mantener la siguiente estructura:

Página 92 de 132
VERSIÓN 4

Página 93 de 132
VERSIÓN 4
Las subcarpetas para manejar las solicitudes de paso a producción (-Control de Cambios y – Paso a Producción) se deben mantener dentro
de la carpeta principal del proyecto.
7.2.4. Asignación de la cuenta y permisos de la cuenta.
Se hará por solicitud del Planificador de gestión de la demanda, vía correo en el cual se deben relacionar los datos básicos del ingeniero y el
código del proyecto que va a trabajar.
Las asignación de permisos a proyectos delegados por otro ingeniero solo se pueden hacer hasta que los fuentes hayan sido liberados (check
in).
Características de la cuenta
El administrador de TFS será el encargado de proporcionar las cuentas de acuerdo a los requerimientos estipulados en la Asignación de la
cuenta.
Nombre la cuenta ó UserName

Previo a la creación de la cuenta en TFS, deberá existir la cuenta como usuario de Windows. La cuenta en TFS llevara en mismo UserName,
con el fin de sincronizarse a su ingreso en la aplicación.
Clave personal de entrada o Password
Se establecerá inicialmente el mismo UserName, pudiendo el usuario cambiarla desde el menú Tools/Change Password en el Aplicativo TFS.
Suspensión de la cuenta
Suspensión temporal de la cuenta:
Cuando el ingeniero encargado delega el proyecto a otro ingeniero, se suspenderán los permisos, esto se realizara a petición del coordinador
de proyectos.
Suspensión definitiva de la cuenta:
Finalización de contrato de trabajo. Para la seguridad de la información se quitaran todos los permisos en la base de datos TFS.
Configuración
Los usuarios del TFS son responsables de instruirse y configurar sus proyectos con los procedimientos básicos para su funcionamiento y para
contar con la seguridad mínima que brinde protección a sus dispositivos.
7.2.5. Recomendaciones de Uso
Se recomienda especial cuidado en no alterar el árbol principal de la estructura de archivos. Dentro de cada proyecto principal existirán dos
subcarpetas llamadas:
– Paso a Producción (Carpeta destinada para depositar los correspondientes archivos para los pasos a producción.)
- Control de Cambios (Esta subcarpeta debe contener los documentos soporte con los cuales se hizo el paso a producción en cada fecha,
ejemplo: FOR-GTI-001-20060615.doc)

Página 94 de 132
VERSIÓN 4
Al finalizar el paso a producción, cada ingeniero deberá subir al TFS los correspondientes cambios de su proyecto, con el fin de realizar un
corte de desarrollo y mantener el histórico de versiones, para que al finalizar la semana, éste proyecto quede en el backup.
Cuando el funcionario sale a vacaciones, es indispensable haber dejado desbloqueado sus correspondientes proyectos en el TFS (check in).
NO se deben realizar copias a proyectos que ya están siendo respaldados en el TFS ya que si se requiere recuperar una versión se hace a
través del histórico de versiones.
Es importante que cuando se cambie un proyecto de responsable, el funcionario que entrega libere todo las fuentes antes de asignar los
permisos al nuevo funcionario con el fin de eliminar los permisos anteriores.
Al realizar el check out y Check in del proyecto es recomendable añadir los correspondientes comentarios, ayuda en algún momento cuando
se trata de recuperar versiones.
7.2.6. Malas Prácticas
Almacenamiento de información que no hace parte de algún proyecto de Software, entiéndase documentación personal.
Realizar copias totales a proyectos que ya existen en el árbol de TFS. Para esto TFS maneja los históricos de versiones.
Crear subcarpetas con copias de versiones anteriores, para el TFS maneja histórico.
7.2.7. Vínculos de TFS con otros Software
Los proyectos en TFS están directamente relacionados con las herramientas de desarrollo (Microsoft VisualStudio).
Derecho de propiedad
El usuario reconoce que el contenido (incluidos entre otros: texto, software, sonido, fotografías, vídeo, gráficos u otro material) ubicado dentro
de la base de datos TFS, está protegido por derechos de autor, marcas, patentes u otros bienes mercantiles o formas diferentes del derecho
de propiedad.
El usuario podrá hacer copia de este contenido exclusivamente para su uso laboral, no comercial, siempre y cuando se mantengan presentes
todos los derechos de autor.
El usuario no podrá modificar, copiar, reproducir, volver a publicar, cargar, exponer, transmitir o distribuir de cualquier forma el contenido
disponible en la base de datos TFS y los sitios vinculados, incluidos el código fuente y el software fuera de Consorcio, so pena de incurrir en
responsabilidad civil y responsabilidad penal, según las normas vigentes.
Copias de Seguridad y Protección de la información:
Procesamientos de datos realizara backup histórico cada semana a la base de datos del TFS.
7.3. Consolidación de bases de datos
La Centralización de Bases de Datos de forma inicial y general busca eliminar el crecimiento (proliferación) del número de bases de datos en
producción que va en aumento mensualmente, generando una gran labor administrativa tanto a nivel de personal dedicado a realizar estas
labores, como en costos tanto en tiempo como en recursos físicos (servidores, incremento en tráfico sobre las red de comunicación, tapes para
respaldos, etc.) Adicionalmente busca ir de la mano con la consolidación de servidores empresariales. El objetivo final de este proyecto es
contar con 5 grandes bases de datos: Administrativa, EPS, Caja, IPS, AF
Dentro del las normas generales se encuentran las siguientes:
Cuando se genere una solicitud de creación de un nuevo SI, dentro de la etapa de análisis se debe estudiar y determinar la base de datos
actual dentro de la cual se crearán los nuevos objetos para satisfacer esta nueva necesidad de usuario.

Página 95 de 132
VERSIÓN 4
Dentro de la definición de la base de datos, debe contarse con el concepto del proceso Mantener y Operar Tecnología de Información a fin de
conocer las necesidades de ampliación de hardware a que haya lugar (si las hay).
Las bases de datos actuales estarán sujetas a seguimientos semanales para verificar el porcentaje de su uso y número de conexiones a fin de
establecer si sus objetos pueden situarse dentro de otra base de datos a fin de eliminar la actual.
Si se ve la viabilidad de mover objetos de una base de datos a otra, se debe evaluar con el ingeniero de desarrollo las posibles modificaciones
que deban realizarse al código de la aplicación que accesa la base de datos a eliminar y su impacto organizacional.
Se deben evaluar las bases de datos que solamente se usan para procesos puntuales con una periodicidad baja (mensual, semestral anual,
etc.) a fin de buscar su inclusión dentro de otra base de datos en producción).
En el estudio de consolidación de bases de datos debe tenerse muy en cuenta que tan viable puede ser la coexistencia de usuarios de diferentes
aplicativos dentro de una sola base de datos, tanto a nivel de seguridad como de concurrencia a los objetos de la base de datos.
A medida que se vayan consolidando bases de datos se debe evaluar de forma paralela la arquitectura de los servidores sobre los cuales se
está llevando a cabo dicha consolidación a fin de evitar cuellos de botellas en este nivel.
Aunque no es totalmente referente a la centralización de bases de datos, es necesario comenzar a definir el proceso (incluido scripts) de
depuración para cada una de las bases de datos, con lo que se busca reducir el tamaño en los archivos de datos y facilitar en alguna medida
la consolidación de las bases de datos.

Página 96 de 132
VERSIÓN 4
8. Estructuración ambiente de desarrollo, pruebas y producción
8.1. Plataforma Cliente/Servidor e Intranet
Se debe llegar a un estado en el que se tengan dos ambientes diferentes al de PRODUCCIÓN, uno de DESARROLLO con total libertad para
los ingenieros en cuanto a lógica de negocio, bases de datos, e interfaces gráficas, y uno de PRUEBAS, en el que los ingenieros puedan tener
replicados periódicamente los datos reales de producción, y en el cual se instalen los nuevos desarrollos antes de ser puestos en producción.
Es favorable para determinar la estabilidad de los desarrollos realizados, tener el ambiente de PRUEBAS lo más cercano técnicamente posible
al ambiente de producción para conocer datos confiables en cuanto a desempeño y funcionalidad.
8.1.1. Ambiente de desarrollo
8.1.1.1. Servidor de bases de datos:
Actualmente contamos con el servidor de bases de datos de DESARROLLO, el cual tiene la capacidad de los discos duros utilizada casi en su
totalidad. Adicionalmente algunos ingenieros de desarrollo tienen SQL Server instalado en sus propias máquinas para desarrollar sus
aplicaciones, lo que implica una administración no centralizada, mayores costos en licenciamiento del motor de base de datos, y poca o nula
capacidad de hacer copias de respaldo de las bases de datos que no se encuentran en producción.
El ambiente ideal en cuanto a servidor de bases de datos para DESARROLLO es, sin conocer detalladamente las especificaciones técnicas
del Aquanta, por lo menos 1GB en RAM, y una capacidad de disco duro adecuada para tener por cada base de datos en producción una copia
operativa en ambiente de desarrollo. En cuanto al desempeño de los procesadores de esta máquina, creo no han presentado inconveniente.
8.1.1.2. Servidor de componentes:

Las aplicaciones Cliente/Servidor desarrolladas hasta hace poco tiempo, son de 2 niveles, por lo que nunca se vio la necesidad de pensar en
un servidor de componentes, pues las aplicaciones constaban en algunos casos de un archivo ejecutable únicamente, y en otros casos de un
archivo ejecutable y varios componentes instalados en la misma máquina del cliente. Con el surgimiento de las nuevas aplicaciones Intranet, y
la tendencia a desarrollar todas las nuevas aplicaciones en este ambiente, se presenta la necesidad de un servidor COM+ de DESARROLLO,
preferiblemente dedicado, sin muchos requerimientos de máquina, el cual debería tener la capacidad mínima necesaria especialmente en
memoria RAM y velocidad del (de los) procesador(es).
8.1.1.3. Servidor web:
En cuanto a servidores WEB, y debido a que el IIS es algo con lo que se cuenta en todas las máquinas con W2K (Professional o Server) sin
costo de licenciamiento adicional, para DESARROLLO se deben manejar los sitios web en las máquinas de los ingenieros de desarrollo, con
lo cual se tiene control sobre este aspecto.
8.1.2. Ambiente de pruebas

Se debe tener un servidor de PRUEBAS con restricciones para los ingenieros de desarrollo, en el que los datos se replicarían periódicamente
desde el ambiente de producción. Los cambios a los objetos de bases de datos en este servidor deben ser acordados entre el ingeniero de
desarrollo y operaciones de TI, y a su vez, operaciones se encargaría de la sincronización periódica de los datos de este servidor con el
ambiente de producción. En cuanto a especificaciones técnicas, este servidor debería tener una configuración lo más cercana posible al servidor
de PRODUCCIÓN.

Página 97 de 132
VERSIÓN 4

Debe existir un servidor COM+ de PRUEBAS dedicado, el cual debe tener la capacidad en memoria RAM y velocidad del (de los) procesador(es)
tan cercana a la del servidor COM+ de PRODUCCIÓN como sea posible. La actualización de los componentes en este ambiente debe ser
acordada entre los ingenieros de desarrollo y operaciones de TI.

Debe existir un servidor IIS de PRUEBAS dedicado, el cual debe tener la capacidad en memoria RAM y velocidad del (de los) procesador(es)
tan cercana a la del servidor IIS de producción como sea posible. La actualización de los objetos WEB en este ambiente debe ser acordada
entre los ingenieros de desarrollo y operaciones de TI.
8.1.3. Ambiente de producción
Totalmente restringido en cuanto a claves, acceso y permisos para los ingenieros de desarrollo. Para actualizar objetos de bases de datos en
producción, Operaciones de TI transfiere los cambios instalados en el servidor de PRUEBAS. Sea o no un servidor centralizado, debe tener
todas las características de redundancia de procesadores, fuentes de poder, ventiladores y unidades de cinta o almacenamiento de respaldo,
y que permita efectuar cambios a estos componentes en caliente. En cuanto a almacenamiento primario, la recomendación de los fabricantes
de bases de datos es tener tres arreglos de discos con fault tolerance por hardware, independientes física y lógicamente, uno para el sistema
operativo, uno para las bases de datos y otro para los logs de transacciones.

Debe existir un servidor COM+ de PRODUCCIÓN dedicado, el cual debe tener la capacidad en memoria RAM y velocidad del (de los)
procesador(es) determinada por el número de usuarios concurrentes, tamaño de los componentes y carga de los mismos. Totalmente
restringido para los ingenieros de desarrollo. La actualización de los componentes se efectúa por parte de Operación de TI a partir de lo instalado
en el servidor de PRUEBAS.

Debe tenerse un servidor IIS de PRODUCCIÓN dedicado, el cual debe tener la capacidad en memoria RAM y velocidad del (de los)
procesador(es) necesaria dada por los indicadores de carga de las aplicaciones existentes, proyectándolos a las aplicaciones próximas a salir
en producción. Este ambiente debe ser totalmente restringido para los ingenieros de desarrollo, y la actualización de los objetos WEB en este
ambiente debería ser efectuada por Operación de TI con base en los objetos instalados en el servidor WEB de PRUEBAS.
Otras consideraciones:
• · Dependiendo del avance del desarrollo, las pruebas de usuarios se deben hacer sobre los servidores de DESARROLLO en
las etapas tempranas, pues son ambientes sin ser estabilizados todavía, o sobre los servidores de PRUEBAS para estados que
indiquen que los desarrollos están cerca de ser puestos en producción.
• · El canal de comunicaciones entre los servidores debe ser el mayor disponible en cuanto a tarjetas de red, cableado y equipos
de comunicaciones.
8.2. Plataforma De Desarrollo ABS ( Enterprise Application Environment)
8.2.1. Ambiente De Desarrollo:

Página 98 de 132
VERSIÓN 4
Actualmente contamos con el servidor de DESARROLLO el cual trabaja con sistema operativo Windows Server 2003 R2, SQL Server 2005 y
ABS como herramienta de desarrollo.
Se definieron dos repositorios centrales de especificaciones ABS en los cuales se encuentran las lógicas del negocio para Afiliados y Almacén
y Desarrollo Humano denominadas respectivamente AFILDB y ALDHDB. El primero permite el ingreso multiusuario de todos los ingenieros de
desarrollo desde sus respectivos puestos de trabajo con el fin de ejecutar sus labores diarias de desarrollo y mantenimiento de aplicativos
nuevos o ya existentes. El segundo solo permite el ingreso monousuario del administrador de las especificaciones en donde diariamente a
través del proceso de cargue de mdl ( ) se actualizan las lógicas o estructuras para su paso a producción.
La base de datos SQL adyacente al repositorio multiusuario contiene los datos de la BD de producción de la semana inmediatamente anterior,
sobre la cual, los ingenieros de desarrollo realizan sus respectivas pruebas en línea o batch. Igualmente desde cada estación se tiene el
acceso a las estructuras por SQL. Por el contrario, la base de datos SQL del repositorio monousuario es vacía ya que la finalidad de este es
sólo para paso a producción de las especificaciones nuevas o modificadas.
Ambiente de Desarrollo EAE

en ES7000DESA
Repositorio Ambiente
Multiusuario
•B.D. SQL: DH ES7000SERVER
•SISTEMA: ALDHSYS
ALDHDB
•B.D. SQL: AF
•SISTEMA: AFILDBSYS
AFILDB ALDHSYS
B.D. SQL DH
•Restaure de Datos de SQL Semanal
Extract
MDL
Controlado
AFILDBSYS
B.D. SQL AF
ALDHDB
AFILDB
•Generación Semanal
Repositorio
Monousuario

Página 99 de 132
VERSIÓN 4
8.2.2. Ambiente De Pruebas:
Inicialmente los ingenieros realizan sus pruebas sobre las Bases de datos SQL AF y DH, ubicadas en el servidor
SERVIDOR_ABS_DESARROLLO, las cuales cuentan con los datos replicados semanalmente desde el ambiente de producción. Para la
depuración del código es utilizada la herramienta de debugger Developer Test, fundamental para el seguimiento de las lógicas y los Reportes.
Para la respectiva prueba de reportes estos deben ser generados desde el Developer Multiusuario, ingresando al equipo
SERVIDOR_ABS_DESARROLLO por Terminal Service. Una vez terminada exitosamente la generación se realizan las pruebas a través del
sistema (\\SERVIDOR_ABS_DESARROLLO\Afiliados). Para este ambiente se crearon los mismos directorios que en producción, en donde
reposan los datos de entrada y salida (\\SERVIDOR_ABS_DESARROLLO\datos) y las impresiones (\\SERVIDOR_ABS_DESARROLLO\BD).
AMBIENTE DE PRUEBAS
Repositorio DEVELOPER
Multiusuario TEST
ALDHDB Repository
Utility
AFILDB •DEVELOPER TEST
SQ
L
AF ALDHDB
AFILDB
F:\DEV_TEST
Developer Test:
Herramienta que permite realizar seguimiento en línea a las lógicas (Ispec, reportes, lógicas globales) como apoyo a las pruebas en el ambiente
de desarrollo, a través de bases de datos de tablas indexadas que se encuentran ubicadas en los directorios :

Página 100 de 132
VERSIÓN 4
F:\DEV_TEST\AFILDB\
F:\DEV_TEST\ALDHDB\
Los datos son tomados de la base de datos AFILDB / ALDHDB del SERVIDOR_ABS_DESARROLLO y bajados a planos mediante reportes
DXU<nombre estructura> para posteriormente ser cargados a la base de datos de tablas indexadas mediante reportes DXL<nombre estructura>
que son ejecutados de 20 en 20 por las transacciones:
En AFILDB: EGA80 a EGA89

En ALDHDB: EGA80 a EGA85
Los reportes DXU<nom.Ispec> deben ser actualizados en su código interno, por el ingeniero responsable en la medida que la estructura de
datos correspondiente se haya modificado. En el evento de la creación de una nueva estructura para su cargue en Dev-Test debe ser creado
el reporte DXU.
8.2.3. Paso A Producción:
Diariamente teniendo en cuenta las solicitudes realizadas por los ingenieros de desarrollo mediante el cargue de mdl se establece una orden
de generación a producción de los reportes modificados en el día y de especificaciones en línea los fines de semana. Estos mdl son generados
por cada ingeniero y colocados en la carpeta \\172.22.145.20\Extracts\Afildbsys para Afiliados.
Para el paso a producción de las especificaciones en línea trasladadas al repositorio monousuario, igualmente los ingenieros de desarrollo ABS
realizan sus correspondientes mdl que son copiados a este y validados por el responsable del mantenimiento de especificaciones de turno. Al
área de procesamiento se entrega todos los viernes una orden de generación que índica si hay cambios en estructura o no para el
correspondiente aviso al área de Soporte quien se encarga de la replicación de la base de datos sql CS. Una vez generado el repositorio
monousuario hacía producción, se realiza el restaure de datos en la base de AFILDB y ALDHDB en el SERVIDOR_ABS_DESARROLLO.

Página 101 de 132
VERSIÓN 4
9. Protocolo de traslado a producción de sistemas de información y actualizaciones
Este capítulo expone los principales criterios que se deben tener en cuenta al momento de poner en producción una aplicación Cliente Servidor
y además fija los procedimientos necesarios para llevar a cabo la instalación.
9.1. Protocolo Preliminar
Previo a toda actividad de solicitudes de traslado a producción se deben realizar las siguientes actividades para asegurar una salida a
producción con ceros errores.
9.1.1. Protocolo Preliminar pruebas
9.2. Solicitud Salida Producción Nuevo Aplicativo
El procedimiento de instalación de un aplicativo en producción es el siguiente:
El subproceso de Construcción de Software solicita a Operaciones de TI la instalación de acuerdo con el formato Solicitud Instalación y
Actualización Aplicaciones (FOR-GTI-001). Previo a esto se debe haber entregado el Manual Técnico correspondiente.
La solicitud es evaluada por Operaciones de TI verificando se cumplan los requerimientos mínimos de instalación consignados en el manual,
la disponibilidad de licencias, si es el caso, y definirá el plan de trabajo de acuerdo con la disponibilidad de servidores.
El ingeniero de soporte procede a instalar la aplicación en los equipos correspondientes realizando las siguientes tareas:
Leer y entender el muy bien el manual de instalación
a. Verificar que se cumplan los requisitos de hardware y software especificados en el manual de instalación
Seguir en secuencia los pasos de instalación especificados en el manual
Realizar el correspondiente test de la aplicación
Verificado que la instalación quedó correctamente, el ingeniero de soporte reporta al solicitante el resultado de la gestión
9.3. Solicitud Modificación Versión Aplicativo en Producción
El procedimiento de actualización de aplicativos que ya se encuentran en producción es el siguiente:
En lo relacionado con Mantenimiento y Soporte de Aplicaciones se debe planear una actualización mensual que puede incluir uno o varios de
los puntos concluidos dentro del plan de trabajo. Sólo en casos excepcionales y de urgencia se podrá hacer más de una actualización mensual
para el mismo aplicativo.
El ingeniero responsable de la aplicación solicita al responsable del repositorio único de instaladores la actualización mediante los formatos de
control de cambio de aplicaciones.
Los formatos son recibidos por el ingeniero responsable de administración de cambios a más tardar el día miércoles de cada semana para
entrar en producción a más tardar el lunes de la siguiente semana. Estos documentos son entregados a la persona contacto de Operaciones
de TI responsable de enrutar las solicitudes a quien corresponda.
El ingeniero de soporte debe proceder a actualizar/instalar y verificar que la instalación quedó correctamente, reporta al área solicitante y al
ingeniero responsable el resultado de la gestión.
Algunas actualizaciones no requieren el uso de un instalador, basta con la copia de archivos a una ubicación especificada. Este es el caso de
actualización de plantillas de reportes o cambios en la misma aplicación que no requieren reinstalación
9.4. Solicitud Instalación Aplicativos
El procedimiento de instalación que deben seguir los interesados en utilizar un aplicativo ya existente es el siguiente:

Página 102 de 132
VERSIÓN 4
El área interesada debe reportar a Operación de TI la solicitud de instalación en el formato Solicitud Autorización Instalación Aplicativos. En
este se debe identificar el usuario y el equipo y justificar la necesidad de uso del aplicativo.
La solicitud es estudiada por Operación de TI evaluando que se cumplan los requerimientos mínimos de instalación consignados en el Manual
o Fecha Técnica del Sistema, la disponibilidad de licencias, si es el caso, la pertinencia de uso del aplicativo, etc. La solicitud puede ser
aprobada, rechazada o escalada.
En caso de ser aprobada la solicitud, el ingeniero de soporte procede a instalar la aplicación en el(los) equipo(s) correspondiente(s)
Verificado que la instalación quedó correctamente, el ingeniero de soporte reporta al área solicitante.
9.5. Repositorio Único de Instaladores
El repositorio único de instaladores es la carpeta compartida definida por Mantener y Operar Tecnología y se tiene solo un responsable del
mantenimiento y control de esta carpeta.
9.5.1. Características
El ingeniero encargado crea una única carpeta con el nombre de la aplicación y esta carpeta debe contener:
Manual o Ficha Técnica: debe ser único y permanecer actualizado

Carpeta Instalador: puede ser una o varias (por ejemplo, instalación en el cliente, instalación en el servidor) según lo requiera el aplicativo y
estar debidamente relacionadas en el manual correspondiente.
Carpeta Reportes: debe contener los archivos actualizados de los reportes. Sólo para el caso en que la actualización de reportes sea realizada
simplemente reemplazando una plantilla ya existente
Carpeta Ultimo Ejecutable: contine un único archivo con la última versión del ejecutable de la aplicación. Esto para el caso que la actualización
se reduzca al reemplazo de este archivo.
Ejemplo: La estructura de archivos y directorios para el programa Vivienda quedaría así:

Página 103 de 132
VERSIÓN 4
Ruta oficial \\Ingenieria\soporte$\SUF\desaprod
Los instaladores de programas, controles, ayudas, componentes o librerías adicionales que sean usados en el momento de la instalación de
las aplicaciones se almacenarán en la carpeta \\Ingenieria\soporte$\SUF\desaprod\Instaladores de uso general
Los componentes creados por los ingenieros de desarrollo deben seguir el mismo esquema de almacenamiento de los proyectos. Los
programas no desarrollados por ingenieros (Ejemplo: Ajax, Crystal Reports 4.2, FrameWork 3.0, etc.), por su carácter, no tendrán manual de
instalación pero deberán tener un archivo Leame.txt con una descripción general del programa y sus usos.
9.5.2. Control de Acceso
Al repositorio único de instaladores tienen acceso los ingenieros de Soporte con permisos de Solo Lectura y el ingeniero encargado del
mantenimiento y control con permiso de Lectura / Escritura
Los ingenieros de desarrollo que deseen realizar actualizaciones a los archivos de este repositorio deben diligenciar el formato “Autorización
de Traslado a Producción en Ambiente Cliente Servidor” y enviarlo al ingeniero responsable

Página 104 de 132
VERSIÓN 4
9.5.3. Manejo de Históricos
El repositorio único de instaladores NO es una carpeta para guardar históricos de estos archivos. Para esto se tiene la carpeta compartida
\\OFISERVEREPS\DESARROLLO_HISTORICOS$ donde el ingeniero debe ubicar los instaladores anteriores. En esta carpeta se tendrán las
últimas 3 versiones de los instaladores generados y Operaciones de TI se encargará de realizar respaldos semanales a este repositorio.
9.6. Manual Técnico – Capítulo Proceso Instalación
Debe tener como mínimo la siguiente información
Advertencia de leer el manual: Mensaje que comprometa al ingeniero de soporte a leer el manual antes de proceder con la instalación, Ejemplo:
Antes de realizar cualquier intento de instalación, asegúrese de leer y entender claramente los pasos explicados en este manual.
Indice
Información Básica de la aplicación
Nombre de la Aplicación
Nombre de la(s) Base(s) de Datos donde accede
Servidor(es) de Base(s) de Datos
Breve descripción de la aplicación
Persona Responsable y extensión
Persona Delegada y extensión
Lenguaje de Programación
Herramientas de Reportes utilizadas por el aplicativo y versiones
Ruta de ubicación de reportes
Métodos de conexión a la base de datos
Requerimientos mínimos de Instalación
Hardware
Disco duro
Memoria
Velocidad del Procesador
Otros
Software
Sistema Operativo
Office versión X
Mdac versión X
Proveedores de ODBC
Service Pack
Otros
Relación de ubicación de los instaladores y su propósito
Procedimiento de Instalación para cada instalador

Página 105 de 132
VERSIÓN 4
Procedimiento (Secuencia de instalación con Pantallazos documentados)

Parámetros para la configuración de ODBC (Si es el caso)
Registro de Librerías Manuales (Si es el caso)
Configuración regional del equipo (Si es el caso)
Registros de componentes o escrituras adicionales en el registro
Otros procedimientos adicionales que sea necesario realizar
Procedimientos especiales de acuerdo a la máquina
Procedimiento de Test
Errores conocidos de instalación (Pantallazos con comentarios)
Estos serán reportados por los ingenieros de soporte vía mail en el proceso de pruebas o en los momentos de instalación incluyendo la
información de la máquina en la cual se está instalando (Sistema Operativo, Versión de Office, Service Pack, Disco Duro disponible, Memoria,
etc.). En conjunto el ingeniero y el ingeniero de soporte deberán estudiar el caso y documentar la solución para cada error.
9.7. Programa Instalación
Para poner en funcionamiento un aplicativo se puede requerir de uno o más instaladores, cada uno de los cuales debe cumplir lo especificado
en este punto.
9.7.1. Características
Ubicado en el repositorio único de instaladores y relacionado en el manual de instalación

Contiene un archivo ejecutable para correr el programa de instalación. Ejemplo : Instalador.msi o Setup.exe
Tener todos los archivos y procedimientos necesarios para que el ingeniero de soporte no tenga que realizar copiados adicionales de archivos
Debe crear las respectivas escrituras sobre el registro de componentes y librerías, seimpre que sea posible. En el manual de instalación
deberán relacionarse aquellos casos en los cuales el registro deba hacerse manualmente.
Debe crear las conexiones ADO u ODBC necesarias para el funcionamiento de la aplicación o utilizar un método de conexión que no utilice
estas formas de conexión
9.7.2. Herramientas Generación Instaladores
Actualmente se cuenta con los siguientes las siguientes herramientas. Debe ser utilizada la que permita que el programa instalador cuente con
las características expuestas en el punto 8.6.1.
Visual Studio Installer
Es una herramienta incluida en el Visual Studio que permite la construcción de paquetes basados en el Windows Installer. Permite entre otras
las siguientes facilidades:
Programar la escritura en el registro de parámetros del sistema a nivel de usuario o de máquina

Incluir archivos adicionales a los del programa de instalación (Reportes, Ayudas, etc) y especificar la ubicación destino
Asistente para empaquetado y distribución de Visual Basic

Esta es una herramienta incluida con el Visual Basic 6.0 que permite crear instaladores con las siguientes características:
• Permite incluir archivos adicionales a los del programa de instalación (Reportes, Ayudas, etc) y especificar la ubicación destino

Página 106 de 132
VERSIÓN 4
9.7.3. Pruebas de Instaladores
Se cuenta con un ambiente de pruebas en diferentes sistemas operativos y versiones de Office antes de instalar nuevas versiones en producción
Debe ser posible que en el ambiente de pruebas se simulen las condiciones de software de los equipos clientes
Para realizar las pruebas de instalación es necesario que se cuente con el respectivo Manual Técnico
Los ingenieros de desarrollo deben solicitar vía help desk la preparación y ejecución de estas pruebas al ingeniero de soporte, especificando:
Las características de las máquinas a instalar en caso se conocerlas, o

El área y usuarios a quienes se hará la instalación para que soporte pueda verificar las características de los equipos de acuerdo con el
archivo maestro de inventario de máquinas y software (Ver Numeral 8.7)
Durante el proceso de prueba se debe levantar la respectiva documentación especificando la bitácora de pruebas y errores encontrados y su
solución. Esta documentación deberá presentarse dentro del manual de instalación
9.8. Archivos Maestro
9.8.1. Inventario de máquinas y software
Este documento debe contener la información de todos los computadores existentes en Consorcio y para cada uno de ellos tener debidamente
relacionada la siguiente información:
Nombre del Equipo

Ubicación Física (Sede, Piso, Area)
Area a la que pertenece
Nombre del(los) usuario(s) que hacen uso de este recurso
Inventario de software incluyendo la versión de Sistema Operativo y Office
El propósito de este documento es que, por una parte, las personas que aprueban la instalación revisen los requerimientos mínimos de software
y hardware al momento de aprobar la instalación (Ver Numerales 8.1 a 8.3) y, por otra parte, el ingeniero sepa todo el tiempo en qué equipos
está instalada su aplicación y pueda prever eventualidades como errores por manejo de concurrencia, etc.
Este documento reposará para consulta de los ingenieros en la carpeta \\OFISERVEREPS\Desarrollo$\Documentos y la realización de este
documento estará a cargo de Operación de TI
9.8.2. Inventario de Aplicaciones y Responsables
El propósito de este documento es que los Ingenieros de Soporte tengan una herramienta básica de consulta para ubicar rápidamente a una
persona responsable o delegada de una aplicación en el momento de la instalación del aplicativo o en algún otro caso donde el usuario les
reporte equivocadamente errores de la aplicación.
Este documento debe contener la siguiente información:
Código Aplicación
Nombre de la aplicación
Breve descripción
Responsable de la aplicación y Extensión
Delegado y Extensión

Página 107 de 132
VERSIÓN 4
9.8.3. Inventario de Instalaciones en equipos clientes
En este documento se registrarán los siguientes datos
Nombre de la aplicación
Persona que solicita la instalación
Justificación de Instalación
Culminación de la tarea de Instalación
La realización y mantenimiento de este documento estará a cargo del proceso de Operaciones de TI y se ubicará para consulta en la carpeta
\\OFISERVEREPS\Desarrollo$\Documentos\
9.9. Manejo de Versiones
Todas las aplicaciones deben contar con el manejo de número de versión que permita control de ingreso de usuarios cuando su equipo no se
encuentre actualizado a la última versión. El control debe restringir por completo el acceso al sistema en caso que así se requiera por las
implicaciones de los cambios o debe generar mensaje de advertencia sobre la desactualización de su equipo.
9.10. Buenas y malas prácticas
9.10.1. Malas Prácticas
En cuanto a los procesos de Instalación
No se deben copiar instaladores del repositorio a otras locaciones, si por la práctica es necesario hacerlo para mejorar tiempos de
respuesta, no se considerarán estos instaladores como los instaladores oficiales de la aplicación y deben ser borrados al terminar la
instalación

Página 108 de 132
VERSIÓN 4
10. Compromiso frente a la adecuada utilización de los recursos, desempeño y tiempos de respuesta en los sistemas de
información
Uno de los mayores compromisos y responsabilidades que tenemos como desarrolladores y gestores de sistemas de información, es el de
adecuarnos a las limitantes financieras impuestas tanto por la ley como por los parámetros de eficiencia fijados por la dirección.
En ese sentido características adicionales que deben poseer los desarrollos y los sistemas adquiridos son las de una utilización racional de los
recursos, utilización de procedimientos, métodos, e instrucciones eficientes que garanticen unos tiempos de respuesta adecuados para una
buena calidad de servicio, una baja utilización de servidores que permita a la organización crecer el volumen de afiliados y servicios sin que se
tenga que tener actualizaciones o crecimientos permanentes de plataforma.
Tener presente estos criterios durante el desarrollo y con ellos diseñar los procesos computacionales de tal forma que sean tenidos en cuenta
los diferentes elementos que interactúan cuando un sistema está en producción así:
Los componentes de software desarrollados

El servidor en cual residirá
Los accesos a la base de datos
La red sobre la cual operará
La configuración de los clientes en los cuales funcionará
Los procesos masivos establecidos
En virtud de lo anterior es muy importante analizar y determinar el uso adecuado de:
Operaciones de entrada /salida
Cantidad de registros mostrados en cada consulta
Análisis de información que viaja por la red
Volumen de la información a procesar
Restringir el uso de instrucciones pesadas.
Atender las prácticas asociadas con el ciclo de vida de los sistemas de Información. Debemos recordar que unas horas de más en el desarrollo
nos pueden traer años de eficiencia de los sistemas en producción.

Página 109 de 132
VERSIÓN 4
11. Documentación integral de los sistemas de información
La documentación completa y adecuada de cada uno de los Sistemas de Información es considerada como un aspecto fundamental que
promueve la calidad en cuanto a desarrollo, desempeño y operación de los aplicativos y por ende de los procesos en los cuales se apoya la
Caja para la prestación de sus servicios. La documentación integral de los Sistemas de Información será reflejada únicamente en dos
documentos maestros llamados Guía de Interacción de Usuario con el Sistema y Ficha Técnica del Sistema.
11.1. Guía de Interacción de Usuario con el Sistema
El objetivo de la Guía de Interacción de Usuario es facilitar y hacer más simple la interacción de los usuarios con el sistema, así como también
promover el proceso de manejo y aprendizaje sobre las aplicaciones , buscando por parte del usuario un desarrollo eficiente dentro de su
ámbito laboral.
11.1.1. Contenido de la Guía de Interacción de Usuario con el Sistema
El documento INS-GTI-007-DOCUMENTACIÓN PARA USUARIO SOLUCIÓN DE SOFTWARE - define las características del documento.
Debe tener en general los siguientes componentes:
Identificación del Sistema

Contenido
Objetivo
Alcance
Descripción de opciones y módulos del sistema
Descripción Mensajes de error
Descripción Reglas de Validación
Descripción de Salidas
11.1.2. Indicaciones para la elaboración de la Guía de Interacción de Usuario con el Sistema
La Guía de Usuario debe ser elaborada como un documento Word o equivalente estándar con encabezado y estructura según las definiciones
del Sistema General de Calidad en cuanto a documentación.
Tipo de letra Arial normal de tamaño 10 cpi.
El documento será guardado como documento de formato Inter. /intranet (Código HTML).
Las imágenes adjuntas deben ser en formato *.jpg.
El tamaño sumado de texto e imágenes del documento no puede sobrepasar 1 Mb.
El archivo debe estar protegido para impedir actualización por parte de los usuarios.
El nombre del archivo del documento debe guardar la siguiente estructura:
Guía de Usuario SW-xxxxxx.

Donde SW-xxxxx es el código de la aplicación.
11.1.3. Manuales Sistemas de Información adquiridos externamente
En caso de tratarse de sistemas de información adquiridos externamente, el manual de usuario se enmarcará claramente dentro del proceso
de adquisición del software y deberá estar explícito en el contrato. Adicionalmente y en cuanto sea posible adecuar la presentación, esquema
y contenido, de acuerdo con las definiciones . El proveedor deberá entregar 2 copias, una para la consulta del usuario final y la otra copia será
recibida por la Gerencia de Sistemas, para el archivo de documentación.

Página 110 de 132
VERSIÓN 4
11.1.4. Acceso y consulta del manual de usuario.
La Guía de Usuario podrá ser accedido a través de la Intranet en la sección “Guías de Usuario”. Allí aparecerán clasificados por los grandes
temas , Caja, Salud y Administración y dentro de cada tema, encontrarán el detalle de guías de cada una de las aplicaciones existentes.
11.1.5. Esquema de almacenamiento
En el servidor de TFS existe una carpeta por cada uno de los sistemas de información, clasificados por los grandes temas Caja, Salud y
Administración. Allí se almacenará la última versión actualizada de la Guía de usuario.
11.1.6. Políticas de actualización Guía de Interacción
El (La) ingeniero(a), es la persona responsable de actualizar los documentos originales en cuanto a su contenido, ya que es el directo
responsable de la forma como se maneja su respectiva aplicación.
Cada persona responsable de la aplicación debe coordinar con Operaciones de TI la generación de las versiones actualizadas en el ambiente
de producción respectivo (Intranet, Cliente).
El documento debe ser revisado por el Planificador de Construcción de Software que tiene responsabilidad sobre la aplicación y aprobado por
el Líder de Construcción de Software.
11.2. Documentación Técnica del Sistema
El objetivo de la documentación técnica es consolidar en un solo documento toda la información técnica relacionada con la elaboración del
software, así como la información requerida para su instalación e implementación.
11.2.1. Contenido del Manual Técnico del Sistema
El documento INS-GTI-006-DOCUMENTACION TECNICA SOLUCION DE SOFTWARE_ajustada - define las características del documento.
Debe contener en forma general los siguientes componentes:
Identificación del Sistema

Contenido
Platafoma tecnológica
Diagrama Entidad Relación
Diccionario de Base de Datos
Diagrama de Arquitectura del Sistema
Inventario de programas, lógicas y reportes
Proceso de instalación

Página 111 de 132
VERSIÓN 4
12. Integrador de sistemas - ISICOM
Todos los Sistemas de Información ó verticales que requieran información del Sistema Central de Afiliados deben hacerlo a través del Web
Services ISICOM. Actualmente cuenta con dos servicios AF y AFSYS.
AF: Este servicio provee información de las tablas del Sistema Central de Afiliados y retorna información en formato XML. Actualmente
suministra información de Afiliado, Empresa, Personas autorizadas para retirar cheques y Citas Médicas.
AFSYS: Este servicio permite el acceso al Sistema Central de Afiliados a través de los Ispecs ó formatos. Actualmente cuenta con dos métodos:
GetFields: Este método retorna en XML la definición del Ispec, con opción 1 retorna cada campo del ispec con su definición como Nombre,
Tipo (A ó N), Valor actual, Longitud y si es de Lectura (R) o no, con la opción 0 retorna un XML con un registro que contiene los valores
predeterminados del Ispec, cada columna representa cada campo del ispec.
Ispec: Este método procesa la información enviada por la aplicación al Ispec definido como parámetro. Requiere el ingreso de los datos en
formato XML de la misma forma como lo retorna el método GetFields en la opción 0. Se pueden obviar los campos que no se deseen enviar ó
que no sean necesarios para la aplicación. Importante tener en cuenta que este método en todos los casos retorna una nueva columna llama
MESSAGE que contiene la respuesta del Ispec. Esta respuesta debe ser analizada por la aplicación para determinar si la transacción fue
exitosa o no. En caso de que no sea exitosa el mensaje contiene el detalle de la validación.
12.1. Arquitectura ISICOM

Página 112 de 132
VERSIÓN 4
.NET IIS
XML
Seg
urid
X Servicio Servicio
M
EAE AF
L
(S Componentes
O AF
.ASP IIS empresariales
Comp de
Acceso a
Datos
ADO
Recordset
VB 6.0 XML
cSoap.dll Servicio
Windows
Clases
EAE
ADO
Recordset
cSoap.dll MSM
Q

Página 113 de 132
VERSIÓN 4
13. Lista de chequeo en aplicaciones .NET

El objetivo de esta lista de chequeo es garantizar que las aplicaciones cumplan con los estándares definidos y con las expectativas de
escalabilidad, confiabilidad, flexibilidad, rendimiento, y disponibilidad fijadas por las necesidades del negocio. Además de facilitar la evolución
y migración a nuevas tecnologías.
A continuación se describen las mejores prácticas que se deben tener en cuenta para el diseño, presentación, implementación, base de datos,
seguridad y configuración.
13.1. Diseño
13.1.1. Patrónes de diseño:
El principal objetivo de los patrones de diseño es utilizar buenas prácticas que nos permitan mejorar la calidad del diseño del software, reducir
esfuerzos de desarrollo y de mantenimiento. Los patrones son soluciones probadas a problemas comunes y su uso nos dan la posibilidad de
organizar nuestras clases en estructuras comunes y bien probadas, mejorar las aplicaciones en cuanto a flexibilidad, modularidad y
extensibilidad.
Toda aplicación debe evaluar su utilización a nivel estructural, de creación y comportamiento de objetos.
13.1.2. Aprovechamiento adecuado del cache:
Es una buena alternativa para mejorar el rendimiento de la aplicación y para hacer más eficiente el consumo de recursos disponibles, se debe
usar para almacenar tablas de referencia ó valores que no cambian en el tiempo y que se requieren para varios procesos de la aplicación.
El otro mecanismo son las variables de sesión que se deben utilizar para pasar información entre solicitud y solicitud, una aplicación web
funciona basada en http, esto significa que cada solicitud se trata como un ente independiente, se crea, se procesa y se destruye, por ello, la
sesión, el view state y la información de la aplicación permite mantener el estado entre solicitud y solicitud.
Es muy importante utilizar la granularidad adecuada para el almacenamiento y manipulación de este tipo de variables, ya que si no se realiza
adecuadamente, el CLR de .NET estará alocando memoria de forma ineficiente.
En ASP.NET existen tres mecanimos para almacenar la información: Inprocess, State Server y SQL Server, se debe evaluar el uso en el
escenario específico.
13.1.3. Separación de responsabilidades:
Es necesario que toda aplicación esté separada en capas para delimitar responsabilidades entre quien debe realizar ciertas tareas, las capas
no deben ni tienen porque saber de cómo y con quien interactúan las otras capas. Con esta delimitación no se debe presentar que en la capa
de presentación tenga lógica de negocio ó lógica de acceso a datos, o que la lógica de negocio tenga lógica de acceso a datos.
13.1.4. No utilización de direcciones IP ó nombres de equipos de los clientes.
Se debe diseñar una estrategia diferente a la utilización de las direcciones IP para mecanismos de identificación ó autorización, en escenarios
con direcciones IP dinámicas ó públicas es imposible su control.
13.2. Presentación
13.2.1. Diseño gráfico:

Página 114 de 132
VERSIÓN 4
Toda aplicación debe tener el diseño gráfico estándar definido por Consorcio que incluye estilos, encabezados, página de bienvenida, diseño
de páginas funcionales, controles de login, cambio de contraseña, navegación, botones, imágenes, salida del sistema y presentación de
mensajes.
Se encuentra en el TFS en la carpeta de Calidad.
13.3. Implementación
13.3.1. Validación de tipos de datos/formato:
Validar la entrada de datos para comprobar lo que ingresa el usuario en busca de errores y, si es necesario, mostrar mensajes. Una forma es
utilizar controles de validación de .NET que se añaden a una página de la misma forma que el resto de controles. Hay controles para tipos
específicos de validación, por ejemplo comprobación de rango o coincidencia con patrones, además de un RequiredFieldValidator que asegura
que un usuario no olvide ingresar ó seleccionar un valor. Se pueden asociar más de un control de validación a un control de entrada para
especificar tanto que un campo es obligatorio y que debe contener un rango específico de valores.
Adicionalmente, hacer validaciones de datos en la frontera de entrada de los componentes y verificar la nulidad para no generar
NullReferenceExceptions.
13.3.2. No duplicidad de código:
Se debe mantener unificado y organizado el código en unidades reutilizables desde los diferentes módulos del sistema. Es clave separar las
tareas relacionadas a configuración, acceso a datos, validación, construcción de objetos y elementos funcionales. La duplicidad dificulta la
depuración para encontrar defectos y de hecho hace al código más propenso a la aparición de defectos en el mediano y largo plazo.
13.3.3. No utilizar OCX ni componentes COM :
La utilización de OCX crea dependencia de la plataforma del cliente y comprometen la seguridad de este.
13.3.4. Interfaces comunes:
Se deben definir interfaces comunes en la implementación, a través de una interfaz o una clase abstracta si el caso está relacionado con una
jerarquía completa de clases en las cuales se puede reutilizar funcionalidad a través de la herencia, los componentes deben estar abiertos a
extensión pero cerrados a modificación de tal manera que no tenga que cambiar el componente ni la consecuente redistribución del mismo.
13.3.5. Manejo de excepciones:
El manejo estructurado de excepciones en las aplicaciones con Microsoft .NET Framework está basado en un esquema jerárquico de clases
que agrupan diferentes categorías de error en la ejecución de la aplicación. Esta especialización permite tener diferentes comportamientos en
el procesamiento de las excepciones de la aplicación dependiendo del tipo. Si las excepciones se generalizan demasiado, durante la ejecución
del código es difícil tomar decisiones de manera programática. Igualmente si la información del contexto de la excepción se almacena en
cadenas de texto que solo contienen mensajes de descripción del problema, estos difícilmente se pueden utilizar en las aplicaciones.
Se recomienda que las clases que representen excepciones hereden de la clase ApplicationException, para mantener la jerarquía de las
excepciones. Igualmente deben tener un modelo de especialización que permita utilizarlas en contextos particulares, recopilando la mayor
información posible para tomar alguna acción en el momento de ser atrapadas y así también permitir la creación de nuevas excepciones sin
impactar el código existente.
En la definición de esta jerarquía es importante identificar primero que excepciones ya existen en el .Net Framework para la condición que se
quiere encapsular, que condiciones requieren un tratamiento o procesamiento particular que se pueda discriminar para evitar la utilización de

Página 115 de 132
VERSIÓN 4
excepciones muy genéricas que no permitan tomar todas las decisiones, y finalmente se debe evaluar si se debe encapsular algún
comportamiento en particular como parte de la excepción.
13.3.6. Captura y propagación de las excepciones:
Las excepciones únicamente se deben atrapar si se va a ejecutar alguna de las siguientes acciones: obtener información para registrar en el
sistema, adicionar información relevante a la excepción, ejecutar código de limpieza, intentar la recuperación. Si ninguna de estas tareas se va
a realizar, no se debe atrapar la excepción, y por el contrario se debe permitir que se siga propagando hasta el cliente, hasta encontrar la
ubicación apropiada para hacer su procesamiento.
13.3.7. Registro de excepciones:
El registro de excepciones es responsabilidad del framework que cuenta con la clase FactoryMensaje especializada en estas tareas, permite
mediante un proveedor configurar cual es el repositorio para manejar apropiadamente los esquemas de información de la excepción.
13.3.8. Manejo de variables y conversiones:
Una de las tareas más costosas en ejecución es el “Cast” de variables ya que requiere la carga de definiciones de tipo y la manipulación en
memoria de los mismos, es importante minimizar el uso de esta operación.
13.3.9. Utilización de cadenas:
El manejo de concatenación de cadenas con el operador &, afecta fuertemente el rendimiento en términos de consumo de CPU, Memoria y
presión al Garbage Collector, se debe utilizar la clase System.Text.StringBuilder para la preparación de cadenas compuestas, esta forma reduce
el tiempo de procesamiento y el consumo de recursos.
13.3.10. Comentarios relevantes:
El código fuente, procedimientos almacenados y ETLs debe ir documentados en la medida que se requiera especificar validaciones,
parámetros, condiciones especiales, modificaciones en comentarios, procesos importantes, etc., de manera que cualquier desarrollador pueda
comprender la ejecución de la misma. Cómo mímimo debe indicar:
Fecha, Autor,
Ultima fecha de modificación,
Propósito,
Parámetros,
Salidas.
Para ETLs:
Fecha,
Autor,
Descripción general,
Bases de datos y tablas que accede,
Prerrequisitos,
Actualiza S/N,
Reprocesable S/N,
Destino (si es insumo para otro proceso mencionar cual, si es para un área mencionarla, si es para un usuario específico, etc),
Ruta y nombres de archivos de salida, si los genera.
Forma de ejecución, si es manual, si debe ser programada ó si se activa por alguna aplicación.

Página 116 de 132
VERSIÓN 4
Periodicidad
Colocar un nombre descriptivo en cada tarea que ejecuta el ETLs
Todos los ETLs deben generar log de eventos.
13.3.11. Estructuras heredades de VB6:
No se debe importar lógica de visual basic 6.0 porque puede generar problemas de compatibilidad y mantenimiento.
13.3.12. Compilación estricta y explícita:
Se debe mantener esta configuración activada para garantizar que todas las variables utilizadas estan definidas y con un tipo de dato, no
permite declaración de variables genéricas.
13.4. Base de datos
13.4.1. Utilización de la clase cDatos del framework:
Esta clase implementada en el framework utiliza componentes provistos por Enterprise library para el acceso a datos y esta integrada con
adminus para obtener la cadena de conexión, los módulos comunes de Enterprise Library permiten un desarrollo más rápido y fácil en el
entorno de la plataforma .NET, actualmente a través de esta clase se pueden ejecutar los siguientes comandos:
ExecReader():Ejecuta el commando y retorna un IDataReader. Es responsabilidad del llamador cerrar la conexion para que el reader sea
destruido.
ExecDataSet():Ejecuta un comando y retorna un resultado en el Dataset.
ExecNonQuery():Ejecuta el commando y retorna el número de filas afectadas.
ExecScalar():Ejecuta el commando y retorna la primera columna de la primera fila del resultado.
13.4.2. Sentencias SQL en el código:
Se debe mantener al mínimo secciones de código SQL “quemadas” en el código .NET, ya que se pueden generar amenazas como SQL
injection, o problemas para el mantenimiento adicional y la constante necesidad de re compilación de consultas por parte del motor de base de
datos que afectan el rendimiento.
13.4.3. SQL dinámico en los procedimientos almacenados:
Esta práctica también genera al igual que las sentencias en el código, re compilaciones de dichos procedimientos en el servidor de base de
datos generando un mayor tiempo de respuesta.
13.4.4. Manejo y contexto de los errores en base de datos:
Los motores relacionales como SQL utilizan un mecanismo para informar la existencia de un error que es propagado a través de una excepción
de acceso a datos. Esta es la mejor manera de hacerlo y la infraestructura del .NET Framework provee soporte a través de las propiedades de
las clases SqlException y OleDbException entre otras.
Cuando se requiere propagar una situación de error desde sqlserver se utiliza la palabra Raiserror, mediante la cual se indica la severidad y el
mensaje de error asociados sin tener que modificar la interface funcional expuesta por el procedimiento almacenado.

Página 117 de 132
VERSIÓN 4
Es muy importante tener claro que los errores generados en las capas de datos y acceso a datos, por lo general no representan errores a nivel
de negocio sino simplemente un detalle que hace parte de un error más complejo, es por esto, que no se recomienda entregar códigos o
números de error relacionados al negocio desde la base de datos o la capa de acceso a datos, estos códigos de error de negocio deben ser
asignados a niveles superiores a partir de la información obtenida de los errores de bajo nivel. Solo en el caso de ser un error no controlable o
no conocido por los niveles superiores se debe propagar la información de las excepciones de acceso a datos.
13.4.5. Estándares de nomenclatura de Bases de Datos:
Los objetos de la base de datos deben cumplir con los estándares de nomenclatura que se encuentran detallados en este documento
13.4.6. Definición de cadenas de conexión:
Las cadenas de conexión se definen en Adminus en el módulo administrador de cadenas de conexión, se define el servidor, base de datos,
usuario y contraseña. Estos parámetros son consultados por la clase cDatos del framework para establecer la conexión a la base de datos, lo
hace a través del web service wseguridad previa autenticación. La aplicación no requiere hacer ninguna definición de este tipo en el archivo de
configuración, ni tiene porque solicitar directamente la cadena de conexión al servicio.
13.4.7. Planes de ejecución
En ningún caso es aceptable que se encuentre un Table scan sobre tablas transaccionales o debe ser justificado y documentado
suficientemente
13.5. Seguridad
13.5.1. Protección del archivo de configuración ante cualquier modificación:
Al estar desprotegidos los archivos de configuración, se convierte en una vulnerabilidad relevante para la estabilidad de la aplicación, es
importante utilizar los mecanismos provistos por la plataforma para proteger esta información. Actualmente el framework tiene la clase cDpapi
con la que se puede encriptar todos los valores de la sección Appsettings del web.config. Es un API de protección de datos y lo utiliza el
framework para ayudar a proteger la clave privada, esta clave es administrada por el sistema operativo en lugar de la aplicación. DPAPI no es
responsable por almacenar la información confidencial que protege, sólo es responsable por cifrar y descifrar los datos. Al utilizar DPAPI, la
cadena cifrada es específica de un equipo determinado y por lo tanto, debe generarse en cada servidor donde se instala la aplicación.
13.5.2. Datos de usuarios y/o contraseñas explicitas en el código:
Uno de los principios básicos de seguridad en programación es evitar el almacenamiento de secretos en el código, si son datos para
autenticación a nivel de la aplicación, se deben almacenar encriptados en el archivo de configuración y si son usuarios de la aplicación deben
estar definidos en el Sistema de administración de usuarios Adminus.
13.5.3. Algoritmos de encripción implementados:
La utilización de algoritmos propios de encripción no son seguros. para eso existen algoritmos estándar provistos por el framework de .NET.
13.5.4. Adopción de Adminus:

Página 118 de 132
VERSIÓN 4
Adminus es el sistema de administración de usuarios y permisos para las aplicaciones , todas las aplicaciones deben tener esta implementación
que se hace a través de los providers, ninguna aplicación puede tener módulos propios para administrar usuarios.
13.5.5. Utilización de los providers del framework:
Estos providers facilitan la autenticación de los usuarios del dominio y/o fuera del dominio, tambien permiten el cambio de contraseña de
usuarios que no están en el dominio y el cargue del SiteMap (el cambio de contraseñas de usuarios del dominio se hace a través de windows),
estas clases están implementadas para trabajar con los controles propios de .NET que realizan estas tareas, acceden la base de datos de
Adminus para hacer la autenticación y para consultar los permisos del usuario, si es un usuario del dominio el framework hace la autenticación
en el directorio activo y si es un usuario que no está en el dominio la autenticación se hace en Adminus, todo depende del parámetro de
autenticación definido (1: aplicación para usuarios windows, 2: aplicación para usuarios que no están en el dominio 3: aplicación para ambos
tipos de usuarios).
En el caso de que la aplicación tenga usuarios que no estan en el dominio, se debe implementar el cambio de contraseña, consiste en utilizar
el control de .NET de cambio de contraseña y solicitar el cambio cuando el provider lo exija (cuando el usuario es nuevo o porque la clave esta
vencida), posteriomente utilizar la funcionalidad del provider para procesar el cambio.
13.5.6. Acceso a servicios Web a través del framewok:
Es importante acceder a los web services que requiera la aplicación a través de las clases proxys creadas en el framework, hay mecanismos
de seguridad (autenticación, autorización) que hace el framework en los servicios.
13.5.7. ViewState protegido:
El view state (estado de los controles presentes en un formulario) debe estar protegido para evitar acciones como el Tampering que consiste
en la modificación manual de los datos. Se puede manejar el parámetro de encripción en el web.config para mantenerlo protegido a nivel de
toda la aplicación.
13.6. Procedimiento de Test
La aplicación debe tener una página de test para verificar su correcta instalación donde se compruebe la correcta configuración de adminus,
disponibilidad de servicios, acceso a base de datos, etc.
13.7. Configuración
13.7.1. Definición de cadenas de conexión:
Ninguna aplicación debe definir cadenas de conexión en los archivos de configuración, además no lo requieren porque el framework se encarga
de obtener la cadena de conexión utilizando el código de aplicación definido en el archivo de configuración.

Página 119 de 132
VERSIÓN 4
13.7.2. Verificación de que el valor de un parámetro de configuración no se ha definido:
Es importante que la aplicación valide a través de una funcionalidad que los parámetros de configuración se hayan definido y que estén bien
definidos, que no correspondan a un valor por defecto, de lo contrario indicar que dicho parámetro no se ha configurado.
13.7.3. Utilización del código de aplicación:
Toda aplicación tiene un código único asignado para identificarla, este código siempre debe estar definido en el archivo de configuración y es
el que la aplicación debe leer para enviar a los diferentes servicios integradores que lo soliciten, este código tambien es utilizado por el
framework para obtener la cadena de conexión.
13.7.4. Rutas de archivos:
Esta información se debe almacenar como parámetro en el archivo de configuración para su fácil administración.
13.7.5. Administración del estado de sesión:
Se debe evaluar la configuración más adecuada:
• InProcess: para aplicaciones generales con menos de 200 usuarios, donde el estado de la sesión se maneja en el mismo proceso donde se
ejecuta la aplicación.
• StateServer: Se utiliza cuando hay mayor carga, el estado de la sesión corre en un proceso separado, en el mismo servidor ó en otro
servidor.
• SQL Server: Para mayor carga con escenarios web farm ó web garden, el manejo de la sesión es similar al stateserver
13.7.6. Opción de compilación para depuración:
Esta opción del archivo de configuración debe permanecer siempre en false para ambientes de producción, con este valor la ejecución se lleva
a cabo de una forma más rápida y utiliza menos recursos del sistema ya que no adjunta el depurador, si se deja en true se está habilitando la
depuración y se está adjuntando el depurador a la ejecución del código, lo cual afecta considerablemente el rendimiento de la aplicación,
además en caso de error se estaría mostrando demasiada información del error al usuario.
13.7.7. Opción de trace
Esta opción del archivo de configuración debe permanecer en false, solo se habilitaría para aplicaciones en seguimiento
13.7.8. Llaves en el web.config
No se deben definir varias llaves con el mismo valor, no hay razón técnica para hacerlo, además dificulta su administración.
13.7.9. Llaves comentariadas en el web.config
El web.config no debe contener llaves comentariadas con datos, urls de pruebas, cadenas de conexión, etc.
13.8. Instaladores

Página 120 de 132
VERSIÓN 4
Instaladores Los instaladores deben ser archivos MSI y todas las aplicaciones deben estar compiladas en release para su instalación en
producción y en ningún caso debe contener archivos fuente.
13.8.1. Nombre del instalador
El nombre del instalador debe corresponder al nombre de la aplicación. ejemplo: Adminus.msi
13.8.2. Assemblies en el GAC
Si la aplicación requiere assemblies en el GAC se debe crear un instalador para hacer este registro, no se debe solicitar procedimientos
manuales en la instalación.
Impresión de Reportes
Opciones para generar información:
• Información generada en páginas htm

• Exportación de archivos en formato XML
• PDFs que se deben generar utilizando el componente Itext con la debida restricción de seguridad.
• Archivos Planos
• Archivos planos con formato para que se puedan abrir en excel. No se pueden utilizar componentes propios de office para generar
información porque se crea dependencia con estas herramientas y con versiones actuales.
• Reporting Services, todos los reportes se deben construir en esta herramienta teniendo en cuenta las siguientes recomendaciones:
o Las aplicaciones deben utilizar el Report Viewer para mostrar los reportes al usuario
o Los parámetros del reporte se deben manejar con controles de .NET (con validación) y no mostrar el prompt default de reporting
services.
o Los reportes deben obtener sus datos únicamente a través de procedimientos almacenados.
o Los reportes se deben organizar en carpetas por aplicación y deben manejar orígenes de datos compartidos.
Documentación
Documentación mínima que debe tener toda aplicación,
Manual de usuario
Manual técnico
Diagramas de Arquitectura (componentes y despliegue)
Fuentes
El repositorio único de fuentes y documentación es el TFS, teniendo en cuenta las políticas definidas para la utilización de esta herramienta.
Browser del cliente

Página 121 de 132
VERSIÓN 4
Todos sitios web (paginas, reportes, validaciones y controles en el cliente) deben ser compatibles con los navegadores de internet más
utilizados como internet explorer (9.0, mínimo 8.0), Chrome (mínima versión 48.0.2564.82), Mozilla (mínima versión 44), Safari (mínima versión
9).
Lenguaje de Desarrollo
El lenguaje de desarrollo de las aplicaciones de Consorcio es Visual Basic.
Seguimiento
Deben tener un log de transacciones activable desde el web.config, la estructura debe mantener el estándar de los servicios como ISICOM
Respuestas erradas
Dentro de lo posible se debe mantener un número reducido de respuestas erradas, preferiblemente un solo mensaje para todo lo que sea error
de software y/o plataforma, registrando el detalle del error en el Event Log
13.9. Auditoría
13.10. Reportes / Impresión
13.10.1. Reportes
Opciones para generar información:
• Información generada en páginas htm

• Exportación de archivos en formato XML
• PDFs que se deben generar utilizando el componente Itext con la debida restricción de seguridad.
• Archivos Planos
• Archivos planos con formato para que se puedan abrir en excel. No se pueden utilizar componentes propios de office para generar
información porque se crea dependencia con estas herramientas y con versiones actuales.
• Reporting Services, todos los reportes se deben construir en esta herramienta teniendo en cuenta las siguientes recomendaciones:
o Las aplicaciones deben utilizar el Report Viewer para mostrar los reportes al usuario
o Los parámetros del reporte se deben manejar con controles de .NET (con validación) y no mostrar el prompt default de reporting
services.
o Los reportes deben obtener sus datos únicamente a través de procedimientos almacenados.
Los reportes se deben organizar en carpetas por aplicación y deben manejar orígenes de datos compartidos.
13.11. Documentación
Documentación mínima que debe tener toda aplicación :
Manual de usuario
Manual técnico
Diagramas de Arquitectura (componentes y despliegue)

Página 122 de 132
VERSIÓN 4
13.12. Fuentes
El repositorio único de fuentes y documentación es el TFS, teniendo en cuenta las políticas definidas para la utilización de esta herramienta.
13.13. Otros
13.13.1. Lenguaje de Desarrollo
El lenguaje de desarrollo de las aplicaciones de Compensar es Visual Basic.
13.14. Servicios Web
13.14.1. Seguimiento
Deben tener un log de transacciones activable desde el web.config, la estructura debe mantener el estándar de los servicios como ISICOM
13.14.2. Respuestas erradas
Dentro de lo posible se debe mantener un número reducido de respuestas erradas, preferiblemente un solo mensaje para todo lo que sea
error de software y/o plataforma, registrando el detalle del error en el Event Log

Página 123 de 132
VERSIÓN 4
Dentro de los temas explicados en la charla, puedo destacar los siguientes:

Justificación de la existencia de al menos tres capas. Es necesario que cualquier aplicación de mediana o gran envergadura
esté separada en las capas de Presentación, Negocio y Datos. Esto es para delimitar responsabilidades entre quien debe realizar
ciertas tareas, y por que las capas no deben ni tienen por qué saber de cómo y con quien interactúan las otras capas.
Existencia de las entidades de negocio. Las entidades de negocio representan elementos del mundo real, y que son utilizados
por los procesos que componen nuestra aplicación, como por ejemplo órdenes de compra, usuarios o un grupo de permisos.
Formato de las entidades de negocio. Dentro de las opciones revisadas se presentaron el uso de XML, Datasets tipificados o no
y clases desarrolladas en algún lenguaje como C# o VB. Los criterios de definición nos hacen decidirnos teniendo en cuenta
necesidades como de ordenación de estas o buscar sobre un grupo, si se requiere hacer bind sobre controles o el nivel de acceso que
tendrán (local o remoto – web services). Hay que considerar que no existe un formato único. Cada entidad requiere un estudio propio.
Comunicación entre las capas. Las distintas capas se comunican en gran medida utilizando entidades de negocio. Hay algunas
veces que no es necesario o en definitiva no es posible. Por ejemplo, para realizar eliminaciones no es necesario utilizar una entidad.
Con entregar los elementos que identifican el elemento basta. Igual sucede al buscar algún elemento.
Visibilidad entre las capas. La visibilidad se da desde cualquier capa a la capa inmediatamente inferior. No es posible desde una
capa ver a la capa superior ni tampoco saltarse alguna capa hacia abajo y poder acceder a alguna que se encuentre dos o más niveles
por abajo, como por ejemplo que interfaz puede acceder a datos directamente. Si bien la propuesta original lo permite, no creo que sea
correcto. Esta restricción impuesta generó consultas durante la presentación, la que serán expuestas más adelante.
Visibilidad dentro de las capas. Cada capa tiene sus reglas de visibilidad interna. Los casos importantes son la capa de datos y
negocio. Es evidente que entre elementos de negocio debe haber comunicación pero no así dentro de los elementos de datos. No es
posible que un elemento de datos llame a otro de datos. La razón es simple. La ejecución de algún método de datos que se encuentre
dentro de una orquestación realizada desde negocios requiere ciertas validaciones. La orquestación y validación se hace en negocio,
por lo tanto, la capa de datos no puede realizar más acciones que la estrictamente solicitada.
14. Arquitectura de los sistemas de información
La Arquitectura Empresarial de Sistemas de Información, está definida por los siguientes aspectos
14.1. Arquitectura de referencia para aplicaciones y servicios

Página 124 de 132
VERSIÓN 4
Internet
Aplicaciones
ISA Server
Web
Service
WSComCaja WSComIps WSComAdm WSComEps
s o
Web
Services
Conector WIsicom
ES7OO0
O
Framework Seguridad, Providers
Acceso a Datos estándar
Assembly Clases genéricas
y
Bases de AF
Datos
14.1.1. Aplicaciones
Aplicaciones web .NET Framework 2.0

Aplicaciones Windows Framework 2.0
14.1.2. Web Services
Conjunto de servicios donde se expone funcionalidad y lógica de negocio para facilitar su integración:
Wscomadmo: Servicio que expone funcionalidad de negocio relacionada con procesos Integradores como la lógica para recepción y
registro de recaudos. (Ej: Recaudos realizados a través de la aplicación SAC y Sitio transaccional web ).

Página 125 de 132
VERSIÓN 4
Wscomeps: Servicio que expone la funcionalidad de negocio relacionada con procesos de Aseguramiento en Salud (Ej: Autorización
de servicios de salud a través de SAS, Audiorespuesta, Sitio transaccional WCompensar, IPS externa Sisalud).
Wscomclientes: Servicio que expone la funcionalidad de negocio relacionada con procesos de Relacionamiento. (Ej: Registro de
clientes y Vinculación Pos, Vinculación CCF, etc.).
14.1.3. Web Service Conector
Servicio web conector que expone toda la funcionalidad del ES7000 a las aplicaciones de plataforma abierta, a través de los servicios
a) AF: Consultas SQL y b) AFSYS: Acceso a la lógica del ES7000 utilizando los ispecs (Componentes java bin plataforma ABS.
14.1.4. Assembly
Componente de software construido, especializado en seguridad, acceso a datos, y métodos comunes. Los objetivos de este estándar
son:
Facilitar el uso de los estándares definidos referente a seguridad y acceso a los datos
Agilizar el desarrollo de las aplicaciones de negocio porque se desentienden de la capa de datos y seguridad adicionalmente se ofrecen métodos
como impresión y acceso a otros servicios
Proveer integración encapsulada con adminus (
Promover la reutilización de código
Facilitar el mantenimiento
Adoptar mejores prácticas en el desarrollo de software
14.1.5. Bases de datos
Modelo de datos basado en las siguientes características:
Base de datos única de clientes

Bases de datos complementarias agrupadas por frente de negocio (Salud, Bienestar, Relacionamiento, Integradores)
Bases de datos específicas para cada solución de negocio
14.2. Implementación de aplicaciones .NET
Arquitectura en Capas
Son aplicaciones en capas, donde cada capa expone servicios que otras aplicaciones o capas pueden consumir, y donde cada capa puede
consumir servicios de otras
Ventajas
Reutilización de software.
Estas funcionalidades pueden estar en ubicaciones diferentes, incluso con tecnologías diferentes para mejorar la escalabilidad.
Se minimizan los efectos de cambiar una capa
Se puede comunicar con otros servicios que involucran múltiples protocolos, formatos de datos.
¿Cuáles son las capas y qué componente se coloca en cada capa?

Página 126 de 132
VERSIÓN 4
Comunicaciones
Seguridad
Usuarios
Componentes de IU
Componentes de Proceso de IU
Interfaces de Servicios
Lógica Entidades del

de Negocio Negocio
Componentes de Acceso a Agentes de Servicios

Datos
Datos Servicios
Componentes de interfaz de usuario: Son las formas, controles, etc, encargados de leer y mostrar datos al usuario.
Procesos de interfaz de usuario: Son componentes propios en el cliente, encargados de mostrar los datos del usuario, obtiener los datos del
usuario, interpretar los eventos del usuario, Cambiar el estado de la interfaz y facilitan las tareas al usuario.
Interfaces de servicios: Es el punto de entrada de la Capa de Negocio, expone la funcionalidad que otras aplicaciones pueden consumir. Se
implementa con Servicios Web o Remoting (en caso de aplicaciones distribuidas), tambien se puede implementar con otras tecnologías: BizTalk
Server, Message Queues...
Lógica de Negocio: Es la capa encargada de implementar actividades y lógica del negocio, es la implementación en software de conceptos de
negocios, encapsulan las reglas de negocio de la aplicación, relacionadas con las entidades de negocio. Algunos métodos requieren acceder
a la base de datos.
Entidades de Negocio: es la representación de los datos y su composición, encapsulan y ocultan los detalles de representación de datos.
Encargado de representar los datos en esquemas relevantes del negocio, opcionalmente encapsulan comportamiento (lógica) y definir formas
de composición, ejemplo: XML, Dataset, Dataset tipados y objetos propios.
Se referencian desde la capa de presentación, desde la interfaz de servicio y desde los componentes de negocio.

Página 127 de 132
VERSIÓN 4
Componentes de Acceso a Datos: Encapsulamiento de acceso a datos y lógicas de transformación, encargados de encapsular el acceso a
datos.
Datos: Almacenamiento persistente de los datos
Agentes de Servicios: Proxies de Web Service .NET, Componentes Propios, encargados de invocar servicios externos, transformar y formatear
datos. Es una forma de Componente de Acceso a Datos de servicios
Servicios de Integración: Como Web Services, MSMQ Listeners, encargados de exponer funcionalidad del Negocio
14.3. Implementación de web services
Web Services
Los servicios encapsulan sus propios datos y métodos, funcionando como una aplicación independendientes, desde el punto de vista conceptual
los servicios se pueden considerar como componentes de la solución global, se comunican mediante el intercambio de mensajes (cadenas de
texto o XML)
Ventajas
• Los servicios se diseñan para comunicarse entre sí con el mínimo grado de acoplamiento.
• Cada servicio está formado por una aplicación que dispone de sus propios orígenes de datos, lógica empresarial e interfaces de usuario.
• Puede generar y exponer un servicio que no disponga de interfaz de usuario directamente asociado
• Cada servicio encapsula sus propios datos y administra las transacciones atómicas con sus propios orígenes de datos.
Servicio
Entidades de
Negocio Componentes de
Acceso a Datos
Lógica de
Negocio Agente de Servicios
Orquestador de DataTransferObjects
procesos

Página 128 de 132
VERSIÓN 4
Entidades de Negocio: es la representación de los datos y su composición, encapsulan y ocultan los detalles de representación de datos.
Encargado de representar los datos en esquemas relevantes del negocio, opcionalmente encapsulan comportamiento (lógica) y definir formas
de composición, ejemplo: XML, Dataset, Dataset tipados y objetos propios.
Se referencian desde la capa de presentación, desde la interfaz de servicio y desde los componentes de negocio.
Lógica de Negocio: Es la capa encargada de implementar actividades y lógica del negocio, es la implementación en software de conceptos de
negocios, encapsulan las reglas de negocio de la aplicación, relacionadas con las entidades de negocio. Algunos métodos requieren acceder
a la base de datos.
Orquestador de procesos : Es la capa encargada de gestionar y orquestar todo el flujo de información entre las capas que realizan las funciones
propias del negocio. Ejemplo, el proceso para realizar una vinculación de un cliente, toma los datos que envía la aplicación, utiliza los
DataTransferObjects para crear un objeto tipado que pueda ser transformado en una entidad de negocio que luego es enviada a la lógica de
negocio, esta capa es la responsable de realizar la vinculación a través de servicios de acceso a datos (isicom) para realizar transacciones en
el ES7000.
Componentes de Acceso a Datos: Encapsulamiento de acceso a datos y lógicas de transformación, encargados de encapsular el acceso a
datos.
Agente de Servicios: Proxies de Web Services.NET, Componentes Propios, encargados de invocar servicios externos, transformar y formatear
datos. Es una forma de Componente de Acceso a Datos de servicios
DataTransferObjects: Son los esquemas tipados que representan tablas relacionadas. Sirven para almacenar los valores de las variables en
xml que se van a ser transportados de envío ó de respuesta.
14.4. Arquitectura de seguridad

Página 129 de 132
VERSIÓN 4
GLOSARIO
Ambiente: corresponde al conjunto de elementos de infraestructura y plataforma dispuestos para un fin específico; se define dentro de la
infraestructura de Consorcio la generación de los ambientes de desarrollo, pruebas, preproducción y producción.
Aplicación de Gestión de Requerimientos: herramienta de software que permite la administración de los requerimientos.
Caso de Uso: Herramienta que permite especificar requerimientos de negocio de manera detallada con el fin de ser codificados en una
herramienta de desarrollo de software.
Gestión del Portafolio Aplicaciones: proceso centralizado que realiza la planificación del desarrollo, despliegue y mantenimiento del las
aplicaciones del Portafolio. Comprende la identificación y priorización de demanda sobre las aplicaciones así como la inclusión de productos
de proyectos tecnológicos.
Gestor: persona encargada de distribuir los requerimientos.
Gestor de Cambio: persona que realiza la solicitud de cambio (pruebas o producción).
Incidente: Reporte de errores o fallos encontrados dentro del portafolio de aplicaciones.
Ingeniero: persona que efectúa el desarrollo de la solución.
Mantis: La herramienta utilizada para la gestión de requerimientos, es un software que facilita la inclusión, seguimiento, ingreso de novedades,
solicitudes y control de estados de los requerimientos
Página 130 de 132
VERSIÓN 4
Mejora: Corresponde con la inclusión de una nueva funcionalidad o componente de software relacionado con el portafolio de aplicaciones.
Portafolio Aplicaciones: conjunto de aplicaciones de software que dan soporte al negocio, agrupados para facilitar su gestión, y que dan
respuesta a los objetivos estratégicos de la organización.
Requerimiento: solicitud para un sistema de información con el fin de adicionar o mejorar funcionalidad actual o de generar información a partir
de los datos que se encuentran registrados en la base de datos del aplicativo.
Requisito (s/DRAE): Circunstancia o condición necesaria para algo.
Requisitos funcionales: Comportamientos que debe tener el sistema ante cada estímulo externo. También denominados "casos de uso".
Incluimos también las características de usabilidad, presentación u otras que sean relevantes desde el punto de vista del usuario final.
Requisitos técnicos u operativos: Características que debe tener el sistema relativas a su operación en producción. Pueden ser de
disponibilidad, flexibilidad, tiempos de respuesta, soporte, etc..
ULA: Usuario líder de aplicación que es asignado según el portafolio de aplicaciones de Consorcio, es el interlocutor válido ante gestión de la
demanda para realizar solicitudes sobre las aplicaciones.
Usuario: persona autorizada por cada Proceso para la creación, seguimiento y cierre de requerimientos.
Plataforma: conjunto de elementos de hardware y software que se establecen los tipos de arquitectura, sistema operativo, lenguaje de
programación o interfaz de usuario sobre los cuales funcionan las aplicaciones del Portafolio. Se distinguen dos tipos de plataformas: plataforma
EAE y la plataforma NO EAE corresponde con las aplicaciones desarrolladas bajo .NET.
15. Controles de Cambios en las aplicaciones

Consideraciones que se deben tener en el diligenciamiento y la gestión de los controles de cambios.
15.1. RollBack de las aplicaciones
El procedimiento de Rollback se aplicará cuando el Sistema de Información al que se aplicó el control de cambio, quede no disponible. En tal
caso el componente de software se debe reversar, indicando en el Control de Cambios, en la sección de Consideraciones de ROLLBACK de
forma detallada los pasos a realizar por el operador.
15.1.1. Instaladores de aplicaciones, servicios, Etls y Reportes (*.rdl)
En el caso de los ejecutables *.msi, se debe:

• Asegurar la última versión estable descargándola de Tfs u obteniéndola de la ruta de los pasos.
• Ubicarla en la carpeta ROLLBACK del paso.
• Indicar la ruta en la sección Consideraciones de ROLLBACK, ejemplo:

Página 131 de 132
VERSIÓN 4
• Si las Etl’s están programadas mediante job’s, se debe indicar si esos job’s se deben actualizar.
15.1.2. Objetos de base de datos
Si se trata de objetos que existen, se debe solicitar un backup del objeto previo al despliegue del script:
Otra opción es preparar script de Rollback que haga todas las reversiones necesarias y modifique tablas, campos, SPs,
Funciones, Vistas, Registros que permitan dejar la base de datos al estado antes del cambio. Este se puede adjuntar como
objeto del control de cambios:
7. ACTIVIDADES Y TAREAS
Cuando aplique enumere la lista de actividades en orden de ejecución que hacen parte del desarrollo del documento con los siguientes campos:
Número (consecutivo), responsable (registre el cargo del colaborador que realiza la actividad), actividad (defina el que hacer) y tarea (liste las
tareas que hacen parte de la actividad).
No. RESPONSABLE ACTIVIDAD TAREA
8. DOCUMENTOS DE REFERENCIA INTERNOS Y EXTERNOS

Página 132 de 132
VERSIÓN 4
Son aquellos documentos que soportan la operación y que son generados tanto en los procesos, como por organismos externos a la entidad
(no se anexan al documento).
VERSIÓN
CODIGO NOMBRE DEL DOCUMENTO EXTERNO GENERADO POR
fecha INTERNO
(cuando aplique)
FOR-GTI-001 CONTROL DE CAMBIOS PLATAFORMA .NET X
INS-GTI-006 DOCUMENTACION TECNICA SOLUCION DE SOFTWARE X
INS-GTI-007 DOCUMENTACIÓN PARA USUARIO SOLUCIÓN DE SOFTWARE X
9. ANEXOS
Esta sección identifica los documentos que se requieren para soportar la operación, se identifican con letras mayúsculas (Anexo A, B), y el
nombre del anexo. Los documentos van adjuntos al final del documento
ANEXO DESCRIPCION PAGINA
i MVC, https://msdn.microsoft.com/es-co/library/bb972251.aspx#M20
ii http://www.unisys.com/offerings/high-end-servers/clearpath-systems/cross-platform-software/agile-business-suite
iii https://msdn.microsoft.com/es-co/library/bb972268.aspx
iv http://www.w3.org/standards/webdesign/
v http://www.w3.org/TR/html401/interact/forms.html
vi http://www.w3.org/TR/html401/interact/forms.html

Documento de Estándares y Ciclo de Vida de Los Sistemas de Información

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Documento de Estándares y Ciclo de Vida de Los Sistemas de Información

Cargado por

Copyright:

Formatos disponibles

Página 1 de 132

Documento de estándares y ciclo de vida de los sistemas de información

HISTORIAL DEL DOCUMENTO

ELABORACIÓN O MODIFICACIÓN REVISIÓN APROBACIÓN MODIFICACIÓN

0 Fabián Eduardo 03/02/2011 Lyda Zoraida Lyda Zoraida 31/05/201 Lanzamiento

2 José A. Mejia 05/09/2015 Lyda Zoraida Lyda Zoraida Actualización

3 José A. Mejia 02/08/2016 Lyda Zoraida Lyda Zoraida Actualización

No. CARGO PROCESO AL QUE PERTENECE

CONSULTE EL LISTADO MAESTRO

1 Usuarios líderes de Aplicación Procesos Consorcio

CONSULTE EL LISTADO MAESTRO

CONSULTE EL LISTADO MAESTRO

3.3.3. Ventanas. ...................................................................................................................................... 33

CONSULTE EL LISTADO MAESTRO

5. ESTANDARES DE INFRAESTRUCTURA, ADMINISTRACIÓN Y OPERACIÓN DE LOS SISTEMAS DE INFORMACIÓN 81

CONSULTE EL LISTADO MAESTRO

9.8.2. Inventario de Aplicaciones y Responsables ............................................................................... 106

CONSULTE EL LISTADO MAESTRO

13.5. Seguridad .................................................................................................................................... 117

CONSULTE EL LISTADO MAESTRO

1. ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN

1.1. DEFINICIÓN CONCEPTUAL

Tomado de Ingeniería de software, Addison Wesley Ian Sommerville 2015.

2 Ingeniería de software, Addison Wesley Ian Sommerville 2015.

1.2.1. Tipos de Diagrama UML:

1.2.1.1. Modelos De Contexto

Tomado de Ingeniería de software, Addison Wesley Ian Sommerville 2015.

1.2.1.2. Modelos De Interacción

• Diagramas de Casos de Uso, expresan la relación entre un sistema y su entorno.

Tomado de Ingeniería de software, Addison Wesley Ian Sommerville 2015.

Tomado de Ingeniería de software, Addison Wesley Ian Sommerville 2015.

CONSULTE EL LISTADO MAESTRO

1.2.1.3. Modelos Estructurales

Tomado de Ingeniería de software, Addison Wesley Ian Sommerville 2015.

MODELOS ORIENTADOS A EVENTOS

CONSULTE EL LISTADO MAESTRO

2. ARQUITECTURA DE LOS SISTEMAS DE INFORMACIÓN

2.1. ARQUITECTURA DE SOFTWARE

2.1.1. Aplicaciones de Escritorio:

2.1.2. Aplicaciones ABS

6 Ingeniería de software, Addison Wesley Ian Sommerville 2015.

2.1.3. Componentes o Ensamblados

2.1.4. Componentes de Extracción Transformación y Carga.

2.1.5. Aplicaciones WEB

CONSULTE EL LISTADO MAESTRO

2.1.6. Componentes de Bus de Servicio.

CONSULTE EL LISTADO MAESTRO

2.2. ARQUITECTURA DE SEGURIDAD

a) Aplicaciones y servicios que consumen bases de datos.

2.2.1. Acceso a Bases de Datos

2.2.2. Aplicaciones de escritorio:

7 aplicación, servicio web, componente

2.2.3. Aplicaciones y servicios WEB:

CONSULTE EL LISTADO MAESTRO

3. Atributos dominio y la ruta (Domain and Path)

4. Atributos Caduca y Max-Edad (Expire, Max-Age)

CONSULTE EL LISTADO MAESTRO

Lineamientos generales para CONSORCIO.

2.2.4. Aplicaciones ABS:

CONSULTE EL LISTADO MAESTRO

2.3. ARQUITECTURA DE BASE DE DATOS

CONSULTE EL LISTADO MAESTRO

3. ESTÁNDARES DE DESARROLLO DE SISTEMAS DE INFORMACIÓN