Tecnologías Información Gestión Proyectos

Dr. Antonio González Torres (Ed.
Tecnologías de la Información
y Gestión de Proyectos
Facultad de Tecnologías de la Información

ULACIT
2016
Dr. Antonio González Torres (Ed.)
Facultad de Tecnologías de la Información

ULACIT
2016
ISBN: 978-9977-37-006-4
Primera edición, 2016
Universidad Latinoamericana de Ciencia y Tecnología
ULACIT
Lugar de edición: San José, Costa Rica

Editorial: Universidad Latinoamericana de Ciencia y Tecnología
Teléfono: 2523-4000
Impreso en Costa Rica
Reservados todos los derechos. Prohibida la reproducción no autorizada por

cualquier medio, mecánico o electrónico del contenido total o parcial de esta
publicación.
A quienes trabajan mientras sueñan.
Prefacio
Nos complace presentar este primer volumen de publicaciones de las

investigaciones realizadas por profesores y estudiantes de ULACIT de la carrera
de Ingeniería Informática, en las que se abordan aspectos interesantes de la
tecnología de información y la gestión informática. Representan el resultado de
un esfuerzo sostenido de la Facultad de Tecnologías de Información por construir
una estructura permanente de investigación que haga escuela para la formación
de investigadores dentro de nuestra Facultad docente y comunidad de estudiantes
de bachillerato, licenciatura y maestría en Ingeniería Informática.
Este libro es la respuesta a un desafío formidable que enfrentan las
universidades privadas para realizar investigación científica en ingeniería,
ciencias naturales o ciencias sociales, por la escasez de recursos humanos
y materiales, dado su alto costo en esfuerzo, tiempo y calidad. Para los
especialistas, es reconocida la gran dificultad que existe en estas instituciones
para articular investigadores experimentados y docentes en un programa de
investigación que arranca desde cero, con el propósito de ser permanente y
riguroso en su contenido.
En los procesos de investigación de las ciencias naturales y sociales, se extrae
información y conocimiento a partir de la observación directa o indirecta del
objeto en estudio, para confirmar o refutar hipótesis de trabajo planteadas,
siguiendo el llamado método científico. En ingeniería, por el contrario, no
se persigue como fin la descripción o explicación del objeto como tal, sino
encontrar la solución a un problema u optimizar una solución. Esto puede
implicar iterar planteamientos o realizar experimentos y simulaciones, utilizando
objetos de estudio físicos o abstractos (ej. Máquinas de turing), para inferir
un planteamiento que satisfaga las restricciones y requisitos que imponga el
contexto. Es así como se utiliza el llamado método de investigación de ingeniería,
diferente del método científico.
La investigación científica en ingeniería en general y en tecnología de
información en particular, busca encontrar soluciones eficaces y eficientes a
problemas simples o complejos, aplicando sistemáticamente el conocimiento
científico y las herramientas tecnológicas, para crear el diseño de la solución;
desarrollar y construir dispositivos, estructuras y procesos, bajo restricciones
y requisitos impuestos por la tecnología disponible y por consideraciones
económicas, legales, ambientales y humanas.
Las publicaciones que se presentan en este primer volumen representan esta
clase de investigación científica que aborda la solución de problemas de ingeniería
informática, buscando hallar el camino para establecer un pequeño universo de
líneas de investigación que puedan consolidarse y profundizarse en el tiempo y
que nos permitan concentrar recursos y esfuerzos para ganar en profundidad y
rigor científico.
Los factores claves para crear en tan poco tiempo la estructura de
investigación de académicos, estudiantes y recursos tecnológicos y financieros,
han sido el compromiso de los profesores investigadores que conforman el
equipo de investigación; la seriedad con que han abordado sus trabajos de
investigación los estudiantes, autores de las publicaciones presentadas, y el
compromiso de las autoridades de la Universidad para apoyar la construcción
de la estructura de investigación en ingeniería de ULACIT, cuyo objetivo
es formar a los profesores y estudiantes de la carrera Ingeniería Informática
con las competencias para efectuar investigación científica en este campo, que
propicie la producción de publicaciones que incrementen su desarrollo académico
y proyecten a la universidad en respuesta a las necesidades de talento de la
economía costarricense.
En este momento, el sector industrial tecnológico del país (diseño,
manufactura y servicios tecnológicos) emplea a más de 25.000 ingenieros, de
los cuales más de 3.000 laboran a tiempo completo en equipos de investigación,
como parte de los procesos que buscan mejorar las cadenas de valor y optimizar
los procesos que la componen, así como en innovar productos y servicios. Hasta
ahora las empresas han encontrado el talento que requieren para hacer que sus
procesos se expandan en el país, pero están enfrentando escasez de ingenieros
con formación en investigación en ingeniería. De igual forma, las empresas están
haciendo frente a la falta de líderes de equipos de investigación y administradores
de investigación, por lo que han manifestado que necesitan apoyo académico e
institucional para el desarrollo de estas capacidades y habilidades en el personal
que requieren contratar.
Hemos observado que la demanda de ingenieros competentes para participar
en equipos de investigación de ingeniería está en aumento desde hace cinco años,
aproximadamente. Es un requerimiento emergente, que no está siendo atendido
por la academia en la medida necesaria para apoyar el desarrollo de un sector
industrial tecnológico, más allá de la manufactura, que ha encontrado en el
talento costarricense el capital humano para establecerse y expandirse en el país.
M.Sc. Edwin Aguilar Sánchez

Decano
Facultad de Ingeniería Informática
Setiembre del 2016

Comité Evaluador
Este trabajo es producto de varios trabajos presentados en el Workshop en

Ingeniería Informática y Tecnologías de la Información que es organizado por la
Facultad de Ingeniería Informática de la Universidad Latinoamerica de Ciencia
y Tecnología (ULACIT).
En este volumen se incluyen los trabajos presentados en el marco de la
tecnología de la información y gestión de proyectos informáticos.
El comité evaluador de los trabajos presentados estuvo constituido por los
siguientes profesores:
Edwin Aguilar Sánchez

Antonio González Torres
Randall Barnett Villalobos
Julio Córdoba Retana
Índice general
Metodología para la gestión de terceros en procesos de desarrollo de

software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Yeison Núñez Sánchez y Antonio González Torres
Gestión de la relación con terceros y metodologías ágiles . . . . . . . . . . . . . . . 22
Fabián Chaves Serrano, David Mora Solano y Antonio González
Torres∗
Definición y modelado del proceso de gestión de la demanda para

tecnología de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
David Rodolfo Camacho Quiros, Reagan Ching Fung, Julio Córdoba
Retana y Antonio González Torres
Recomendaciones para la gestión de incidencias de tecnologías de la
información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Verny Mora Jiménez, Paulo Viales Wahrmann, Julio Córdoba
Retana y Antonio González Torres
Diseño de una arquitectura para la comunicación entre protocolos en
internet de las cosas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Marco Córdoba Padilla, Frank Trejos Moya, Fernando Chinchilla
Jiménez y Antonio González Torres
Etiquetas de Geolocalización en imágenes ráster para la identificación
de especímenes biológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Jonathan Quintana Berríos, Esteban Robleto Rodríguez, Antonio
González Torres
Caracterización de malware usando lenguajes de intercambio de
inteligencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Randall Barnett Villalobos, Susan Rodríguez Segura, Julio
Chinchilla Moya y Wilson Acuña Araya
Metodología para la gestión de terceros en
procesos de desarrollo de software
Yeison Núñez Sánchez y Antonio González Torres∗
Escuela de Ingeniería,
Universidad Latinoamericana de Ciencia y Tecnología,
ULACIT, Urbanización Tournón, 10235-1000
San José, Costa Rica
ynunezs664@ulacit.ed.cr
agonzalez@ulacit.ac.cr∗
http://www.ulacit.ac.cr
Resumen La tercerización permite que las empresas reduzcan costos,

optimicen el uso de sus recursos, brinden mayor valor agregado en la
entrega de servicios y se concentren en alcanzar los objetivos estratégicos
del negocio. Sin embargo, el desconocimiento de cuáles elementos es
necesario considerar en la planificación de los procesos de tercerización
ha contribuido al fracaso de un gran número de proyectos de desarrollo de
software. Entre los elementos que por lo general se omiten se encuentran
aspectos de aseguramiento de la calidad tanto del producto como del
proceso, la falta de participación activa de los clientes y usuarios
finales durante todas las etapas del proceso y la falta de seguimiento
y comunicación con el proveedor. Como consecuencia, el objetivo de este
trabajo de investigación es proponer una metodología para la gestión
de la relación entre clientes y proveedores durante los procesos de
tercerización del desarrollo de sistemas. Por lo que se realiza una síntesis
de los procesos y mejores prácticas que deben contemplarse en la gestión
de terceros con el fin de facilitar los procesos de tercerización, mejorar
los resultados que se obtienen y contribuir con la generación de valor
agregado tanto para el cliente como para el proveedor. Como resultado,
este trabajo presenta una metodología que contempla 7 fases, las cuales
a su vez comprenden entradas, tareas y salidas que son utilizadas por las
fases subsiguientes.
Palabras clave: Gestión de terceros, outsourcing, tercerización,

adquisición de software
1. Introducción
La evolución en los negocios ha propiciado mayor competencia en todos los
ámbitos de los mercados de bienes y servicios, por lo que las organizaciones
buscan utilizar mejor sus recursos económicos y humanos para brindar valor
agregado a sus clientes, a la vez que se concentran en alcanzar los objetivos
2 Núñez y González
estratégicos del negocio. Con ese fin utilizan como alternativa la tercerización1
de servicios, la cual consiste en la contratación de un proveedor para que ejecute
algunas funciones específicas que, por lo general, no son parte de las actividades
centrales de la empresa.
Aunque se considera que los beneficios de la tercerización son numerosos,
se han logrado identificar inconvenientes que se presentan durante su
implementación, debido a una deficiente gestión de las relaciones entre las partes.
De acuerdo con algunos estudios, alrededor de un 30 % de las empresas cancelan
sus contratos de tercerización de forma prematura; entre el 20 y 25 % fracasan
durante los primeros dos años del contrato y el 50 % fracasa en los primeros
cinco años de vigencia (Grossi y Calvo-Manzano, 2012). Cabe resaltar que los
casos de mayor incertidumbre e inconvenientes se presentan en los procesos de
tercerización de software, debido a la complejidad y naturaleza de los tipos de
proyectos.
Los problemas que se asocian con la tercerización del desarrollo de software se
presentan por el desconocimiento de los factores que se deben contemplar durante
la etapa de planificación para adquirir productos de software. Esto tiene como
consecuencia que el producto final no responda a las necesidades o no se ajuste
a los requerimientos definidos por el cliente (Erazo-Paruma, Guerrero-Mera y
Correa-Pino, 2014).
Este tipo de inconvenientes suelen presentarse cuando la empresa contratante
no realiza de forma adecuada las siguientes tareas:
1. Definición de los requerimientos.

2. Selección y contratación del proveedor (Erazo-Paruma et al., 2014).
3. Identificación del alcance del proyecto.
4. Definición de la metodología de desarrollo.
5. Participación activa de los clientes o usuarios finales en el proceso de
desarrollo.
6. Adecuada administración y comunicación con el proveedor.
A esto se debe agregar la ausencia de sistemas de apoyo al proceso de

desarrollo y gestión, así como de herramientas y métricas de control para el
aseguramiento de la calidad (Selleo, 2016).
Como consecuencia, se han preparado diversos documentos e investigaciones
que detallan las mejores prácticas para mitigar estos problemas y apoyar el
proceso de tercerización. Sin embargo, la información se encuentra dispersa en
diversas fuentes, y no existe una presentación visual e integral del proceso para
facilitar la planificación de la calidad y gestión de la comunicación para guiar de
forma apropiada a los gerentes y directores de proyectos.
El proceso de tercerización requiere el cumplimiento de ciertas pautas y pasos
para disminuir los riesgos durante el desarrollo de los productos, a la vez que
se aumenta la posibilidad de éxito y maximizan los beneficios económicos. Por
tanto, los objetivos de este trabajo de investigación consisten en identificar el
flujo del proceso de administración de la relación con terceros y proponer una
1
La tercerización es conocida en inglés como outsourcing.
Metodología para la gestión de terceros en procesos de desarrollo de software 3
metodología para sintetizar algunas de las mejores prácticas e investigaciones

realizadas sobre el tema.
Con ese fin, este trabajo de investigación lleva a cabo una revisión de
bibliografía (sección 2) para desarrollar una metodología con las mejores
prácticas para la gestión de proyectos de software en procesos de tercerización
(sección 3) y, finalmente, presenta las conclusiones y trabajos futuros (sección
4).
2. Estado del arte

Los procesos de tercerización del desarrollo de software, por lo general, son
complejos, y aunque existe bibiliografía para apoyar a los gestores de estos
procesos, aún persiste una serie de desafíos que requieren atención.
Las actividades de alto nivel de un proceso de tercerización contempla la
identificación del tipo de proyecto que se quiere llevar a cabo, pero de forma
concreta y detallada también toma en cuenta qué es lo que se va a desarrollar,
cómo se va a llevar a cabo y quiénes estarán involucrados durante su desarrollo.
Con base en esto, es relevante considerar los siguientes puntos (Selleo, 2016)
cuando se desea iniciar un proceso de tercerización:
¿Cuáles tareas o proyectos se van a tercerizar? Debe existir claridad

sobre las tareas o proyectos que se desea tercerizar y la naturaleza de estos.
¿Qué se requiere hacer? La respuesta a esta pregunta tiene por fin definir de
forma precisa qué es lo que se requiere hacer y cuáles son sus requerimientos.
¿Cómo cómo se llevarán a cabo las tareas o el proyecto? Por su parte
la respuesta a esta pregunta involucra no solo la metodología por utilizar
sino también la estructura del equipo de trabajo que va a participar en su
desarrollo.
¿Quién estarán involucrados? Es importante conocer quiénes serán los
usuarios del sistema, los gerentes o ejecutivos que apoyarán el desarrollo y
quiénes estarán participando en el proyecto, tanto en la etapa de definición
de requerimientos como de seguimiento y aceptación.
Lo anterior se puede realizar después de efectuar bechmarking interno y

externo (Franceschini, Galetto, Pignatelli y Varetto, 2003). En este contexto,
estos dos tipos de benchmarking se entiende de la siguiente forma:
Benchmarking interno: consiste en analizar las competencias centrales de la

empresa y la identificación de los procesos que serán tercerizados, conforme
con los resultados de un análisis que evidencia la reducción de costos o la falta
de habilidades de los empleados. En esta etapa se define el tipo de relación
que se establecerá con la empresa proveedora, de acuerdo con los intereses
del cliente. La relación que se establece puede ser tradicional, temporal,
estratégica o de red organizacional.
Benchmarking externo: se utiliza para analizar, identificar y seleccionar al
proveedor, así como para definir los niveles del acuerdo de servicios.
En línea con lo anterior, un modelo para la administración del proceso de

tercerización puede contemplar (Erazo-Paruma et al., 2014) los siguientes pasos:
Planificación: en esta etapa se determina la necesidad de adquisición, los
requisitos del software a adquirir, la identificación de los proveedores
potenciales y criterios de aceptación en conjunto con el plan de adquisición,
por lo que se procede a efectuar la planificación definiendo sus prioridades y
el orden de su desarrollo.
Anuncio: se encarga de dar a conocer la necesidad y requerimientos del
producto a los posibles proveedores que fueron identificados.
Selección del proveedor: en esta etapa se lleva a cabo la selección del
proveedor que mejor se ajusta al desarrollo del sistema y el cumplimiento de
los requerimientos.
Contratar: es la etapa durante la cual se establecen de manera formal los
acuerdos negociados con el proveedor, y se formaliza la relación entre el
cliente y el proveedor que incluye la celebración del contrato.
Monitoreo: tiene como fin dar seguimiento al progreso de los proveedores en el
cumplimiento de las metas, y efectúa una revisión del avance del proveedor
de acuerdo con los costos y plazos acordados.
Esto se lleva a cabo de acuerdo con los niveles del acuerdo de servicios.
Uno de los fines de esta etapa es medir el desempeño del proveedor
mediante curvas de eficiencia. Éstas curvas consisten en establecer por
cada acuerdo de servicio dos líneas. La primera línea se relaciona con los
objetivos que se busca lograr y la segunda línea refleja los resultados del
rendimiento del proveedor y sirve para determinar las brechas en el proceso
de implementación mediante dos ejes de evaluación (tiempo y nivel de
acuerdo de servicio), los cuales son evaluados en función de la cantidad
de fases que se desean evaluar. para tomar acciones correctivas en caso de
incumplimiento (Franceschini et al., 2003).
Aceptación: durante esta etapa se lleva a cabo la evaluación del producto,
aplicando las pruebas y criterios de aceptación establecidos.
Cierre: es la etapa encargada de verificar que todos los entregables del producto
han sido aceptados de forma satisfactoria.
Seguimiento: en esta ultima etapa se realiza el monitoreo del desempeño del
sistema y de los tiempos de respuesta del proveedor.
En general, las tareas y pasos que contempla el proceso de tercerización
se pueden agrupar en 5 grandes fases: preparación, selección del proveedor,
transición, administración de las relaciones y reconsideración (Perunović y
Pedersen, 2007). En estas fases se describen actividades que responden a una
o varias preguntas claves para el desarrollo de cada una de las fases.
La planificación para la tercerización debe ser integral y debe definir el
tipo de relación que se desea tener con la empresa proveedora. Esta relación
es influenciada por la importancia de la actividad y los riesgos de realizar la
tercerización, lo cual se puede representar mediante una matriz según el tipo
de relación: colaboración competitiva, colaboración cercana, muchos suplidores
o suministros seguros (McIvor, 2005).
Debido a la aceptación de la tercerización como un método eficaz para apoyar

a los negocios, varias organizaciones internacionales han desarrollado pautas y
recomendaciones, entre las cuales se encuentran estrategias para identificar los
procesos que se pueden tercerizar, establecer aspectos de coordinación entre los
procesos del cliente y el proveedor, determinar roles y responsabilidades, el tipo
de información que se debe comunicar y factores para la gobernanza del proceso
(CabinetOffice, 2011). En la misma dirección, también se busca asegurar que
los contratos estén alineados con las necesidades del negocio, administrar el
rendimiento, negociar y formalizar los contratos y mantener políticas para la
gestión del ciclo de vida del proyecto (CabinetOffice, 2011).
Otro referente utilizado en la planificación de proyectos es el Project
Management Institute (PMI), el cual establece procesos para planificar, efectuar
y dar seguimiento a un proyecto (Project Management Institute, 2013).
Entonces, tomando como base las mejores prácticas de PMI y los problemas
que se presentan durante la gestión de terceros en los procesos de desarrollo de
software, es importante resaltar los siguientes puntos:
Gestión del alcance: se deben incluir las características y funciones que

requieren los usuarios mediante la adecuada definición de requerimientos.
Gestión de las comunicaciones: este tipo de gestión es necesaria para
propiciar una comunicación eficaz entre quienes participan en el proyecto,
tanto del lado cliente como proveedor, por los diferentes niveles de
experiencia, perspectivas e intereses que pueden influir y tener impacto en
los resultados de los proyectos.
Gestión de los interesados: incluye procesos para identificar a las personas,
grupos u organizaciones que pueden afectar o ser afectados por el proyecto.
Es preciso analizar aspectos relacionados como las expectativas de los
interesados y lograr su participación en las decisiones y ejecución de
proyectos.
El resultado final de la tercerización del desarrollo de software es la entrega

de un sistema que cumpla aspectos de calidad y satisfaga las expectativas y
necesidades planteadas por los usuarios. Por esa razón es importante considerar
desde el inicio del proceso la ausencia de defectos, la aptitud para el uso, la
seguridad, la confiabilidad, el cumplimiento de especificaciones y los elementos
necesarios, de acuerdo con el proyecto, en torno a los elementos de calidad de
software (Mendoza, Pérez y Grimán, 2005).
La incorporación de la calidad en la elaboración de productos o prestación
de servicios por lo general se incorpora en las etapas finales del proceso de
desarrollo del software, por ejemplo: en las pruebas finales de los entregables.
Sin embargo, la calidad es un proceso que se construye desde que inicia un
proyecto de software, y no es un elemento que pueda ser agregado de forma
posterior, durante el proceso o mediante una evaluación final. La calidad del
proceso de desarrollo garantiza la calidad del producto y como consecuencia no
se pueden desvincular (Mendoza et al., 2005). Por consiguiente, el aseguramiento
de la calidad se debe realizar durante todo el proceso, con la finalidad de que
se puedan corregir de inmediato las disconformidades (CENDITEL, Fundación,

2013).
Con base en los conceptos discutidos hasta este punto, y la recopilación de
normas e investigaciones con respecto a las evaluaciones de calidad Mendoza
et al. (Mendoza et al., 2005) proponen un marco de evaluación dividido en los
siguientes niveles:
Nivel 0: este nivel contempla el valor más alto en la jerarquía y se corresponde

con los aspectos externos e internos tanto del proceso como del producto.
Nivel 1: en este nivel se definen 6 categorías de evaluación para el producto y
5 categorías para el proceso de desarrollo.
Nivel 2: este nivel relaciona las características de cada unas de las categorías
que definen las áreas claves para satisfacer, lograr, asegurar y controlar la
calidad tanto del producto como del proceso.
Nivel 3: en este otro nivel se asocian las métricas utilizadas para medir
cuantitativamente cada una de las características que fueron definidas con
el fin de determinar si la calidad planificada es satisfactoria o no.
La estimación adecuada de la calidad realiza cálculos tanto para estimar la

calidad del software como producto como del proceso, y contribuye a identificar
las características que no han sido satisfechas por el sistema desarrollado
(Mendoza, Pérez, Grimán y Rojas, 2002). Este proceso se divide en tres fases, en
donde la primera fase se corresponde con la evaluación del proceso de desarrollo,
la segunda fase con la valoración del sistema y la tercera fase con la integración
de los resultados que combinan ambas etapas.
De acuerdo con el análisis realizado, varios trabajos de investigación
sugieren diferentes fases para el proceso de tercerización. Sin embargo, los
trabajos estudiados no contemplan aspectos relacionados con la gestión de las
comunicaciones, la gestión de los interesados y el aseguramiento de calidad, los
cuales son aspectos que deben estar presentes en la definición de una metodología
para gestionar la relación con terceros durante los procesos de tercerización.
Como consecuencia, la metodología que se propone en la siguiente sección
sintetiza las fases fundamentales que se deben tomar en cuenta en los procesos
de tercerización y tiene presentes aspectos para mejorar la comunicación, la
participación activa de las partes y la calidad del producto final.
3. Fases para la gestión de terceros en proyectos

de desarrollo de software
En esta sección se presenta la propuesta de una metodología para apoyar la
gestión de los procesos de tercerización, usando como referencia la revisión y el
análisis efectuado en la sección 2. La metodología propuesta se divide en 7 fases:
1. Inicio.
2. Planificación.
3. Selección y contratación del proveedor.

4. Ejecución.
5. Administración de la relación con el proveedor.
6. Aceptación y cierre.
7. Reconsideración.
La relación entre las fases mencionadas con los procesos aseguramiento de

la calidad, administración de la relación y gestión de la comunicación se puede
observar en la figura 1, además de los vínculos que existen entre estos.
La gestión de la comunicación se debe desarrollar durante casi todas las fases
de la tercerización (con excepción de las fases Inicio y Planificación), e incluye
la administración de la relación y el aseguramiento de la calidad. El objetivo de
este proceso es garantizar una mejor comunicación entre el cliente y el proveedor
por medio de herramientas, métodos y técnicas que faciliten el intercambio de
información desde las etapas iniciales del desarrollo del sistema.
Por su parte, la administración de la relación busca mejorar la relación
entre el proveedor, usuarios e interesados para garantizar la comprensión
de necesidades, efectuar el seguimiento del avance del proyecto mediante
evaluaciones durante el desarrollo y durante la entrega del producto. En cuanto
al aseguramiento de la calidad, esta debe estar presente desde el inicio de la
ejecución o desarrollo del sistema, y juega un papel preponderante en la fase de
aceptación y cierre.
Figura 1: Relación entre las fases y procesos para la gestión de terceros durante el
desarrollo de software.
En las siguientes secciones se explican con detalle las fases contempladas en

la figura 1.
3.1. Inicio
Esta fase verifica la necesidad de desarrollar un sistema por medio de la
tercerización, y si dicha verificación es positiva, justificar su desarrollo, obtener
el apoyo interno, y formalizar el inicio del proceso de contratación con el apoyo
de los ejecutivos y directores. Algunas de las tareas que es necesario contemplar
en esta fase son las siguientes:
Análisis, ¿desarrollo interno o externo?: se debe realizar la evaluación

objetiva del problema que se requiere resolver, para verificar si es posible
efectuar el desarrollo de forma interna o si se requiere apoyo externo. Existen
factores que pueden influir (Project Management Institute, 2013) en esta
decisión:
Capacidades esenciales de la organización: este factor hace énfasis en
la verificación de las capacidades centrales del negocio y su principal
actividad económica, para delegar a terceros las funciones que no generan
valor agregado o sobre las cuales se cuenta con poco conocimiento y
experiencia.
Valor proporcionado por los proveedores: consiste en analizar la
capacidad del proveedor en el cumplimiento de las expectativas del
proyecto, las posibilidades de que ayude a generar valor y contribuya
a satisfacer las necesidades del cliente.
Riesgos asociados al desarrollo del proyecto: realiza una evaluación
para identificar los riesgos que conlleva efectuar el desarrollo del sistema
a lo interno de la empresa. Si los riesgos identificados son significativos,
tienen alta probabilidad de concretarse y pueden ocasionar perjuicios
graves, es conveniente considerar la tercerización del desarrollo para
delegar la responsabilidad en una organización experimentada que pueda
asegurar el éxito y lograr una rentabilidad efectiva con el desarrollo del
proyecto.
Comparación de la capacidad interna y los proveedores: tiene por
objetivo determinar si las herramientas, conocimientos, experiencia,
capacidad de administración y capacidades técnicas de los proveedores
son mayores a las capacidades internas de la organización para llevar a
cabo el desarrollo exitoso del proyecto.
Individualización de los proyectos a tercerizar: esta tarea tiene por fin
comparar la eficiencia de las actividades o procesos que realiza la
organización, usando como base posibles pérdidas de dinero, gastos excesivos
o ausencia de habilidades para el desarrollo del sistema, con el objetivo de
identificar los proyectos que se pueden tercerizar.
Enunciado del proyecto o desarrollo del acta de constitución: se
encarga de determinar la necesidad de adquisición de una forma general, para
presentar el proyecto a los encargados de la organización con la intención de
obtener su aceptación y compromiso. Esta tarea se puede realizar mediante

diferentes técnicas:
Historias de usuario.
Elaboración de la descripción general del sistema por medio de reuniones,
sesiones, foros, talleres o lluvia de ideas que involucren no solo a los altos
jerarcas sino también a los usuarios finales.
Identificación de los interesados: corresponde a la identificación de las
personas internas que pueden ser beneficiadas o perjudicadas con el
desarrollo del sistema. Esta tarea busca garantizar la participación de esas
personas en el proceso.
3.2. Planificación
Esta fase corresponde a la definición de los aspectos que se deben tomar en
cuenta para controlar la ejecución del proyecto y obtener el producto deseado,
por lo que se debe efectuar la definición adecuada del alcance, los requerimientos,
los elementos de calidad que se deben evaluar, el recurso humano necesario, las
formas de comunicación con el proveedor, la definición de criterios de selección
de proveedor, el tipo de contrato a utilizar y el contenido presupuestario.
Como consecuencia, estas tareas se pueden desarrollar de la siguiente manera:
Definición del alcance: brinda el panorama de alto nivel de los requerimientos

del sistema, por lo que es necesario detallar (Selleo, 2016):
La visión general de la aplicación o producto deseado.
El propósito del nuevo sistema, así como el problema (objetivo o
necesidad) que busca resolver y su definición para alcanzar el éxito.
La lista de funcionalidades, características del producto y usuarios que
lo usarán.
Los requisitos de desempeño, velocidad, disponibilidad, volumen y
fiabilidad.
La tecnología por utilizar, la integración de requisitos como el lenguaje
de desarrollo, el sistema operativo y sistemas que deben trabajar en
conjunto con la nueva aplicación.
Existen circunstancias en las cuales según el tipo de sistema, no se tiene
claridad para definir el alcance al inicio de la planificación. En estos
escenarios, es conveniente abordarlo y completarlo en las etapas claves,
por ejemplo, en las iteraciones o aceptaciones de los entregables. De forma
adicional, se debe tomar en cuenta la selección del tipo de contrato para
estos escenarios, a fin de no afectar los costos o el producto final.
Análisis y definición de requisitos funcionales y no funcionales: se
establecen los requerimientos de bajo nivel del sistema y contempla la
definición de todas las necesidades que debe satisfacer para alcanzar el
producto deseado, según los objetivos planteados y el problema que busca
resolver.
Realización del presupuesto: para identificar la inversión que se debe
efectuar para el desarrollo del software.
Definición del plan de aseguramiento de la calidad: se encarga de

planificar los procesos, requerimientos, salidas y canales de retroalimentación
de la calidad del sistema durante el ciclo de vida del proyecto. Para realizar
la gestión de la calidad de software se deben considerar (IEEE Computer
Society, 2014) las siguientes fases:
Planificación: esta tarea consiste en determinar cuál o cuáles estándares se
desean incluir en el proceso de desarrollo, definir los objetivos de calidad,
estimar los costos y definir el cronograma para realizar las actividades
de revisión de la calidad del software.
Aseguramiento: esta actividad se encarga de asegurar la calidad mediante
la definición de las actividades para satisfacer los requerimientos,
necesidades y costos en tiempo, de acuerdo con el cronograma del
proyecto. Pero además define y evalúa si el proceso seleccionado para
el desarrollo es apropiado, contempla la definición de los objetivos de
calidad e identifica las medidas técnicas y los procedimientos para el
reporte de problemas y la ejecución de acciones correctivas.
Con base en lo anterior, se recomienda seleccionar las categorías de calidad
(Mendoza et al., 2002) que se desea evaluar:
Funcionalidad: la capacidad de cumplir con los requerimientos o
necesidades para las cuales el sistema fue desarrollado.
Fiabilidad: se refiere al correcto funcionamiento del sistema.
Usabilidad: corresponde con la facilidad de uso, comprensión y
aprendizaje por parte de los usuarios.
Eficiencia: consiste en el rendimiento apropiado en escenarios con
demandas de trabajo y respuesta diferentes.
Mantenibilidad: es la capacidad que posee el sistema para ser modificado,
de acuerdo con las necesidades de la empresa.
Portabilidad: corresponde a la posibilidad de que el sistema pueda ser
utilizado en diferentes ambientes operativos o plataformas sin necesidad
de realizar cambios.
El procedimiento establece la selección de un máximo de tres categorías,
de las cuales es obligatorio seleccionar la evaluación de la funcionalidad,
debido a que evalúa el cumplimiento de los requerimientos definidos. La
recomendación de seleccionar un máximo de tres categorías se debe a que
la elección de un número mayor puede desencadenar que la evaluación de
una categoría entre en conflicto con la evaluación de otra categoría. La
selección de las otras dos categorías adicionales depende de la estrategia y
necesidades que la organización busca satisfacer con el sistema. Por último,
en esta fase y con base en las categorías seleccionadas, se seleccionan las
métricas cuantitativas que permitirán realizar la evaluación y estimación de
la calidad del producto.
Planificación de la gestión de recursos humanos: es necesario planificar
los roles necesarios para la gestión del proyecto y el desarrollo exitoso del
sistema (Erazo-Paruma et al., 2014). Estos roles pueden variar de acuerdo
con el tipo de organización y proyecto, pero se recomienda tener en cuenta
los roles que se presenta en la tabla 1.
Tabla 1: Roles de participantes en el proceso de tercerización de software
Puesto/Rol Descripción de responsabilidad

Director (Dir) Es la persona con conocimiento de los procesos de la
organización y tiene la responsabilidad de administrar el
proyecto.
Encargado de Es el encargado de realizar, coordinar y efectuar la contratación
adquisiciones (EA) del proveedor, con base en los parámetros definidos, y es el
contacto directo entre el cliente y el proveedor, con el fin de
centralizar la comunicación y el flujo de información.
Programador o Es la persona o grupo de personas que colaboran en la
Ingeniero de definición de los alcances y requerimientos del sistema. Esta
software (IS): persona puede ser el contacto técnico para comunicaciones con
el proveedor cuando se esté ejecutando el proyecto.
Encargado de Es la persona o grupo con conocimientos en aspectos legales
contratación (EC): para el establecimiento y negociación del contrato, con base en
las necesidades definidas por el director y los usuarios.
Ingeniero de calidad Es la persona o grupo encargado de participar, verificar,
de software (QA): asegurar, probar, controlar y comunicar la calidad del proceso
y producto con base en lo planificado y acordado con el
proveedor. Envía información a los interesados sobre el estado
del proyecto para identificar atrasos, disconformidades o
brechas que puedan existir con el fin de que se pueda realizar
la toma de decisiones de forma oportuna.
Usuario/interesado Son las personas interesadas o afectadas por el desarrollo del
(I): sistema y se debe procurar su compromiso de participación en
el proceso para asegurar su satisfacción con el producto final.
Elaboración del plan de comunicaciones: contempla determinar el flujo de

comunicación entre el cliente y el proveedor para garantizar la participación
activa de los interesados y canalizar la información por medio de un
encargado, que facilite el proceso y esté en disposición de utilizar las
herramientas para hacer la gestión adecuada de la comunicación. Los
elementos básicos que debe tener el plan de comunicaciones (Project
Management Institute, 2013) son los siguientes:
Requisitos de comunicación de los interesados.
Tipo de información que debe ser comunicada, incluidos el idioma,
formato, contenido y nivel de detalle.
Motivo para distribuir dicha información.
Plazos y frecuencia para la distribución de la información y recepción de
las confirmaciones o respuestas.
Responsable de comunicar la información.
Responsable de autorizar la divulgación de información confidencial.
Persona o grupos que recibirán la información.
Métodos o herramientas utilizadas para transmitir la información, tales
como memorandos, correo electrónico o comunicados de prensa.
Recursos asignados para las actividades de comunicación, incluidos el

tiempo y presupuesto.
Proceso de escalamiento, con identificación de los plazos y la cadena de
mando (nombres) para el escalado de los incidentes que no se puedan
resolver a un nivel inferior.
Método para actualizar y refinar el plan de gestión de las comunicaciones
a medida que el proyecto avanza y se desarrolla.
Glosario de terminología común.
Diagramas del flujo que sigue la información del proyecto, flujos de
trabajo con la posible secuencia de autorizaciones, lista de informes y
planes de reuniones.
Restricciones en materia de comunicación que se derivan de la legislación
o normativa, la tecnología o las políticas de la organización.
Definición del tipo de contrato por utilizar: La definición del tipo de
contrato a utilizar se debe basar en el tipo de producto y proyecto (Project
Management Institute, 2013), y podría ser alguno de los siguientes:
Contratos de precio fijo: este tipo de contrato establece un precio final
que es fijo y es adecuado cuando la especificación de requerimientos es
precisa, aunque por lo general establecen que si se realiza un cambio
posterior se dará un aumento en los costos.
Contratos de costos reembolsables: se realizan los pagos por los costos
incurridos durante el desarrollo del sistema, más los honorarios del
proveedor. Este tipo de contratos ofrece flexibilidad para reorientar al
proveedor si el alcance del trabajo no se puede definir con precisión al
inicio y requiere modificaciones.
Contrato por tiempo y materiales: corresponde a un híbrido de los dos
tipos anteriores y se utiliza cuando se necesita aumentar el personal,
contratar expertos o cualquier tipo de apoyo externo en los casos en
que no es posible establecer con prontitud, al inicio del proyecto, ésta
información en el enunciado del trabajo.
Es importante que de forma independiente al tipo de contrato seleccionado,
se puedan contemplar incentivos para motivar al desarrollador o proveedor
a que inviertar mayor esfuerzo y genere un producto de calidad.
Establecimiento de los criterios de selección del proveedor: esta tarea
realiza la identificación de los criterios básicos con lo cuales serán
evaluados y seleccionados los proveedores. Algunos criterios (Grossi
y Calvo-Manzano, 2012) que pueden ser considerados son: el precio,
la calidad, tiempo de entrega, flexibilidad, capacidad técnica, riesgo,
reputación, posición en la industria, comprensión de las necesidades,
garantía presentada, referencias, desempeños anteriores, posición financiera,
capacidad de respuesta, experiencia, recursos humanos, participación de
mercado, administración, organización y soporte. Es importante establecer,
según las prioridades de la organización, el peso relativo de cada criterio para
calcular la calificación final.
Identificación de los proveedores potenciales: corresponde a la

identificación de los proveedores que pueden desarrollar el sistema con
base en la experiencia de expertos, la experiencia de proyectos anteriores y
el análisis del mercado.
Establecimiento y documentación de los criterios de aceptación:
Estos criterios corresponden a la especificación de las necesidades,
requerimientos, capacidades técnicas y de calidad que el cliente establece
como mínimos para aceptar los entregables y el producto final.
Realización del enunciado del trabajo: este documento contempla la
información del alcance y requerimientos del sistema con suficiente detalle
para permitir que los proveedores realicen el análisis y determinen si están
en condiciones de proporcionar el sistema requerido. Este tipo de documento
es necesario para solicitar propuestas a los posibles proveedores y realizar el
anuncio formal de la solicitud de tercerización.
3.3. Selección y contratación del proveedor

La fase de selección y contratación conlleva efectuar la recepción de
ofertas, efectuar la evaluación según los criterios definidos, proceder con la
selección del proveedor, preparar el contrato y formalizar la relación contractual
(Erazo-Paruma et al., 2014), pasos que se detallan a continuación:
Anunciar la tercerización: con base en el enunciado del proyecto, se

anuncia la necesidad de contratar a un proveedor (i.e. mediante licitación,
contratación directa o invitación).
Recepción de las ofertas: una vez transcurrido el plazo definido, se reciben
las propuestas de los proveedores interesados.
Evaluar las ofertas: para garantizar el beneficio de la organización, se realiza
la selección del proveedor con base en los criterios de selección establecidos y
según la estrategia de la organización con respecto al peso en la calificación
de cada criterio.
Selección del proveedor: se recomienda utilizar una matriz de calificación
cuantitativa con los resultados de las evaluaciones de los criterios, para
obtener la calificación de los proveedores y garantizar la mejor selección.
Preparación y negociación del contrato: esta tarea debe contemplar al
menos la definición del alcance, requisitos de rendimiento, cronograma,
acuerdos y responsabilidades, información de puntos de contacto, periodo y
lugar de ejecución, canales y frecuencia de las comunicaciones, estructura del
precio, términos de pago, criterios de inspección y aceptación de entregables,
garantías presentadas por el proveedor, acuerdos de servicio y soporte,
proceso para hacer cambios al proyecto, confidencialidad, derechos de autor
y propiedad intelectual, derechos de terminación, criterios de rendimiento de
los proveedores (SLA2 ), informes de desempeño, incentivos y penalizaciones
(Project Management Institute, 2013) .
2
SLA se refiere Service Level Agreement en su acepción del inglés.
Adjudicación del contrato: se establece un acuerdo contractual con el

proveedor y se formaliza mediante la firma de las partes interesadas, lo cual
da lugar al inicio formal del desarrollo del producto especificado.
3.4. Ejecución
La fase de ejecución contempla la etapa de desarrollo del sistema y requiere
la participación activa del cliente y es necesario ejecutar el plan de control de la
calidad. Este plan recibe como entrada los elementos del plan de aseguramiento
de la calidad y se encarga de realizar la evaluación de criterios mediante
revisiones, auditorias e inspecciones (véase la figura 2). Estas evaluaciones se
realizan en todo el ciclo del desarrollo del sistema para asegurar un producto de
calidad (IEEE Computer Society, 2014) y comprenden:
Revisiones de administración: se encargan de monitorear el progreso del

proyecto, y del cronograma, y la efectividad de la gestión del proceso de
desarrollo realizando comparaciones con lo planificado.
Revisiones técnicas: se encargan de realizar una evaluación del producto con
base en las categorías de evaluación definidas y verificación de acuerdo con
las métricas establecidas.
Evaluación de técnicas estáticas: son responsables de examinar la
documentación (requerimientos, diseño y modelo, entre otros aspectos) y
el código fuente del software sin proceder con su ejecución.
Evaluación de técnicas dinámicas: determinan el cumplimiento de las
medidas o niveles de calidad deseados del software, ejecutando el código
previo a realizar el lanzamiento.
3.5. Administración de la relación

La administración de la relación con el proveedor enfoca sus esfuerzos en
la participación de los interesados del proyecto y la empresa proveedora para
maximizar la presencia de los usuarios finales en el equipo de desarrollo, con el
fin de alcanzar mayor entendimiento, compresión y solución de las necesidades
(véase la figura 3). Además, contempla realizar evaluaciones del avance del
proyecto mediante el uso de herramientas colaborativas y representaciones
gráficas de cumplimientos de tareas para reducir las distancias físicas, culturales
y de idioma, y acercar a los participantes del cliente y el proveedor. Esta fase
se encarga de gestionar los posibles problemas que se puedan presentar por
cambios o diferencias de criterios durante el desarrollo del proyecto. Las tareas
que sustentan esta fase son las siguientes:
Efectuar el plan de gestión de comunicaciones: se recomienda llevar a

cabo las actividades del plan de gestión de comunicaciones, gestionar las
reuniones, comunicación y participación activa de los interesados e involucrar
a los usuarios en el proceso de desarrollo, así como desarrollar las siguientes
actividades de apoyo:
Figura 2: Diagrama de gestión de calidad
Maximizar la presencia física de los interesados o usuarios finales

en el equipo de desarrollo, para lograr mayor cumplimiento de los
requerimientos, proporcionar retroalimentación y resolver ambigüedades
en los requerimientos.
Efectuar por lo menos dos reuniones formales a la semana, siempre y
cuando las ubicaciones físicas del cliente y el proveedor lo permitan,
contemplando una reunión presencial y otra virtual entre los interesados
y el equipo de desarrollo para solucionar inconvenientes, verificar
los avances, el cumplimiento de objetivos, así como de los acuerdos
alcanzados con base en las sesiones anteriores y responder inquietudes.
Cuando no sea posible realizar reuniones físicas semanales entre los
interesados y el equipo de desarrollo debido a limitaciones geográficas
por la ubicación de los equipos en diferentes localidades, es necesario
ajustar el número de reuniones físicas para que sea requerido realizar al
menos una reunión al mes y efectuar por lo menos una reunión virtual
a la semana.
Obtener información de las direcciones de contacto del proveedor como
grupos de correos electrónicos, números de teléfono de los encargados,
direcciones de contacto para realizar videoconferencias e información de
las reuniones presenciales.
Figura 3: Diagrama de administración de la relación con el proveedor
Es importante que los mensajes que se intercambien sean concretos,

coherentes, completos, claros, concisos y correctos, sin importar el medio
de comunicación que se utilice.
Representar de forma visual el flujo de trabajo es una de las mejores
opciones y formas de mantener la comunicación. Por lo que se recomienda
usar un tablero de Kanban para que ambas empresas de manera visual
puedan observar cuáles son las labores que están pendientes, cuáles se
están ejecutando para preparar y efectuar las evaluaciones de calidad,
así como cuáles están en proceso de pruebas o completamente listas.
Utilizar herramientas de trabajo colaborativo para la comunicación entre
las organizaciones (chats y correos electrónicos), gestión del conocimiento
(wikis, gestión de notas, gestión de fotos, almacenamiento en línea,
ediciones colaborativas, publicación de documentos y presentaciones) y
la gestión del proyecto (control del calendario, seguimiento de reuniones,
eventos, controlar los hitos, las tareas pendientes, herramientas de
responsabilidades y distribución del trabajo). Además, es importante
elaborar mapas mentales y tableros colaborativos, por ejemplo, mediante
el uso de conceptboard para la inclusión de comentarios y notas o

corkboard para incluir notas a los participantes del proyecto.
Informar el desempeño del proveedor: se encarga de recopilar y distribuir
información de desempeño, por lo que se puede comparar el cumplimiento
de los requerimientos para comprender y comunicar el avance, el desempeño
y el cumplimiento del proyecto mediante el análisis de curvas de eficiencia,
además de analizar indicadores con respecto al cronograma, costos, calidad,
trabajos completados, pendientes, estado de los incidentes y riesgos.
Si existen brechas entre lo alcanzado y lo esperado, es necesario analizar las
razones por las cuales se presentan y comunicarse con el proveedor para que
suministre los planes de acciones correctivas que le permitan cumplir con
todas las metas y entregables del proyecto.
Presentar los hallazgos: los informes de desempeño y la participación de
los interesados en el proceso permiten realizar revisiones de incidentes,
problemas, retroalimentación u oportunidades de mejora, las cuales es
necesario comunicar, controlar y brindarles seguimiento para asegurar su
resolución satisfactoria.
Identificar afectaciones: en conjunto con los interesados, es necesario
identificar cambios importantes que puedan afectar el servicio durante la
siguiente fase de ejecución del proyecto, así como los cambios que provocaron
incidentes.
Evaluar aspectos ajenos al proceso: esta tarea se encarga de evaluar los
eventos clave que requieren atención especial por parte del proveedor.
Gestionar la resolución de conflictos: tiene por fin solucionar las
discrepancias de puntos de vista, renegociar aspectos necesarios con
base en hallazgos presentados y administrar variaciones por cambios no
contemplados que alteren el alcance de los objetivos del proyecto.
3.6. Aceptación y cierre

Esta fase hace énfasis en la recepción por parte del usuario e interesados de
los entregables parciales y finales para evaluarlos con base en los criterios de
aceptación acordados, los cuales deben estar alineados con las características de
calidad planificadas y las pruebas de evaluación. Las tareas básicas de esta fase
(Erazo-Paruma et al., 2014) son las siguientes:
1. Recibir la entrega parcial o final del sistema, realizar las pruebas al sistema,
valorar los resultados y tomar en cuenta los criterios de aceptación para el
cumplimiento satisfactorio del producto.
2. Cuando en el proceso de pruebas se identifiquen no conformidades, realizar
el reporte para proceder con las correcciones necesarias, en caso contrario,
proceder con la aceptación del entregable.
3. Administrar los contratos y facturas canceladas o pendientes de pago para
el proveedor.
4. Confirmar al final del proyecto que todos los entregables sean aceptados.
5. Al cerrar las adquisiciones, proceder con la conclusión del contrato,

evaluación general del proveedor y el registro de experiencias aprendidas
para utilizarlas en futuros proyectos.
3.7. Reconsideración
La fase de reconsideración corresponde a una evaluación con base en la
experiencia e información suministrada durante el desarrollo del proyecto, y
considera efectuar las siguientes actividades:
1. Realizar revisiones del servicio, alcance y contratos de forma anual, para

compararlos con las necesidades actuales del negocio y asegurar que se brinde
un verdadero valor de retorno a la inversión o realizar los cambios y ajustes
necesarios para alinearlos a los objetivos estratégicos.
2. Cuando el proveedor lleva a cabo su trabajo de acuerdo con los niveles del
servicio y el cumplimiento de criterios y evolución del proyecto, pero existe
una percepción de insatisfacción final, verificar el ajuste de las métricas
de evaluación debido a que puede ser la consecuencia de una inapropiada
definición de los criterios en la planificación.
3. Reconsiderar continuar o cambiar de proveedor (en caso de incumplimientos
comprobados y verificables), y evaluar el impacto del costo que esta decisión
pueda provocar a la empresa contratante.
4. En los escenarios donde el proveedor cumpla con sus funciones correctamente
y tanto los acuerdos de nivel de servicio y los tiempos de verificación sean
cumplidos de forma satisfactoria, pero se comprueba que el desarrollo de este
tipo de sistemas no agrega valor al negocio o retorno de la inversión, se puede
considerar realizar el backsourcing, que consiste en reintegrar el proceso
tercerizado a lo interno de la empresa, si se cuenta con las capacidades
suficientes. Sin embargo, es importante evaluar el impacto en costos y
recursos que esta operación pueda significar para la organización.
La figura 4 presenta de manera visual las fases definidas para la gestión de

terceros durante los procesos de desarrollo de software. En esta figura se pueden
notar en primera instancia los roles mínimos que se consideran necesarios para el
desarrollo de cada una de las fases. Esta metodología individualiza las entradas
y subprocesos y define las salidas que se espera obtener.
Como se mencionó, la fase de administración de la relación no es una fase
de ejecución secuencial, debido a que contiene las fases de ejecución, aceptación
y cierre y reconsideración. Adicionalmente, en el diagrama se hace referencia a
la utilización de una base de datos para almacenar datos relacionados con la
gestión, evaluación del proveedor y experiencias aprendidas durante el proyecto
o proyectos previos.
Metodología para la gestión de terceros en procesos de desarrollo de software
19
Figura 4: Diagrama propuesto de gestión de terceros para el desarrollo de software
4. Conclusiones y trabajos futuros

La gestión de las relaciones con terceros es un elemento crítico cuando
se realiza la contratación de proveedores para el desarrollo de sistemas de
software,por lo que este trabajo contempló la elaboración de una metodología
para realizar la gestión adecuada de un proyecto de tercerización.
La metodología es una síntesis de los procesos y mejores prácticas que deben
contemplarse en la gestión de terceros y resume aspectos fundamentales sobre las
fases, tareas y salidas que se esperan en cada una de las etapas de un proyecto
de esta naturaleza. Por lo tanto se espera que sea una herramienta útil para
orientar y brindar una visión general a los especialistas, de los aspectos que
deben contemplar durante la planificación y desarrollo de proyectos de software
contratados a terceros.
La incorporación de aspectos como la planificación de la administración de
la relación con los proveedores, la gestión de la comunicación y el aseguramiento
de la calidad durante todo el proceso, desde la concepción del sistema hasta su
aceptación, son los elementos de mayor relevancia en la metodología, debido a
su transcendencia para el éxito del desarrollo de sistemas de calidad.
Cabe resaltar que una de las virtudes de la metodología desarrollada es la
síntesis visual que ofrece del proceso, lo cual brinda un panorama claro de la ruta
y actividades que se pueden considerar. Esto tiene por fin facilitar la comprensión
del proceso, y la comunicación con la gerencia, y mejorar la aplicación del
proceso.
Como trabajo futuro se recomienda evaluar el uso de herramientas
colaborativas y de gestión de proyectos, e identificar las mejores opciones
disponibles para ser integradas en un proceso de tercerización. Además, también
se recomienda desarrollar una metodología que contribuya con el correcto
levantamiento de requerimientos para el desarrollo de sistemas, tomando en
cuenta la participación activa de usuarios e interesados.
Referencias
CabinetOffice. (2011). ITIL service strategy (segunda ed.).
CENDITEL, Fundación. (2013). Aseguramiento de calidad en el desarrollo de
software libre. Venezuela.
Erazo-Paruma, L. R., Guerrero-Mera, G. L. y Correa-Pino, F. J. (2014). Método
para la adquisición de software en pequeñas organizaciones. Revista UIS
Ingenierías, 13 (1).
Franceschini, F., Galetto, M., Pignatelli, A. y Varetto, M. (2003). Outsourcing:
guidelines for a structured approach. Benchmarking: An International
Journal , 10 (3), 246–260.
Grossi, L., y Calvo-Manzano, J. A. (2012). Mejora de procesos en el Ámbito
de adquisición: Un modelo de decisión para la selección de proveedores de
ti. CISTI (Iberian Conference on Information Systems & Technologies /
Referencias 21
Conferência Ibérica de Sistemas e Tecnologias de Informação) Proceedings,

483-488.
IEEE Computer Society. (2014). SWEBOK, guide to the software engineering
body of knowledge. Descargado de https://www.computer.org/web/
swebok
McIvor, R. (2005). The influence of transaction cost economics and the resource
based view on the outsourcing process. En Sixteenth Annual Conference
of POMS, Chicago.
Mendoza, L. E., Pérez, M. A., Grimán, A. y Rojas, T. (2002). Algoritmo para la
evaluación de la calidad sistémica del software. En Proceedings of Second
Ibero-American Symposium on Software Engineering and Knowledge
Engineering (JIISIC’02), Salvador, Brasil, octubre, 2002 (pp. 85–96).
Mendoza, L. E., Pérez, M. A. y Grimán, A. C. (2005). Prototipo de modelo
sistémico de calidad (mosca) del software. Computación y sistemas, 8 (3),
196–217.
Perunović, Z., y Pedersen, J. L. (2007). Outsourcing process and theories. En
Proceedings of the Eighteenth Annual Conference (POMS), 4 a 7 de mayo,
Dallas, Texas, 2007 (Vol. 3).
Project Management Institute, I. (2013). Guía de los fundamentos para la
dirección de proyectos (guía del PMBOK®) (quinta ed.). Autor
Selleo. (2016). A practical guide to outsourcing your software development.
Descargado 09-08-2016, de http://selleo.com/wp-content/uploads/
2014/08/software-outsourcing-guide.pdf
Gestión de la relación con terceros y
metodologías ágiles
Fabián Chaves Serrano, David Mora Solano y Antonio González Torres∗
San José, Costa Rica [fchavess976,dmoras530]@ulacit.ed.cr
Resumen La tercerización del desarrollo de software es una práctica

común entre muchas empresas. Sin embargo, con frecuencia el resultado
final no satisface las necesidades del cliente debido a la mala
comunicación, creación de falsas expectativas, deficiente transferencia
del conocimiento, la inadecuada definición del alcance del proyecto y
el escaso involucramiento del cliente. A lo anterior se debe agregar
que los modelos y estándares más utilizados no contemplan detalles
sobre la forma en que se puede gestionar la relación que establecen los
clientes y proveedores. Como consecuencia, el objetivo de este trabajo de
investigación es proponer un modelo que sirva como guía para apoyar la
gestión de las relaciones con terceros, utilizando como base los principios
de las metodologías ágiles más importantes, las cuales contemplan el uso
de microciclos y la constante comunicación con los usuarios y clientes.
Palabras clave: Tercerización, relación con terceros, desarrollo ágil
1. Introducción
El creciente y rápido cambio de la tecnología trae diversos y complejos retos
a las empresas para llevar a cabo de manera eficiente y eficaz sus procesos de
negocios, lo cual requiere la constante evolución de los servicios y productos que
ofrecen las compañías. Esto implica que deben contar con personal capacitado
para enfrentarse a esos retos y mantenerse en el mercado. Pero, en ocasiones,
ante la ausencia de ese personal, se enfrentan a problemas presupuestarios al
implementar nuevas tecnologías, por los problemas que se originan en la mala
gestión y deficiencias técnicas. Por esa razón, la tercerización ha sido vista como
una posible solución para mejorar la capacidad de respuesta de los negocios y
su estructura de costos.
En los últimos años la tercerización ha crecido de forma considerable y se ha
expandido de manera rápida para brindar servicios de toda índole, incluyendo
desarrollo de software, soporte técnico, reclutamiento de personal, finanzas y
contabilidad, entre otros.
Gestión de la relación con terceros y metodologías ágiles 23
En la actualidad la tercerización de desarrollo de software es de alta relevancia

y muy popular; países como India y China son grandes exponentes de esta
tendencia. Sin embargo, el número de casos donde el producto no se entrega
a tiempo es elevado, el intercambio de información entre las partes es deficiente
y no se cumple con la mayoría de los requerimientos establecidos. En algunos
casos las causas son las barreras culturales y de idioma, un inadecuado control
de los procesos dentro del ciclo de desarrollo del software, la mala comunicación,
la falta de participación activa de los clientes y la creación de falsas expectativas.
El objetivo de este trabajo de investigación es preparar una guía de
mejores prácticas, tomando como base los principios de las metodologías
ágiles. El fin de esta guía es contribuir con la disminución de los efectos
negativos de la tercerización de desarrollo de software y facilitar la adecuada
comunicación, transferencia de conocimiento, establecimiento de expectativas y
el entendimiento y control entre los clientes y los proveedores.
2. Estado del arte

La tercerización consiste en el traslado de la ejecución de parte de los procesos
del negocio a otra empresa, la cual cuenta con la especialización y capacidades
para desarrollar dicha actividad como un servicio a más bajo costo y de forma
más eficiente que la empresa contratante. La tercerización se ha convertido para
muchas compañías en una solución práctica para mejorar su funcionamiento.
Los procesos que se transfieren no forman parte del núcleo del negocio, no
son esenciales ni críticos, aunque en algunos casos documentados (Girotra y
Netessine, 2012) se ha evidenciado que estos también son transferidos a terceras
empresas.
La tercerización suele confundirse con la subcontratación, subcontratación
internacional y externalización al extranjero, los cuales funcionan de forma
diferente:
Subcontratación: consiste en que parte del trabajo se transfiere a otra empresa

la cual contrata a otra que tiene habilidades o recursos que le permiten
realizar tareas claramente especificadas en especiales y mejores condiciones
(Dolgui y Proth, 2013).
Subcontratación internacional: cuando una compañía traslada
completamente sus procesos de negocio a otro país distinto al de origen, se
habla de subcontración internacional. Esta situación es relativamente rara
ya que es arriesgada (Dolgui y Proth, 2013).
Externalización al extranjero: la empresa contratada se encuentra en un
país diferente al de la empresa que contrata. Así que la localización diferencia
el concepto (Dolgui y Proth, 2013).
Debido al auge de la tercerización, muchas compañías buscan como

implementarlo en sus negocios. Estas empresas investigan qué beneficios les
puede traer y qué impacto tiene. Esta metodología trae consigo diversos
beneficios y puede mejorar el valor de la firma del cliente de muchas maneras,
24 Chaves et al.
como por ejemplo el acceso a la base de la competencia. Recientes investigaciones

encontraron que la reducción de costos se sitúa en la posición más alta entre otros
beneficios de la tercerizacion (Kakumanu y Portanova, 2006; Bersin, 2005).
Por otra parte la tercerización trae consigo algunas desventajas como las
siguientes:
El dilema de la competencia: se genera cuando el cliente y el vendedor

establecen entre si una relación estrecha, donde el flujo de información es
vasta y se comparte información de los procesos centrales del negocio. De esta
manera el vendedor con todo este conocimiento estará listo para competir
con el cliente (Kakumanu y Portanova, 2006).
Pérdida de la iniciativa por el cliente: el cliente genera una elevada
dependencia del vendedor, limitando su libertad de acción, los costos
generados por el vendedor pueden llegar a ser altos, pero debido a la
dependencia no se puede prescindir de estos.
La tercerización fuera de las fronteras a países desarrollados: se
genera cuando un producto o una parte del producto se soluciona a
través de la tercerización en otro país y este por consecuencia termina
siendo más barato. Esto causa que una vez que el producto se venda,
tendrá repercusiones en el mercado para compañías locales, las cuales no
podrían “competir” con dichos precios.También, si la misma compañía
fabrica productos similares pero de manera local, se verán afectados por los
productos que fueron tercerizados.
La tercerización de software trae consigo diferentes problemas, esto causa que

algunos proyectos no sean exitosos. Diversas investigaciones han determinado que
los problemas más comunes son la mala comunicación, la ausencia del cliente
durante el proyecto y la generación de falsas expectativas. Al respecto, existe un
gran número de casos en los cuales los procesos no han sido exitosos. Sobre este
particular, KPMG, Dreischmeier y Deloitte han observado diferentes aspectos
por los cuales la tercerización no ha funcionado como se desea, entre los que se
encuentran los objetivos, la relación entre el cliente y el proveedor, la calidad
del servicio, los problemas de comunicación y la mala gestión (Sáenz, Cámara,
Calvo-Manzano y Arcilla, 2014).
El análisis de los procesos de tercerización muestra que en múltiples ocasiones
(Bersin, 2005) falta:
Comunicación: frecuentemente las partes que intervienen en los procesos de

tercerización se excluyen mutuamente de la comunicación. No intercambian
información constante de avances o dudas que se generan; se basan solo en
una reunión inicial; y pocas veces se reúnen para revisar, clarificar, preguntar,
y redefinir tanto aspectos técnicos como de gestión en relación al proyecto.
Transferencia del conocimiento: la información generada por el proveedor
no se transmite de manera adecuada al cliente. Si bien es cierto que se
entrega documentación como manuales técnicos y de usuario, esto no es
suficiente, porque durante el desarrollo del proyecto, pudieron existir diversos
escenarios que recibieron atención específica, además de complicaciones que

se resolvieron con ideas innovadoras, y todo esto se traslapa con los manuales
antes mencionados.
Definición del alcance y expectativas: se puede decir que el alcance de un
proyecto es en ocasiones difícil de definir y a raíz de este alcance se generan
las expectativas del proyecto. Cuando no existe una adecuada comunicación
estos dos aspectos pueden variar, y los resultados no cumplen completamente
los requerimientos planteados.
Seguimiento y participación activa del cliente: el cliente se reúne con el
proveedor, definen el contrato, se levantan requerimientos y se presenta un
posible diseño previo.Todo lo anterior se realiza al inicio del proyecto, después
de esto el cliente no se entera de los siguientes procesos, y en la fecha
de finalización del proyecto, después de mucho tiempo sin comunicación se
informa que el proyecto está finalizado, o por el contrario que el proyecto
está atrasado y el cliente no sabe la razón de esto. Lo anterior sucede debido
a que el cliente no tiene un control real en el seguimiento del proveedor y,
además, no está involucrado de manera eficaz ni dominante.
Debido a que el enfoque de esta investigación se basa en los principios de
diversas metodologías ágiles, es importante mencionar cuál es su relación con
la tercerización. Las metodologías ágiles nacieron enfocadas al desarrollo de
software, pero con el paso del tiempo se comenzaron a utilizar en otro tipo
de proyectos. Sin excepción, toda metodología ágil se basa en los principios del
“Manifiesto ágil” (Beck et al., 2001). Las metodologías ágiles buscan que los
procesos sean más eficientes y eliminar aquellos que son innecesarios, es por
esto que se considera que estas metodologías podrían dar un gran aporte a las
relaciones con terceros.
Las metodologías ágiles buscan flexibilidad y efectividad cuando se desarrolla
un proyecto de software o de otra índole. Se realizan iteraciones incrementales
conocidas como Sprint, las cuales comprenden dos semanas y consisten en ciclos
de desarrollo, revisión, retroalimentación, aprobación y ajuste, y tienen como
objetivo generar un entregable tangible al finalizar el ciclo. Las diferencia en
relación con otras prácticas es la posibilidad de generar cambios durante el ciclo
del proyecto, sin afectar de manera agresiva su proceso.
Otro aspecto importante que se debe tomar en cuenta es la continua
visibilidad y comunicación que existe entre clientes, usuarios y desarrolladores
para asegurar el éxito y rumbo del proyecto.
En la actualidad existe una gran diversidad de metodologías ágiles, para
diferentes tipos de proyectos y necesidades. Las metodologías que se estudian a
continuación fueron elegidas debido a las buenas prácticas, guías y consejos que
brindan y que se ajustan al objetivo de esta investigación. A continuación se
muestra un resumen con la información más relevante de cada una de ellas.
Programación externa: Esta metodología se basa en cuatro aspectos:
comunicación, simplicidad, retroalimentación y coraje. Esta metodología
busca que todo se realice de manera sencilla, para una mejor comprensión,
manteniendo al cliente altamente informado de lo que sucede.
26 Chaves et al.
Scrum: Scrum es una metodología que se basa en iteraciones dividiendo el

proyecto en partes, donde se realizan entregas incrementales al cliente,
basandose siempre en buenas practicas.
Crystal: Crystal es una familia de metodologías, ocho en total, las cuales se
basan y tienen en común los siguientes aspectos:
Frecuentemente entregados.
Mejoramiento reflexivo.
Comunicación cercana.
Seguridad cercana.
Concentración.
Fácil acceso a usuarios expertos.
Estas familias funcionan con base en el tamaño y el nivel de criticidad de
los proyectos, según sea el nivel de estos, así una familia u otra podrá ser
implementada.
Lead Development: Esta metodología tiene como característica el ser más una
filosofía que un proceso de desarrollo. Se basa en algunas buenas prácticas y
buenos principios debido a su naturaleza. Ejemplo de ellas son: satisfacer al
cliente es la máxima prioridad, todo se puede cambiar, una solución al 80 %
hoy, en vez de una al 100 % mañana.
Los puntos claves que se analizaron sobre estas metodologías se muestran de

forma resumida en el cuadro 1.
Metodología ágil Puntos claves

Programación
Lanzamientos pequeños y frecuentes.
extrema
Reuniones cortas todos los días.
Proyecto dividido en iteraciones.
Scrum
Requisitos de proyecto presentados en
bloques de tiempo cortos.
El avance se muestra al cliente al final de
cada iteración.
Crystal Entregas frecuentes.

Acceso a usuarios finales expertos.
Comunicación cercana.
Lead development La satisfacción del cliente es la prioridad.

Activa participación del cliente.
Brindar soluciones generales y no especificas.
Tabla 1: Cuadro resumen de metodologías ágiles.

3. Gestión de proyectos y metodologías ágiles
Figura 1: Gestión de proyectos de tercerización con metodologías ágiles.
La figura 1 muestra la propuesta de un proceso para la tercerización del

desarrollo de software. La propuesta se divide en las siguientes etapas:
Definición de requerimientos: es la primera etapa del proceso, se emplea un

marco de referencia denominado Design Sprint, el cual tiene como objetivo
reunir las partes claves en el proyecto, tanto del lado del cliente como del
proveedor, para crear un prototipo y definir los requerimientos iniciales del
proyecto, eliminando los problemas de comunicación en esta fase.
Iteraciones: en esta fase se inicia un ciclo que incluye diferentes procesos hasta
que el producto esté terminado y sea aprobado por el cliente. Las etapas que
comprende son las siguientes:
Ciclos de desarrollo: estos ciclos están a cargo de los desarrolladores de
software, y comprenden la parte de carpintería del proyecto en la cual se
escribe el código.
Revisión del dueño del producto: el dueño del producto es quien está
a cargo de los resultados de los desarrolladores y es quien se encarga de
gestionar a los interesados, por lo que en esta fase se toma la tarea de
revisar el producto de la fase anterior.
Retroalimentacion: después de pasar por el desarrollo y su aprobación
se realiza una reunión rápida con los involucrados para hablar sobre
los avances en el proyecto, qué se debe mejorar y cuáles son las tareas
que se deben realizar, así como los posibles cambios a la planificación.
Esta etapa busca impulsar la interacción continua entre los clientes y los
involucrados en el proyecto.
Aprobación del cliente: en esta fase el cliente define si el proyecto está
listo para su lanzamiento o se debe continuar con otra iteración.
28 Chaves et al.
Ajustes: es la ultima fase de la iteración y en esta se determinan los ajustes

que se deben realizar en el proyecto para continuar con la siguiente
iteración.
Lanzamiento: se realiza la entrega del producto final al cliente.
4. Guía de mejores prácticas para la tercerización

de software
El uso de los elementos claves de las diferentes metodologías ágiles es
un excelente punto de partida para elaborar una guía que le proporcione al
cliente una herramienta para ayudarle a asegurar la finalización exitosa de un
proyecto. Con base en esto, a continuación se presenta dicha guía, tomando en
cuenta la comunicación, trasferencia de conocimiento, definición del alcance y
expectativas, el seguimiento de las tareas y la participación activa del cliente.
4.1. Comunicación
La comunicación es un factor clave entre el cliente y el proveedor (Bersin,
2005). Sin embargo, esta no suele ser gestionada de manera correcta, por lo que
se propone realizar:
Reuniones constantes: El cliente debe crear un cronograma donde se

establezcan reuniones constantes con el proveedor. Estas reuniones deben
programarse de acuerdo con la conveniencia de ambas partes y pueden ser
virtuales para evitar el traslado del personal. La frecuencia debe ser menor
a 15 días, porque que se considera que no es prudente revisar resultados y
avances en ventanas de tiempo mayores. Se recomienda que la duración de
las reuniones no sea mayor de 30 minutos si solo se presentan actividades de
gestión. Pero las reuniones pueden extenderse más si es necesaria la discusión,
presentación y prueba de algún prototipo.
La documentación de las reuniones se puede realizar de diferentes maneras,
como las siguientes:
Grabación tanto de vídeo como de audio.
Minutas o herramientas que utilice la empresa para documentar.
El cliente puede enviar un correo electrónico con la minuta de los puntos
revisados en la reunión.
Reuniones personales: Las reuniones virtuales son un punto clave para
la comunicación, pero se recomienda realizar reuniones personales. Estas
reuniones son de gran valor para la discusión de ideas del cliente y el
proveedor, y son de utilidad para presentar diseños en papel, interpretar
reacciones de las personas y probar prototipos.
Se recomienda realizar las reuniones personales en un lugar en que los
participantes puedan tener acceso a las herramientas necesarias para
desarrollar la sesión (computadoras, Internet, papel, lápices, pizarras,
marcadores). Esto proporcionará un ambiente donde se puedan clarificar
o remarcar aspectos que no estén completamente definidos, incluso el

proveedor puede sacar ventaja de estas reuniones para mostrar ideas o
diseños que puedan surgir durante el proyecto.
Estas reuniones se pueden realizar para discutir el avance actual y los
puntos importantes pendientes, así como cada vez que se produzca un avance
importante en el desarrollo (iteración).
Este tipo de reuniones puede ser documentada con:
Herramientas de documentación.
Minutas.
Grabación con cámaras en la sala de reunión.
Escaneo del material que se genere en la reunión para compartirlo y
archivarlo de forma digital.
Reportes: Las reuniones tanto virtuales como personales, son sumamente
enriquecedoras, pero cuando no se cuenta con material suficiente, o es
necesario informar sobre algún suceso antes de la fecha establecida, útil usar
reportes con información breve
Esos reportes pueden, dependiendo en la cantidad y valor de la información,
sustituir una posible reunión, si esto es aceptado por el cliente.
4.2. Trasferencia de conocimiento

Otro de los problemas más comunes cuando se contrata a un tercero para
el desarrollo de software, es que el conocimiento no se transfiere al cliente de
la manera adecuada. Por ejemplo, el conocimiento que se adquiere durante la
realización del proyecto, solamente queda en manos del proveedor, por lo que es
importante considerar un plan que fomente la cooperación entre ambas partes
para compartir información.
Para realizar la transferencia de conocimiento se sugiere la implementación
de tres conceptos que introduce ITIL en sus buenas prácticas para el manejo de
información:
Base de conocimiento: uso de una base de conocimiento1 para almacenar

información sobre la resolución de problemas recurrentes, datos relevantes
sobre sistemas de información internos y el uso de metodologías. Este
tipo de base de datos se suele integrar con un sistema de gestión del
conocimiento, el cual se encarga de proporcionar detalles a los usuarios
finales de manera eficiente. Además proporciona una vía para que los usuarios
generen conocimiento basado en su experiencia con el proyecto.
Se recomienda utilizar el sistema de gestión del conocimiento para
documentar la información relevante que se genere durante el desarrollo y que
pueda ser útil en el futuro para realizar modificaciones, implementaciones y
solucionar problemas del sistema.
La generación de conocimiento puede derivarse de diversas formas y deben
documentarse por medio de una herramienta de este tipo:
1
Conocida en inglés como Knowledge Base (KB).
30 Chaves et al.
Errores del sistema y su solución: durante las pruebas del sistema,

podrían generarse errores que son producto de la propia naturaleza del
software, por lo cual son resueltos de manera especifica, y tanto el error
como la solución deben ser documentados.
Complejidad: los sistemas se componen de varios módulos que no
funcionan de la misma forma, por lo que los procedimientos para el
manejo de la programación o mantenimiento de un módulo deben
documentarse.
Versiones del software: cada versión del sistema evoluciona de acuerdo
con el avance del proyecto; si existen aspectos que cambian radicalmente
o que son fundamentales en la herramienta y son cambiados de una
versión a otra, estos deben ser registrados.
Otros: pueden existir muchos aspectos que el cliente o proveedor consideren
que deben ser documentados, y que deben establecerse de manera
conjunta para que sea realizado de manera correcta. Entre las opciones
disponibles se encuentran las siguientes:
Soluciones en el mercado:
Novo Solutions
KBPublisher
XWiki
CMDB2 : es una herramienta que tiene como objetivo el manejo eficiente de los
servicios y activos, que están conformadas por elementos de configuración3 .
Soluciones en el mercado:
Cherwell
Servicenow
CMDBuild
DSL (Biblioteca definitiva de software)4 : se refiere a un repositorio central
de software para gestionar imágenes de software con sus distintas versiones
autorizadas, documentación, componentes aprobados por los desarrolladores,
licencias y otra información relevante.
4.3. Definición del alcance y expectativas

El alcance del sistema debe ser definido por el cliente de forma inicial y tiene
que ser comunicado al proveedor para tener claros los límites del proyecto.
Las expectativas que se generan entre las partes involucradas tiene su origen
en la definición correcta del alcance, el cual cuando es definido de forma
incorrecta se convierte en un grave problema para la tercerización de software
(Smuts, van der Merwe, Kotzé y Loock, 2010).
Reuniones de diseño
Es importante establecer desde un inicio, de forma clara y eficiente, lo que
se espera del proveedor, por lo que se deben realizar reuniones de diseño, en las
3
Los elementos de configuración son conocidos en inglés como configuration items.
cuales se puede usar como referencia el marco de trabajo denominado Design

Sprint. Este marco de trabajo permite diseñar soluciones a problemas en un lapso
de dos a cinco días, y además permite la contribución de diversos participantes
en el proceso, a la vez que facilita la comunicación y claridad a la hora de definir
las ideas.
El concepto de este marco de trabajo fue tomado de las metodologías ágiles
y adaptado por Google. En la actualidad el marco de trabajo utiliza un proceso
que se divide en seis etapas:
Entender: se realiza un proceso para entender qué es lo que el usuario necesita,

e involucra a los usuarios expertos para que expliquen en qué consiste el
negocio o proceso que se pretende mejorar, además de una investigación
sobre el mercado actual y las capacidades tecnológicas.
Definir: se determinan las características que el sistema debe tener y se les
pide a los usuarios que definan con tres frases cómo les gustaría que fuese el
sistema; además, en esta etapa se crean historias sobre la interacción de un
usuario con el sistema.
Divergir: se les pide a los usuarios que dibujen ocho ideas en cinco minutos
sobre el sistema, además de realizar una historieta sobre una de sus ideas.
Decidir: se discute y decide sobre cuáles ideas podrían resultar útiles para el
sistema y a partir de estas se genera la discusión sobre las características de
un prototipo.
Prototipo: se implementa un prototipo y se obtiene retroalimentación de los
usuarios expertos.
Validar: el prototipo es probado por los usuarios, a quienes se les hace una serie
de preguntas sobre lo que piensan acerca de los prototipos.
Al finalizar estas fases se cuenta con los requerimientos iniciales y la definición

de los sprints para las reuniones de diseño. Cabe destacar que al final de cada
etapa se debe realizar un resumen con los resultados, los cuales deben ser
documentados. Además, se recomienda que el equipo de trabajo esté formado por
diseñadores, ingenieros, gerentes de proyecto, expertos y el maestro de sprint 5 .
4.4. Participación activa del cliente

El cliente debe estar informado sobre lo que ocurre en el proyecto, pero
también debe participar de forma activa. Esto se convierte en un punto clave,
porque el cliente debe trabajar con el proveedor de forma constante, dando
seguimiento a los avances, problemas y resultados.
Pruebas con usuarios expertos

En las diferentes reuniones se pueden realizar pruebas que le permitan al
cliente observar el estado del producto. Pero se recomienda que estas pruebas no
5
El maestro de sprint es la persona encargada de diseñar los retos para cada etapa
del sprint.
32 Chaves et al.
sean realizadas solo por el proveedor, sino que los usuarios expertos del cliente
las realicen.
Algunos de estos usuarios expertos también deben participar en las reuniones
virtuales y presenciales, porque son quienes utilizarán el sistema una vez que esté
finalizado.
Con el fin de que los usuarios expertos formen parte de las sesiones de prueba
de manera efectiva, se recomienda que el proveedor cree y facilite documentos
de control como:
Lista de control6 : este documento consiste en una lista de puntos que el

usuario debe evaluar, marcando o dejando vacío el punto correspondiente.
Evaluar cumplimiento de requerimientos: este documento detalla los
requerimientos que se deben evaluar. El usuario debe indicar si el
requerimiento ha sido cumplido o no, con base en los requerimientos iniciales
y las expectativas.
Documento de observaciones: En este documento el usuario tiene completa
libertad para exponer sus observaciones con respecto al módulo que se haya
probado.
El usuario podrá dar su opinión detallada o más directa dependiendo del

documento, acerca del avance, lo cual servirá como retroalimentación para el
proveedor.
En estas pruebas el proveedor es un guía y no debe influir en el usuario sobre
cómo utilizar el sistema. El proveedor no debe indicar acciones que conduzcan
al usuario por una ruta determinada, y el usuario debe ser quien decida qué
características utilizar. Esto es la clave para generar retroalimentación de valor
para el proveedor.
5. Discusión y conclusiones
Los problemas que han sido mencionados en este trabajo de investigación
son conocidos por la mayoría de gerentes y administradores relacionados con
los procesos de contratación del desarrollo de sistemas de software. Sin embargo,
estos problemas no han sido abordados con la amplitud y profundidad requerida.
Lo anterior se puede deducir del análisis bibliográfico que se llevó a cabo y la
constante preocupación mostrada por los autores de los trabajos estudiados.
El análisis de la bibliografía ayudó a determinar que algunas de las
metodologías ágiles que se utilizan de forma más frecuente, permiten gestionar la
relación con terceros de mejor manera que como se lleva a cabo tradicionalmente.
Sin embargo, es posible mencionar que en diferentes aspectos estas metodologías
no son eficientes. Por lo tanto, la guía propuesta tiene como fin combinar las
principales fortalezas en cuanto a la gestión de la relación con terceros de las
metodologías que fueron analizadas.
La guía tomó en cuenta las características particulares de cada una de las
metodologías, y fue elaborada con base en la evidencia del éxito que han tenido
en la práctica. La estructura de la guía es flexible ante las necesidades que pueda
Referencias 33
tener el cliente, debido a que la implementación de cada uno de los puntos no

es obligatoria, porque el escenario de cada empresa no es el mismo. Así, cuando
una empresa tiene problemas de comunicación con el proveedor, puede tomar
en cuenta las recomendaciones que se brindan para esa área. Si por otra parte,
el problema al que se enfrenta la empresa tiene relación con la definición del
alcance del proyecto, puede revisar este apartado e implementar los puntos que
corresponden a esa sección, y de forma similar para cada área contemplada en
la guía.
Como consecuencia, la principal contribución de este trabajo consiste en la
propuesta de la guía para apoyar la gestión de las relaciones entre clientes y
proveedores, aunque conviene mencionar que la validación práctica de dicho
instrumento queda pendiente como un trabajo futuro de investigación.
Referencias
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W.,
Fowler, M., . . . Thomas, D. (2001). Manifiesto por el desarrollo Ágil
de software. Descargado de http://www.agilemanifesto.org/iso/es/
Bersin, J. (2005). Business process outsourcing: Pros and cons. Chief Learning
Officer , 4 (4), 34 - 40. Descargado de http://search.ebscohost.com/
login.aspx?direct=true&db=buh&AN=16479531&lang=es&site=ehost
-live
Dolgui, A., y Proth, J.-M. (2013). Outsourcing: definitions and analysis.
International Journal of Production Research, 51 (23/24), 6769 - 6777.
Girotra, K., y Netessine, S. (2012, oct). Why apple has to manufacture
in china. Descargado de https://hbr.org/2012/10/why-apple-has-to
-manufacture-i
Kakumanu, P., y Portanova, A. (2006). Outsourcing: Its benefits, drawbacks
and other related issues. Journal of American Academy of Business,
Cambridge, 9 (2), 1 - 7.
Sáenz, J., Cámara, M. d. l., Calvo-Manzano, J. A. y Arcilla, M. (2014).
Necesitan los proveedores de outsourcing una metodología para la provisión
de servicios?: Is it needed a methodology for outsourcing service providers?
RISTI-Revista Ibérica de Sistemas e Tecnologias de Informação(SPE1),
61–75.
Smuts, H., van der Merwe, A., Kotzé, P. y Loock, M. (2010). Critical
success factors for information systems outsourcing management: A
software development lifecycle view. En Proceedings of the 2010 annual
research conference of the south african institute of computer scientists
and information technologists (pp. 304–313). New York, NY, USA: ACM.
Descargado de http://doi.acm.org/10.1145/1899503.1899537 doi:
10.1145/1899503.1899537
Definición y modelado del proceso de gestión de
la demanda para tecnología de información
David Rodolfo Camacho Quiros, Reagan Ching Fung,

Julio Córdoba Retana y Antonio González Torres∗
[dcamachoq046, rchingf302, jcordobar022]@ulacit.ed.cr
Resumen En la actualidad las organizaciones se ven en la necesidad

de utilizar mejores prácticas y recomendaciones, por lo que se utilizan
marcos de referencia reconocidos y probados. Por esta razón es de suma
importancia, identificar cuáles son las prácticas y marcos de referencia
que mejor se adaptan al giro de negocio de la organización, lo cual resulta,
en muchos casos, en metodologías híbridas que extraen lo mejor de cada
marco. En el presente artículo se presenta un modelo híbrido del proceso
de gestión de la demanda. La definición de dicho modelo como resultado
del análisis y comparación de los marcos de referencia ITIL versión 3 y
COBIT versión 5.
Palabras clave: COBIT5, ITILv3, gestión de la demanda, gestión de la

capacidad
1. Introducción
Las organizaciones realizan grandes inversiones en aplicaciones,
infraestructura y personal, con el fin de obtener ventajas competitivas en
el mercado, optimizar procesos, obtener mayores utilidades económicas o
disminuir los gastos en el corto o mediano plazo. De forma que para alinear y
disminuir las brechas que existen entre las áreas de negocio y las tecnologías
de la información (TI), las organizaciones necesitan implementar y mejorar los
procesos de gestión. Entre estos procesos se destaca la gestión de la demanda
de servicios de TI.
La gestión de la demanda de servicios de TI comprende desde las peticiones
de soporte que entran en una mesa de asistencia, hasta la solicitud de nuevas
aplicaciones o su modificación. Este proceso es el encargado de administrar y
garantizar la disponibilidad de los recursos o servicios que el área de TI brinda
a la organización, por lo que su implementación inadecuada o ausencia, provoca
que los proyectos de TI se vean impactados de forma negativa. Esto ocurre
Definición y modelado del proceso de gestión de la demanda para TI 35
cuando se carece de los recursos necesarios, debido a que los proyectos sufren
aumentos en los costos y la organización debe incurrir en el uso indiscriminado
de recursos e incrementar el presupuesto de los proyectos para compensar los
retrasos.
Para comprender el papel que desempeña la gestión de la demanda en las
organizaciones, este trabajo ofrecerá una guía sobre cómo se puede llevar a cabo
su implementación o mejora mediante la definición de un modelo de gestión de
la demanda. De acuerdo con lo anterior, se realiza una evaluación de los marcos
de referencia COBIT 5 e ITIL v3, con el fin de definir la gestión de la demanda,
identificar los procesos y actividades pertinentes a la gestión de la demanda, y
modelar el proceso mencionado. La tabla 1 muestra los procesos de los marcos
de referencia mencionados, que son tomados en cuenta para el desarrollo de este
trabajo.
Tabla 1: Procesos de marcos de referencia analizados

COBIT 5 ITIL v3
EDM04 - Asegurar la optimización de recursos Gestión de la demanda
BAI04 -Gestionar la disponibilidad y capacidad Gestión de la capacidad
En síntesis, este trabajo de investigación busca identificar un proceso básico,
que sirva como punto de partida para cualquier organización y como una
herramienta a nivel gerencial y operacional para la gestión del proceso de la
gestión de la demanda.
2. Marco teórico
2.1. Gestión de la demanda
La gestión de la demanda es un proceso presente en todas las organizaciones,
aunque no se encuentre identificado como tal o esté implementado de forma
errónea. En general, este proceso permite habilitar o poner en ejecución un
requerimiento del negocio, en donde se pueden tener varias fuentes que estén
haciendo la petición de dicho requerimiento, el cual puede ser sencillo o complejo.
Según la frecuencia y el impacto que se tenga sobre el negocio, cada petición
requiere que se le asigne un nivel de prioridad.
En este contexto, las solicitudes de cuentas de correo electrónico para los
usuarios nuevos de la organización son un ejemplo de la demanda de un servicio,
que requiere tener en consideración la capacidad de los servidores y el ancho de
banda de la organización.
La importancia de la gestión de la demanda radica en la consecución de
beneficios para los usuarios y la empresa. Por lo que es necesario que se tengan
en cuenta los pasos del ciclo de vida de la demanda, conforme con el nivel de
madurez de la gestión de la demanda (Alonso, Caro y Verdún, 2008).
De acuerdo con lo anterior, los departamentos de TI que definen y
administran de forma correcta el proceso de gestión de demanda pueden mejorar
36 Camacho et al.
los servicios que ofrecen. Esto conlleva la necesidad de determinar el grado de

madurez de dicho proceso y se recomienda el uso de ITIL v3 y COBIT 5.
Con respecto a la selección de un marco de referencia para la definición del
proceso de gestión de la demanda, es fundamental conocer los tres tipos de
demanda existentes (Alonso et al., 2008):
1. Estratégica: Este tipo de demanda es gestionada a través del portafolio de

proyectos y contempla la solicitud de nuevos programas para introducir
la innovación, y activar nuevos negocios, productos y servicios. Además,
representa una oportunidad para la organización debido a que se identifican
los objetivos estratégicos de cada unidad de negocio. Las solicitudes de esta
naturaleza son analizadas, clasificadas y priorizadas, teniendo en cuenta su
influencia en la toma de decisiones.
2. Táctica: Esta clase de demanda se gestiona por medio del portafolio de
servicios. Su principal foco es el portafolio de servicio, que brinda su atención
en el catálogo, para evaluar los flujos de trabajo y se ordena de acuerdo con
las prioridades de la organización, para efectos de aprobación y entrega.
3. Operacional: La demanda operacional es la que gestiona la construcción y
mantenimiento de la infraestructura de TI y tiene como función velar por
los servicios, tanto de software como de hardware así como cumplir con los
planes de mantenimiento y actualización.
2.2. Marcos de referencia: COBIT e ITIL

COBIT es un conjunto de mejores prácticas que proporcionan un marco
de trabajo con un enfoque táctico que está dirigido, principalmente, a los
administradores, gerentes, auditores y encargados o responsables del área de
TI (Muñoz-Serna y Martínez-Arias, 2012). Además, este marco de referencia es
utilizado como herramienta para satisfacer las necesidades del negocio y servir
como guía para los procesos y métricas de control.
COBIT versión 5 se compone de cinco dominios y treinta y siete procesos
que buscan brindar una serie de normas para el uso eficiente de los recursos. En
este punto es importante anotar que la aplicación de este marco de referencia
conlleva tiempo y esfuerzo, por lo que debido a las limitaciones de tiempo en la
realización de este trabajo, solo se estudian y analizan los siguientes procesos:
1. Asegurar la optimización de los recursos

2. Gestionar la disponibilidad y la capacidad
El proceso de Asegurar la optimización de los recursos se encuentra en el área

de Gobierno y pertenece al dominio evaluar, orientar y supervisar. Este proceso
se encarga de asegurar que se asigna la capacidad adecuada y suficiente (e.g.,
personas, procesos y tecnologías) para soportar de forma eficaz los objetivos de
la empresa, a un costo óptimo (Ministerio de Tecnologías de la Información
y las Comunicaciones, s.f.). Además, tiene como propósito asegurar que las
necesidades de recursos de la empresa sean cubiertas de forma adecuada, que
el coste de TI sea apropiado y que se pueda incrementar la probabilidad de

obtener beneficios así como la preparación para cambios futuros (ISACA, 2012).
En cuanto al proceso Gestionar la disponibilidad y la capacidad, se encuentra
en el área de Gestión y pertenece al dominio Construir, adquirir e implementar.
Este proceso se encarga de equilibrar las necesidades actuales y futuras de
disponibilidad, rendimiento y capacidad, con una provisión de servicio efectivo
en costos. Además, incluye la evaluación de las capacidades actuales, la previsión
de las necesidades futuras conforme con los requerimientos del negocio, el análisis
del impacto en el negocio y la evaluación del riesgo para planificar e implementar
acciones para alcanzar los requerimientos identificados. De forma adicional, tiene
como propósito mantener la disponibilidad del servicio, la gestión eficiente de los
recursos y la optimización del rendimiento de los sistemas mediante la predicción
del rendimiento futuro y los requerimientos de capacidad (ISACA, 2012).
ITIL es un marco de trabajo que busca apoyar a la gerencia y a los encargados
de las áreas de soporte de TI por medio de guías para agilizar las entregas de
servicios. Este marco proporciona mecanismos para aumentar la interacción entre
usuarios y clientes, con el fin mejorar la prestación y calidad de los servicios
(Ministerio de Tecnologías de la Información y las Comunicaciones, s.f.). La
versión 3 de ITIL divide el ciclo de vida de los servicios en cinco fases:
1. Estrategia
2. Diseño
3. Transición
4. Operación
5. Mejora
En este trabajo se profundiza en la fase de Estrategia, específicamente en el

proceso de la Gestión de la demanda y de forma complementaria en el proceso
de Gestión de la capacidad (fase de diseño).
El proceso Gestión de la Demanda se encarga de efectuar proyecciones,
regular los ciclos de consumo y adaptar la prestación de servicios a los picos
de mayor exigencia, para asegurar que se puedan seguir prestando de acuerdo
con tiempos y niveles de calidad aceptables (OSIATIS, 2015). Para esto es
fundamental analizar las actividades de la organización, a fin de extraer los
patrones de las actividades del negocio y prevenir cuáles servicios son o van a
ser demandados y planificar el alcance de los servicios necesarios y su prioridad
(Quevedo, 2009).
El proceso de la Gestión de la capacidad busca garantizar la capacidad
necesaria para soportar los servicios de TI de acuerdo con las necesidades de
la organización (OSIATIS, 2015). El fin de dicho proceso es que los recursos
tecnológicos estén disponibles cuando los usuarios así lo requieran. Para ello, es
indispensable que este proceso se encuentre alineado con el negocio, con el fin
de evitar la adquisición de recursos innecesarios. Por lo que se debe conocer el
estado actual de la organización y tener una visión clara sobre su rumbo.
La adecuada gestión de este proceso permite mejorar el rendimiento de los
recursos, planificar de forma adecuada el crecimiento en función al negocio,
38 Camacho et al.
reducir los gastos innecesarios por mantenimiento o adquisición de nuevos

dispositivos y reducir posibles incompatibilidades y fallas en la infraestructura
(ITIL vs COBIT , s.f.).
3. Metodología
El método que se utilizó para desarrollar, definir y modelar la propuesta del
proceso de Gestión de la demanda, se basó en el estudio de cada una de las
actividades que tienen los procesos seleccionados de COBIT 51 e ITIL v32 . De
acuerdo con ese estudio se realizó la correlación de los componentes específicos
y los marcos de referencia, con el fin de identificar similitudes y diferencias para
realizar el modelado.
4. Resultados y aportes
El principal aporte de este trabajo es un proceso híbrido que tiene en cuenta
las actividades de los marcos de referencias de ITIL v3 y COBIT 5 con respecto
a la Gestión de la demanda y está constituido por nueve actividades (véase la
Figura 1).
4.1. Descripción del proceso

Recopilación de información: El proceso propuesto inicia con la recopilación
de información3 , cuyo encargado de su ejecución es el departamento de TI.
Suministro de planes de negocio y requerimientos: Esta actividad tiene
por objetivo comprender e identificar las actividades del negocio y la forma
como estas inciden en la demanda de los servicios. Las fuentes de información
de esta actividad son los planes de negocio, planes de mercadeo, proyecciones
de ventas y solicitudes de nuevos requerimientos.
Análisis de documentos: Esta actividad debe ser desarrollada por el
departamento de TI4 y tiene como finalidad la identificación de los patrones
de las actividades del negocio, también conocidas como PBAs5 . Además de
identificar los PBA, esta actividad define los perfiles de los usuarios o UP6 ,
basándose en sus roles y responsabilidades en la organización.
1
EDM04 Asegurar la optimización de recursos y BAI04 Gestionar la disponibilidad
y capacidad.
2
Gestión de la demanda y Gestión de la capacidad
3
La recopilación de información es propuesta con base en el proceso Gestión de
demanda de ITIL v3.
4
El diseño de esta actividad se basó en ITIL v3, específicamente en el proceso Gestión
de demanda.
5
Patterns of Business Activity, por su acepción en inglés.
6
User Profile, en inglés.
Figura 1: Proceso de modelado de la gestión de la demanda.
40 Camacho et al.
Análisis de la definición y capacidad del servicio a nivel de recursos:

Esta actividad fue definida tomando como referencia COBIT 5 y los
siguientes procesos:
BAI04.02: Evaluar el impacto en el negocio de COBIT 5. Este proceso
busca identificar los servicios importantes para la empresa, relacionar
los servicios y recursos con los procesos de negocio e identificar las
dependencias del negocio.
BAI04.03: Planificar requisitos de servicios nuevos o modificados. En el
caso de este procesado está asociado con la planificación y priorización
de la disponibilidad, el rendimiento y la capacidad para realizar cambios
conforme con las necesidades del negocio y los requerimientos de servicio.
EDM04.02: Orientar la gestión de los recursos. Este proceso está
relacionado con la adopción de principios de gestión de recursos para
permitir el uso óptimo de los recursos de TI a lo largo de su ciclo de
vida.
Para esta actividad también se usó como referencia la actividad Gestión
basada en la demanda de ITIL v3 que busca asegurar que los planes de
negocio de los consumidores se encuentren sincronizados con el manejo de
los planes del servicio que los atiende. Con base en los patrones de demanda
se desarrolla la oferta, y se puede dividir en dos grandes grupos de servicios:
esenciales y de soporte. Con la definición anterior, se generan paquetes de
servicios específicos para los distintos grupos de clientes.
Evaluación de la disponibilidad de recursos: Esta actividad se basa en
el proceso BAI04.05 Investigar y abordar cuestiones de disponibilidad,
rendimiento y capacidad de COBIT 5, el cual permite abordar desviaciones
de los servicios investigando y resolviendo los problemas identificados en
relación con la disponibilidad, rendimiento y capacidad.
Aprobación de mejoras y puesta en marca: Si la capacidad del servicio,
con base en la disponibilidad de recursos, puede satisfacer la demanda, el
flujo continua con la actividad del proceso Aprobar mejoras y puesta en
marcha.
Solicitud de recursos: En caso de que la capacidad y los recursos no puedan
satisfacer la demanda, se procede a gestionar y solicitar los recursos. Dicha
solicitud se realiza al negocio, debido a que involucra al área financiera de la
organización y el desempeño del negocio.
Análisis de presupuesto: Si el negocio no aprueba la solicitud de recursos, de
debe de volver a realizar el análisis de la capacidad y los recursos que requiere
el servicio, de esta manera se puede replantear el alcance de la prestación
del servicio y ajustarlo al presupuesto con el que se cuenta en ese momento.
Evaluación periódica de capacidad y disponibilidad del servicio: Esta
actividad invoca a un subproceso para dar seguimiento a los servicios y sus
recursos, y se basa en tres procesos de COBIT 5:
BAI04.01: Evaluar la disponibilidad, rendimiento y capacidad actual y
crear una línea de referencia. Este proceso tiene como objetivo asegurar
la disponibilidad, capacidad y rendimiento de los servicios mediante su
evaluación.
BAI04.04: Supervisar y revisar la disponibilidad y la capacidad. En el

caso de este proceso, se enfoca en supervisar, medir, analizar, informar
y revisar la disponibilidad, el rendimiento y la capacidad; además de
identificar desviaciones respecto a las líneas de referencia establecidas
y revisar informes de análisis de tendencias identificando cualquier
problema o variación significativa para iniciar las acciones necesarias con
el fin de asegurar que se realiza el seguimiento de todos los problemas
pendientes.
EDM04.03: Supervisar la gestión de recursos. Este proceso indica que se
deben supervisar los objetivos y métricas claves de los procesos de gestión
de recursos, así como establecer la forma en que serán identificados y se
les dará seguimiento a las desviaciones o problemas.
La evaluación periódica de capacidad y disponibilidad del servicio también

se basó en el proceso Gestión de la capacidad de ITIL v3, el cual tiene relación
con el seguimiento y revisión de los informes de desempeño de los servicios
y componentes, además de reaccionar y ayudar en la solución de problemas
específicos de rendimiento, si se llegan a materializar.
Otro objetivo de esta actividad es suministrar información, con la cual se
pueda determinar si el nivel de demanda del servicio está sobre pasando la
capacidad si el servicio se encuentra subutilizado. Si el funcionamiento del
servicio es normal, se termina el flujo; en caso contrario, se procede a realizar
el análisis de la documentación del negocio para determinar si la capacidad de
los recursos está mal definida, si es necesario gestionar más recursos o se debe
incentivar a los usuarios para que utilicen el servicio.
5. Conclusiones
Los marcos de referencia ITIL v3 y COBIT 5 se complementan entre sí,
debido a que ambos apoyan el crecimiento de la organización y el mantenimiento
de los servicios. Lo anterior se confirmó con el desarrollo de este trabajo, el cual
llevó a cabo la correlación de información de ambos marcos de referencia y
permitió la definición de un proceso de gestión de la demanda.
Lo anterior permite afirmar que la utilización mixta de los marcos de
referencia en cuestión es factible y facilita el desarrollo de marcos de trabajo
ajustados a cada organización. Por ejemplo, COBIT es un marco de referencia
flexible y adaptable a cualquier organización, lo cual es uno de sus aspectos
esenciales, como quedó expuesto con el planteamiento del modelo con la gestión
de la demanda.
Cabe señalar que los insumos o documentación del negocio, a partir de la cual
se realiza la identificación de la demanda de los servicios, es de suma importancia,
porque sin estos no es posible conocer los servicios que se requieren, ni las salidas
y demandas esperadas.
En línea con lo anterior, es importante tener en cuenta que la evaluación
continua de los servicios es vital porque los requerimientos del negocio y el
42 Camacho et al.
entorno donde se desenvuelve la organización está en constante cambio, lo cual

requiere que la capacidad para satisfacer la demanda se ajuste a las necesidades
actuales.
Como trabajo futuro se recomienda evaluar el marco de referencia CMMi
para servicio, debido a que este se enfoca en la administración y entrega de los
servicios ofertados, lo cual es un producto del proceso de gestión de la demanda.
Para optimizar el proceso planteado en este trabajo, se requiere incorporar un
estudio de continuidad, y CMMi para servicios puede ofrecer el apoyo necesario
para optimizar el proceso.
Referencias
Alonso, I. A., Caro, E. T. y Verdún, J. C. (2008, dic). The importance of it
strategic demand management in achieving the objectives of the strategic
business planning. En International Conference on Computer Science and
Software Engineering, 2008 (Vol. 2, p. 235-238).
ISACA. (2012). COBIT 5: Procesos Catalizadores. Autor. Descargado de
www.isaca.org
ITIL vs COBIT. (s.f.). Descargado de http://www.cntec.mx/noticias/41/
122-itilvscobit.html
Ministerio de Tecnologías de la Información y las Comunicaciones. (s.f.). Marco
de referencia: arquitectura TI de Colombia.
Muñoz-Serna, R., y Martínez-Arias, M. A. (2012). Caracterización de procesos
de gestión de TI basados en COBIT 5 y mapeo con ISO27002, ITIL,
CMMI DEV, PMBOK, para la implementación en la industria editorial
colombiana, apoyando el proceso de transformación digital.
OSIATIS. (2015, dic). ITIL Foundation. Descargado de http://itilv3
.osiatis.es/
Quevedo, A. M. (2009, set). Implementación de una metodología de procesos para
la mejora de TI en una empresa. Universitat Politècnica de Catalunya.
Descargado de http://upcommons.upc.edu/handle/2099.1/7599
Recomendaciones para la gestión de incidencias
de tecnologías de la información
Verny Mora Jiménez, Paulo Viales Wahrmann, Julio Córdoba Retana y

Antonio González Torres∗
[vmor80@hotmail.com,pviales@gmail.com,jcordobar022]@ulacit.ed.cr
Resumen La gestión de incidencias es un proceso crítico en la

administración de los servicios de tecnologías de la información (TI),
por el impacto en las operaciones de las organizaciones y la relación que
se establece entre los usuarios y el departamento de TI. De acuerdo con
esto, este trabajo de investigación lleva a cabo el análisis de las principales
actividades asociadas, conforme con los marcos de referencia ITIL,
COBIT y CMMI, y propone un proceso para la gestión de incidencias.
El objetivo es apoyar a los administradores de TI en la definición e
implementación de la gestión de incidencias mediante la discusión de
la propuesta y el flujo de las tareas que componen el proceso.
Palabras clave: Gestión de Incidencias, ITIL, COBIT, CMMI
1. Introducción
En el contexto actual, las tecnologías de la información (TI) son un factor
crítico para el desempeño de las organizaciones, por lo que requieren el correcto
funcionamiento de los sistemas de hardware y software que utilizan. Esto
conlleva a que las incidencias1 que se presenten deban ser resueltas de forma
oportuna, tanto a usuarios internos como externos, por lo que es necesario que
las incidencias se gestionen de forma adecuada, para evitar que se transformen
en riesgos para la continuidad de la organización
En este punto resulta indispensable tener en cuenta que los servicios de TI
deben ofrecer servicios de calidad con alta disponibilidad; utilizar los recursos
de forma más eficiente; ayudar a incrementar la productividad de los usuarios;
reducir costos, tiempos de ejecución de procesos y riesgos; y alinearse a los
procesos del negocio. Sin embargo, los altos niveles de calidad de los servicios no
1
Se denomina como incidencia a un problema que sobreviene en la prestación de un
servicio que es soportado por hardware o software.
44 Mora et al.
se pueden alcanzar únicamente con fuertes inversiones en tecnología y personal

cualificado, sino que es necesario contar con una buena gestión y planificación a
nivel empresarial. Para esto, es recomendable implementar un sistema de gestión
de servicios de TI (SGSTI), potenciar la labor de los gestores y utilizar métricas
para el seguimiento y control de la resolución de incidencias (Bauset-Carbonell
y Rodenes-Adam, 2013; Mutafelija y Stromberg, 2008).
También es conveniente tener en cuenta que la gestión de incidencias,
además del impacto que tiene en la organización, determina la relación de los
departamentos de TI con los usuarios, y en cierta forma se convierte en un reflejo
de la calidad de los servicios que estos ofrecen. Cabe resaltar que la calidad de los
servicios implica tanto el nivel de efectividad de la resolución de los problemas
como la forma en que el servicio es percibido por los usuarios y el resto de la
organización (Persse, 2013).
De acuerdo con la experiencia de los autores, un gran número de
organizaciones no aplican las mejores prácticas de la industria para la gestión
de incidencias, en algunos casos por desconocimiento y en otros por que no le
brindan la importancia necesaria. Tomando en cuenta lo anterior, en este trabajo
se estudian y analizan los lineamientos y mejores prácticas que son recomendadas
por COBIT, ITIL y CMMI, con el fin de proponer un proceso y una lista de
recomendaciones que sirvan como guía para realizar la gestión de incidencias en
servicios de TI. Dicho proceso pretende contribuir con la detección oportuna de
desviaciones en los procedimientos, la correcta clasificación de las incidencias, la
utilización de procedimientos de escalado y el cierre adecuado de las incidencias.
El fin de este planteamiento es contribuir con la mejora de los porcentajes de
efectividad en la resolución de incidencias de las organizaciones, en un plazo no
mayor de un año de la puesta en marcha del proceso.
2. Marco teórico
Una incidencia es un evento que implica la interrupción no planificada o la
reducción de la calidad de un servicio de TI, el cual es soportado por elementos
de hardware o software (ITIL Foundation, 2011). Las incidencias pueden ser
detectadas por el personal técnico, reportadas por herramientas de seguimiento
de eventos, comunicadas por los usuarios de forma telefónica o mediante un
sistema de incidencias o informadas por terceros (e.g., proveedores y socios de
negocio2 ). En tanto, la gestión de las incidencias es el proceso responsable de
administrar el ciclo de vida de cada incidencia (Persse, 2013).
La gestión de incidencias requiere brindar respuesta oportuna y efectiva a las
peticiones de los usuarios relacionadas con la resolución de problemas asociados
a los servicios de TI, con el fin de no afectar los procesos de la organización
y cumplir con los compromisos con terceros (Forrester, Buteau y Shrum,
2011). En términos generales, este proceso contempla registrar las peticiones de
servicio, diagnosticar el problema de forma precisa (i.e., identificar y describir
2
Conocidos como partners, por su acepción en inglés.
Recomendaciones para la gestión de incidencias de TI 45
los síntomas de las incidencias, así como asignar los recursos necesarios para
su resolución), determinar la prioridad de la incidencia, resolver las incidencias
(i.e., determinar las posibles causas, efectuar escalaciones y recuperar el servicio,
en caso necesario), documentar y registrar de forma exhaustiva la resolución de
la incidencia, cerrar las incidencias y mantener un registro histórico (véase los
procesos DSS02 y DSS03 de COBIT 5) (ISACA, 2012; O’Toole, 2015).
El registro de las peticiones de servicio requiere verificar que estas cumplan
con los criterios mínimos establecidos y que los usuarios que las realizan estén
debidamente autorizados. Cada incidencia debe contar con un número único de
referencia, hora y fecha de registro, identificación de la persona que realizó el
registro de la incidencia, método de notificaciones del estado de la incidencia y
descripción de los síntomas.
En cuanto al diagnóstico, es necesario contar con toda la información
disponible para efectuar una mejor evaluación del problema para efectuar su
categorización, determinar el impacto en el negocio (i.e., nivel de pérdida
financiera, el posible efecto en la reputación del negocio y las regulaciones
del país) y la urgencia de su resolución, efectuar una correcta asignación de
la prioridad, obtener la aprobación financiera y si se requiere, el cambio de
procedimientos o estándares.
Como parte de este proceso, se requiere utilizar la base de datos de
conocimiento, si existe, para determinar si el problema está asociado a un error
conocido, o si este ha sido resuelto anteriormente. Este paso se debe efectuar
antes de asignar a un especialista para realizar un análisis de mayor profundidad
o que se lleven a cabo acciones para restaurar los servicios afectados, con ayuda
de otros especialistas.
En los casos en los que la incidencia es reportada por teléfono, se recomienda
efectuar un diagnóstico inicial e intentar ofrecer una solución de forma inmediata,
trabajando junto con el usuario, si es factible. Si no es posible ofrecer una solución
inmediata, entonces se debe informar al interesado sobre el procedimiento que
se seguirá, y darle un número de incidencia para que le pueda dar seguimiento.
En lo que respecta a la resolución de incidencias, conviene tener en cuenta la
posibilidad de seguir el procedimiento para efectuar el escalado de la incidencia.
Este tipo de procedimiento usualmente contempla el escalado funcional (se
solicita el apoyo de un especialista de más alto nivel para resolver el problema) o
jerárquico (se acude a un responsable de mayor autoridad para tomar decisiones
por encima del nivel del personal técnico involucrado, como la asignación de
recursos adicionales para la resolución de la incidencia).
En todo caso, es recomendable resolver cada incidencia en el menor tiempo
posible, para restaurar o normalizar el servicio y salvaguardar los intereses de
la organización. Además, es necesario que en el transcurso de la resolución se
le brinde seguimiento al estado de las incidencias hasta que se realice el cierre
de esta. El proceso de seguimiento involucra documentar y revisar las acciones
realizadas, escalar las incidencias según se requiera y comunicar el estado de la
incidencia a las partes interesadas.
46 Mora et al.
En el transcurso de la resolución de una incidencia puede ser necesario

efectuar procedimientos de recuperación de los servicios, los cuales dependerán
de la naturaleza de esta, y podrían involucrar la participación activa del usuario
en la realización de actividades concretas; de forma similar se podría requerir
la participación de otros especialistas e incluso de consultores o proveedores
externos.
Una vez que la incidencia ha sido resuelta, se deben hacer las comprobaciones
necesarias con el usuario para cerrar el caso, medir la satisfacción, tener en
cuenta los requerimientos de informes de las partes interesadas en la gestión de
incidencias y utilizar criterios de calidad del servicio (Forrester et al., 2011).
El cierre de la incidencia debe contemplar la documentación de las actividades
que se realizaron para resolverla, la fecha de resolución, la categoría de cierre, la
fecha en que se está efectuando el cierre y la resolución de las causas subyacentes
a la incidencia (Kenett y Baker, 2010). Además, se requiere documentar
las soluciones identificadas, registrar si se usaron soluciones temporales o
acciones de recuperación de servicios, determinar las acciones incorrectas que
se llevaron a cabo y comprender el proceso que se siguió durante la resolución.
Esta información permite efectuar el análisis, evaluación y clasificación de
incidencias para establecer tendencias, encontrar patrones de asuntos recurrentes
e infracciones a los procedimientos, reducir la ocurrencia de incidencias similares
en el futuro, mejorar su resolución y apoyar la búsqueda de mejores prácticas.
3. Proceso para la gestión de incidencias

La definición de un proceso para la gestión de incidencias requiere que,
en primer lugar, se determinen de forma clara las políticas, procedimientos
y definiciones que serán considerados por este. Conforme con lo anterior, se
recomienda tomar en cuenta los elementos que se presentan en la siguiente lista.
Definición de una incidencia: Es necesario diferenciar de forma clara entre

una incidencia y una solicitud de servicio. Una incidencia es la interrupción
no planificada o la reducción de la calidad de un servicio de TI. Si bien
las solicitudes de servicio deben ser reportadas de forma similar que las
incidencias a la mesa de servicio, la diferencia es que estas no representan la
interrupción de un servicio (ITIL Foundation, 2011).
Categorías: La definición de categorías es otro elemento fundamental en
la gestión de incidencias, para ubicar y asignar los recursos humanos y
materiales de forma correcta cuando una incidencia es reportada. Sobre este
particular, tanto ITIL como CMMI ofrecen recomendaciones para realizar
un catálogo de categorías de incidencias (ITIL Foundation, 2011; Forrester
et al., 2011). Como recomendación, se sugiere realizar una lluvia de ideas
con el personal involucrado en la gestión de incidencias (e.g., los técnicos
de soporte, supervisores de gestión de incidencias y administradores), para
crear una lista preliminar de categorías, que se ponga a prueba por un periodo
corto de tiempo. De forma posterior, se recomienda analizar las incidencias
reportadas durante un periodo de tiempo para afinar la lista de categorías

de incidencias.
Como buena práctica, el catálogo de categorías debe ser analizado de forma
periódica, cada 3 o 5 meses, para realizar actualizaciones y mantenerlo
adecuado a las necesidades del negocio.
Responsable de incidencias: La asignación de responsabilidades es otro
elemento a tener en cuenta. En este aspecto, tanto COBIT (IT Governance
Institute, 2013) como CMMI (Forrester et al., 2011) especifican varios
lineamientos importantes. En general, es necesario especificar cuáles son
las responsabilidades del técnico al que se le asigna una incidencia, así
como quién es el responsable de supervisar, dar seguimiento al estado de
las incidencias, efectuar los procesos de escalado y realizar la transferencia
de responsabilidades entre pasos o procesos.
Asignación de prioridad: La resolución de las incidencias requiere contar con
diferentes niveles de prioridad, en función de la relevancia e impacto en el
negocio. De acuerdo con el análisis de COBIT 5, ITIL y CMMI se recomienda
el uso de 5 niveles de prioridad usando valores numéricos (e.g., 1 a 5) o
categóricos (baja, media, alta, grave, crítica).
Reporte de incidencias: Es importante definir de forma clara los mecanismos
para el reporte y seguimiento de las incidencias, sin importar si se realiza
de forma manual o automatizada. En todo caso, las personas que reportan
las incidencias deben encontrarse autorizadas, exceptuando los casos en que
se demuestre que peligra la vida de las personas o que la continuidad del
negocio está siendo afectada.
En general, se recomienda contar con un sistema que facilite el reporte de
incidencias a los usuarios (Forrester et al., 2011), la actualización de los
estados (e.g., abierta, en progreso, resuelta y cerrada) (ITIL Foundation,
2011) y seguimiento de las acciones realizadas durante el ciclo de vida de las
incidencias.
Reapertura de incidencias: En algunos casos es posible que una incidencia
no haya sido resuelta por completo y sea necesario reabrirla, por lo que
se requiere definir las reglas para reabrir incidencias, asignarles una nueva
categoría y prioridad, y determinar quién será el responsable que trabajará
en la solución.
En general, los modelos relacionados con la gestión de las tecnologías de la

información coinciden en cuanto a las principales tareas que requiere el proceso
de gestión de incidencias, siendo esas tareas las siguientes:
1. Registro de incidencias.
2. Resolución de incidencias.
3. Cierre de incidencias.
4. Seguimiento y análisis de incidencias.
En consecuencia, este trabajo ha tomado en cuenta la lista de tareas

enunciadas y las mejores prácticas de COBIT (IT Governance Institute, 2013),
48 Mora et al.
ITIL (ITIL Foundation, 2011) y CMMI (Forrester et al., 2011), para proponer
el proceso que se muestra en la figura 1. Las tareas ordinarias de dicho proceso
son representadas por cajas rectangulares y las decisiones por rombos, en tanto
que las líneas de color rojo indican el flujo ordinario de las tareas y las líneas
punteadas de color negro muestran la secuencia alternativa, en donde el flujo
puede seguir uno u otro camino con base en las decisiones que se han tomado.
El proceso propuesto comienza con la identificación de las incidencias por
parte de los usuarios de la organización o los miembros del departamento de
TI (i.e., por observación en el campo o por medio del uso de sistemas para
ese propósito). Una vez que la incidencia ha sido identificada, se procede a
registrarla, para luego efectuar el diagnóstico (i.e., de forma opcional se puede
usar la base de conocimientos), categorización y asignación de prioridad. Con
base en el diagnóstico, se determina si la resolución de la incidencia requiere
recursos extraordinarios, y en caso necesario se solicita la aprobación de esos
recursos al comité ejecutivo. A partir de ese punto, se inicia la recuperación de
servicios (cuando se requiera) y la resolución de la incidencia.
Cuando la incidencia ha sido resuelta, de acuerdo con el personal técnico,
se realizan las pruebas técnicas necesarias para validar la resolución. En caso
de que la incidencia se haya resuelto de forma efectiva, se hace la verificación
y aceptación de la solución con el usuario. Sin embargo, cuando la incidencia
no ha sido resuelta, se verifica si el personal técnico a cargo puede terminar de
solucionarla o si es necesario solicitar el escalado de la incidencia. En caso de que
sea necesario escalar la incidencia, se determina si el escalado que se requiere es
funcional o jerárquico. Cuando el proceso de escalado ha terminado, se verifica
si la incidencia ha sido resuelta, y si es así, se procede a realizar la verificación y
aceptación con el usuario. En caso de que la incidencia no haya sido resuelta tras
el proceso de escalado, se determina si el equipo de la mesa de servicio puede
terminar de resolverla o si es necesario volver a seguir el proceso de escalado.
Una vez que la resolución de la incidencia ha sido resuelta de forma definitiva,
tras efectuar la verificación y aceptación con el usuario, se procede a cerrarla y
documentarla.
La descripción de cada una de las tareas que conforman el proceso propuesto
se detalla a continuación.
Identificación de incidencias: En un escenario ideal, se brinda seguimiento

constante a los recursos y servicios críticos de la organización para prevenir la
ocurrencia de incidencias o bien, un gran número de incidencias es detectado
por el departamento de TI en el momento en que se presentan, incluso antes
de que los usuarios se den cuenta de los eventos. Sin embargo, como muestra
la figura 1, la identificación de las incidencias, por lo general, es realizada
tanto por los usuarios de la organización como por el departamento de TI.
Recomendaciones para la gestión de incidencias de TI
Figura 1: Proceso para la gestión de incidencias de tecnologías de la información.
49
50 Mora et al.
Registro de incidencias: El proceso para registrar las incidencias debe poner

a disposición de los usuarios autorizados tantos medios como sea posible,
incluyendo llamadas telefónicas, registro web y mensajería instantánea.
Cabe recalcar que tanto el reporte como el registro de incidencias debe
ser efectuado por usuarios que se encuentren autorizados, conforme a lo
establecido por las políticas y reglamentos de la organización.
Algunos de los principales elementos de información para registrar una
incidencia son los siguientes:
1. Nombre de quien registra y quien reporta la incidencia
2. Datos de contacto
3. Descripción detallada de la incidencia
4. Fecha y hora del reporte (tomada por el sistema)
5. Número de referencia (generado por el sistema)
6. Prioridad y categoría inicial (ingresada por quien registra la incidencia)
7. Notas sobre el impacto en el negocio
Diagnóstico, categorización y prioridad: El diagnóstico, dependiendo de
la naturaleza de la incidencia, se puede realizar de forma paralela a su
registro. En algunos casos es posible que durante este proceso, con asistencia
de una base de datos de conocimiento, el problema sea solucionado por
el usuario que está efectuando el reporte o por quien está registrando
la incidencia (e.g., también es posible que la incidencia sea resuelta al
momento de hacer el diagnóstico, en el momento en que se recibe el
reporte por teléfono). Pero también en algunos casos, podría ser necesario
solicitar aprobación para proceder, por razones financieras, de riesgo en los
procedimientos o para solicitar apoyo adicional de otras áreas. En todo caso,
en esta etapa del proceso debe asignar la categoría y prioridad definitiva a
la incidencia, en función del tipo de incidencia, urgencia e impacto.
Autoayuda- BD conocimiento: Los sistemas modernos de gestión de
incidencias utilizan el registro histórico de las incidencias, y toda la
información relacionada con el seguimiento, para crear bases de datos de
conocimiento que orientan al usuario sobre las posibles acciones que pueden
seguir para resolver las incidencias por su cuenta. antes de realizar un reporte.
De forma similar, este tipo de sistemas permite que los técnicos realicen los
diagnósticos y resolución de incidencias de forma más efectiva, por medio
de información relacionada con casos similares que han sido resueltos. En el
caso del proceso propuesto, esta actividad se encuentra ligada al diagnóstico,
categorización y asignación de prioridad a las incidencias, así como a la
recuperación y resolución de la incidencia, tomando en cuenta lo anterior.
Aprobación del comité ejecutivo: Cuando se considera que es necesario
utilizar recursos o procedimientos extraordinarios para la resolución de una
incidencia, se debe contar con la aprobación del comité ejecutivo. Toda
aprobación debe ser documentada en formato papel o digital, y se debe
evidenciar la firma del responsable del comité (i.e., se recomienda el uso de
firma digital).
Recuperación y resolución de incidencias: Para realizar esta tarea, la
mesa de servicio debe contar con el personal capacitado y herramientas para
determinar el mejor curso de acción para la resolución de la incidencia. Entre

las tareas que pueden ser necesarias durante la resolución de las incidencias
se encuentran las siguientes:
1. Realizar la recuperación de uno o varios servicios asociados.
2. Efectuar el reemplazo de equipos, dispositivos o partes (i.e., en algunas
ocasiones puede ser necesario cambiar los estándares sobre características
de equipos de la empresa para resolver una incidencia).
3. Cambiar procedimientos internos o utilizar procedimientos
extraordinarios.
4. Solicitar personal de otras áreas o personal adicional.
5. Revisar las bitácoras y acciones que fueron realizadas antes y después de
reportada la incidencia. Esto tiene como fin determinar los cambios que
han sufrido tanto el servicio afectado como otros servicios asociados, así
como determinar cuáles acciones adicionales pueden ser requeridas.
Escalado de incidencias: En el transcurso de la resolución de incidencias, es
frecuente que cuando no pueden ser resueltas por la mesa de servicio, se
recurra a los procedimientos de escalado.
Las reglas de escalado y gestión de incidencias deben encontrarse
especificadas en las políticas, procedimientos o acuerdos formulados por la
organización (e.g., acuerdo de nivel de servicio, acuerdo de nivel operacional
y contrato de apoyo) con los grupos de apoyo internos y externos. En el
caso concreto de este trabajo, se toman en cuenta el escalado funcional y
jerárquico (ITIL Foundation, 2011), como se muestran en la Figura 1 y es
descrito a continuación.
Escalado funcional: Este tipo de escalado es utilizado para resolver una
incidencia de forma apropiada, en el tiempo requerido, y tiene como fin
apoyar al grupo que tiene a cargo una incidencia cuya complejidad y
prioridad demanda la participación de otros grupos con un nivel más
alto de especialización, experiencia y capacitación. Los grupos de apoyo
pueden ser internos o externos, como proveedores de software, fabricantes
de hardware o personal de mantenimiento.
Por lo general, la mesa de servicio es la encargada de escalar las
incidencias al nivel funcional apropiado, pero se recomienda que sea la
responsable de darles seguimiento, mantener informados a los usuarios
y efectuar el cierre de estas, sin importar el grupo al que hayan sido
referidas para su resolución.
Escalado jerárquico: Este tipo de escalado se realiza cuando es necesario
que los mandos superiores estén al tanto de la situación por el impacto
en el negocio, cuando se requiere su apoyo para coordinar con otros
departamentos o es necesario contar con recursos adicionales, internos o
externos.
Verificación y aceptación: Cuando la incidencia ha sido resuelta, la mesa de
servicio procede a realizar la verificación, junto con los usuarios afectados,
de que el problema se ha solucionado de forma satisfactoria. Si el usuario
acepta la resolución de la incidencia, se efectúa el cierre y documentación,
52 Mora et al.
de lo contrario, se procede a trabajar en los aspectos necesarios para resolver

la incidencia a satisfacción del usuario.
Cierre y documentación: El cierre y documentación de una incidencia
concluye el ciclo de gestión de incidencias, para una incidencia en particular.
Sin embargo, la gestión de incidencias es un proceso continuo que comprende
la resolución de las incidencias, la documentación de todas las acciones
realizadas y el uso de la información que se genera para obtener conocimiento
que permita mejorar la atención de lo usuarios. De acuerdo con lo anterior, el
cierre de la incidencia requiere verificar y corregir, si es el caso, la categoría
y prioridad asignada, y la documentación de las tareas realizadas.
Aunque algunas organizaciones implementan mecanismos para el cierre
automático de incidencias después de un determinado periodo de tiempo, en
este trabajo se recomienda que el cierre de las incidencias sea realizado de
forma explícita por la mesa de servicio. El cierre automático de las incidencias
no es adecuado porque puede ocasionar distorsiones sobre las incidencias que
han sido resueltas de forma satisfactoria y las que se pueden haber dejado
en el olvido por su baja prioridad.
El seguimiento de las incidencias es una tarea que se encuentra presente en

todo el proceso de gestión de incidencias. Es preciso registrar todos los detalles
de las acciones que se realizan en torno a las incidencias (Forrester et al., 2011;
ITIL Foundation, 2011) y contar con las herramientas apropiadas para alertar
al personal técnico cuando sea necesario, y también para brindarles información
constante sobre el estado de las incidencias, así como sobre las interrelaciones e
interacciones que tienen entre sí.
De forma posterior al cierre de las incidencias, se deben estudiar y analizar
los problemas recurrentes, su naturaleza y causa. Además, se recomienda
determinar, con los grupos de soporte involucrados, si las causas de este tipo
de incidencias han sido resueltas, y la posibilidad de que se vuelvan a presentar
otras incidencias relacionadas con esas mismas causas. Esto tiene como fin, tomar
medidas para eliminar o reducir el número de incidencias por una misma causa.
Un elemento de gran importancia en este proceso es asegurar la satisfacción
de los usuarios, por lo que se recomienda efectuar encuestas (por medio de correo
o teléfono) para determinar su nivel de satisfacción con los servicios de gestión
de incidecias y tomar las medidas necesarias para corregir los problemas que se
detecten. En línea con esto, es necesario contar con una política y procedimientos
claros en torno a la reapertura de incidencias, en caso necesario, por lo que es
importante que se brinde capacitación constante a todo el personal de la mesa
de servicio, tanto sobre aspectos técnicos como de procedimientos y servicio al
cliente.
4. Conclusiones
Las organizaciones se enfrentan a retos diversos que requieren el uso de
las mejores prácticas existentes, sobre todo cuando se trata de la gestión de
Referencias 53
incidencias de TI, por la alta dependencia que tienen sus actividades de los
sistemas de hardware y software. Por eso, la definición de un proceso de gestión
de incidencias con base en los marcos de referencia COBIT, ITIL y CCMI es
de gran importancia. Sin embargo, es importante considerar que la definición
de un proceso de esa naturaleza debe tomar en cuenta las particularidades de
cada organización con respecto a metas, objetivos y recursos. Conforme con lo
anterior, el fin de este trabajo ha sido orientar a los administradores de TI en
la definición del proceso de gestión de incidencias, mediante la propuesta de un
proceso basado en las mejores prácticas de los marcos de referencia mencionados.
La definición de un proceso de gestión de incidencias requiere estudiar en
detalle cada organización y analizar los servicios de TI con los cuales cuenta.
En general, para implementar de forma exitosa y eficiente un proceso de esta
naturaleza, es necesario comprender los procesos de negocio y la forma en que
son soportados por los servicios de TI, para definir de forma adecuada las tareas
y actividades que se requieren. En todo caso, cuando el número de servicios es
reducido, o cuando estos no son complejos, no es necesario definir un proceso
complejo o costoso.
El uso de bibliografía complementaria para definir y justificar la definición
e implantación de un proceso de gestión de incidencias, adaptado a las
necesidades de la organización, puede ser de gran ayuda. En la literatura
se encuentra documentado que el uso de buenas prácticas ayuda a eliminar
el trabajo redundante; mejora los tiempos de respuesta (i.e., indicadores de
soporte al negocio); y contribuye con la definición de departamentos de TI
mejor estructurados, más eficientes y enfocados en los objetivos de la empresa
(Herold, 2007). No obstante, las justificaciones basadas en la literatura (e.g.,
modelos de referencia, y casos de estudio) suelen ser insuficientes, porque es
necesario justificar con evidencia sustancial la razón costo/beneficio, ante la
administración. Además, se debe tener en cuenta que la divulgación, aceptación y
reconocimiento del proceso por parte de la organización toma tiempo y recursos
(Quesnel, 2012). Por esa razón, podría ser necesario implementar un plan piloto
que permita demostrar el impacto del proceso cuando se presentan incidencias
que implican la interrupción de servicios en departamentos estratégicos.
Finalmente, cabe mencionar que los marcos de referencia, aunque tienen
objetivos similares, sugieren estrategias diferentes para alcanzarlos. Por ejemplo,
las organizaciones con un nivel de madurez bajo, pueden utilizar ITIL como
referencia, debido al grado de detalle que ofrece y el enfoque orientado a tomar
en cuenta los factores internos de cada entidad. Por su parte, CMMI puede ser
usado por empresas con un nivel de madurez más alto, con mayor experiencia en
la gestión de incidencias y el uso de buenas prácticas. Lo anterior, debido a que
ofrece recomendaciones (e.g., implementar sistemas de software para la gestión
de incidencias) que no se adaptan a organizaciones con niveles de madurez bajo.
Referencias
Bauset-Carbonell, M. C., y Rodenes-Adam, M. (2013, jan). Gestión de los
54 Mora et al.
servicios de tecnologías de la información: modelo de aporte de valor basado

en itil e iso/iec 20000. El profesional de la información, 22 (1).
Forrester, E., Buteau, B. y Shrum, S. (2011). CMMI for services: Guidelines
for superior service. Pearson Education.
Herold, R. (2007). The shortcut guide to improving it service support through
itil. Realtimepublishers.com.
ISACA. (2012). COBIT 5: Procesos Catalizadores. Autor. Descargado de
www.isaca.org
IT Governance Institute. (2013). Cobit 5. Rolling Meadows.
ITIL Foundation. (2011, Julio). Itil v3 2011. Descargado de http://itilv3
.osiatis.es/
Kenett, R., y Baker, E. (2010). Process improvement and cmmi® for systems
and software. CRC Press.
Mutafelija, B., y Stromberg, H. (2008). Process improvement with cmmi® v1.2
and iso standards. CRC Press.
O’Toole, D. (2015). Incident management for i.t. departments. On Demand
Publishing, LLC-Create Space.
Persse, J. (2013). The it service management process manual. van Haren
Publishing.
Quesnel, J. (2012). Entender itil 2011: Normas y mejores prácticas para avanzar
hacia iso 20000. Éd. ENI.
Diseño de una arquitectura para la comunicación
entre protocolos en internet de las cosas
Marco Córdoba Padilla, Frank Trejos Moya, Fernando Chinchilla Jiménez y

[mcordobap487,ftrejosm824,fchinchillaj980]@ulacit.ed.cr
Resumen El uso de internet y las tecnologías relacionadas se ha

incrementado con el paso del tiempo. En ese contexto, internet de las
cosas (IoT ) ha entrado a jugar un papel de importancia con una gran
cantidad de dispositivos y aplicaciones para ofrecer servicios y soluciones
novedosas, que en muchos casos están atadas a protocolos y fabricantes
particulares. De forma que la principal riqueza de IoT (la variedad
de dispositivos, protocolos y fabricantes) se ha convertido en el mayor
reto para garantizar la utilidad máxima de las posibilidades detrás
de este concepto. La diversidad de IoT permite solucionar problemas
de diferentes maneras, con costos y calidad variable, pero introduce
dificultades relacionadas con la compatibilidad cuando se intentan
realizar combinaciones específicas para resolver problemas particulares.
Ante este escenario, el objetivo de este trabajo de investigación es
proponer el diseño de una arquitectura de bajo costo basada en
una puerta de enlace para facilitar la interconexión de dispositivos y
protocolos diversos. Con ese fin se lleva a cabo la discusión sobre los
diferentes elementos que componen la arquitectura de un sistema IoT, se
estudian los principios de las puertas de enlace, se realiza la propuesta
del diseño y se presenta un posible escenario de uso.
Palabras clave: internet de las cosas, protocolos, comunicaciones
1. Introducción
En años recientes ha surgido un gran número de dispositivos que se
caracterizan por sus excelentes capacidades de comunicación, bajo costo y
consumo energético, y sus capacidades reducidas tanto de procesamiento como
de almacenamiento. Estos dispositivos han sido agrupados bajo el concepto
de internet de las cosas1 y se usan en áreas tan diversas como el transporte,
1
El término internet de las Cosas se deriva de Internet of Things en inglés y se asocia
con las siglas IoT.
56 Córdoba et al.
la seguridad, la salud, el seguimiento de los signos vitales de las personas, la

inteligencia ambiental, la iluminación, el control de la temperatura de edificios y
el acceso a áreas restringidas. En general, su uso está ligado con la búsqueda de
mejoras a los procesos de las organizaciones y la calidad de vida de las personas.
Conforme el concepto de internet de las cosas (Ashton, 2009) ha tomado
fuerza en años recientes, han surgido de forma masiva tanto fabricantes
como nuevos dispositivos. A finales del 2015, el número de desarrolladores de
aplicaciones y soluciones de IoT superó los 6, 2 millones (Rana, 2016), y mostró
un crecimiento del 34 % con respecto al año anterior. Este crecimiento ha sido
empujado por la caída en los costos de los dispositivos y el acceso a internet.
Lo anterior, ha impulsado la rápida evolución de nuevas tecnologías, pero
ha originado problemas de integración e interconexión entre los dispositivos
producidos por diferentes fabricantes, debido a la ausencia de un protocolo
o pila de protocolos dominante, como el caso de TCP/IP en las redes
tradicionales2 . A esto también ha contribuido la necesidad de desarrollar
dispositivos especializados con características propias y diferenciadas, para
resolver problemas particulares y complejos que, por lo general, requieren el
uso de dispositivos de varios fabricantes.
Como parte de los esfuerzos que realizan los fabricantes para lograr mayor
capacidad de interconexión, se han establecido varias alianzas para impulsar el
desarrollo y crecimiento de IoT a través de la investigación y creación de nuevos
productos. Tal es el caso de Z-Wave Alliance (The Z-Wave Alliance, 2016), la
cual impulsa el desarrollo del protocolo con el mismo nombre, y que desde su
establecimiento en el 2005 ha incorporado a 375 compañías. Otro caso similar es
la alianza (ZigBee Alliance, 2016) de fabricantes de dispositivos que utilizan el
protocolo inalámbrico ZigBee, y que es conformada por más de 400 compañías
que utilizan dicho protocolo.
Sin embargo, la necesidad de realizar diseños en los cuales conviven e
interactúan diferentes protocolos en un mismo sistema IoT sigue siendo una
prioridad, porque la interoperabilidad entre estos (Manyika et al., 2016) puede
contribuir a generar ingresos adicionales a la industria por un 40 %.
Este trabajo propone un diseño para que los protocolos más utilizados en
IoT puedan comunicarse usando una arquitectura basada en una puerta de
enlace3 , por lo que el principal aporte del trabajo realizado es la propuesta de una
arquitectura de bajo costo para comunicar dispositivos y protocolos heterogéneos
en el contexto de IoT.
Como consecuencia, la sección 2 analiza los principales elementos de una
arquitectura de IoT, discute los conceptos relacionados con la interconexión entre
dispositivos y estudia los fundamentos de las puertas de enlace. Con base en la
información presentada en la sección 2, la sección 3 presenta el diseño de una
2
Los dispositivos de internet de las cosas, en su mayoría, utilizan protocolos simples
que requieren contar con menos capacidad de procesamiento y consumo de energía
que los dispositivos que utilizan TCP/IP.
3
Las puertas de enlace permiten la comunicación entre dispositivos en diferentes
segmentos de una red, en los cuales utilizan protocolos diversos.
Diseño de una arquitectura para la comunicación entre protocolos 57
arquitectura de IoT basada en una puerta de enlace y analiza un escenario

de uso para dicha propuesta. Finalmente, la sección 4 discute las principales
conclusiones del trabajo.
2. Antecedentes
La arquitectura de alto nivel de un sistema de IoT es similar a la arquitectura
genérica de cualquier otro sistema; se compone de elementos de entrada,
procesamiento y salida. La diferencia básica es que la entrada de datos se puede
realizar por medio de sensores y la salida se puede efectuar con actuadores.
Así, los datos que se adquieren del entorno por medio de sensores se transmiten
a los dispositivos de control (procesamiento) usando tecnologías y protocolos
de comunicación, y una vez que son procesados, el resultado es enviado a los
actuadores para modificar, si es el caso, las condiciones del entorno.
El procesamiento de datos en un sistema IoT requiere protocolos de
comunicación para el intercambio de datos y de algoritmos para su tratamiento
y análisis. Los algoritmos se encargan de procesar los datos e integrarlos, de
conformidad con las relaciones de comunicación que se pueden formar entre los
dispositivos y la arquitectura del sistema.
Los sistemas de esta naturaleza también pueden recibir entradas de los
usuarios, por lo general en forma de parámetros de configuración o de actuación
con base en los resultados. De forma similar, estos sistemas también pueden
producir salidas tradicionales a un monitor o impresora. De forma que la interfaz
del usuario suele estar vinculada al dispositivo controlador, y es utilizada para
configurar y gestionar el sistema (véase la figura 1).
Figura 1: Elementos de la arquitectura de un sistema IoT.

58 Córdoba et al.
Conforme con lo anterior, la arquitectura de un sistemas de IoT, por lo

general, se compone de los siguientes elementos o dispositivos:
Interfaz para la interacción con los usuarios (entrada y salida): La

interfaz permite que el usuario configure el sistema, ingrese los parámetros
de operación, revise resultados y ejecute operaciones. La función de la
interfaz es facilitar el control y la administración de los dispositivos que
conforman un sistema IoT. Cuando se adquiere un sistema de IoT, la interfaz
de usuario puede venir incluida; pero cuando se desarrolla una solución
personalizada, es necesario desarrollarla de acuerdo con los requerimientos
del sistema.
Adquisición de datos del entorno (entrada): Captura de datos del
entorno por medio de sensores y los envía a la dispositivo de control para
su procesamiento.
Protocolos de comunicación (procesamiento): Se encargan del
intercambio de información entre los dispositivos que conforman el
sistema, y son un elemento crítico para su interconexión.
Equipo o software controlador (procesamiento): Es el equipo que recibe
los datos de los sensores, los procesa y de acuerdo con rutinas preestablecidas,
envía órdenes a los actuadores.
Procesamiento y análisis de los datos obtenidos (procesamiento): Lo
conforman los algoritmos y métodos que se encargan del tratamiento y
análisis de los datos. Los sistemas IoT pueden utilizar servicios en la nube
para almacenar y acceder recursos como bases de datos (e.g., SQL, NoSQL
y NewSQL), servicios web y servidores.
Ejecución de tareas (salida): Cuando la salida del sistema conlleva una
actuación sobre el entorno, se ejecutan acciones por medio de actuadores para
modificar determinadas condiciones. Sin embargo, cuando se busca modificar
las condiciones del entorno, las tareas que se llevan a cabo pueden consistir
en el análisis o ejecución de tareas adicionales de procesamiento.
Despliegue de resultados (salida): Los resultados se pueden desplegar en
un monitor para que el usuario tenga conocimiento de las actuaciones que
realiza el sistema, o simplemente para que el usuario tenga conocimiento del
resultado del procesamiento, de forma similar a los sistemas tradicionales.
Una arquitectura más compleja es la propuesta por Intel (Intel, 2015), la cual
contempla el uso de un gran número de protocolos de comunicación, conexión a
sistemas de almacenamiento y análisis, y servidores locales y en la nube.
2.1. Interconexión de dispositivos

Las topologías de comunicación de los sistemas IoT se pueden clasificar como
uno a uno (punto a punto), uno a muchos (estrella) y muchos a muchos (malla)
(Pacelle, 2014). Según el tipo de topología que se utilice, los datos pueden ser
recibidos, integrados y procesados por solo un dispositivo (el cual cumple la
función de controlador general) o por cada dispositivo en el sistema.
En cualquiera de las topologías señaladas, los dispositivos receptores y

transmisores conforman segmentos de comunicación (véase la figura 1), que
pueden utilizar diferentes protocolos. La clasificación genérica de estos segmentos
es la siguiente:
Sensor - dispositivo de control

Dispositivo de control – actuador
Los requerimientos de los sistemas de IoT con frecuencia requieren el uso

de dispositivos con funciones especializadas y características específicas y es
común que se requiera utilizar dispositivos de varios fabricantes diferentes,
los cuales pueden utilizar protocolos, medios de transmisión y distancias de
cobertura distintas. Entre los protocolos de comunicación más utilizados en IoT
se encuentran X10 (Cuevas, Martínez y Merino, 2002), NFC, ZigBee, Bluetooth,
RFID (Chavarría, s.f.), KNX (Jara-Maldonado, 2015), Z-Wave (Buxeres-Soler,
2014) y SigFox(Cárdenes-Tacoronte, 2016) (véase la tabla 1).
Tabla 1: Comparación de los protocolos más utilizados por IoT.

Protocolo Uso Frecuencia Cobertura Otras características
X1O Red eléctrica 120 KHz N/A Utiliza la red
doméstica eléctrica doméstica
como medio de
transmisión.
NFC Aplicaciones 13,56 MHz 10 cm Diseñado para
con poco aplicaciones de
volumen de autenticación.
datos
KNX Domótica N/A N/A Paralelo a la red
eléctrica.
ZigBee Datos 868 GHz 915 10 a 75 m Diseñado para bajo
inalámbricos GHz 2,4 GHz consumo de energía.
Z-Wave Datos Menos de 1 30 a 200 m Tranmisión de baja
inalámbricos GHz (varía potencia.
según el país)
Bluetooth Datos 2,4 GHz 10 m Utiliza enlaces de
inalámbricos frecuencia libre.
RFID Datos 9-135 KHz 2 a 100 m Tecnología con
inalámbricos 13,56 MHz mayor rango de
433 MHz y aplicaciones por las
860-960MHz frecuencias en las
2,45-5GHz que opera.
SIGFOX Smart Cities 868 o 902 3 a 5 Km Se considera la
MHz mejor opción para
Smart Cities por la
distancia que logra
abarcar.
60 Córdoba et al.
Algunos protocolos mencionados en la tabla 1 comparten ciertas

características, como el tipo de aplicación o frecuencias de comunicaciones que
utilizan, pero difieren en otras. Esto conlleva problemas de compatibilidad que
les impiden interconectarse, y requiere el uso de puertas de enlace para la
interconexión de dispositivos que usan diferentes protocolos.
2.2. Puertas de enlace

Las puertas de enlace cumplen varias funciones además de servir como
intermediarias en la comunicación entre dispositivos. Esas funciones pueden
incluir el procesamiento de información, gestión de la seguridad y controlador o
administrador del sistema.
Las puertas de enlace puede ser implementadas por medio de software o
hardware. En el caso de la implementación por software, por lo general se lleva
a cabo usando bibliotecas internas. Estas bibliotecas se componen de interfaces
programadas por los mismos desarrolladores de los protocolos, o por terceros,
cuando el código fuente y admite la posibilidad de agregarle funcionalidad a los
protocolos. Estas interfaces son funciones que se pueden invocar desde diferentes
lenguajes de programación. Por su parte, las puertas de enlace por hardware
sirven como punto de interconexión de dispositivos por medio de interfaces físicas
o procesadores de comunicaciones inalámbricas de distintos tipos.
El proceso de interconexión que realizan las puertas de enlace por software y
hardware requiere la desencapsulación y encapsulación de datos, para decodificar
y codificar la información en los formatos que utilizan tanto el origen como el
destino de la comunicación. Lo que implica que la puerta de enlace debe procesar
las unidades de datos del protocolo (UDP) para cada capa del modelo o estándar
de comunicaciones que utilizan los dispositivos en un segmento.
En el mercado se encuentran disponibles varias puertas de enlace, tanto de
software como hardware. Dell Edge Gateway permite varias conexiones cableadas
e inalámbricas (Dell, 2016b, 2016a) para interconectar protocolos como ZigBee,
BACnet y ModBus, entre otros. Mientras que Intel IoT Gateway es una familia
de productos (Intel, 2016) que permiten comunicar dispositivos por medio
de ZigBee, Bluetooth, USB, VPN y Wi-Fi. Por su parte, Texas Instruments
(Texas Instruments Incorporated, 2016) y EuroTech (Eurotech, 2016a, 2016b)
también cuentan con puertas de enlace que tienen características similares a las
mencionadas.
3. Propuesta de diseño
Las arquitecturas comerciales de IoT pueden resultar costosas, lo cual pone
en evidencia la necesidad de contar con un diseño cuya implementación sea
sencilla y económica. Con base en esto, este trabajo propone el diseño de una
arquitectura basada en una puerta de enlace que se compone de un dispositivo
de control, módulos de comunicación y bibliotecas para el intercambio de
información entre el dispositivo de control y los módulos (véase la figura 2).
Figura 2: Arquitectura con dos módulos de comunicaciones.
El diseño propuesto toma ventaja de la arquitectura de Raspberry Pi

(Raspberry Pi Foundation, 2016) y lo utiliza como dispositivo de control, por
ser una computadora de diseño reducido y propiedad registrada, pero de uso
libre, lo cual permite que los usuarios puedan modificar y agregar módulos de
acuerdo con sus necesidades. Así, por ejemplo, es posible que agreguen módulos
de memoria adicional u otros módulos para comunicarse con diferentes protocolos
y tecnologías como ZigBee, Z-Wave, RFID, 3G y GSM. Además, es importante
destacar que Raspberry Pi soporta el uso de Python, C, C++ y Ruby para
programar diferentes algoritmos.
El sistema operativo oficial de Raspberry Pi es una versión adaptada de
Debian, denominada como RaspBian, y el precio de los módulos de comunicación
que se le pueden agregar es relativamente bajo. Esto hace que el costo de
implementación de esta propuesta sea significativamente bajo, en comparación
con las opciones de puertas de enlace propietarias que existen en el mercado.
El diseño propuesto contempla el uso de cualquiera de los protocolos de los
módulos que soporta Raspberry Pi, pero cabe señalar que de acuerdo con la
investigación realizada, los protocolos más utilizados por los sistemas IoT son
Z-Wave y RFID.
3.1. Escenario de uso

Un edificio con un gran número de espacios cuenta con puertas de apertura
y cierre automático, circuitos de iluminación, sistema de detección de incendios
y cámaras de seguridad con sensores de movimiento.
Cada día por la mañana, se deben abrir las puertas, encender las luces de
cada sitio de manera individual y revisar los vídeos de las cámaras. Este proceso,
62 Córdoba et al.
lo realiza solo una persona autorizada por razones de seguridad, pero presenta
los siguientes inconvenientes:
La apertura de puertas y encendido de luces toma 10 minutos en la mañana
y 10 minutos por la tarde.
El personal que trabaja en las instalaciones no puede ingresar antes de su
hora de entrada oficial, ni puede quedarse trabajando después de la hora de
salida oficial. Esto afecta el desarrollo de algunos proyectos de alta prioridad
debido al proceso burocrático para justificar las razones de una jornada
especial y, como consecuencia, se activa un protocolo de seguridad especial.
La revisión de los vídeos puede tomar varias horas y es frecuente que se
realice su revisión cuando sucede un incidente.
En general, la administración no puede conocer detalles sobre los eventos que
se generan en torno a la apertura de puertas, iluminación, alarmas de incendio y
cámaras, porque no cuenta con un sistema de alertas y estadísticas eficiente. Esto
impide que los administradores puedan reaccionar a tiempo ante emergencias o
variaciones en los patrones de comportamiento de los funcionarios y visitantes,
por lo que la organización y el escenario descrito requieren considerar el diseño
e implementación de los siguientes sistemas:
Control: El fin de este sistema es controlar las luces, sensores de incendios,
cámaras y la apertura de puertas utilizando los protocolos RFID y Z-Wave.
Gestión: El objetivo de este sistema es realizar el procesamiento de la
información, enviar notificaciones de emergencia y realizar el análisis de
patrones de identificación y comportamiento a partir de la información de
los sensores y vídeos.
Conforme con lo anterior, el funcionamiento del subsistema de iluminación,
apertura y cierre de puertas para este escenario se plantea de la siguiente forma:
El personal autorizado cuenta con una tarjeta RFID como medio de
identificación, cuya lectura es realizada por un módulo RFID.
Una vez que la persona ha sido identificada, el sistema realiza la apertura
de las puertas y el encendido de las luces mediante el envío de señales a los
dispositivos Z-Wave.
– Las luces se encienden por medio de un apagador Z-Wave.
– La apertura de puertas se hace usando una cerradura de puerta Z-Wave.
Este subsistema requiere codificar cada tarjeta RFID con los datos personales
del empleado correspondiente, realizar la configuración de la red de dispositivos
Z-Wave de acuerdo con las instrucciones de los fabricantes y programar los
scripts en un lenguaje de programación, como Python. Las rutinas que deben
comprender los scripts cuando el lector RFID detecta una tarjeta son las
siguientes:
Encender los circuitos de luces y abrir la cerradura de las puertas, si la
última condición de las luces es “apagado” y la condición de las cerraduras
es “cerrado”.
Apagar los circuitos de luces y cerrar las puertas si la última condición de

las luces es “encendido” y la condición de las cerraduras es “abierto”.
En cuanto al sistema de gestión de eventos y análisis de patrones, este se

encuentra conformado por el dispositivo de control y el sistema de análisis
(localizado en la nube). La secuencia de funcionamiento y procesamiento de
este sistema se realiza de acuerdo con la siguiente secuencia de pasos:
Dispositivo de control: Este dispositivo recibe datos de los diferentes

dispositivos y envía notificaciones a las personas designadas por medio de
un APP, de acuerdo con las reglas que tiene configuradas.
Procesamiento en la nube: El dispositivo de control además envía los datos
de todos los eventos e imágenes que registran las cámaras a un sistema de
análisis en la nube.
Sistema de análisis: Este sistema se encuentra en la nube y se encarga
de procesar los datos conforme los recibe e integra los resultados del
procesamiento con los resultados históricos. El análisis que realiza este
sistema contempla desde los eventos relacionados con la apertura y cierre
de puertas, encendido de luces y movimientos registrados por los sensores
hasta el análisis de imágenes captadas por las cámaras con el fin de identificar
personas y sus patrones de comportamiento.
Estadísticas y patrones: Los resultados del análisis son representados de
forma visual para hacerlos más comprensibles y útiles para los usuarios.
En cuanto a la implementación del sistema completo, se requieren los

siguientes componentes de hardware:
Dispositivo de control - Raspberry Pi (PCB): Este dispositivo se

describe como una minicomputadora con todas las características necesarias
para realizar las tareas de control y procesamiento de datos, pero además
se conecta a la nube para enviar datos para su almacenamiento y
procesamiento. El modelo utilizado debe contar con puerto Ethernet o
conexión usando 802.11n.
Módulos Z-Wave: Se recomienda utilizar Razberry (RaZberry, 2016), para
permitir la comunicación de sensores y actuadores que usan Z-Wave. En
concreto, los dispositivos que utilizaran Z-Wave son los apagadores de luces,
los elementos de cierre y apertura de puertas, los sensores de incendios y las
cámaras.
Razberry cuenta con una interfaz de usuario que permite su rápida
implementación, pero también facilita el desarrollo de interfaces
personalizadas por encontrarse disponible la documentación del fabricante
para ese fin.
Módulo RFID: Este módulo permite la lectura de las tarjetas RFID y se
mantiene activado en modo de lectura al dispositivo de control (Raspberry
Pi ), para que capte las señales transmitidas por las etiquetas RFID.
64 Córdoba et al.
4. Conclusiones
En este trabajo de investigación se llevó a cabo una revisión bibliográfica
sobre los principales protocolos y arquitecturas que se utilizan en IoT. Dicha
revisión permitió analizar y discutir el estado actual de internet de las cosas
y las implicaciones que tiene el uso de protocolos diferentes en los procesos de
interconexión y comunicación.
Como resultado, fue posible conocer con mayor detalle y poner de
manifiesto la relación que existe entre los protocolos, dispositivos, fabricantes
y arquitecturas en el proceso de comunicación. Esto permitió proponer una
arquitectura de bajo costo para la interconexión de protocolos y dispositivos
heterogéneos en sistemas IoT.
Las ventajas del diseño presentado son su sencillez, posibilidades que ofrece
para la interconexión, facilidad de implementación, bajo costo, gestión de alertas
y análisis de patrones. Esto lo hace ideal para resolver problemas de poca y media
complejidad, con personal poco especializado y sin necesidad de incurrir en altos
costos.
El subsistema de análisis de información que incorpora la propuesta
contempla el uso de servidores locales o en la nube, y tiene por fin brindar
detalle sobre los eventos y procesos que han sido atendidos y procesados por el
sistema. Pero además proporcionar mecanismos de inteligencia para la detección
de patrones anormales que pueden requerir la toma de acción inmediata.
Como trabajo futuro, se estará realizando la implementación de la
arquitectura propuesta y se estarán desarrollando casos de uso de mayor
complejidad para validar la arquitectura y agregar factores de escalabilidad a
la propuesta.
Referencias
Ashton, K. (2009, June). That ’Internet of Things’ thing. Descargado de http://
www.rfidjournal.com/articles/view?4986
Buxeres-Soler, A. (2014). Estudio y desarrollo de un sistema basado en una
librería abierta para el uso del protocolo inalámbrico de domótica Z-Wave.
Cárdenes-Tacoronte, D. (2016). Diseño e implementación de una herramienta
para la verificación de cobertura de la red SIGFOX. Estudio de
conectividad en una zona geográfica de orografía compleja.
Chavarría, D. A. (s.f.). Tecnología de comunicacionón de campo cercano (nfc)
y sus aplicaciones.
Cuevas, J. C., Martínez, J. y Merino, P. (2002). El protocolo x10: una
solución antigua a problemas actuales. En Simposio de informática y
telecomunicaciones (sit).
Dell. (2016a). Dell edge gateways for IoT. Descargado de http://www.dell
.com/us/business/p/edge-gateway?s=bsd
Dell. (2016b). Edge Gateway 5000. Descargado de http://www.dell.com/us/
business/p/dell-edge-gateway-5000/pd?ref=PD_OC
Referencias 65
Eurotech. (2016a). IoT Gateways: multi service IoT gateways. Descargado de

https://www.eurotech.com/en/products/devices/iot+gateways
Eurotech. (2016b). ReliaGATE 10-11: compact Multi-Service IoT gateway,
industrial-grade, TI AM3352. Descargado de https://www.eurotech
.com/en/products/ReliaGATE%2010-11
Intel. (2015). Intel IoT Platform Reference Architecture. Descargado de http://
www.intel.com.au/content/dam/www/public/us/en/documents/
white-papers/iot-platform-reference-architecture-paper.pdf
Intel. (2016). Intel IoT gateway technology. Descargado de https://
www-ssl.intel.com/content/www/us/en/embedded/solutions/
iot-gateway/overview.html
Jara-Maldonado, P. A. (2015). Estudio y diseño de un sistema inmótico para
seguridad, comunicación y confort, utilizando el protocolo KNX para el
edificio Torre Piamonte ubicado en el sector de Totoracocha de la ciudad
de Cuenca.
Manyika, J., Chui, M., Bisson, P., Woetzel, J., Dobbs, R., Bughin, J. y
Aharon, D. (2016). Unlocking the potential of the Internet of Things.
Descargado de http://www.mckinsey.com/business-functions/
business-technology/our-insights/the-internet-of-things-the
-value-of-digitizing-the-physical-world
Pacelle, M. (2014, April). 3 topologies driving IoT networking
standards. Descargado de http://radar.oreilly.com/2014/04/3
-topologies-driving-iot-networking-standards.html
Rana, M. (2016, June). Thirty-four percent rise in IoT development. Descargado
de http://www.evansdata.com/press/viewRelease.php?pressID=237
Raspberry Pi Foundation. (2016). Raspberry Pi Foundation. Descargado de
https://www.raspberrypi.org/
RaZberry. (2016). RaZberry Project. Descargado de https://razberry.z-wave
.me/
Texas Instruments Incorporated. (2016). HVAC Gateway. Descargado de
http://www.ti.com/solution/iot_gateway
The Z-Wave Alliance. (2016). The Internet of Things is powered by Z-Wave.
Descargado de http://z-wavealliance.org/
ZigBee Alliance. (2016, July). The ZigBee Alliance creates IoT standards
that help control your world. Descargado de http://www.zigbee.org/
zigbeealliance/
Etiquetas de Geolocalización en imágenes ráster
para la identificación de especímenes biológicos
Jonathan Quintana Berríos, Esteban Robleto Rodríguez y

[jquintanab798,erobletor703]@ulacit.ed.cr
Resumen La identificación de especímenes de la flora y fauna ayuda a

conservar la riqueza de los ecosistemas al permitir conocer su composición
y niveles de riesgo, en términos de extinción, por lo que es necesario
que los científicos que llevan a cabo dicha identificación cuenten con los
métodos y herramientas necesarias para realizarla de forma efectiva y
eficiente. En este contexto, el objetivo de este trabajo de investigación
es apoyar la identificación de especímenes biológicos mediante el uso
de mapas con información georeferenciada, almacenada en imágenes
ráster, para lo cual se desarrolló una prueba de concepto para el
procesamiento de la información de georeferenciación, usando bibliotecas
de código abierto. Esto permite obtener detalles sobre las zonas y áreas
en las cuales se han encontrado muestras de una especie en particular.
Como consecuencia, la principal contribución de este trabajo es la
implementación de una herramienta sencilla para extraer las coordenadas
geográficas de las localizaciones donde se han recolectado muestras de
especies biológicas.
Palabras clave: Analítica visual, GeoTIFF, GeoKey, imágenes ráster,

metadatos, SIG
1. Introducción
El reconocimiento de especímenes biológicos representa un reto para los
científicos (biólogos), debido al número de características que las diferencia
entre sí a las especies de flora y fauna. En este contexto, el uso de elementos
taxonómicos y claves de identificación reviste especial importancia, porque
permite clasificar las muestras por medio de sus características físicas visibles.
Los principales elementos que intervienen en el proceso de identificación,
son los caracteres y los estados de carácter, en donde el término “carácter"hace
referencia a las características generales de las especies, mientras que “estados
de carácter"se refiere a las características específicas.
Etiquetas de geolocalización en imágenes ráster 67
Las herramientas especializadas para la identificación de especies que existen,

tanto comerciales como no comerciales, se basan en árboles de decisión que
permiten elegir caracteres y estados de carácter de acuerdo con las características
de la muestra. Sin embargo, el uso de información de geolocalización, relacionada
con los lugares donde han sido recolectadas las muestras de una especie, no ha
sido explorada de forma amplia, por lo que la utilización de información de
georeferencias, en conjunto con el uso de árboles de decisión, puede contribuir
con el proceso de identificación de especímenes biológicos.
Conforme con lo anterior, este trabajo de investigación busca apoyar el
desarrollo de Iriria, una herramienta de analítica visual1 , mediante el uso de
la información georefenciada que se encuentra almacenada en mapas codificados
como imágenes ráster2 . Cabe mencionar que los científicos pueden crear áreas
trianguladas, las cuales podrían estar superpuestas, a partir de las localizaciones
donde han encontrado muestras de determinadas especies y que es posible
almacenarlas en mapas ráster.
Como consecuencia, la sección 2 lleva a cabo una revisión detallada sobre
el uso de imágenes ráster para la codificación y decodificación de información
georefenciada, mientras que la sección 3 presenta los resultados del trabajo
y la sección 4 discute las principales conclusiones y trabajo futuro de esta
investigación.
2. Estado del arte

Los archivos en formato GeoTIFF (Ritter y Ruth, 2000) permiten almacenar
tanto coordenadas geográficas como metadatos y pueden ser leídos con facilidad
por la mayoría de sistemas de información geográfica (SIG). Las imágenes que
utilizan este formato son conocidas como imágenes ráster, y almacenan datos
de georeferenciación en cada uno de los pixeles, los cuales forman parte de
una matriz conformada por cientos de pixeles que en conjunto proporcionan
información detallada.
En una imagen ráster, por ejemplo, una matriz puede ser bidimensional o
tridimensional, en función del tipo de imagen. En el caso de las imagenes en
2D, las coordenadas geográficas (i.e. latitud y longitud) se almacenan en un
cuadrante x, y de la matriz, mientras que en el caso de las imágenes en 3D los
datos se almacenan en un cuadrante x, y, z para representar la profundidad de
la imagen. De forma adicional, los valores contenidos dentro de los cuadrantes,
se despliegan usando colores, los cuales pueden ser monocromáticos o primarios
(azul, verde y rojo)3 .
1
La analítica visual utiliza una combinación de visualización de la información,
interacción persona-computadora y el razonamiento de las personas para la obtención
de conocimiento (Aigner, Bertone y Miksch, 2008).
2
Ráster se refiere al término inglés raster, que hace referencia a imágenes que
almacenan metadatos relacionados con la representación gráfica que realizan.
3
Los colores rojo, verde y azul son conocidos por sus siglas en inglés como RGB.
68 Quintana et al.
Entre los tipos de archivos más comunes para el almacenamiento de imágenes

ráster se encuentran los siguientes:
BMP (bitmap).
TIFF (Tag Image File Format).
GIF (Graphics Interchange Format).
JPEG (Joint Photographics Experts Group).
Para manipular las imágenes ráster existe un gran número de herramientas

comerciales4 y no comerciales, pero también es posible encontrar bibliotecas para
crear aplicaciones propias. En este trabajo de investigación se está considerando
el uso de bibliotecas de código abierto para la manipulación de los mapas,
codificados como imágenes ráster, para evitar las restricciones que imponen las
licencias de uso comercial.
El tamaño de las imágenes puede ser superior a los 4 gigabytes, en función
de los metadatos que contengan, lo cual requiere que sean almacenadas en un
formato conocido como BigTiff. Por esa razón, las imagenes se comprimen para
facilitar su manipulación, pero el tipo de compresión influye en la lectura de
imágenes ráster y es necesario efectuar el procesamiento de forma correcta para
no perder información. En el caso de la biblioteca de GeoTIFF, esta utiliza el
formato de compresión “BitPack”.
El almacenamiento de información se realiza utilizando bytes en lugar de
bits, lo cual permite tener más datos comprimidos dentro de un archivo TIFF,
y que a la hora de apuntar a una posición donde se encuentran agrupados unos
y ceros, se pueda hacer referencia a una posición dentro del arreglo y no a un
valor particular5 .
En los archivos TIFF la información se almacena usando cuadrículas de
cientos o miles de puntos en notación hexadecimal, y los agrupa en un arreglo
bidimensional usando grupos de 8, 16 y 32 bits. Para poder ubicar un valor en un
arreglo dentro del espacio ráster, conocido también como R, es importante saber
que los pixeles se ubican dentro de una cuadrícula. El área de pixeles se define
por medio de las coordenadas i (fila) y j (columna) para recorrer el arreglo.
Los metadatos que almacena el formato GeoTIFF están organizados en
un catálogo de GeoKeys (GeoKeyDirectoryTag) (Ritter y Ruth, 2000), que se
almacena en el encabezado de los archivos. Las GeoKeys contienen etiquetas
TIFF reservadas que tienen información pública o privada sobre una región o
lugar específico y usan un identificador numérico que se encuentra en un rango
de 0 a 65535. No todas las GeoKeys se pueden utilizar de forma libre, debido a
que pueden estar reservadas para usos específicos.
Los parámetros del encabezado de los archivos GeoTIFF se basan en una
estructura geográfica, que fue desarrollada por el European Petroleum Survey
Group (EPSG/POSC). Estos parámetros se utilizan para identificar posiciones
4
Entre las herramientas comerciales mejor conocidas para la manipulación de
imágenes ráster se encuentran AutoCad, Adobe Ilustrator y Photoshop.
5
A esta forma de guardar datos dentro de un TIFF se le conoce como Big and Little
Endian.
geográficas en un sistema de coordenadas e implica la utilización de un sistema

de estructuras elipsoides u ovaladas para identificar puntos dentro de la tierra,
basados en referencias verticales u horizontales (Geodetic datums). Estos puntos,
también conocidos como ejes, permiten definir tanto la latitud como la longitud,
tomando en cuenta el paralelo 0 (conocido como Ecuador) para el caso de la
latitud y el meridiano de Greenwich para la longitud (Ritter y Ruth, 2000).
Como consecuencia, los archivos GeoTIFF requieren de un par
GeoKey/nombre que está definido en la lista estándar de parámetros, para hacer
una proyección del mapa de forma plana, usando la representación de la tierra
por medio de longitudes y latitudes.
3. Resultados
La implementación de la herramienta se llevó a cabo utilizando GeoTIFF
(Schindler, 2015), una biblioteca en JavaScript para leer los metadatos
contenidos en las imágenes ráster (lhomme, 2014).
La lectura de una imagen ráster conlleva la identificación de las GeoKeys
que se encuentran en la imagen en formato TIFF, lo cual requiere recorrer los
pixeles de la imagen para obtener los metadatos. Una vez que se localizan los
metadatos, estos son extraídos y cargados por la herramienta, lo cual produce un
efecto de cambio de color de la imagen, debido a que la información almacenada
en los metadatos es mostrada.
Las pruebas realizadas durante este trabajo utilizaron como referencia el
mapa que se muestra en la figura 1, sobre la cual se proyectan las imágenes que
son procesadas.
Figura 1: Imagen tomada de Open Street Maps (Foundation, 2006)

70 Quintana et al.
En el contexto de la identificación de especímenes biológicos, se requiere leer

las latitudes y longitudes de las ubicaciones geográficas en las cuales se han
recolectado muestras de las especies biológicas, por lo que se lee la información
que se encuentra almacenada por las GeoKeys y se utilizan mapas en formato
plano.
El procesamiento de las imágenes se lleva a cabo usando una función
denominada loadmaps, la cual carga la imagen de un mapa ráster, para una
región geográfica seleccionada. Esta función utiliza OpenLayers (Kirkman y
Davis, 2014), una biblioteca de código abierto, para ubicar sobre el mapa (figura
1) la imagen de la zona geográfica escogida, con base en los metadatos de
geolocalización.
Una vez que la imagen ha sido cargada y procesada, es posible observar la
información que tiene codificada (véanse las figuras 2 y 3).
Figura 2: Imagen luego de ser mapeada
Los pasos del algoritmo que se siguen una vez que la imagen es cargada, son
los siguientes:
Figura 3: Imagen procesada por las librerías, los colores se encuentran definidos por las
etiquetas y, podrían ser utilizados para identificar datos en un mapa
1. Se realiza la búsqueda de una GeoKey dentro de los metadatos de la imagen,

usando una variable denominada como fieldTagName.
2. Se obtienen los valores almacenados en la etiqueta asociada a la GeoKey.
3. Se ejecuta una función para obtener un TagName. Esta función compara el
valor de la etiqueta y los valores de etiqueta que están definidas en el código
del programa.
4. Se procede a buscar, mediante la variable fieldTypeNames, una GeoKey que
indica el tipo de llave que contiene esa etiqueta.
5. El proceso utiliza una variable para guardar los valores obtenidos, para luego
mostrarlos en el mapa.
La secuencia se repite el número de veces que sea necesario, en función de

las GeoKeys en los metadatos de la imagen.
En el contexto de la identificación de especímenes biológicos, para determinar
si una muestra de una especie ha sido recolectada en una región, se realiza la
lectura de la posición del puntero del ratón cuando se pasa sobre el mapa6 , y
con base en las coordenadas geográficas (latitud y longitud), se consulta la base
de datos para obtener una lista de las especies que se encuentran asociadas a
esas coordenadas.
6
La lectura de posiciones geográficas se realiza mediante el uso del atributo
mouseposition.
72 Quintana et al.
4. Conclusiones
El almacenamiento de metadatos en mapas codificados como imágenes ráster
es un recurso valioso para asociar datos de diferente índole a localizaciones
geográficas específicas, por lo que en el contexto de la identificación de
especímenes biológicos resulta de gran utilidad para obtener detalles acerca de
las especies que se han identificado en una zona o región particular.
Entre los detalles de las especies que se pueden almacenar en los mapas se
encuentran la fecha en que las muestras fueron recolectadas, quién las recolectó
y la institución a la cual se encuentra vinculado el recolector.
En general, el tratamiento de este tipo de imágenes no es un proceso trivial,
se requiere de análisis y estudio para comprender los conceptos generales y
específicos que luego pueden ayudar a estudiar el código y ejemplos de las
bibliotecas disponibles.
El principal aporte de este trabajo de investigación consiste en la
documentación inicial de los conceptos relacionados con imágenes ráster y la
implementación de una prueba de concepto sobre la lectura de este tipo de
imágenes, en el contexto del desarrollo de Iriria.
En línea con lo anterior, como trabajo futuro se estará ampliando la prueba
de concepto para realizar la escritura de información, sobre las muestras de
especies, en las imágenes ráster, así como la integración de la implementación
como parte de Iriria.
Referencias
Aigner, W., Bertone, A. y Miksch, S. (2008). Introduction to visual analytics.
Danube University Krems, Austria.
Foundation, O. (2006, aug). Openstreetmap. Descargado de https://www
.openstreetmap.org/
Kirkman, R., y Davis, T. (2014). Openlayers 3. Descargado de https://
github.com/openlayers/ol3
lhomme, X. (2014, dec). A javascript-based parser for the geotiff image format.
Descargado de https://github.com/xlhomme/GeotiffParser.js
Ritter, N., y Ruth, M. (2000, dec). Geotiff format specification: Geotiff
revision 1.0. Descargado de http://www.remotesensing.org/geotiff/
spec/geotiffhome.html
Schindler, F. (2015). Read raw data from geotiff files. Descargado de https://
github.com/constantinius/geotiff.js
Caracterización de malware usando lenguajes de
intercambio de inteligencia
Randall Barnett Villalobos, Susan Rodríguez Segura, Julio Chinchilla Moya y

Wilson Acuña Araya
[rbarnettv200,srodriguezs044,jchinchillam135,lacunaa475]@ulacit.ed.cr
Resumen Para el año 2015, los laboratorios de Panda Security

procesaron en promedio 230 mil muestras de malware por día, es decir,
84 millones al año. Eso implicó un incremento de 9 millones más que
en el 2014. Es en este escenario que el intercambio de inteligencia en
el área de la seguridad informática busca convertirse en un estándar
que permita compartir las características de las ciberamenazas de una
manera estándar. Con la utilización de metalenguajes de comunicación
y metalenguajes de observabilidad, se logra realizar el intercambio
de información sobre amenazas entre distintas fuentes, efectuando la
caracterización de los archivos para compartir la información obtenida
de forma estándar.
Palabras clave: Internet de las cosas, protocolos, comunicaciones
1. Introducción
Para la identificación de nuevas amenazas es necesario profundizar en el tema
de lenguajes de intercambio de inteligencia. La organización MITRE propone
varios metalenguajes que permiten aprovisionar al investigador, de un sistema
de caracterización y búsqueda entre distintas fuentes de información para la
detección de vulnerabilidades.
Estos metalenguajes son versátiles, ya que permiten crear herramientas de
software por medio de los API de MITRE, para poder consultar la información
en tiempo real. Además, permiten obtener datos de diversas fuentes, ya sean
propias o proporcionadas por terceros, que sirven como una base de conocimiento
gratuita para la rápida resolución de incidentes de ciberseguridad.
La idea central de esta investigación es la creación de una herramienta de uso
libre donde las organizaciones y empresas a nivel global tengan la facilidad de
aprovisionar, consultar y colaborar con información de los archivos sospechosos
que detecten en sus sistemas al haber recibido algún ataque. Esta herramienta
posee la capacidad de extraer datos relevantes de archivos sospechosos y
74 Barnett et al.
comparar la información obtenida para la caracterización de estas amenazas.

En una segunda etapa, se espera que tenga la capacidad de compartir los datos
importantes de caracterización del malware informático en una base de datos de
conocimiento global.
Para lograr la creación de esta herramienta, se utilizaron dos grupos de
metalenguajes un framework de intercambio de información entre servidores que
las API de MITRE ofrecen:
1. Framework de comunicación: TAXII.

2. Metalenguaje de comunicación: STIX.
3. Metalenguajes de observabilidad: Se utilizaron MAEC y CybOX.
El intercambio de inteligencia trata del análisis de la información con el fin

de compartir los hallazgos encontrados en artefactos de software, para poder
realizar una caracterización de las amenazas. Esto permite: describir el tipo de
ataque ulterior, tener información importante de su origen, crear especificaciones
de cómo reconocerlo y posteriormente analizar la manera de cómo evitarlo
(EclecticIQ, 2016).
Los ataques por medio de la web buscan obtener información o acceso a
los sistemas críticos de una organización. Para las empresas u organizaciones es
vital tener conocimiento de las amenazas a las que se están enfrentando, por lo
tanto, a la hora de ocurrir un evento es obligatorio tener una base de datos de
conocimiento con reportes detallados sobre determinados hallazgos de ataques
anteriores, propios o de terceros, lo que permite generar ciberinteligencia para
perfilar y evitar futuras amenazas.
Para realizar este proceso se utilizaron los API provistos en Python 2.X para
extraer información relevante de los archivos, estandarizarlos y ordenarlos de
una manera comprensible al ser humano, sin importar la fuente de procedencia.
Lo anterior permite realizar la comunicación y el intercambio de inteligencia de
manera sencilla, práctica y ordenada.
1.1. STIX
Este metalenguaje estandarizado presenta los datos de las amenazas de
una manera estructurada. Está compuesto por distintos objetos, a saber: los
observables, indicadores, incidentes, TTP, objetivos de exploits, cursos de acción
y los reportes.
Este metalenguaje muestra la información en formato XML fuertemente
tipado, el cual es utilizado para representar los datos adquiridos de una forma
más legible.
Para hacer uso de STIX se deben importar las siguientes librerías de Python:
import stix.utils as utils
from stix.utils import IDGenerator,
set_id_method
from stix.core import STIXPackage,
STIXHeader
Caracterización de malware usando lenguajes de intercambio de inteligencia 75
from stix.indicator import Indicator

from stix.common import InformationSource,
Identity
Además se debe crear un CybOX File Object, el cual va a contener un
hash del archivo a caracterizar, como parte de un identificador único (Security
Intelligence, IBM, 2015). A partir de esto se construye el paquete STIX y se
adjunta el hash:
def add_stix_ciq_identity(file, hash):
stix_package = STIXPackage()
file.add_hash(hash)
Un paso importante para crear un indicador que identifique el artefacto de
software de forma unívoca, haciéndolo observable, se hace de la siguiente manera:
indicator = Indicator()
indicator.title =
"observable indicator" +
file.file_name
indicator.description =
"An indicator containing the observable"
indicator.set_producer_identity(
"ULACIT Costa Rica")
indicator.set_produced_time(
utils.dates.now())
indicator.add_object(file)
Los pasos subsecuentes servirán para poder compartir el objeto observable,
por lo que se debe añadir la fuente de información, para lo cual se usarán los
parámetros de inicialización a fin de establecer los nombres de las herramientas
y de los proveedores del hallazgo. Es necesario, como todo XML fuertemente
tipado, darle las cabeceras adecuadas para que sea inspeccionado por el API y
añadirlo a la colección de paquetes de STIX :
stix_header.information_source =
InformationSource()
tool = ToolInformation(
tool_name="Intel-Sharing",
tool_vendor="The MITRE Corporation"
)
stix_package.stix_header = stix_header
stix_package.add(indicator)
return stix_package.to_xml()
1.2. TAXII
TAXII no se refiere a un programa de intercambio, sino a un conjunto de
especificaciones para el intercambio de información de amenazas cibernéticas
76 Barnett et al.
y así ayudar a las organizaciones a compartir información relevante sobre

estas amenazas. Este framework trabaja como un mecanismo de transporte
para STIX que estandariza automáticamente la información sobre amenazas
(MITRE, 2014).
TAXII tiene tres modelos de reparto de información:
1. Hub and spoke: donde una organización funciona como un centro o

repositorio de intercambio de información para distintas organizaciones que
pueden ver e incluir información.
2. Source/subscriber : donde una organización funciona como una única fuente
de información para otras organizaciones donde solamente pueden ver la
información.
3. Peer to Peer : donde dos o más organizaciones comparten información entre
sí directamente.
TAXII define el comportamiento de cuatro servicios, con respecto a cómo

esa información será compartida:
1. Bandeja de entrada: un servicio para recibir contenido insertado, es

básicamente un oyente de contenido entrante.
2. Encuesta: un servicio para solicitar contenido de una fuente de datos.
3. Gestión de cobros: un servicio para conocer y solicitar suscripciones a
colecciones de datos.
4. Descubrimiento: Un servicio para aprender cuáles servicios son compatibles
y cómo interactuar con ellos.
Para hacer uso de TAXII, se deben importar las siguientes librerías:

libbtaxii que contiene información de la versión y métodos para mensajes de
respuestas HTTP.
libtaxii clients: para clientes HTTP y HTTPS.
libtaxii constants: contiene constantes.
libtaxii messages: crea, maneja y analiza los mensajes.
El siguiente código muestra la forma de construir el mensaje:
import libtaxii as t
import libtaxii.clients as tc
import libtaxii.messages as tm11
from libtaxii.constants import *
def add_taxii(stix_file):
content_block_bindings =
tm.ContentBinding("BIND_ID", None)
content_block =
tm.ContentBlock(content_block_bindings,
stix_file,
None, None)
content_block_list = [content_block]
message = tm.InboxMessage(
"MESSAGE_ID", None, None, None, None,
None, None, None, content_block_list)
# Respuesta de servidor
return message
El siguiente código es la respuesta del estado del mensaje proporcionado por

TAXII.
HTTP/1.1 200 OK
Date: Fri, 19 Ene 2016 13:22:04 GMT
Server: Apache/2.2 (Linux Kali)
X-TAXII-Protocol:
urn:taxii.mitre.org:protocol:http:1.0
X-TAXII-Content-Type:
urn:taxii.mitre.org:message:xml:1.1
X-TAXII-Services:
urn:taxii.mitre.org:services:1.1
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive
Proxy-Connection: keep-alive
<taxii_11:Status_Message
xmlns:taxii_11="http://taxii.mitre.org
/messages/taxii_xml_binding-1.1"
message_id="59222"
in_response_to="36508"
status_type="SUCCESS"/>
Estas cabeceras viajarán entre servidores que consuman el servicio web que
aprovisione el mensaje.
1.3. Relación entre STIX y TAXII

Esta relación permitirá el intercambio y el transporte de información sobre
amenazas entre distintas organizaciones. TAXII puede transmitir en su carga
útil el paquete de STIX, y definirá cómo se va a compartir esta información a
través de la red local o global. En la figura 1 se muestra cómo interactúan entre
sí los metalenguajes de STIX y TAXII.
2. Analizador de direcciones IP
El analizador es una aplicación funcional para el análisis de cualquier
dirección IP en distintas bases de datos, con el fin de obtener información de
78 Barnett et al.
Figura 1: Interacción entre STIX y TAXII
su estado y ubicación geográfica. Además de analizar la IP deseada, es posible

visualizar y agregar otras direcciones de páginas web de lista negra a la base de
datos. En la figura 2 se muestra la imagen del resultado obtenido en la aplicación
Intel-Sharing, donde identifica la información, los servidores donde se encuentra
en lista negra y la ubicación aproximada de la dirección IP ingresada.
Figura 2: Resultado del analizador Web de direcciones IP
3. Virus total
A la aplicación de intercambio de inteligencia se le incluyó el API oficial
de Virus Total, con el cual se le aplica un valor agregado a los reportes, donde
se indica la cantidad de detecciones por antivirus que fueron encontrados en el
archivo analizado.
La herramienta Virus Total tiene la función de indicar si el archivo que se
está analizando para ser caracterizado cuenta con algún tipo de código malicioso,
el cual es detectado por alguno de los motores de antivirus con los que cuenta el
API.
Primero se procede a verificar el hash en la base de datos local, luego se
verifica este mismo dato en Virus Total, el cual proporciona el resultado. Luego
de verificar el archivo malicioso, se procede a realizar el empaquetado de la
información con STIX, se prepara el paquete STIX con las cabeceras TAXII
para el intercambio, se guarda el resultado en la base de datos dejando el archivo
resultante en formato XML en el servidor y, por último, muestra la información
respectiva en pantalla (Barnum, 2014).
4. Resultados
El tema de lenguajes de intercambio de información aún está poco
desarrollado, con su utilización se pueden explorar muchas funcionalidades útiles
para cualquier empresa, sea cual sea la orientación del negocio. Existe gran
cantidad de información que se puede obtener realizando la caracterización de
un archivo malicioso. Se logró caracterizar más de 100 artefactos de software,
almacenando la información resultante en una base de datos MySQL, que
incluye:
Números de identificación unívocos.

Listas negras de donde se encuentra el elemento caracterizado y resultados
de escaneos en más de 60 antivirus por cada artefacto analizado.
Caracterizaciones completas de cada artefacto de software analizado.
Listado de direcciones IP y DNS encontrados en listas negras.
Figura 3: Reporte de aplicación Intel-Sharing.

80 Barnett et al.
5. Conclusiones
El tema de los metalenguajes para el intercambio de información aún está
poco desarrollado. Con su utilización se pueden explorar muchas funcionalidades
útiles para cualquier empresa, sea cual sea la orientación del negocio. Existe
gran cantidad de información que se puede obtener al realizar la caracterización
de un archivo malicioso, el cual conlleva investigar más a fondo para sacarle
mayor provecho a estos metalenguajes. Actualmente se desconoce o no se maneja
muy bien el concepto de este tipo de herramientas (las cuales se pueden utilizar
de manera gratuita), y no existe documentación extensa sobre el tema, lo que
dificulta la implementación de este tipo de aplicaciones.
6. Recomendaciones
Los lenguajes de intercambio de inteligencia, deben ser investigados más a
fondo, debido a que abarcan un sinnúmero de funcionalidades, las cuales no
fueron desarrolladas en su totalidad en este proyecto. Es importante seguir
desarrollando funcionalidades de CyBOX y MAEC, así como STIX y TAXII.
Aún se debe modificar la manera de trabajar de STIX para que reciba la
información requerida por medio de parámetros. Un punto importante para
aplicar en la siguiente investigación es la implementación de un analizador de
malware como Anubis, el cual brindará un informe en distintos formatos que
puede ser relacionado con MAEC y así lograr la caracterización completa. Se
debe agregar seguridad a la aplicación e implementar sockets para mejorar el
rendimiento de la aplicación, para que logre leer más de un archivo (por ejemplo
una carpeta completa con n cantidad de archivos). Se debe continuar con el
desarrollo de un servidor TAXII donde se pueda recibir el paquete que está
listo, para ser enviado por la aplicación y de esta manera realizar el proceso
completo de intercambio de inteligencia.
Referencias
Barnum, S. (2014, feb). Standardizing cyber threat intelligence information
with the structured threat information expression (stix™). Descargado de
http://stixproject.github.io/getting-started/whitepaper/
EclecticIQ. (2016, apr). Stix and taxii threat intelligence analysis. Descargado
de https://www.eclecticiq.com/stix-taxii.html
MITRE. (2014, jan). Taxii-specifications. Descargado de https://github.com/
TAXIIProject/TAXII-Specifications
Security Intelligence, IBM. (2015, mar). Stix, taxii and cybox
can help with standardizing threat information. Descargado de
https://securityintelligence.com/how-stix-taxii-and-cybox
-can-help-with-standardizing-threat-information/
Dr. Antonio González Torres (Ed.)

Tecnologías Información Gestión Proyectos

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tecnologías Información Gestión Proyectos

Caricato da

Copyright:

Formati disponibili

Dr. Antonio González Torres (Ed.

Facultad de Tecnologías de la Información

Facultad de Tecnologías de la Información

Lugar de edición: San José, Costa Rica

Reservados todos los derechos. Prohibida la reproducción no autorizada por

Nos complace presentar este primer volumen de publicaciones de las

M.Sc. Edwin Aguilar Sánchez

Setiembre del 2016

Este trabajo es producto de varios trabajos presentados en el Workshop en

Edwin Aguilar Sánchez

Metodología para la gestión de terceros en procesos de desarrollo de

Definición y modelado del proceso de gestión de la demanda para

Yeison Núñez Sánchez y Antonio González Torres∗

Resumen La tercerización permite que las empresas reduzcan costos,

Palabras clave: Gestión de terceros, outsourcing, tercerización,

1. Definición de los requerimientos.

A esto se debe agregar la ausencia de sistemas de apoyo al proceso de

metodología para sintetizar algunas de las mejores prácticas e investigaciones

2. Estado del arte

¿Cuáles tareas o proyectos se van a tercerizar? Debe existir claridad

Lo anterior se puede realizar después de efectuar bechmarking interno y

Benchmarking interno: consiste en analizar las competencias centrales de la

En línea con lo anterior, un modelo para la administración del proceso de

Debido a la aceptación de la tercerización como un método eficaz para apoyar

Gestión del alcance: se deben incluir las características y funciones que

El resultado final de la tercerización del desarrollo de software es la entrega

se puedan corregir de inmediato las disconformidades (CENDITEL, Fundación,

Nivel 0: este nivel contempla el valor más alto en la jerarquía y se corresponde

La estimación adecuada de la calidad realiza cálculos tanto para estimar la

3. Fases para la gestión de terceros en proyectos

3. Selección y contratación del proveedor.

La relación entre las fases mencionadas con los procesos aseguramiento de

En las siguientes secciones se explican con detalle las fases contempladas en

Análisis, ¿desarrollo interno o externo?: se debe realizar la evaluación

obtener su aceptación y compromiso. Esta tarea se puede realizar mediante

Definición del alcance: brinda el panorama de alto nivel de los requerimientos

Definición del plan de aseguramiento de la calidad: se encarga de

Tabla 1: Roles de participantes en el proceso de tercerización de software

Puesto/Rol Descripción de responsabilidad

Elaboración del plan de comunicaciones: contempla determinar el flujo de

Recursos asignados para las actividades de comunicación, incluidos el

Identificación de los proveedores potenciales: corresponde a la

3.3. Selección y contratación del proveedor

Anunciar la tercerización: con base en el enunciado del proyecto, se

Adjudicación del contrato: se establece un acuerdo contractual con el

Revisiones de administración: se encargan de monitorear el progreso del

3.5. Administración de la relación

Efectuar el plan de gestión de comunicaciones: se recomienda llevar a

Figura 2: Diagrama de gestión de calidad

Maximizar la presencia física de los interesados o usuarios finales

Figura 3: Diagrama de administración de la relación con el proveedor

Es importante que los mensajes que se intercambien sean concretos,

el uso de conceptboard para la inclusión de comentarios y notas o

3.6. Aceptación y cierre

5. Al cerrar las adquisiciones, proceder con la conclusión del contrato,

1. Realizar revisiones del servicio, alcance y contratos de forma anual, para

La figura 4 presenta de manera visual las fases definidas para la gestión de

4. Conclusiones y trabajos futuros

Conferência Ibérica de Sistemas e Tecnologias de Informação) Proceedings,

Fabián Chaves Serrano, David Mora Solano y Antonio González Torres∗

Resumen La tercerización del desarrollo de software es una práctica

Palabras clave: Tercerización, relación con terceros, desarrollo ágil

En la actualidad la tercerización de desarrollo de software es de alta relevancia