Código: TC.GT.

T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE Vigente desde:
PROYECTOS DE SOFTWARE 09/12/2016

1. OBJETIVO

Establecer los lineamientos técnicos mediante el cual se contempla el ciclo de vida de las aplicaciones,
sistemas de información o procedimientos automatizados y el ciclo de vida de la información, basados en
el Marco de Referencia de Gobierno en Línea, para garantizar la optimización del servicio en el Ministerio
del Interior

2. ALCANCE

Inicia con las fases del ciclo de vida de los proyectos o los productos de software independientemente de
la tecnología en la que sean desarrollados y finaliza con los mecanismos que se requieren para lograr el
cumplimiento de los lineamientos de la Estrategia de Gobierno en Línea a través de la Arquitectura
Empresarial y con ello ser parte de “El camino hacia un gobierno integrado”.

3. TERMINOS Y DEFINICIONES

ANS: (Service Level Agreement o SLA), acuerdo de nivel de servicio, es un contrato escrito entre un
proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad de dicho servicio.

Arquitectura e Software: La arquitectura de software es un conjunto de patrones que proporcionan un

marco de referencia necesario para guiar la construcción de un software, permitiendo a los
programadores, analistas y todo el conjunto de desarrolladores del software compartir una misma línea
de trabajo y cubrir todos los objetivos.

Auraportal: Es un sistema para la descripción, ejecución, análisis y mejora de los procesos de una
organización.

Automatizar: Mejorar y simplificar los procesos, integrar procesos internos, ahorrar tiempo y dinero a
través de los sistemas de información.

BPM: (Business Process Management) es un conjunto de métodos, herramientas y tecnologías utilizados

para diseñar, representar, analizar y controlar procesos de negocio operacionales. BPM es un enfoque
centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con
metodologías de proceso y gobierno.

BPMS: (Business Process Management Suite) Es la suite de tecnologías BPM, lo que incluye todos los
módulos funcionales, las capacidades técnicas y la infraestructura de apoyo, integradas en un único
entorno que realiza todas las funciones de la tecnología BPM de manera perfecta, sin fisuras.

Caso De Uso: Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema
en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso
sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con
los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y
los casos de uso en un sistema.

Desarrollo: Por extensión, se utiliza la palabra «desarrollo» para indicar el trabajo de elaboración de un
programa o aplicación.

Diagrama De Flujo: Representación gráfica, mediante la utilización de signos convencionales, del

proceso que sigue la información en un programa determinado.
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Diseño: Proceso de esquematización de un proyecto de software. Es la primera fase en el desarrollo de

aplicaciones.

Diseño Gráfico: Proceso de programar, proyectar, coordinar, seleccionar y organizar una serie de
elementos para producir objetos visuales destinados a comunicar mensajes específicos a grupos
determinados.

Gestión De La Integración: Incluye los procesos y actividades necesarios para identificar, definir,
combinar, unificar y coordinar los diversos procesos y actividades de dirección del proyecto.

NET: Conjunto de herramientas que se usa para diseñar plataformas de acuerdo a la necesidad del
cliente, con el nombre de dominio .net es un dominio utilizado en el Sistema de Nombres de Dominio de
Internet.

Proceso: Operación o conjunto combinado de operaciones con datos, o bien una secuencia de
acontecimientos definida única y delimitada, que obedece a una intención operacional en condiciones
predeterminadas.

Prueba Funcional: Etapa final de la automatización en la cual se comprueba el funcionamiento del

proceso de acuerdo a las configuraciones realizadas.

Prueba Técnica: Son las actividades que permiten verificar y revelar la calidad de un proceso
automatizado. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad del
proceso.

Puesta En Marcha / Producción Del Proceso Automatizado: Cambio de modo en el sistema en el cual
los usuarios pueden iniciar la ejecución del proceso automatizado.

Repositorio: Un repositorio, depósito o archivo es un sitio web centralizado donde se almacena y

mantiene información digital, habitualmente bases de datos o archivos informáticos. Pueden contener los
archivos en su servidor o referenciar desde su web al alojamiento originario.

Requerimientos Funcionales: Los requerimientos funcionales son declaraciones de los servicios que
proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los
requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe
hacer.

Requerimientos No Funcionales: Un requisito no funcional o atributo de calidad es un requisito que

especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus
comportamientos específicos, ya que éstos corresponden a los requisitos funcionales.

TIC: (Tecnología de la Información y las comunicaciones) Las Tecnologías de la Información y la

Comunicación, también conocidas como TIC, son el conjunto de tecnologías desarrolladas para gestionar
información y enviarla de un lugar a otro. Abarcan un abanico de soluciones muy amplio. Incluyen las
tecnologías para almacenar información y recuperarla después, enviar y recibir información de un sitio a
otro, o procesar información para poder calcular resultados y elaborar informes

Viabilidad: Probabilidad que existe de llevar aquello que se pretende o planea a cabo, de concretarlo
efectivamente.

Página 2 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

4. RESPONSABILIDAD

El responsable del procedimiento, de la realización, actualización y socialización del mismo, corresponde

al Jefe de la Oficina de Información Pública y al Coordinador del Grupo de Sistema.

Roles que Intervienen:

Líder de Gestión: Dirigir y gestionar el trabajo del proyecto (de acuerdo a WBS y sus criterios de calidad
y aceptación), elabora el cronograma de actividades, los informes de seguimiento, revisa los casos de
uso, los documentos de pruebas, manuales, actas de aceptación de entregable recibida a satisfacción,
lecciones aprendidas comunicadas y documento informe final aprobado.

Líder Técnico: Genera concepto de viabilidad, concepto de control de cambios, revisa y acompaña los
documentos de requerimientos, diseño, arquitectura, desarrollo y pruebas. Elabora la Ficha Técnica del
Sistema, acompaña la puesta en producción y atiende el segundo Nivel de Soporte.

Analista De Procesos: Se encarga de elaborar el formato de viabilidad, el formato de entendimiento del

proceso, los casos de uso, entrega final y actualización del proceso SIGI automatizado.

Diseñador: Es el encargado de elaborar la guía de estilos que requiere la solución tecnológica, configura
botones, formatos y logos de acuerdo a las necesidades de cada proyecto.

Arquitecto Ti: Define la estructura y el comportamiento de los componentes de los Sistemas de

Información, así como sus interacciones. Define y documenta la arquitectura de la solución, a partir de las
especificaciones establecidas, elabora Documentos de Arquitectura y diseño de Software.

Desarrollador: Construye los componentes de software siguiendo las directrices establecidas en la

arquitectura de la solución y cumpliendo con el diseño definido, asegura que se ejecuten las pruebas
unitarias y de integración de los componentes desarrollados y elabora el formato de prueba técnica.

Analista De Calidad (QA): Es el que elabora los documentos de pruebas, manuales, actas de aceptación
de entregable recibida a satisfacción, lecciones aprendidas comunicadas, documento informe final
aprobado

5. DESARROLLO

Para la ejecución del proyecto se plantean unas fases claramente definidas en donde cada una deberá
tener como entregable intermedio el resumen de la ejecución de la fase, debe entenderse que la
aprobación de dichos entregables son requisito para el inicio de la siguiente, esto no quiere decir que la
totalidad del alcance del proyecto se deba ejecutar al mismo tiempo por cada fase, dependiendo de la
complejidad del proyecto, es factible que las fases se ejecuten por módulo o paquete de acuerdo al
modelo de desarrollo iterativo e incremental. La definición de este tipo de decisiones deberá estar
enmarcada en los planes de gerencia del proyecto.

Página 3 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Figura 1. Modelo de desarrollo iterativo e incremental.

El modelo de ciclo de vida se plantea para todos los tipos de proyecto o producto de software
independiente de la tecnología en la que finalmente sea construida la solución.

1. Levantamiento y análisis de información

Requerimientos funcionales

Son todas las declaraciones de las características que debe proporcionar el sistema, de la manera en que
éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares.
En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar
explícitamente lo que el sistema no debe hacer.

En términos generales el sistema de información deberá satisfacer las siguientes necesidades:

● Solución informática integrada con sistemas misionales del Ministerio del Interior a través de la
propuesta de integración BPM + SOA del ministerio del Interior.
● Solución informática integrada con otros sistemas de información institucionales.
● Solución informática que permita apoyar la actividad institucional en cualquier lugar del país.
● Solución informática de apoyo a la gestión interna.
● Solución informática con implementación de la totalidad de procesos de la función preventiva de
la Dirección/Subdirección/Oficina/Grupo.
● Solución informática con herramientas de análisis de datos.
● Solución informática con integración a herramientas de análisis georreferenciado.
● Solución informática integrada con la gestión de correspondencia y gestión documental.
● Solución informática administrada a través de un portal de información.
● Solución informática a disposición de los ciudadanos toda la información definida como de
carácter público.
● Dentro de los procesos automatizados, se hace necesario el levantamiento de información con la
coordinación del grupo de sistemas de la OIPI así como de las dependencias de control interno y

Página 4 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

de gestión del cambio a las que haya lugar, en el sentido de determinar los informes y reportes
que respondan a las preguntas de nivel de utilización de los procesos automatizados.

Durante la fase de inicio en gestión de proyecto, el proceso de levantamiento de información debe ser
realizado no solo con la información digital o física entregada por los stakeholders sino que debe estar
acompañado por sesiones de entrevistas a las personas pertinentes en la operación futura del sistema.

Para las sesiones de levantamiento, adicional a las respectivas actas de reunión que se levanten se
plantea el formato “Formato entendimiento de proceso y definición de casos de uso.docx”, para su
correcto diligenciamiento se deben tener en cuenta los siguientes aspectos.

Diagrama de flujo de proceso

De no existir o encontrarse desactualizado, se debe elaborar por parte del analista de información el
diagrama donde se plasme el entendimiento del proceso objeto de automatización o sistematización, en
él deben quedar claros los roles que interactúan, los documentos que se generan y tienen como insumo,
las decisiones que se toman, las interrelaciones con otros procesos y las relaciones con sistemas de
información presentes.

Reglas de negocio

Deben describir las políticas, normas, operaciones, definiciones y restricciones presentes en la entidad o
dependencia y que son de vital importancia para alcanzar los objetivos misionales, en ningún caso se
deben confundir las reglas de proceso (restricciones) y las reglas de negocio ya que las segundas
expresan una generalidad que en ningún caso deben depender del resultado de la automatización o
sistematización, las primeras están ligadas explícitamente al sistema que se está modelando.

Escenarios o flujos

Describen un ejemplo del uso del sistema en términos de una serie de interacciones entre el usuario y el
sistema, en lo posible deben determinarse los escenarios de flujo normal, alternos y de excepción.

Casos de uso

Los casos de uso deben estar determinados mediante la obtención de un logro de negocio por parte del
usuario que está realizando la interacción y debe comprender los posibles escenarios presentes en su
ejecución. Como normal general, deberán estar codificados y expresados en forma infinitiva.
Se deberá tener en cuenta la atomicidad del caso de uso, el cual como recomendación deberá hacer
referencia a una única función del sistema y se deberá centrar exclusivamente en la interacción
relacionada al objeto del negocio.

Para todos los casos no deben presentarse sobre el documento palabras técnicas de desarrollo de
software dado que la población objetivo del documento es el de usuarios funcionales del ministerio del
interior.

Al finalizar se debe presentar el diagrama de integración entre casos de uso de modo que denote las
dependencias de implementación de los mismos, esta información es vital para la elaboración de los
planes de pruebas y operación del sistema entregado.

Página 5 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Pantalla prototipo

Se deberá plasmar en pantalla el orden, agrupamiento y tipos de controles (cajas de texto, botones, etc)
de la información levantada y relacionada al caso de uso. En ella se debe evidenciar claramente la
información que sirve de entrada y de salida, la que es obligatoria de la que es opcional, la que es
modificable y la que no lo es. Se puede acompañar de notas para cuando se requiera especificar
comportamientos no obvios en los diferentes campos de datos.

Actores

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda
una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas
externos, además de entidades abstractas, como el tiempo. Se sugiere que los actores definidos en los
casos de uso estén alineados a los roles de los mismos dentro del proceso que se levanta, de este modo
se adelanta la matriz de roles y accesos de cara a los procesos de pruebas y salida a producción.

Requerimientos no funcionales

Todas las soluciones informáticas que se implementen en el Ministerio del Interior deben cumplir con los
siguientes requerimientos definidos por el grupo de sistemas dependiente de la Oficina de Información
Pública.

Los requerimientos no funcionales se refieren a las características del sistema que aplican de manera
general como un todo, más que a rasgos particulares del mismo. Estos requerimientos son adicionales a
los requerimientos funcionales que debe cumplir el sistema, y corresponden a aspectos tales como la
disponibilidad, mantenibilidad, flexibilidad, seguridad, facilidad de uso, etc., los cuales se describen a
continuación.

La solución debe cumplir como mínimo las siguientes características basadas en las especificaciones
funcionales y los requerimientos no funcionales:

Desempeño

● Garantizar la confiabilidad, la seguridad y el desempeño del sistema informático a los diferentes

usuarios a nivel nacional. En este sentido la información almacenada podrá ser consultada y actualizada
permanente y simultáneamente, sin que se afecte el tiempo de respuesta.

● El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios con tiempo de
respuesta aceptable y uniforme, en la medida de las posibilidades tecnológicas del Ministerio del Interior,
en períodos de alta, media y baja demanda de uso del sistema.

Disponibilidad

● Estar disponible 99% o superior, durante el horario 7x24x365, es especial en horario laboral del
Ministerio del Interior a nivel nacional (de lunes a viernes de 8:00 a.m. a 5:00 p.m., con excepción de los
días festivos)

● Operar de la misma manera para todos los niveles de la estructura jerárquica del Ministerio del Interior.

● Para todas las aplicaciones del Ministerio del Interior, se debe tener en cuenta que tanto las
aplicaciones como la data van sobre una infraestructura en nube, por lo que todo sistema de información
debe cumplir con los estándares necesarios para trabajar sobre nube pública (Microsoft Azure) como

Página 6 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

plataforma como servicio (Pass). Y solo en casos especiales, bajo estudio del Grupo de Sistemas, se
permitirá el uso de Infraestructura como servicio (Laas). (No aplica para desarrollos sobre la plataforma
BPM que utilicen la plataforma ya existente).

Escalabilidad

● El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental, de manera tal
que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados afectando el código
existente de la menor manera posible; para ello deben incorporarse aspectos de reutilización de
componentes.

● El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionalidades,

modificar o eliminar funcionalidades después de su construcción y puesta en marcha inicial.

● La estrategia de crecimiento de plataforma de hardware de las aplicaciones debe ser, en lo posible,

horizontal apalancadas en soluciones de Grid Computing.

● El sistema debe ser compatible con el servicio de auto escalamiento de Microsoft Azure
(horizontalmente (Scale Out): Agregar más instancias de un mismo rol).

Facilidad de Uso e Ingreso de Información

● El sistema debe mantener un estándar de trabajo definido, de modo que sea de fácil uso y
entrenamiento por parte de los usuarios del Ministerio del Interior, así como de fácil adaptación de la
entidad con el mismo.

● El sistema no debe permitir el cierre de una operación hasta que todos sus procesos, subprocesos y
tareas relacionados, hayan sido terminados y cerrados satisfactoriamente.

● El ingreso de información al sistema debe diseñarse con transacciones que permitan el ingreso de los
datos de forma parcial; es decir, que el tamaño de las páginas de registro (o formularios) de información
sean adecuadas de acuerdo con la estabilidad de la red o canales de comunicación utilizados.

● El sistema debe presentar mensajes de error que permitan al usuario identificar el tipo de error y
comunicarse con el administrador del sistema.

● El sistema construido en plataformas web debe cumplir con tecnología de Diseño Web Adaptable o en
inglés Responsive Design para que pueda ser usado desde diferentes tamaños en pantalla y
dispositivos

● Los sistemas de información deben utilizar interfaz web, de forma que se universalice el acceso a los
mismos, en su defecto la aplicación debe ser compatible con los estándares de Porlets vigentes. Los
navegadores compatibles deben por lo menos IE 9 o superior, Firefox , Google Crome

Facilidad para las Pruebas

● El sistema debe contar con facilidades para la identificación de la localización de los errores durante la
etapa de pruebas y de operación posterior, para ello los logs de trazabilidad deben indicar la fecha, el
componente de software, la excepción interceptada, el método en ejecución y la línea de código que
produjo el error. En la medida de lo posible se debe indicar el usuario que se encontraba ejecutando la
acción.

Página 7 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Flexibilidad

● El sistema debe ser diseñado y construido con los mayores niveles de flexibilidad en cuanto a la
parametrización de la información, de tal manera que la administración del sistema pueda ser realizada
por un administrador funcional del sistema, en ningún caso el dentro del código fuente deben quedar
valores fijos que dado el negocio requieran ser cambiados posteriormente. Igualmente, si el sistema
incluye la generación de documentos, estos deben partir de plantillas que puedan llegar a ser modificadas
sin tener que realizar una nueva compilación del sistema.

Instalación

● El sistema debe contar con la documentación suficiente para la realización de los procesos de
instalación en todas las plataformas de hardware y software de base definida por el grupo de sistemas
dependiente de la Oficina de Información Pública

● Desde el punto de vista de servidor de aplicaciones el estándar definido para los sistemas es Windows
Server 2012 R2 o superior y IIS 7.5 o superior como servidor de aplicaciones y el motor de base de
datos, reportes BI debe ser MSSQL 2012 o superior

● Se debe aplicar el criterio del menor privilegio, el cual consiste en la instalación solamente de los
recursos que requieren para la ejecución de los programas.

Mantenibilidad

● Todo el sistema deberá estar complemente documentado, cada uno de los componentes de software
que forman parte de la solución propuesta deberán estar debidamente documentados tanto en el código
fuente como en los manuales de administración y de usuario

● Todo proceso de modificación de la plataforma por motivos de liberación de nuevas funcionalidades

debe contar con sus respectivas actividades de instalación, configuración y reversión total de las acciones
para los casos de imposibilidad de instalación de alguno de los componentes.

● El sistema debe contar con una interfaz de administración que incluya: Administración de usuarios,
Administración de módulos y Administración de parámetros. En cada una de éstas secciones deberá
ofrecer todas las opciones de administración disponibles para cada uno

● El sistema debe estar en capacidad de permitir en el futuro su fácil mantenimiento con respecto a los
posibles errores que se puedan presentar durante la operación del sistema.

● El sistema deberá funcionar de manera adecuada frente a una falla de seguridad.

● El sistema debe estar construido de forma que permita la consulta de eventos de modificación de la
información paramétrica, tanto si se realiza desde la aplicación como directamente sobre las fuentes de
datos.

● Se debe tener en cuenta los costos asociados a plataforma como servicio (Nube) y deben estar
disponibles para garantizar la operación continua del sistema de información. Por lo que es parte integral
los costos mensuales y anuales y se deberán aprovisionar según se requiera con la suficiente antelación
para mantener el sistema funcional.

Página 8 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

● El sistema debe contemplar un plan de soporte durante el tiempo estimado de vida del Sistema de
Información

Operatividad

● El sistema debe ser de fácil operación por el grupo de sistemas dependiente de la Oficina de
Información Pública del Ministerio del Interior, y que demande un bajo nivel de soporte de los usuarios del
sistema.

● El sistema deberá poder ser administrado remotamente por las personas encargadas o designadas por
el grupo de sistemas dependiente de la Oficina de Información Pública del Ministerio del Interior.

Seguridad

● La seguridad del sistema debe estar regida por las Políticas de Seguridad de la Información definidas
por el Ministerio del Interior y alineadas con la Estrategia de Gobierno en Línea.

● El acceso al Sistema debe estar restringido a los usuarios de directorio activo que se habiliten para
acceder al sistema. Sólo podrán ingresar al Sistema las personas que estén habilitadas, estos usuarios
serán clasificados en varios tipos de usuarios (o roles) con acceso a las opciones de trabajo definidas
para cada rol.

● Para los usuarios externos o invitados el sistema deberá integrarse con la autenticación única del
ministerio del interior.

● El control de acceso implementado debe permitir asignar los perfiles para cada uno de los roles
identificados, los cuales serán definidos por los dueños del proceso.

● Respecto a la confidencialidad, el sistema debe estar en capacidad de rechazar accesos o

modificaciones indebidos (no autorizados) a la información y proveer los servicios requeridos por los
usuarios del sistema.

● El sistema deberá contar con mecanismos que permitan el registro de actividades (Logs de auditoria)
con identificación de los usuarios que los realizaron, incluyendo los procesos y actividades realizadas en
las bases de datos por parte del usuario.

● El sistema debe contar con pistas de auditoría de las actividades que se realizan sobre el sistema con
niveles razonables para su reconstrucción e identificación de los hechos.

● El grupo de sistemas realizará pruebas previas a la entrada de producción y entregará un informe con
los riesgos encontrados para su correspondiente mitigación por parte del desarrollador. Una vez sean
cerradas las brechas en seguridad, se realizará una segunda prueba, si el sistema no presenta riesgos o
si estos no son de importancia alta el oficial de seguridad dará el visto bueno para la el despliegue en
producción del sistema. El Ministerio se reservará la recepción en producción del sistema de información
hasta no mitigar todos los riesgos 1

Validación de Información

1
Tenga en cuenta TOP 10 de los riesgos de seguridad de Aplicaciones

Página 9 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

El sistema debe validar automáticamente la información contenida en los formularios de ingreso. En el

proceso de validación de la información, se deben tener en cuenta aspectos tales como obligatoriedad de
campos, longitud de caracteres permitida por campo, manejo de tipos de datos, velocidad de respuesta,
tráfico de datos, etc.

Otros Requerimientos No Funcionales

Arquitectura

● La Arquitectura siempre será avalada por parte del grupo de sistemas de la oficina de información
pública del ministerio del interior.

● La solución debe ser 100% “Basada en Web y Nube (Microsoft Azure)”” y toda la parametrización y
administración debe realizarse desde al menos los navegadores definidos.

● La solución debe operar de manera independiente del navegador que se utilice.

● La solución debe tener interfaces gráficas de administración y de operación en idioma español y en

ambiente 100% Web, para permitir su utilización a través de exploradores o navegadores de Internet.

● La información de los formularios que corresponda a listas de selección deberá ser parametrizada y
administrable.

Integración

● La solución deberá integrarse a la página Web que defina el Ministerio del Interior. mediante
estándares propuestos por Gobierno en Línea.

● Si la solución requiere la generación de un código de radicación, se debe disponer el servicio

GDC_Consecutivo Radicación, de acuerdo a lo indicado al Grupo de Sistemas de la Oficina de
Información Pública.

Interoperabilidad

● El sistema debe estar en capacidad de interactuar con los otros sistemas del Ministerio del Interior y
con sistemas de entidades externas a través de la estrategia de SOA seleccionada por el Ministerio del
Interior como la solución de integración de aplicaciones empresariales. La Interoperabilidad debe estar
alineada por las definiciones del apartado de interoperabilidad de GEL

● De ser necesario interactuar con entidades externas al Ministerio del Interior, por requerimientos del
sistema, estas interacciones debe realizarse con la solución de integración de aplicaciones empresariales
y debe estar alineado lo definido en el “Marco para Interoperabilidad de Gobierno en Línea” lo cual
supone que para cualquier implementación de este tipo, se deben consultar y/o solicitar actualización del
“Diccionario del estándar de lenguaje común” según el caso.

Otros Requerimientos

● Facilidades y controles para permitir el acceso a la información al personal autorizado de otras

Página 10 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

entidades del estado a través de Internet, con el propósito de consultar la información pertinente para
cada una de ellas.

● Facilidades para poder adelantar discusiones electrónicas a través de foros o salas de conversación
sobre casos en particular que se adelanten en el Ministerio del Interior y registrar la participación de los
asistentes.

● Contar con herramientas de software para la administración automática de archivos

● Contar con herramientas y características necesarias para su administración, la realización de

búsquedas y la posibilidad de realizar consultas de índole general.

● El diseño gráfico de los sistemas debe responder al diseño oficial del Ministerio del Interior

● El sistema debe propender por el desarrollo de la cultura que minimice el uso del papel. Para ello,
hasta donde sea posible, deberá hacer uso de las diferentes características de la tecnología, tales como
documentos electrónicos, imágenes digitales, buscando minimizar la sobrecarga de las redes de
transporte de datos y en concordancia con la estrategia de gobierno del Línea con la Política de Cero
Papel.

● Garantizar que el diseño de las consultas no afecte el desempeño de la base de datos, ni

considerablemente el tráfico de la red.

Las consideraciones anteriormente descritas aplican tanto para las aplicaciones transaccionales
desarrolladas a la medida como para las que están enmarcadas como automatización de procesos BPM
en la herramienta designada por el ministerio.

Arquitectura, Diseño y Desarrollo

Para las soluciones de software que no se planteen como automatización BPM, se deberá elaborar la
propuesta arquitectónica con la que se estructuraran y determinaran el comportamiento de los
componentes que harán parte de la plataforma teniendo en cuenta la compatibilidad con plataforma como
servicio en nube de Microsoft azure. Para las soluciones que se enmarquen en la plataforma BPM del
Ministerio del Interior no se requiere propuesta arquitectónica toda vez que aplica la presente en la propia
herramienta. Debe tenerse en cuenta los documentos en la versión vigente del Marco de Referencia de
Arquitectura Empresarial2

Base de datos

El sistema de información debe estar basado en el motor de base de datos MSSQL cumpliendo con el
modelo relacional. El Ministerio cuenta con Microsoft SQL Enterprise Edition 2012 R2 en arquitectura de
alta disponibilidad.

El sistema de información debe proveer el licenciamiento necesario para el motor de base de datos en
caso que las capacidades actuales del Ministerio no provean los requerimientos solicitados por el Sistema
de Información, siempre basado en el modelo de licenciamiento por núcleo, integrándose con el motor
actual del Ministerio y con cumplimiento de las políticas de respaldo y con capacidad de coexistir con las
bases de datos e instancias presentes en el Ministerio del Interior sin modificar el motor de base de datos.

Para los servicios de reportes e inteligencia de negocios se debe utilizar MSSQL 2012 R2 y cumplir con

2
http://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8114.html

Página 11 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

las mismas especificaciones que el motor de datos.

El método de autenticación a la base de datos debe ser integrada de Windows, preferiblemente mediante
un usuario de dominio con políticas de seguridad de no vencimiento de clave para evitar bajas en el
servicio, se debe propender que las actividades de interacción entre los componentes y la base de datos
solamente sean de escritura y lectura.

Para los servicios de bases de datos como plataforma (Paas) se utilizará la última versión del motor de
base de datos MSSQL disponible por parte de proveedor (Microsoft Azure)

Georreferenciación

El Ministerio del Interior cuenta con licenciamiento para los productos ARCGIS, los cuales constituyen
una familia de productos de software para construir un Sistema de Información Geográfica (SIG)
completo.

El sistema ARCGIS es un sistema de información geográfica integrado que provee la arquitectura para
implementar SIG para uno o muchos usuarios, emplea modelos de datos inteligentes para la
representación geográfica, incluye las herramientas necesarias para crear y trabajar con datos
geográficos e incluye herramientas para todas las tareas de un SIG, tales como la edición y
automatización de datos, mapeo, manejo de datos, análisis geográfico, despliegue de datos y
aplicaciones sobre Internet.

Por tanto los sistemas que requieran un componente geográfico en su implementación deberán acogerse
a la arquitectura de Sistema de Información Geográfica establecida en el Ministerio y la forma de
integración entre la solución transaccional y el componente de georreferenciación deberá ser evaluado en
conjunto entre el grupo de sistemas de la OIPI y el diseñador de software.

Integración

A continuación se describen las características a tener en cuenta para realizar integraciones entre
sistemas de información de la entidad o hacia otras entidades. En donde la integración a nivel de
procesos de negocio se debe realizar mediante la herramienta BPMs y aquellas integraciones de
exposición de datos como servicio, se realizaran a través de la tubería de servicios de la entidad.

El listado de integraciones contiene tanto las de consulta interna/externa como las de exposición de
información interna/externa y se encuentra documentado bajo el nombre de “Inventario
Integraciones.xlsx” y deberá quedar actualizado posterior a la ejecución del proyecto.

● Tubería de servicios
La tubería de servicios es un componente de software desarrollado bajo tecnología .Net, que
permite la exposición y consumo de servicios de datos con tecnologías XML, WSDL, SOAP,
Rest y ODATA, A continuación se describen las consideraciones técnicas más relevantes:
o Microsoft .Net 4.5
o WCF (Windows Comunication Foundation)
o Entity Framiework 5.0
o ODATA Versión 3

● Arquitectura de Alto Nivel.

A continuación se describe el marco arquitectónico de alto nivel asociado a la solución de la
tubería de servicios.

Página 12 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Figura 2. Marco Arquitectónico de Alto Nivel, tubería de servicios.

o Capa de Servicios Distribuidos Externos: En esta capa se alojaran los servicios

Web tanto en formatos asmx como svc, que se expondrán hacia fuera de la entidad,
dichos servicios están asegurados contra los servicios de directorio activo.
o Las entidades externas que desean acceder a estos servicios se les deberán crear un
usuario en el directorio activo, y asociar al grupo correspondiente al servicio.
o Capa de Servicios Distribuidos Internos: En esta capa se alojaran los servicios Web tanto
en formatos asmx como svc, que se expondrán hacia dentro de la entidad, estos no se
encuentran asegurados a menos que la información que viaje sea de carácter
confidencial, y si es el caso manejara el mismo esquema que la capa asociada a los
externos.
o Capa de Aplicación: En esta capa se alojaran tanto los contratos como las
implementaciones asociadas a los servicios expuestos en las capas superiores (Servicios
Distribuidos Externos e Internos), además servirá como la capa de orquestación entre
otros servicios de esta capa, la capa de datos y el modulo común.
o Capa de Datos: En esta capa contendrá los repositorios y fachadas de datos que tienen
como fin de ser el enlace con las bases de datos relacionales, no relacionales y/o
servicios externos.
o Modulo Común: En esta capa se encuentran todos los componentes de software
transversales al software, como son: adaptadores, Entidades, archivos de recursos,
objetos valor y utilitarios asociados.
o Código Fuente.
El código fuente se encuentra en el archivo digital de los sistemas de información de la oficina
de información pública, en la carpeta “27. TUBERIA DE SERVICIOS”.

CMS

Página 13 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Si se requiere un micro sitio, el proveedor de la solución debe implementar sobre el gestor de contenidos
que le indique el Grupo de Sistemas, desde este CMS podemos administrar todos los contenidos,
subdominios, artículos y noticias a los que tiene acceso el usuario final, debe estar montado sobre la
plataforma del Ministerio del Interior, en servidor web es IIS (Internet Information Services) y anclado a la
base de datos SQLl Server del Ministerio o en su defecto el ministerio del interior evaluará la posibilidad
del uso de MySQL. El diseño y desarrollo deben cumplir todos los lineamientos Gobierno en Línea GEL
3.1 o superior.

BPM

A continuación se describen una serie de lineamientos para el diseño e implementación de procesos

sobre la plataforma Auraportal del Ministerio del Interior, que estarán agrupados en los siguientes ítems y
documentados en el formato “Formato Diseño BPM.docx”:

Definición de claves.

La clave deberá ser definida en relación a los grupos de proceso enfocados a cumplir una necesidad de
negocio en particular y será de ayuda para la identificación y trazabilidad de los componentes de los
mismos. Es altamente recomendable que la longitud de la designación de la clave sea de tres caracteres.
Las claves serán utilizadas como prefijo para los componentes propios de los procesos, por ello, la clave
a utilizar debe ser lo más particular posible.

Definición de términos.

Los términos son una serie de campos creados por el diseñador del proceso, con el fin de ser mostrados
y utilizados en los formularios durante la ejecución de una clase de proceso, en la ficha de familia o en la
ficha de un rol en particular. Para la plataforma BPM del ministerio del interior, dichos términos deben ser
estructurados de la siguiente forma en el árbol por capítulos:

 Tipo de Proceso: En este nodo del árbol se ubican los tipos de procesos que puede tener la entidad
(Apoyo, Estratégicos, Misionales), Adicionalmente existe una quinta categoría como es transversal, en la
cual se agrupan todos aquellos términos que son genéricos y pueden ser utilizados en las otras
categorías de forma canónica o como plantilla guía para formularios.

 Proceso: En esta rama se describe el proceso o sub proceso macro que apalanca el procedimiento a
automatizar.

 Procedimiento: En esta rama se describe el procedimiento el cual se debe implementar

En general, el lineamiento al respecto es que el árbol de términos se encuentre fuertemente relacionado a

la definición de la estructura SIGI y que los nombres de los elementos tengan como prefijo la clave de las
clases de proceso donde van a ser utilizados.

A continuación, se muestra el ejemplo del procedimiento de “Recepción y Tramite de Cuentas” de cómo

se debe estructurar el árbol de términos para la implementación de un proceso.

Página 14 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Figura 3. Ejemplo de Estructura de Terminos de un Proceso.

Definición de familias propias

A continuación se describen una serie de características que se deben tener en cuenta para la definición
de familias propias:

 Las familias propias se deben definir de la forma <Clave>.<Nombre_Familia>, todo esto con el fin de
generar una estandarización en la nomenclatura, y la fácil identificación de familias por dominio de
negocio. Ejemplo: RTC. Contratistas.

 Toda familia propia deberá tener un campo de uso exclusivo, esto con el fin de tener una mayor
flexibilidad en las búsquedas y cierta integridad en la información.

 En la configuración del Grid de las familias propia, los encabezados deberán tener nombres concretos,
esto con el fin de su fácil identificación en su consulta.

 En lo posible validar que las relaciones entre familias se realice mediante mapas de relación entre
familias, el uso de grupos dentro de familias debe validarse para cada caso.

 Velar por el mantenimiento unificado de las familias que representan objetos de negocio y que
representan entidades que presentan un alto nivel de importancia dentro más de un procedimiento, esto
con el fin de no tener pérdidas de integridad de la información.

Definición de clases de proceso

Las clases de proceso son los patrones establecidos de un proceso, en donde se definen las
características de identidad del proceso, el funcionamiento y los tiempos de afectación de este. A
continuación se definen una serie de lineamientos básicos para el diseño e implementación de estas:

La clase de proceso deberá estar ubicada dentro de la estructura de Árbol según el siguiente esquema:
Tipo de Proceso, Proceso Macro, clase de proceso. En la siguiente figura se muestra un ejemplo de la
estructura para la definición de una clase de proceso:

Página 15 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Figura 4. Ejemplo de Definción de una clase de proceso.

En general deben seguir la estructura SIGI de modo que los términos y las clases de proceso donde son
utilizados se encuentren en ramas con iguales características de numeración y nombre.

Cada clase de proceso se le deberá asociar un responsable del proceso, en la mayoría de los casos
deberá ser el líder técnico asociado. En el diagrama del proceso, los objetos de una clase de proceso
como son tareas personales deberán siempre tener en su nomenclatura la descripción básica de la tarea
acompañada de la persona y/o el grupo responsable de su ejecución. Ejemplo: Verificación Área
Contable - Grupo Contable.

En el diagrama del proceso, los objetos de una clase de proceso como son tareas de sistema deberán
siempre tener en su nomenclatura la descripción básica de la tarea, iniciando por el tipo de tarea de
sistema. Ejemplo: NOTIFICADOR - Enviar notificación de retraso.

6.1.8.5 Acceso Usuarios

Los procesos y o procedimientos modelados en la plataforma que requieran el acceso deben distinguir la
naturaleza del usuario “Usuario Externo - portal Externo Usuario interno – acceso a la plataforma,
Usuario Invitado -WIP.” Teniendo en cuenta las WIP debe estar enlazada y definida desde el micrositio
empleado para dicho proceso y/o procedimiento, los enlaces y las acciones principales de acceso (url
WIP) y registro deben estar allí definidas mediante botones que visualicen claramente el tipo de usuario y
acción a realizar.

Transaccional

Para la definición del diseño y arquitectura de las soluciones propuestas sobre .NET se requiere por parte
del proveedor del servicio, la elaboración del documento según el formato “Formato Diseño y Arquitectura
Transaccional”.

Se entiende que para el diseño de un sistema de información, en primera medida se debe definir el
diseño de la arquitectura asociada al sistema, la cual consiste en la definición de los requisitos técnicos y
operacionales del mismo. En donde este proceso tiene la finalidad de definir qué componentes forman el
sistema, como es su relación entre si y como mediante su interacción llevan a cabo la funcionalidad
especificada, cumpliendo con una serie de requerimientos de calidad (requerimientos no funcionales y/o
calidades sistémicas).

Por otra parte y teniendo en cuenta el marco que define la arquitectura de software y el ciclo de vida de
las aplicaciones, el proceso de diseño de la arquitectura juega un papel muy importante. La diferencia

Página 16 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

entre un buen proceso de diseño arquitectural y uno malo puede suponer la diferencia entre el fracaso o
el éxito de un proyecto.

Por lo anterior para un buen diseño arquitectónico de las aplicaciones basadas en tecnología .Net, se
propondrán una serie de lineamientos que estarán agrupados en los siguientes ítems:

 Tipos de aplicaciones que se pueden construir.

 Arquitectura física de la aplicación.
 Arquitectura lógica de la aplicación.
 Arquitectura marco de referencia.
 Estándares de diseño detallado.
 Tecnologías de la aplicación.

1. Tipos de aplicaciones que se pueden construir

Una vez que están claros los objetivos de la iteración y la funcionalidad que desarrollaremos, podemos
pasar a su diseño. Llegados a este punto, el primer paso es decidir qué tipo de aplicación vamos a
desarrollar.

Aplicaciones web: Son aplicaciones que se consumen mediante un navegador y que ofrecen una
interfaz de usuario estándar y completamente interoperable, estas aplicaciones deben tener la posibilidad
de poder ser visualizado en la mayoría de veces, en dispositivos móviles como celulares y tabletas.

Aplicaciones orientadas a Servicios: Se trata de aplicaciones que exponen una funcionalidad

determinada en forma de servicios web para que otras aplicaciones los consuman. Este tipo de
aplicaciones deberán tender a centralizarse por medio de la tubería de servicios preestablecida en la
entidad cuando amerite.

Para otros tipos de aplicaciones, como son: clientes ricos, aplicaciones de escritorio o de dispositivos
móviles, serán evaluados por parte del grupo de sistemas las bondades y las desventajas de poder
implementar este tipo de aplicaciones.3

2. Arquitectura física de la aplicación

Posteriormente a la definición del tipo de aplicación que se va construir, el paso a seguir es el de diseñar
la arquitectura de la infraestructura o la topología de despliegue que tendrá la aplicación. Esta topología,
para el caso particular del ministerio del interior se debe realizar mediante un despliegue distribuido.

Este lineamiento se debe a que un despliegue distribuido permite separar las capas lógicas en distintos
niveles físicos. De esta forma el sistema puede aumentar su capacidad añadiendo servidores donde se
necesiten y se puede balancear la carga para maximizar la eficiencia. Al mismo tiempo, al separar las
capas en distintos niveles aprovechamos mejor los recursos, balanceando el número de equipos por nivel
en función del consumo de las capas que se encuentran en él.

3
En una arquitectura de servidor cliente el término “cliente rico” es usado para clientes donde el procesamiento de datos ocurre principalmente del
lado del cliente. El cliente también provee la interfaz gráfica de usuario. A menudo los clientes ricos son aplicaciones que son extensibles mediante
conexiones (plug gins) y módulos. De esta forma los clientes ricos son capaces de solucionar más de un problema. Los clientes ricos también pueden
solucionar problemas relacionados potencialmente, al igual que aquellos que sean completamente diferentes a su propósito general. Los clientes ricos
son desarrollados típicamente al principio de un framework. Un framework ofrece un punto de inicio básico al principio por el cual el usuario puede unir
lógicamente las partes relacionadas de la aplicación, las cuales son llamadas módulos.

Página 17 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Por lo anterior, los únicos tipos de despliegue soportados para la entidad son: 3 – Niveles, N – Niveles,
para los casos en que se requiera otro tipo de despliegue en una aplicación, esta deberá ser previamente
evaluada por el grupo de sistemas de la OIPI.

3. Arquitectura lógica de la aplicación

Posterior definición del tipo de aplicación y la estructura física de esta, se debe diseñar la arquitectura
lógica de la aplicación. Por lo cual y para un buen diseño, este debe ser guiada mediante un conjunto de
estilos arquitecturales o patrones de arquitectura, los cuales definirán aspectos macro del sistema que se
diseña y representan una forma estándar de definir o implementar dichos aspectos.

En la siguiente tabla se agrupan los diferentes estilos arquitectónicos soportados por la entidad,
agrupados por los aspectos que definen:

Aspecto Estilos arquitecturales

Comunicaciones SOA (Service Oriented Architecture), Bus de mensajes
Dominio Diseño orientado al dominio
Interacción Page Template, SPA (Single Page Application)
Estructura Componentes, Orientado a objetos, Arquitectura en capas

Para otro tipo de estilos arquitectónicos, que se deseen implementar, estos deberán ser previamente
evaluados por el grupo de sistemas de información pública del interior, para su posterior implementación.

4. Arquitectura marco de referencia

A continuación se describe la arquitectura marco de referencia definida por el ministerio del interior, para
la construcción de aplicaciones basadas en plataforma .Net.

Figura 5. Arquitectura Marco de Alto Nivel.

Página 18 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Capa de Presentación: esta capa tiene como responsabilidad la de mostrar información al usuario e
interpretar las acciones que realicen las capas inferiores. Esta capa tiene la responsabilidad de
implementar la funcionalidad requerida para que los usuarios puedan interactuar con la aplicación,
mediante patrones MVP y MVC.

o Subcapa de Componentes Visuales. Son una serie de componentes que tienen como
finalidad ser un mecanismo base para que el usuario utilice el aplicación. Son
componentes que formatean datos, tipos de letras, controles visuales y adicionalmente
reciben datos proporcionados por el usuario.
o Subcapa de Controladores. Son una serie de componentes que permiten la
sincronización y orquestación de las interacciones del usuario con la lógica de la
aplicación y viceversa. Lo anterior tiene como fin lograr que el flujo de proceso y la lógica
de negocio y de gestión se encuentre programada dentro de los formularios visuales.

Capa de Servicios Distribuidos: esta capa actúa como un proveedor de servicios para otras
aplicaciones o para la capa de presentación cuando esta implementa en enfoque SPA (Single Page
Application), en donde se publica la lógica de negocio mediante una capa de servicios.

o Subcapa de Contratos. En esta capa se definen todos aquellas contratos de las firmas
(funcionalidades) que se van a exponer como servicio, así como las complejidades
técnicas como son el comportamiento y el tipo de enlace.
o Subcapa de Implementaciones. Es esta capa se realizan las implementaciones
concretas de los servicios y de cómo estos acceden a capas inferiores como son las de
datos y/o aplicación.

Capa de Aplicación: esta capa tiene como tarea el poder realizar tareas de coordinación de aspectos
tecnológicos de la aplicación, en esta capa se implementa la coordinación de la fontanería de la
aplicación. Como la coordinación de transacciones, ejecución de unidades de trabajo y en definitiva
llamadas a tareas necesarias para la aplicación. Esta capa es usada por la capa de presentación y/o la
capa de servicios distribuidos, y orquesta operaciones entre la capa de datos el modulo común y/o la
capa transversal de calidad de servicio.

o Subcapa de Servicios de Aplicación. En esta capa se albergan todas aquellas clase que
permiten la coordinación de tareas de negocio entre diferentes componentes como son
repositorios, componentes transversales (envió de correos, generación de auditoria y
registro. etc…).
o Subcapa de WorkFlow de Negocio. En esta capa se albergan todas aquellas clases que
permiten la interacción con la plataforma BPMs AuraPortal de la entidad.

Capa de Acceso a Datos: esta capa tiene las capacidades de poder persistir datos así como
lógicamente acceder a ellos. En donde los datos pueden ser propios del sistema o datos expuestos por
sistemas externos, esta capa es utilizada por capas superiores como la de aplicación, servicios
distribuidos y/o presentación directamente cuando no se requiere ningún tipo de orquestación de tareas
de negocio y solo se requiere el paso de los datos.

o Subcapa de Repositorios. Los repositorios son todas aquellas clases encargadas de

realizar operaciones de persistencia y acceso a datos, sobre una tecnología concreta. Lo
anterior tiene como principal ventaja la centralización de la funcionalidad de acceso a
datos.
o Subcapa de Modelos de Datos. En esta capa se albergaran los modelos de datos
definidos bajo el enfoque de sistema ORM Entitiy Framework, estos proporciona
técnicas de definición del modelo de datos a nivel de diagramas “entidad-relación”.

Página 19 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

o Subcapa de Agentes de Servicios Externos. Esta capa nace de las necesidades de tener
componentes de negocio que puedan utilizar funcionalidades expuestas a través de
servicios externos (Normalmente servicios Web) y reutilizarlos internamente en la
aplicación.

Módulo Común: Este módulo transversal, tiene como fin proporcionar componentes de software
comunes a todas las capas, como son:

o Entidades de Dominio. Son una serie de entidades desconectadas, que se utilizan para
alojar y transferir datos de entidades entre las diferentes capas, y adicionalmente
contienen también lógica de dominio relativa a cada entidad.
o Objetos Valor. Son una serie de objetos que describen cosas. Y siendo más precisos, un
objeto sin ninguna entidad conceptual, que describe aspectos del dominio.
o Objetos Utilitarios. Son todas aquellas clases que tienen como funcionalidad
proporcionar utilidades comunes de cálculos, asignaciones y transformaciones a lo largo
de toda la aplicación. Generalmente estas clases son definidas como estáticas.
o Adaptadores. Los adaptadores tienen como finalidad poder transformar un tipo de objeto
a otro, para que estas puedan ser utilizada das por clases que no puedan utilizar el
objeto sin transformar.

Capa transversal de calidad de Servicio (QOS): esta capa tiene la finalidad de proporcionar
capacidades técnicas genéricas que dan soporte a capas superiores. En esta capa también existe el
concepto de servicios. Se encargan de agrupar acciones de infraestructura, como el envió de correos,
controlar aspectos de seguridad, gestión de operaciones, auditoria y registro, etc. En la actualidad la
arquitectura marco del ministerio del interior para aplicaciones .Net, solo soporta los bloques de auditoria
y registro, manejo de excepciones y criptografía.

NOTA: Esta arquitectura de referencia anteriormente descrita se encuentra implementada, y reposito en

el archivo digital de los sistemas de información del grupo de sistemas de la oficina de información
pública.

5. Estándares de diseño detallado

A continuación se describen una serie de principios básicos a la hora de diseñar un sistema de

información, los cuales ayudaran a crear una arquitectura que se ajuste a prácticas demostradas, que
minimicen los costes de mantenimiento y maximicen la usabilidad y extensibilidad.

Principios SOLID. A continuación se describen los principios de diseño relacionados con la sigla SOLID:

o Principio de Única Responsabilidad (Single Responsability Principle): Una clase debe

tener una única responsabilidad o característica. Dicho de otra manera, una clase debe
de tener una única razón por la que está justificado realizar cambios sobre su código
fuente. Una consecuencia de este principio es que, de forma general, las clases deberían
tener pocas dependencias con otras clases/tipos.
o Principio Abierto Cerrado (Open Closed Principle): Una clase debe estar abierta para la
extensión y cerrada para la modificación. Es decir, el comportamiento de una clase debe
poder ser extendido sin necesidad de realizar modificaciones sobre el código de la
misma.
o Principio de Sustitución de Liskov (Liskov Subtitution Principle): Los subtipos deben
poder ser sustituibles por sus tipos base (interfaz o clase base). Este hecho se deriva de
que el comportamiento de un programa que trabaja con abstracciones (interfaces o
clases base) no debe cambiar porque se sustituya una implementación concreta por otra.

Página 20 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Los programas deben hacer referencia a las abstracciones, y no a las implementaciones.

Veremos posteriormente que este principio va a estar muy relacionado con la Inyección
de Dependencias y la sustitución de unas clases por otras siempre que cumplan el
mismo interfaz.
o Principio de Segregación de Interfaces (Interface Segregation Principle): Los
implementadores de Interfaces de clases no deben estar obligados a implementar
métodos que no se usan. Es decir, los interfaces de clases deben ser específicos
dependiendo de quién los consume y por lo tanto, tienen que estar
granularizados/segregados en diferentes interfaces no debiendo crear nunca grandes
interfaces. Las clases deben exponer interfaces separados para diferentes
clientes/consumidores que difieren en los requerimientos de interfaces.
o Principio de Inversión de Dependencias (Dependency Inversion Principle): Las
abstracciones no deben depender de los detalles – Los detalles deben depender de las
abstracciones. Las dependencias directas entre clases deben ser reemplazadas por
abstracciones (interfaces) para permitir diseños top-down sin requerir primero el diseño
de los niveles inferiores.

Mantener el código transversal abstraído de la lógica específica de la aplicación: el código

transversal se refiere a código de aspectos horizontales, cosas como la seguridad, gestión de
operaciones, logging, instrumentalización, etc. La mezcla de este tipo de código con la implementación
específica de la aplicación puede dar lugar a diseños que sean en el futuro muy difíciles de extender y
mantener. Relacionado con este principio está AOP (Aspect Oriented Programming).

Separación de Preocupaciones/Responsabilidades (Separation of Concerns): dividir la aplicación en

distintas partes minimizando las funcionalidades superpuestas ente dichas partes. El factor fundamental
es minimizar los puntos de interacción para conseguir una alta cohesión y un bajo acoplamiento. Sin
embargo, separar la funcionalidad en las fronteras equivocadas, puede resultar en un alto grado de
acoplamiento y complejidad entre las características del sistema.

No repetirse (DRY): se debe especificar la intención en un único sitio en el sistema. Por ejemplo, en
términos del diseño de una aplicación, una funcionalidad específica se debe implementar en un único
componente; esta misma funcionalidad no debe estar implementada en otros componentes.

Minimizar el diseño de arriba abajo (Upfront design): diseñar solamente lo que es necesario, no
realizar sobre ingenierías y evitar el efecto YAGNI (En inglés-slang: You Aint Gonna Need It).

6. Tecnologías de la aplicación

A continuación se describe la arquitectura marco de referencia definida por el ministerio del interior, para
la construcción de aplicaciones basadas en plataforma .Net, detallada en las diferentes tecnologías que
implementa.

Página 21 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Figura 6. Arquitectura Marco de Alto Nivel con Tecnologías Asociadas.

o Microsoft .Net. NET Framework es un entorno de ejecución runtime que administra

aplicaciones cuyo destino es .NET Framework. Incorpora Common Language Runtime,
que proporciona administración de la memoria y otros servicios del sistema, y una
biblioteca de clases completa, que permite a los programadores aprovechar el código
sólido y confiable de todas las áreas principales del desarrollo de aplicaciones.
o Microsoft Asp.Net. ASP.NET es un modelo de desarrollo Web unificado que incluye los
servicios necesarios para crear aplicaciones Web empresariales con el código mínimo.
ASP.NET forma parte de .NET Framework y al codificar las aplicaciones ASP.NET tiene
acceso a las clases en .NET Framework. El código de las aplicaciones puede escribirse
en cualquier lenguaje compatible con el Common Language Runtime (CLR), entre ellos
Microsoft Visual Basic y C#. Estos lenguajes permiten desarrollar aplicaciones ASP.NET
que se benefician del Common Language Runtime, seguridad de tipos, herencia, etc.
o KnockOut.js. Es una biblioteca javascript, que nos ayuda a implementar aplicaciones
mediante un modelo MVVM. Dentro de las características especiales, tal cual indica en
su página, nos permite:
 Realizar Binding Declarativos
 Refresco automático de los elementos del UI, como decía, cuando se actualiza el
modelo vista, nuestra UI se actualiza automáticamente
 Tracking de Dependencias, detecta los cambios realizados en la vista o en el
modelo y es capaz de propagarlos.
 Plantillas, permite  generar rápidamente plantillas en función de los datos del
modelo vista.
o JQuery. Es un framework de JavaScript para facilitar, entre otros, el acceso a los
elementos del DOM, los efectos, interactuar con los documentos HTML, desarrollar
animaciones y agregar interacción con la tecnología AJAX a páginas web.
o OData. Es una estandarización, a través de la carta de compromiso de Microsoft
(Microsoft Open Specification Promise), de la generación y consumo de datos vía Web.
Esta construido sobre un conjunto de estándares de internet, especialmente sobre el
AtomPub especificado en el RFC 5023, quien a su vez está construido sobre Atom.
Odata permite la creación de servicios de datos basados en HTTP mediante un modelo
de datos abstracto mediante un identificador uniforme de recursos (Uri) definidos en el
RFC 2396.

Página 22 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

o Windows Comunication Foundation (WCF). Es el modelo de programación unificado de

Microsoft para generar aplicaciones orientadas a servicios. Permite a los programadores
generar soluciones con transacción seguras y de confianza, que se integren en diferentes
plataformas y que interoperen con las inversiones existentes.
o Entity Framework (EF). Entity Framework es una tecnología que permite a los
desarrolladores trabajar con datos en forma de objetos y propiedades específicos del
dominio, como clientes y direcciones de cliente, sin tener que preocuparse por las tablas
y columnas de la base de datos subyacente donde se almacenan estos datos. Con Entity
Framework, los desarrolladores pueden trabajar en un nivel mayor de abstracción cuando
tratan con datos, y pueden crear y mantener aplicaciones orientadas a datos con menos
código que en las aplicaciones tradicionales. Dado que Entity Framework es un
componente de .NET Framework, las aplicaciones de Entity Framework se pueden
ejecutar en cualquier equipo en el que esté instalado.
o Lucene. Apache Lucene es una biblioteca del motor de búsqueda de alto rendimiento de
texto, con todas las funciones. Se trata de una tecnología adecuada para casi cualquier
aplicación que requiera la búsqueda de texto completo, especialmente multiplataforma.
o Enterprise Libraries. Microsoft Enterprise Library es un conjunto de librerías que facilitan
el desarrollo de aplicaciones empresariales en .NET. Implementan funcionalidad que
típicamente debe incorporarse a las aplicaciones empresariales. Esta funcionalidad se
presenta subdividida en 9 bloques, cada uno apuntando a resolver un tipo de problema
particular:

2. Implementación

ii. General

Es responsabilidad del ejecutor del proyecto la identificación de las necesidades en relación a ambientes
de pruebas y acceso a información del Ministerio del Interior, conjuntamente con el grupo de sistemas de
la OIPI se establecerán los mecanismos de acceso y/o transferencia de información posterior a la
evaluación de confidencialidad de la misma.

iii. BPM

Todos los elementos de una clase de proceso deben documentarse de acuerdo a su finalidad dentro del
mismo, para ello se debe diligenciar el campo Descripción para todos los elementos de tipo Evento,
Compuerta y Tarea (Personal y Sistema).

1. Construcción de formularios

A continuación se describen una serie de lineamientos técnicos a tener en cuenta para la construcción de
formularios sobre la plataforma.

Los Nombres de los formularios deberán ser de la forma <Clave>.<Objeto>, Ejemplo: RTC.IM_Proceso
X, el anterior ejemplo identifica al formulario asociado al inicio del proceso. Las divisiones de los
formularios deberán ser de la forma <Clave>.<Objeto>.<NombreDiv>, Ejemplo: RCT.IM_Proceso
X.HEADER_FORMULARIO, el anterior ejemplo identifica a la división asociada a la cabecera del
formulario.

Los estilos aplicados a los objetos del formulario deberán en todos los casos estar enlazados a los estilos
previamente aprobados para el proyecto y configurados en la herramienta en la sección de galería de
estilos.

Página 23 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Se debe evaluar la necesidad de que los eventos IM y EM se publiquen como servicios web, de este
modo se posibilita que los procesos puedan ser iniciados o continuados por programas externos.

2. Seguridad

En relación a este punto se debe partir del enfoque de la herramienta hacia los recintos seguros, en ese
orden de ideas se deberán en lo posible determinar tres tipos diferentes de estos para aplicar a los
elementos configurados a saber:

 Recintos de Monitorización: Aplicables a la monitorización de los procesos automatizados los

cuales deberán cumplir con la sintaxis Clave.RCM.X donde X representa el nombre particular al o
los procesos que se blindan con el recinto. Es preferible que para la aplicación del recinto en su
sección de Lectura se defina un solo Rol Personal.
 Recintos de Procesos: Aplicables a los inicios y eventos intermedios de los procesos
automatizados, deberán cumplir con la sintaxis Clave.RCP.X donde X representa el nombre
particular relacionado al o los eventos de los procesos que se blindan con el recinto. Es preferible
que para la aplicación del recinto en su sección de Lectura se defina un solo Rol Personal.
 Recintos de Familias: Aplicables a los accesos de tipo CRUD de las familias utilizadas, deberán
cumplir con la sintaxis Clave.RCF.X donde X representa el nombre particular al o las familias que
se blindan con el recinto. Es preferible que para la aplicación del recinto en sus secciones de
Lectura / Edición / Adición / Cancelación se defina un solo Rol Personal.

En lo relacionado a los roles a aplicar sobre los recintos seguros y siguiendo las recomendaciones de
casa matriz, se deben nombrar de acuerdo a su utilización en los recintos en el modo en que apliquen de
la forma, por ejemplo, si el rol aplica para un recinto de familia, el rol deberá determinarse como
Clave.RCF.X_Y, donde X es el nombre particular dado al recinto y Y la abreviatura del modo (L, E, A, C)
– (Lectura, Edición, Actualización, Cancelación).

iv. Transaccional

Se requiere que el código fuente entregado como definitivo se encuentre debidamente documentado en
cuanto a las clases y los métodos que la componen. Solo para los casos en que la lógica descrita sea
demasiado compleja se sugiere documentar las porciones de código relacionadas.
Es altamente recomendable que se realicen inspecciones de codificación sobre la los artefactos en
construcción con el fin de disminuir la utilización de malas prácticas de software, al respecto, en cualquier
momento el grupo de sistemas de la OIPI podrá solicitar al proveedor de la solución, el código fuente para
la realización de inspecciones sobre la construcción.

3. Pruebas

v. General

El ejecutor del proyecto se encuentra en libertad de aplicar su metodología en lo relacionado a las

pruebas unitarias y pruebas de certificación de los desarrollos, sin embargo debe contemplar dentro de
sus planes, la elaboración y ejecución de un plan de certificación por parte del usuario final. Estas
pruebas deberán contemplar los escenarios de negocio junto con los datos de entrada y resultados
esperados de modo que a manera de lista de chequeo, una vez finalizados los desarrollos, el usuario
final defina el nivel de cumplimiento que presenta la herramienta en relación a los procesos de negocio
incluidos en el alcance del proyecto.

Página 24 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

Para dar como verificado un caso de uso, se debe diligenciar el documento según formato “Formato de
Pruebas Funcionales TC-GT-P2-F5” en el que deberá quedar consignada la conformidad por parte del
usuario con el producto entregado.

4. Entrega

vi. General

Para la recepción del proyecto por parte del grupo de sistemas de la OIPI, el ejecutor del proyecto
deberá hacer la entrega total de la siguiente información:

 Formatos de Gestión de inicio, seguimiento y cierre del proyecto, bajo acta de aceptación.
 Casos de prueba certificados por los respectivos usuarios finales, bajo actas de aceptación.
 Código fuente de todos los componentes (proyectos transaccionales).
 Ficha técnica del sistema de información (proyectos transaccionales), se deben incluir los datos
de contacto para las eventuales solicitudes de soporte.
 Manual de usuario.
 Manual de instalación y configuración (proyectos transaccionales).
 Manual técnico de operación en el cual se debe incluir el listado de errores comunes y sus
formas de solucionarlo.
 Documento de entrega de procesos (BPM).

Se entiende que los entregables intermedios del proyecto pueden tener modificaciones durante la
ejecución de las fases posteriores, por ello se hace necesario que como parte de la entrega final se
presenten los documentos definitivos relacionados a todos los entregables.

vii. BPM

El manual de usuario de los procesos BPM debe en gran medida enfocarse al detalle de la ejecución de
pasos y acciones dentro de las pantallas que acompañan la definición del mismo. Para resaltar algunos
de los puntos que se entienden como clave y obligatorios al momento de evaluar y recibir el manual de
usuario se listan a continuación las consideraciones mínimas a tener en cuenta:

- Debe contener una sección general al inicio del manual donde se describan las operaciones
comunes a todas las pantallas y que expliquen la forma de funcionamiento de los controles como
botones, cuadros de selección, tablas y demás controles que permiten la interacción de los
usuarios con el sistema.

- Definición de los grupos de empleados con su respectiva descripción que aplican sobre la
ejecución de las tareas en los procesos.

- Matriz de trazabilidad que indique la relación entre grupos de procesos y pantallas, esto es útil
para generar un contexto visual de las tareas en que un grupo de empleados en particular debe
intervenir directamente.

Página 25 de 26
 Código: TC.GT.T1
Versión: 01
PROTOCOLO DE LINEAMIENTOS TÉCNICOS
PARA EL MANEJO DE CICLO DE VIDA DE
Vigente desde:
PROYECTOS DE SOFTWARE

6. DOCUMENTO/ REGISTRO

REGISTROS RESPONSABLE FRECUENCIA UBICACIÓN

Acta de Aceptación Líder de Gestión Permanente 1301.48
Documento Técnico Líder Técnico Permanente 1301.48
Ficha Técnica Desarrolladores Permanente 1301.48
Formato de Pruebas Analista de Calidad Permanente 1301.48

*Tabla de retención documental

7. CONTROL DE CAMBIOS

FECHA CAMBIO VERSIÓN

8. CONTROL DE FIRMAS

Elaboró Revisó y Aprobó

Firma Firma

_______________________ ______________________
Nombre Nombre
Firma Firma

9. ANEXOS

Para apoyo, comprensión y aplicación de las actividades descritas en este documento es necesario
consultar e implementar los lineamientos de gobierno en línea en marcados en el link:
http://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8114.html

Página 26 de 26