Creación de un prototipo de software basado en elcomponente de Autoevaluación institucional del Modelo

Estándar de Control Interno MECI

Jorge Enrique Castro Pescador

Especialización en ingeniería de SoftwareUniversidad Dsitrital Francisco José de Caldas

Bogotá D.C. Colombia25 de noviembre de 2016

Creación de un prototipo de software basado en elcomponente de Autoevaluación institucional del Modelo

Estándar de Control Interno MECI

Jorge Enrique Castro Pescador

DirectorAlexandra Abuchar Porras

RevisorJosé Ignacio Palacios

Especialización en ingeniería de SoftwareUniversidad Dsitrital Francisco José de Caldas

Bogotá D.C. Colombia25 de noviembre de 2016

Índice

Introducción 4

I Contextualización de la investigación 5

1. Descripción de la investigación 51.1. Titulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Estudio del problema de investigación 62.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2. Formulación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Sistematización del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Objetivos de la investigación 83.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

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

5. Marco de referencia 105.1. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1.1. Antecedentes y estado actual . . . . . . . . . . . . . . . . . . . . . . . . 105.1.2. Modelo Estándar de Control Interno . . . . . . . . . . . . . . . . . . . . 105.1.3. Marco conceptual de arquitectura empresarial . . . . . . . . . . . . . . . 125.1.4. The Open Group Architecture Framework . . . . . . . . . . . . . . . . . 12

5.2. Revisión sucinta sobre el lenguaje de arquitectura empresarial . . . . . . . . . . 135.2.1. Especificación de Archimate . . . . . . . . . . . . . . . . . . . . . . . . . 135.2.2. Metodología de desarrollo ágil Scrum . . . . . . . . . . . . . . . . . . . . 18

5.3. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3.1. Autoevaluación Institucional . . . . . . . . . . . . . . . . . . . . . . . . 205.3.2. Contexto de la autoevaluación institucional en el MECI . . . . . . . . . 205.3.3. Metodología estándar para la realización Autoevaluación Institucional . 21

5.4. Marco legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6. Aspectos metodológicos 246.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2. Método de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3. Fuentes y técnicas para la recolección de la información . . . . . . . . . . . . . 25

6.3.1. Fuentes primarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.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 287.1. Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8. Diseño de la Arquitectura Empresarial 31

9. Punto de vista del negocio 319.1. Punto de vista de la organización . . . . . . . . . . . . . . . . . . . . . . . . . . 319.2. Punto de vista de cooperación de actor . . . . . . . . . . . . . . . . . . . . . . . 329.3. Punto de vista de función de negocio . . . . . . . . . . . . . . . . . . . . . . . . 349.4. Punto de vista de proceso de negocio . . . . . . . . . . . . . . . . . . . . . . . . 359.5. Punto de vista de cooperación de proceso de negocio . . . . . . . . . . . . . . . 379.6. Punto de vista de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

10.Punto de vista de la aplicación 4110.1. Punto de vista de comportamiento de aplicación . . . . . . . . . . . . . . . . . 4110.2. Punto de vista de cooperación de aplicación . . . . . . . . . . . . . . . . . . . . 4210.3. Punto de vista de estructura de aplicación . . . . . . . . . . . . . . . . . . . . . 4310.4. Punto de vista de Uso de aplicación . . . . . . . . . . . . . . . . . . . . . . . . 45

11.Punto de vista Tecnológico 4711.1. Punto de vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . 4711.2. Punto de vista de uso de infraestructura . . . . . . . . . . . . . . . . . . . . . . 4811.3. Punto de vista de Implementación y despliegue . . . . . . . . . . . . . . . . . . 5011.4. Punto de vista de Estructura de información . . . . . . . . . . . . . . . . . . . 5111.5. Punto de vista de realización de servicio . . . . . . . . . . . . . . . . . . . . . . 5211.6. Punto de vista de Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

12.Extensión Motivacional 5512.1. Punto de vista de stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5512.2. Punto de vista de realización de objetivos . . . . . . . . . . . . . . . . . . . . . 5612.3. Punto de vista de contribución de objetivos . . . . . . . . . . . . . . . . . . . . 5812.4. Punto de vista de principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5812.5. Punto de vista de realización de requerimientos . . . . . . . . . . . . . . . . . . 5912.6. Punto de vista de motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

13.Extensión de Implementación y Migración 6213.1. Punto de vista de proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6213.2. Punto de vista de migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6313.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 6715.1. Historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

15.1.1. Primer Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6915.1.2. Segundo Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

15.2. Análisis de la metodología de software . . . . . . . . . . . . . . . . . . . . . . . 7715.2.1. Burndown chart del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 7715.2.2. Gráfica de velocidad del proyecto . . . . . . . . . . . . . . . . . . . . . . 78

15.3. Plataforma tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8015.4. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

16.Arquitectura de software 8116.1. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8116.2. Modelo de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8216.3. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

17.Metodología web 8517.1. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

17.1.1. Selección de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8517.1.2. Expectativa de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 8617.1.3. Expectativa de la organización . . . . . . . . . . . . . . . . . . . . . . . 86

17.2. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8617.2.1. Selección de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8617.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 9019.1. Aportes Originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9119.2. Trabajos o publicaciones derivadas . . . . . . . . . . . . . . . . . . . . . . . . . 91

20.Prospectiva del trabajo de grado 9120.1. Trabajos de investigación futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Bibliografia 93

21.Anexos 9421.1. Anexo 1 - Formato de entrevistas realizadas . . . . . . . . . . . . . . . . . . . . 9421.2. Anexo 2 - Procedimiento para la tabulación de encuestas e intepretación de

resultados del MECI [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3

IntroducciónLa 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óninstitucional 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 engeneral, el ente de regulación por defecto a nivel interno de una organización de carácterdescentralizado.

Siguiendo y tomando como base la definición del área, de sus funciones y los lineamientosque debe seguir, vigilados y presentes a la luz de la normatividad colombiana, se establecenciertos 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 implementacionesconcretas 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 puedautilizarse a partir de éste estándar.

Por esto, esta investigación pretende hacer uso de la disciplina de la ingeniería de softwarepara 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 detrabajo y herramientas tecnológicas que permitan solucionar el problema.

El problema de investigación que se espera resolver es la automatización del proceso debidoa que generalmente se realiza de forma manual o con el uso de múltiples herramientas nointegradas para la realización, consolidación, y análisis de resultados de las evaluaciones quepuede llevar en los retrasos de entrega de los resultados.

Esto se considera una propuesta favorable debido a que actualmente el concepto de invertiren una infraestructura tecnológica y de sistemas de información como apoyo en estos procesossuele ser de gran ayuda para la organización que desea que aquellas tareas que sean repetitivaso que presenten dificultades puedan ser solucionadas. La ingeniería de software como disciplinafundamental para este paso se realiza con rigurosidad y metodología.

La motivación académica y profesional busca investigar y conocer los insumos conceptualesnecesarios para resolver este tipo de problemas de forma asertiva. La consulta de nuevosavances tecnológicos motivan la puesta en practica de estos conceptos por medio de solucionesen el ámbito empresarial que son útiles y además deban contribuir como insumos para futurosproblemas de investigación con características similares.

4

Parte I

Contextualización de la investigación1. 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 quebuscan 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 estadode los planes y políticas en la organización. En el nivel externo, como herramienta de apoyopara la presentación de informes de gestión a entes de control nacional que se establecen segúnel 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 delMECI, dentro de toda la estructura del estándar que comprende otros módulos y componentesdefinidos.

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 comocontralorías de orden en el Distrito capital y a nivel Nacional. Existen implementaciones ensistemas de software que soportan la presentación de los informes y herramientas creadas porel estado y su funcionamiento se emplea para el control general en el nivel externo, pero anivel interno cada organización es responsable de decidir si desea soportar sus procesos enestas tecnologías.

Aquellas organizaciones que no desean soportar este proceso tienden a hacerlo de formamanual, y es necesario que se les otorgue una herramienta con las tendencias tecnológicasactuales para que sus tareas, generalmente operativas, puedan ser automatizadas y el enfoquede los involucrados cambie de realizar estas tareas a buscar mecanismos de mejora del propioproceso esto con el fin de reorientar las actividades de los analistas del área y a la vez promoveruna 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 uncaso de estudio y proponer un prototipo funcional para las organizaciones que tengan estascaracterí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 haconsiderado como un punto fundamental en las organizaciones maduras que buscan medir susprocesos 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 luegode que la evaluación se realice y todos los resultados parciales por área o por proceso seanorganizados y tabulados.

Un problema que surge a partir de esto es cuando la organización no tiene alineado esteproceso con las tecnologías de información, evidenciando que el proceso de consolidación dela información y la obtención de los resultados es realizada manualmente y no existe unmecanismo de comunicación conveniente entre los actores del proceso, causando en el futuroretrasos en los resultados para las áreas que lo requieren, como las que llevan a cabo un rol en elmejoramiento continuo de la entidad (planeación, control interno, dirección general), posiblesinconsistencias en los resultados, búsqueda de personal adicional temporal para agilizar elproceso y un retraso en la presentación de los informes de gestión a entes de control cuandoal entidad es de carácter descentralizado.

Las decisiones a tomar para controlar parte de este problema incluye la alineación delproceso 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 entrelos involucrados pueden ser modelados en un sistema de software que permitirá realizar lossubprocesos 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 levantamientode la información, las técnicas para el modelado del sistema de software, los detalles para lapuesta en producción, alineación con los procesos existentes de la empresa y las practicas parael 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 mantenerla 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 decontrol interno se verán afectados de la implementación de un prototipo que automaticelos 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 validaen 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ánindicadores verídicos que podrán ser interpretados por el equipo de control interno, y sese tomarán como apoyo para la toma de decisiones acerca de los planes y proyectos demejoramiento 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 adoptadopor diversas entidades de carácter Descentralizado, mediante la definición de la arquitecturaempresarial del proceso particular con el fin de proporcionar un mecanismo confiable acercade 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 decontrol 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 inicialpara identificar el contexto del problema.

2. Diseñar la arquitectura empresarial orientada al proceso de negocio de la autoevaluacióninstitucional gestionada por el área de control interno de la organización utilizando unametodología de desarrollo de arquitecturas ADM con el fin de expresar una definiciónde requerimientos acertada para la descripción del prototipo a construir.

3. Construir el prototipo funcional mediante el uso de una metodología de desarrollo desoftware ágil que permita gestionar el proceso de autoevaluación y otorgue resultadossobre 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 derealizar 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 yapoyen a las entidades reguladoras, el cómo se ejecutan en proyectos y planes, y la búsquedade resultados que apoyen la toma de decisiones debe siempre buscar la mejora de los proyectosrealizados con los recursos disponibles que aporta la misma sociedad y cuyo fruto debe serbeneficioso para ella[1].

Dentro de este conjunto de herramientas esta la autoevaluación institucional como unmecanismo de medición interno en cada organización.

El proceso actual que llevan las entidades publicas para el proceso de autoevaluacióninstitucional se realiza concretamente mediante el enfoque de encuestas, y que éstas deben serconsolidadas manualmente así como también la forma en la que se lleva a cabo el calculo de losresultados para su posterior análisis es un proceso que puede desviar la visión del analista quees la toma de decisiones. Por esto, se debe diseñar una herramienta que pueda representarun sistema capaz de colaborar con las áreas involucradas utilizando las tecnologías de lainformación, que modele los procesos operativos y entregue resultados parciales y totales enmenor tiempo comparado al proceso manual, y por consiguiente, permita a las áreas de controlinterno que adoptan el modelo MECI medir el cumplimiento de los objetivos organizacionalescon 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 seformalizan en la normatividad colombiana desde 1993 y una serie de reformas y actualizacionesen la cual la versión del MECI actual corresponde a la del año 2014. Desde entonces, la normaha buscado expresar las políticas y lineamientos que cumplan tanto en una escala de todala estructura administrativa[7], como de forma interna de cada organización orientándola acumplir 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 áreaorganizacional 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 lasRamas del Poder Público en sus diferentes órdenes y niveles, por la organización electoral, losorganismos de control, los establecimientos públicos, las empresas industriales y comercialesdel Estado, las sociedades de economía mixta en las cuales el Estado posea el 90% o más decapital 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óny seguimiento, y de comunicación. Los elementos de cada modulo se vienen actualizandosobre cada implementación del MECI, conformando versiones del estándar con el identificadordel 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 loselementos, actualizarlos o realizar modificaciones de los mecanismos de seguimiento, todos loscambios vienen dados por el conjunto de organismos de definen el estándar que anualmentese encuentran realizando revisiones a partir de informes y evidencias de las entidades que loponen 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 unaherramienta de apoyo para el control a la gestión publica, mediante mecanismos de evaluacióny seguimiento que permitan, de forma generalizada, ser aplicables para todas las entidadespú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ónde 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 seriede decretos, actualizaciones, normas y estándares las características que deben encontrarsepresentes en el control interno de las entidades y los diferentes enfoques implementales quepueden 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 objetivosinstitucionales 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 estableceuna estructura compuesta de dos módulos, seis componentes y trece elementos en un esquemagrá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 Humano1) Acuerdos compromisos y protocolos éticos2) Desarrollo de talento humano

b) Componente Direccionamiento Estratégico1) Planes, programas y proyectos2) Modelo de operación por procesos3) Estructura organizacional4) Indicadores de gestión5) Políticas de operación

c) Componente Administración del Riesgo1) Politicas de administración del riesgo2) Identificación del riesgo3) Análisis y valoración del riesgo

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

a) Componente Autoevaluación Institucional1) Autoevaluación del control y gestión

11

b) Componente de Auditoría Interna1) Auditoría interna

c) Componente Planes de Mejoramiento1) Plan de mejoramiento

3. Eje Transversal Información y Comunicación

a) Información y comunicación interna y externab) 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 decontrol, 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 principiode autogestión, es decir establecer acciones de la entidad a garantizar su función, verificarsey evaluarse a si misma, mantener una organización en sus procesos y otorgarle un sistema decomunicació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 sunegocio 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 parala 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 Arquitectode Software, quien define una arquitectura empresarial, es identificar como los implicados(stakeholders) y cómo los requerimientos que tengan deben ser conducidos durante desarrollodel sistema[9].

Las arquitecturas empresariales proveen una descripción formal del sistema tanto en suspropiedades estructurales como comportamentales y su evolución, y proveen un plan sobrecomo 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 permitela construcción de arquitecturas empresariales concretas, a partir de una metodología paradiseñar el estado objetivo, estos marcos de trabajo contienen un conjunto de elementos, unasemá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, laplaneación, la implementación y la gestión de una arquitectura orientada con las tecnologías dela información[9]. TOGAF define como “empresarial” a cualquier colección de organizacionesque tienen un conjunto de objetivos comunes, por ejemplo, una agencia gubernamental, unadivisión de una corporación, una corporación, o un área de una empresa. El concepto deArquitectura Empresarial es utilizada para denotar el todo de una organización, incluyendo sussistemas de información, procesos e infraestructura. Grandes corporaciones pueden desarrollar

12

y mantener un conjunto de arquitecturas empresariales, por esto se tienen las bondades deun 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 empresarialesincorporando un paradigma orientado al servicio que propone un principio organizativo enté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 organizarlos 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 deestructura 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 sondefinidos 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 elementosde 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), uncomportamiento (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 lossistemas, 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 accesiblesmediante 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; sedefine como una agrupación temporal de dos o más elementos estructurales, que trabajanjuntos para desempeñar un comportamiento colectivo; una interacción esta definida comouna 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 enlos 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 realizadospor 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 estructurageneral dentro de cada capa es similar, mismos tipos de conceptos y relaciones son usadaspero 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óny sus relaciones. Las entidades activas son sujetos (actores de negocio o roles de negocio) querealizan un comportamiento como procesos de negocio o funciones. El concepto de interfacesde negocio son utilizadas para especificar ubicaciones (físicas o lógicas) o canales donde losservicios que un rol ofrece al entorno pueden ser accedidos, ejemplo, el mismo servicio puedeser 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ónes el componente de aplicación. Este concepto es utilizado para modelar cualquier entidadestructura en la capa de aplicación, no únicamente componentes reusables pueden ser partede una o más aplicaciones, sino también aplicaciones de software completas o sistemas deinformación. Las interfaces de aplicación son los canales lógicos por los cuales los servicios deun componente pueden ser accedidos. El concepto de colaboración de aplicación es definidocomo 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íaes el nodo, este concepto es utilizado para modelar entidades estructurales en esta capa, sucomportamiento 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 sonofrecidos por un nodo y pueden ser accedidos por otros nodos o componentes de aplicación dela capa de aplicación. Los nodos pueden ser dispositivos o sistemas de software y se puedenrelacionar 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 arquitecturaempresarial, estas motivaciones influencian, guían y restringen el diseño. Se utilizan conceptoscomo 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 yel 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 unpaquete 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 losentregables, 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 dela arquitectura de una empresa, reconoce los conceptos de stakeholders y manejadores, lasmetas de los stakeholders deben ser traducidos dentro de la arquitectura de la organización yesta debe reflejar como los requerimientos son realizados por servicios, procesos y aplicacionesde software en las operaciones diarias. Los elementos “core” de la arquitectura se encuentranrelacionados con elementos motivacionales por medio de los requerimientos, una relación deejemplo entre el meta modelo y la extensión motivacional es que un actor de negocio puedeser 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 aspectosde la arquitectura, en términos de decisión, información o mostrar detalles para todos losstakeholders.

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 lenguajeArchimate, que provee un conjunto de conceptos independientes, y una representación gráficapara 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 crearun nuevo producto definido a través de una visión del proyecto y entregables que aportan valorrápidamente durante su duración. La fuerza clave esta en el uso de pequeños equipos motivadosconcentrados en realizar tareas cortas concentradas durante ciclos de trabajo denominadosSprints.[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 (Productbacklog) el cual contiene una lista de requerimientos del negocio y del proyecto escritas enforma 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 crearincrementos de ese producto, cada integrante puede tener tareas asignadas con tiempos enhoras 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 miembrosdel equipo para discutir el progreso diario. Al final del sprint, se realiza una reunión durantela cual el dueño del producto y los interesados más relevantes evalúan una demostración delentregable. El dueño del producto acepta el entregable solo si cumple con los criterios deaceptación definidos en las historias de usuario. El ciclo del sprint termina con una reuniónde retrospectiva donde el equipo discute las formas de mejorar el proceso y el desempeño dela 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 lavisió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 actualy 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 losplanes, 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óninstitucional[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íasinternas.

El análisis de los resultados de la autoevaluación y la toma de decisiones orientadas ala 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 aseguir por parte de las áreas de la organización para garantizar el logro de los resultadosprevistos”[7].

Todos los niveles y áreas de la organización: “Evalúan periódicamente los avances desus planes de acción y deben reportarlos a la Oficina de Planeación, así como tambiénparticipar en los mecanismos que la oficina de control interno disponga para la ejecuciónde la autoevaluación”.

La oficina de Control Interno o quien haga sus veces: “Debe evaluar el sistema de controlinterno de la entidad, con énfasis en la existencia, funcionamiento y coherencia de loscomponentes y elementos que lo conforman y presentar informes a la Dirección y alComité 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 yseguimiento 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 yproyectos, 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 deMejoramiento.

20

El componente de autoevaluación institucional se enfoca de forma general tomando encuenta 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ódicamentecon el fin de entregar resultados sobre la gestión. Esto conlleva un conjunto de beneficios parala 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óna la alta dirección.

El siguiente esquema representa el contexto general que se aborda dentro del MECI parael 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 implementadosen 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 elnivel de funcionarios es bastante numeroso para la realización de Entrevistas estructuradas yel alcance de la autoevaluación es amplio, igualmente si la alta dirección desea minimizar eltiempo para la obtención de la información. Bajo este enfoque no se requiere experiencia porparte de los evaluadores y se reduce el numero de reuniones y coordinación para obtener losresultados.

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, dichametodología cuenta con una serie de pasos secuenciales que abarcan desde la planeación eintencionalidad 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 dejuntas, envío de información y realimentación con respecto a la evaluación realizada enel periodo anterior que permita establecer planes de mejora del proceso para el nuevoperiodo.[7]

21

2. Definir la organización de la autoevaluación, bien sea por procesos, por áreas o porproyectos, 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 oportunidadde mejora, (estos dos últimos campos son opcionales y dependen de la organización dela evaluación).[5]

Las preguntas se encuentran orientadas a la organización de la evaluación, biensea por procesos o por áreas, un conjunto de preguntas pueden ser evaluadas paratodos los procesos y para procesos específicos.La escala definida por el estándar es de tipo cualitativo para el evaluador: Nosabe, No se cumple, Se cumple insatisfactoriamente, Se cumple aceptablemente, Secumple en alto grado, Se cumple plenamente. y de tipo cuantitativo para el analistade 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 accionescorrectivas o de mejoramiento. (para este procedimiento se toma en cuenta el anexo 2del 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 ylas acciones correctivas o de mejoramiento.

6. Analizar los resultados de la Autoevaluación y adoptar las acciones correspondientesque garanticen mantener la orientación de la entidad publica hacia el cumplimiento desus objetivos institucionales.

5.4. Marco legal

Existe un fundamento legal que soportan los mecanismos de Autocontrol, Autorregulacióny Autogestión dentro de las áreas de Control Interno, Así como su reconocimiento y lasfunciones que éstas deben cumplir dentro de las entidades de carácter publico las cuales serigen a nivel nacional.

Ley 87 de 1993: Se establecen normas para el ejercicio del control interno en las entidadesy organismos del estado; entre los objetivos y aspectos del sistema de control interno sedestacan[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 elcontrol.

• 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ónAdministrativa del Sector Público, y establece evaluaciones periódicas por los comitésde desarrollo administrativo que evalúen los sistemas de información actuales que seencuentren 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 alproceso planificador y facilitando la retroalimentación de las actividades, la tomade decisiones y la reorientación de las acciones para garantizar el logro de losresultados previstos.

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

• Autoevaluación a la gestión: Elemento de control, que basado en un conjunto deindicadores de gestión diseñados en los planes y programas y en los procesos de laentidad 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 sobrelas cuales se deben tomar los correctivos que garanticen mantener la orientaciónde la entidad pública hacia el cumplimiento de sus objetivos institucionales.

Manual de Implementación MECI 2005 y MECI 2014. El manual de ImplementaciónMECI, 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ónen 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 etapasdefinidas.

• Proceso de actualización del modelo en caso de que la organización ya tenga unaimplementació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íasde 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ácterdescentralizado, 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 queinciden 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 delcontexto planteado.

El tipo de investigación sobre la cual se determinará el nivel de profundidad y la forma enque se abordaŕa el problema es de tipo descriptivo, realizando una previa caracterización detodos los hechos y situaciones presentadas dentro de un entorno empresarial y a partir de laexperiencia 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 elproceso y que actitudes se evidencian frente a este. La observación juega un papel importantepuesto que permitirá describir con claridad todo el flujo del proceso, los actores externos aeste y la forma en que los involucrados, que son los principales gestores de comunicación yejecutores puedan resultar beneficiados.

Previas investigaciones se abordan acerca de las técnicas para la medición de objetivosempresariales y además estándares conocidos para este proceso, por tanto los antecedentespresentados sirven como apoyo para esta investigación y permitirán ampliar las bases y losfundamentos teóricos de éste estudio.

La recolección de información se centrará en la norma Colombiana como uno de los ejescentrales para la creación de la herramienta, debido a que el Modelo Estándar de ControlInterno tiene su fundamento en los trabajos realizados y la experiencia de la gestión de laadministración pública a lo largo de las ultimas tres décadas en el estado Colombiano detodas las entidades de carácter descentralizado que hacen parte de este; y cuyas experienciasy prácticas son recopiladas en sus manuales respectivos y además exigidas por el fundamentolegal que le precede. La metodología del componente a analizar se encuentra soportado ydocumentado en gran medida y el conocimiento acerca de este se amplia con nuevas versionesdel estándar.

Se espera que las evidencias y las situaciones que se presenten luego de que se implementeen una organización de este tipo y con base en la hipótesis planteada puedan ser la base parael 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ónde información apropiadas podrán obtener información acerca de los involucrados de todo elproceso 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 quese deberán abordar.

24

Estas características particulares podrán analizarse desde el marco teórico general y delmarco legal definido empleando al deducción con el fin de establecer sus relaciones con lainformación adquirida y la generación de un prototipo concreto que se encuentre orientado auna 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óninicial 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 obtenidacon la experiencia personal para obtener un cuerpo conceptual inicial que será refinado conlas 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óndel 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 enque se emplean.

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

Herramientas tecnológicas disponibles para la implementación de la herramienta, y nivelde 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 pararealizar 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 inicialmentey otros hechos que puedan servir para identificar situaciones subyacentes del problema deinvestigación.

6.3.2. Fuentes secundarias

La recopilación de la información secundaria parte de tres fuentes secundarias clave enla realización del estudio, la primera corresponde a toda la información relacionada con elproceso y el moldeamiento de los requerimientos dentro del entorno planteado de forma quela información obtenida se encuentre relacionada con el contexto de la gestión publica. Estoincluye:

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 derealizar 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 yartí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íapara el desarrollo de software especifico consistente al problema planteado:

Realizar consultas bibliográficas sobre casos de estudio acerca de las metodologías dedesarrollo 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 laque se va a realizar la solución del problema, y mostrar el aprendizaje obtenido en el desarrollodel 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 cadacaso:

Fuentes primarias de Información: Para el caso de las entrevistas se procede a consolidarla información y analizarla y representar el conocimiento obtenido a través de modelosvisuales como mapas conceptuales y documentos de tipo descriptivo y posteriormenteexpresar las necesidades especificas en una sección de requerimientos formal. En el casode las encuestas se debe consolidar la información y utilizar técnicas estadísticas detabulación y representarla en los gráficos correspondientes.

26

Con la información obtenida a partir de las fuentes secundarias relacionadas de consultasacerca 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 uncronograma orientado al desarrollo del prototipo.

Se plantea que el tratamiento de la información y la obtención de las fuentes de informaciónse establezcan tanto al inicio como en toda la duración del proyecto de investigación, es decirlas actividades de recolección y el tratamiento de la información deben continuarse realizandohasta que la definición de todo el contexto del proyecto se encuentre definido en su totalidad.

27

Parte II

Desarrollo de la investigación7. 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 debetener en cuenta. Al ser una solución orientada a una herramienta de enfoque de encuestas nose opta por recolectar información a través de encuestas.

Realización de entrevistas

Grupo objetivo

Representantes del proceso en la entidadEspecialistas de control internoEspecialista del área de sistemasrepresentantes 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 IDIPRONForma de contacto Entrevista cara a cara

Muestra 7 entrevistasTipo de pregunta Todas las preguntas AbiertasForma 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 delproceso:

Para ver la estructura de la entrevista remitirse al anexo 1

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

Se requiere una herramienta que otorgue resultados al momento que se desee consultarbien 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 losusuarios el objetivo de la autoevaluación.

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

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 deimplementación.

Es recomendable que se utilicen tecnologías libres apoyando Política de Promoción yUso 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 yno 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 tomemá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óndel proceso:

• Toda la organización hace parte del proceso, juegan el papel de evaluadores de suspropios procesos y des los cuales se involucran.

• Los entes externos como entes de control son informados a través del área de controlinterno

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ónes transversal a todos los procesos y tiene en cuenta aspectos relacionados de loscuales se dan una valoración por parte de los involucrados del proceso que gestionay de los involucrados que colaboran.

Herramientas actuales utilizadas: descripción de las herramientas, el uso y la forma enque 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ónde preguntas.

Cronograma del proceso, vigencia y objetivo de los resultados, tipo de resultado que sedesea 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ónactividades que mejoren las falencias en los procesos para la vigencia siguientede acuerdo a los planes de mejoramiento, los resultados deben presentarse a ladirección general.

Herramientas tecnológicas disponibles para la implementación de la herramienta, y nivelde 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 decomputo.

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

• Incomodidades por tener que descargarla manualmente, guardar y enviarla porcorreo electrónico sin notificación de recibido. Desgaste para consolidar y tabularlas encuestas.

30

8. Diseño de la Arquitectura EmpresarialEl 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 dela organización definiendo el producto Valueme, Herramienta de apoyo para la realización dela autoevaluación institucional basada en el MECI.

9. Punto de vista del negocioEl 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 actoresde 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 yresponsabilidades 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 involucradosse 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 suentorno, es útil determinando dependencias externas y colaboraciones y muestra la cadena devalor 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 mostrarinteracciones 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 comoevaluadores de cada uno de sus procesos; el actor de seguimiento, quien es el responsablede presentar los indicadores tiene el rol de ser el analista del proceso, juntos conforman lacolaboració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 elrepositorio 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 unaorganizació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 delas actividades primarias que desempeña, independientemente de los cambios organizacionaleso desarrollos tecnológicos. Por lo tanto, la arquitectura de funciones pueden ser similares encompañías con actividades del mismo mercado. Esto provee una visión de las operacionesgenerales de la compañía, y puede utilizarse para identificar competencias necesarias o laestructura 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 resultadosde las encuestas y realizar el análisis de los resultados para presentar el informe a la altadirecció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 nively 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 unproceso 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 denegocio para presentar los resultados en tiempo real. Los subprocesos son la realización de laencuesta, que parte de un evento como la solicitud de la evaluación por parte del director delproceso, la consolidación y tabulación de los resultados y su posterior análisis, el evento definalizació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ónentre uno o más procesos de negocio con cada uno y/o con su entorno. Provee las dependenciasentre 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 encuestay 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 informecon indicadores, ambos procesos son realizados por dos roles, el evaluador y el analista en lalocalizació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 clienteo las las partes externas involucradas y muestra la composición de uno o más productos entérminos de los servicios, contratos o acuerdos. Puede ser utilizado para mostrar las interfacesa través de las cuales este producto es ofrecido, y los eventos asociados con el producto. Estepunto de vista es usado típicamente en el desarrollo para diseñar un producto a partir de losservicios 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 pararealizar el proceso de autoevaluación institucional, su valor está en que puede gestionar larecepción, consolidación y tabulación de encuestas automáticamente, y presentar informesen tiempo real, aún si la todas las evaluaciones por parte de los involucrados no se hayanrealizado. Además permite gestionar el cronograma general del proceso y comunicar a todoslos evaluadores información mediante correo electrónico y noticias en el portal a través detoda la duración del proceso.

39

Figura 9.12: modelo de producto

40

10. Punto de vista de la aplicaciónEl 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ónreusables, 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 deuna aplicación, es útil para diseñar el comportamiento principal de aplicaciones o componentese 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, componentesy elementos a los que pertenece la evaluación, el banco de preguntas y los tipos deevaluaciones, 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óna los evaluadores acerca del proceso y enviar los informes de resultados a todos losinvolucrados.

El componente autenticador de usuarios debe proveer información sobre los evaluadoresy analistas y denegar o permitir accesos a llenar una evaluación según el cronograma deactividades.

41

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

ValueMe representa el componente de acceso que permite configurar y comunicarse conlos 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 componentesen 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 deservicios 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 parala interfaz de comunicación visible para el usuario final y Back Office que representará laarquitectura 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 ocomponentes 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 delos 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ámetrosde 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 indicadoresde 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 odenegar accesos según los tiempos establecidos en el cronograma.

Comunicación:

• Provee notificaciones, información e indicadores de resultados acerca del proceso aValueMe y este a todos los involucrados (usuarios registrados).

• requiere de los indicadores de resultados sobre la evaluación del analizador deresultados.

Organizador de cronograma:

44

• Provee el control de acceso para los usuarios según los tiempos establecidos parala 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 soportaruno o más procesos de negocio, y como van a ser utilizadas por otras aplicaciones. Puedeser utilizada en el diseño de una aplicación para identificar los servicios requeridos por losprocesos de negocio y otras aplicaciones, o en el diseño de procesos de negocio describiendolos 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ónpropuestos: recepción de evaluaciones y presentación de informes, y como estos servicios deaplicación son usados los procesos de negocio definidos y se definen los componentes candidatosque realizan estos servicios de aplicación.

Figura 10.8: Modelo de uso de aplicación

46

11. Punto de vista TecnológicoEl 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 dehardware 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. (sistemasoperativos, 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, queserá en el dominio de la compañía donde se despliega el producto, los nodos de software ylos dispositivos cliente soportados por la aplicación serán ubicados dentro de esta localizaciónfisicamente en la infraestructura que presente la entidad. El protocolo de comunicación entreel cliente y el producto será a través de TCP/IP, implementando el protocolo de aplicaciónhttp. Todos los dispositivos que dispongan de un navegador web y una conexión a internetpodrá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 deaplicaciones ejecutado bajo un Sistema Operativo anfitrión, un sistema gestor de bases dedatos NoSql y el producto de software.

Software Versión DescripciónUbuntu Server 14.04 - 16.04 Sistema Operativo Anfitrión GNU/Linux

Apache Tomcat 7.0.55 Contenedor de Aplicaciones java basado en servletsZimbra 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 soportadaspor la infraestructura de software y hardware: los servicios de infraestructura son entregadospor los dispositivos, los sistemas de software y redes son entregados a las aplicaciones. Estepunto de vista juega un rol importante en el análisis del rendimiento y la escalabilidad ypuede ser usado para determinar requerimientos de rendimiento y calidad en la infraestructurabasado 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 laaplicació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 aplicacionesson realizadas sobre la infraestructura. Esto implica el mapeo de aplicaciones (lógicas) ycomponentes en artefactos (físicos). Esta vista juega un papel importante en el análisis delrendimiento y la escalabilidad debido a la relación entre la infraestructura y el mundo lógicode 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 nodode servidor de aplicaciones, el componente de comunicación va a ser realizado por el nodoservidor de aplicaciones y tiene una relación de asociación con el nodo servidor de e-mail queproveerá las configuraciones de software específico para el envío de notificaciones, resultadose 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 tradicionalescreados en el desarrollo de la mayoría de sistemas de información, muestra la estructura deinformación usada en la empresa o un proceso específico o aplicación en términos de los tiposde 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 resultadoy el cronograma de actividades, los objetos de aplicación son la evaluación concreta que es laencuesta, el resultado representado en un indicador y el cronograma de actividades para cadaperiodo de evaluación. La encuesta se encuentra asociada a un usuario, tiene un conjunto depreguntas 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 serviciosde negocio son realizados por los procesos subyacentes (y algunas veces por componentes deaplicaciones), forma un puente entre la vista de productos de negocio y la vista de procesosde 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 resultadosasignados a componentes de aplicación que serán de soporte para dichos proceso. Los procesosde negocio son realizados de forma secuencial y la realización de todos proveen los serviciosde 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 arquitecturaempresarial 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 elconjunto 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 estructurales que cada capa dedicada expone por medio de una relación de “realización” una capa deservicios, las cuales serán “usadas por” la siguiente capa dedicadas. A partir de esto se puedeseparar la estructura interna y la organización de cada capa dedicada de su comportamientoexterno 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 sonintegrados 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 serviciosde aplicación específicos que a su vez son realizados por componentes de aplicación definidospara la arquitectura del sistema de software. Los componentes se encuentran soportados enservicios de infraestructura realizados por nodos de infraestructura y aplicaciones de softwareconcretas.

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 altonivel 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 laentidad, y cuya misión se es realizar una evaluación de la organización a nivel interno, presentacomo debilidad el desconocimiento del proceso y para qué puede llegar a ser importante, ensus fortalezas se encuentran la experiencia sobre las tareas que llega a cabo, los objetivos quepretenden fortalecer esa experiencia es crear un sistema de realimentación de la evaluación, ydisminuir el desconocimiento con información acerca del proceso y su importancia.

El modelo de analistas cuyo stakeholder corresponde al equipo de control interno de laentidad tiene como misión realizar el proceso de autoevaluación y medir el cumplimientode los objetivos de la organización, varias debilidades se evidencian sobre cómo se lleva acabo el proceso de consolidación de resultados y tabulación, por eso de pretende atacar estasdebilidades automatizando el proceso en las tareas operativas y facilitando la generaciónde reportes, a su vez que permite mejorar el sistema de control interno del componente deautovaluació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 enobjetivos más concretos, y la refinación de estos objetivos en requerimientos o restricciones quedescriben las propiedades que deben cumplirse para realizar estos objetivos. El refinamiento deestos objetivos se realiza mediante la relación de agregación. El refinamiento de los objetivosen 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 dosobjetivos relacionados a la automatización del proceso de autoevaluación, estos objetivosconcretos permiten evidenciar los requerimientos correspondientes que finalmente apunten aun 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 lasrelaciones de influencia entre los objetivos y los requerimientos. Las vistas resultantes puedenser utilizadas para analizar el impacto que los objetivos tienen entre sí y determinar conflictosentre 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 requerimientoobtenido a partir de un objetivo puede afectar de forma positiva o negativa otros objetivosrelacionados.

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 queson relevantes en el diseño del problema concreto, incluyendo los objetivos que motivan estosprincipios. Adicionalmente, las relaciones entre principios y sus objetivos pueden modelarse apartir 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 comodidady 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 objetivosorganizacionales, 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 delos requerimientos por los elementos claves como los actores de negocio, los servicios, procesosy aplicaciones de negocio. Típicamente, los requerimientos surgen a partir de la refinación delpunto 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 requerimientosque realizan uno o más objetivos, para este caso el objetivo se relaciona con la realizaciónde reportes y estado del proceso, donde se presentan dos requerimientos que realizan esteobjetivo. Adicionalmente se presentan restricciones o requerimientos refinados derivados delos 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 parcialdel aspecto motivacional relacionando los stakeholders, su principios primarios, los principiosque son aplicados y los requerimientos principales en los servicios, procesos, aplicaciones yobjetos.

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 elequipo de control interno y sus valoraciones, para cada una de ellas se asocia a un objetivo quefinalmente debe ser realizado por uno o más requerimientos, un requerimiento puede realizardos objetivos y fortalecer valores de varios stakeholders simultáneamente que se relacionanpor 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 cambioen 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 laarquitectura empresarial) tiene consecuencias significativas en el corto y largo plazo para elcrecimiento de la estrategia y las decisiones subsecuentes del proceso de realización. Algunosaspectos 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 tareasque 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 trabajary 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 aceptadopor 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 procesomediante 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 paraespecificar la transición de una arquitectura existente a una arquitectura deseada. La plateaes un estado relativo de la arquitectura que existe en un tiempo limitado, una brecha es unaunidad 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óndel 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 contenertodos los lineamientos para la gestión de la evaluación mediante enfoque de encuesta ygeneración de reportes básicos.

2. La segunda platea corresponde a un sistema mejorado de comunicación entre todos losparticipantes y realimentación y valoración de la evaluación.

3. La tercera platea incluye otros mecanismos empleados en el estándar para realizar laautoevaluació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 yproyectos a las partes de la arquitectura que ellas implementa. esta vista permite modelar elalcance de los programas, proyectos y actividades en términos de las plateas que son realizadaso los elementos de la arquitectura individual que son afectados. Adicionalmente, la forma enque los elementos son afectados pueden se indicados anotando las relaciones. Este punto devista puede ser utilizado en combinación con los puntos de vista de programas y proyectospara soportar la administración del portafolio.

El punto de vista de implementación y migración se sitúa para relacionar objetivos denegocio (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 paquetede trabajo busca satisfacer con los requerimientos planteados en los anteriores puntos de vistapara conformar la plataforma de lanzamiento funcional inicial. Se presenta el iterable, y lasplateas y brechas en sus futuras versiones, localizada en un dominio web, cuyos usuariosprincipales 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 basadaen el Modelo Estándar de Control Interno MECI, ValueMe - Valórame, una herramienta deapoyo para la consolidación, gestión y entrega de resultados del proceso de autoevaluacióninstitucional.

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

65

14. Cierre de la definición de la arquitectura empresarialLa 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 lossistemas 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 devista, identifican claramente el proceso de negocio que representa, la estructura de aplicacióny aspectos tecnológicos a tener en cuenta, su influencia para todos los involucrados de laorganización y el proyecto que se espera ejecutar para integrarse con las tecnologías de lainformación.

66

15. Desarrollo del plan de trabajo bajo ScrumLa 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 lanzamientodel aplicativo con la finalización de los requerimientos iniciales. Para este lanzamientose programaron 3 iteraciones (Sprints):

• 1 sprint: 4 semanas: (14/07/2016 - 11/08/2016) Diseño del esquema de la base dedatos, 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 lanzamientodel aplicativo con reportes y ajustes a medida.Para este lanzamiento se programan 2iteraciones (Sprints)

• 1 sprint: 4 semanas: (22/09/2016 - 21/10/2016) Notificaciones y componente decorreo 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 actividadesque define el paquete de trabajo:

1. Planear las entregas: Se establecen dos entregas la primera entrega final contiene losrequerimientos iniciales de la aplicación para ser puesta en producción. La segundaentrega 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 laplataforma.

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 organizarlasen 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 usuarioNombre Cuenta de usuarioEsfuerzo 13.00Descripción Como usuario del sistema debo tener acceso por medio de una cuenta

de usuario que me identifique dentro del sistemaCriterios deaceptación

rutas de acceso : El sistema debe proporcionar el acceso mediante lapagina principal y autenticación en cualquier dirección url

Tareasasociadas

1 - Creación de la estructura de base de datos.

Tipo Historia de usuarioNombre Edición de categoriasEsfuerzo 8.00Descripción Como analista debo tener la posibilidad de editar los procesos y la

estructura MECI de la plataforma sin afectar las encuestas realizadasni los usuarios existentes.

Criterios deaceptación

Edición de categorias : Al editar un atributo de la categoria, esta debeverse relfejada en las cuentas de usuario, encuestas, evaluaciones ycategorias de las preguntas.

Tareasasociadas

32 - Eliminación de categorias. 4 - Edición de categorias en la jerarquia.

Tipo Historia de usuarioNombre Vista jerarquica de categoriasEsfuerzo 5.00Descripción Como analista deseo ver los procesos que se evalúan categorizados

según la jerarquia de la entidad verlos de forma organizada.Criterios deaceptación

Jerarquia Adyacente : Cuando el usuario desee seleccionar el detalle deuna categoria se debe mostrar en diagrama organizacional lascategorias adyacentes en la jerarquia.

Tareasasociadas

6 - Añadir vista jerarquica en categorias.

69

Tipo Historia de usuarioNombre Cuentas de usuario por procesoEsfuerzo 3.00Descripción Como evaluador de un proceso de la entidad, mi cuenta debe

encontrarse relacionada con ese proceso y el mecanismo deautenticación es el correo electronico del área que gestiona el proceso

Criterios deaceptación

asignación de cuenta : El correo electronico debe asignarse por área ydeben haber multiples cuentas de usuario asignadas a procesos de laentidad.

Tareasasociadas

5 - Asignación de usuarios a procesos.

Tipo Historia técnicaNombre Gestión de cuentasEsfuerzo 5.00Descripción Todos los usuarios deben tener la posibilidad de cambiar su contraseña

del sistema, el usuario analista puede gestionar todas las cuentas deusuario

Criterios deaceptación

cambio de contraseña : El usuario que cambie la contraseña deberá sernotificado via correo electronico

Tareasasociadas

8 - Función de recuperar contraseña.

Tipo Historia de usuarioNombre Manejo de roles y permisosEsfuerzo 5.00Descripció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 decada tipo de usuario

Criterios deaceptación

Modificación de roles : Al modificar los roles de una cuenta de usuario,los accesos deben ser reflejados en la proxima autenticación

Tareasasociadas

2 - Configuración de permisos. 3 - Manejo de roles.

70

Tipo Historia técnicaNombre Parametros de configuraciónEsfuerzo 8.00Descripció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 deaceptación

Parametros : Las configuraciones de parametros deben estructurar laherramienta de forma que pueda establecerse el proceso por área, porproceso, por usuario y ajustarse a la estructura del meci, nuevoscomponentes, elementos y modulos.

Tareasasociadas

33 - Parametro de vista principal. 7 - Parametros de categorias.

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

Tipo Historia de usuarioNombre Escalas de valoraciónEsfuerzo 3.00Descripción Como analista debo adoptar las metricas de evaluación propuestas en el

MECI para que se encuentren disponibles en la plataformaCriterios deaceptación

Escala MECI : Cuando un evaluador repsonda una pregunta de laevaluación la escala debe corresponder al estandar: no sabe, no secumple, se cumple insatisfactoriamente, se cumple aceptablemente, secumple en alto grado, se cumple plenamente.

Tareasasociadas

19 - Establecer escala de valoración

Tipo Historia de usuarioNombre Campos personalizadosEsfuerzo 8.00Descripción Como evaluador puedo establecer campos personalizados para la

encuesta que considere relevantes en la evaluación de los procesos.Criterios deaceptación

Tipos de campos : Cuando un analista desee crear un campopersonalizado debe escoger entre encabezado y contenido (porpregunta) y de tipo: selección multiple o campo abierto de texto

Tareasasociadas

18 - Asociacion con las encuestas 16 - CRUD campos personalizados 17- Tipos de campos personalizados

71

Tipo Historia de usuarioNombre Asignación de encuestasEsfuerzo 3.00Descripción Como usuario evaluador debo encontrarme asignado al proceso de la

entidad del cual evaluo en la encuestaCriterios deaceptación

Asignación de unica categoria : Cada usuario puede completar laencuesta unicamente del proceso o categoria que se encuentra asignado

Tareasasociadas

11 - Cambiar asignación de encuesta

Tipo Historia de usuarioNombre Herramienta de documentaciónEsfuerzo 5.00Descripción Se debe implementar una herramienta de documentación que muestre

al usuario todas las acciones disponibles en el sistema y muestrerespuestas a las preguntas comunes.

Criterios deaceptación

Plataforma : La platafoma de documentación debe estar accesible desdela herramienta con enlaces de cada modulo.

Tareasasociadas

9 - Herramienta Web Dokuwiki 10 - Estilo visual

Tipo Historia técnicaNombre Validaciones de las encuestasEsfuerzo 3.00Descripción El sistema debe validar los campos de la encusta obligatorios, el

numero de encuestas permitidas por usuario, los campos obligatorios enlas categorias y los campos unicos

Criterios deaceptación

Respuestas requeridas : Todas las preguntas deben ser completadasEncuestas por usuario : El usuario puede completar más de unaencuesta siempre que no supere el limite establecido por un parametrode configuración general.

Tareasasociadas

15 - Validación del campo de valoración

72

Tipo Historia de usuarioNombre Formulación de encuestasEsfuerzo 13.00Descripción Como analista debo crear el conjunto de encuestas por procesos en la

entidad, y la herramienta me permita asignar preguntas comunes paravarias encuestas independientemente del proceso.

Criterios deaceptación

una pregunta multiples encuestas : Cuando el analista desee crear laspreguntas, se deben mostrar los procesos que aplican para las preguntasy establecer la misma pregunta en varias encuestas.Creación automatica : Las encuestas que no existen se deben crearautomaticamente cuando se cree una pregunta que involucre lasencuestas

Tareasasociadas

13 - Edición de encuestas 12 - Creación de preguntas 14 - Edición depreguntas

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

Tipo Historia de usuarioNombre Estructurar el MECIEsfuerzo 5.00Descripción Como analista debo parametrizar el modelo estandar de control interno

en el aplicativo acorde a los criterios de evaluación que emplea laentidad

Criterios deaceptación

Categorias especificas : Se pueden establecer categorias del meciespecificos de evaluación si la entidad omite modulos, componentes oelementos en el proceso.

Tareasasociadas

34 - Enlace principal MECI

Tipo Historia de usuarioNombre Edición de categoriasEsfuerzo 8.00Descripción Como analista debo tener la posibilidad de editar los procesos y la

estructura MECI de la plataforma sin afectar las encuestas realizadasni los usuarios existentes.

Criterios deaceptación

Edición de categorias : Al editar un atributo de la categoria, esta debeverse relfejada en las cuentas de usuario, encuestas, evaluaciones ycategorias de las preguntas.

Tareasasociadas

32 - Eliminación de categorias. 4 - Edición de categorias en la jerarquia.

73

Tipo Historia de usuarioNombre Manejo de cronogramaEsfuerzo 5.00Descripción Como analista debo poder manejar el cronograma por vigencia para ver

las fechas de evaluación de todas las vigencias y establecer fechas deacceso a usuarios por vigencia.

Criterios deaceptación

Vigencia activa : Unicamente pueden tener acceso los usuarios acompletar la encuesta en una vigencia activa y que corresponda con lafecha actual.

Tareasasociadas

22 - Cronograma por vigencia

Tipo Historia de usuarioNombre Ver progreso de las evaluaciónesEsfuerzo 5.00Descripció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 deaceptación

Vista de progreso general : El analista debe ver el estado de losusuarios que realizaron encuestas para todas las vigencias.

Tareasasociadas

23 - Progreso de los participantes

Tipo Historia de usuarioNombre Modulo de resultados basicoEsfuerzo 13.00Descripción Como analista debo tener acceso a un conjunto de resultados generales

de la consolidación y tabulación de las encuestas que me permitanevaluar el proceso de la entidad.

Criterios deaceptación

Resultados consolidados: Los resultados consolidados solo puedenobtenerse a partir de las encuestas realizadas en una vigencia yorganizadas por la estructura MECI.

Tareasasociadas

20 - Resultados totales

74

15.1.2. Segundo Release

1 Sprint (22/09/2016 - 21/10/2016) numero de historias de usuario realizadas: 4

Tipo Historia de usuarioNombre Reporte IndividualEsfuerzo 5.00Descripció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 deaceptación

Acceso a resultados individuales: El analista es el unico rol que puedever los resultados por cuenta de usuario.

Tareasasociadas

25 - Resultado por cuenta

Tipo Historia técnicaNombre Control de encuestas por cuentaEsfuerzo 8.00Descripción La herramienta debe contemplar la posibilidad de que cada cuenta

pueda completar más de una encuesta por vigencia relacionada almismo proceso.

Criterios deaceptación

Consolidación de resultados: Los resultados por cuenta debenconsolidarse para todas las encuestas realizadas, asimismo en resultadosconsolidados por proceso.

Tareasasociadas

27 - Control de parametros de cuenta

Tipo Historia de usuarioNombre Comparación de resultadosEsfuerzo 8.00Descripción Como analista debo poder ver los resultados de diferentes procesos

filtrados en modulos, componentes y elementos para comparar lasvaloraciones de aspectos similares entre procesos relacionados

Criterios deaceptación

Vista independiente: Los resultados de la consolidación deben ser engraficos independientes del proceso base y de los proceso(s) a comparar.

Tareasasociadas

24 - Comparación por proceso

75

Tipo Historia técnicaNombre Notifcaciones por correo electronicoEsfuerzo 5.00Descripción El sistema debe notificar via correo electronico acciones relacionadas

con el evaluador como cambios de contraseña, activaciones y realizaciónde las encuestas

Criterios deaceptación

Email de destino: La cuenta de correo a enviar unicamente debe serpara la cuenta de usuario registrada.Notifcación: Las notificaciones deben ser realizadas justo despues derealizar alguna acción descrita en la historia de usuario.

Tareasasociadas

26 - Confgración de correo electronico

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

Tipo Historia de usuarioNombre Reporte IndividualEsfuerzo 5.00Descripció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 deaceptación

Acceso a resultados individuales: El analista es el unico rol que puedever los resultados por cuenta de usuario.

Tareasasociadas

25 - Resultado por cuenta

Tipo Historia técnicaNombre Control de encuestas por cuentaEsfuerzo 8.00Descripción La herramienta debe contemplar la posibilidad de que cada cuenta

pueda completar más de una encuesta por vigencia relacionada almismo proceso.

Criterios deaceptación

Consolidación de resultados: Los resultados por cuenta debenconsolidarse para todas las encuestas realizadas, asimismo en resultadosconsolidados por proceso.

Tareasasociadas

27 - Control de parametros de cuenta

76

Tipo Historia de usuarioNombre Comparación de resultadosEsfuerzo 8.00Descripción Como analista debo poder ver los resultados de diferentes procesos

filtrados en modulos, componentes y elementos para comparar lasvaloraciones de aspectos similares entre procesos relacionados

Criterios deaceptación

Vista independiente: Los resultados de la consolidación deben ser engraficos independientes del proceso base y de los proceso(s) a comparar.

Tareasasociadas

24 - Comparación por proceso

Tipo Historia técnicaNombre Notifcaciones por correo electronicoEsfuerzo 5.00Descripción El sistema debe notificar via correo electronico acciones relacionadas

con el evaluador como cambios de contraseña, activaciones y realizaciónde las encuestas

Criterios deaceptación

Email de destino: La cuenta de correo a enviar unicamente debe serpara la cuenta de usuario registrada.Notifcación: Las notificaciones deben ser realizadas justo despues derealizar alguna acción descrita en la historia de usuario.

Tareasasociadas

26 - Confgración de correo electronico

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 deesfuerzo) a través de los lanzamientos y de las iteraciones. En cada iteración el numero dehistorias restantes disminuye hasta completar el 100% de la realización del proyecto, Lamayor parte los puntos acumulados entre historias de usuario fueron completadas en el primerlanzamiento.

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, esdecir 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 capacidadplaneada para la ejecución de las historias. Todas las historias se realizaron según la capacidadplaneada en cada sprint. No existieron historias de usuario realizadas fuera del Sprint dondese 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 apoyarel uso de nuevas tecnologías.

15.4. Manual de usuario

El sistema de documentación sobre un ambiente web permite al usuario conocer el manejode la herramienta y representa el primer punto de partida para buscar y conocer las accionesdisponibles del sistema. Contiene el instructivo para realizar las actividades concernientes alproceso 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 basesde 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 dedocumentos cono encuestas, formularios y listados que requieren una rápida respuestaa las consultas cuando el numero de documentos aumenta.

Es posible modelar fácilmente colecciones con documentos distintos dentro de la mismacolección, es decir encuestas con preguntas y campos diferentes entre si.

El framework de desarrollo permite abstraer de forma natural las colecciones de labase 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 almacenarsecomo un documento con todos los datos embebidos.

La representación visual del documento se muestra en formato JSON. Esto tambiénfacilita la integración con otros sistemas a través de API que utilizan esta notacióncomo 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 laaplicació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 cuentasde usuarios, información del proceso al que pertenece.

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

Permission: Entidad de permisos específicos dentro de la aplicación. Los permisos sonaccesos concretos a acciones en la aplicación.Es el nivel más detallado de control deacceso.

Param: Entidad de parámetros de configuración del sistema. Representa configuracionesde organización de la aplicación procesos, áreas, estructura MECI.

Category: Entidad de Categorías del sistema. Las categorías se gestionan por tipo yrepresentan 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 dela estructura.

Category type: Tipos de categorías del sistema para la estructura de la encuesta y delas cuentas de usuarios.

Survey: Entidad de la encuesta. Representa la plantilla de la encuesta asignada a unproceso, contiene únicamente las preguntas a ser evaluadas.

Question: Entidad que representa la pregunta.Pertenece a una categoría dentro de laestructura 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 preguntade 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 unapregunta.

Schedule: Representa el cronograma de la encuesta. Permite crear varios cronogramascada uno con su vigencia.

Password Encoder: Utilitario de cifrado de contraseña para la cuenta de usuario. elalgoritmo 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], estocorresponde con una descripción detallada del punto de vista de infraestructura en la definiciónde 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 clientey el servidor. Se utiliza un certificado de seguridad gratuito a través de una entidadcertificadora sin animo de lucro.

Capa de acceso a la aplicación: se utiliza el contenedor de aplicaciones de java servletcompatible con groovy - Gestiona la aplicación en formato Web application ARchiveWAR. 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 webgestionadas a través del framework. Este genera los contenidos estáticos como imágenesy scripts ejecutados en la capa del cliente.

84

Capa lógica del negocio: Se estructura a través del framework empleando el patrón desoftware 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 yel mapeador del framework, se utiliza el patro de registro activo y la implementacióndel mapeador en Hibernate para establecer la conexión con la base de datos y ejecutarlas consultas.

Capa de persistencia: En la capa de persistencia se gestiona a través del SGBD (Sistemagestor 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 alojadasen web. Presentan acceso a los contenidos del aplicativo y pueden hacer uso de dispositivosmoviles para consultar información.

Usuarios de la organización: Todas las áreas de la entidad y las personas que tienen relacióncon los procesos, bien sean misionales, estratégicos, de seguimiento o de apoyo. se definen lostipos 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 deacceso 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. Seutiliza un marco de trabajo para la presentación Semantic UI (Liencia MIT). Este marco detrabajo 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 lasfuncionalidades desde el menú principal a todos los módulos de la herramienta, cada modulocuenta 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 losmó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 deresultados, migración de encuestas entre periodos o que involucren varias entidades deldominio como la creación de las encuestas.

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

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 paletade 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ón18. Resultados y discusión

A partir de la definición de requerimientos por medio de la metodología de desarrollo desoftware, la definición de la arquitectura empresarial orientada al proceso de autoevaluacióninstitucional, y el levantamiento de la información del contexto del problema, se logra construirun prototipo capaz de gestionar el proceso de Autoevaluación con los criterios establecidos enel MECI. El ejemplo de aplicación es la implementación en la entidad publica Instituto distritalpara la protección de la niñez y la juventud IDIPRON. Se da por finalizada la construccióndel prototipo dando cumplimiento al alcance del problema.

19. ConclusionesSe describió el proceso de autoevaluación institucional evidenciando que se maneja unenfoque 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 desdeel punto de vista de las áreas de control interno y es independiente de como se manejeen 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 cuyoenfoque se basa en el MECI. El uso de entrevistas como fuente primaria de informaciónfue 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 partirde 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 ladefinició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 cronogramaplanteados.(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 seestructuraron las historias de usuario utilizando un lenguaje común con el objetivo deque 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 losmódulos, componentes y elementos del MECI y consolidados por procesos.

Cuando este proceso se realiza manualmente, toma tiempo y esfuerzo por parte de losanalistas en tareas repetitivas;(sec 7.1) con el uso de las tecnologías de la información yla constante búsqueda en integrarlas con los procesos en las organizaciones, los analistastendrá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 deevaluació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 analistamediante 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 manualesutilizando 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 posibilidadque ofrece esta disciplina permite identificar nuevos conceptos y características que ayudenal 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 amedida que el proceso lo hace.

El proceso de autoevaluación institucional involucra un gran numero de componentes yelementos empresariales y cuya naturaleza, al ser aplicable a toda la organización, puedecaracterizar a toda la organización, en sus funciones y procesos, valores institucionales ysu objeto social para las entidades públicas de forma general. La arquitectura empresarialdefinida para este proceso puede aportar como insumo base para la definición de una nuevaarquitectura 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 aspectosde una arquitectura empresarial con una abstracción suficientemente detallada que puedecomprender el arquitecto de software y los involucrados en le proyecto, en este proyectose evidenció que esto puede ser aplicado a un proceso concreto de forma natural y como unejemplo de aprendizaje para futuras definiciones arquitecturas aplicables también a un entornoempresarial.

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 buscade identificar falencias y mejorar aplicables al entorno empresarial.

Se propone establecer una arquitectura de software que permita implementar diferentesenfoques 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 deservicios web y compatible con una arquitectura orientada a servicios como parte de sistemasmacro orientados al MECI a medida que la herramienta evolucione.

Debido a que esta herramienta y el diseño a partir de la arquitectura empresarial delproceso se interrelaciona con un estándar regido a nivel nacional, como trabajo futuro sepretende proveer a esta herramienta a todas las entidades de carácter descentralizado con elapoyo de entidades como el ministerio de las TIC y apps.co para su financiación, se espera quese consolide como una herramienta general y el propio uso y realimentación de sus usuariospermita 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 yse dictan otras disposiciones. noviembre 1993.

[2] Colombia Congreso Nacional de la Republica. Ley 489 de 1998, por la cual se dictannormas 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 dictannormas sobre el Sistema Nacional de Control Interno de las Entidades y Organismos dela 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 ModeloEstandar 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 elentrevistador. Las entrevistas son realizadas cara a cara.

1. ¿Conoce el proceso de autoevaluación institucional?. Realice una breve descripción delo 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 negativoen 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 serealizan.

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 deorganizar 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 dosprimeros 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ón0 No sabe1 No se cumple2 Se cumple insatisfactoriamente3 Se cumple aceptablemente4 Se cumple en alto grado5 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 cadauno de los valores establecidos en la tabla anterior.

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

Pregunta No 1Valor Frecuencia

0 01 32 43 64 35 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 daren 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.

MANUAL DE IMPLEMENTACION82

Pregunta No 1Valor Frecuencia Porcentaje

(Frecuencia /Total de encuestas)0 0 (0/20) 01 3 (3/20) 0,152 4 (4/20) 0,23 6 (6/20) 0,34 3 (3/20) 0,155 4 (4/20) 0,2

3. Multiplicar cada valor por el porcentaje determinado en el paso anterior, con el fin de hallar unvalor parcial para cada uno:

En el ejemplo, la situación sería:

Pregunta No 1Valor Frecuencia Porcentaje Valor parcial

(Valor * Porcentaje)0 0 0 01 3 0,15 0,152 4 0,2 0,43 6 0,3 0,94 3 0,15 0,65 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 (serecomienda trabajar las preguntas en el mismo orden en que se aplicaron).

6. Determinar el Puntaje Total sumando los puntajes obtenidos para cada pregunta ydivididié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

0 1 2 3 4 5

PT

F% (F/T)P (V*%)

PREGUNTA nF%P

PREGUNTA 1PP

P1 + P

2 + P

n

TOTALF1+F

2+F

n.

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 frecuenciasPT 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 acuerdocon la siguiente tabla:

Para cada uno de los rangos se encuentra definido un criterio, que representa una valoracióncualitativa del Puntaje Total. Con base en esta valoración se interpretarán los resultados obtenidosen 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 elelemento 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 accionespara el diseño e implementación del elemento; si se ubica en los rangos satisfactorio o adecuado, lasacciones 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 decisionesrelacionadas 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 latabulació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 delelemento, 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:

Rango CriteriosPuntaje Total entre 0.0 y 2.0 InadecuadoPuntaje Total entre 2.1 y 3.0 DeficientePuntaje Total entre 3.1 y 4.0 SatisfactorioPuntaje Total entre 4.1 y 5.0 Adecuado

Pregunta Valor 0 1 2 3 4 5 total PP1 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 proponerlas acciones que permitan superar ese estado deficiente, procurando trabajar con mayor esfuerzoen los aspectos indagados a través de las las preguntas que obtuvieron un menor puntaje parcial.