Creación de un prototipo de software basado en el

componente de Autoevaluación institucional del Modelo

Estándar de Control Interno MECI

Jorge Enrique Castro Pescador

Especialización en ingeniería de Software

Universidad Dsitrital Francisco José de Caldas
Bogotá D.C. Colombia
25 de noviembre de 2016
 Creación de un prototipo de software basado en el
componente de Autoevaluación institucional del Modelo
Estándar de Control Interno MECI

Jorge Enrique Castro Pescador

Director
Alexandra Abuchar Porras
Revisor
José Ignacio Palacios

Especialización en ingeniería de Software

Universidad Dsitrital Francisco José de Caldas
Bogotá D.C. Colombia
25 de noviembre de 2016
Índice

Introducción 4

I Contextualización de la investigación 5

1. Descripción de la investigación 5
1.1. Titulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Estudio del problema de investigación 6

2.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Formulación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Sistematización del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Objetivos de la investigación 8
3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4. Justificación de la Investigación 9
4.1. Justificación practica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5. Marco de referencia 10
5.1. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Antecedentes y estado actual . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Modelo Estándar de Control Interno . . . . . . . . . . . . . . . . . . . . 10
5.1.3. Marco conceptual de arquitectura empresarial . . . . . . . . . . . . . . . 12
5.1.4. The Open Group Architecture Framework . . . . . . . . . . . . . . . . . 12
5.2. Revisión sucinta sobre el lenguaje de arquitectura empresarial . . . . . . . . . . 13
5.2.1. Especificación de Archimate . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Metodología de desarrollo ágil Scrum . . . . . . . . . . . . . . . . . . . . 18
5.3. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1. Autoevaluación Institucional . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.2. Contexto de la autoevaluación institucional en el MECI . . . . . . . . . 20
5.3.3. Metodología estándar para la realización Autoevaluación Institucional . 21
5.4. Marco legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6. Aspectos metodológicos 24
6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Método de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Fuentes y técnicas para la recolección de la información . . . . . . . . . . . . . 25
6.3.1. Fuentes primarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3.2. Fuentes secundarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. Tratamiento de la información . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1
II Desarrollo de la investigación 28

7. Análisis de la información 28
7.1. Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8. Diseño de la Arquitectura Empresarial 31

9. Punto de vista del negocio 31

9.1. Punto de vista de la organización . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2. Punto de vista de cooperación de actor . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Punto de vista de función de negocio . . . . . . . . . . . . . . . . . . . . . . . . 34
9.4. Punto de vista de proceso de negocio . . . . . . . . . . . . . . . . . . . . . . . . 35
9.5. Punto de vista de cooperación de proceso de negocio . . . . . . . . . . . . . . . 37
9.6. Punto de vista de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

10.Punto de vista de la aplicación 41

10.1. Punto de vista de comportamiento de aplicación . . . . . . . . . . . . . . . . . 41
10.2. Punto de vista de cooperación de aplicación . . . . . . . . . . . . . . . . . . . . 42
10.3. Punto de vista de estructura de aplicación . . . . . . . . . . . . . . . . . . . . . 43
10.4. Punto de vista de Uso de aplicación . . . . . . . . . . . . . . . . . . . . . . . . 45

11.Punto de vista Tecnológico 47

11.1. Punto de vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.2. Punto de vista de uso de infraestructura . . . . . . . . . . . . . . . . . . . . . . 48
11.3. Punto de vista de Implementación y despliegue . . . . . . . . . . . . . . . . . . 50
11.4. Punto de vista de Estructura de información . . . . . . . . . . . . . . . . . . . 51
11.5. Punto de vista de realización de servicio . . . . . . . . . . . . . . . . . . . . . . 52
11.6. Punto de vista de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

12.Extensión Motivacional 55
12.1. Punto de vista de stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
12.2. Punto de vista de realización de objetivos . . . . . . . . . . . . . . . . . . . . . 56
12.3. Punto de vista de contribución de objetivos . . . . . . . . . . . . . . . . . . . . 58
12.4. Punto de vista de principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
12.5. Punto de vista de realización de requerimientos . . . . . . . . . . . . . . . . . . 59
12.6. Punto de vista de motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

13.Extensión de Implementación y Migración 62

13.1. Punto de vista de proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
13.2. Punto de vista de migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.3. Punto de vista de migración e implementación . . . . . . . . . . . . . . . . . . 64

14.Cierre de la definición de la arquitectura empresarial 66

2
15.Desarrollo del plan de trabajo bajo Scrum 67
15.1. Historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
15.1.1. Primer Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
15.1.2. Segundo Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15.2. Análisis de la metodología de software . . . . . . . . . . . . . . . . . . . . . . . 77
15.2.1. Burndown chart del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 77
15.2.2. Gráfica de velocidad del proyecto . . . . . . . . . . . . . . . . . . . . . . 78
15.3. Plataforma tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
15.4. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

16.Arquitectura de software 81
16.1. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
16.2. Modelo de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
16.3. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

17.Metodología web 85
17.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
17.1.1. Selección de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
17.1.2. Expectativa de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
17.1.3. Expectativa de la organización . . . . . . . . . . . . . . . . . . . . . . . 86
17.2. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
17.2.1. Selección de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
17.2.2. Estructura de navegación . . . . . . . . . . . . . . . . . . . . . . . . . . 86
17.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

III Cierre de la investigación 90

18.Resultados y discusión 90

19.Conclusiones 90
19.1. Aportes Originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
19.2. Trabajos o publicaciones derivadas . . . . . . . . . . . . . . . . . . . . . . . . . 91

20.Prospectiva del trabajo de grado 91

20.1. Trabajos de investigación futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Bibliografia 93

21.Anexos 94
21.1. Anexo 1 - Formato de entrevistas realizadas . . . . . . . . . . . . . . . . . . . . 94
21.2. Anexo 2 - Procedimiento para la tabulación de encuestas e intepretación de
resultados del MECI [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3
Introducción
La presente investigación tiene como objetivo abordar el problema que surge a partir de
encontrar un mecanismo confiable y cómodo para la realización del proceso de autoevaluación
institucional en aquellas entidades que implementen un modelo estándar de control interno,
como área encargada de la medición y el seguimiento de los planes de acción, metas y en
general, el ente de regulación por defecto a nivel interno de una organización de carácter
descentralizado.
Siguiendo y tomando como base la definición del área, de sus funciones y los lineamientos
que debe seguir, vigilados y presentes a la luz de la normatividad colombiana, se establecen
ciertos mecanismos de medición y evaluación como el Modelo Estándar de Control Interno.
Sin embargo, no se encuentran definidos en su totalidad y dependen de implementaciones
concretas de software que cada entidad decide realizar según sus características particulares.
Es de interés de la investigación encontrar un solución que pueda ser generalizada y apli-
cada a varios contextos posibles conformar en lo posible un prototipo de software que pueda
utilizarse a partir de éste estándar.
Por esto, esta investigación pretende hacer uso de la disciplina de la ingeniería de software
para el levantamiento de requerimientos, definición de arquitectura empresarial del proceso,
el uso de metodologías de desarrollo de software conocidas y consulta sobre los marcos de
trabajo y herramientas tecnológicas que permitan solucionar el problema.
El problema de investigación que se espera resolver es la automatización del proceso debido
a que generalmente se realiza de forma manual o con el uso de múltiples herramientas no
integradas para la realización, consolidación, y análisis de resultados de las evaluaciones que
puede llevar en los retrasos de entrega de los resultados.
Esto se considera una propuesta favorable debido a que actualmente el concepto de invertir
en una infraestructura tecnológica y de sistemas de información como apoyo en estos procesos
suele ser de gran ayuda para la organización que desea que aquellas tareas que sean repetitivas
o que presenten dificultades puedan ser solucionadas. La ingeniería de software como disciplina
fundamental para este paso se realiza con rigurosidad y metodología.
La motivación académica y profesional busca investigar y conocer los insumos conceptuales
necesarios para resolver este tipo de problemas de forma asertiva. La consulta de nuevos
avances tecnológicos motivan la puesta en practica de estos conceptos por medio de soluciones
en el ámbito empresarial que son útiles y además deban contribuir como insumos para futuros
problemas de investigación con características similares.

4
Parte I
Contextualización de la investigación
1. Descripción de la investigación
1.1. Titulo
Creación de un prototipo de software basado en el componente de Autoevaluación insti-
tucional del Modelo Estándar de Control Interno MECI

1.2. Definición
El componente de autoevaluación institucional es de gran interés para las entidades que
buscan mecanismos adicionales a los ya establecidos para la medición de la gestión pública [6].
A nivel interno este componente puede ser útil para la toma de decisiones y conocer el estado
de los planes y políticas en la organización. En el nivel externo, como herramienta de apoyo
para la presentación de informes de gestión a entes de control nacional que se establecen según
el tipo de entidad.
El tema de investigación se encuentra orientado al componente de autoevaluación institu-
cional, un componente que pertenece al modulo de Control de evaluación y seguimiento del
MECI, dentro de toda la estructura del estándar que comprende otros módulos y componentes
definidos.
Modelo Estándar de Control Interno MECI.

• Módulo Control de Evaluación y Seguimiento.

◦ Componente Autoevaluación Institucional.
 Autoevaluación del Control y Gestión.

En Colombia, existe un fundamento legal que soporta este control y son conocidas como
contralorías de orden en el Distrito capital y a nivel Nacional. Existen implementaciones en
sistemas de software que soportan la presentación de los informes y herramientas creadas por
el estado y su funcionamiento se emplea para el control general en el nivel externo, pero a
nivel interno cada organización es responsable de decidir si desea soportar sus procesos en
estas tecnologías.
Aquellas organizaciones que no desean soportar este proceso tienden a hacerlo de forma
manual, y es necesario que se les otorgue una herramienta con las tendencias tecnológicas
actuales para que sus tareas, generalmente operativas, puedan ser automatizadas y el enfoque
de los involucrados cambie de realizar estas tareas a buscar mecanismos de mejora del propio
proceso esto con el fin de reorientar las actividades de los analistas del área y a la vez promover
una cultura hacia la autoevaluación donde implique que realizar la evaluación sea algo fácil,
cómodo y motivador.
Se espera proveer un estudio a la comunidad académica sobre este tema como base pa-
ra futuras investigaciones, presentar la forma en la que se aborda este problema como un
caso de estudio y proponer un prototipo funcional para las organizaciones que tengan estas
características puedan hacer uso de ésta herramienta.

5
2. Estudio del problema de investigación
2.1. Planteamiento del problema
La evaluación acerca del cumplimiento de los objetivos de una organización siempre se ha
considerado como un punto fundamental en las organizaciones maduras que buscan medir sus
procesos y el nivel de avance de sus proyectos, estos procesos de medición interna general-
mente se realizan de forma conjunta e implican a todos los involucrados en la organización.
Actualmente es visto como un proceso sistematizado secuencial y que genera resultados luego
de que la evaluación se realice y todos los resultados parciales por área o por proceso sean
organizados y tabulados.
Un problema que surge a partir de esto es cuando la organización no tiene alineado este
proceso con las tecnologías de información, evidenciando que el proceso de consolidación de
la información y la obtención de los resultados es realizada manualmente y no existe un
mecanismo de comunicación conveniente entre los actores del proceso, causando en el futuro
retrasos en los resultados para las áreas que lo requieren, como las que llevan a cabo un rol en el
mejoramiento continuo de la entidad (planeación, control interno, dirección general), posibles
inconsistencias en los resultados, búsqueda de personal adicional temporal para agilizar el
proceso y un retraso en la presentación de los informes de gestión a entes de control cuando
al entidad es de carácter descentralizado.
Las decisiones a tomar para controlar parte de este problema incluye la alineación del
proceso con las tecnologías de la información, dado que éste puede verse de forma estructurada,
la consolidación de evaluaciones, resultados, cronograma del proceso y comunicación entre
los involucrados pueden ser modelados en un sistema de software que permitirá realizar los
subprocesos operativos con precisión y rapidez. La ingeniería de software entonces, proveerá
de las metodologías para solucionar este problema y los mecanismos para el levantamiento
de la información, las técnicas para el modelado del sistema de software, los detalles para la
puesta en producción, alineación con los procesos existentes de la empresa y las practicas para
el uso de interfaces de interacción de los usuarios y la herramienta.
De esta forma se facilita a los participantes obviar los detalles de éstas tareas y mantener
la prioridad en enfocarse en cómo mejorar el proceso y el propio mecanismo de evaluación.

2.2. Formulación del problema

¿De que forma los entes involucrados en una organización que usan el modelo estándar de
control interno se verán afectados de la implementación de un prototipo que automatice
los procesos operativos para la autoevaluación institucional?

2.3. Sistematización del problema

¿La definición de una arquitectura empresarial sobre el proceso como eje para el mode-
lado de requerimientos será efectivo y podrá catalogarse como una metodología valida
en la Ingeniería de requerimientos para la investigación en ingeniería de software?

¿El prototipo generado será extensible de forma que pueda ser empleado para este pro-
ceso en todas las organizaciones que implementen el sistema de control interno MECI?

6
¿Los datos resultantes del proceso de consolidación y análisis de evaluaciones, serán
indicadores verídicos que podrán ser interpretados por el equipo de control interno, y se
se tomarán como apoyo para la toma de decisiones acerca de los planes y proyectos de
mejoramiento de la organización?

7
3. Objetivos de la investigación
3.1. Objetivo general
Construir un prototipo de herramienta basado en el componente de Autoevaluación insti-
tucional del Modelo Estándar de Control Interno MECI bajo el enfoque de encuesta adoptado
por diversas entidades de carácter Descentralizado, mediante la definición de la arquitectura
empresarial del proceso particular con el fin de proporcionar un mecanismo confiable acerca
de los indicadores de gestión relevantes para éstas organizaciones.

3.2. Objetivos específicos

1. Describir el proceso de Autoevaluación institucional basado en el modelo estándar de
control interno MECI, mediante la definición del marco teórico, conceptual y la recolec-
ción de la información de especialistas de control interno, que otorgue el insumo inicial
para identificar el contexto del problema.

2. Diseñar la arquitectura empresarial orientada al proceso de negocio de la autoevaluación

institucional gestionada por el área de control interno de la organización utilizando una
metodología de desarrollo de arquitecturas ADM con el fin de expresar una definición
de requerimientos acertada para la descripción del prototipo a construir.

3. Construir el prototipo funcional mediante el uso de una metodología de desarrollo de

software ágil que permita gestionar el proceso de autoevaluación y otorgue resultados
sobre los indicadores de gestión de la organización.

8
4. Justificación de la Investigación
4.1. Justificación practica
Establecer un mecanismo de autoevaluación en las entidades publicas surge a partir de
realizar un seguimiento a la gestión pública y los recursos que se destinan, utilizando herra-
mientas que permitan medir la gestión realizada y cuyos indicadores sean transparentes y
apoyen a las entidades reguladoras, el cómo se ejecutan en proyectos y planes, y la búsqueda
de resultados que apoyen la toma de decisiones debe siempre buscar la mejora de los proyectos
realizados con los recursos disponibles que aporta la misma sociedad y cuyo fruto debe ser
beneficioso para ella[1].
Dentro de este conjunto de herramientas esta la autoevaluación institucional como un
mecanismo de medición interno en cada organización.
El proceso actual que llevan las entidades publicas para el proceso de autoevaluación
institucional se realiza concretamente mediante el enfoque de encuestas, y que éstas deben ser
consolidadas manualmente así como también la forma en la que se lleva a cabo el calculo de los
resultados para su posterior análisis es un proceso que puede desviar la visión del analista que
es la toma de decisiones. Por esto, se debe diseñar una herramienta que pueda representar
un sistema capaz de colaborar con las áreas involucradas utilizando las tecnologías de la
información, que modele los procesos operativos y entregue resultados parciales y totales en
menor tiempo comparado al proceso manual, y por consiguiente, permita a las áreas de control
interno que adoptan el modelo MECI medir el cumplimiento de los objetivos organizacionales
con precisión y rapidez.

9
5. Marco de referencia
5.1. Marco Teórico
5.1.1. Antecedentes y estado actual
Las primeras definiciones sobre la necesidad de una regulación a las entidades publicas se
formalizan en la normatividad colombiana desde 1993 y una serie de reformas y actualizaciones
en la cual la versión del MECI actual corresponde a la del año 2014. Desde entonces, la norma
ha buscado expresar las políticas y lineamientos que cumplan tanto en una escala de toda
la estructura administrativa[7], como de forma interna de cada organización orientándola a
cumplir sus propósitos misionales, en un enfoque de control y seguimiento.
Debido a que es modelo definido y presentado en un marco legal, es de carácter obliga-
torio que cada entidad publica o perteneciente al estado lo adopte, generalmente en un área
organizacional de la empresa como las áreas u oficinas de Control Interno: “El Modelo Es-
tándar de Control Interno debe ser aplicado por todos los organismos y organizaciones de las
Ramas del Poder Público en sus diferentes órdenes y niveles, por la organización electoral, los
organismos de control, los establecimientos públicos, las empresas industriales y comerciales
del Estado, las sociedades de economía mixta en las cuales el Estado posea el 90 % o más de
capital social, el Banco de la República y los fondos de origen presupuestal.”[7]
Este modelo se ha caracterizado por adoptar una estructura organizativa en módulos,
cada uno de los módulos se enfoca en un componente de planeación y gestión, de evaluación
y seguimiento, y de comunicación. Los elementos de cada modulo se vienen actualizando
sobre cada implementación del MECI, conformando versiones del estándar con el identificador
del año a partir del regimiento de la actualización. Durante la implementación concreta,
se han presentado dos versiones formales, 2005 y 2014, en las cuales se busca mejorar los
elementos, actualizarlos o realizar modificaciones de los mecanismos de seguimiento, todos los
cambios vienen dados por el conjunto de organismos de definen el estándar que anualmente
se encuentran realizando revisiones a partir de informes y evidencias de las entidades que lo
ponen en práctica.

5.1.2. Modelo Estándar de Control Interno

En Colombia, el Modelo Estándar de Control Interno, surge como un esfuerzo por crear una
herramienta de apoyo para el control a la gestión publica, mediante mecanismos de evaluación
y seguimiento que permitan, de forma generalizada, ser aplicables para todas las entidades
públicas, y que posibiliten un medio de regulación del estado a estas entidades.
Es por esto que el departamento Administrativo de la Función Publica, con la colaboración
de la academia, el Comité Interinstitucional de Control Interno Nacional-CICINAL, organis-
mos de control y el Instituto de Auditores Internos II, [5, 7] determinar mediante una serie
de decretos, actualizaciones, normas y estándares las características que deben encontrarse
presentes en el control interno de las entidades y los diferentes enfoques implementales que
pueden usarse para lograr estos indicadores de medición.
“El MECI concibe el Control Interno como un conjunto de elementos interrelacionados,
donde intervienen todos los servidores de la entidad, como responsables del control en el ejer-
cicio de sus actividades; busca garantizar razonablemente el cumplimiento de los objetivos
institucionales y la contribución de éstos a los fines esenciales del Estado.”[7].

10
 Figura 5.1: Estructura MECI 2014 [7]

Con el objetivo de medir el cumplimiento de objetivos organizacionales, el MECI establece

una estructura compuesta de dos módulos, seis componentes y trece elementos en un esquema
gráfico (Fig 5.1)

ESTRUCTURA DEL MODELO ESTÁNDAR DE CONTROL INTERNO

1. Módulo de Control de Planeación y Gestión

a) Componente Talento Humano

1) Acuerdos compromisos y protocolos éticos
2) Desarrollo de talento humano
b) Componente Direccionamiento Estratégico
1) Planes, programas y proyectos
2) Modelo de operación por procesos
3) Estructura organizacional
4) Indicadores de gestión
5) Políticas de operación
c) Componente Administración del Riesgo
1) Politicas de administración del riesgo
2) Identificación del riesgo
3) Análisis y valoración del riesgo

2. Módulo Control de Evaluación y Seguimiento.

a) Componente Autoevaluación Institucional

1) Autoevaluación del control y gestión

11
 b) Componente de Auditoría Interna
1) Auditoría interna
c) Componente Planes de Mejoramiento
1) Plan de mejoramiento

3. Eje Transversal Información y Comunicación

a) Información y comunicación interna y externa

b) Sistemas de información y comunicación

cuyo objetivo es proporcionar un modelo para definir la estructura, autoridad y responsabi-

lidad del área de control interno, identificar y analizar riesgos, establecer las actividades de
control, realizar una evaluación continua, comunicar y evaluar las deficiencias y servir de apo-
yo a los sistemas de gestión de calidad de la entidad. Asimismo busca cumplir con el principio
de autogestión, es decir establecer acciones de la entidad a garantizar su función, verificarse
y evaluarse a si misma, mantener una organización en sus procesos y otorgarle un sistema de
comunicación con los departamentos que la vigilan y la regulan.

5.1.3. Marco conceptual de arquitectura empresarial

En la actualidad, muchas organizaciones han dado de cuenta lo necesario de integrar su
negocio con las Tecnologías de la Información y la comunicación como un factor clave en el
éxito del negocio, esto es posible lograrlo con la construcción de un contexto estratégico para
la evolución de los sistemas de información en respuesta a las necesidades cambiantes.
Por esto, una arquitectura empresarial permite alcanzar el balance correcto entre la efi-
ciencia de las Tecnologías de la Información y la innovación del negocio. El rol del Arquitecto
de Software, quien define una arquitectura empresarial, es identificar como los implicados
(stakeholders) y cómo los requerimientos que tengan deben ser conducidos durante desarrollo
del sistema[9].
Las arquitecturas empresariales proveen una descripción formal del sistema tanto en sus
propiedades estructurales como comportamentales y su evolución, y proveen un plan sobre
como los productos pueden ser desarrollados y como van a ser integrados en todo el siste-
ma. El uso de Marcos de Trabajo como un conjunto de estructuras fundamentales permite
la construcción de arquitecturas empresariales concretas, a partir de una metodología para
diseñar el estado objetivo, estos marcos de trabajo contienen un conjunto de elementos, una
semántica definida y pueden adoptar uno más estándares.

5.1.4. The Open Group Architecture Framework

El marco de trabajo de arquitectura de Open Group provee un enfoque para el diseño, la
planeación, la implementación y la gestión de una arquitectura orientada con las tecnologías de
la información[9]. TOGAF define como “empresarial” a cualquier colección de organizaciones
que tienen un conjunto de objetivos comunes, por ejemplo, una agencia gubernamental, una
división de una corporación, una corporación, o un área de una empresa. El concepto de
Arquitectura Empresarial es utilizada para denotar el todo de una organización, incluyendo sus
sistemas de información, procesos e infraestructura. Grandes corporaciones pueden desarrollar

12
y mantener un conjunto de arquitecturas empresariales, por esto se tienen las bondades de
un marco de trabajo estándar que incentiva el reuso de modelos y diseños arquitectónicos.

5.2. Revisión sucinta sobre el lenguaje de arquitectura empresarial

5.2.1. Especificación de Archimate
Archimate define un marco de trabajo para el modelado de arquitecturas empresariales
incorporando un paradigma orientado al servicio que propone un principio organizativo en
términos del negocio, aplicación e infraestructura. Archimate provee una representación uni-
forme en términos de diagramas que describe la arquitectura empresarial y permite organizar
los diferentes dominios y sus relaciones y dependencias[10].

Figura 5.2: Metamodelos a diferentes niveles de especificidad

El “core” del lenguaje consiste en tres tipos primarios de elementos: elementos de estruc-
tura activa, elementos de comportamiento y elementos de estructura pasiva; los elementos de
estructura activa se definen como entidades que son capaces de desempeñar algún comporta-
miento; los elementos de comportamiento son definidos como unidades de actividad desempe-
ñadas por uno o mas elementos de estructura activa; los elementos de estructura pasiva son
definidos como los objetos en los cuales el comportamiento es realizado.

Figura 5.3: Estructura del Marco de Trabajo

En organizaciones cuya actividad depende intensamente de la información, los elementos

de estructura pasiva son usualmente objetos de información, pero también pueden represen-

13
tarse como objetos físicos. Estos son tres aspectos: una estructura activa (un sujeto), un
comportamiento (verbo) y una estructura pasiva (un objeto).

Figura 5.4: Conceptos clave de Archimate

También se presenta una distinción entre una vista interna y una vista externa en los
sistemas, en el aspecto comportamental se define la vista externa por medio de un servicio:
una unidad de funcionalidad que un sistema expone a su entorno. Los servicios son accesibles
mediante interfaces, como puntos de acceso donde uno o mas servicios son expuestos al entorno
(todo lo que se encuentra externo al sistema).
El comportamiento puede ser realizado por un elemento estructural único (actor, rol,
componente), o de varios elementos estructurales, esto se conoce como una colaboración; se
define como una agrupación temporal de dos o más elementos estructurales, que trabajan
juntos para desempeñar un comportamiento colectivo; una interacción esta definida como
una unidad de comportamiento realizado desempeñado por una colaboración.
Archimate también contiene una especificación para las relaciones entre los elementos,
adoptados desde la especificación UML 2.0.

Figura 5.5: Correspondencia entre Archimate y TOGAF

14
 La estructura general del lenguaje de Archimate define tres capas primarias basadas en
los componentes: La capa de negocio, que ofrece productos y servicios a clientes externos,
los cuales son realizados en la organización en procesos de negocio por medio de los actores.
La capa de aplicación que soporta la capa de negocio con servicios de aplicación realizados
por aplicaciones de software. y la capa de tecnología, que ofrece servicios de infraestructura,
almacenamiento, comunicación requerida para la ejecución de las aplicaciones. La estructura
general dentro de cada capa es similar, mismos tipos de conceptos y relaciones son usadas
pero su granularidad y semántica cambian.

Capa de Negocio Los aspectos de estructura activa en la capa de negocio refiere a la estruc-
tura estática de una organización, en términos de las entidades de conforman la organización
y sus relaciones. Las entidades activas son sujetos (actores de negocio o roles de negocio) que
realizan un comportamiento como procesos de negocio o funciones. El concepto de interfaces
de negocio son utilizadas para especificar ubicaciones (físicas o lógicas) o canales donde los
servicios que un rol ofrece al entorno pueden ser accedidos, ejemplo, el mismo servicio puede
ser ofrecido a a un numero diferente de interfaces, (email, teléfono o a través de Internet).

Figura 5.6: Metamodelo Capa de negocio

Capa de Aplicación El concepto principal de estructura activa para la capa de aplicación

es el componente de aplicación. Este concepto es utilizado para modelar cualquier entidad
estructura en la capa de aplicación, no únicamente componentes reusables pueden ser parte
de una o más aplicaciones, sino también aplicaciones de software completas o sistemas de
información. Las interfaces de aplicación son los canales lógicos por los cuales los servicios de
un componente pueden ser accedidos. El concepto de colaboración de aplicación es definido
como un conjunto de componentes que realizan interacciones.

15
 Figura 5.7: Metamodelo Capa de Aplicación

Capa de Tecnología El concepto principal de estructura activa para la capa de tecnología

es el nodo, este concepto es utilizado para modelar entidades estructurales en esta capa, su
comportamiento es modelado a través de relaciones explicitas en conceptos comportamentales.
La interfaz de infraestructura es la ubicación lógica donde los servicios de infraestructura son
ofrecidos por un nodo y pueden ser accedidos por otros nodos o componentes de aplicación de
la capa de aplicación. Los nodos pueden ser dispositivos o sistemas de software y se pueden
relacionar a través de rutas de comunicación (realizadas físicamente mediante redes).

Figura 5.8: Metamodelo Capa de Tecnología

Extensión Motivacional Los conceptos motivacionales son usados para modelar las mo-
tivaciones o razones, que se encuentran debajo del diseño o el cambio de alguna arquitectura
empresarial, estas motivaciones influencian, guían y restringen el diseño. Se utilizan conceptos
como el stakeholders o involucrados, los manejadores o misión del stakeholder, las valoraciones,
determinadas mediante el análisis de las oportunidades, amenazas, fortalezas y debilidades y
el objetivo al cual se persigue disminuir esa amenaza o aumentar esa fortaleza.

16
 Figura 5.9: Metamodelo Extensión Motivacional

Extensión de Implementación y migración El concepto central comportamental es un

paquete de trabajo, un paquete de trabajo es claramente definido con fechas iniciales y finales,
una definición concreta de los objetivos y resultados. Para este modelo se tienen en cuenta los
entregables, la Platea y la brecha.

Figura 5.10: Metamodelo de Extensión de Implementación y migración

La extensión motivacional abarca el elemento que provee el contexto o la razón detrás de

la arquitectura de una empresa, reconoce los conceptos de stakeholders y manejadores, las
metas de los stakeholders deben ser traducidos dentro de la arquitectura de la organización y
esta debe reflejar como los requerimientos son realizados por servicios, procesos y aplicaciones
de software en las operaciones diarias. Los elementos “core” de la arquitectura se encuentran
relacionados con elementos motivacionales por medio de los requerimientos, una relación de
ejemplo entre el meta modelo y la extensión motivacional es que un actor de negocio puede
ser asignado a un stakeholder, que puede ser visto como un rol motivacional.

Puntos de Vista Los puntos de vista permiten definir arquitecturalmente los conceptos,
modelos, técnicas de análisis y visualización con el propósito de comunicar e informar aspectos
de la arquitectura, en términos de decisión, información o mostrar detalles para todos los
stakeholders.

17
 Figura 5.11: Clasificación de puntos de vista de la arquitectura empresarial

La Metodología de Desarrollo Arquitectónico (ADM) es complementada con el lenguaje

Archimate, que provee un conjunto de conceptos independientes, y una representación gráfica
para construir modelos integrados consistentes de la arquitectura en todas sus fases. Fig. 5.5

5.2.2. Metodología de desarrollo ágil Scrum

Un proyecto basado en este marco de trabajo involucra un trabajo colaborativo para crear
un nuevo producto definido a través de una visión del proyecto y entregables que aportan valor
rápidamente durante su duración. La fuerza clave esta en el uso de pequeños equipos motivados
concentrados en realizar tareas cortas concentradas durante ciclos de trabajo denominados
Sprints.[11]

Figura 5.12: Metodología del proyecto bajo Scrum

El ciclo comienza con una reunión con los stakeholders, durante la cual la visión del pro-
yecto es creada. El dueño del producto (product owner) desarrolla un cronograma (Product
backlog) el cual contiene una lista de requerimientos del negocio y del proyecto escritas en
forma de historias de usuario. Cada sprint o entregable comienza con una reunión de pla-
neación durante la cual las historias de usuario se priorizan y se incluyen en el entregable.
Éste generalmente dura entre una y seis semanas e involucra al equipo de trabajo para crear
incrementos de ese producto, cada integrante puede tener tareas asignadas con tiempos en
horas para una o más historias de usuario que se encuentren en ese sprint.

18
 Durante el sprint, se desarrollan reuniones diarias que son conducidas por los miembros
del equipo para discutir el progreso diario. Al final del sprint, se realiza una reunión durante
la cual el dueño del producto y los interesados más relevantes evalúan una demostración del
entregable. El dueño del producto acepta el entregable solo si cumple con los criterios de
aceptación definidos en las historias de usuario. El ciclo del sprint termina con una reunión
de retrospectiva donde el equipo discute las formas de mejorar el proceso y el desempeño de
la propia metodología para el siguiente sprint.[11]
El lanzamiento del producto (release) concluye con la ejecución de varios sprints que en-
tregan valor agregado al producto final. El lanzamiento del producto se encuentra sujeto a la
visión del proyecto inicial y los requerimientos de todas las historias de usuario. Nuevos lanza-
mientos sobre el mismo producto pueden darse a partir de nuevas visiones del producto actual
y agregación o modificación de requerimientos del dueño del producto y los stakeholders.[11]

Figura 5.13: Fases de un proyecto usando Scrum

19
5.3. Marco Conceptual
5.3.1. Autoevaluación Institucional
Los mecanismos de evaluación institucional permiten medir el nivel de ejecución de los
planes, proyectos y programas que las entidades tienen previsto en sus objetivos organizacio-
nales, en este proceso se tienen en cuenta una serie de etapas que identifican la autoevaluación
institucional[5]:

Sensibilización sobre el proceso de autoevaluación por medio de actividades y comuni-

cación sobre su importancia.

El uso de herramientas metodológicas que permitan medir con exactitud el estado in-
terno de la organización con base a indicadores específicos y el soporte de auditorías
internas.

El análisis de los resultados de la autoevaluación y la toma de decisiones orientadas a

la realización de planes de mejoramiento para los hallazgos encontrados.

También se definen una serie de involucrados en este proceso:

El Nivel Directivo. “Debe evaluar los avances y grado de cumplimiento del plan in-
dicativo, toma las decisiones correspondientes y da las orientaciones y lineamientos a
seguir por parte de las áreas de la organización para garantizar el logro de los resultados
previstos”[7].

Todos los niveles y áreas de la organización: “Evalúan periódicamente los avances de

sus planes de acción y deben reportarlos a la Oficina de Planeación, así como también
participar en los mecanismos que la oficina de control interno disponga para la ejecución
de la autoevaluación”.

La oficina de Control Interno o quien haga sus veces: “Debe evaluar el sistema de control
interno de la entidad, con énfasis en la existencia, funcionamiento y coherencia de los
componentes y elementos que lo conforman y presentar informes a la Dirección y al
Comité de Coordinación de Control Interno de la entidad”.

5.3.2. Contexto de la autoevaluación institucional en el MECI

La estructura del Modelo de Estándar de Control Interno consta de tres módulos prima-
rios, El modulo de Control de Planeación y Gestión, El modulo de Control de Evaluación y
seguimiento y un Eje transversal de Información y comunicación[7].
El objetivo del modulo de Evaluación y seguimiento, es establecer un proceso de mejo-
ramiento continuo en la entidad, por medio de valoraciones a nivel de planes, programas y
proyectos, con el propósito de detectar debilidades o falencias dentro de los mismos, y pro-
yectar acciones encaminadas a contribuir con el logro de la misión y visión de la entidad.
Bajo el esquema general del Modulo de Control de Evaluación y Seguimiento se mane-
jan tres componentes: La autoevaluación institucional, la auditoría interna y los planes de
Mejoramiento.

20
 El componente de autoevaluación institucional se enfoca de forma general tomando en
cuenta la participación de todos involucrados dentro de la entidad categorizado según los pro-
cesos, programas o proyectos y es vista como un proceso que se debe realizar periódicamente
con el fin de entregar resultados sobre la gestión. Esto conlleva un conjunto de beneficios para
la entidad como estimular el trabajo en equipo, aumentar la confianza entre los funcionarios,
generar un compromiso y cultura por la autoevaluación, y además proveer mecanismos confia-
bles para determinar el estado del control y de los riesgos que a su vez provee de información
a la alta dirección.
El siguiente esquema representa el contexto general que se aborda dentro del MECI para
el componente de Autoevaluación institucional[7].
Modelo Estándar de Control Interno.

• Módulo Control de Evaluación y Seguimiento.

◦ Componente Autoevaluación Institucional.
 Autoevaluación del Control y Gestión.

Enfoques de Autoevaluación - Encuestas y cuestionarios

Existen varias herramientas utilizadas en la autoevaluación institucional inicialmente defi-
nidos por el Departamento Administrativo de la Función Pública que han sido implementados
en la guía de Autovaloración del Control,[4] entre los cuales se destacan:
Matriz de riesgo y control.

Encuestas y cuestionarios.

Entrevistas estructuradas.

Entrevistas de Autovaloración.

Talleres de Autovaloración.
El enfoque de Encuestas y cuestionarios es una herramienta empleada en entidades cuando el
nivel de funcionarios es bastante numeroso para la realización de Entrevistas estructuradas y
el alcance de la autoevaluación es amplio, igualmente si la alta dirección desea minimizar el
tiempo para la obtención de la información. Bajo este enfoque no se requiere experiencia por
parte de los evaluadores y se reduce el numero de reuniones y coordinación para obtener los
resultados.

5.3.3. Metodología estándar para la realización Autoevaluación Institucional

La siguiente metodología es una descripción general del proceso de autoevaluación, dicha
metodología cuenta con una serie de pasos secuenciales que abarcan desde la planeación e
intencionalidad de realizar hasta el análisis de resultados por parte del organismo de control[5]:
1. Iniciar una fase de sensibilización sobre el proceso a toda la organización por medio de
juntas, envío de información y realimentación con respecto a la evaluación realizada en
el periodo anterior que permita establecer planes de mejora del proceso para el nuevo
periodo.[7]

21
 2. Definir la organización de la autoevaluación, bien sea por procesos, por áreas o por
proyectos, luego definir el cronograma de trabajo para la aplicación de la encuesta.
3. Aplicar el enfoque de encuesta teniendo en cuenta la organización y el numero de per-
sonas involucradas, el formato de la encuesta lleva el conjunto de preguntas especificas,
una escala de valoración, observaciones, evidencias de cumplimiento y una oportunidad
de mejora, (estos dos últimos campos son opcionales y dependen de la organización de
la evaluación).[5]

Las preguntas se encuentran orientadas a la organización de la evaluación, bien

sea por procesos o por áreas, un conjunto de preguntas pueden ser evaluadas para
todos los procesos y para procesos específicos.
La escala definida por el estándar es de tipo cualitativo para el evaluador: No
sabe, No se cumple, Se cumple insatisfactoriamente, Se cumple aceptablemente, Se
cumple en alto grado, Se cumple plenamente. y de tipo cuantitativo para el analista
de cero a cinco respectivamente.

4. Tabular la información obtenida de las encuestas, realizar la valoración de forma ge-

neral y entregar los resultados al representante de la Dirección, junto con las acciones
correctivas o de mejoramiento. (para este procedimiento se toma en cuenta el anexo 2
del MECI 2005, para tabulación de encuestas e interpretación de resultados).
5. Someter a consideración del comité de coordinación de control interno los resultados y
las acciones correctivas o de mejoramiento.
6. Analizar los resultados de la Autoevaluación y adoptar las acciones correspondientes
que garanticen mantener la orientación de la entidad publica hacia el cumplimiento de
sus objetivos institucionales.

5.4. Marco legal

Existe un fundamento legal que soportan los mecanismos de Autocontrol, Autorregulación
y Autogestión dentro de las áreas de Control Interno, Así como su reconocimiento y las
funciones que éstas deben cumplir dentro de las entidades de carácter publico las cuales se
rigen a nivel nacional.
Ley 87 de 1993: Se establecen normas para el ejercicio del control interno en las entidades
y organismos del estado; entre los objetivos y aspectos del sistema de control interno se
destacan[1]:

• Garantizar la correcta evaluación y seguimiento de la gestión organizacional.

• Establecimiento de sistemas modernos de información que faciliten la gestión y el
control.
• Organización de métodos confiables para la evaluación de la gestión.

Ley 489 de 1998: El capitulo IX establece la creación del Sistema General de Información
Administrativa del Sector Público, y establece evaluaciones periódicas por los comités
de desarrollo administrativo que evalúen los sistemas de información actuales que se
encuentren relacionados con la evaluación de la gestión pública.[2]

22
Decreto 2145 de 1999: define el concepto de evaluación a la luz de la norma colombiana:[3]

• Evaluación. Este componente es el complemento fundamental de la planeación,

consistente en la verificación y seguimiento a la gestión dándole dinamismo al
proceso planificador y facilitando la retroalimentación de las actividades, la toma
de decisiones y la reorientación de las acciones para garantizar el logro de los
resultados previstos.

Decreto 1599 DE 2005 - Por el cual se adopta el Modelo Estándar de Control Interno
para el Estado Colombiano. Define formalmente el componente de la autoevaluación
institucional para el MECI:

• Autoevaluación a la gestión: Elemento de control, que basado en un conjunto de

indicadores de gestión diseñados en los planes y programas y en los procesos de la
entidad pública, permite una visión clara e integral de su comportamiento, la obten-
ción de las metas y de los resultados previstos e identificar las desviaciones sobre
las cuales se deben tomar los correctivos que garanticen mantener la orientación
de la entidad pública hacia el cumplimiento de sus objetivos institucionales.

Manual de Implementación MECI 2005 y MECI 2014. El manual de Implementación

MECI, es una metodología estándar que sirve como apoyo de las leyes y decretos anterior-
mente descritos y establece los lineamientos de forma practica para la implementación
en los sistemas de control interno. Es la hoja de ruta para la realización de este proyecto,
este incluye:

• Proceso de planeación para implementar el MECI en una organización en etapas

definidas.
• Proceso de actualización del modelo en caso de que la organización ya tenga una
implementación de MECI.
• Descripción de los Subsistemas y elementos del control, Estructura, roles y respon-
sabilidades.
• Definición del proceso de autoevaluación en el enfoque de encuesta (tipologías
de encuesta, banco de preguntas base, determinación del tamaño de la muestra,
procedimiento para la tabulación de encuestas e interpretación de resultados).
• Normograma Sistema de Control interno.

23
6. Aspectos metodológicos
6.1. Tipo de estudio
El presente trabajo de investigación busca realizar una recopilación de los diferentes ele-
mentos que caracterizan el problema dentro del contexto de las organizaciones de carácter
descentralizado, para esto se identifican los hechos o las causas del problema y sus consecuen-
cias y las situaciones que suelen presentarse a fin de mitigar el problema. Otros hechos que
inciden pero que no son visibles deben determinarse para abordar el problema en su totalidad,
dejando un precedente que pueda ser el insumo clave para futuras investigaciones dentro del
contexto planteado.
El tipo de investigación sobre la cual se determinará el nivel de profundidad y la forma en
que se abordaŕa el problema es de tipo descriptivo, realizando una previa caracterización de
todos los hechos y situaciones presentadas dentro de un entorno empresarial y a partir de la
experiencia adquirida en la realización del proceso, es de resaltar que también se deben obser-
var las situaciones y comportamientos de las personas involucradas cuando están realizando el
proceso y que actitudes se evidencian frente a este. La observación juega un papel importante
puesto que permitirá describir con claridad todo el flujo del proceso, los actores externos a
este y la forma en que los involucrados, que son los principales gestores de comunicación y
ejecutores puedan resultar beneficiados.
Previas investigaciones se abordan acerca de las técnicas para la medición de objetivos
empresariales y además estándares conocidos para este proceso, por tanto los antecedentes
presentados sirven como apoyo para esta investigación y permitirán ampliar las bases y los
fundamentos teóricos de éste estudio.
La recolección de información se centrará en la norma Colombiana como uno de los ejes
centrales para la creación de la herramienta, debido a que el Modelo Estándar de Control
Interno tiene su fundamento en los trabajos realizados y la experiencia de la gestión de la
administración pública a lo largo de las ultimas tres décadas en el estado Colombiano de
todas las entidades de carácter descentralizado que hacen parte de este; y cuyas experiencias
y prácticas son recopiladas en sus manuales respectivos y además exigidas por el fundamento
legal que le precede. La metodología del componente a analizar se encuentra soportado y
documentado en gran medida y el conocimiento acerca de este se amplia con nuevas versiones
del estándar.
Se espera que las evidencias y las situaciones que se presenten luego de que se implemente
en una organización de este tipo y con base en la hipótesis planteada puedan ser la base para
el inicio de investigaciones futuras que generen un conocimiento explicativo.

6.2. Método de investigación

Los métodos de investigación para el desarrollo del proyecto serán a partir de la obser-
vación y la inducción.
Se parte de la observación como método de investigación sobre el fundamento de la ex-
periencia personal y de la observación participando del proceso, Las técnicas de recolección
de información apropiadas podrán obtener información acerca de los involucrados de todo el
proceso y los especialistas que conocen de forma particular la implementación del estándar.
Esto conformará una caracterización de la situación concreta y de los hechos particulares que
se deberán abordar.

24
 Estas características particulares podrán analizarse desde el marco teórico general y del
marco legal definido empleando al deducción con el fin de establecer sus relaciones con la
información adquirida y la generación de un prototipo concreto que se encuentre orientado a
una realidad particular.
Posibles lineas de investigación de interés en la que tendría cabida este proyecto de inves-
tigación:

Ingeniería de software.

Mecanismos de medición en gestión empresarial.

Arquitectura de Software.

Ingeniería de Requerimientos.

6.3. Fuentes y técnicas para la recolección de la información

6.3.1. Fuentes primarias
Las fuentes primarias para la recolección de la información parten de una observación
inicial dentro del proceso en una entidad particular y las actividades que se realizan a cabo,
identificando información relevante para el estudio. Luego se contrasta la información obtenida
con la experiencia personal para obtener un cuerpo conceptual inicial que será refinado con
las técnicas posteriores:

Entrevistas con los especialistas del área de control interno de la entidad.

Entrevistas con los especialistas del área de sistemas de la entidad.

Entrevistas con los involucrados en el proceso, evaluadores y entes internos.

Encuestas iniciales que indiquen las actitudes sobre el proceso.

Información que se desea obtener

Identificar los stakeholders, participantes y entes externos que influyen en la realización
del proceso.

Flujo del proceso y todas las tareas realizadas durante la realización de la autoevaluación.

Herramientas actuales utilizadas: descripción de las herramientas, el uso y la forma en

que se emplean.

Cronograma del proceso, vigencia y objetivo de los resultados, tipo de resultado que se
desea obtener y su uso en los informes de control interno.

Herramientas tecnológicas disponibles para la implementación de la herramienta, y nivel

de conocimiento de los usuarios acerca de las tecnologías de la información.

Actitudes sobre el proceso: nivel de aceptación del enfoque de encuesta, motivación para
realizar la evaluación, causas de rechazo al proceso e incomodidades realizándola.

25
A partir de la información obtenida se busca conocer aspectos no considerados inicialmente
y otros hechos que puedan servir para identificar situaciones subyacentes del problema de
investigación.

6.3.2. Fuentes secundarias

La recopilación de la información secundaria parte de tres fuentes secundarias clave en
la realización del estudio, la primera corresponde a toda la información relacionada con el
proceso y el moldeamiento de los requerimientos dentro del entorno planteado de forma que
la información obtenida se encuentre relacionada con el contexto de la gestión publica. Esto
incluye:
Normas vigentes y actualizaciones sobre el estándar que se rige actualmente.
Información en artículos, revistas y casos de estudio de medición de objetivos empresa-
riales.
Otros estándares encontrados relacionados con el objeto de estudio.
La segunda fuente principal corresponde a la información que se debe obtener con el fin de
realizar la definición de la arquitectura empresarial del proceso, es decir, documentación exis-
tente y practicas acordes para este problema particular a partir de la consulta de estándares y
artículos disponibles en bases de datos académicas de la Universidad Distrital Francisco José
de Caldas. Para esto se busca:
Seleccionar la Metodología para levantamiento de requerimientos indicada.
Definición de la arquitectura empresarial orientada al proceso.
La tercera fuente principal corresponde a la búsqueda de información sobre la metodología
para el desarrollo de software especifico consistente al problema planteado:
Realizar consultas bibliográficas sobre casos de estudio acerca de las metodologías de
desarrollo de software y el ciclo de vida a tener en cuenta.
Las tres fuentes de información secundaria se encontrarán orientados al problema de investi-
gación y sus objetivos específicos. Además se busca que sirvan como apoyo en la forma en la
que se va a realizar la solución del problema, y mostrar el aprendizaje obtenido en el desarrollo
del proyecto en las practicas utilizadas.

6.4. Tratamiento de la información

Para el tratamiento de la información obtenida tanto de fuentes primarias como de se-
cundarias, es necesario aplicar técnicas de tratamiento de información especificas para cada
caso:
Fuentes primarias de Información: Para el caso de las entrevistas se procede a consolidar
la información y analizarla y representar el conocimiento obtenido a través de modelos
visuales como mapas conceptuales y documentos de tipo descriptivo y posteriormente
expresar las necesidades especificas en una sección de requerimientos formal. En el caso
de las encuestas se debe consolidar la información y utilizar técnicas estadísticas de
tabulación y representarla en los gráficos correspondientes.

26
 Con la información obtenida a partir de las fuentes secundarias relacionadas de consultas
acerca de la metodología de desarrollo de software, se pretende establecer los lineamien-
tos y directrices del desarrollo, con la definición de las tareas especificas a realizar y un
cronograma orientado al desarrollo del prototipo.

Se plantea que el tratamiento de la información y la obtención de las fuentes de información

se establezcan tanto al inicio como en toda la duración del proyecto de investigación, es decir
las actividades de recolección y el tratamiento de la información deben continuarse realizando
hasta que la definición de todo el contexto del proyecto se encuentre definido en su totalidad.

27
Parte II
Desarrollo de la investigación
7. Análisis de la información
7.1. Entrevistas
Para esta investigación, se optó por realizar entrevistas personalizadas debido a que repre-
sentan la forma más acertada de conocer el problema y los lineamientos que la solución debe
tener en cuenta. Al ser una solución orientada a una herramienta de enfoque de encuestas no
se opta por recolectar información a través de encuestas.

Realización de entrevistas
Representantes del proceso en la entidad
Especialistas de control interno
Grupo objetivo
Especialista del área de sistemas
representantes de los procesos misionales, estratégicos,
de apoyo y de evaluación y seguimiento de la entidad.
Universo Instituto para la protección de la niñez y la juventud IDIPRON
Forma de contacto Entrevista cara a cara
Muestra 7 entrevistas
Tipo de pregunta Todas las preguntas Abiertas
Forma de análisis Identificar a criterio del entrevistador las respuestas
relacionadas al planteamiento del problema.

Cuadro 1: Ficha técnica realización de entrevistas

A continuación se describen los resultados de las entrevistas con los involucrados del
proceso:

Para ver la estructura de la entrevista remitirse al anexo 1

Observaciones de las entrevistas con los especialistas del área de control interno
de la entidad:

Se requiere una herramienta que otorgue resultados al momento que se desee consultar
bien sea parciales o consolidados al final del proceso.

Se requiere que pueda utilizarse a través de las vigencias.

Es necesario que se de apoyo al proceso de información y seguimiento informando a los

usuarios el objetivo de la autoevaluación.

Es necesario que los informes sean de utilidad para el informe pormenorizado de control
interno, entes de control y la misma entidad en planes de mejoramiento para la viegencia
posterior.

28
Observaciones del especialista del área de sistemas de la entidad:

La herramienta debe ser acorde visualmente a los demás sistemas de información exis-
tentes.

Se debe tener en cuenta la plataforma tecnología existente la momento de la fase de

implementación.

Es recomendable que se utilicen tecnologías libres apoyando Política de Promoción y

Uso del Software libre. Acuerdo 279 de 2007

Observaciones de los involucrados en el proceso, evaluadores y entes internos:

Actitudes del proceso: Los involucrados desconocen los resultados al final del proceso y
no son informados de por que se realiza este tipo de autoevaluación.

Se desconoce el modelo estándar de control interno y los elementos a evaluar.

Actualmente se consolidan encuestas en formato excel lo que hace que el proceso tome
más tiempo y cause menor motivación para realizar la evaluación.

Información relevante obtenida para la identificación del problema

Identificar los stakeholders, participantes y entes externos que influyen en la realización

del proceso:

• Toda la organización hace parte del proceso, juegan el papel de evaluadores de sus
propios procesos y des los cuales se involucran.
• Los entes externos como entes de control son informados a través del área de control
interno

Flujo del proceso y todas las tareas realizadas durante la realización de la autoevaluación.

• Todos los procesos de la entidad se encuentran involucrados de forma que contri-

buyen al cumplimento de la misión y los objetivos organizacionales: La evaluación
es transversal a todos los procesos y tiene en cuenta aspectos relacionados de los
cuales se dan una valoración por parte de los involucrados del proceso que gestiona
y de los involucrados que colaboran.

Herramientas actuales utilizadas: descripción de las herramientas, el uso y la forma en

que se emplean:

• Herramientas ofimáticas, uso de correo electrónico para el envío de la información.

• Manuales y documentación digital de los procesos de la entidad para la formulación
de preguntas.

Cronograma del proceso, vigencia y objetivo de los resultados, tipo de resultado que se
desea obtener y su uso en los informes de control interno.

29
 • Se realiza en vigencia anual, se requiere que los resultados contribuyan a la creación
actividades que mejoren las falencias en los procesos para la vigencia siguiente
de acuerdo a los planes de mejoramiento, los resultados deben presentarse a la
dirección general.

Herramientas tecnológicas disponibles para la implementación de la herramienta, y nivel

de conocimiento de los usuarios acerca de las tecnologías de la información.

• Los usuarios conocen las tecnologías de información como navegadores web, he-
rramientas ofimáticas. Desde la entidad de tiene acceso a internet y equipos de
computo.

Actitudes sobre el proceso: nivel de aceptación del enfoque de encuesta, motivación para
realizar la evaluación, causas de rechazo al proceso e incomodidades realizándola.

• Incomodidades por tener que descargarla manualmente, guardar y enviarla por

correo electrónico sin notificación de recibido. Desgaste para consolidar y tabular
las encuestas.

30
8. Diseño de la Arquitectura Empresarial
El diseño de la arquitectura empresarial orientada al proceso de autoevaluación institu-
cional comprende los puntos de vista del lenguaje de descripción arquitectónica Archimate,
punto de vista del negocio, aplicación, tecnológico, extensión motivacional y extensión de im-
plementación y migración. Cada punto de vista es una descripción detallada del proceso de
la organización definiendo el producto Valueme, Herramienta de apoyo para la realización de
la autoevaluación institucional basada en el MECI.

9. Punto de vista del negocio

El punto de vista del negocio trata acerca de procesos de negocio, servicios, funciones y
eventos en unidades de negocio. Esta capa “ofrece productos y servicios a clientes externos,
quienes son realizados en la organización por procesos de negocio desempeñados por actores
de negocio y sus roles”.

9.1. Punto de vista de la organización

El punto de vista de la organización se enfoca en la organización interna de una compañía,
departamento o entidad organizacional, es útil para identificar competencias, autoridad y
responsabilidades en una organización.[10]

Figura 9.1: metamodelo organización

Punto de vista de la organización

Se presentan los actores de la organización organizados en procesos, todos los involucrados
se organizan según el proceso donde participan en la entidad, actores de procesos estratégicos,
misionales, de apoyo y de seguimiento, y las localizaciones donde estos se encuentran.

31
 Figura 9.2: modelo organización

9.2. Punto de vista de cooperación de actor

El punto de vista de Actor cooperación se enfoca en las relaciones entre los actores y su
entorno, es útil determinando dependencias externas y colaboraciones y muestra la cadena de
valor o red donde el actor opera.
Un uso importante es mostrar como un un numero de actores de negocio y/o compo-
nentes de aplicación realizan juntos un proceso de negocio, en esta vista, se pueden mostrar
interacciones entre actores y roles.[10]

32
 Figura 9.3: metamodelo cooperación de actor

Punto de vista de cooperación de actor

En el proceso de la autoevaluación institucional, todos los actores tienen un rol como
evaluadores de cada uno de sus procesos; el actor de seguimiento, quien es el responsable
de presentar los indicadores tiene el rol de ser el analista del proceso, juntos conforman la
colaboración denominada “equipo de evaluación”. la interacción entre ambos roles se presen-
ta mediante la interfaz del portal web, que provee las interfaces de correo electrónico y el
repositorio documental donde se almacenan las evaluaciones.

33
 Figura 9.4: modelo cooperación de actor

9.3. Punto de vista de función de negocio

El punto de vista de función de negocio muestra las funciones principales de negocio de una
organización y sus relaciones en términos del flujo de la información, valor o bienes entre ellos.
Las funciones de negocio son usadas para representar los aspectos mas estables en términos de
las actividades primarias que desempeña, independientemente de los cambios organizacionales
o desarrollos tecnológicos. Por lo tanto, la arquitectura de funciones pueden ser similares en
compañías con actividades del mismo mercado. Esto provee una visión de las operaciones
generales de la compañía, y puede utilizarse para identificar competencias necesarias o la
estructura de la organización de acuerdo a sus actividades principales.[10]

Figura 9.5: metamodelo función de negocio

34
Punto de vista de función de negocio
Las funciones de negocio realizadas por el analista son realizar las actividades de sensibi-
lización, que incluye crear el cronograma de actividades del proceso. consolidar los resultados
de las encuestas y realizar el análisis de los resultados para presentar el informe a la alta
dirección. Las funciones de negocio del evaluador corresponden a completar la evaluación.

Figura 9.6: modelo función de negocio

9.4. Punto de vista de proceso de negocio

El punto de vista de proceso de negocio es usado para mostrar una estructura de alto nivel
y composición entre uno o mas procesos de negocio, incluye conceptos como[10]:

Los servicios que un proceso de negocio ofrece al mundo exterior mostrando como un
proceso contribuye a la realización de los productos

La asignación de los procesos de negocio a los roles quienes dan la visión de las respon-
sabilidades de los actores asociados.

La información utilizada por los procesos de negocio.

35
 Figura 9.7: metamodelo proceso de negocio

Punto de vista de proceso de negocio

El proceso de negocio macro es la autoevaluación institucional, este realiza un servicio de
negocio para presentar los resultados en tiempo real. Los subprocesos son la realización de la
encuesta, que parte de un evento como la solicitud de la evaluación por parte del director del
proceso, la consolidación y tabulación de los resultados y su posterior análisis, el evento de
finalización es la presentación del informe con los indicadores de gestión obtenidos.

Figura 9.8: modelo proceso de negocio

36
9.5. Punto de vista de cooperación de proceso de negocio
El punto de vista de cooperación de proceso de negocio es utilizado para mostrar la relación
entre uno o más procesos de negocio con cada uno y/o con su entorno. Provee las dependencias
entre procesos de negocio. Sus características principales son[10]:

Presenta relaciones causales entre los procesos de negocio de la empresa.

Muestra una correlación entre procesos de negocio hacia funciones de negocio.

Muestra la realización de servicios por procesos de negocio.

Uso de datos compartidos.

Figura 9.9: metamodelo de cooperación de proceso de negocio

Punto de vista de cooperación de proceso de negocio

Los subprocesos de negocio de la autoevaluación institucional, realización de la encuesta
y análisis de resultados se encuentran asociados a dos objetos de negocio: la evaluación,
representada por el formulario de la encuesta, y el resultado, representado por un informe
con indicadores, ambos procesos son realizados por dos roles, el evaluador y el analista en la
localización del dominio de despliegue del producto.

37
 Figura 9.10: modelo de cooperación de proceso de negocio

9.6. Punto de vista de producto

El punto de vista del producto representa el valor que estos productos ofrecen al cliente
o las las partes externas involucradas y muestra la composición de uno o más productos en
términos de los servicios, contratos o acuerdos. Puede ser utilizado para mostrar las interfaces
a través de las cuales este producto es ofrecido, y los eventos asociados con el producto. Este
punto de vista es usado típicamente en el desarrollo para diseñar un producto a partir de los
servicios nuevos que deben ser creados, dándole al cliente el valor que espera de él.[10]

38
 Figura 9.11: metamodelo de producto

Punto de vista de producto

El producto ValueMe (Valórame), representa la rapidez, seguridad y comodidad para
realizar el proceso de autoevaluación institucional, su valor está en que puede gestionar la
recepción, consolidación y tabulación de encuestas automáticamente, y presentar informes
en tiempo real, aún si la todas las evaluaciones por parte de los involucrados no se hayan
realizado. Además permite gestionar el cronograma general del proceso y comunicar a todos
los evaluadores información mediante correo electrónico y noticias en el portal a través de
toda la duración del proceso.

39
Figura 9.12: modelo de producto

40
10. Punto de vista de la aplicación
El punto de vista de la aplicación trata acerca de las aplicaciones de software que so-
portan los componentes del negocio con servicios de aplicaciones, componentes de aplicación
reusables, e interfaces de comunicación para estos componentes.

10.1. Punto de vista de comportamiento de aplicación

El punto de vista de comportamiento de aplicación describe el comportamiento interno de
una aplicación, es útil para diseñar el comportamiento principal de aplicaciones o componentes
e identificar la superposición funcional entre diferentes aplicaciones.[10]

Figura 10.1: Metamodelo de comportamiento de aplicación

Modelo de comportamiento de aplicación

Se presentan un conjunto de componentes candidatos:

El gestor de la evaluación que proveerá la configuración para los módulos, componentes

y elementos a los que pertenece la evaluación, el banco de preguntas y los tipos de
evaluaciones, así como también el almacenamiento de las evaluaciones y su consulta.

El analizador de resultados debe tabular los resultados y proveer los indicadores resul-
tado de todas las evaluaciones realizadas.

El componente de comunicación debe ser configurable para presentar la información

a los evaluadores acerca del proceso y enviar los informes de resultados a todos los
involucrados.

El componente autenticador de usuarios debe proveer información sobre los evaluadores

y analistas y denegar o permitir accesos a llenar una evaluación según el cronograma de
actividades.

41
 El componente de organizador de cronograma debe configurar los tiempos y el periodo
de las actividades, como por ejemplo las fechas para presentar la evaluación y generar
los resultados.

ValueMe representa el componente de acceso que permite configurar y comunicarse con

los demás componentes.

Figura 10.2: Modelo de comportamiento de aplicación

10.2. Punto de vista de cooperación de aplicación

El punto de vista de cooperación de aplicación describe las relaciones entre los componentes
en términos de flujo de información o en términos de los servicios que estos proveen o usan.
este punto de vista también es usado para expresar la cooperación interna u orquestación de
servicios que juntos soportan la ejecución de un proceso de negocio.[10]

42
 Figura 10.3: Metamodelo de cooperación de aplicación

Modelo de cooperación de aplicación

En el punto de vista de cooperación de aplicación se presenta un modelo Front Office para
la interfaz de comunicación visible para el usuario final y Back Office que representará la
arquitectura en la que los componentes de aplicación van a estar localizados en el producto.

Figura 10.4: Modelo de cooperación de aplicación

10.3. Punto de vista de estructura de aplicación

El punto de vista de estructura de aplicación muestra la estructura de una o más apli-
caciones o componentes. Es útil para diseñar o entender la estructura de las aplicaciones o
componentes y la información asociada.[10]

43
 Figura 10.5: Metamodelo de estructura de aplicación

Modelo de estructura de aplicación

El punto de vista de estructura de aplicación muestra la comunicación entre cada uno de
los componentes a través de sus interfaces:

Gestor de la evaluación:

• Provee la evaluación realizada por el evaluador al analizador de resultados.

• Requiere de la configuración de la evaluación: Preguntas, categorías, parámetros
de evaluación de ValueMe para configurar las evaluaciones.
• Requiere del evaluador como información de registro de la evaluación del Autenti-
cador de usuarios.

Analizador de resultados:

• Provee los indicadores de resultados al componente de comunicación.

• Requiere de la evaluación del gestor en las evaluaciones para generar los indicadores
de resultados.

Autenticador de Usuarios:

• Provee los usuarios evaluadores, administradores y analistas al gestor de la evalua-

ción para la gestión de la evaluación.
• Requiere de las políticas de control de acceso del cronograma para permitir o
denegar accesos según los tiempos establecidos en el cronograma.

Comunicación:

• Provee notificaciones, información e indicadores de resultados acerca del proceso a

ValueMe y este a todos los involucrados (usuarios registrados).
• requiere de los indicadores de resultados sobre la evaluación del analizador de
resultados.

Organizador de cronograma:

44
 • Provee el control de acceso para los usuarios según los tiempos establecidos para
la evaluación, así como también las actividades se realizan en el proceso.

Figura 10.6: Modelo de estructura de aplicación

10.4. Punto de vista de Uso de aplicación

El punto de vista de aplicación describe como las aplicaciones son usadas para soportar
uno o más procesos de negocio, y como van a ser utilizadas por otras aplicaciones. Puede
ser utilizada en el diseño de una aplicación para identificar los servicios requeridos por los
procesos de negocio y otras aplicaciones, o en el diseño de procesos de negocio describiendo
los servicios que van a estar disponibles.[10]

45
 Figura 10.7: Metamodelo de uso de aplicación

Modelo de uso de aplicación

El punto de vista de uso de aplicación muestra la realización de los servicios de aplicación
propuestos: recepción de evaluaciones y presentación de informes, y como estos servicios de
aplicación son usados los procesos de negocio definidos y se definen los componentes candidatos
que realizan estos servicios de aplicación.

Figura 10.8: Modelo de uso de aplicación

46
11. Punto de vista Tecnológico
El punto de vista de infraestructura general, trata acerca del hardware y la infraestructura
de comunicación que soporta la capa de aplicación. Esta capa ofrece servicios de infraestruc-
tura requeridos para desplegar las aplicaciones realizadas en los ordenadores y los sistemas de
hardware y software.

11.1. Punto de vista de Infraestructura

el punto de vista de infraestructura contiene los elementos de software y hardware que so-
portan la capa de aplicación, como dispositivos físicos, redes o sistemas de software. (sistemas
operativos, bases de datos o middleware).[10]

Figura 11.1: Metamodelo de infraestructura

Modelo de infraestructura
En el punto de vista de la infraestructura se identifica la localización del sistema, que
será en el dominio de la compañía donde se despliega el producto, los nodos de software y
los dispositivos cliente soportados por la aplicación serán ubicados dentro de esta localización
fisicamente en la infraestructura que presente la entidad. El protocolo de comunicación entre
el cliente y el producto será a través de TCP/IP, implementando el protocolo de aplicación
http. Todos los dispositivos que dispongan de un navegador web y una conexión a internet
podrán acceder a la aplicación.

47
 Figura 11.2: Modelo de infraestructura

Especificaciones técnicas de infraestructura

Se cuenta con un servidor de email para el componente de comunicación, un servidor de
aplicaciones ejecutado bajo un Sistema Operativo anfitrión, un sistema gestor de bases de
datos NoSql y el producto de software.

Software Versión Descripción

Ubuntu Server 14.04 - 16.04 Sistema Operativo Anfitrión GNU/Linux
Apache Tomcat 7.0.55 Contenedor de Aplicaciones java basado en servlets
Zimbra Collaboration 8.6.0 Servidor de correo electrónico SMTP
MongoDB 3.2.4 DBMS NoSQL orientado a documentos.
ValueMe 1.0 Producto de software web a construir

Cuadro 2: Especificaciones técnicas de infraestructura

11.2. Punto de vista de uso de infraestructura

El punto de vista de uso de infraestructura muestra como las aplicaciones son soportadas
por la infraestructura de software y hardware: los servicios de infraestructura son entregados
por los dispositivos, los sistemas de software y redes son entregados a las aplicaciones. Este
punto de vista juega un rol importante en el análisis del rendimiento y la escalabilidad y
puede ser usado para determinar requerimientos de rendimiento y calidad en la infraestructura
basado en las demandas de las aplicaciones que la usan.[10]

48
 Figura 11.3: Metamodelo de uso de infraestructura

Modelo de uso de infraestructura

En este punto de vista se identifican los servicios de infraestructura principales que co-
rresponden al servicio de notificaciones, generar reportes, establecer tiempos de acceso a la
aplicación, y gestionar los usuarios. Cada uno de los servicios de infraestructura entrega con-
figuración y la funcionalidad requerida hacia los componentes de aplicación.

Figura 11.4: Modelo de uso de infraestructura

49
11.3. Punto de vista de Implementación y despliegue
El punto de vista de implementación y despliegue muestra como uno o más aplicaciones
son realizadas sobre la infraestructura. Esto implica el mapeo de aplicaciones (lógicas) y
componentes en artefactos (físicos). Esta vista juega un papel importante en el análisis del
rendimiento y la escalabilidad debido a la relación entre la infraestructura y el mundo lógico
de las aplicaciones.[10]

Figura 11.5: Metamodelo de implementación y despliegue

Modelo de implementación y despliegue

En este punto de vista, se muestra como todos los componentes son realizados por el nodo
de servidor de aplicaciones, el componente de comunicación va a ser realizado por el nodo
servidor de aplicaciones y tiene una relación de asociación con el nodo servidor de e-mail que
proveerá las configuraciones de software específico para el envío de notificaciones, resultados
e información sobre el proceso.

50
 Figura 11.6: modelo de implementación y despliegue

11.4. Punto de vista de Estructura de información

El punto de vista de estructura de información es comparable a los modelos tradicionales
creados en el desarrollo de la mayoría de sistemas de información, muestra la estructura de
información usada en la empresa o un proceso específico o aplicación en términos de los tipos
de datos o las estructuras de clases (orientado a objetos).[10]

Figura 11.7: Metamodelo de estructura de información

Modelo de Estructura de información

Los objetos de negocio descritos principales para este proceso son la evaluación, el resultado
y el cronograma de actividades, los objetos de aplicación son la evaluación concreta que es la
encuesta, el resultado representado en un indicador y el cronograma de actividades para cada
periodo de evaluación. La encuesta se encuentra asociada a un usuario, tiene un conjunto de
preguntas y puede pertenecer a un conjunto de categorías.

51
 Figura 11.8: Modelo de estructura de información

11.5. Punto de vista de realización de servicio

El punto de vista de realización de servicio es usado para mostrar como uno o mas servicios
de negocio son realizados por los procesos subyacentes (y algunas veces por componentes de
aplicaciones), forma un puente entre la vista de productos de negocio y la vista de procesos
de negocio.[10]

Figura 11.9: Metamodelo de realización de servicio

52
Modelo de realización de servicio
El punto de vista de realización del servicio muestra los procesos de negocio de la arqui-
tectura: realización de la evaluación, consolidación de la información y análisis de resultados
asignados a componentes de aplicación que serán de soporte para dichos proceso. Los procesos
de negocio son realizados de forma secuencial y la realización de todos proveen los servicios
de negocio definidos.

Figura 11.10: Modelo de realización de servicio

11.6. Punto de vista de Capas

El punto de vista por capas muestra las diferentes capas y aspectos de la arquitectura
empresarial en un modelo. Existen dos categorías de capas, capas dedicadas y capas de servicio.
Las capas son resultado de la relación de “agrupación” para un particionado natural de todo el
conjunto de objetos y relaciones que pertenecen al modelo. La infraestructura, la aplicación,
los procesos y los actores/roles pertenecen a la primera categoría. El principio estructural
es que cada capa dedicada expone por medio de una relación de “realización” una capa de
servicios, las cuales serán “usadas por” la siguiente capa dedicadas. A partir de esto se puede
separar la estructura interna y la organización de cada capa dedicada de su comportamiento
externo observable expresado como el servicio que esa capa dedicada realiza.[10]

Modelo de Capas
El modelo de capas muestra como los servicios de negocio, aplicación e infraestructura son
integrados por medio de sus modelos intermedios: Se muestran los servicios de negocio prin-
cipales y los procesos de negocio que los realizan, estos procesos están asociados con servicios
de aplicación específicos que a su vez son realizados por componentes de aplicación definidos
para la arquitectura del sistema de software. Los componentes se encuentran soportados en
servicios de infraestructura realizados por nodos de infraestructura y aplicaciones de software
concretas.

53
Figura 11.11: modelo de capas

54
12. Extensión Motivacional
12.1. Punto de vista de stakeholder
El punto de vista del stakeholder permite al analista modelar los stakeholders, los ma-
nejadores internos y externos de cambio, y las valoraciones, (en términos de sus fortalezas,
debilidades, oportunidades y amenazas) de estos manejadores. También los enlaces de alto
nivel para los objetivos que conducen estas valoraciones. Estos objetivos conforman la ba-
se para el proceso de ingeniería de requerimientos, incluyendo el refinamiento de objetivos,
contribución, análisis de conflictos y los requerimientos derivados de estos objetivos.

Figura 12.1: Metamodelo de stakeholder

Modelo de stakeholder
En este punto de vista se presentan dos modelos gráficos correspondientes a los dos sta-
keholders principales del proceso:
El modelo de los evaluadores, cuyo stakeholder concreto son los responsables de área de la
entidad, y cuya misión se es realizar una evaluación de la organización a nivel interno, presenta
como debilidad el desconocimiento del proceso y para qué puede llegar a ser importante, en
sus fortalezas se encuentran la experiencia sobre las tareas que llega a cabo, los objetivos que
pretenden fortalecer esa experiencia es crear un sistema de realimentación de la evaluación, y
disminuir el desconocimiento con información acerca del proceso y su importancia.
El modelo de analistas cuyo stakeholder corresponde al equipo de control interno de la
entidad tiene como misión realizar el proceso de autoevaluación y medir el cumplimiento
de los objetivos de la organización, varias debilidades se evidencian sobre cómo se lleva a
cabo el proceso de consolidación de resultados y tabulación, por eso de pretende atacar estas
debilidades automatizando el proceso en las tareas operativas y facilitando la generación
de reportes, a su vez que permite mejorar el sistema de control interno del componente de
autovaluación.

55
 Figura 12.3: Modelo de stakeholder Equipo de control interno

Figura 12.2: Modelo de stakeholder Responsable de Área

12.2. Punto de vista de realización de objetivos

El punto de vista de realización de objetivos permite al diseñador refinar objetivos en
objetivos más concretos, y la refinación de estos objetivos en requerimientos o restricciones que
describen las propiedades que deben cumplirse para realizar estos objetivos. El refinamiento de
estos objetivos se realiza mediante la relación de agregación. El refinamiento de los objetivos
en requerimientos se modela utilizando la relación de realización.

56
 Figura 12.4: Metamodelo de realización de objetivos

Modelo de realización de objetivos

El modelo de realización de objetivos muestra un objetivo seleccionado refinado en dos
objetivos relacionados a la automatización del proceso de autoevaluación, estos objetivos
concretos permiten evidenciar los requerimientos correspondientes que finalmente apunten a
un principio motivacional en el proceso.

Figura 12.5: Modelo de realización de objetivos

57
12.3. Punto de vista de contribución de objetivos
El punto de vista de contribución de objetivos permite al diseñador o analista modelar las
relaciones de influencia entre los objetivos y los requerimientos. Las vistas resultantes pueden
ser utilizadas para analizar el impacto que los objetivos tienen entre sí y determinar conflictos
entre los objetivos de los stakeholders.

Figura 12.6: Metamodelo de contribución de objetivos

Modelo de contribución de objetivos

En el modelo de contribución de objetivos, se evalúa la forma en que el requerimiento
obtenido a partir de un objetivo puede afectar de forma positiva o negativa otros objetivos
relacionados.

Figura 12.7: Modelo de contribución de objetivos

12.4. Punto de vista de principios

El punto de vista de principios permite al analista o diseñador modelar los principios que
son relevantes en el diseño del problema concreto, incluyendo los objetivos que motivan estos
principios. Adicionalmente, las relaciones entre principios y sus objetivos pueden modelarse a
partir de la influencia de forma negativa o positiva entre ellos.

58
 Figura 12.8: Metamodelo de principios

Modelo de Principios
En este punto de vista se destaca el objetivo organizacional principal: ”brindar comodidad
y rapidez en el proceso de autoevaluación” y todos los principios que realizan ese objetivo.
Comunicación como medio entre los involucrados, un principio de seguimiento a los objetivos
organizacionales, la capacidad de valoración y organización.

Figura 12.9: Modelo de principios

12.5. Punto de vista de realización de requerimientos

El punto de realización de requerimientos permite al diseñador modelar la realización de
los requerimientos por los elementos claves como los actores de negocio, los servicios, procesos
y aplicaciones de negocio. Típicamente, los requerimientos surgen a partir de la refinación del
punto de vista de contribución de objetivos.

59
 Figura 12.10: Metamodelo de realización de requerimientos

Modelo de realización de requerimientos

En el punto de vista de realización de requerimientos se especifican los requerimientos
que realizan uno o más objetivos, para este caso el objetivo se relaciona con la realización
de reportes y estado del proceso, donde se presentan dos requerimientos que realizan este
objetivo. Adicionalmente se presentan restricciones o requerimientos refinados derivados de
los principales.

Figura 12.11: Modelo de realización de requerimientos

12.6. Punto de vista de motivación

El punto de vista de motivación permite al diseñador o analista modelar el aspecto moti-
vacional, sin necesidad de enfocarse en concreto de algunos elementos dentro de este aspecto.
Por ejemplo, este punto de vista puede emplearse para mostrar una revisión completa o parcial
del aspecto motivacional relacionando los stakeholders, su principios primarios, los principios
que son aplicados y los requerimientos principales en los servicios, procesos, aplicaciones y
objetos.

60
 Figura 12.12: Metamodelo de motivación

Modelo de motivación
En el modelo de motivación se relacionan ambos stakeholders, los responsables de área y el
equipo de control interno y sus valoraciones, para cada una de ellas se asocia a un objetivo que
finalmente debe ser realizado por uno o más requerimientos, un requerimiento puede realizar
dos objetivos y fortalecer valores de varios stakeholders simultáneamente que se relacionan
por la caracterización del proceso.

Figura 12.13: Modelo de motivación

61
13. Extensión de Implementación y Migración
13.1. Punto de vista de proyecto
El punto de vista del proyecto es usado principalmente para modelar la gestión del cambio
en la arquitectura, la arquitectura del proceso de migración desde una situación anterior
(estado actual de la arquitectura empresarial) a una situación deseada (estado objetivo de la
arquitectura empresarial) tiene consecuencias significativas en el corto y largo plazo para el
crecimiento de la estrategia y las decisiones subsecuentes del proceso de realización. Algunos
aspectos que deben tomarse en cuenta por el diseñador en este punto de vista son:

Desarrollar una arquitectura empresarial completa para una organización es una tareas
que puede requerir varios años.

Todos los sistemas y servicios deben mantenerse operando en caso que ocurran modifi-
caciones y cambios en la arquitectura empresarial durante el proceso de cambio.

El proceso de cambio puede tener que tratar con estándares inmaduros de tecnología
(mensajería, seguridad, datos).

El cambio tiene consecuencias serias para el personal, la cultura, la manera de trabajar

y la organización.

Figura 13.1: Metamodelo del proyecto

Modelo del proyecto

El objetivo al cual se realizará el primer paquete de trabajo corresponde al objetivo prin-
cipal del proceso, para esto se define el paquete de trabajo en cuyo caso debe ser aceptado
por los roles del evaluador y el analista. El primer paquete de trabajo debe gestionar las eva-
luaciones dentro del enfoque de la encuesta y presentar resultados iniciales sobre el proceso
mediante reportes visuales básicos.

62
 Figura 13.2: Modelo del proyecto

13.2. Punto de vista de migración

El punto de vista de migración se implica modelos y conceptos que pueden ser usados para
especificar la transición de una arquitectura existente a una arquitectura deseada. La platea
es un estado relativo de la arquitectura que existe en un tiempo limitado, una brecha es una
unidad de análisis de transición entre dos plateas.

Figura 13.3: Metamodelo de migración

Modelo de Migración
En el punto de vista de migración se presentan tres plateas que conformarán la evolución
del sistema en sus versiones finales.

1. La primera platea corresponde a una versión de herramienta tipo web que se encuen-
tre alineada con la definición de la arquitectura empresarial propuesta. Debe contener
todos los lineamientos para la gestión de la evaluación mediante enfoque de encuesta y
generación de reportes básicos.

2. La segunda platea corresponde a un sistema mejorado de comunicación entre todos los

participantes y realimentación y valoración de la evaluación.

3. La tercera platea incluye otros mecanismos empleados en el estándar para realizar la

autoevaluación como lo son las auditorías internas, la modalidad de taller y entrevistas.

63
 Figura 13.4: Modelo de migración

13.3. Punto de vista de migración e implementación

El punto de vista de migración e implementación es utilizado para relacionar programas y
proyectos a las partes de la arquitectura que ellas implementa. esta vista permite modelar el
alcance de los programas, proyectos y actividades en términos de las plateas que son realizadas
o los elementos de la arquitectura individual que son afectados. Adicionalmente, la forma en
que los elementos son afectados pueden se indicados anotando las relaciones. Este punto de
vista puede ser utilizado en combinación con los puntos de vista de programas y proyectos
para soportar la administración del portafolio.
El punto de vista de implementación y migración se sitúa para relacionar objetivos de
negocio (y requerimientos) por medio de los programas y proyectos de la arquitectura.

Figura 13.5: Metamodelo de migración e implementación

Modelo de migración e implementación

Basado en el objetivo principal a partir de las valoraciones de los stakeholders, el paquete
de trabajo busca satisfacer con los requerimientos planteados en los anteriores puntos de vista
para conformar la plataforma de lanzamiento funcional inicial. Se presenta el iterable, y las
plateas y brechas en sus futuras versiones, localizada en un dominio web, cuyos usuarios
principales serán aquellos que posean el rol de analistas y evaluadores dentro de la entidad.

64
 El prototipo iterable se conoce como la Plataforma de Autoevaluación institucional basada
en el Modelo Estándar de Control Interno MECI, ValueMe - Valórame, una herramienta de
apoyo para la consolidación, gestión y entrega de resultados del proceso de autoevaluación
institucional.

Figura 13.6: Modelo de migración e implementación

65
14. Cierre de la definición de la arquitectura empresarial
La finalización de la arquitectura empresarial otorga como resultados obtenidos un conjun-
to de modelos semánticos representativos del proceso empresarial en todas sus dimensiones,
que representan un recurso que modela un conocimiento importante para el proceso y la or-
ganización, la arquitectura empresarial como hoja de ruta para la futura integración de los
sistemas de información con procesos y funciones de negocio en las empresas.
La autoevaluación institucional basado en el MECI modelado en todos sus puntos de
vista, identifican claramente el proceso de negocio que representa, la estructura de aplicación
y aspectos tecnológicos a tener en cuenta, su influencia para todos los involucrados de la
organización y el proyecto que se espera ejecutar para integrarse con las tecnologías de la
información.

66
15. Desarrollo del plan de trabajo bajo Scrum
La metodología relacionada para el desarrollo es Scrum - como apoyo a la metodología se
utiliza la plataforma web Icescrum.
Se desarrolla en 2 lanzamientos (releases).

1 Lanzamiento: Duración 10 semanas (14/07/2016 - 21/09/2016): Primer lanzamiento

del aplicativo con la finalización de los requerimientos iniciales. Para este lanzamiento
se programaron 3 iteraciones (Sprints):

• 1 sprint: 4 semanas: (14/07/2016 - 11/08/2016) Diseño del esquema de la base de

datos, Gestión de cuentas de usuarios y autenticación.
• 2 sprint: 3 semanas: (12/08/2016 - 30/08/2016) Diseño general de la encuesta,
Campos personalizados de encuestas, Implementación de plataforma de documen-
tación.
• 3 sprint: 3 semanas: (31/08/2016 - 21/09/2016) Gestión de resultados Básica, Ges-
tión del cronograma de la encuesta.

2 Lanzamiento: Duración 8 semanas (22/09/2016 - 16/11/2016): Segundo lanzamiento

del aplicativo con reportes y ajustes a medida.Para este lanzamiento se programan 2
iteraciones (Sprints)

• 1 sprint: 4 semanas: (22/09/2016 - 21/10/2016) Notificaciones y componente de

correo electrónico, Esquema de navegación para usuarios registrados.
• 2 sprint: 4 semanas: (22/10/2016 - 16/11/2016) Reportes particulares de resultado,
diseño de estilo visual de la herramienta, ajustes Generales.

15.1. Historias de usuario

Para la programación de los entregables e iteraciones se realiza un conjunto de actividades
que define el paquete de trabajo:

1. Planear las entregas: Se establecen dos entregas la primera entrega final contiene los
requerimientos iniciales de la aplicación para ser puesta en producción. La segunda
entrega contiene los reportes a medida realizados.

a) Planear las características de las entregas (Features)

1) Características principales Lanzamiento 1: Experiencia de usuario, configura-
ble a medida, subproceso de captura de encuesta, consolidación de encuesta,
registro de usuarios.
2) Características principales Lanzamiento 2: presentación de resultados específi-
cos, comunicación utilizando correo electrónico.

2. Planear los usuarios y roles: Se toman los roles definidos en la arquitectura empresa-
rial: Analista, Evaluador, Administrador es un rol adicional que se especifica para la
plataforma.

67
 Figura 15.1: Esquema gráfico de las historias de usuario del primer lanzamiento

3. Planear las historias de usuario en la pila del producto (product Backlog) y organizarlas
en cada uno de las iteraciones a realizar.

4. Planear y ejecutar tareas para cada historia de usuario.

El plan de entrega (release plan) contiene el lanzamiento asociado a las iteraciones (sprints)
y las historias de usuario (user stories) que se realizan en cada iteración:

Numero de Historias de usuario: 25.

Numero total de Lanzamientos: 2

Numero total de puntos acumulados: 166

68
15.1.1. Primer Release
1 Sprint (14/07/2016 - 11/08/2016) numero de historias de usuario realizadas: 7

Tipo Historia de usuario

Nombre Cuenta de usuario
Esfuerzo 13.00
Descripción Como usuario del sistema debo tener acceso por medio de una cuenta
de usuario que me identifique dentro del sistema
Criterios de rutas de acceso : El sistema debe proporcionar el acceso mediante la
aceptación pagina principal y autenticación en cualquier dirección url
Tareas 1 - Creación de la estructura de base de datos.
asociadas

Tipo Historia de usuario

Nombre Edición de categorias
Esfuerzo 8.00
Descripción Como analista debo tener la posibilidad de editar los procesos y la
estructura MECI de la plataforma sin afectar las encuestas realizadas
ni los usuarios existentes.
Criterios de Edición de categorias : Al editar un atributo de la categoria, esta debe
aceptación verse relfejada en las cuentas de usuario, encuestas, evaluaciones y
categorias de las preguntas.
Tareas 32 - Eliminación de categorias. 4 - Edición de categorias en la jerarquia.
asociadas

Tipo Historia de usuario

Nombre Vista jerarquica de categorias
Esfuerzo 5.00
Descripción Como analista deseo ver los procesos que se evalúan categorizados
según la jerarquia de la entidad verlos de forma organizada.
Criterios de Jerarquia Adyacente : Cuando el usuario desee seleccionar el detalle de
aceptación una categoria se debe mostrar en diagrama organizacional las
categorias adyacentes en la jerarquia.
Tareas 6 - Añadir vista jerarquica en categorias.
asociadas

69
Tipo Historia de usuario
Nombre Cuentas de usuario por proceso
Esfuerzo 3.00
Descripción Como evaluador de un proceso de la entidad, mi cuenta debe
encontrarse relacionada con ese proceso y el mecanismo de
autenticación es el correo electronico del área que gestiona el proceso
Criterios de asignación de cuenta : El correo electronico debe asignarse por área y
aceptación deben haber multiples cuentas de usuario asignadas a procesos de la
entidad.
Tareas 5 - Asignación de usuarios a procesos.
asociadas

Tipo Historia técnica

Nombre Gestión de cuentas
Esfuerzo 5.00
Descripción Todos los usuarios deben tener la posibilidad de cambiar su contraseña
del sistema, el usuario analista puede gestionar todas las cuentas de
usuario
Criterios de cambio de contraseña : El usuario que cambie la contraseña deberá ser
aceptación notificado via correo electronico
Tareas 8 - Función de recuperar contraseña.
asociadas

Tipo Historia de usuario

Nombre Manejo de roles y permisos
Esfuerzo 5.00
Descripción Como administrador de la plataforma debo poder crear o editar roles y
asginarlos a los usuarios para tener un mayor control de los permisos de
cada tipo de usuario
Criterios de Modificación de roles : Al modificar los roles de una cuenta de usuario,
aceptación los accesos deben ser reflejados en la proxima autenticación
Tareas 2 - Configuración de permisos. 3 - Manejo de roles.
asociadas

70
 Tipo Historia técnica
Nombre Parametros de configuración
Esfuerzo 8.00
Descripción La herramienta debe ser parametrizable en tanto que pueda ser
extensible para otras entidades cuyos mapas de procesos, usuarios,
categorias a evaluar del MECI sean diferentes
Criterios de Parametros : Las configuraciones de parametros deben estructurar la
aceptación herramienta de forma que pueda establecerse el proceso por área, por
proceso, por usuario y ajustarse a la estructura del meci, nuevos
componentes, elementos y modulos.
Tareas 33 - Parametro de vista principal. 7 - Parametros de categorias.
asociadas

2 Sprint (12/08/2016 - 30/08/2016) numero de historias de usuario realizadas: 6

Tipo Historia de usuario

Nombre Escalas de valoración
Esfuerzo 3.00
Descripción Como analista debo adoptar las metricas de evaluación propuestas en el
MECI para que se encuentren disponibles en la plataforma
Criterios de Escala MECI : Cuando un evaluador repsonda una pregunta de la
aceptación evaluación la escala debe corresponder al estandar: no sabe, no se
cumple, se cumple insatisfactoriamente, se cumple aceptablemente, se
cumple en alto grado, se cumple plenamente.
Tareas 19 - Establecer escala de valoración
asociadas

Tipo Historia de usuario

Nombre Campos personalizados
Esfuerzo 8.00
Descripción Como evaluador puedo establecer campos personalizados para la
encuesta que considere relevantes en la evaluación de los procesos.
Criterios de Tipos de campos : Cuando un analista desee crear un campo
aceptación personalizado debe escoger entre encabezado y contenido (por
pregunta) y de tipo: selección multiple o campo abierto de texto
Tareas 18 - Asociacion con las encuestas 16 - CRUD campos personalizados 17
asociadas - Tipos de campos personalizados

71
Tipo Historia de usuario
Nombre Asignación de encuestas
Esfuerzo 3.00
Descripción Como usuario evaluador debo encontrarme asignado al proceso de la
entidad del cual evaluo en la encuesta
Criterios de Asignación de unica categoria : Cada usuario puede completar la
aceptación encuesta unicamente del proceso o categoria que se encuentra asignado
Tareas 11 - Cambiar asignación de encuesta
asociadas

Tipo Historia de usuario

Nombre Herramienta de documentación
Esfuerzo 5.00
Descripción Se debe implementar una herramienta de documentación que muestre
al usuario todas las acciones disponibles en el sistema y muestre
respuestas a las preguntas comunes.
Criterios de Plataforma : La platafoma de documentación debe estar accesible desde
aceptación la herramienta con enlaces de cada modulo.
Tareas 9 - Herramienta Web Dokuwiki 10 - Estilo visual
asociadas

Tipo Historia técnica

Nombre Validaciones de las encuestas
Esfuerzo 3.00
Descripción El sistema debe validar los campos de la encusta obligatorios, el
numero de encuestas permitidas por usuario, los campos obligatorios en
las categorias y los campos unicos
Criterios de Respuestas requeridas : Todas las preguntas deben ser completadas
aceptación Encuestas por usuario : El usuario puede completar más de una
encuesta siempre que no supere el limite establecido por un parametro
de configuración general.
Tareas 15 - Validación del campo de valoración
asociadas

72
 Tipo Historia de usuario
Nombre Formulación de encuestas
Esfuerzo 13.00
Descripción Como analista debo crear el conjunto de encuestas por procesos en la
entidad, y la herramienta me permita asignar preguntas comunes para
varias encuestas independientemente del proceso.
Criterios de una pregunta multiples encuestas : Cuando el analista desee crear las
aceptación preguntas, se deben mostrar los procesos que aplican para las preguntas
y establecer la misma pregunta en varias encuestas.
Creación automatica : Las encuestas que no existen se deben crear
automaticamente cuando se cree una pregunta que involucre las
encuestas
Tareas 13 - Edición de encuestas 12 - Creación de preguntas 14 - Edición de
asociadas preguntas

3 Sprint (31/08/2016 - 21/09/2016) numero de historias de usuario realizadas: 5

Tipo Historia de usuario

Nombre Estructurar el MECI
Esfuerzo 5.00
Descripción Como analista debo parametrizar el modelo estandar de control interno
en el aplicativo acorde a los criterios de evaluación que emplea la
entidad
Criterios de Categorias especificas : Se pueden establecer categorias del meci
aceptación especificos de evaluación si la entidad omite modulos, componentes o
elementos en el proceso.
Tareas 34 - Enlace principal MECI
asociadas

Tipo Historia de usuario

Nombre Edición de categorias
Esfuerzo 8.00
Descripción Como analista debo tener la posibilidad de editar los procesos y la
estructura MECI de la plataforma sin afectar las encuestas realizadas
ni los usuarios existentes.
Criterios de Edición de categorias : Al editar un atributo de la categoria, esta debe
aceptación verse relfejada en las cuentas de usuario, encuestas, evaluaciones y
categorias de las preguntas.
Tareas 32 - Eliminación de categorias. 4 - Edición de categorias en la jerarquia.
asociadas

73
Tipo Historia de usuario
Nombre Manejo de cronograma
Esfuerzo 5.00
Descripción Como analista debo poder manejar el cronograma por vigencia para ver
las fechas de evaluación de todas las vigencias y establecer fechas de
acceso a usuarios por vigencia.
Criterios de Vigencia activa : Unicamente pueden tener acceso los usuarios a
aceptación completar la encuesta en una vigencia activa y que corresponda con la
fecha actual.
Tareas 22 - Cronograma por vigencia
asociadas

Tipo Historia de usuario

Nombre Ver progreso de las evaluaciónes
Esfuerzo 5.00
Descripción Como analista debo tener acceso a ver los evaluadores que han realizado
la encuesta como los que aún falta para ver el progreso del proceso.
Criterios de Vista de progreso general : El analista debe ver el estado de los
aceptación usuarios que realizaron encuestas para todas las vigencias.
Tareas 23 - Progreso de los participantes
asociadas

Tipo Historia de usuario

Nombre Modulo de resultados basico
Esfuerzo 13.00
Descripción Como analista debo tener acceso a un conjunto de resultados generales
de la consolidación y tabulación de las encuestas que me permitan
evaluar el proceso de la entidad.
Criterios de Resultados consolidados: Los resultados consolidados solo pueden
aceptación obtenerse a partir de las encuestas realizadas en una vigencia y
organizadas por la estructura MECI.
Tareas 20 - Resultados totales
asociadas

74
15.1.2. Segundo Release
1 Sprint (22/09/2016 - 21/10/2016) numero de historias de usuario realizadas: 4

Tipo Historia de usuario

Nombre Reporte Individual
Esfuerzo 5.00
Descripción Como analista debo poder ver las evaluaciones realizadas por los
usuarios de forma individual y los resultados consolidados por modulo,
componente o elemento
Criterios de Acceso a resultados individuales: El analista es el unico rol que puede
aceptación ver los resultados por cuenta de usuario.
Tareas 25 - Resultado por cuenta
asociadas

Tipo Historia técnica

Nombre Control de encuestas por cuenta
Esfuerzo 8.00
Descripción La herramienta debe contemplar la posibilidad de que cada cuenta
pueda completar más de una encuesta por vigencia relacionada al
mismo proceso.
Criterios de Consolidación de resultados: Los resultados por cuenta deben
aceptación consolidarse para todas las encuestas realizadas, asimismo en resultados
consolidados por proceso.
Tareas 27 - Control de parametros de cuenta
asociadas

Tipo Historia de usuario

Nombre Comparación de resultados
Esfuerzo 8.00
Descripción Como analista debo poder ver los resultados de diferentes procesos
filtrados en modulos, componentes y elementos para comparar las
valoraciones de aspectos similares entre procesos relacionados
Criterios de Vista independiente: Los resultados de la consolidación deben ser en
aceptación graficos independientes del proceso base y de los proceso(s) a comparar.
Tareas 24 - Comparación por proceso
asociadas

75
 Tipo Historia técnica
Nombre Notifcaciones por correo electronico
Esfuerzo 5.00
Descripción El sistema debe notificar via correo electronico acciones relacionadas
con el evaluador como cambios de contraseña, activaciones y realización
de las encuestas
Criterios de Email de destino: La cuenta de correo a enviar unicamente debe ser
aceptación para la cuenta de usuario registrada.
Notifcación: Las notificaciones deben ser realizadas justo despues de
realizar alguna acción descrita en la historia de usuario.
Tareas 26 - Confgración de correo electronico
asociadas

2 Sprint (22/10/2016 - 16/11/2016) numero de historias de usuario realizadas: 4

Tipo Historia de usuario

Nombre Reporte Individual
Esfuerzo 5.00
Descripción Como analista debo poder ver las evaluaciones realizadas por los
usuarios de forma individual y los resultados consolidados por modulo,
componente o elemento
Criterios de Acceso a resultados individuales: El analista es el unico rol que puede
aceptación ver los resultados por cuenta de usuario.
Tareas 25 - Resultado por cuenta
asociadas

Tipo Historia técnica

Nombre Control de encuestas por cuenta
Esfuerzo 8.00
Descripción La herramienta debe contemplar la posibilidad de que cada cuenta
pueda completar más de una encuesta por vigencia relacionada al
mismo proceso.
Criterios de Consolidación de resultados: Los resultados por cuenta deben
aceptación consolidarse para todas las encuestas realizadas, asimismo en resultados
consolidados por proceso.
Tareas 27 - Control de parametros de cuenta
asociadas

76
 Tipo Historia de usuario
Nombre Comparación de resultados
Esfuerzo 8.00
Descripción Como analista debo poder ver los resultados de diferentes procesos
filtrados en modulos, componentes y elementos para comparar las
valoraciones de aspectos similares entre procesos relacionados
Criterios de Vista independiente: Los resultados de la consolidación deben ser en
aceptación graficos independientes del proceso base y de los proceso(s) a comparar.
Tareas 24 - Comparación por proceso
asociadas

Tipo Historia técnica

Nombre Notifcaciones por correo electronico
Esfuerzo 5.00
Descripción El sistema debe notificar via correo electronico acciones relacionadas
con el evaluador como cambios de contraseña, activaciones y realización
de las encuestas
Criterios de Email de destino: La cuenta de correo a enviar unicamente debe ser
aceptación para la cuenta de usuario registrada.
Notifcación: Las notificaciones deben ser realizadas justo despues de
realizar alguna acción descrita en la historia de usuario.
Tareas 26 - Confgración de correo electronico
asociadas

15.2. Análisis de la metodología de software

15.2.1. Burndown chart del proyecto
La siguiente gráfica muestra el numero de puntos en historias de usuario (medición de
esfuerzo) a través de los lanzamientos y de las iteraciones. En cada iteración el numero de
historias restantes disminuye hasta completar el 100 % de la realización del proyecto, La
mayor parte los puntos acumulados entre historias de usuario fueron completadas en el primer
lanzamiento.
El numero de historias técnicas realizadas se muestra en color naranja.

77
 Figura 15.2: Burndown chart del proyecto

Convenciones: R1S1: Release 1 - Sprint 1, R1S2: Release 1 - Sprint 2, R1S3: Release 1 -

Sprint 3, R2S1: Release 2 - Sprint 1, R2S2: Release 2 - Sprint 2.

15.2.2. Gráfica de velocidad del proyecto

La siguiente gráfica muestra la velocidad del proyecto en puntos de historias de usuario, es
decir el numero de puntos realizados en cada iteración. Con un total de 159 puntos acumulados.
un 74.21 % realizado en el primer lanzamiento y 25.79 % realizado en el segundo lanzamiento.

78
 Figura 15.3: Velocidad del proyecto

El siguiente gráfico muestra el numero de puntos en historias de usuario y la capacidad

planeada para la ejecución de las historias. Todas las historias se realizaron según la capacidad
planeada en cada sprint. No existieron historias de usuario realizadas fuera del Sprint donde
se planeó y ejecutó. La capacidad fue completada en totalidad para cada sprint.

79
 Figura 15.4: Velocidad del proyecto vs Capacidad de Sprints

15.3. Plataforma tecnológica

Tecnologías de apoyo

Amazon Web Services - contenedor EC2.

Zoho Mail - Servicio de correo electrónico.

Let’s Encrypt - Entidad certificadora que provee certificación SSL gratuita.

name.com - Servicio de dominio web.

Herramientas de software de apoyo

Dokuwiki Licencia CC BY-SA 4.0 - Software de documentación.

Apache HTTP server - Servidor Web.

Apache Tomcat - Contenedor de Aplicaciones.

MongoDB - Sistema gestor de Bases de Datos.

Grails - Framework de desarrollo.

80
Propósitos para usar las tecnologías implementadas en este proyecto
Usar tecnologías recientes y practicas de desarrollo de software.
Utilización de tecnologías libres en la entidad publica.
Crear modelos de datos no convencionales como el orientado a documentos para apoyar
el uso de nuevas tecnologías.

15.4. Manual de usuario

El sistema de documentación sobre un ambiente web permite al usuario conocer el manejo
de la herramienta y representa el primer punto de partida para buscar y conocer las acciones
disponibles del sistema. Contiene el instructivo para realizar las actividades concernientes al
proceso de cargue de información al sistema y generación de resultados.

16. Arquitectura de software

16.1. Modelo de datos
El modelo de datos se realiza de acuerdo al modelo entidad - relación, El gestor de bases
de datos es un sistema orientado a documentos (MongoDB):

Figura 16.1: Modelo de datos entidad - relación

81
Justificación del modelado de datos en estructura de documentos

Los sistemas orientados a documentos se adaptan de forma natural a estructuras de

documentos cono encuestas, formularios y listados que requieren una rápida respuesta
a las consultas cuando el numero de documentos aumenta.

Es posible modelar fácilmente colecciones con documentos distintos dentro de la misma

colección, es decir encuestas con preguntas y campos diferentes entre si.

El framework de desarrollo permite abstraer de forma natural las colecciones de la

base de datos en entidades de dominio y gestiona automáticamente los documentos,
permitiendo utilizar relaciones entre documentos cuando es estrictamente necesario.

El modelo de requerimientos establece que generalmente las encuestas no son modifica-

bles después de haberse realizado. Lo que implica que la evaluación puede almacenarse
como un documento con todos los datos embebidos.

La representación visual del documento se muestra en formato JSON. Esto también

facilita la integración con otros sistemas a través de API que utilizan esta notación
como estructura de los mensajes.

Se maneja la estructura en idioma ingles acorde al framework de desarrollo Grails.

16.2. Modelo de dominio

El modelo de dominio muestra de forma general las entidades que se relacionan en la
aplicación.

82
 Figura 16.2: Modelo de dominio

Descripción de las entidades

User account: Entidad de la cuenta de usuario, representa la información de las cuentas

de usuarios, información del proceso al que pertenece.

Role: Representa el rol de las cuentas de usuario.Un rol puede tener varios permisos
asociados.

Permission: Entidad de permisos específicos dentro de la aplicación. Los permisos son

accesos concretos a acciones en la aplicación.Es el nivel más detallado de control de
acceso.

Param: Entidad de parámetros de configuración del sistema. Representa configuraciones

de organización de la aplicación procesos, áreas, estructura MECI.

Category: Entidad de Categorías del sistema. Las categorías se gestionan por tipo y
representan procesos, formas de organizar la encuesta. Se presenta una relación a la

83
 misma entidad que indica que pueden existir sucategorias y categorias padre dentro de
la estructura.

Category type: Tipos de categorías del sistema para la estructura de la encuesta y de

las cuentas de usuarios.

Survey: Entidad de la encuesta. Representa la plantilla de la encuesta asignada a un

proceso, contiene únicamente las preguntas a ser evaluadas.

Question: Entidad que representa la pregunta.Pertenece a una categoría dentro de la

estructura MECI.

Assessment: Entidad que representa las evaluaciones concretas realizadas por los usua-
rios, contiene las respuestas, la encuesta plantilla y campos de respuesta personalizados.

Answer: Respuestas asociadas a una evaluación, se encuentran asociadas con la pregunta

de la encuesta.

Custom Field: Representan los campos personalizados que se establecen en las evalua-
ciones, pueden encontrase en el encabezado o junto como campos adicionales de una
pregunta.

Schedule: Representa el cronograma de la encuesta. Permite crear varios cronogramas

cada uno con su vigencia.

Password Encoder: Utilitario de cifrado de contraseña para la cuenta de usuario. el

algoritmo por defecto utilizado para el cifrado es bcrypt.

16.3. Arquitectura de la aplicación

La arquitectura general de la aplicación sigue un modelo web basado en capas[8], esto
corresponde con una descripción detallada del punto de vista de infraestructura en la definición
de la arquitectura empresarial.

Capa de cliente: Gestionada a través del navegador web.

Capa de red: Utiliza el protocolo https para asegurar la conexión cirfrada entre el cliente
y el servidor. Se utiliza un certificado de seguridad gratuito a través de una entidad
certificadora sin animo de lucro.

Capa de acceso a la aplicación: se utiliza el contenedor de aplicaciones de java servlet

compatible con groovy - Gestiona la aplicación en formato Web application ARchive
WAR. El servidor web de apache permite establecer el enlace a través del puerto 443,
el nombre del dominio y la aplicación desplegada en tomcat.

Capa de presentación: La capa de presentación se define a través de plantillas web

gestionadas a través del framework. Este genera los contenidos estáticos como imágenes
y scripts ejecutados en la capa del cliente.

84
 Capa lógica del negocio: Se estructura a través del framework empleando el patrón de
software Modelo - Vista - Controlador, a través de controladores que reciben las peti-
ciones de las vistas y procesan las acciones, los servicios emplean más funcionalidades,
los objetos de dominio representan las entidades

Capa de acceso a la persistencia: A traves del conector de la base de datos especifica y

el mapeador del framework, se utiliza el patro de registro activo y la implementación
del mapeador en Hibernate para establecer la conexión con la base de datos y ejecutar
las consultas.

Capa de persistencia: En la capa de persistencia se gestiona a través del SGBD (Sistema

gestor de bases de datos) MongoDB orientado a documentos.

Figura 16.3: Arquitectura general de la aplicación

17. Metodología web

17.1. Análisis
17.1.1. Selección de usuarios
Usuarios de la organización y de la entidad definidos en los roles de la arquitectura em-
presarial. Todos los usuarios tienen conocimientos en uso de sistemas y aplicaciones alojadas
en web. Presentan acceso a los contenidos del aplicativo y pueden hacer uso de dispositivos
moviles para consultar información.
Usuarios de la organización: Todas las áreas de la entidad y las personas que tienen relación
con los procesos, bien sean misionales, estratégicos, de seguimiento o de apoyo. se definen los
tipos de usuarios:

Evaluadores.

85
 Analistas.

Administradores de la plataforma.

Figura 17.1: Tipos de usuarios de la plataforma

17.1.2. Expectativa de usuarios

Navegación de fácil uso.

plantillas reconocidas para las acciones.

estructura paso a paso que informe sobre el proceso.

Que puedan consultar la información o realizar la evaluación desde cualquier dispositivo.

17.1.3. Expectativa de la organización

Establecer un diseño personalizado de acuerdo a la entidad, estilos visuales, fuentes agra-
dables. La herramienta debe informar acerca del proceso a los usuarios, Las interfaces de
acceso deben ser diferentes deacuerdo a los roles y permisos.

17.2. Planificación
17.2.1. Selección de software
Tecnologías actuales para la definición de contenido web HTML5, CSS, Javascript. Se
utiliza un marco de trabajo para la presentación Semantic UI (Liencia MIT). Este marco de
trabajo permite usar los componentes visuales y temas personalizados.

17.2.2. Estructura de navegación

Se maneja una estructura de red con un panel principal donde se puedan acceder a todas las
funcionalidades desde el menú principal a todos los módulos de la herramienta, cada modulo
cuenta con accesos a opciones especificas.

86
 Figura 17.2: Mapa de navegación general opraciones CRUD

Operaciones Crud: Las operaciones crud de las entidades (encuestas, usuarios, pregun-
tas, categorías). Manejan el mismo sistema de navegación para los módulos. Todos los
módulos presentan las operaciones básicas de consulta, inserción, modificación y eli-
minación. Algunos módulos emplean operaciones especificas como la consolidación de
resultados, migración de encuestas entre periodos o que involucren varias entidades del
dominio como la creación de las encuestas.

Operaciones de consolidación de resultados: Los resultados se muestran sobre la misma

pagina.

Operaciones de completado de la encuesta: Se presenta una guía.

87
 Figura 17.3: Mapa de navegación general

17.3. Diseño
Diseño establecido por la organización. Se tiene en cuenta los estilos visuales y la paleta
de colores de los demás aplicativos y sistemas de la organización.

88
Figura 17.4: Diseño de la aplicación

89
Parte III
Cierre de la investigación
18. Resultados y discusión
A partir de la definición de requerimientos por medio de la metodología de desarrollo de
software, la definición de la arquitectura empresarial orientada al proceso de autoevaluación
institucional, y el levantamiento de la información del contexto del problema, se logra construir
un prototipo capaz de gestionar el proceso de Autoevaluación con los criterios establecidos en
el MECI. El ejemplo de aplicación es la implementación en la entidad publica Instituto distrital
para la protección de la niñez y la juventud IDIPRON. Se da por finalizada la construcción
del prototipo dando cumplimiento al alcance del problema.

19. Conclusiones
Se describió el proceso de autoevaluación institucional evidenciando que se maneja un
enfoque particular orientado al MECI, es decir, el estándar puede utilizarse como estruc-
tura para realizar la autoevaluación y proveer los aspectos a evaluar, esto es visto desde
el punto de vista de las áreas de control interno y es independiente de como se maneje
en otras entidades. Para un ejemplo de un caso real se tomó como fuente de informa-
ción el Instituto distrital para la protección de la niñez y la juventud IDIPRON cuyo
enfoque se basa en el MECI. El uso de entrevistas como fuente primaria de información
fue suficiente para identificar el contexto del problema.(sec 7.1)

Se definió la arquitectura empresarial orientada al proceso utilizando el lenguaje de des-

cripción de arquitectura Archimate, todos los puntos de vista fueron tratados a partir
de la información obtenida y representan el proceso organizacional y aspectos del pro-
ceso de autoevaluación institucional en general.(sec 11.6) En este punto se consolida la
definición del producto, el nombre del prototipo funcional.

Se empleó la metodología agíl para el desarrollo de software Scrum, que permitió or-
ganizar el trabajo y las actividades de desarrollo de software a través del cronograma
planteados.(sec 15) Las historias de usuario fueron planteadas y organizadas sin apla-
zamientos en las entregas dentro de los tiempos establecidos. En la metodología se
estructuraron las historias de usuario utilizando un lenguaje común con el objetivo de
que los involucrados del proyecto puedan comprender el estado del proyecto y las ta-
reas que se realizan. El prototipo logra otorgar indicadores de resultados a través de los
módulos, componentes y elementos del MECI y consolidados por procesos.

Cuando este proceso se realiza manualmente, toma tiempo y esfuerzo por parte de los
analistas en tareas repetitivas;(sec 7.1) con el uso de las tecnologías de la información y
la constante búsqueda en integrarlas con los procesos en las organizaciones, los analistas
tendrán más tiempo para enfocarse en realmente la evaluación se que esta realizando,
esto es, mediante este enfoque, cómo buscar mejorar las preguntas y los mecanismos de
evaluación para que la propia evaluación sea más acertada.

90
 En cuanto al proceso de la evaluación institucional y el prototipo generado, se evidenció
una mejora de comunicación que no era presente entre todos los evaluadores y el analista
mediante el uso de canales de comunicación como el correo electrónico, esto sirvió como
“puente” entre los evaluadores para la misma mejora de la evaluación.

19.1. Aportes Originales

Creación de un modelo de arquitectura empresarial orientado al proceso de autoevalua-
ción institucional.

Creación de un prototipo de apoyo para el proceso que automatiza las tareas manuales
utilizando las tecnologías de información.

19.2. Trabajos o publicaciones derivadas

La definición de la arquitectura empresarial se presenta como un enfoque holístico y me-
todológico de todo el proceso, esto permite conocer con exactitud las necesidades de la orga-
nización y la metodología para el diseño y puesta en marcha de la solución. La posibilidad
que ofrece esta disciplina permite identificar nuevos conceptos y características que ayuden
al proceso, facilitando la integración con otros sistemas de información y el diseño de mode-
los independientes de la computación como estructuras semánticas que pueden evolucionar a
medida que el proceso lo hace.
El proceso de autoevaluación institucional involucra un gran numero de componentes y
elementos empresariales y cuya naturaleza, al ser aplicable a toda la organización, puede
caracterizar a toda la organización, en sus funciones y procesos, valores institucionales y
su objeto social para las entidades públicas de forma general. La arquitectura empresarial
definida para este proceso puede aportar como insumo base para la definición de una nueva
arquitectura empresarial cuyo dominio sea toda la organización.
A través de la definición de los puntos de vista como de negocio, aplicación, infraestructura,
extensión motivacional y extensión de implementación y migración se pueden modelar aspectos
de una arquitectura empresarial con una abstracción suficientemente detallada que puede
comprender el arquitecto de software y los involucrados en le proyecto, en este proyecto
se evidenció que esto puede ser aplicado a un proceso concreto de forma natural y como un
ejemplo de aprendizaje para futuras definiciones arquitecturas aplicables también a un entorno
empresarial.

20. Prospectiva del trabajo de grado

20.1. Trabajos de investigación futuros
Se espera implementar la herramienta de Autoevaluación institucional a la entidad selec-
cionada para su aplicación y se espera continuar con un soporte y acompañamiento en busca
de identificar falencias y mejorar aplicables al entorno empresarial.
Se propone establecer una arquitectura de software que permita implementar diferentes
enfoques de autoevaluación institucional adicionales a la encuesta aplicables a diferentes enti-
dades de carácter descentralizado, mediante la puesta en marcha de las versiones del sistema

91
a partir de las plateas definidas en el punto de vista de migración e implementación, adicio-
nalmente se esperan mejorar las herramientas tecnológicas con la implementación futura de
servicios web y compatible con una arquitectura orientada a servicios como parte de sistemas
macro orientados al MECI a medida que la herramienta evolucione.
Debido a que esta herramienta y el diseño a partir de la arquitectura empresarial del
proceso se interrelaciona con un estándar regido a nivel nacional, como trabajo futuro se
pretende proveer a esta herramienta a todas las entidades de carácter descentralizado con el
apoyo de entidades como el ministerio de las TIC y apps.co para su financiación, se espera que
se consolide como una herramienta general y el propio uso y realimentación de sus usuarios
permita la mejora continua del mecanismo de evaluación.

92
Referencias
[1] Colombia Congreso Nacional de la Republica. Ley 83 de 1993, por la cual se establecen
normas para el ejercicio del control interno en las entidades y organismos del estado y
se dictan otras disposiciones. noviembre 1993.

[2] Colombia Congreso Nacional de la Republica. Ley 489 de 1998, por la cual se dictan
normas sobre la organizacion y funcionamiento de las entidades del orden nacional. no-
viembre 1998.

[3] Colombia Congreso Nacional de la Republica. Decreto 2145 de 1999. por el cual se dictan
normas sobre el Sistema Nacional de Control Interno de las Entidades y Organismos de
la Administracion Publica del Orden Nacional y Territorial. noviembre 1999.

[4] Instituto de Auditores Internos de Colombia. Guia Autovaloracion del Control. Depar-
tamento Administrativo de la Funcion Publica, julio 2010.

[5] Departamento Administrativo de la Funcion Publica. Manual de Implementacion Modelo

Estandar de Control Interno para el Estado Colombiano MECI 1000:2005, 2005.

[6] Departamento Administrativo de la Funcion Publica. Guia para la construccion de indi-

cadores de gestion, 2012.

[7] Departamento Administrativo de la Funcion Publica. Manual Tecnico del Modelo Estan-
dar de Control Interno para el Estado Colombiano, mayo 2014.

[8] Martin Fowler. Gui architectures. http://www.martinfowler.com/eaaDev/uiArchs.html,

2006.

[9] The Open Group. Togaf 9.1 specification. http://pubs.opengroup.org/architecture/togaf9-

doc/arch, 2011.

[10] The Open Group. Archimate 2.1 specification.

http://pubs.opengroup.org/architecture/archimate2-doc, 2013.

[11] SCRUMstudy. Scrum Framework. II. SBOK Guide. VMEdu, Inc., 2016.
http://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2013.pdf.

93
21. Anexos
21.1. Anexo 1 - Formato de entrevistas realizadas
El siguiente formato de entrevista fue aplicado para los involucrados del proceso de au-
toevaluación institucional, Las preguntas son abiertas y consolidadas de forma escrita por el
entrevistador. Las entrevistas son realizadas cara a cara.

1. ¿Conoce el proceso de autoevaluación institucional?. Realice una breve descripción de

lo que significa para usted.

2. ¿Que tipo de resultados debería arrojar el proceso de autoevaluación? (Pregunta espe-

cifica al analista)

a) ¿Para que se emplean estos resultados?

3. ¿Cual es el periodo en el que se realiza este proceso?

4. ¿De qué forma es informado de los resultados del proceso?

5. ¿Cree que el proceso actual de consolidación es demorado o causa algún impacto negativo
en su trabajo?

a) ¿Cómo podría mejorar el proceso?¿En que aspectos?

6. ¿Quienes son los involucrados en el proceso?

a) ¿Como se establece su organización?

b) ¿Quienes no hacen parte del proceso?

7. ¿Sobre que criterios de evaluación parte el proceso de evaluar?

a) ¿Conoce el Modelo Estándar de control Interno?

b) ¿Conoce las funciones principales del área de control interno de la entidad?

8. ¿Como es el proceso que se lleva a cabo actualmente?. Indique las actividades que se
realizan.

a) ¿Cuando finaliza?. Indique los tiempos de evaluación.

9. ¿Que herramientas de software utiliza de apoyo para realizar este proceso?

10. ¿Se encuentra familiarizado con herramientas de realización de encuestas?¿cuales?

11. ¿Quienes estructuran las encuestas y las preguntas?¿Como van organizadas las pregun-
tas?

12. ¿Pueden existir campos adicionales que se requieran en la encuesta?

94
21.2. Anexo 2 - Procedimiento para la tabulación de encuestas e intepre-
tación de resultados del MECI [5]

95
 MANUAL DE IMPLEMENTACION 81

ANEXO 2
Procedimiento para la tabulación de
encuestas e interpretaciòn de resultados

Una vez se haya aplicado la encuesta correspondiente, se deben tabular las respuestas con el fin de
organizar la información que cada una arroja y analizarla para consolidar los resultados respectivos.
Este procedimiento servirá para la tabulación de las encuestas de diagnóstico utilizadas en los dos
primeros Subsistemas, y para las encuestas de autoevaluación, previstas en el tercer Subsistema..

Procedimiento de Tabulación

Para efectos de la tabulación, a cada respuesta de la escala de valoración24 , se le asignó un valor,

tal como se aprecia en la siguiente tabla:

Valor Descripción
0 No sabe
1 No se cumple
2 Se cumple insatisfactoriamente
3 Se cumple aceptablemente
4 Se cumple en alto grado
5 Se cumple plenamente

Tomando como referencia lo anterior, se recomienda adelantar las siguientes acciones:

1. Definir, en cada pregunta, la Frecuencia o número de veces que una respuesta obtuvo cada
uno de los valores establecidos en la tabla anterior.

Ejemplo: En una encuesta aplicada a 20 personas, la pregunta número 1 tuvo las siguientes
frecuencias:

Pregunta No 1
Valor Frecuencia
0 0
1 3
2 4
3 6
4 3
5 4

En caso de que una pregunta se haya dejado de responder, se debe asumir el valor 0.

2. Dividir cada frecuencia por el número total de encuestas aplicadas. Este resultado se debe dar
en términos porcentuales.

En el caso del ejemplo, estos porcentajes quedarían así:

24
Esta escala de valoración se encuentra en la parte inicial de cada Formato de Encuesta.
82 MANUAL DE IMPLEMENTACION

Pregunta No 1
Valor Frecuencia Porcentaje
(Frecuencia /Total de encuestas)
0 0 (0/20) 0
1 3 (3/20) 0,15
2 4 (4/20) 0,2
3 6 (6/20) 0,3
4 3 (3/20) 0,15
5 4 (4/20) 0,2

3. Multiplicar cada valor por el porcentaje determinado en el paso anterior, con el fin de hallar un
valor parcial para cada uno:
En el ejemplo, la situación sería:

Pregunta No 1
Valor Frecuencia Porcentaje Valor parcial
(Valor * Porcentaje)
0 0 0 0
1 3 0,15 0,15
2 4 0,2 0,4
3 6 0,3 0,9
4 3 0,15 0,6
5 4 0,2 1

4. Sumar los valores parciales para obtener el puntaje de la pregunta.

En el ejemplo, la sumatoria dará como resultado: 0 + 0,15 + 0,4 + 0,9 + 0,6 + 1 = 3,05

5. Repetir este mismo procedimiento para todas las preguntas que integran el cuestionario (se
recomienda trabajar las preguntas en el mismo orden en que se aplicaron).
6. Determinar el Puntaje Total sumando los puntajes obtenidos para cada pregunta y
divididiéndolos por el número total de preguntas realizadas.
En el caso del ejemplo, el total de la sumatoria de los puntajes por pregunta debe dividirse por 20.
Para adelantar los pasos 1 a 6 se sugiere utilizar un formato como el siguiente:

Tabulación Encuesta:
Componente:
Elemento:
FRECUENCIA Y PORCENTAJE DE VALORACIÓN PP
PREGUNTA 1 TOTAL P1 + P2 + Pn
0 1 2 3 4 5 F1+F2+Fn.
F
% (F/T)
P (V*%)
PREGUNTA n
F
%
P
PT
 MANUAL DE IMPLEMENTACION 83

En donde:
F Frecuencia, número de veces que una respuesta obtuvo el mismo valor
% Porcentaje, número de respuestas obtenidas por cada valor sobre el total de respuestas.
P Valor parcial que se obtiene de multiplicar el valor (0,1,2,3,4,ó,5) por el porcentaje.
PP Puntaje por pregunta, corresponde a la suma de los valores parciales.
TOTAL Número de encuestas aplicadas, que en todo caso, deberá corresponder a la sumatoria
de las frecuencias
PT Puntaje Total corresponde a la suma de todos los puntajes por pregunta

Interpretación de Resultados

Ubique el Puntaje Total (definido en el paso 6) dentro del rango que le corresponde de acuerdo
con la siguiente tabla:
Rango Criterios
Puntaje Total entre 0.0 y 2.0 Inadecuado
Puntaje Total entre 2.1 y 3.0 Deficiente
Puntaje Total entre 3.1 y 4.0 Satisfactorio
Puntaje Total entre 4.1 y 5.0 Adecuado

Para cada uno de los rangos se encuentra definido un criterio, que representa una valoración
cualitativa del Puntaje Total. Con base en esta valoración se interpretarán los resultados obtenidos
en cada una de las encuestas y se definirán las acciones que han de emprenderse.
Si se trata de una encuesta de diagnóstico, dependiendo del rango en que se encuentre ubicado el
elemento de control, se proponen las acciones para garantizar la existencia del elemento; si el ele-
mento se encuentra ubicado en los rangos inadecuado o deficiente, se deben proponer acciones
para el diseño e implementación del elemento; si se ubica en los rangos satisfactorio o adecuado, las
acciones definidas deben orientarse hacia el mejoramiento o mantenimiento del elemento.
En cuanto a las encuestas de Autoevaluación del Control, el análisis de resultados permite deter-
minar la efectividad del diseño y operación de cada componenete a fin de tomar las decisiones
relacionadas con la corrección o el mejoramiento de los mismos.
En aquellos elementos en los que se utilizaron encuestas de diagnóstico, los resultados de la
tabulación de las mismas se podrán comparar con los resultados de la Autoevaluación, determi-
nando con ello si las acciones propuestas permitieron su el mejoramiento o mantenimiento del
elemento, o si por el contrario éste no demostró ningún cambio.
Ejemplo: como resultado de tabular una encuesta de tres preguntas, se obtuvieron los siguientes datos:

Pregunta Valor 0 1 2 3 4 5 total PP

1 f 0 3 4 6 3 4 20 3,05
% 0 0,15 0,2 0,3 0,15 0,2
P 0 0,15 0,4 0,9 0,6 1
2 f 2 5 3 5 2 3 20 2,45
% 0,1 0,25 0,15 0,25 0,1 0,15
P 0 0,25 0,3 0,75 0,4 0,75
3 f 1 3 2 4 6 4 20 3,15
% 0,05 0,15 0,1 0,2 0,3 0,2
P 0 0,15 0,2 0,6 1,2 1
PT 2,88

Se observa que el puntaje total se ubica en el rango deficiente, por lo tanto, se deberán proponer
las acciones que permitan superar ese estado deficiente, procurando trabajar con mayor esfuerzo
en los aspectos indagados a través de las las preguntas que obtuvieron un menor puntaje parcial.