diseÑo de un sistema de informaciÓn geogrÁfico
TRANSCRIPT
DISEÑO DE UN SISTEMA DE INFORMACIÓN GEOGRÁFICO PARTICIPATIVO,
BASADO EN LOS REQUERIMIENTOS DE GERENCIA INTEGRAL DE LA
INTERVENTORÍA INGETEC-SEDIC, PARA EL PROYECTO HIDROELÉCTRICO
ITUANGO: UNA PROPUESTA DESDE LO SOCIAL, PARA SUPERAR
BARRERAS INTERDISCIPLINARES.
JOSÉ VICTOR LLINÁS PEDROZA.
UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN
FACULTAD DE INGENIERÍAS
ESPECIALIZACIÓN EN GESTIÓN TERRITORIAL
MEDELLIN
2015
DISEÑO DE UN SISTEMA DE INFORMACIÓN GEOGRÁFICO PARTICIPATIVO,
BASADO EN LOS REQUERIMIENTOS DE GERENCIA INTEGRAL DE LA
INTERVENTORÍA INGETEC-SEDIC, PARA EL PROYECTO HIDROELÉCTRICO
ITUANGO: UNA PROPUESTA DESDE LO SOCIAL, PARA SUPERAR
BARRERAS INTERDISCIPLINARES.
JOSÉ VICTOR LLINÁS PEDROZA
Proyecto presentado para optar al título de Especialista en Gestión Territorial.
Asesores
Helena Pérez Garcés, M.C. en Ciencias Ambientales
Carlos Arturo Castro, M.C. en Ingeniería con énfasis en Informativa Educativa.
UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN
FACULTAD DE INGENIERÍAS
ESPECIALIZACIÓN EN GESTIÓN TERRITORIAL
MEDELLIN
2015
Nota de aceptación
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
Firma del jurado
__________________________
Firma del jurado
Medellín, 13 de abril de 2015
DEDICATORIA
A Tata, mi referente de vida y amor.
A mi madre, quien me ha alentado todos los días a seguir mis objetivos y me
enseño a confiar en mí mismo.
A mi familia, que siempre ha estado ahí, dispuesta a apoyarme en cada reto que
asumo.
A Astrid, porque hay personas que siempre serán parte de mi vida, a pesar de
todo.
AGRADECIMIENTOS
A todo el Equipo Integral del Consocio Ingetec – Sedic, Interventoría de Obras
Principales de Infraestructura del Proyecto Hidroeléctrico Ituango, por sus valiosos
aportes, los cuales hicieron posible alcanzar los objetivos trazados, construir una
herramienta inédita para la gestión social y demostrar que el trabajo interdisciplinar
esta tanto necesario como posible.
CONTENIDO
INTRODUCCIÓN. .................................................................................................... 9
1. JUSTIFICACIÓN. ............................................................................................ 13
2. PLANTEAMIENTO DEL PROBLEMA. ............................................................... 15
3. OBJETIVO GENERAL..................................................................................... 18
4. OBJETIVOS ESPECÍFICOS. .......................................................................... 18
5. DISEÑO METODÓLOGICO. ........................................................................... 20
5.1. Proceso - Planeación De Sistemas De Información (PSI). ..................... 21
5.1.1. Actividad - Descripción general de la PSI. ............................................. 21
5.1.2. Actividad - Definición y Organización de la PSI. .................................... 22
5.1.3. Actividad - Estudio de la información relevante. .................................... 22
5.1.4. Actividad - Identificación de Requisitos. ................................................ 23
5.1.5. Actividad - Estudio de los Sistemas de Información actuales. ............... 23
5.1.6. Actividad - Diseño del Modelo de Sistemas de Información. ................. 24
5.1.7. Actividad - Definición de la Arquitectura Tecnológica. ........................... 24
5.1.8. Actividad - Definición del Plan de Acción. ............................................. 25
5.1.9. Actividad - Revisión y Aprobación. ........................................................ 26
5.2. Proceso – Desarrollo del Sistema de Información. ................................ 26
5.2.1. Subproceso - Estudio de Viabilidad del Sistema – EVS. ....................... 26
5.2.2. Subproceso – Análisis del Sistema de Información – ASI. .................... 30
5.2.3. Subproceso – Diseño del Sistema de Información (DSI). ...................... 39
5.2.4. Subproceso – Construcción del Sistema de Información (CSI). ............ 49
5.2.5. Subproceso – Implantación y Aceptación del Sistema. ......................... 54
5.3 Proceso – Mantenimiento del Sistema de Información. .......................... 61
5.3.1 Actividad - Registro de la petición. ......................................................... 61
5.3.2. Actividad - Análisis de la petición. ......................................................... 62
5.3.3. Actividad - Preparación de la implementación de la modificación. ........ 62
5.3.4. Actividad - Seguimiento y evaluación de los cambios hasta la
aceptación. ...................................................................................................... 63
6. APLICACIÓN DE MÉTRICA 3 AL DISEÑO DEL SIGPP DEL MECANISMO DE
ATENCIÓN A LA COMUNIDAD DEL PHI. ............................................................. 64
6.1. Planeación del sistema de información. .................................................. 64
6.1.1. Descripción general de la PSI. .............................................................. 64
6.1.2. Definición y organización de la PSI. ...................................................... 66
6.1.3. Estudio de la información relevante....................................................... 67
6.1.4. Identificación de requisitos. ................................................................... 68
6.1.5. Estudio de los sistemas de información actuales. ................................. 69
6.1.6. Diseño del modelo de información. ....................................................... 70
6.1.7. Definición de la arquitectura tecnológica. .............................................. 70
6.1.8. Definición del plan de acción. ................................................................ 71
6.1.9. Revisión y aprobación. ......................................................................... 71
6.2. Estudio de la viabilidad del sistema. ....................................................... 71
6.2.2. Análisis del sistema de información. ...................................................... 74
6.2.3 Modelo de datos. .................................................................................... 76
6.2.4 Especificación de casos de uso. ............................................................ 78
6.3. Diseño del sistema de información. ......................................................... 78
6.3.2. Requerimientos de hardware. ............................................................... 80
6.3.2. Modelo de datos. ................................................................................... 81
6.3.3. Informes. ............................................................................................... 82
6.3.2. Requerimientos de seguridad del sistema. ............................................ 82
7. CRONOGRAMA ................................................................................................ 95
8. CONCLUSIONES. ............................................................................................. 98
9. LISTADO DE ANEXOS. .................................................................................. 99
10. REFERENCIAS BIBLIOGRAFICAS ............................................................... 100
9
INTRODUCCIÓN.
La Participación Ciudadana fue considerada como uno de los ejes centrales de la
agenda del Programa 21, otorgándole un papel decisorio en el éxito del
cumplimiento de las metas, objetivos, políticas y estrategias, acogida por los
países firmantes, para la formulación de una propuesta coherente de Desarrollo
Sostenible. Así mismo, esta agenda plantea que la tecnología deberá estar al
servicio de sus objetivos y, en esta medida, los Gobernantes y planificadores
deberán estar comprometidos con la comprensión de las dimensiones
ambientales, sociales y económicas que se articulan para pensar el ordenamiento
de los territorios (Naciones Unidas, 2013).
George Brown (Brown, 2012) fija su atención en la relación que supone los dos
ejes centrales antes referidos y plantea que existe un ambiente de desconfianza
de los Gobiernos frente al resultado del ejercicio participativo y sus repercusiones
respecto a la toma de decisiones de proyectos de interés nacionales.
Consecuente con lo anterior, Jonathan Ball (Ball, 2002) plantea que los proyectos
de desarrollo que garantizan la participación ciudadana adolecen de un excesivo
control por parte de los planificadores que asumen a los `actores interesados´ o
`grupos de interés´ como males necesarios para validar los procesos de
socialización que exige la ley. Esta prevención se relaciona con dos condiciones
inherentes a los procesos de participación dentro del contexto de la participación,
a saber: i) la presión ejercida por suplantadores de las `partes interesadas´ que
desplazan a los actores sociales legítimos para imponer sus propias agendas
dentro del proceso de planificación y ii) las dudas que existente respecto al valor
10
que pueda aportar los datos arrojados por los procesos participativos, en la toma
de decisiones.
Por su parte, Sandra Barrera (Barrera, 2009) plantea que si bien la construcción
cartográfica está determinada por una intencionalidad que viene dictada desde la
las instancias del Poder o Instituciones Oficinales, las cuales ordenan para sus
propósitos el mapeo de los territorios, existe también un conocimiento narrativo
concebido a partir de las representaciones de las comunidades que los habitan,
que debe ser considerado dentro de la elaboración cartográfica, por ser
fundamental para la toma de decisiones incluyentes y equitativas, dentro de la
planeación.
El resultado de plasmar las representaciones de los grupos de interés en un mapa,
da origen al concepto de cartografía social, entendida como la recreación de un
espacio, a partir de las experiencias que todo ser humano crea en su mente sobre
un lugar determinado o de las potencialidades que este percibe sobre el mismo,
utilizando SIG (Ball, 2002). En este mismo sentido, Tao Zhong (Zhong et al, 2008)
plantea que la posibilidad de articular diferentes perspectivas sobre un lugar
específico, permite crear representaciones que generan un sentido de
empoderamiento de los grupos de interés respecto a su entorno y favorece la
toma de decisiones desde una perspectiva incluyente.
Como todo concepto, el de SIGPP evolucionan de la mano del desarrollo
investigativo, no obstante, David Green (Green, 2010) señala que la literatura
especializada a concertado en llamar Sistema de Información Geográfica de
Participación Pública - SIGPP, al método que articulando las tecnologías
geoespaciales con los mecanismos de participación ciudadana favoreciendo la
planificación y los procesos de toma de decisiones, a partir de la construcción de
la cartografía social o mapeo social. En este mismo sentido, Greg Brown y
Christopher M. Raymond (Brown et al, 2014) plantean que los SIGPP le permite a
los planeadores la compresión de los conflictos que emergen de los grupos de
11
interés, respecto a la conservación de los recursos naturales o del paisaje, la
preservación de los elementos que permiten evocar el pasado y los cambios en el
entorno. Este entendimiento facilita el discurso argumentativo de las partes
interesadas, aporta elementos de negociación frente a los conflictos y permite la
construcción de consensos, motivados por el interés general.
Diferentes autores (Greg et al, 2014) han planteado que la articulación de SIG y
los mecanismos de participación ha dado lugar a conceptos como Sistemas de
Información Geografica Participativa –SIGP o Información Geográfica Voluntaria –
IGV, no obstante no existe una clara diferenciación teórica y práctica entre estos y
los Sistema de Información Geográfica de Participación Pública – SIGPP,
concluyéndose que en la práctica este último término debe ser tratado más como
un enfoque que abarca las diferentes dimensiones de los métodos que dan lugar
al mapeo social.
En este orden de ideas, como enfoque, los SIGPP atienden a un conjunto de
cuestiones generales, a saber: el énfasis del proceso (SIG vs Participación), el tipo
de muestreo (Participativo – individual- voluntario), el propósito del mapeo
(Mejorar la participación pública para informar a la ordenación del territorio, la
gestión y la toma de decisiones - Fomentar el empoderamiento de la comunidad -
ampliar la información espacial), el origen de la información (in situ – laboratorio),
fuentes utilizadas (Primaria – secundaria) y contexto (Urbano – rural – mixto).
(Ball, 2002)
Tal y como lo plantea Piotr Jankowski (Jankowski, 2009), la información, consulta,
implicación, colaboración y capacitación constituyen los cinco niveles de
participación. Estos niveles dibujan una escala, en donde cada uno representa un
factor de impacto del ejercicio participativo mayor que el anterior. De manera
concomitante, el autor plantea que los SIG pueden ser aplicados en cada uno de
estos niveles, siempre que la metodología y el apoyo tecnológico que se utilice se
ajuste a las exigencias de cada uno de estos niveles. Justamente, este es el
12
aspecto en el que se reconoce la dimensión de la potencialidad de los SIGPP, en
los ejercicios de Planificación.
David R. Green (Green, 2010) ha advertido sobre las oportunidades del desarrollo
de investigaciones alrededor de los GISPP, indicando que el principal reto es el de
someter a prueba las consideraciones surgidas desde la práctica, respecto a las
limitaciones que este método encarna. La primera de estas limitaciones, hace
referencia a que los resultados de los estudios de SIGPP no aportan resultados
concluyentes y transforman los análisis argumentativos en retórica. El segundo
problema que plantea la crítica a los SIGPP se refiere a que el modelo apunta a
más a una estrategia para informar a los grupos de interés sobre los procesos de
planificación, que a un instrumento para la toma decisiones dentro de este
proceso. Un tercer aspecto a tratar, inherente a todos los procesos participativos,
se relaciona con la necesidad de ajustar el modelo, de manera que se supere la
apatía o el desinterés de la comunidad, de participar en los procesos de
planificación, en la media en que esta variable afecta la valides de los resultados
del proceso de participación. Un cuarto elemento hace referencia al método de
elección de la muestra o a la definición de la población que participara del proceso
de SIGPP, en la medida en que se debe asegurar un nivel de representatividad,
que limite el alcance de los resultados del proceso de planificación.
En este mismo orden de ideas, las limitaciones de los SIGPP indicando que los
procesos de participación ciudadana no siempre garantizan elementos de juicios
sufrientes que permiten la toma de decisiones apropiadas a las condiciones
sociales, ambientales y económicas y que los SIG no siempre son la mejor
herramienta de apoyo para consultar a las comunidades. (Jankowski, 2009).
13
1. JUSTIFICACIÓN.
A partir de la determinación constitucional del Estado colombiano como uno
participativo, la Gestión Social en proyectos de desarrollo ha venido
perfeccionándose a lo largo de más de 20 años, encontrando en su camino
obstáculos y retos por superar, en su misión de garantizar el ejercicio participativo
en el marco de la ejecución de obras de interés comunitario, y si se quiere,
nacional.
Uno de los obstáculos determinantes que se repite proyecto tras proyecto, se
constituye en la ausencia de un lenguaje común que articule el conocimiento
multidisciplinar y el saber, sentir e intuición de las comunidades asentadas en las
zonas intervenidas por el Estado, a las cuales se les demanda de una alta cuota
de sacrificio, bajo la justificación de que las obras de ingeniera traen consigo, per
se, desarrollo local, regional y nacional.
En este orden de ideas, bajo el amparo que supone la defensa del interés general,
los expertos planificadores y ejecutores de los proyectos de desarrollo determinan
lo que se debe y no hacer, corriendo el riesgo de descuidar las necesidades
particulares y las expectativas de las comunidades que constituyen los territorios,
las cuales también anhelan soluciones que integren sus propios intereses, de
frente a los impactos asociados a la ejecución de obras de infraestructura.
La compresión de la anterior disyuntiva ha calado hondamente dentro de los
grupos interdisciplinarios que tienen a su cargo la gestión territorial de un proyecto
de infraestructura, trayendo como consecuencia lógica el desarrollo del concepto
de territorio desde un esquema representativo de lugar, extensión y forma a un
modelo que integrar también las relaciones que plantean los elementos biótico,
físico y social, interactuando en un espacio determinado. (González, 2011).
14
La coyuntura a la que hacemos referencia -esa que se abre ante el reconocimiento
de lo social como un factor determinante en la planeación del territorio-, le exige a
los gestores sociales el diseño de estrategias que permitan la comprensión de la
dimensión social en las mesas en donde se toman las grandes decisiones sobre el
desarrollo de los territorios, desde un óptica multidisciplinar.
Ahora bien, desde la óptica de la gestión territorial un proyecto como HidroItuango
está llamado a valerse de las herramientas tecnológicas necesarias para
monitorear, controlar y atender los efectos que conlleva su inserción en una región
deprimida, históricamente carente de la protección del Estado, ausente de
inversión social, marginada por la ausencia de oportunidades; todo esto teniendo
como telón de fondo el hecho de estar en el corazón palpitante de unas de las
zonas del país con mayor presencia de actores armados y ahora bandas
criminales, lo que marco su historia violenta y de dominio a través del uso de la
fuerza, por no hablar de la cultura de la ilegalidad que se abrió paso, dejando
como única posibilidad de sostenimiento de las comunidades asentadas en este
territorio el cultivo de sembrados ilícitos y de la minería ilegal.
Es así como surge el diseño de un Sistema de Información Geográfica Publica
Participativa, basado en los requerimientos de la Gerencia Integral de la
Interventoría Ingetec-Sedic la cual tiene a su cargo la supervisión de las obras de
infraestructura del Proyecto Hidroeléctrico Ituango y los registros de seguimiento
levantadas por el equipo de Gestión Social del Proyecto dentro del marco del
mecanismo de atención a la comunidad, como una propuesta desde lo social, para
acercar los conocimientos multidisciplinares y el saber de las comunidades
intervenidas, en procura de acertarle a la toma de decisiones socialmente cada
vez más responsables.
15
2. PLANTEAMIENTO DEL PROBLEMA.
Con la definición política de Colombia, como un estado participativo, la
Constitución de 1991 otorgó el derecho a los ciudadanos de participar activamente
en la planificación y control de la cosa pública y determinó, como deber del
Estado, el asegurar dicho ejercicio a través de los mecanismos de control y
seguimiento social de la gestión pública y de sus resultados.
Más de dos décadas han trascurrido desde la firma de la Carta Magna y aun son
muchos los retos que encarna la articulación de la participación ciudadana y la
gestión pública. En un sentido práctico, en una orilla del río tenemos las
aspiraciones, conocimientos, idiosincrasia y necesidades de un grupo social y en
la otra orilla del mismo río tenemos a los grandes planificadores y ejecutes que,
aplicando sus criterios técnicos y financieros, definen lo que es mejor para ese
grupo específico.
Ante tal disyuntiva continua vigente la fórmula de los Gestores Sociales;
profesionales con un perfil humanístico que a través de su formación y
herramientas conceptuales buscan revelar los vasos comunicantes entre el interés
comunitario y las diferentes posiciones interdisciplinarias que domina el ejercicio
de lo público.
Ahora bien, utilizando la analogía del lenguaje para explicar la forma en que se ha
venido tratando de conciliar estas dos dimensiones, sería correcto decir que la
pretensión desde la Gestión Social ha sido que lo técnico-científico entienda y
hable el lenguaje de lo social. Este planteamiento ha despertado una resistencia
16
rozable entre los expertos, desde donde se ha venido cultivando la idea de que la
comprensión de la dimensión técnico-científica se da en la medida en que el
Gestor Social logra procesar el discurso técnico y traducirlo a formas más
elementales y, si quiere coloquiales, que sean de fácil entendimiento para los
grupos de interés.
En este punto, es válido afirmar que en la práctica ambas posiciones están lejos
de resolver el problema que plantea la articulación interdisciplinaria, en términos
de la comprensión desde los actores y procesos implicados la gestión de los
territorios, en la medida en que ambas suponen un tipo de renuncia de la contra
parte.
El anterior es el dilema que se plantea al interior de los equipos interdisciplinarios
que tiene a su cargo la planificación y ejecución de los proyectos de desarrollo,
que para que caso que nos ocupará se referirá a las obras de infraestructura vial
que hacen parte del Proyecto Hidroeléctrico Ituango, específicamente la
construcción de la vía que conduce del Corregimiento de Puerto Valdivia al sitio de
Presa, desde el Km 0+000 al Km 1+000 y el marco de referencia será el Programa
de Participación contenido en el Capítulo Social del Plan de Manejo Ambiental con
el que la Autoridad Nacional de Licencia Ambientales licenció el Proyecto.
Como una manera de resolver la anterior disyuntiva, la propuesta del presente
trabajo está dirigida hacia el planteamiento de una tercera vía, que se hallaría en
la posibilidad de lograr la articulación interdisciplinaria a través de un lenguaje
común, en la forma de un Sistema de Información Geográfica que permita
construir un modelo espacial, teniendo como insumo los datos recabados desde
las herramientas de Gestión Social derivadas del Sistema de Atención a la
Comunidad del Proyecto Hidroeléctrico Ituango, y que permita dar respuesta a los
requerimientos de la Gerencia Integral de la Interventoría Ingetec-Sedic, en
procura de la toma de decisiones socialmente responsables.
17
PLANTEAMIENTO DEL PROBLEMA
¿Cuáles son los criterios y características pertinentes para diseñar un modelo de
Sistema de Información Geográfica, a partir de los requerimientos de la Gerencia
Integral de la Interventoría Ingetec-Sedic y los registros levantados por el área de
gestión social del Proyecto Hidroeléctrico Ituango, que concilie las posturas
interdisciplinarias, en procura de la toma de decisiones socialmente responsables?
18
3. OBJETIVO GENERAL.
Diseñar un Sistema de Información Geográfica Participativa a partir de la
adaptación del manual Métrica 3, en función a los requerimientos de la Gerencia
Integral de la Interventoría Ingetec-Sedic, respecto a los registros levantados por
el área de gestión social de las obras de infraestructura del Proyecto Hidroeléctrico
Ituango.
4. OBJETIVOS ESPECÍFICOS.
Determinar los criterios y características que deberán ser consideradas
dentro del diseño de un modelo de Sistema de Información Geográfica en
función del manual Métrica versión 3, a partir de los requerimientos de la
Gerencia Integral de la Interventoría Ingetec-Sedic y los registros de gestión
social, definidos como pertinentes para tal fin por el área social del Proyecto
Hidroeléctrico Ituango.
Aplicar el manual Métrica versión 3 al diseño un modelo de Sistema de
Información Geográfica, a partir de los requerimientos de la Gerencia
Integral de la Interventoría Ingetec-Sedic y los registros de gestión social
definidos por el área social del Proyecto Hidroeléctrico Ituango como
pertinentes para interactuar de manera interdisciplinaria y tomar decisiones
socialmente responsable.
19
Probar el modelo de Sistema de Información Geográfica Participativo,
alimentado con la información obtenida a partir de los registros definidos
por el área social del Proyecto Hidroeléctrico Ituango como pertinentes para
interactuar interdisciplinarmente.
20
5. DISEÑO METODÓLOGICO.
El diseño metodológico que trazará las líneas de trabajo del presente proyecto es
una adaptación de la metodología METRICA en su versión 3, desarrollada por el
Ministerio de Hacienda y Administraciones Públicas del Gobierno de España y que
ha demostrado ser útil en la sistematización del diseño, construcción y
mantenimiento de software, que para el caso que nos ocuparemos será un
Sistema de Información Geográfico (SIG).
T
Grafico 1. .Esquema metodología Métrica V. 3. Producción personal.
21
5.1. Proceso - Planeación De Sistemas De Información (PSI).
La primera fase del proyecto -construcción del Sistema de Información- es el
establecer un marco estratégico de referencia propio de la organización a la que
va a servir, es decir, la Gerencia Integral de la Interventoría Ingetec-Sedic. En este
sentido, la ruta de la construcción del Sistema estará orientada por un objetivo
estratégico –qué se quiere lograr/adonde se quiere llegar- y a los subsecuentes
pasos que se deberán dar para cumplir con la misión encomendada.
En este primer momento se avizoraran las factores comprometidos en el éxito el
proyecto, los recursos requeridos para su implementación y las actuaciones o
roles y responsables de cada actividad necesaria para la construcción del Sistema
e Información, conservando la lógica jerárquica y su secuencia estratégica,
instrumental y operativa.
El resultado o productos de los procesos involucrados en el nivel de planeación
serán:
5.1.1. Actividad - Descripción general de la PSI.
Tarea 5.1.1.1. Establecer las necesidades a cubrir por el proyecto.
Tarea 5.1.1.2. Definir la relación del objetivo del proyecto con el
cumplimiento de los objetivos estratégicos de la Gerencia Integral de la
Interventoría Ingetec-Sedic.
22
Tarea 5.1.1.3. Definir como ámbito, las áreas de las Gerencias de la
Interventoría Ingetec-Sedic que se verán afectadas con la construcción del
proyecto.
Tarea 5.1.1.4. Definir y asignar responsabilidades a cada actor del proceso
de construcción del Sistema de Información.
5.1.2. Actividad - Definición y Organización de la PSI.
Tarea 5.1.2.1. Describir el ámbito, alcance y los objetivos específicos del
proyecto.
Tarea 5.1.2.2. Describir el perfil de cada actor en función a las categorías
de dirección, seguimiento y administración del proyecto.
Tarea 5.1.2.3. Establecer plan de trabajo, estableciendo actividades,
responsables y tiempo de ejecución.
5.1.3. Actividad - Estudio de la información relevante.
Tarea 5.1.3.1. Recabar y analizar la información referente a trabajos y/o
desarrollos ejecutados anteriormente y que puedan servir como un
antecedente relevante para el proyecto, siendo de especial utilidad las
opiniones que sobre los mismos puedan aportar el personal de la
organización que se relaciona con estos.
Terea 5.1.3.2. Valoración de los antecedentes definidos en la tarea anterior
(5.1.3.1), con el fin de establecer términos de referencias, normativas o
23
procedimientos que puedan servirle al proyecto. A partir de esta tarea se
iniciará la construcción del Catalogo de Requisitos.
5.1.4. Actividad - Identificación de Requisitos.
Tarea 5.1.4.1. Identificar y estudiar cada uno de los procesos de la
Gerencia Integral de la Interventoría Ingetec-Sedic que se ven afectados
por el proyecto, determinando los cargos implicados, qué funciones
desempeñan, y cuál información fluye dentro de dichos procesos.
Tarea 5.1.4.2. Identificar y analizar las necesidades de información de los
procesos de la Gerencia Integral de la Interventoría Ingetec-Sedic
implicados en el proyecto, proponiendo un modelo ideal de flujo de éste en
el que se especifique las actividades y funciones en cada proceso expuesto
en la tarea anterior (5.1.4.1).
Tarea 5.1.4.3. Basados en las tareas anteriores (5.1.4.1 y 5.1.4.2), definir
los requisitos que el Sistema de Información deberá cubrir, asignándoles
prioridades a cada uno de ellos, de acuerdo a las opiniones de sus
usuarios. Esta tarea tendrá como objetivo el complementar la información
recogida en la actividad 5.1.3.2, Catalogo de Requerimientos.
5.1.5. Actividad - Estudio de los Sistemas de Información actuales.
Tarea 5.1.5.1. Determinar el alcance y los objetivos del Sistema de
Información existente que se verá afectado por el plan del nuevo proyecto.
Tarea 5.1.5.2. Analizar los Sistemas de Información existentes,
describiendo sus características básicas referidas a datos, software y
24
procesos de la Gerencia Integral de la Interventoría Ingetec-Sedic a los que
brinda soporte. Para esta tarea es fundamental registrar las opiniones de
los usuarios que interactúan en los mismos (Gerente Integral, Coordinador
de Gestión Social y Profesionales Sociales).
Tarea 5.1.5.3. Evaluar la eficiencia de los Sistemas de Información
existente, identificando las fuerzas a favor y en contra que actúan dentro de
este, como oportunidades o problemas. Para esta tarea es necesario
basarse en las opiniones de las personas sobre los riesgos y amenazas
relacionadas con el sistema existente, con el fin de determinar si se debe
sustituir o sólo realizar mejoras en el Sistema.
5.1.6. Actividad - Diseño del Modelo de Sistemas de Información.
Tarea 5.1.7.1. Determinar la cobertura de requisitos (obtenidos de la
actividad número 5.1.4) por parte de los Sistemas de Información actuales y
aquellos que no se encuentran incluidos en estos sistemas, junto con sus
necesidades de información.
Tarea 5.1.7.2. Definir un modelo de Sistema de Información discriminando
los elementos del sistema actuales que se mantendrá o mejorará y los
elementos del nuevo sistema que entrarían a satisfacer las necesidades y
requerimientos identificados.
5.1.7. Actividad - Definición de la Arquitectura Tecnológica.
Tarea 5.1.7.1. Identificar las necesidades de infraestructura tecnológica
necesaria para el proyecto, acorde con las posibilidades logísticas, técnicas
y económicas de la Gerencia Integral de la Interventoría Ingetec-Sedic.
25
Tarea 5.1.7.2. Seleccionar la alternativa tecnológica, que soporte de la
manera más adecuada al sistema de información, de acuerdo a las
posibilidades logísticas, técnicas y económicas de la Gerencia Integral de la
Interventoría Igentec-Sedic.
5.1.8. Actividad - Definición del Plan de Acción.
De acuerdo a la metodología METRICA 3, “En el Plan de Acción, que se
elabora en esta actividad, se definen los proyectos y acciones a llevar a cabo
para la implantación de los modelos de información y de sistemas de
información, determinados en las actividades Identificación de Requisitos (PSI)
y Diseño del Modelo de Sistemas de Información (PSI), con la arquitectura
tecnológica propuesta en la actividad Definición de la Arquitectura Tecnológica
(PSI). El conjunto de estos tres modelos constituye la arquitectura de
información.” Tal fin se enmarca dentro de las siguientes tareas:
Tarea 5.1.8.1. Definir los proyectos a realizar, especificando para cada cual
las acciones que se deberán implementar y sus respectivos objetivos,
recursos, cronograma, restricciones, riesgos y beneficios para la Gerencia
Integral de la Interventoría Ingentec-Sedic.
Tarea 5.1.8.2. Construir el plan de mantenimiento de la PSI, donde se
determinará los productos que obtendrán a partir del sistema de
información que deberán ser actualizados, la periodicidad con la se
realizará dicha actualización y el responsable de la misma.
26
5.1.9. Actividad - Revisión y Aprobación.
Tarea 5.1.9.1. Elaborar un resumen que simplifique todos los resultados de
esta etapa, para someterlo a revisión del comité de Dirección del PSI.
Tarea 5.1.9.2. Como respuesta a la tarea 5.1.9.1, el comité de Dirección del
PSI podrá emitir propuestas de mejoras u observaciones que deberán ser
recogidas y valoradas, analizando su posible incorporación al proyecto.
Tarea 5.1.9.3. Presentar la propuesta final y se somete a aprobación del
Director del Comité del PSI.
5.2. Proceso – Desarrollo del Sistema de Información.
Cada tarea definida en el proceso de Planificación del Sistema de Información
tiene definidos unos resultados o productos de salidas, los cuales serán
retomados en el proceso siguiente, en el que se establecen la ruta para el
Desarrollo del Sistema de Información del proyecto (DSI). Este proceso está
organizado a su vez en subprocesos, los cuales tiene definidas sus propias tareas
que tienen como resultado unos productos determinados.
5.2.1. Subproceso - Estudio de Viabilidad del Sistema – EVS.
El manual Métrica versión 3 establece que el objetivo del Estudio de Viabilidad del
Sistema “es el análisis de un conjunto concreto de necesidades para proponer una
solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas,
legales y operativas. La solución obtenida como resultado del estudio puede ser la
definición de uno o varios proyectos que afecten a uno o varios sistemas de
información ya existentes o nuevos”.
27
5.2.1.1. Actividad – Establecimiento de alcances del sistema.
Tarea 5.2.1.1.1. Describir las necesidades planteadas por los usuarios y
estudio de las restricciones económicas, técnicas, legales y operativas y, a
partir de esto, se realizan la siguiente descripción y catálogos:
Descripción General del Sistema de Información.
Catálogo de objetivos del Estudio de Viabilidad del Sistema.
Catálogo de requisitos actualizado.
Tarea 5.2.1.1.2. Identificar las áreas de la Gerencia Integral de la
Interventoría Ingenetec-Sedic que se verían afectados por el proyecto, sus
responsables y estructura.
Tarea 5.2.1.1.3. Establecer las actividades y tareas a realizar, definiendo
específicamente si se realiza el Estudio de la Situación Actual y, en caso de
que se amerite su ejecución, determinar su propósito para efectos del
proyecto.
5.2.1.2. Actividad - Estudio de la Situación Actual.
Tarea 5.2.1.2.1. Basado en la arquitectura de información resultado de la
actividad 5.1.7 de la PSI, identificar aquellos sistemas de información
existentes que puedan afectar o ser afectados por el proyecto.
28
Tarea 5.2.1.2.2. Partiendo del catálogo de usuarios, se define quiénes
participaran en el estudio de viabilidad, se les informa que serán llamados a
hacer parte del proceso y se espera su confirmación.
Tarea 5.2.1.2.3. Con los usuarios designados y la identificación de los
sistemas de información actuales, elaborar la descripción del sistema
actual, así:
Descripción lógica del sistema actual.
Descripción del modelo físico del sistema actual.
Matriz de localización geográfica y física de módulos y datos, incluida
las redundancias.
Tarea 5.2.1.2.4. Realizar un diagnóstico actual del sistema identificando
problemas, deficiencias y oportunidades de mejoras.
5.2.1.3. Actividad - Definición de Requisitos del Sistema.
Tarea 5.2.1.3.1. Definir las directrices técnicas y de gestión que seguirá el
proyecto para dar lugar al sistema de información requerido por la Gerencia
Integral de la Interventoría Ingetec-Sedic. Para lo anterior se debe contar
con:
Políticas de gestión de proyectos.
Políticas de seguridad.
Directrices de planificación
Directrices de gestión de cambios.
Directrices de gestión de calidad.
29
Tarea 5.2.1.3.2. Se analiza la información obtenida en las sesiones de
trabajo para la Identificación de Requisitos, definiendo y catalogando los
requisitos (funcionales y no funcionales) que debe satisfacer el sistema,
indicando sus prioridades.
5.2.1.4. Actividad - Estudio de alternativas de solución.
Tarea 5.2.1.4.1. Plantear, a manera de propuesta, los sistemas alternativos
que puedan dar respuesta a los requisitos planteados en el catálogo
resultado de la tarea 5.2.1.3.2. En este momento se debe vislumbrar si el
proyecto requerirá la adquisición de algún software existen en el mercado,
uno diseñado a la medida o de tipo mixto.
Tarea 5.2.1.4.2. Relacionar cada alternativa de solución planteada con los
requerimientos que cada una de estas cubre.
Tarea 5.2.1.4.3. Para cada alternativa, describir la forma en que se logrará
su implantación. Dependiendo de la naturaleza de la solución se debe
definir:
En caso de que implique el desarrollo de un software: Especificar el
modelo abstracto de datos/modelo de procesos y modelo de
negocios/modelo de dominio.
En caso de que la solución incluya un software existente en el
mercado: Describir el producto, su evolución, costos y adaptabilidad.
5.2.1.5. Actividad - Valoración de las Alternativas.
30
Tarea 5.2.1.5.1. Establecer la viabilidad económica de las alternativas, a
través de un análisis de costo/beneficio.
Tarea 5.2.1.5.2. Analizar cada alternativa para identificar su complejidad e
identificar los factores de riesgo asociados a cada proyecto, proponiendo
las acciones necesarias para minimizarlos.
Tarea 5.2.1.5.3. Establecer un plan de trabajo por cada alternativa, que
permita visualizar su articulación con los proyectos en desarrollo o aquellos
cuya ejecución se encuentran proyectada.
5.2.1.6. Actividad - Selección de la solución.
Tarea 5.2.1.6.1. Enviar al Comité de Dirección el resultado de las
actividades del Estudio de Viabilidad del Sistema y someterlo a su estudio y
revisión, a fin de que se determinen cuáles son las alternativas que serán
presentadas.
Tarea 5.2.1.6.2. Presentar al Comité de Dirección y al equipo de Gestión
Integral de la Interventoría Ingetec-Sedic las alternativas seleccionadas en
la tarea anterior, exponiendo las ventajas e inconvenientes asociados a la
implementación de cada una de estas, de manera que estas sean
debatidas suficientemente hasta la aprobación de la alternativa final.
Tarea 5.2.1.6.3. La Gerencia Integral de la Interventoría Ingetec-Sedic
aprueba formalmente la alternativa seleccionada o determina su
inviabilidad, estableciendo los fundamentos de la misma.
5.2.2. Subproceso – Análisis del Sistema de Información – ASI.
31
El objetivo del Análisis del Sistema de Información es el de establecer los pasos
necesarios para garantizar que el modelo satisface efectivamente las necesidades
de todos los usuarios que lo utilizaran.
5.2.2.1. Actividad - Definición del Sistema.
Tarea 5.2.2.1.1. Delimitar el sistema de información, indicar los procesos
que pertenecen al ámbito del Sistema de Información e identifican las
entidades externas al sistema que aportan o reciben información.
Tarea 5.2.2.1.2. Definir, desde un nivel estratégico, el entorno tecnológico
que se requiere para dar respuesta a las necesidades de información,
especificando sus posibles condicionantes y restricciones, teniendo en
cuenta el entorno tecnológico propuesto en la descripción de la solución,
que se obtuvo en el proceso Estudio de Viabilidad del Sistema (EVS).
Tarea 5.2.2.1.3 Actualizar el catálogo de normas elaborado en el proceso
Estudio de Viabilidad del Sistema (EVS), incorporando toda la información
que, desde el punto de vista de la instalación, se considere necesario
contemplar para la elaboración de los distintos productos del ciclo de vida.
Tarea 5.2.2.1.4. Identifican los usuarios participantes y finales,
interlocutores tanto en la obtención de requisitos como en la validación de
los distintos productos y la aceptación final del sistema, definiendo para
cada uno de estos sus funciones y responsabilidades. Para ello, se
actualiza el catálogo de usuarios generado previamente en el Estudio de
Viabilidad del Sistema (EVS).
32
5.2.2.2. Actividad - Establecimiento de requisitos.
Tarea 5.2.2.2.1. Recabar, a partir de la información aportada por los
usuarios del sistema, los requisitos que este debe cumplir, especificando
también las restricciones que estas puedan también tener.
Tarea 5.2.2.2.2. A partir de la tarea anterior (5.2.2.2.1), detectar
inconsistencias, ambigüedades, duplicidad o escasez de información, etc y
analizar las prioridades establecidas por el usuario y su asociación con los
requisitos relacionados entre sí.
Tarea 5.2.2.2.3. Confirmar, partiendo de los conceptos de los usuarios, que
los requisitos especificados en el catálogo de requisitos y los casos de uso,
son válidos, consistentes y completos.
5.2.2.3. Actividad - Identificación de subsistemas de análisis.
Tarea 5.2.2.3.1. La descomposición en subsistemas debe estar orientado,
principalmente, hacia el desarrollo orientado a negocio, basados en los
siguientes criterios:
Homogeneidad de procesos.
Servicios comunes.
Prioridad.
Afinidad de requisitos.
Localización geográfica.
33
En análisis orientado a objetos, se identifican y definen las dependencias
entre subsistemas analizando los elementos compartidos entre ellos o las
interfaces entre subsistemas.
Tarea 5.2.2.3.2. Construir los modelos de análisis de cada uno de los
subsistemas de tal forma que se eliminen duplicidades y se logre la
precisión en los teñirnos de glosario. De esta manera su puede tener una
visión global de todos los modelos.
5.2.2.4. Actividad - Análisis de los casos de uso.
Esta actividad se realiza únicamente para proyectos orientado a objetos.
Tarea 5.2.2.4.1. Identificar los objetos necesarios para realizar el caso de
uso, basándose en la especificación que tenemos del mismo, generando un
modelo, así:
Clase entidad. (Representa la información manipulada en el caso de
uso).
Clase de interfaz de usuario. Establece las interacciones entre los
actores y el sistema.
Clase de control. Incluye a los responsables de la coordinación,
secuencia de transacciones y control de los objetos relacionados con
un caso de uso.
Tarea 5.2.2.4.2. Describir la cooperación entre los objetos utilizados para la
realización de un caso de uso, que ya fueron identificados en la tarea
anterior, mediante diagramas de interacción.
34
5.2.2.5. Actividad - Análisis de clases.
Esta actividad se realiza únicamente para proyectos orientado a objetos.
Tarea 5.2.2.5.1. Identificar las responsabilidades y atributos relevantes de
una clase. Estudiando los papeles que desempeñan los objetos dentro de
los distintos casos de uso, se determinan las responsabilidades de cada
clase.
Tarea 5.2.2.5.2. Estudiar los mensajes entre los objetos incluidos en el
diagrama de interacción para determinar las asociaciones existentes entre
las clases correspondientes.
Tarea 5.2.2.5.3. Organizar las clases en una representación que permita
una implementación sencilla de la herencia y una agrupación semántica de
las diferentes clases, en función a los estándares definidos en la actividad
5.2.2.1. Definición del Sistema.
5.2.2.6 Actividad - Elaboración del modelo de datos (solamente para desarrollo
estructurado).
Tarea 5.2.2.6.1. Diseñar un modelo conceptual de datos en el que se
Identifique y defina las entidades que quedan dentro del ámbito del sistema
de información, los atributos de cada entidad.
Tarea 5.2.2.6.2. Elaborar el modelo lógico de datos a partir del modelo
conceptual, es decir, resolver, eliminar y determinar dependencias entre las
relaciones de las entidades, así como prescindir de redundancias y
ambigüedades. De igual forma, se deben realizar las siguientes acciones:
35
Resolver las relaciones complejas que pudieran existir entre las
distintas entidades.
Eliminar las relaciones redundantes que puedan surgir como
consecuencia de la resolución de las relaciones complejas.
Eliminar cualquier ambigüedad sobre el significado de los atributos.
Identificar las relaciones de dependencia entre entidades.
Completar la información de las entidades y los atributos, una vez
resueltas las relaciones complejas.
Revisar y completar los identificadores de cada entidad.
Especificar para cada entidad el número máximo y medio de
ocurrencias, estimaciones de crecimiento por periodo, tipo y
frecuencia de acceso, características relativas a la seguridad,
confidencialidad, disponibilidad y demás consideraciones que se
estimen relevantes
Tarea 5.2.2.6.3. Normalizar el modelo lógico de datos, garantizando la no
ocurrencia de duplicidades de datos o de sus relaciones, a partir de su
conocimiento semántico.
Tarea 5.2.2.6.4. Si es necesario, se realiza un plan de migración de datos
desde otros sistemas y carga inicial del sistema. Para esta tarea es preciso
tener en cuenta aspectos tales como: la planificación de la migración y
carga inicial, prioridad, requisitos de conversión de información:
necesidades de depuración de información, importación de información
complementaria, validaciones y controles, plan de pruebas específico,
necesidades especiales de equipamiento hardware y estimaciones de
capacidad, en función de los volúmenes de las estructuras de datos origen,
necesidades especiales de utilidades software y posibles modificaciones del
sistema origen, que faciliten la ejecución o verificación de la migración o
carga inicial.
36
5.2.2.7. Elaboración del modelo de procesos.
Esta actividad se ejecuta sólo para los casos estructurados.
Tarea 5.2.2.7.1. Por medio de un diagrama de flujo, describir los
subsistemas definidos en la actividad 5.2.2.3 Identificación de Subsistemas
de Análisis, mediante la descomposición en sucesivos niveles de procesos.
Describiendo la estructura de los flujos y de los grupos de datos se elabora
una especificación para cada proceso primitivo, especificando en detalle el
tipo de tratamiento, la operativa asociada, las restricciones y limitaciones
impuestas al proceso, y las características de rendimiento que se
consideren relevantes.
Tarea 5.2.2.7.2. Describir en detalle las interfaces con otros sistemas de
información, con el fin de definir y delimitar el modo en que el sistema va a
relacionarse con el exterior, especificando:
Procesos del sistema de información asociados.
Especificaciones funcionales de los sistemas origen o destino.
Formatos de los datos intercambiados.
Aspectos operativos de la interfaz: en lotes o en línea y medio físico
utilizado.
Frecuencia o periodicidad del intercambio.
Evento que desencadena la interfaz.
Validaciones, requisitos especiales de seguridad, etc.
Modificaciones o adaptaciones necesarias en los sistemas origen o
destino.
37
5.2.2.8. Actividad - Definición de interfaces de usuario.
Tarea 5.2.2.8.1. Especificar los estándares, directrices y elementos
generales a tener en cuenta en la definición de la interfaz de usuario, tanto
para la interfaz interactiva (gráfica o carácter), como para los informes y
formularios impresos.
Tarea 5.2.2.8.2. Realizar un catálogo de perfiles, de acuerdo a su nivel de
responsabilidad y al alcance o naturaleza de las funciones que realizan, así
como analizar las características más relevantes de los usuarios que van a
asumir esos perfiles, valorando tanto su conocimiento técnico, es decir, la
mecánica necesaria para usar la interfaz eficazmente, como de negocio, en
cuanto a la comprensión de las funciones que realizan, relación entre
funciones y condicionantes en su ejecución. Para tal fin se genera un
catálogo de perfiles de usuario.
Tarea 5.2.2.8.3. Especificar cada formato individual de la interfaz de
pantalla, desde el punto de vista estático.
Tarea 5.2.2.8.4. Definir los formatos individuales de informes y formularios y
las características de las salidas o entradas impresas del sistema,
especificando la periodicidad, confidencialidad, procedimientos de entrega o
difusión y salvaguarda de copia.
5.2.2.9. Actividad - Análisis de consistencia y especificación de requisitos.
Tarea 5.2.2.9.1. Asegurar la calidad formal de los distintos modelos,
conforme a la técnica seguida para la elaboración de cada producto y a las
normas determinadas en el Catálogo de Normas actualizado en la Tarea
5.2.2.1.3.
38
Tarea 5.2.2.9.2. Asegurar la coherencia entre modelos, comprobando la
falta de ambigüedades o duplicación de información.
Tarea 5.2.2.9.3 Validar los modelos de acuerdo al catálogo de requisitos
especificados para el sistema de información y a la validación directa del
usuario, especialmente necesaria en el caso de la interfaz de usuario.
Tarea 5.2.2.9.4. Una vez validados los modelos en la tarea anterior,
elaborar la Especificación de Requisitos de Software (ERS), el cual
incorporará la información necesaria para la aprobación final del Análisis del
Sistema de Información, según el siguiente índice:
Introducción.
Ámbito y alcance.
Participantes.
Requisitos del sistema de información.
Visión general del sistema de información.
Referencia de los productos a entregar.
Plan de acción
5.2.2.10. Actividad - Especificación del plan de pruebas.
Tarea 5.2.2.10.1. Especificar y justificar los niveles de pruebas a realizar,
así como el marco general de planificación de cada nivel de prueba, según
el siguiente esquema:
Definición de los perfiles implicados en los distintos niveles de
prueba.
Planificación temporal.
Criterios de verificación y aceptación de cada nivel de prueba.
39
Definición, generación y mantenimiento de verificaciones y casos de
prueba.
Análisis y evaluación de los resultados de cada nivel de prueba.
Productos a entregar como resultado de la ejecución de las pruebas.
Tarea 5.2.2.10.2 Definir y recopilar los requisitos relativos al entorno de
pruebas, completando el plan de pruebas.
Tarea 5.2.2.10.3. Especificar las pruebas de aceptación del sistema
describiendo los criterios de aceptación del sistema que sirven de base
para asegurar que satisface los requisitos exigidos, en función de los
siguientes aspectos:
Procesos críticos del sistema.
Rendimiento del sistema.
Seguridad.
Disponibilidad
5.2.2.11. Actividad - Presentación y aprobación del Análisis del Sistema de
Información.
Tarea 5.2.2.11.1. Presentar los resultados obtenidos a partir de las tareas
dentro del Análisis del Sistema de Información (ASI) y Especificación de
Requisitos de Software (ERS) al Comité de Dirección, para su aprobación
final.
5.2.3. Subproceso – Diseño del Sistema de Información (DSI).
40
En esta etapa se trata de definir la arquitectura general del sistema de
información, especificando dentro de sus componentes las distintas particiones
físicas del mismo, la descomposición lógica en subsistemas de diseño y la
ubicación de cada subsistema en cada partición, así como la especificación
detallada de la infraestructura tecnológica necesaria para dar soporte al sistema
de información.
5.2.3.1. Actividad - Definición de la arquitectura del sistema.
Tarea 5.2.3.1.1. Describir los niveles de la arquitectura software, mediante
la definición de las principales particiones físicas del sistema de
información, representadas como nodos y comunicaciones entre nodos.
Tarea 5.2.3.1.2. Especificar los requisitos que están directamente
relacionados con la adopción o diseño de una arquitectura o infraestructura
concreta, y que pueden condicionar el diseño o la construcción del sistema
de información, todo el con el fin de actualizar el catálogo de requisitos.
Tarea 5.2.3.1.3. Definir los estándares técnicos y de nomenclatura, normas
y recomendaciones, que generalmente están relacionados con la adopción
o diseño de una arquitectura o infraestructura tecnológica concreta, y que
pueden condicionar el diseño o la construcción del sistema de información.
Tarea 5.2.3.1.4. Dividir de forma lógica el sistema de información en
subsistemas de diseño, con el fin de reducir la complejidad y facilitar el
mantenimiento. Hay que tomar como referencia inicial los subsistemas de
análisis especificados en el proceso de Análisis del Sistema de Información
(ASI).
41
Tarea 5.2.3.1.5. Definir en detalle los distintos elementos de la
infraestructura técnica que dan soporte al sistema de información,
determinando la implementación concreta de los nodos y comunicaciones
especificados en la tarea Definición de Niveles de Arquitectura (DSI).
Tarea 5.2.3.1.6. Definir los procedimientos de seguridad y operación
necesarios para no comprometer el correcto funcionamiento del sistema y
garantizar el cumplimiento de los niveles de servicios que exigirá el sistema
en cuanto a la gestión de operaciones (procesos por lotes, seguridad,
comunicaciones, etc.). Los niveles de servicio se especifican formalmente
en el proceso Implantación y Aceptación del Sistema (IAS).
5.2.3.2. Actividad - Diseño de la arquitectura de soporte.
Tarea 5.2.4.2.1. Especificar y diseñar los módulos/clases que forman parte
de los subsistemas de soporte, identificados en la tarea 5.2.3.1.5,
Identificación de Subsistemas de Diseño. Esta tarea se lleva a cabo
siempre y cuando no se disponga en la instalación de servicios comunes
que respondan satisfactoriamente a los requisitos planteados.
Tarea 5.2.4.2.2. Identificar y diseñar, en el caso de no existir en la
instalación, mecanismos genéricos de diseño y construcción, que sirvan
como patrones o guías de diseño.
5.2.3.3. Actividad - Diseño de casos de uso reales.
Esta actividad, que se realiza sólo en el caso de diseño orientado a objetos y tiene
como propósito especificar el comportamiento del sistema de información para un
42
caso de uso, mediante objetos o subsistemas de diseño que interactúan, y
determinar las operaciones de las clases e interfaces de los distintos subsistemas
de diseño.
Es importante anotar que las tareas incluidas dentro de las actividades 5.2.3.3
Diseño de casos de usos reales y 5.2.3.4. Diseño de clases se realizan en
paralelo.
Tarea 5.2.3.3.1. Identificar las clases que intervienen en cada caso de uso,
a partir del conjunto de clases que definidas paralelamente en la tarea
5.2.3.4.1 Identificación de Clases Adicionales.
Tarea 5.2.3.3.2. Definir la interacción entre los objetos identificados en la
tarea 5.2.3.3.1 para realizar, desde un punto de vista técnico, un caso de
uso del sistema de información. Para ello, se parte de los escenarios
especificados en el análisis, y se detallan teniendo en cuenta que se deben
llevar cabo sobre un entorno tecnológico concreto y unos mecanismos
genéricos de diseño.
Tarea 5.2.3.3.3. Diseñar detalladamente el comportamiento de la interfaz de
usuario, a partir de la especificación de la misma, de acuerdo con el entorno
tecnológico definido.
Tarea 5.2.3.3.4. Describir cada caso de uso en términos de los subsistemas
que interviene en el caso de uso y las interfaces que se requieren entre
ellos.
5.2.3.4. Actividad - Diseño de clases.
43
Tarea 5.2.3.4.1. Identificar un conjunto de clases que completen el modelo
de clases analizado en la tarea Validación de los Modelos del proceso
anterior teniendo en cuenta que:
Cada interfaz identificada en el análisis se corresponde en el diseño
con una clase que proporcione esa interfaz.
El conjunto de clases del análisis puede modificarse en función de
las tecnologías de desarrollo utilizadas y de los mecanismos
genéricos de diseño especificados.
Tarea 5.2.3.4.2. Completar las asociaciones entre las clases del modelo de
clases del diseño, estudiando la secuencia de mensajes entre los objetos
correspondientes en el diagrama de interacción de los escenarios definidos
en la tarea 5.2.3.3.2. Descripción de la Interacción entre Objetos.
Tarea 5.2.3.4.3. Definir detalladamente las operaciones de cada clase de
diseño. Para ello, se toma como punto de partida el modelo de clases
generado en el análisis, así como el diseño de los casos de uso reales y los
requisitos de diseño que pueden aparecer al definir el entorno de desarrollo.
Tarea 5.2.3.4.4. Revisar la jerarquía de clases que ha surgido en el modelo
de clases a lo largo de las tareas anteriores y comprobar que esa jerarquía
es viable según los mecanismos disponibles en el entorno de desarrollo
utilizado.
Tarea 5.2.3.4.5. Describir los métodos que se usan para detallar como se
realiza cada una de las operaciones de una clase.
44
Tarea 5.2.3.4.6. Especificar, en caso de que sea necesario, las necesidades
de migración o carga inicial de los datos requeridos por el sistema,
5.2.3.5. Actividad - Diseño de la arquitectura de módulos del sistema.
Tarea 5.2.3.5.1. Definir las interfaces entre los módulos de cada
subsistema, entre subsistemas y con el resto de los sistemas, incluyendo
tanto la comunicación de control como los datos propios del sistema, de
acuerdo a la arquitectura propuesta y a las características del entorno
tecnológico. Hay que definir interfaces sencillas, que permitan reducir la
complejidad de comunicación entre los distintos módulos, especialmente los
relacionados con las comunicaciones entre subsistemas.
Tarea 5.2.3.5.3. Realizar el diseño detallado de la interfaz de usuario, tanto
de pantalla como impresa, a partir de la especificación obtenida en el
proceso de Análisis del Sistema de Información, de acuerdo al entorno
tecnológico seleccionado y considerando los estándares y directrices
marcados por el Comité de Dirección.
5.2.3.6. Actividad - Diseño físico de datos.
Tarea 5.2.3.6.1.Realizar el diseño del modelo físico de datos a partir del
modelo lógico de datos normalizado o del modelo de clases, en el caso de
diseño orientado a objetos.
Tarea 5.2.3.6.2. Determinar los caminos de acceso a los datos persistentes
del sistema, utilizados por los principales módulos/clases de acuerdo al
modelo físico de datos, con el fin de optimizar el rendimiento de los
45
gestores de datos o sistemas de ficheros y el consumo de recursos, así
como disminuir los tiempos de respuesta.
Tarea 5.2.3.6.3. Optimizar el diseño físico de datos, con el objetivo de
mejorar el tiempo de respuesta en el acceso a datos persistentes, hacer
una adecuada utilización de los recursos del sistema y, en consecuencia,
garantizar que el diseño satisface las necesidades de tratamiento
establecidas para el sistema de información en cuanto a que se ajusta a los
requisitos de rendimiento exigidos.
Tarea 5.2.3.6.4. Determina el modelo de distribución de datos, teniendo en
cuenta los requisitos de diseño establecidos. Se establece la ubicación de
los gestores de bases de datos o sistemas de ficheros, así como de los
distintos elementos de la estructura física de datos, en los nodos
correspondientes, de acuerdo al particionamiento físico del sistema de
información especificado en la actividad Diseño de la Arquitectura del
Sistema
5.2.3.7. Actividad - Verificación y aceptación de la arquitectura del sistema.
Tarea 5.2.3.7.1. Asegurar la calidad formal de los distintos modelos,
conforme a la técnica seguida para la elaboración de cada producto y a las
normas y estándares especificados en el catálogo de normas.
Tarea 5.2.3.7.2. Asegurar que las especificaciones del diseño son
coherentes entre sí, comprobando la falta de ambigüedades o duplicación
de información. Esta consistencia se asegura entre especificaciones de
diseño, y con respecto a los modelos del análisis.
46
Tarea 5.2.3.7.3. Obtener la aceptación, por parte de la Gerencia Integral de
la Interventoría Ingetec-Sedic, de la arquitectura del sistema de información
y de los requisitos de operación y seguridad, con el fin de poder valorar su
impacto en la instalación.
5.2.3.8. Actividad - Generación de especificaciones de construcción.
Tarea 5.2.3.8.1. Definición de manera detalla y completa del entorno
necesario para la construcción de los componentes del sistema de
información, de acuerdo a:
Entorno tecnológico: hardware, software y comunicaciones.
Herramientas, generadores de código y compiladores.
Restricciones técnicas.
Planificación de capacidades previstas.
Requisitos de operación y seguridad.
Tarea 5.2.3.8.2. La especificación de los subsistemas de construcción se
realiza a partir de los subsistemas de diseño, con una continuidad directa,
permitiéndose a su vez un mayor nivel de detalle agrupando componentes
en subsistemas dentro de un subsistema de construcción.
Tarea 5.2.3.8.3. Especificar de manera detallada cada componente, en
pseudocódigo o lenguaje natural, completando la información que se
considere necesaria según el entorno tecnológico y determinan y
especifican todos los elementos o parámetros complementarios a la propia
definición de componentes que, en función del entorno tecnológico,
completan las especificaciones de construcción
47
Tarea 5.2.3.8.4. Especificar las necesidades para la definición y creación de
los elementos del modelo físico de datos, mediante el lenguaje de definición
de datos del correspondiente gestor de base de datos o sistema de
ficheros, teniendo en cuenta el entorno tecnológico, las normas y
estándares de la organización y características intrínsecas del gestor o
sistema de ficheros a utilizar.
5.2.3.9. Actividad - Diseño de la migración y carga inicial de datos.
Tarea 5.2.3.9.1. Definir el entorno tecnológico propio de los procesos de
migración y carga inicial, adecuando al mismo las necesidades y requisitos
reflejados en el plan de migración y carga inicial de datos. En la descripción
del entorno tecnológico, hay que tener en cuenta las herramientas o
utilidades software específicas de estos procesos.
Tarea 5.2.3.9.2. Definir de los procedimientos necesarios para llevar a cabo
la migración y carga inicial de datos del sistema.
Tarea 5.2.3.9.3. Diseñar, en sucesivos niveles de detalle, los módulos de
migración y carga inicial, indicando la jerarquía y orden de ejecución.
Tarea 5.2.3.9.4. Completar la especificación del plan de migración y carga
inicial, concretando el plan de trabajo de acuerdo a los procedimientos y
procesos de migración y carga inicial definidos.
5.2.3.10. Actividad - Especificación técnica del plan de pruebas.
48
Tarea 5.2.3.10.1. Definir, de manera detallada y completa, el entorno
necesario para la realización de las pruebas del sistema: unitarias, de
integración, de implantación y de aceptación.
Tarea 5.2.3.10.2. Acorde con las características del diseño del sistema,
establecer las verificaciones de acuerdo a los niveles de prueba
establecidos, de tal forma que sean aplicables a grupos de componentes y
cubran aspectos funcionales y no funcionales que aseguren el buen
funcionamiento. Dichas verificaciones deben puntualizar:
Diseñar, de manera detallada, los distintos niveles de prueba, especificados
en el plan de pruebas elaborado en el proceso Análisis del Sistema de
Información. Estas verificaciones deben cubrir aspectos funcionales y no
funcionales, considerando las excepciones que puedan producirse, así
como las soluciones de diseño adoptadas, tanto del propio diseño de
detalle del sistema de información, como de la utilización de subsistemas
de soporte propios de la instalación, especificando:
Ámbito de aplicación (prueba unitaria, de integración, del sistema, de
implantación o aceptación) y objetivo.
Casos de prueba.
Procedimientos de prueba.
Entorno de prueba.
Criterios de aceptación de la prueba.
Análisis y evaluación de resultados.
Tarea 5.2.3.10.3. Completar y especificar la planificación de las pruebas,
determinando los distintos perfiles implicados en la preparación y ejecución
de las pruebas y en la evaluación de los resultados, así como el tiempo
49
estimado para la realización de cada uno de los niveles de prueba, de
acuerdo a la estrategia de integración establecida.
5.2.3.11. Actividad - Establecimiento de requisitos de implantación.
Tarea 5.2.3.11.1. Recabar toda la información necesaria para la
especificación de la documentación a entregar al usuario, que incluirá los
manuales de usuario y, cuando proceda, los manuales de explotación.
Tarea 5.2.3.11.2. Especificar de forma detallada los requisitos de
implantación, generalmente relacionados con la formación, infraestructura e
instalación, con el fin de preparar y organizar, con la antelación suficiente,
todos los recursos necesarios para la implantación e instalación del sistema
de información.
5.2.3.12. Aprobación del diseño del sistema de información.
Tarea 5.2.3.12.1 realiza la presentación del diseño del sistema de
información al Comité de Dirección del proyecto por parte de la Gerencia
Integral de la Interventoría Ingentec-Sedic para la aprobación final del
mismo.
5.2.4. Subproceso – Construcción del Sistema de Información (CSI).
Para el buen funcionamiento del sistema de información es necesario realizar
aquellas actividades donde se generan los códigos de cada uno de los
componentes, se desarrollan los procedimientos de seguridad y operación, junto
con los manuales de usuarios. En esta etapa se realizan dichas actividades.
50
5.2.4.1. Actividad - Preparación del entorno de generación y construcción.
Tarea 5.2.4.1.1. Esta tarea implica: a) Crear los elementos del sistema
gestor de base de datos o sistema de ficheros; b) Reservar el espacio de
almacenamiento, definiendo, entre otros, los dispositivos físicos a emplear,
tamaño de los bloques, tipo de registro físico, zona de desbordamiento,
opciones de almacenamiento de datos, etc. y c) Inicializar la base de datos
o ficheros, cargando los datos considerados necesarios en el espacio de
almacenamiento previamente definido.
Tarea 5.2.4.1.2. Preparar el entorno en el que se construirán los
componentes del sistema de información.
5.2.4.2. Actividad - Generación del código de los componentes y procedimientos.
Tarea 5.2.4.2.1. Genera el código correspondiente a cada uno de los
componentes del sistema de información, identificados en la tarea 5.2.3.8.2
Definición de Componentes y subsistemas de Construcción del (DSI).
Tarea 5.2.4.2.2. Generar los procedimientos de operación y administración
del sistema de información, así como los procedimientos de seguridad y
control de acceso, necesarios para ejecutar el sistema una vez que se haya
implantado y esté en producción.
5.2.4.3. Actividad - Ejecución de las pruebas unitarias.
Tarea 5.2.4.2.3. Realizar las pruebas unitarias de cada uno de los
componentes del sistema de información, una vez codificados, con el objeto
51
de comprobar que su estructura es correcta y que se ajustan a la
funcionalidad establecida.
Tarea 5.2.4.2.4. Preparar todos los recursos necesarios para realizar las
pruebas unitarias de cada uno de los componentes del sistema de
información.
5.2.4.4. Actividad - Ejecución de las pruebas de integración.
Tarea 5.2.4.4.1. Asegurar la disponibilidad de todos los recursos necesarios
para la realización de las pruebas de integración (entorno, datos, librerías y
procedimientos), que permitan observar si los componentes están
interactuando correctamente a través de sus interfaces.
Tarea 5.2.4.4.2. Comprobar el correcto funcionamiento de los componentes
del sistema de información, codificados en la actividad 5.2.4.2 Generación
del Código de los Componentes y Procedimientos del (CSI), conforme a las
verificaciones establecidas en el plan de pruebas para el nivel de pruebas
unitarias, en la actividad 5.2.3.10 Especificación Técnica del Plan de
Pruebas del (DSI).
5.2.4.5 Actividad - Ejecución de las pruebas del sistema.
Tarea 5.2.4.5.1. Disponen todos los recursos necesarios para realizar las
pruebas de integración de los componentes y subsistemas que conforman
el sistema de información, asegurando la disponibilidad del entorno y de los
datos necesarios para ejecutar estas pruebas.
52
Tarea 5.2.4.5.2. Verificar el correcto funcionamiento de las interfaces
existentes entre los distintos componentes y subsistemas, conforme a las
verificaciones establecidas para el nivel de pruebas de integración.
Tarea 5.2.4.5.3. Analizar los resultados de las pruebas de integración y
efectuar su evaluación. Dicha evaluación recoge el grado de cumplimiento
de las pruebas y consiste en: Comparar los resultados obtenidos con los
esperados, identificar el origen de cada problema detectado para poder
remitirlo a quien proceda, determinar la envergadura de las modificaciones
y qué acciones deben llevarse a cabo para resolverlo de forma satisfactoria
e indicar si el plan de pruebas debe volver a realizarse total o parcialmente,
y si será necesario contemplar nuevos casos de prueba no considerados
anteriormente.
5.2.4.6. Actividad - Evaluación de los manuales de usuario.
Tarea 5.2.4.6.1. Elaborar la documentación de usuario, tanto usuario final
como de explotación, de acuerdo a los requisitos establecidos en la tarea
5.2.3.11.1 Especificación de Requisitos de Documentación de Usuario del
(DSI), y recogidos en el catálogo de requisitos.
5.2.4.7. Actividad - Definición de la formación de usuarios finales.
Tarea 5.2.4.7.1. Establecer las necesidades de formación del usuario final,
con el objetivo de conseguir la explotación eficaz del nuevo sistema.
Tarea 5.2.4.7.2. Definir el contenido de la formación del usuario final del
sistema, realizando, a su vez, una estimación de la duración de los distintos
apartados o acciones formativas que se contemplen.
53
5.2.4.8. Actividad - Construcción de los componentes y procedimientos de
migración y carga inicial de datos.
Tarea 5.2.4.8.1. En esta tarea se debe: a) disponer el entorno en el que se
van a construir los componentes y procedimientos de migración y carga
inicial de datos, considerando las bibliotecas o librerías a utilizar,
herramientas o utilidades específicas para la conversión, y compiladores,
entre otros, cuya necesidad se habrá establecido en la tarea 5.2.3.9.1
Especificación del Entorno de Migración del (DSI) y b) determinar los datos
necesarios para realizar las pruebas de los componentes y procedimientos
asociados y se configura el entorno de acuerdo a dichas necesidades.
Tarea 5.2.4.8.2. Generar del código correspondiente a los procedimientos y
componentes necesarios para llevar a cabo la migración, definidos en el
plan de migración y carga inicial de datos obtenidos en las tareas 5.2.3.9.2
Diseño de Procedimientos de Migración y Carga Inicial y 5.2.3.9.3 Diseño
Detallado de Componentes de Migración y Carga Inicial del (DSI).
Tarea 5.2.4.8.3. Efectuar las pruebas de los distintos componentes y
procedimientos de migración y evaluar su resultado. Esta evaluación recoge
el grado de cumplimiento de las mismas, y consiste en: Comparar los
resultados obtenidos con los esperados, identificar el origen de cada
problema detectado para poder remitirlo a quien proceda, determinar la
envergadura de las modificaciones y qué acciones deben llevarse a cabo
para resolverlo de forma satisfactoria e indicar si el plan de pruebas debe
volver a realizarse total o parcialmente, y si será necesario contemplar
nuevos casos de prueba no considerados anteriormente.
54
5.2.4.9. Actividad - Aprobación del sistema de información.
Tarea 5.2.4.9.1. Recopilar los productos del sistema de información y se
presentan al Comité de Dirección, delegado por la Gerencia Integral de la
Interventoría Ingetec-Sedic, para su aprobación.
5.2.5. Subproceso – Implantación y Aceptación del Sistema.
Este proceso tiene como objetivo principal la entrega y aceptación del sistema en
su totalidad, y la realización de todas las actividades necesarias para el paso a
producción del mismo.
5.2.5.1. Actividad - Establecimiento del plan de implantación.
Tarea 5.2.5.1.1. Definir un plan de implantación que permita calcular
adecuadamente el esfuerzo y los recursos necesarios para llevar a cabo
con éxito la implantación. Dicho plan debe contemplar todas las tareas
relacionadas con:
La formación necesaria para la implantación, tanto a usuarios finales
como al equipo que se encarga de realizar las pruebas de
implantación y aceptación del sistema.
La preparación de la infraestructura necesaria para la incorporación
del sistema al entorno de operación.
La instalación de todos los componentes y procedimientos manuales
y automáticos asociados a cada sistema de información implicado en
la implantación.
55
Tarea 5.2.5.1.2. Identifican, en función del nivel de esfuerzo requerido, los
distintos participantes implicados en la implantación del sistema (usuarios,
equipo técnico y responsable de mantenimiento), determinando
previamente sus perfiles, responsabilidades, nivel de implicación y fechas
previstas de participación a lo largo de toda la implantación.
5.2.5.2. Actividad - Formación necesaria para la implantación.
Tarea 5.2.5.2.1. Define la formación necesaria para el equipo de trabajo
responsable de la implantación y aceptación del sistema, estableciendo el
esquema de formación para cada tipo de perfil dentro del equipo y la
duración estimada de los cursos.
Tarea 5.2.5.2.2. Formar al equipo que va a ser responsable de la
implantación y aceptación del sistema, según el plan de formación que se
haya establecido en la tarea anterior, asegurando la asistencia de todos sus
integrantes.
Tarea 5.2.5.2.3. Revisa el esquema de formación a los usuarios finales,
elaborado en la actividad 5.2.5.2 Definición de la Formación de Usuarios
Finales del (CSI), asegurando que se cuenta con los recursos humanos,
técnicos y materiales necesarios para realizar la formación correspondiente.
Tarea 5.2.5.2.4 Realizar seguimiento al plan de formación previsto e
informar de las posibles desviaciones para tomar las medidas oportunas.
5.2.5.3. Actividad - Incorporación del sistema al entorno de operación.
56
Tarea 5.2.5.3.1. Verificar que está disponible la infraestructura necesaria
para configurar el entorno. Dicha infraestructura debe cumplir los requisitos
de implantación (instalación e infraestructura) y tener en cuenta los
procedimientos de seguridad y control de acceso (mantenimiento de la
integridad y confidencialidad de los datos, control de accesos al sistema,
copias de seguridad y recuperación de datos, etc.), y operación y
administración del sistema (estándares, recuperación y reanudación de
trabajos, planificación de trabajos, etc.).
Tarea 5.2.5.3.2. Instalar todos los componentes del nuevo sistema,
incluidos los procedimientos manuales y automáticos, de acuerdo al plan de
implantación y a su ubicación física, establecida en el proceso Diseño del
Sistema de Información. Se deben tener en cuenta los estándares y
normativas por los que se rige la organización en los entornos de
operación. Asimismo, se prepara el entorno de datos identificando los
sistemas de información que forman parte del sistema objeto de la
implantación. Para cada uno de ellos:
Se crean las bases de datos a partir del esquema físico elaborado en
el proceso de construcción.
Se establecen los procedimientos de explotación y uso de las bases
de datos, es decir, la normativa necesaria para la utilización de las
bases de datos, actualización, consulta, etc.
Se revisan los procedimientos necesarios para realizar las copias de
seguridad de los datos y de restauración de las copias indicando su
frecuencia, así como los procedimientos de consolidación y
sincronización de la información, estos últimos cuando proceda.
Se preparan las autorizaciones de acceso a los datos para los
distintos perfiles de usuarios.
57
5.2.5.4. Actividad - Carga de datos al entorno de operación.
Tarea 5.2.5.4.1 Realizar la carga inicial de datos del nuevo sistema, y se
comprueba que ha finalizado correctamente. A continuación, si procede, se
hace la migración de datos, activando los procedimientos correspondientes,
para efectuar la transformación de los datos de la estructura existente a la
nueva. Se lleva a cabo la depuración de los datos que no sean
consistentes, hasta comprobar su correcta finalización.
5.2.5.5. Actividad - Pruebas de implantación del sistema.
Tarea 5.2.5.5.1. Comprobar la disponibilidad de los recursos humanos y
técnicos necesarios para realizar las pruebas de implantación. Se revisan
las verificaciones establecidas en el plan de pruebas. Si fuera necesario, se
crea algún caso de prueba adicional que se considere importante y que no
se haya tenido en cuenta hasta entonces. Se preparan las condiciones que
permitan simular las situaciones límite previstas para las pruebas.
Tarea 5.2.5.5.2. Realizar las pruebas de implantación, de acuerdo a las
verificaciones establecidas en el plan de pruebas definido en la actividad
5.2.3.10 Especificación Técnica del Plan de Pruebas del (DSI). Es
necesario tener en cuenta las posibles pruebas adicionales incorporadas a
dicho plan en la tarea anterior.
Tarea 5.2.5.5.3. Evaluar los resultados de las pruebas analizando las
incidencias recibidas y comprobando que se han llevado a cabo todos los
casos de pruebas establecidos en el plan de pruebas. Dicha evaluación
consiste en:
58
Comparar los resultados obtenidos con los esperados.
Identificar el origen de cada problema para poder remitirlo a quién
proceda, determinar la envergadura de las modificaciones y las
acciones que deben llevarse a cabo para resolverlo de forma
satisfactoria.
Indicar si el plan de pruebas debe volver a realizarse total o
parcialmente, y si será necesario contemplar nuevos casos de
prueba no considerados anteriormente.
5.2.5.6. Actividad – Pruebas de aceptación del sistema.
Tarea 5.2.5.6.1. Analizan los criterios de aceptación establecidos por el
usuario y recogidos en las verificaciones del plan de pruebas, por si fuera
necesario incorporar algún caso de prueba adicional.
Tarea 5.2.5.6.2. Realizar las pruebas de aceptación final del sistema para
asegurar que todos los componentes responden a los criterios de
aceptación especificados. Se registra la realización de las pruebas,
incluyendo un informe que recoja la desviación de los requisitos
establecidos y los problemas que quedan sin resolver.
Tarea 5.2.5.6.3. Evaluar los resultados de las pruebas, analizando las
incidencias recibidas y comprobando que se han llevado a cabo todos los
casos de pruebas establecidos en el plan de pruebas. Dicha evaluación
consiste en:
Comparar los resultados obtenidos con los esperados.
Identificar el origen de cada problema para poder remitirlo a quién
proceda y determinar qué acciones o medidas correctoras es preciso
llevar a cabo para resolverlo de forma satisfactoria.
59
Indicar qué pruebas se debe volver a realizar, o si será necesario
contemplar nuevos casos de prueba.
5.2.5.7. Actividad - Preparación del mantenimiento del sistema.
Tarea 5.2.5.7.1. Recopilar los productos de cada uno de los sistemas de
información implicados en la implantación que van a ser objeto de
mantenimiento. Se entregan a su responsable con el fin de implicarle más
activamente en el dominio del sistema, para que una vez aceptado e
implantado responda de forma satisfactoria a las peticiones de
mantenimiento. El conjunto de productos a entregar dependerá del alcance
y nivel de soporte que se haya establecido previamente para el
mantenimiento del sistema.
Tarea 5.2.5.7.2. Establecer formalmente el plan de mantenimiento para el
sistema, una vez que haya sido aceptado y se incorpore al entorno de
producción. Se fija el tipo de mantenimiento que se va a asumir para cada
sistema de información, determinando los criterios de regulación necesarios
para cada tipo de mantenimiento contemplado y reflejando los requisitos de
formación esenciales, de manera que se pueda responder
satisfactoriamente a las peticiones de mantenimiento. Se estiman los
recursos humanos necesarios para el servicio de mantenimiento
establecido, definiendo claramente sus perfiles, asignando
responsabilidades y determinando las funciones que van a llevar a cabo,
con el fin de garantizar la coordinación en la gestión del mantenimiento.
5.2.5.8. Actividad - Establecimiento del acuerdo de nivel de servicio.
60
Tarea 5.2.5.8.1. Identificar los tipos de servicio requeridos por el sistema
objeto de la implantación, en función de los sistemas de información que
componen el sistema, sus requisitos y su localización geográfica.
Tarea 5.2.5.8.2. Para cada tipo de servicio identificado anteriormente se
detallan sus propiedades funcionales, estableciendo las características que
permiten especificar el funcionamiento del servicio (agentes que
intervienen, acciones que se llevan a cabo, condiciones de activación, etc.).
Asimismo, se especifican las propiedades de calidad que constituyen el
nivel de servicio, y que permiten valorar la calidad de dicho servicio. Estas
propiedades hacen referencia a la eficiencia del sistema (en relación con el
tiempo y recursos necesarios), y su fiabilidad y facilidad de uso, entre otros.
Tarea 5.2.5.8.3. Establecer formalmente los tipos de servicios a los que se
debe dar respuesta, tanto por operación como por el usuario, mediante la
especificación del acuerdo de servicio.
5.2.5.9. Presentación y aprobación del sistema.
Tarea 5.2.5.9.1. Recopilar la información del sistema que se debe entregar
al Comité de Dirección (evaluación de las pruebas, acuerdo de nivel de
servicio y plan de mantenimiento) y se realiza la convocatoria para la
presentación del sistema. Se recibe la confirmación por parte del Comité de
Dirección y se prepara la presentación del sistema.
Tarea 5.2.5.9.2. Se presenta el sistema al Comité de Dirección según el
plan previsto y se aprueba formalmente el sistema.
5.2.5.10. Paso a producción.
61
Tarea 5.2.5.10.1. Analizar la pertinencia de incorporar componentes
adicionales al entorno de producción, de acuerdo a las características y
condiciones del entorno en que se hayan llevado a cabo las pruebas y se
realiza la instalación de los componentes necesarios. Se va lora también,
en cuanto a los datos, la necesidad de realizar una nueva carga, una
inicialización o una restauración.
Tarea 5.2.5.10.2. Arrancar el nuevo sistema en producción activando tanto
el proceso de Mantenimiento, si se ha determinado en el sistema, como los
servicios que se van a prestar.
5.3 Proceso – Mantenimiento del Sistema de Información.
El objetivo de este proceso es la obtención de una nueva versión de un sistema de
información desarrollado con MÉTRICA Versión 3 ó Versión 2, a partir de las
peticiones de mantenimiento que los usuarios realizan con motivo de un problema
detectado en el sistema, o por la necesidad de una mejora del mismo.
5.3.1 Actividad - Registro de la petición.
Tarea 5.3.1.1. Registrar las peticiones que los usuarios solicitan con motivo
de la detección de un problema o por la necesidad de una mejora. Se crea
un catálogo que constituye un medio para la comunicación entre el usuario
o cliente y el responsable de mantenimiento.
Tarea 5.3.1.2. Determina el tipo de mantenimiento requerido por la petición
catalogada, teniendo en cuenta toda la información que se ha registrado en
la tarea anterior. Hay que identificar también los sistemas de información
inicialmente afectados por petición.
62
5.3.2. Actividad - Análisis de la petición.
Tarea 5.3.2.1. Verifica la validez de la petición registrada, determinando si
el problema se puede reproducir, para el caso de un mantenimiento
preventivo o si es razonable o factible, para el caso del mantenimiento
evolutivo.
Tarea 5.3.2.2. Estima el alcance de cada petición, valorando la prioridad
inicialmente asignada, de acuerdo a los requisitos planteados. A
continuación, se analiza la relación entre peticiones. Se decide cuáles
pueden abordarse de forma conjunta asignando, si procede, una prioridad
global a los grupos identificados y determinando en qué secuencia deben
implementarse los cambios.
5.3.3. Actividad - Preparación de la implementación de la modificación.
Tarea 5.3.3.1. Analizar el impacto de la petición, con el fin de conocer el
alcance real de la modificación en función del número, características y
relaciones existentes entre los elementos afectados.
Tarea 5.3.3.2. Eliminar el llamado efecto onda, es decir, que los cambios
provocados por una petición no introduzcan un comportamiento no deseado
o errores adicionales en otros componentes no modificados, especificando
los casos de prueba en función de las relaciones existentes entre los
distintos componentes identificados en la tarea 5.3.3.1 Identificación de
Elementos Afectados del (MSI).
Tarea 5.3.3.3. Realizar el seguimiento del plan de acción de acuerdo a los
puntos de control establecidos en la actividad anterior, monitoreando los
63
cambios necesarios en los componentes de cada sistema de información
afectado, así como en los productos asociados, siguiendo las actividades
correspondientes a los procesos de Análisis, Diseño, Construcción e
Implantación identificadas en la actividad anterior.
5.3.4. Actividad - Seguimiento y evaluación de los cambios hasta la aceptación.
Tarea 5.3.4.1. Se hace el seguimiento del plan de acción de acuerdo a los
puntos de control establecidos en la actividad anterior. Se realiza el
seguimiento de los cambios necesarios en los componentes de cada
sistema de información afectado, así como en los productos asociados,
siguiendo las actividades correspondientes a los procesos de Análisis,
Diseño, Construcción e Implantación identificados en la actividad anterior.
Tarea 5.3.4.2 Realizar las pruebas de regresión definidas en la actividad
anterior con el objeto de asegurar que ningún sistema de información
implicado en el cambio ve comprometido su funcionamiento normal. En el
caso de detectarse problemas, se elabora un informe que recoge las
incidencias y se remite a quién proceda para que tome las medidas
correctivas que considere oportunas.
Tarea 5.3.4.3 Aprobar formalmente la finalización de la petición de
mantenimiento de acuerdo a los resultados obtenidos en la tarea anterior.
Se actualiza el catálogo de peticiones registrando el cierre de la petición
tratada.
64
6. APLICACIÓN DE MÉTRICA 3 AL DISEÑO DEL SIGPP DEL MECANISMO DE
ATENCIÓN A LA COMUNIDAD DEL PHI.
6.1. Planeación del sistema de información.
6.1.1. Descripción general de la PSI.
Luego de un análisis detallado del procedimiento de monitoreo del sistema de
Atención a la comunidad, realizado por el Equipo de Gestión Social de la
Interventoría, se concluyó que es necesario desarrollar un sistema que permita
visualizar la gestión adelantada por el proyecto, para la atención, seguimiento y
cierre de las solicitudes, reclamaciones y quejas interpuestas por la comunidad,
que aporte elementos de análisis complejos para la decisiones por parte de la
Gerencia Integral de la Interventoría.
Desde el comité del proyecto se plantea que la construcción de un sistema de
información está en consonancia con la Política de Responsabilidad Ambiental y
Social del Proyecto Hidroeléctrico Ituango, en cual establece en el numeral 17.3.
Lineamientos.
Mejorar continuamente el desempeño ambiental y social, en el marco de las
posibilidades tecnológicas y económicas.
(…)
El desempeño socialmente responsable será medido y reportado a los grupos
de interés y otros públicos en general, con métricas definidas y alineadas con
estándares aceptados internacionalmente.
65
Las áreas que de la Gerencia Integral que se verán afectadas por el proyecto
serán:
1. La Gerencia Integral de la Interventoría Ingetec-Sedic. Como responsable
de la toma de decisiones del área integral e interlocución con la Gerencia
Técnica de la Interventoría Ingenetec-Sedic.
2. La Coordinación Social de la de la Interventoría Ingetec-Sedic: Como
responsable del monitoreo del sistema de atención a la comunidad del PHI.
3. La Coordinación ambiental de la Interventoría Ingetec-Sedic: Como
responsable del monitoreo del componente físico – biótico del PHI.
4. La Coordinación SISO de la Interventoría Ingetec-Sedic: Como responsable
del monitoreo de los programas de salud ocupacional y seguridad industrial
del PHI.
5. La Coordinación de riesgos de la Interventoría Ingetec-Sedic: Como
responsable del seguimiento de los indicadores de riesgos del PHI.
Teniendo en cuenta lo anterior, el Comité de Dirección del PSI se conformó de la
siguiente manera:
NOMBRE CARGO FUNCIÓN
Ing. Juan Carlos
Peña.
Gerente
Integral
Encabezará el comité y tendrá las
funciones de dirección estratégica del
proyecto y será el responsable de emitir
las aprobaciones necesarias. Director de
Comité
P.S. José Llinás Coordinador
social.
Jefe del proyecto.
Ing. Marcela pareja. Coordinadora
ambiental
Participará en la mesa de discusión,
revisara los productos generados en los
66
diferentes momentos del proyecto y
emitirá un concepto de evaluación frente
a los mismos.
Ing. Jeniffer Tovar. Coordinadora
SISO.
Participará en la mesa de discusión,
revisara los productos generados en los
diferentes momentos del proyecto y
emitirá un concepto de evaluación frente
a los mismos.
Ing. Carlos Pérez. Coordinador
de riesgos.
Participará en la mesa de discusión,
revisara los productos generados en los
diferentes momentos del proyecto y
emitirá un concepto de evaluación frente
a los mismos.
T.S. Yenny
Hernández.
Profesional
social
Usuario experto.
6.1.2. Definición y organización de la PSI.
El alcance del proyecto será: encontrar una manera de visualizar la gestión
adelantada por la Interventoría, dentro del marco del mecanismo de atención a la
comunidad del PHI.
Para lo anterior, deberán considerarse las siguientes delimitaciones:
i) Teniendo en cuenta que la Interventoría Ingetec-Sedic tiene bajo su
supervisión varios de los contratos de construcción del PHI, este proyecto
se aplicará sólo para el Contrato CT-I-2013-000001: Construcción de la vía
entre Puerto Valdivia y el sitio de la presa del Proyecto Hidroeléctrico
Ituango.
67
ii) Para la construcción del mismo se deberá tener en cuenta los
procedimientos establecidos en el mecanismo de atención a la comunidad
del PHI.
iii) El sistema será alimentado con los registros generados por el mecanismo
de atención a la comunidad desde el inicio de las obras objeto del Contratos
CT-2013-000001, hasta el 31 de diciembre de 2014.
Las áreas que de la Gerencia Integral que se verán afectadas por el proyecto
serán:
1. La Gerencia Integral de la Interventoría Ingetec-Sedic. Como responsable
de la toma de decisiones del área integral e interlocución con la Gerencia
Técnica de la Interventoría Ingenetec-Sedic.
2. La Coordinación Social de la de la Interventoría Ingetec-Sedic: Como
responsable del monitoreo del sistema de atención a la comunidad del PHI.
3. La Coordinación ambiental de la Interventoría Ingetec-Sedic: Como
responsable del monitoreo del componente físico – biótico del PHI.
4. La Coordinación SISO de la Interventoría Ingetec-Sedic: Como responsable
del monitoreo de los programas de salud ocupacional y seguridad industrial
del PHI.
5. La Coordinación de riesgos de la Interventoría Ingetec-Sedic: Como
responsable del seguimiento de los indicadores de riesgos del PHI.
6.1.3. Estudio de la información relevante.
Se realizó una revisión de los sistemas de información con alcance similar
(mecanismos de atención a la comunidad o PQRs) y se identificó que en la
actualidad los desarrollos se han encaminado hacia el control de los tiempos de
respuesta de las atenciones recibidas. En este sentido, se apunta que el objetivo
68
de este tipo de software apunta a garantizar la oportunidad de las respuestas,
atendiendo los tiempos establecidos por la ley, dejando a un lado el asunto de la
gestión misma, del análisis del proceso de atención como un todo.
En el mercado se encuentra una serie de software dirigidos a empresas del sector
público, basados en la metodología del semáforo, el cual emite unas alertas sobre
los casos a los que se les está agotando los términos de respuesta. Esta es la
base del sistema Mercurio, adoptado por EPM para el control del sistema de
atención a la comunidad, desde su plataforma central. Al respecto, se anota que el
alcance real de este software es la gestión de correspondencia, quedando
desatendido el monitoreo del proceso mismo de trámite y seguimiento del caso.
De esta manera, los desarrollos en esta metería o similares no tiene como objeto
de interés el visualizar la gestión asociada a la atención, trámite, evaluación,
análisis y solución de los casos que ingresarían al sistema a través del mecanismo
de atención a la comunidad.
El proceso afectado por el sistema de información será el mecanismo de atención
a la comunidad. Este proceso implica a:
1. Coordinador social: Realiza el análisis de indicadores de cumplimiento por
parte del contratista respecto al mecanismo, determina la criticidad de los
casos, señala amenazas y reporta a la gerencia Integral.
2. Profesional social: Da cuenta a la coordinación social de las evidencias de
las acciones ejecutada por el Contratista dentro del mecanismos de
atención a la comunidad.
6.1.4. Identificación de requisitos.
69
El proceso que enmarca el mecanismo de atención a la comunidad se da en tres
etapas:
1. Recepción de atención.
2. Seguimiento y trámite de la atención.
3. Cierre de atención.
En este sentido, el sistema debería dar cuenta de las siguientes cuestiones, sobre
el mecanismo de atención a la comunidad:
REQUISITO IDENTIFICADO. PROCESO
1. ¿Cuándo se recibió la atención?
2. ¿Quién es el titular del caso?
3. ¿Cuál es el estado de la atención?
4. ¿Qué áreas involucra?
5. ¿Qué acciones se han adelantado?
6. ¿Cómo se cerró?
7. ¿Cuándo se cerró?
Recepción.
Recepción.
Trámite.
Trámite.
Seguimiento.
Cierre.
Cierre.
Se concluye en este punto que las respuestas a las anteriores preguntas son
determinantes para analizar en profundad las acciones adelantadas por el por el
proyecto dentro del mecanismo de atención a la comunidad y estas no pueden ser
resultas por el sistema de información que actualmente se implementa.
6.1.5. Estudio de los sistemas de información actuales.
La Interventoría Ingetec-Sedic no lleva actualmente una base de datos que
permita el control de los casos recepcionados a través del mecanismo de atención
70
a la comunidad, de manera que los registros de atención, seguimiento y cierre de
casos se encuentran archivados en AZ en el archivo general de la Interventoría.
En este sentido se precisa:
1. La posibilidad de consulta se ve restringida, haciéndose obligatorio el
remitirse nuevamente a los expedientes físicos asociados a cada caso.
2. El sistema actual se basa en un modelo casuístico.
3. El sistema actual no permite crear un modelo de lo que acontece al interior
del mecanismo de atención a la comunidad y tampoco permite establecer
relaciones entre variables, de manera que no es posible generar un análisis
profundo del que se extraigan conclusiones de fondo para la toma de
decisiones.
6.1.6. Diseño del modelo de información.
Partiendo del análisis de la información relevante, desarrollo similares, estado
actual del sistema, requisitos deseables y condicionantes se propone la
construcción de un Sistema de Información Geográfico aplicado a los registros que
surten como evidencias del funcionamiento del mecanismo de atención a la
comunidad del Proyecto Hidroeléctrico Ituango, para el Contrato CT-I-2013-
000001: Construcción de la vía entre Puerto Valdivia y el sitio de la presa del
Proyecto Hidroeléctrico Ituango.
6.1.7. Definición de la arquitectura tecnológica.
La arquitectura tecnología que soportara el proyecto, debe sujetarse a los
siguientes condicionantes:
71
1. La Interventoría Ingetec-Sedic opera desde el campamento Tacuí, oficinas
de obra de EPM. De esta manera, la infraestructura que se vaya a montar
debe estar acorde a la capacidad técnica instalada en las oficinas.
2. Teniendo en cuenta lo procesos de licenciamiento a los que está sujeto
EPM para la instalación de software es necesario montar el sistema a partir
de los paquetes que se encuentran ya licenciados: paquete de office,
Autocad, Proyect y ArcGis.
3. No es posible utilizar equipos diferentes a los dispuestos por EPM en los
puestos de trabajo, por regulación de la Gerencia Instrumental de la
interventoría y de EPM.
4. Se deberá tener en cuenta que los permisos de acceso a la red son
regulados por EPM y su consecución implica un trámite dispendioso, por lo
que es recomendable pensar en un sistema administrado por máximo 2
usuarios en 1 sólo equipo.
6.1.8. Definición del plan de acción.
El plan de acción fue aprobado por la Gerencia Integral de Interventoría, mediante
acta interna No.19, fechada el 5 de noviembre de 2014 y está incluido en el
numeral 7. CRONOGRAMA.
6.1.9. Revisión y aprobación.
El proyecto propuesto fue aprobado por la Gerencia Integral de Interventoría,
mediante acta interna No.19, fechada el 5 de noviembre de 2014.
6.2. Estudio de la viabilidad del sistema.
Alcance del Sistema de Información.
72
El sistema que se propone deberá asignarle un consecutivo a cada solicitud,
permitir saber cuándo se instauro, el titular de la misma, el asunto que plantea, el
área que involucra, el tipo de atención a la que corresponde, su ubicación en
campo, el seguimiento realizado y la fecha de cierre, de manera que se puedan
realizar las siguientes tareas:
1. Realizar consultas sobre el estado o avance de cada proceso.
2. Ubicar geográficamente cada solicitud ingresada al mecanismo de atención
a la comunidad.
3. Realizar consultas temáticas, por área involucrada y tipo de atención.
4. Consolidar el total de las solicitudes cargadas en mecanismo.
5. Filtrar las solicitudes cerradas y las que se encuentran en seguimiento.
6. Establecer cruces de variables, en función a los atributos: ubicación, fecha
de ingreso, fecha de cierre, titular de solicitud, área involucrada y tipo de
atención.
Catálogo de usuarios.
Por usuarios del sistema se entiende aquellos funcionarios que se relacionaran
directamente con el mismo bien sea administrándolo, operándolo, consultándolo o
realizando labores de mantenimiento.
En este sentido se definen:
a) Gerente Integral de la Interventoría.
b) Coordinadores de Gestión Integral de la Interventoría
c) Profesionales sociales de la Interventoría.
Estudio de la situación actual.
73
En la actualidad, los datos recogidos en los formatos de recepción, seguimiento y
cierre de casos, dentro del marco del mecanismo de atención a la comunidad, no
se encuentra organizados ni estructurados en una base de datos, lo que
representa una deficiencia en el procesamiento de la información generada desde
este componente del plan de gestión social.
Los registros de recepción, seguimiento y cierre son agrupados por casos,
conformando un expediente para cada uno de estos los cuales se archivan en AZ
que reposan en el archivo general de la Interventoría. En el informe mensual de
gestión social, se remite al Cliente copia de los casos cerrados.
En su conjunto, el procedimiento expuesto anteriormente, además de
rudimentario, no facilita la respuesta oportuna a los requerimientos de información
que realiza el Cliente respecto a los procesos que se adelantan dentro del marco
del mecanismo de atención a la comunidad, en la medida en que no permite
realizar consultas rápidas y eficientes. Se anota también, como trasfondo, que tal y
como se lleva el mecanismo, no es posible visualizar elementos significativos
dentro de la gestión, para generar alertas tempranas, análisis de contexto y tomar
decisiones soportadas suficientemente.
Definición de los requisitos del sistema
En lo que respecta a la identificación de requisitos, se establece que las directrices
que debe seguir el proyecto están formuladas por la política de responsabilidad
social y ambiental y por el Programa de Monitoreo de Plan de Manejo Ambiental
del PHI.
Estudio de alternativa de solución.
74
Debido a las restricciones operativas y de licenciamiento descritas en la etapa de
Planeación, el proyecto deberá montarse como un sistema de información
geográfica sobre el software ArcGis 10.
En lo que respecta la relación costo/beneficio, no se prevé que se incurrían en
ninguna inversión económica ya que el proyecto se desarrollará con los recursos
tecnológicos y humanos con los que dispone el PHI en la actualidad. No obstante
lo anterior, se prevé el retorno de los siguientes beneficios intangibles:
a) Mejora en los procesos, representado en la optimización del tiempo y los
recursos.
b) Disponer de un sistema de información que permitirá extraer elementos de
análisis necesarios para la toma de decisiones.
c) Posicionar al área social de la Interventoría, dentro del entorno de las
nuevas tecnológicas.
d) Cumplir con los estándares de calidad de la Interventoría, que apuntan a la
satisfacción del Cliente.
6.2.2. Análisis del sistema de información.
Definición de los requisitos del sistema.
Retomando los requisitos identificados en la etapa de Planeación del Sistema de
Información, el alcance del sistema y las necesidades del Equipo Integral de la
Interventoría Ingentec-Sedic y se formulan el siguiente Catálogo de Requisitos:
No. DESCRIPCIÓN TIPO PRIORIDAD
1 El sistema permitirá identificar cada caso por
su número de consecutivo. Funcional 2
75
2 El sistema permite mantener actualizados
todos sus campos. Funcional 1
3 El sistema permitirá identificar cada caso por el
nombre del titular del mismo. Funcional 1
4 El sistema permite clasificar los casos por
dependencia. Funcional 1
5 El sistema permite clasificar los casos por tipo
de atención. Funcional 2
6 El sistema permite clasificar los casos por
complejidad de actores. Funcional 1
7 El sistema permite clasificar los casos por tipo
de solicitud. Funcional 2
8 El sistema permite clasificar los casos por
complejidad temática. Funcional 1
9 El sistema permite clasificar los casos por
responsable. Funcional 3
10 El sistema permite clasificar los casos por
estado. Funcional 1
11 El sistema permite clasificar los casos por la
oportunidad en los tiempos de cierre. Funcional 1
12 El sistema brindara información sobre el asunto
de cada caso. Funcional 3
13 El sistema brindará información sobre el
seguimiento de cada caso. Funcional 3
14 El sistema permitirá georeferenciar los casos. Funcional 1
El sistema deberá diseñarse sobre el software
ArcGis No funcional 1
El sistema deberá funcionar en el Sistema No funcional 1
76
Operativo Windows XP.
PRIORIDADES
Número Nivel 1 Alto 2 Medio 3 Bajo
Tabla 1. Requisitos del sistema.
6.2.3 Modelo de datos.
Continuando con la aplicación de la metodología Métrica V3, se recopila la
información generada desde las mesas de trabajo del equipo de seguimiento del
Proyecto (fundamentalmente para esta etapa las realizadas entre el Jefe del
Proyecto y los Usuarios Expertos) y se parametriza el sistema de información.
Atributo Descripción. Valores Valores
aceptados.
Cod. Interno Corresponde al número consecutivo que identifica cada expediente.
Numéricos. Del 001 al 999.
Fecha de Ingreso Corresponde a la fecha en que se levantó el registro de recepción de la solicitud.
Fecha mm/dd/aaaa
Periodo de ingreso Corresponde al mes y año en que se levantó el registro de la solicitud.
Fecha mm-aaaa
Nombre del ciudadano
Corresponde al nombre completo del titular de la solicitud, tal y como quedó consignado en el registro de la solicitud.
Texto
Primer nombre Segundo nombre Primer apellido Segundo apellido.
Descripción de la Atención
Corresponde al asunto expuesto por el solicitante en el registro.
Texto Hasta 5.000 caracteres.
Calidad del solicitante
Establece la diferenciación entre una solicitud interpuesta por una persona de la comunidad y por un trabajador del proyecto.
Numérico.
1 = Comunidad
2 = Trabajador del proyecto
Tipo de Atención.
Corresponde a la clasificación de los asuntos expuestos en las solicitudes. Texto
Integral. Laboral. Afectación de actividad económica. Afectación
77
ambiental. Afectación a terceros. Afectación de bienes. Afectación de vivienda. Afectación de infraestructura comunitaria.
Complejidad por actores.
Se relaciona con la cantidad de actores involucrados en la atención o solución de la solicitud
Numérico
1: un actor
2: dos o más actores.
Tipo de solicitud
Corresponde a la clasificación de la solicitud, a partir de su pretensión. Texto.
Solicitud de información. Reclamación. Queja. Derecho de petición.
Complejidad temática Se relaciona con la cantidad de tópicos involucrados el asunto de la solicitud
Numérico 1: un tema
2: 2 o más temas
Responsable Corresponde al actor que lidera el proceso de atención de la solicitud.
Texto EPM. MISPE. Interventoría.
Estado
Corresponde al momento procedimental en que se encuentra la solicitud. Texto
Remitida EPM. Remitida a la Asesoría. En trámite. Cerrada.
Seguimiento
Corresponde a un resumen de las gestiones adelantadas para el trámite de una queja, conducentes a su cierre.
Alfa-numérico. Hasta 5.000 caracteres.
Periodo de cierre. Corresponde al mes y año en que se cerró el registro de la solicitud.
Fecha mm/aaaa
Fecha de cierre Corresponde a la fecha en que se cerró dio respuesta a la solicitud.
Fecha dd/mm/aaaa
Oportunidad tiempos de respuesta
Corresponde a la calificación de la respuesta, de acuerdo al tiempo que transcurrió desde la recepción de la solicitud hasta su cierre.
Numérico
1: de uno a 15 dás.
2: de 16 a 45 días.
3: más de 45 días.
Tiempos de atención
Corresponde al conteo de días transcurridos entre la fecha en que se registró la solicitud y la fecha en que se le dio respuesta.
Numérico De 1 a 999.
78
Procedencia
Corresponde al nombre del municipio en donde se encuentra ubicada la Oficina de Atención a la Comunidad que registró la solicitud.
Texto OAC-Briceño. OAC-Puerto Valdivia. OAC-Ituango.
Tabla 2. Modelo de datos.
6.2.4 Especificación de casos de uso.
Teniendo en cuenta que el diseño de un sistema de información geográfica,
aplicable al mecanismo de atención a la comunidad del PHI, surge de la necesidad
de generar un modelo espacial de la realidad social de la obra, como una
alternativa paralela a la información que se puede obtener a partir de la consulta
de los registros de tención, el Comité de Dirección definió los siguientes Casos de
Usos, teniendo en cuenta los elementos de análisis que aportan sus resultados,
para visualizar la gestión de la Interventoría y para la conducente toma de
decisiones.
1. Selección de PQRs por número de consecutivo.
Ver anexo PHI_SO_011.
2. Selección de PQRs por estado.
Ver anexo PHI_SO_012.
3. Selección de PQRs por complejidad.
Ver anexo PHI_SO_013.
4. Selección de PQRs por responsable de la atención.
Ver anexo PHI_SO_014.
5. Selección de PQRs por oportunidad de la atención.
Ver anexo PHI_SO_015.
6.3. Diseño del sistema de información.
6.3.1. Diagrama de la arquitectura del sistema.
79
El sistema tendrá como elementos de entrada los registros generados por el equipo de gestión social del Proyecto, los cuales documentan cada caso y determinan en campo la localización de los temas referidos en las quejas, a partir de un proceso de participativo en el que se ven involucrado los titulares de las solicitudes, personal experto pertinente y representantes de las organizaciones comunitarias o de la Administración Municipal, estos últimos, si el caso lo amerita. El Auxiliar Social de la Interventoría, responsable del Componente del Plan de Manejo Ambiental “Participación Ciudadana”, remitirá copia de cada registro al Coordinador Social de la interventoría, quien tendrá el rol de Administrador dentro del sistema de información. Así mismo, archivara los originales de los registro en el archivo general de la Interventoría, tal y como reza el procedimiento de manejo documental del Sistema Integral de Gestión de Calidad. El administrador del sistema migrara la información que reposa en los registro a un formato de administración de base de datos cargado en el servidor del proyecto. El anterior, será uno de los elementos que constituya la Geodata-base del Sistema, el cual será completado, dentro del marco del módulo de datos, con Ortofoto del
corredor del proyecto vía Puerto Valdivia – Sitio de presa, el diseño del trazado del Proyecto, división político-administrativa veredal de los municipios Valdivia e Ituango. A partir de la anterior configuración, se podrán realizar consultas al sistema, de acuerdo a los requerimientos de información definidos por el Comité de Dirección, en cabeza de la gerencia Integral de la Interventoría y, de estas consultas, se generaran informes mensuales. Es importante anotar que el sistema tendrá la potencialidad de responder consultas de requerimientos no definidos en el presente trabajo, pero que en el desarrollo del Proyecto puedan ser requeridas. El relacionamiento de los usuarios del sistema, estará condicionado a los permisos otorgados por el Centro de Informática de la Interventoría, así:
a. El Administrador tendrá acceso a todos los procesos del sistema, con la facultad de cargar el sistema, realizar consultas y de modificarlo o borrar información, más no aplicativos o software.
b. Los usurarios nombrados “profesional social 1 y 2” podrán acceder al sistema con permisos limitados, de manera podrán realizar consultas tanto dentro de la Geodatabase como de los informes mensuales que contienen el histórico de las consultas realizadas al sistema, a partir de los requerimientos de información definidos en el presente trabajo.
c. Al margen del presente trabajo y de acuerdo a los parámetros definidos por el
Centro de Informática, el usuario nombrado “Gerente Integral” tendría acceso irrestricto a todos los procesos del sistema al igual que el Administrador. No
80
obstante, para efectos del proyecto que enmarcamos, tendrá acceso a la consulta de los informes mensuales.
Diagrama 1. Diagrama despliegue del sistema
6.3.2. Requerimientos de hardware.
REQUERIMIENTOS DE HARDWARE
Procesador Intel ® Core ™ i5-3470 CPU 3.20CHz Memoria RAM: 4,00 GB Windows 7 Professional. Capacidad disco duro: 165 Gb. Monitor HP, CPQ LA1956X, 19", LED, Cuadrado. Resolución: 1366 x 768.
81
Destop HP 6000 pro Microtwer. Core 2 duo T 7500 2.93 GHz -HDD 300 GB 5500 Rpm 1.5 7200 Rpm - Ram 4 GB - Video Intel R Q45 on Board 128 MB.
Tabla 3. Requerimientos de hardware.
6.3.2. Modelo de datos.
DISEÑO DEL MODULO DE DATOS
DATABASE: El modulo del sistema está organizado por 4 grupos de dataset, asi:
1. Como entidad geográfica principal, se contará con la ortofoto del Área de Influencia Directa del Proyecto.
2. Como entidad geográfica secundaria, se contara con el diseño y del corredor de la vía Puerto Valdivia – Sitio de Presa, con su correspondiente planimetría.
3. Como entidad geográfica terciaria, se contara con una capa de información que contiene la división político administrativa veredal del Municipio de Valdivia, Área de Influencia Directa del proyecto.
4. Formato de almacenamiento de datos vectoriales los cuales referencia la ubicación y los atributos de los casos registrados en el mecanismo de atención a la comunidad.
1
Ortofoto del corredor del proyecto vía Puerto Valdivia – Sitio de presa. Resolución: 0.50m/pixel. Escala 1:5.000
2
Diseño del trazado de la vía Puerto Valdivia – Sitio de Presa. Curvas de nivel. Programa origen: Autocad 10. Clase de entidad: Líneas.
3
División político - administrativa veredal del Municipio del Valdivia. Clase de entidad: Polígono.
4
Formato o programa de almacenamiento de los casos registrados dentro del mecanismo de atención a la comunidad del PHI, georeferenciado por el lugar relacionado en el asunto de la solicitud, quejas o reclamos. Clase de entidad: Puntos.
82
Arcgis versión 10. Software plataforma sobre el que correrá el sistema de información.
Tabla 4. Módulos de datos.
6.3.3. Informes.
PRODUCTOS
Informes mensuales: Conjunto de reportes mensuales, realizados a partir de la consulta del sistema, aplicando los diferentes casos de usos reales definidos por la Gerencia Integral de la Interventoría Ingetec – Sedic.
Table 5. Productos.
6.3.2. Requerimientos de seguridad del sistema.
Dentro de los requisitos para poner en operación el sistema de información, se ha de considerar los protocolos de SEGURIDAD INFORMATICA establecidos por el Centro de Informática de la interventoría, el cual establece los procedimientos que resguardan el acceso a los datos del servidor y los permisos de los usuarios que aceden al mismo, para operar dentro de este.
Identificación y autenticación.
La primera línea de seguridad está definida por el control de acceso al sistema operativo de cada uno de los computadores conectados al servidor, el cual restringe el acceso al mismo sólo al personal de la Interventoría Ingetec-Sedic autorizado, bajo la asignación de un nombre de usuario y clave de acceso. Se denomina Identificación al nombre que registra el usuario para presentarse dentro del sistema y Autenticación a la clave de verificación que este ingresa al sistema, para validar dicha identificación. Cabe anotar que cada 30 días el sistema le requiere al usuario cambio de clave, como una medida que aumenta el nivel de seguridad del proceso de Autenticación.
83
Imagen 1. Interfase de acceso al equipo.
Esta primera barrera, además de proteger al sistema operativo de la red y de aplicaciones o software no autorizados, garantiza que cada usuario acceda a la información contenida en cada computador y en el servidor, partiendo de los permisos definidos para operar dentro de este, manteniendo así la integridad y confidencialidad de la información. Los procesos adelantada por el Centro de Informática de la Interventoría, relacionados con la definición “permisos de los usuarios”, son: Solicitud de las cuentas de usuarios: Para habilitar una cuenta de acceso para un usuario del área Social de la Interventoría Ingetec-Sedic se requiere autorización de la Gerencia Integral y, de acuerdo con sus requerimientos específicos de acceso, se genera el perfil del usuario en el sistema de seguridad, en el sistema operativo o en la aplicación según corresponda. Para el caso que nos ocupa, el personal involucrado en el presente trabajo cuenta con un ID de Usuario, clave de validación y tiene un perfil de seguridad establecido.
Cierre de cuentas de usuarios: Cuando un funcionario de la Interventoría Ingetec-
Sedic sea desvinculado del Proyecto, se genera un reporta desde la Gerencia
Instrumental de la Interventoría, y, a partir de este, el Centro de Informática de la
interventoría anula los permisos de acceso.
Modificación de los perfiles de usuario: En los casos en donde se requiera modificar los parámetros de seguridad o permisos de un usuario en particular, bien sea por cambio en la asignación o funciones desempeñadas, mediando solicitud
84
de la Gerencia Integral, el Centro de Informática podrá realizar los cambios necesarios, para ajustar el perfil al nuevo requerimiento.
El Sistema de Información objeto del presente trabajo exigirá en este proceso, la modificación del perfil del Coordinador Social y de los profesionales sociales de la Interventoría Ingetec-Sedic, configurando las limitaciones actuales a los servicios, permitiendoles el uso de software especiales. En lo que respecta a la Gerencia Integral, no se requiere realizar ninguna modificación a su perfil, pues este cuenta con acceso total a las diferentes aplicaciones.
Dentro del ajuste del perfil del Coordinador Social y de los profesionales sociales de la Interventoría, se deberá definir la modalidad de uso de cada aplicativo o software y de manipulación de la información almacenada, así:
Lectura: El usuario puede únicamente leer o visualizar la información pero no puede alterarla. En este caso, el usuario podrá copiar o imprimir la información.
Escritura: Este tipo de acceso permite agregar datos, campos de datos, archivos y modificar o borrar información.
Ejecución: Este acceso otorga al usuario el privilegio de ejecutar programas.
Borrado: Permite al usuario eliminar recursos del sistema como programas.
Creación: permite al usuario crear nuevos archivos, registros o campos.
Búsqueda: permite listar los archivos de un directorio determinado.
Una vez establecidos el requerimiento desde la Gerencia Integral, el Centro de Informática valora los ajustes que se hacen necesarios para modificar los perfiles de los usuarios y permitirles el uso de los softwares requeridos. En lo que respecta al nivel de seguridad necesario sobre los datos, determina el riesgo que produciría una eventual exposición de los mismos a usuarios no autorizados.
En este orden de ideas, el Centro de Informática analiza la información más sensible y las aplicaciones más críticas y, a partir de esto, define cada modalidad de uso o acceso, acorde a una escala de riesgo (ALTO-MEDIO-BAJO). Una vez realizada esta clasificación, establece las medidas de seguridad para cada uno de los niveles de la escala.
85
Teniendo en cuenta lo anterior, la modalidad de uso software y acceso a la información de los usuarios involucrados en el presente trabajo quedara definida de la siguiente manera, de acuerdo a los niveles de riesgo, y define si autoriza o no el permiso requerido:
CARGO NIVEL DE RIESGO
MODALIDAD DE USO Y ACCESO
PERMISO
Gerencia Integral.
BAJO ALTO BAJO ALTO BAJO BAJO
Lectura. Escritura. Ejecución. Borrado. Creación. Búsqueda.
CONCEDIDO CONCEDIDO CONCEDIDO
NO CONCEDIDO CONCEDIDO CONCEDIDO
Coordinación Social.
BAJO ALTO BAJO ALTO
MEDIO BAJO
Lectura. Escritura. Ejecución. Borrado. Creación. Búsqueda.
CONCEDIDO CONCEDIDO CONCEDIDO
NO CONCEDIDO CONCEDIDO CONCEDIDO
Profesionales sociales.
BAJO ALTO BAJO ALTO ALTO BAJO
Lectura. Escritura. Ejecución. Borrado. Creación. Búsqueda.
CONCEDIDO CONCEDIDO – LIMITADO.
CONCEDIDO NO CONCEDIDO NO CONCEDIDO
CONCEDIDO Tabla 6. Concesión de permisos a usuarios del sistema.
6.2.5. Subproceso – Implantación y aceptación del sistema.
Continuando con la aplicación de la metodología Métrica V3, el jefe del proyecto
expone que la conveniencia de unificar los procesos de construcción e
implementación del Sistema de Información, en procura de optimizar los tiempos
de ejecución del proyecto. En este sentido, se omiten las tareas tendientes a la
construcción del prototipo y se pasará inmediatamente a la carga del sistema con
la totalidad de la información que se ha sistematizado, la cual corresponde al
100% de la documentación que se ha generado desde el mecanismo de atención
a la comunidad, desde el inicio del Contrato CT-I-2013-000001: Construcción de
la vía entre Puerto Valdivia y el sitio de la presa del Proyecto Hidroeléctrico
Ituango, hasta el 31 de diciembre de 2014.
86
A partir de lo anterior, se procede a la generar las consultas definidas por el
Comité de Dirección como de interés para el análisis del componente social del
Proyecto, así:
1. Selección de PQRs por número de consecutivo: Se realizó la consulta, mediante la aplicación Selección por Atributo, de la queja identifica con el número de consecutivo 3.
2. Selección de PQRs por estado: Se realizó la consulta de Estado de la
quejas, por la aplicación Selección por Atributos. El sistema presenta las
opciones predeterminadas (Cerradas o Seguimiento) y se le realizó el
requiriéndole que discriminara aquellas que se registraron como cerradas.
87
3. Selección de PQRs por complejidad: Para establecer una escala de
complejidad, se definió que se categorizarían las quejas de acuerdo a la
cantidad de actores y temas involucrados en cada una de estas. En este
sentido, se formularon las siguientes caracterizaciones:
a. 1 Actor – 1 Tema: Define las PQRs en donde se ve involucrado un solo
actor del proyecto en la atención de una queja que tiene 1 tema definido
claramente.
b. 1 Actor - > 1 Tema: Define las PQRs en donde se ve involucrado un solo
actor del proyecto en la atención de una queja en donde se implican
más de un tema.
c. > 1 Actor – 1 Tema: Define las PQRs en donde más de un actor se ve
involucrado en la atención de una queja que tiene un solo tema.
d. >1 Actor - > 1 Tema: Define las PQRs en donde más de un actor se ve
involucrado en la atención de una queja que involucra más de un tema.
88
En este orden de ideas, se le realiza el requerimiento al sistema para que
resalte las PQRs que cumplan con la condición 1 Actor – 1 Tema.
4. Selección de PQRs por responsable de la atención: Las quejas pueden tener como responsable de su atención al Contratista o EPM, dependiendo de la competencia de uno o del otro, respecto a la toma de decisiones para la solución del caso. En este caso, se le requirió al sistema que seleccionara aquellas PQRs que tuviesen como responsable de su atención a EPM.
89
5. Selección de PQRs por oportunidad de la atención: Para la caracterización
de las quejas por la oportunidad de su atención y solución de las quejas se
definieron 3 rangos, en donde el primero va de 1 a quince días, siendo este
el rango óptimo de atención; el segundo de 16 a 45 días, siendo este un
rango aceptable y tercer rango, correspondiente a más de 45 días, marca la
ruta crítica del mecanismo de atención. Así las cosas, le fue realizada la
consulta al sistema, requiriéndosele que seleccionara las quejas que tienen
más de 45 días en proceso de atención.
90
6. Selección de PQRs por nombre del ciudadano: Partiendo de que cada
queja tiene como titular de la atención a un ciudadano, plenamente
identificado, se le requirió al sistema seleccionar las quejas que tiene como
nombre ciudadano “Juan de Dios”, identificando así aquellas que fueron
interpuestas por este.
91
7. Seleccionar PQRs por tipo de atención: Se realiza la consulta al sistema de
las PQRs que fueron registradas con el tipo de atención “Afectación de
Bienes”.
92
8. Selección de PQRs por tipo de solicitud: Se realiza la consulta al sistema de
las PQRs que fueron registradas con el tipo de slicitud “Derechos de
Petición”.
93
Finalizada la exposición, el Comité de Dirección delibero respecto a los productos
entregados y partiendo de los criterios de pertinencia, aporte de elementos nuevos
de análisis y visualización de la gestión aprobó el sistema de información en sus
etapas de construcción e implementación.
6.3. Proceso – Mantenimiento del sistema de información.
El presente trabajo se desarrolló hasta la formulación e implementación del
Sistema de Información Geográfica de Participación Publica del mecanismo de
atención a la comunidad del Proyecto Hidroeléctrico Ituango y, en esa medida y
por su calidad inédita, deberá ser sometido a diferentes evaluaciones y puestas en
94
uso por parte del equipo de sostenibilidad del Proyecto, antes de generarse un
procedimiento de mantenimiento.
95
7. CRONOGRAMA
ACTIVIDAD RESPONSABLE MES 1 MES 2 MES 3 MES 4
S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
PLANIFICACIÓN DEL SISTEMA DE INFORMACIÓN
Estudio de la información relevante. UE - JP
Identificación de requisitos. UE - JP
Estudio de los sistemas de información actuales. UE - JP
Diseño del Modelo de Sistemas de Información. UE – AT - JP
Definición de la Arquitectura Tecnológica. AT - JP
Revisión y Aprobación del PSI. DC – DC - UE
ESTUDIO DE VIABILIDAD DEL SISTEMA
Establecimiento del alcance del sistema. CD – JP
Estudio de la situación actual. CD – UE – AT - JP
Definición de requisitos del sistema. UE - JP
Estudio de alternativas de solución. UE – AT - JP
Valoración de las alternativas. AT - JP
Selección de la solución. DC – CD - JP
ANALISIS DEL SISTEMA DE INFORMACIÓN
Definición del Sistema. CD – AT - JP
Establecimiento de Requisitos. UE – AT
Identificación de Subsistemas de Análisis. UE – AT
Análisis de los Casos de Uso. AT - JP
Análisis de Clases. AT - JP
Elaboración del Modelo de Datos. UE – AT - JP
Elaboración del Modelo de Procesos. AT - JP
Definición de Interfaces de Usuario. UE – AT - JP
Análisis de Consistencia y Especificación de Requisitos.
UE – AT - JP
Especificación del Plan de Pruebas. UE – AT - JP
Aprobación del Análisis del Sistema de Información.
DC – CD - JP
DISEÑO DEL SISTEMA DE INFORMACIÓN
Definición de la Arquitectura del Sistema. AT – JP
Diseño de la Arquitectura de Soporte. AT – JP
Diseño de Casos de Uso Reales. JP – AT
Diseño de Clases. CD – UE – AT – JP
96
Diseño de la Arquitectura de Módulos del Sistema. CD – UE – AT - JP
Diseño Físico de Datos. CD – UE – AT – JP
Verificación y Aceptación de la Arquitectura del Sistema.
CD – UE – AT - JP
Generación de Especificaciones de Construcción. CD – UE – AT - JP
Diseño de la Migración y Carga Inicial de Datos. CD – UE – AT - JP
Especificación Técnica del Plan de Pruebas. CD – UE – AT - JP
Establecimiento de los requisitos de Implantación. CD – UE – AT - JP
Aprobación del Diseño del Sistema de Información.
DC – CD - JP
CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN
Preparación del Entorno de Generación y Construcción.
UE – AT – JP
Generación del Código de los componentes y Procedimientos.
AT - JP
Ejecución de las Pruebas Unitarias. AT - JP
Ejecución de las Pruebas de Integración. AT - JP
Ejecución de las Pruebas del Sistema. AT - JP
Elaboración de los Manuales de Usuario. UE – JP
Definición de la Formación de Usuarios Finales. AT – JP
Construcción de los Componentes y Procedimientos de Migración y Carga Inicial de Datos.
CD - UE – JP AT
Aprobación del Sistema de Información. CD – JP
IMPLANTACIÓN DEL SISTEMA DE INFORMACIÓN
Establecimiento del Plan de Implantación. CD – UE – JP
Formación Necesaria Para la Implantación. CD – UE – JP
Incorporación del Sistema al Entorno de Operación.
JP – UE
Carga de Datos al Entorno de Operación. JP – UE
Pruebas de Implantación del Sistema. JP – UE
Pruebas de Aceptación del Sistema. CD – JP
Preparación del Mantenimiento del Sistema. CD – JP
Establecimiento del Acuerdo de Nivel de Servicio. CD – UE – JP
97
RESPONSABLE CONVENSIÓN
DIRECTOR COMITÉ DC
JEFE DE PROYECTO JP
COMITÉ DE DIRECCIÓN. CD
USURIO EXPERTO UE
ASESORES TRABAJO DE GRADO
AT
Presentación y Aprobación del Sistema. DC – CD – UE - JP
Paso a Producción. DC – CD – UE - JP
98
8. CONCLUSIONES.
Resultado del presente trabajo se ha diseñado, a manera de prototipo, un
Sistema de Información Geográfica a partir de los registros generados por
el mecanismo de atención. En su calidad de prototipo, deberá continuarse
con usa fase exploratoria y de evaluación rigurosa, que permita extraer toda
la potencialidad de esta herramienta.
El Sistema de Información Geográfica formulado aporta elementos nuevos
a considerarse dentro del análisis del contexto social del Proyecto
Hidroeléctrico Ituango, de manera que es factible su implementación para la
totalidad de los contratos objeto de supervisión de la Interventoría Ingetec-
Sedic; la ruta propuesta es entonces la modelación de los escenarios social
posibles, a partir del uso de las herramientas informáticas.
Como guía metodológica, el uso de METRICA en su versión 3, aportó rigor
a los procesos adelantados en cada uno de las etapas del Proyecto, sin
embargo, es importante anotar que su mayor contribución estuvo orientada
hacia facilitar el trabajo interdisciplinario.
Si bien el Comité de Dirección señalo 5 casos de uso como de su interés,
complementado con 4 consulta adicionales, el potencial del sistema de
información es mayor, de manera que se pueden realizar tantas consultas
como combinaciones de variables posibles se definan, a partir de los
atributos especificados.
La gestión del territorio requiere el uso de herramientas informáticas que
permitan la articulación de las variables sociales a los escenarios de
análisis de las realidades intervenidas; en este sentido, el resultado del
presente trabajo puede entenderse como una insinuación de una ruta para
lograr dicho cometido.
99
9. LISTADO DE ANEXOS.
Anexo 1. Acta interna 3_12_2014.
Anexo 2. Acta interna 10_12_2014.
Anexo 3. Acta interna 5_11_2014.
Anexo 4. Acta interna 10_04_2015.
Anexo 5. Caso de uso - Selección de PQRs por número de consecutivo.
Anexo 6. Caso de uso - Selección de PQRs por estado.
Anexo 7. Caso de uso - Selección de PQRs por complejidad.
Anexo 8. Caso de uso - Selección de PQRs por responsable de la atención.
Anexo 9. Caso de uso - Selección de PQRs por oportunidad de la atención.
100
10. REFERENCIAS BIBLIOGRAFICAS
Guevara, J. A. (1993). V Coloquio de Geografía Cuantitativa. IFC-Departamento
de Geografía y Ordenación del Territorio, Universidad de Zaragoza, 21 – 30.
Román, R. (2013). La Historia Oral y la Interdisciplinariedad. Retos y
perspectivas. Revista Estudios sobre las Culturas Contemporáneas,
Volumen XXIII, número 43. Páginas 173-177.
González, L. E. (2011). Gestión del territorio: un método para la intervención
territorial. Santiago de Chile, Chile. Recuperado en
http://www.captura.uchile.cl/handle/2250/50768.
Ministerio de Administraciones Públicas de España. Métrica Versión 3. Recuperado en http://www.csi.map.es/csi/metrica3/.
NACIONES UNIDAS, Departamento de asuntos económicos y sociales – División
de desarrollo sostenible, Programa 21, 2013. Recuperado de
http://www.un.org/spanish/esa/sustdev/agenda21/agenda21sptoc.htm
[consulta: sábado, 22 de marzo de 2013].
Brown, G. An empirical evaluation of the spatial accuracy of public participation
GIS (PPGIS) data, Applied Geography, Volume 34, May 2012, Pages 289-
294.
Ball, J. T. a methodology for mapping ‘regions for sustainability’ using PPGIS,
Progress in Planning, Volume 58, Issue 2, August 2002, Pages 81-140.
Brown, G. y Kytta, M. Key issues and research priorities for public participation GIS
(PPGIS): A synthesis based on empirical research, Applied Geography,
Volume 46, January 2014, Pages 122-136.
Zhong, T., Kae Young, R.,Lowry, M y Rutherford, S. A model for public
involvement in transportation improvement programming using participatory
Geographic Information Systems, Computers, Environment and Urban
Systems, Volume 32, Issue 2, March 2008, Pages 123-133.
Green, D. The role of Public Participatory Geographical Information Systems
(PPGIS) in coastal decision-making processes: An example from Scotland,
101
UK, Ocean & Coastal Management, Volume 53, Issue 12, December 2010,
Pages 816-821.
Brown, G. y Raymond, C. Methods for identifying land use conflict potential using
participatory mapping, Landscape and Urban Planning, Volume 122,
February 2014, Pages 196-208.
Jankowski, P. Towards participatory geographic information systems for
community-based environmental decision making, Journal of Environmental
Management, Volume 90, Issue 6, May 2009, Pages 1966-1971.
Barrera, S. Reflexiones sobre Sistemas de Información Geográfica Participativos
(SIGP) y cartografía social, Revista Colombiana de Geografía, Volumen 18,
2009, Paginas 9 – 23.