Tecnologías de La Información y Gestión de Proyectos

Dr. Antonio Gonzlez Torres (Ed.
Tecnologas de la Informacin
y Gestin de Proyectos
Facultad de Tecnologas de la Informacin

ULACIT
2016
Dr. Antonio Gonzlez Torres (Ed.)
Facultad de Tecnologas de la Informacin

ULACIT
2016
ISBN: 978-9977-37-006-4
Primera Edicin, 2016
Universidad Latinoamericana de Ciencia y Tecnologa
ULACIT
Lugar de Edicin: San Jos, Costa Rica
Editorial: Universidad Latinoamericana de Ciencia y Tecnologa
Telfono: 2523-4000
Impreso en Costa Rica
Reservados todos los derechos. Prohibida la reproduccin no autorizada por

cualquier medio, mecnico o electrnico del contenido total o parcial de esta
publicacin.
A quienes trabajan mientras suean.
Prefacio
Nos complace presentar este primer volumen de publicaciones de las

investigaciones realizadas por profesores y estudiantes de la universidad de la
carrera de Ingeniera Informtica, en las que se abordan aspectos interesantes de
la tecnologa de informacin y la gestin informtica. Representan el resultado de
un esfuerzo sostenido de la Facultad de Tecnologas de Informacin por construir
una estructura permanente de investigacin que haga escuela para la formacin
de investigadores dentro de nuestra Facultad docente y comunidad de estudiantes
de bachillerato, licenciatura y maestra en Ingeniera Informtica.
Este libro es la respuesta a un desafo formidable que enfrentan las
universidades privadas para realizar investigacin cientfica en ingeniera,
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 investigacin que
arranca desde cero con el propsito de ser permanente y riguroso en su contenido.
En los procesos de investigacin de las ciencias naturales y sociales, se extrae
informacin y conocimiento a partir de la observacin directa o indirecta del
objeto en estudio, para confirmar o refutar hiptesis de trabajo planteadas,
siguiendo el llamado mtodo cientfico. Mientras que en ingeniera no se
persigue como fin la descripcin o explicacin del objeto como tal, sino
encontrar la solucin a un problema u optimizar una solucin. Esto puede
implicar iterar planteamientos o realizar experimentos y simulaciones, utilizando
objetos de estudio fsicos o abstractos (ej. Mquinas de Turing), para inferir
un planteamiento que satisfaga las restricciones y requisitos que imponga el
contexto. Es as como se utiliza el llamado mtodo de investigacin de ingeniera,
diferente del mtodo cientfico.
La investigacin cientfica en ingeniera en general y en tecnologa de
informacin en particular, busca encontrar soluciones eficaces y eficientes a
problemas simples o complejos, aplicando sistemticamente el conocimiento
cientfico y las herramientas tecnolgicas, para crear el diseo de la solucin,
desarrollar y construir dispositivos, estructuras y procesos, bajo restricciones
y requisitos impuestos por la tecnologa disponible y por consideraciones
econmicas, legales, ambientales y humanas.
Las publicaciones que se presentan en ese primer volumen, representan esta
clase de investigacin cientfica que aborda la solucin de problemas de ingeniera
informtica, buscando hallar el camino para establecer un pequeo universo de
lneas de investigacin que puedan consolidarse y profundizarse en el tiempo,
que nos permitan concentrar recursos y esfuerzos para ganar en profundidad y
rigor cientfico.
Los factores claves para crear en tan poco tiempo la estructura de
investigacin de acadmicos, estudiantes, recursos tecnolgicos y financieros,
han sido el compromiso de los profesores investigadores que conforman el

equipo de investigacin, la seriedad con que han abordado sus trabajos de
investigacin los estudiantes, autores de las publicaciones presentadas, y el
compromiso de las autoridades de la universidad para apoyar la construccin
de la estructura de investigacin en ingeniera de ULACIT, cuyo objetivo
es formar a los profesores y estudiantes de la carrera Ingeniera Informtica
con las competencias para efectuar investigacin cientfica en este campo, que
propicie la produccin de publicaciones que incrementen su desarrollo acadmico
y proyecten a la universidad en respuesta a las necesidades de talento de la
economa costarricense.
En este momento, el sector industrial tecnolgico del pas (diseo,
manufactura y servicios tecnolgicos) emplea a ms de 25.000 ingenieros, de
los cuales ms de 3.000 laboran a tiempo completo en equipos de investigacin,
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 pas, pero estn enfrentando escasez de ingenieros
con formacin en investigacin en ingeniera. De igual forma las empresas estn
haciendo frente a la falta de lderes de equipos de investigacin y administradores
de investigacin, por lo que han manifestado que requieren de apoyo acadmico 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 investigacin de ingeniera est en aumento desde hace cinco aos
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 tecnolgico, ms all de la manufactura, que ha encontrado en el
talento costarricense el capital humano para establecerse y expandirse en el pas.
Msc. Edwin Aguilar Snchez

Decano
Facultad de Ingeniera Informtica
Setiembre de 2016
Comit Evaluador
Este trabajo es producto de varios trabajos presentados en el Workshop en

Ingeniera Informtica y Tecnologas de la Informacin que es organizado por la
Facultad de Ingeniera Informtica de la Universidad Latinoamerica de Ciencia
y Tecnologa (ULACIT).
En este volumen se incluyen los trabajos presentados en el marco de la
tecnologa de la informacin y gestin de proyectos informticos.
El comit evaluador de los trabajos presentados estuvo constituido por los
siguientes profesores:
Edwin Aguilar Snchez
Antonio Gonzlez Torres
Randall Barnett Villalobos
Julio Crdoba Retana
ndice general
Metodologa para la gestin de terceros en procesos de desarrollo de

software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Yeison Nez Snchez y Antonio Gonzlez Torres
Gestin de la Relacin con Terceros y Metodologas giles . . . . . . . . . . . . .
Fabin Chaves Serrano, David Mora Solano y Antonio Gonzlez
Torres
Definicin y Modelado del Proceso de Gestin de la Demanda para
Tecnologa de Informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
David Rodolfo Camacho Quiros, Reagan Ching Fung, Julio Crdoba
Retana y Antonio Gonzlez Torres
Recomendaciones para la Gestin de Incidencias de Tecnologas de la
Informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verny Mora Jimnez, Paulo Viales Wahrmann, Julio Crdoba
Retana y Antonio Gonzlez Torres
Diseo de una arquitectura para la comunicacin entre protocolos en
Internet de las Cosas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marco Crdoba Padilla, Frank Trejos Moya, Fernando Chinchilla
Jimnez y Antonio Gonzlez Torres
Etiquetas de Geolocalizacin en Imgenes Rster para la Identificacin
de Especmenes Biolgicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jonathan Quintana Berros, Esteban Robleto Rodrguez, Antonio
Gonzlez Torres
Caracterizacin de Malware usando Lenguajes de Intercambio de
Inteligencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Randall Barnett Villalobos, Susan Rodrguez Segura, Julio
Chinchilla Moya y Wilson Acua Araya
1
22
35
44
56
67
74
Metodologa para la gestin de terceros en

procesos de desarrollo de software
Yeison Nez Snchez y Antonio Gonzlez Torres
Escuela de Ingeniera,
Universidad Latinoamericana de Ciencia y Tecnologa,
ULACIT, Urbanizacin Tournn, 10235-1000
San Jos, Costa Rica
ynunezs664@ulacit.ed.cr
agonzalez@ulacit.ac.cr
http://www.ulacit.ac.cr
Resumen La tercerizacin 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 estratgicos
del negocio. Sin embargo, el desconocimiento de cules elementos es
necesario considerar en la planificacin de los procesos de tercerizacin
ha contribuido al fracaso de un gran nmero 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 participacin activa de los clientes y usuarios
finales durante todas las etapas del proceso y la falta de seguimiento
y comunicacin con el proveedor. Como consecuencia, el objetivo de este
trabajo de investigacin es proponer una metodologa para la gestin
de la relacin entre clientes y proveedores durante los procesos de
tercerizacin del desarrollo de sistemas. Por lo que se realiza una sntesis
de los procesos y mejores prcticas que deben contemplarse en la gestin
de terceros con el fin de facilitar los procesos de tercerizacin, mejorar
los resultados que se obtienen y contribuir con la generacin de valor
agregado tanto para el cliente como para el proveedor. Como resultado,
este trabajo presenta una metodologa que contempla 7 fases, las cuales
a su vez comprenden entradas, tareas y salidas que son utilizadas por las
fases subsiguientes.
Palabras clave: Gestin de terceros, Outsourcing, tercerizacin,
Adquisicin de software
1.
Introduccin
La evolucin 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 econmicos y humanos para brindar valor
agregado a sus clientes, a la vez que se concentran en alcanzar los objetivos
Nez y Gonzlez
estratgicos del negocio. Con ese fin utilizan como alternativa la tercerizacin1
de servicios, la cual consiste en la contratacin de un proveedor para que ejecute
algunas funciones especficas, que por lo general, no son parte de las actividades
centrales de la empresa.
Aunque se considera que los beneficios de la tercerizacin son numerosos,
se han logrado identificar inconvenientes que se presentan durante su
implementacin, debido a una deficiente gestin de las relaciones entre las partes.
De acuerdo con algunos estudios alrededor de un 30 % de las empresas cancelan
sus contratos de tercerizacin de forma prematura; entre el 20 y 25 % fracasan
durante los primeros dos aos del contrato y el 50 % fracasa en los primeros
cinco aos de vigencia (Grossi y Calvo-Manzano, 2012). Cabe resaltar que los
casos de mayor incertidumbre e inconvenientes se presentan en los procesos de
tercerizacin de software, debido a la complejidad y naturaleza de los tipos de
proyectos.
Los problemas que se asocian con la tercerizacin del desarrollo de software
se presentan por el desconocimiento de los factores que se deben contemplar
durante la etapa de planificacin para adquirir productos de software. Lo cual
tiene como consecuencia que el producto final no responda a las necesidades o no
se ajuste a los requerimientos definidos por el cliente (Paruma, Mera, y Correa,
2014).
Este tipo de inconvenientes suelen presentarse cuando la empresa contratante
no realiza de forma adecuada las siguientes tareas:
1.
2.
3.
4.
5.
Definicin de los requerimientos.

Seleccin y contratacin del proveedor (Paruma y cols., 2014).
Identificacin del alcance del proyecto.
Definicin de la metodologa de desarrollo.
Participacin activa de los clientes o usuarios finales en el proceso de
desarrollo.
6. Adecuada administracin y comunicacin con el proveedor.
A lo cual se debe agregar la ausencia de sistemas de apoyo al proceso de
desarrollo y gestin, as como de herramientas y mtricas de control para el
aseguramiento de la calidad (?, ?).
Como consecuencia, se han preparado diversos documentos e investigaciones
que detallan las mejores prcticas para mitigar estos problemas y apoyar el
proceso de tercerizacin. Sin embargo, la informacin se encuentra dispersa en
diversas fuentes, y no existe una presentacin visual e integral del proceso para
facilitar la planificacin de la calidad y gestin de la comunicacin para guiar de
forma apropiada a los gerentes y directores de proyectos.
El proceso de tercerizacin 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 econmicos. Por
lo cual, los objetivos de este trabajo de investigacin consisten en identificar el
flujo del proceso de administracin de la relacin con terceros y proponer una
1
La tercerizacin es conocida en ingls como outsourcing.
Metodologa para la gestin de terceros en procesos de desarrollo de software
metodologa para sintetizar algunas de las mejores prcticas e investigaciones

realizadas sobre el tema.
Con ese fin, este trabajo de investigacin lleva a cabo una revisin de
bibliografa (seccin 2) para desarrollar una metodologa con las mejores
prcticas para la gestin de proyectos de software en procesos de tercerizacin
(seccin 3) y finalmente presenta las conclusiones y trabajos futuros (seccin 4).
2.
Estado del arte
Los procesos de tercerizacin del desarrollo de software, por lo general, son

complejos, y aunque existe bibiliografa para apoyar a los gestores de estos
procesos, an persiste una serie de desafos que requieren atencin.
Las actividades de alto nivel de un proceso de tercerizacin contempla la
identificacin del tipo de proyecto que se quiere llevar a cabo, pero de forma
concreta y detallada tambin toma en cuenta qu es lo que se va a desarrollar,
cmo se va a llevar a cabo y quienes estarn involucrados durante su desarrollo.
Con base en esto, es relavante considerar los siguientes puntos (selleo, 2016)
cuando se desea iniciar un proceso de tercerizacin:
Cules 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? La respuesta a esta pregunta tiene por fin definir de forma precisa qu
es lo que se requiere hacer y cules son sus requerimientos.
Cmo? Por su parte esta pregunta debe ser respondida en el contexto de la
forma como se llevaran a cabo las tareas o proyectos, e involucra no solo la
metodologa a utilizar sino tambin la estructura del equipo de trabajo que
va a participar en su desarrollo.
Quin? Es importante conocer quienes sern los usuarios del sistema que se
desarrolle, quienes son los gerentes o ejecutivos que apoyan el desarrollo y
quienes estarn participando en el proyecto, tanto en la etapa de definicin
de requerimientos como de seguimiento y aceptacin.
Lo anterior se puede realizar despus de efectuar bechmarking interno y
externo (Franceschini, Galetto, Pignatelli, y Varetto, 2003). En este contexto,
estos dos tipos de benchmarking se entiende la siguiente forma:
Benchmarking interno: consiste en analizar las competencias centrales de la
empresa y la identificacin de los procesos que sern tercerizados, de acuerdo
con los resultados de un anlisis que evidencia la reduccin de costos o la falta
de habilidades de los empleados. En esta etapa se define el tipo de relacin
que se establecer con la empresa proveedora, de acuerdo con los intereses
del cliente. La relacin que se establece puede ser tradicional, temporal,
estratgica 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 .
Nez y Gonzlez
En lnea con lo anterior, un modelo para la administracin del proceso de

tercerizacin puede contemplar (Paruma y cols., 2014) los siguientes pasos:
Planificacin: en esta etapa se determina la necesidad de adquisicin, los
requisitos del software a adquirir, la identificacin de los proveedores
potenciales y criterios de aceptacin en conjunto con el plan de adquisicin.
Por lo que se procede a efectuar la planificacin 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.
Seleccin del proveedor: en esta etapa se lleva a cabo la seleccin 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. se formaliza la relacin entre el cliente
y el proveedor que incluye la celebracin del contrato.
Monitoreo: tiene como fin dar seguimiento al progreso de los proveedores en el
cumplimiento de las metas, y efecta una revisin 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 desempeo del proveedor
mediante curvas de eficiencia. stas curvas consisten en establecer por
cada acuerdo de servicio dos lneas. La primera lnea se relaciona con los
objetivos que se busca lograr y la segunda lnea refleja los resultados del
rendimiento del proveedor y sirve para determinar las brechas en el proceso
de implementacin mediante dos ejes de evaluacin (tiempo y nivel de
acuerdo de servicio), los cuales son evaluados en funcin de la cantidad
de fases que se desean evaluar. para tomar acciones correctivas en caso de
incumplimiento (Franceschini y cols., 2003).
Aceptacin: durante esta etapa se lleva a cabo la evaluacin del producto,
aplicando las pruebas y criterios de aceptacin 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 desempeo del
sistema y de los tiempos de respuesta del proveedor.
En general, las tareas y pasos que contempla el proceso de tercerizacin
se puede agrupar en 5 grandes fases: preparacin, seleccin del proveedor,
transicin, administracin de las relaciones y reconsideracin (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 planificacin para la tercerizacin debe ser integral y debe definir el
tipo de relacin que se desea tener con la empresa proveedora. sta relacin
es influenciada por la importancia de la actividad y los riesgos de realizar la
tercerizacin, lo cual se puede representar mediante una matriz segn el tipo
de relacin: colaboracin competitiva, colaboracin cercana, muchos suplidores
o suministros seguros (McIvor, 2005).
Debido a la aceptacin de la tercerizacin como un mtodo 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 coordinacin entre los
procesos del cliente y el proveedor, determinar roles y responsabilidades, el tipo
de informacin que se debe comunicar y factores para la gobernanza del proceso
(CabinetOffice, 2011). En la misma direccin, tambin se busca asegurar que
los contratos estn alineados con las necesidades del negocio, administrar el
rendimiento, negociar y formalizar los contratos y mantener polticas para la
gestin del ciclo de vida del proyecto (CabinetOffice, 2011).
Otro referente utilizado en la planificacin 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 prcticas de PMI, y tomando en
cuenta los problemas que se presentan durante la gestin de terceros en los
procesos de desarrollo de software, es importante resaltar los siguientes puntos:
Gestin del alcance: se deben incluir las caractersticas y funciones que
requieren los usuarios mediante la adecuada definicin de requerimientos.
Gestin de las comunicaciones: este tipo de gestin es necesaria para
propiciar una comunicacin 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.
Gestin 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 participacin en las decisiones y ejecucin de
proyectos.
El resultado final de la tercerizacin 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 razn 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 al proyecto, en torno a los elementos de calidad de software
(Mendoza, Prez, y Grimn, 2005).
La incorporacin de la calidad en la elaboracin de productos o prestacin 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 evaluacin final. La calidad del proceso de desarrollo
garantiza la calidad del producto y como consecuencia no se pueden desvincular
(Mendoza y cols., 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, 2013).
Nez y Gonzlez
Con base en los conceptos discutidos hasta este punto, y la recopilacin de

normas e investigaciones con respecto a las evaluaciones de calidad Mendoza et
al. (Mendoza y cols., 2005) proponen un marco de evaluacin dividido en los
siguientes niveles:
Nivel 0: este nivel contempla el valor ms alto en la jerarqua y se corresponde
con los aspectos externos e internos tanto del proceso como del producto.
Nivel 1: en este nivel se definen 6 categoras de evaluacin para el producto y
5 categoras para el proceso de desarrollo.
Nivel 2: este nivel relaciona las caractersticas de cada unas de las categoras
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 mtricas utilizadas para medir
cuantitativamente cada una de las caractersticas que fueron definidas con
el fin de determinar si la calidad planificada es satisfactoria o no.
La estimacin adecuada de la calidad realiza clculos tanto para estimar la
calidad del software como producto como del proceso, y contribuye a identificar
las caractersticas que no han sido satisfechas por el sistema desarrollado
(Mendoza, Prez, Grimn, y Rojas, 2002). Este proceso se divide en tres fases, en
donde la primera fase se corresponde con la evaluacin del proceso de desarrollo,
la segunda fase con la valoracin del sistema y la tercera fase con la integracin
de los resultados que combinan ambas etapas.
De acuerdo con el anlisis realizado, varios trabajos de investigacin
sugieren diferentes fases para el proceso de tercerizacin. Sin embargo, los
trabajos estudiados no contemplan aspectos relacionados con la gestin de las
comunicaciones, la gestin de los interesados y el aseguramiento de calidad, los
cuales son aspectos que deben estar presentes en la definicin de una metodologa
para gestionar la relacin con terceros durante los procesos de tercerizacin.
Como consecuencia, la metodologa que se propone en la siguiente seccin
sintetiza las fases fundamentales que se deben tomar en cuenta en los procesos
de tercerizacin y tiene presentes aspectos para mejorar la comunicacin, la
participacin activa de las partes y la calidad del producto final.
3.
Fases para la gestin de terceros en proyectos

de desarrollo de software
En esta seccin se presenta la propuesta de una metodologa para apoyar la

gestin de los procesos de tercerizacin, usando como referencia la revisin y el
anlisis efectuado en la seccin 2. La metodologa propuesta se divide en 7 fases:
1.
2.
3.
4.
Inicio.
Planificacin.
Seleccin y contratacin del proveedor.
Ejecucin.
5. Administracin de la relacin con el proveedor.

6. Aceptacin y cierre.
7. Reconsideracin.
La relacin entre las fases mencionadas con los procesos aseguramiento de
la calidad, administracin de la relacin y gestin de la comunicacin se puede
observar en la figura 1, adems de los vnculos que existen entre estos.
La gestin de la comunicacin se debe desarrollar durante casi todas las fases
de la tercerizacin (con excepcin de las fases Inicio y Planificacin), e incluye
la administracin de la relacin y el aseguramiento de la calidad. El fin de este
proceso es garantizar una mejor comunicacin entre el cliente y el proveedor
por medio de herramientas, mtodos y tcnicas que faciliten el intercambio de
informacin desde las etapas iniciales del desarrollo del sistema.
Por su parte la administracin de la relacin tiene por objetivo mejorar la
relacin entre el proveedor, usuarios e interesados para garantizar la comprensin
de necesidades, efectuar el seguimiento del avance del proyecto mediante
evaluaciones durante el desarrollo y en durante la entrega del producto. En
cuanto al aseguramiento de la calidad, esta debe estar presente desde el inicio de
la ejecucin o desarrollo del sistema y juega un papel preponderante en la fase
de aceptacin y cierre.
Figura 1. Relacin entre las fases y procesos para la gestin de terceros durante el
desarrollo de software.
En las siguientes secciones se explica con detalla las fases contempladas en

la figura 1.
Nez y Gonzlez
3.1.
Inicio
Esta fase tiene por fin verificar la necesidad de desarrollar un sistema

por medio de la tercerizacin, y si dicha verificacin es positiva, justificar
su desarrollo, obtener el apoyo interno, y formalizar el inicio del proceso de
contratacin con el apoyo de los ejecutivos y directores. Alguna de las tareas
que es necesario contemplar en esta fase son las siguientes:
Anlisis, desarrollo interno o externo?: se debe realizar la evaluacin
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
decisin:
Capacidades esenciales de la organizacin: este factor hace nfasis en
la verificacin de las capacidades centrales del negocio y su principal
actividad econmica, 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: tiene por fin realizar
una evaluacin 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
tercerizacin del desarrollo para delegar la responsabilidad en una
organizacin experimentada que pueda asegurar el xito y lograr una
rentabilidad efectiva con el desarrollo del proyecto.
Comparacin de la capacidad interna y los proveedores: tiene por
fin determinar si las herramientas, conocimientos, experiencia, capacidad
de administracin y capacidades tcnicas de los proveedores son mayores
a las capacidades internas de la organizacin para llevar a cabo el
desarrollo exitoso del proyecto.
Individualizar los proyectos a tercerizar: esta tarea tiene por fin comparar
la eficiencia de las actividades o procesos que realiza la organizacin, usando
como base posibles prdidas 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 constitucin: se
encarga de determinar la necesidad de adquisicin de una forma general
para presentar el proyecto a los encargados de la organizacin para obtener
su aceptacin y compromiso. Esta tarea se puede realizar mediante diferentes
tcnicas:
Historias de usuario.
Elaboracin de la descripcin general del sistema por medio de reuniones,

sesiones, foros, talleres o lluvia de ideas que involucren no solo a los altos
jerarcas sino tambin a los usuarios finales.
Identificacin de los interesados: corresponde a la identificacin de las
personas internas que pueden ser beneficiadas o perjudicadas con el
desarrollo del sistema. Esta tarea tiene por fin garantizar la participacin
de esas personas en el proceso.
3.2.
Planificacin
Esta fase corresponde a la definicin de los aspectos que se deben de tomar

en cuenta para controlar la ejecucin del proyecto y obtener el producto deseado.
Por lo que se debe efectuar la definicin adecuada del alcance, requerimientos,
elementos de calidad que se deben evaluar, recurso humano necesario,
formas de comunicacin con el proveedor, definicin de criterios de seleccin
de proveedor, tipo de contrato a utilizar y contenido presupuestario.
Como consecuencia, stas tareas se pueden desarrollar de la siguiente manera:
Definicin del alcance: tiene por fin brindar el panorama de alto nivel de los
requerimientos del sistema, por lo que es necesario detallar (?, ?):
La visin general de la aplicacin o producto deseado.
El propsito del nuevo sistema, as como el problema (objetivo o
necesidad) que busca resolver y su definicin para alcanzar el xito.
La lista de funcionalidades, caractersticas del producto y usuarios que
lo usarn.
Los requisitos de desempeo, velocidad, disponibilidad, volumen y
fiabilidad.
La tecnologa a utilizar, la integracin de requisitos como el lenguaje
de desarrollo, el sistema operativo y sistemas que deben trabajar en
conjunto con la nueva aplicacin.
Existen circunstancias en las cuales segn el tipo de sistema, no se tiene
claridad para definir el alcance al inicio de la planificacin. 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 seleccin del tipo de contrato para
estos escenarios para no afectar los costos o el entregable final.
Anlisis y definicin de requisitos funcionales y no funcionales: se
establecen los requerimientos de bajo nivel del sistema y contempla la
definicin de todas las necesidades que debe satisfacer para alcanzar el
producto deseado, segn los objetivos planteados y el problema que busca
resolver.
Realizar el presupuesto: para identificar la inversin que se debe efectuar
para el desarrollo del software.
Definir el plan de aseguramiento de la calidad: se encarga de planificar
los procesos, requerimientos, salidas y canales de retroalimentacin de la
calidad del sistema durante el ciclo de vida del proyecto. Para realizar
10
Nez y Gonzlez
la gestin de la calidad de software se deben considerar (IEEE Computer

Society, 2014) las siguientes fases:
Planificacin: esta tarea consiste en determinar cul o cules estndares 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 revisin de la calidad del software.
Aseguramiento: esta actividad se encarga de asegurar la calidad mediante
la definicin de las actividades para satisfacer los requerimientos,
necesidades y costos en tiempo, de acuerdo con el cronograma del
proyecto. Pero adems define y evala si el proceso seleccionado para
el desarrollo es apropiado, contempla la definicin de los objetivos de
calidad e identifica las medidas tcnicas y los procedimientos para el
reporte de problemas y la ejecucin de acciones correctivas.
Con base en lo anterior, se recomienda seleccionar las categoras de calidad
(Mendoza y cols., 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, comprensin 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 seleccin de un mximo de 3 categoras,
siendo obligatorio seleccionar la evaluacin de la funcionalidad, debido a que
evala el cumplimiento de los requerimientos definidos. La recomendacin
de seleccionar un mximo de 3 categoras se debe a que la eleccin de un
nmero mayor puede desencadenar que la evaluacin de una categora entre
conflicto en conflicto con la evaluacin de otra categora. La seleccin de las
otras dos categoras adicionales depende de la estrategia y necesidades que
la organizacin busca satisfacer con el sistema. Por ltimo, en esta fase y con
base en las categoras seleccionadas, se seleccionan las mtricas cuantitativas
que permitirn realizar la evaluacin y estimacin de la calidad del producto.
Planificar la gestin de recursos humanos: es necesario planificar los roles
necesarios para la gestin del proyecto y el desarrollo exitoso del sistema
(Paruma y cols., 2014). Estos roles pueden variar de acuerdo con el tipo de
organizacin y proyecto, pero se recomienda tener en cuenta los roles que se
presenta en el cuadro 3.2.
Hacer el plan de comunicaciones: contempla determinar el flujo de
comunicacin entre el cliente y el proveedor para garantizar la participacin
activa de los interesados y canalizar la informacin por medio de un
11
Puesto/Rol
Director (Dir)
Descripcin de responsabilidad
Es la persona con conocimiento de los procesos de la
organizacin y tiene la responsabilidad de administrar el
proyecto.
Encargado de
Es el encargado de realizar, coordinar y efectuar la contratacin
adquisiciones (EA) del proveedor, con base en los parmetros definidos, y es el
contacto directo entre el cliente y el proveedor, con el fin de
centralizar la comunicacin y el flujo de informacin.
Programador o
Es la persona o grupo de personas que colaboran en la
Ingeniero de
definicin de los alcances y requerimientos del sistema. Esta
software (IS):
persona puede ser el contacto tcnico para comunicaciones con
el proveedor cuando se est ejecutando el proyecto.
Encargado de
Es la persona o grupo con conocimientos en aspectos legales
contratacin (EC): para el establecimiento y negociacin 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. Enva informacin 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 participacin en
el proceso para asegurar su satisfaccin con el producto final.
Cuadro 1. Roles de participantes en el proceso de tercerizacin de software
encargado, el cual facilite el proceso y est en disposicin de utilizar

las herramientas para hacer la gestin adecuada de la comunicacin. Los
elementos bsicos que debe tener el plan de comunicaciones (Project
Management Institute, 2013) son los siguientes:
Requisitos de comunicacin de los interesados.
Tipo de informacin que debe ser comunicada, incluidos el idioma,
formato, contenido y nivel de detalle.
Motivo para distribuir dicha informacin.
Plazos y frecuencia para la distribucin de la informacin y recepcin de
las confirmaciones o respuestas.
Responsable de comunicar la informacin.
Responsable de autorizar la divulgacin de informacin confidencial.
Persona o grupos que recibirn la informacin.
Mtodos o herramientas utilizadas para transmitir la informacin, tales
como memorandos, correo electrnico o comunicados de prensa.
Recursos asignados para las actividades de comunicacin, incluidos el
tiempo y presupuesto.
12
Nez y Gonzlez
Proceso de escalamiento, con identificacin de los plazos y la cadena de

mando (nombres) para el escalado de los incidentes que no se puedan
resolver a un nivel inferior.
Mtodo para actualizar y refinar el plan de gestin de las comunicaciones
a medida que el proyecto avanza y se desarrolla.
Glosario de terminologa comn.
Diagramas del flujo que sigue la informacin del proyecto, flujos de
trabajo con la posible secuencia de autorizaciones, lista de informes y
planes de reuniones.
Restricciones en materia de comunicacin que se derivan de la legislacin
o normativa, la tecnologa o las polticas de la organizacin.
Definir el tipo de contrato a utilizar: La definicin del tipo de contrato
a utilizar se debe basar en el tipo de producto y proyecto (Project
Management Institute, 2013), y podra 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 especificacin 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, ms los honorarios del
proveedor. Este tipo de contratos ofrece flexibilidad para reorientar al
proveedor si el alcance del trabajo no se puede definir con precisin al
inicio y requiere modificaciones.
Contrato por tiempo y materiales: corresponde a un hbrido 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
informacin 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.
Establecer los criterios de seleccin del proveedor: esta tarea realiza la
identificacin de los criterios bsicos con lo cuales sern 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 tcnica, riesgo, reputacin, posicin en la
industria, comprensin de las necesidades, garanta presentada, referencias,
desempeos anteriores, posicin financiera, capacidad de respuesta,
experiencia, recursos humanos, participacin de mercado, administracin,
organizacin y soporte. Es importante establecer, segn las prioridades de
la organizacin, el peso relativo de cada criterio para calcular la calificacin
final.
Identificar proveedores potenciales: corresponde a la identificacin de los
proveedores que pueden desarrollar el sistema con base en la experiencia de
expertos, la experiencia de proyectos anteriores y el anlisis ded mercado.
13
Establecer y documentar los criterios de aceptacin: Estos

criterios
corresponden a la especificacin de las necesidades, requerimientos,
capacidades tcnicas y de calidad que el cliente establece como mnimos
para aceptar los entregables y el producto final.
Realizar el enunciado del trabajo: este
documento
contempla
la
informacin del alcance y requerimientos del sistema con suficiente
detalle para permitir que los proveedores realicen el anlisis y determinen
si estn 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 tercerizacin.
3.3.
Seleccin y contratacin del proveedor
La fase de seleccin y contratacin conlleva efectuar la recepcin de ofertas,

efectuar la evaluacin segn los criterios definidos, proceder con la seleccin del
proveedor, preparar el contrato y formalizar la relacin contractual(Paruma y
cols., 2014), las cuales se detallan a continuacin:
Anunciar la tercerizacin: con base en el enunciado del proyecto, se
anuncia la necesidad de contratar a un proveedor (i.e. mediante licitacin,
contratacin directa o invitacin).
Recepcin 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 organizacin, se realiza
la seleccin del proveedor con base en los criterios de seleccin establecidos y
segn la estrategia de la organizacin con respecto al peso en la calificacin
de cada criterio.
Seleccin del proveedor: se recomienda utilizar una matriz de calificacin
cuantitativa con los resultados de las evaluaciones de los criterios, para
obtener la calificacin de los proveedores y garantizar la mejor seleccin.
Preparacin y negociacin del contrato: esta tarea debe contemplar al
menos la definicin del alcance, requisitos de rendimiento, cronograma,
acuerdos y responsabilidades, informacin de puntos de contacto, periodo y
lugar de ejecucin, canales y frecuencia de las comunicaciones, estructura del
precio, trminos de pago, criterios de inspeccin y aceptacin de entregables,
garantas presentadas por el proveedor, acuerdos de servicio y soporte,
proceso para hacer cambios al proyecto, confidencialidad, derechos de autor
y propiedad intelectual, derechos de terminacin, criterios de rendimiento de
los proveedores (SLA), informes de desempeo, incentivos y penalizaciones
(Project Management Institute, 2013) .
Adjudicacin del contrato: se establece un acuerdo contractual con el
proveedor y se formaliza mediante la firma de las partes interesadas dando
lugar al inicio formal del desarrollo del producto especificado.
14
Nez y Gonzlez
3.4.
Ejecucin
La fase de ejecucin contempla la etapa de desarrollo del sistema y requiere

la participacin activa del cliente y es necesario realizar 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 evaluacin de criterios
mediante revisiones, auditorias e inspecciones (ver 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 comprende:
Revisiones de administracin: se encarga de monitorear el progreso del
proyecto, del cronograma y la efectividad de la gestin del proceso de
desarrollo realizando comparaciones con lo planificado.
Revisiones tcnicas: se encargan de realizar una evaluacin del producto con
base en las categoras de evaluacin definidas y verificacin de acuerdo a las
mtricas establecidas.
Evaluacin de tcnicas estticas: son responsables de examinar la
documentacin (requerimientos, diseo, modelo, entre otros aspectos) y el
cdigo fuente del software sin proceder con su ejecucin.
Evaluacin de tcnicas dinmicas: determinan el cumplimiento de las
medidas o niveles de calidad deseados del software ejecutando el cdigo
previo a realizar el lanzamiento.
3.5.
Administracin de la relacin
La administracin de la relacin con el proveedor enfoca sus esfuerzos en

la participacin 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, compresin y solucin de las necesidades
(ver figura 3). Adems, contempla realizar evaluaciones del avance del proyecto
mediante el uso de herramientas colaborativas y representaciones grficas de
cumplimientos de tareas para reducir las distancias fsicas, culturales e 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 diferencia
de criterios durante el desarrollo del proyecto. Las tareas que sustentan esta fase
son las siguientes:
Efectuar el plan de gestin de comunicaciones: se recomienda llevar a
cabo las actividades del plan de gestin de comunicaciones, gestionar las
reuniones, comunicacin y participacin activa de los interesados e involucrar
a los usuarios en el proceso de desarrollo, as como desarrollar las siguientes
actividades de apoyo:
Maximizar la presencia fsica de los interesados o usuarios finales
en el equipo de desarrollo para lograr mayor cumplimiento de los
requerimientos, proporcionar retroalimentacin y resolver ambigedades
en los requerimientos.
15
Figura 2. Diagrama de gestin de calidad
Efectuar por lo menos dos reuniones formales a la semana, siempre y

cuando las ubicaciones fsicas del cliente y el proveedor lo permitan,
contemplando una reunin 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 fsicas semanales entre los
interesados y el equipo de desarrollo debido a limitaciones geogrficas,
debido a la ubicacin de los equipos en diferentes localidades, es necesario
ajustar las reuniones fsicas siendo requerido realizar al menos una al mes
y efectuar por lo menos una reunin virtual a la semana.
Obtener informacin de las direcciones de contacto del proveedor como
grupos de correos electrnicos, nmeros de telfono de los encargados,
direcciones de contacto para realizar vdeo-conferencias e informacin de
las reuniones presenciales.
Es importante que los mensajes que se intercambien sean concretos,
coherentes, completos, claros, concisos y correctos, sin importar el medio
de comunicacin que se utilice.
Representar de forma visual el flujo de trabajo es una de las mejores
opciones y formas de mantener la comunicacin. Por lo que se recomienda
usar un tablero de Kanban para que ambas empresas de manera visual
16
Nez y Gonzlez
Figura 3. Diagrama de administracin de la relacin con el proveedor
puedan observar cuales son las labores que estn pendientes, saber cules
se estn ejecutando para preparar y efectuar las evaluaciones de calidad,
as como cules estn en proceso de pruebas o completamente listas.
Utilizar herramientas de trabajo colaborativo para la comunicacin entre
las organizaciones (chats y correos electrnicos), gestin del conocimiento
(wikis, gestin de notas, gestin de fotos, almacenamiento en lnea,
ediciones colaborativas, publicacin de documentos y presentaciones) y
la gestin del proyecto (control del calendario, seguimiento de reuniones,
eventos, controlar los hitos, las tareas pendientes, herramientas de
responsabilidades y distribucin del trabajo). Adems, es importante
elaborar mapas mentales y tableros colaborativos, por ejemplo, mediante
el uso de conceptboard"para la inclusin de comentarios y notas o
corkboard"para incluir notas a los participantes del proyecto.
Informar el desempeo del proveedor: se encarga de recopilar y distribuir
informacin de desempeo. Por lo que se pueden comparar el cumplimiento
de los requerimientos para comprender y comunicar el avance, el desempeo
y el cumplimiento del proyecto mediante el anlisis de curvas de eficiencia,
17
adems 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.
Presentacin de hallazgos: los informes de desempeo y la participacin de
los interesados en el proceso permiten realizar revisiones de incidentes,
problemas, retroalimentacin u oportunidades de mejora, las cuales es
necesario comunicarlas, controlarlas y brindarles seguimiento para asegurar
su resolucin satisfactoria.
Identificar afectaciones: en conjunto con los interesados, es necesario
identificar cambios importantes que puedan afectar el servicio durante la
siguiente fase de ejecucin del proyecto, as como los cambios que provocaron
incidentes.
Aspectos ajenos al proceso: esta tarea se encarga de evaluar los eventos
clave que requieren atencin especial por parte del proveedor.
Gestionar la resolucin 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.
Aceptacin y cierre
sta fase hace nfasis en la recepcin por parte del usuario e interesados de
los entregables parciales y finales para evaluarlos con base en los criterios de
aceptacin acordados, los cuales deben estar alineados con las caractersticas de
calidad planificadas y las pruebas de evaluacin. Las tareas bsicas de esta fase
(Paruma y cols., 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 aceptacin para el
cumplimiento satisfactorio del producto.
2. Cuando en el proceso de pruebas se identificar no conformidades, es necesario
realizar el reporte para proceder con las correcciones necesarias, caso
contrario, se procede con la aceptacin del entregable.
3. Administrar los contratos y facturas canceladas o pendientes de pago para
el proveedor.
4. Confirmar que final del proyecto que todos los entregables son aceptados.
5. Al cerrar las adquisiciones, se procede con la conclusin del contrato,
evaluacin general del proveedor y el registro de experiencias aprendidas
para utilizarlas en futuros proyectos.
18
Nez y Gonzlez
3.7.
Reconsideracin
La fase de reconsideracin corresponde a una evaluacin con base en la

experiencia e informacin 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 inversin o realizar los cambios y ajustes
necesarios para alinearlos a los objetivos estratgicos.
2. Cuando el proveedor lleva a cabo su trabajo de acuerdo con los niveles de
acuerdo de servicio y el cumplimiento de criterios y evolucin del proyecto,
pero existe una percepcin de insatisfaccin final, es necesario verificar el
ajuste de las mtricas de evaluacin debido a que puede ser la consecuencia
de una inapropiada definicin de los criterios en la planificacin.
3. Reconsiderar continuar o cambiar de proveedor (en caso de incumplimientos
comprobados y verificables) y evaluar el impacto del costo que sta decisin
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 verificacin 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 inversin,
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 operacin pueda significar para la organizacin.
La figura 4 presenta de manera visual las fases que definidas para la gestin de
terceros durante los procesos de desarrollo de software. En esta figura se pueden
notar en primera instancia los roles mnimos que se consideran necesarios para el
desarrollo de cada una de las fases. Esta metodologa individualiza las entradas
y subprocesos y define las salidas que se espera obtener.
Como se mencion, la fase de administracin de la relacin no es una fase
de ejecucin secuencial, debido a contiene las fases de ejecucin, aceptacin y
cierre, y reconsideracin. Adicionalmente, en el diagrama se hace referencia a
la utilizacin de una base de datos para almacenar datos relacionados con la
gestin, evaluacin del proveedor y experiencias aprendidas durante el proyecto
o proyectos previos.
4.
Conclusiones y trabajos futuros
La gestin de las relaciones con terceros es un elemento crtico cuando

se realiza la contratacin de proveedores para el desarrollo de sistemas de
software. Por lo que el desarrollo de este trabajo contempl la elaboracin de una
metodologa para realizar la gestin adecuada de un proyecto de tercerizacin.

19
Figura 4. Diagrama propuesto de gestin de terceros para el desarrollo de software
20
Nez y Gonzlez
La metodologa es una sntesis de los procesos y mejores prcticas que deben

contemplarse en la gestin de terceros y resume aspectos fundamentales sobre
las fases, tareas y salidas que se esperan en cada una de las fases de un proyecto
de esta naturaleza. Por lo que se espera que sea una herramienta til para
orientar y brindar una visin general a los especialistas de los aspectos que
deben contemplar durante la planificacin y desarrollo de proyectos de software
contratados a terceros.
La incorporacin de aspectos como la planificacin de la administracin de
la relacin con los proveedores, la gestin de la comunicacin y el aseguramiento
de la calidad durante todo el proceso, desde la concepcin del sistema hasta su
aceptacin, son los elementos de mayor relevancia en la metodologa debido a su
transcendencia para el xito del desarrollo de sistemas de calidad.
Cabe resaltar que una de las virtudes de la metodologa desarrollada es la
sntesis visual que ofrece del proceso, lo cual ofrece un panorama claro de la ruta
y actividades que se pueden considerar. Esto tiene por fin facilitar la comprensin
del proceso, facilitar la comunicacin con la gerencia y mejorar la aplicacin del
proceso.
Como trabajo futuro se recomienda evaluar el uso de herramientas
colaborativas y de gestin de proyectos, e identificar las mejores opciones
disponibles para ser integradas en un proceso de tercerizacin. Adems, tambin
se recomienda desarrollar una metodologa que contribuya con el correcto
levantamiento de requerimientos para el desarrollo de sistemas, tomando en
cuenta la participacin activa de usuarios e interesados.
Referencias
CabinetOffice. (2011). Itil service strategy (second ed.). 2011.
CENDITEL, F. (2013). Aseguramiento de calidad en el desarrollo de software
libre. Venezuela, May.
Franceschini, F., Galetto, M., Pignatelli, A., y Varetto, M. (2003). Outsourcing:
guidelines for a structured approach. Benchmarking: An International
Journal , 10 (3), 246260.
Grossi, L., y Calvo-Manzano, J. A. (2012). Mejora de procesos en el mbito
de adquisicin: Un modelo de decisin para la seleccin de proveedores de
ti. CISTI (Iberian Conference on Information Systems & Technologies /
Conferncia Ibrica de Sistemas e Tecnologias de Informao) 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 16th annual conference of poms,
chicago.
Mendoza, L. E., Prez, M. A., Grimn, A., y Rojas, T. (2002). Algoritmo
para la evaluacin de la calidad sistmica del software. En Proceedings
Referencias
21
of 2nd ibero-american symposium on software engineering and knowledge

engineering (jiisic02), salvador, brasil, october 2002 (pp. 8596).
Mendoza, L. E., Prez, M. A., y Grimn, A. C. (2005). Prototipo de modelo
sistmico de calidad (mosca) del software. Computacin y sistemas, 8 (3),
196217.
Paruma, L. R. E., Mera, G. L. G., y Correa, F. J. P. (2014). Mtodo para
la adquisicin de software en pequeas organizaciones. REVISTA UIS
INGENIERAS , 13 (1).
Perunovi, Z., y Pedersen, J. L. (2007). Outsourcing process and theories. En
Proceedings of the poms 18th annual conference, may 47, dallas, texas,
007 (Vol. 3).
Project Management Institute, I. (2013). Gua de los fundamentos para la
R (fifth ed.). Autor
direccin de proyectos (gua del pmbok )
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
Gestin de la Relacin con Terceros y

Metodologas giles
Fabin Chaves Serrano, David Mora Solano y Antonio Gonzlez Torres
San Jos, Costa Rica
[fchavess976,dmoras530]@ulacit.ed.cr
Resumen La tercerizacin del desarrollo de software es una prctica

comn entre muchas empresas. Sin embargo, con frecuencia el resultado
final no satisface las necesidades del cliente debido a la mala
comunicacin, creacin de falsas expectativas, deficiente transferencia
del conocimiento, la inadecuada definicin del alcance del proyecto y
el escaso involucramiento del cliente. A lo anterior se debe agregar
que los modelos y estndares ms utilizados no contemplan detalles
sobre la forma en que se puede gestionar la relacin que establecen los
clientes y proveedores. Como consecuencia, el objetivo de este trabajo de
investigacin es proponer un modelo que sirva como gua para apoyar la
gestin de las relaciones con terceros, utilizando como base los principios
de las metodologas giles ms importantes, las cuales contemplan el uso
de microciclos y la constante comunicacin con los usuarios y clientes.
Palabras clave: Tercerizacin, relacin con terceros, desarrollo gil
1.
Introduccin
El creciente y rpido cambio de la tecnologa 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 evolucin de los servicios y productos que
ofrecen las compaas. 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 tecnologas, por los problemas que se originan en la mala
gestin y deficiencias tcnicas. Por esa razn, la tercerizacin ha sido vista como
una posible solucin para mejorar la capacidad de respuesta de los negocios y
mejorar su estructura de costos.
En los ltimos aos la tercerizacin ha crecido de forma considerable y se ha
expandido de manera rpida para brindar servicios de toda ndole, incluyendo
desarrollo de software, soporte tcnico, reclutamiento de personal, finanzas y
contabilidad, entre otros.
Gestin de la relacin con terceros y metodologas giles
23
En la actualidad la tercerizacin de desarrollo de software es de alta relevancia

y muy popular, pases como India y China son grandes exponentes de esta
tendencia. Sin embargo, el nmero de casos donde el producto no se entrega
a tiempo es elevado, el intercambio de informacin entre las partes es deficiente
y no se cumple con la mayora 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 comunicacin,
la falta de participacin activa de los clientes y la creacin de falsas expectativas.
El objetivo de este trabajo de investigacin es preparar una gua de
mejores prcticas, tomando como base los principios de las metodologas
giles. El fin de esta gua es contribuir con la disminucin de los efectos
negativos de la tercerizacin de desarrollo de software y facilitar la adecuada
comunicacin, transferencia de conocimiento, establecimiento de expectativas y
el entendimiento y control entre los clientes y los proveedores.
2.
Estado del arte
La tercerizacin consiste en el traslado de la ejecucin de parte de los procesos

del negocio a otra empresa, la cual cuenta con la especializacin y capacidades
para desarrollar dicha actividad como un servicio a ms bajo costo y de forma
ms eficiente que la empresa contratante. La tercerizacin se ha convertido para
muchas compaas en una solucin prctica para mejorar su funcionamiento.
Los procesos que se transfieren no forman parte del ncleo del negocio, no
son esenciales ni crticos, aunque en algunos casos documentados (Girotra y
Netessine, 2012) se ha evidenciado que estos tambin son transferidos a terceras
empresas.
La tercerizacin suele confundirse con la subcontratacin, subcontratacin
internacional y externalizacin al extranjero, los cuales funcionan de forma
diferente:
La subcontratacin: 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).
Subcontratacin internacional: cuando
una
compaa
traslada
completamente sus procesos de negocio a otro pas distinto al de origen, se
habla de subcontracin internacional. Esta situacin es relativamente rara
ya que es arriesgada(Dolgui y Proth, 2013).
Externalizacin al extranjero: la empresa contratada se encuentra en un
pas diferente al de la empresa que contrata. As que la localizacin diferencia
el concepto(Dolgui y Proth, 2013).
Debido al auge de la tercerizacin muchas compaas buscan como
implementarlo en sus negocios.Estas empresas investigan que beneficios les puede
traer y que impacto tiene. Esta metodologa trae consigo diversos beneficios
y puede mejorar el valor de la firma del cliente de muchas maneras, como
24
Chaves et al.
por ejemplo el acceso a la base de la competencia. Recientes investigaciones

encontraron que la reduccin de costos se sita en la posicin ms alta entre
otros beneficios de la tercerizacion(Kakumanu y Portanova, 2006; Bersin, 2005).
Por otra parte la tercerizacin trae consigo algunas desventajas como las
siguientes:
El dilema de la competencia: se genera cuando el cliente y el vendedor
establecen entre si una relacin estrecha, donde el flujo de informacin
es vasta e inclusive se comparte informacin 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).
Prdida de la iniciativa por el cliente: el cliente genera una elevada
dependencia del vendedor, limitando su libertad de accin, inclusive los
costos generados por el vendedor llegan a ser altos, pero debido a la
dependencia no se puede prescindir de estos.
La tercerizacin fuera de las fronteras a pases desarrollados: se
genera cuando un producto o una parte del producto se soluciona atreves
de la tercerizacin en otro pas y este por consecuencia termina siendo ms
barato. Esto causa que una vez el producto se venda, tendr repercusiones
en el mercado para compaas locales, las cuales no podran competir con
dichos precios.Tambin, si la misma compaa fabrica productos similares
pero de manera local, se vern afectados por los productos que fueron
tercerizados.
La tercerizacin de software, trae consigo diferentes problemas, esto causa que
algunos proyectos no sean exitosos. Diversas investigaciones, han determinado
que los problemas ms comunes son la mala comunicacin, la ausencia del cliente
durante el proyecto y la generacin de falsas expectativas. Al respecto, existe un
gran nmero 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 tercerizacin no ha funcionado como se desea. Entre esos
aspectos se encuentran los objetivos, la relacin entre el cliente y el proveedor,
la calidad del servicio, los problemas de comunicacin y la mala gestin (Senz,
Cmara, Calvo-Manzano, y Arcilla, 2014).
El anlisis de los procesos de tercerizacin muestra que en mltiples ocasiones
(Bersin, 2005) falta:
Comunicacin: frecuentemente las partes que intervienen en los procesos de
tercerizacin se excluyen mutuamente de la comunicacin. No intercambian
informacin constante de avances o dudas que se generan, se basan solo en
una reunin inicial, pocas veces se renen para revisar, clarificar, preguntar,
y redefinir tanto aspectos tcnicos como de gestin en relacin al proyecto.
Transferencia del conocimiento: la informacin generada por el proveedor
no se transmite de manera adecuada al cliente. Si bien es cierto se
entrega documentacin como manuales tcnicos y de usuario, pero esto
no es suficientes, ya que durante el desarrollo del proyecto, pudieron
25
existir diversos escenarios que recibieron una especfica atencin, ademas

complicaciones que se resolvieron con ideas innovadoras, y todo esto se
traslapan con los manuales antes mencionados.
Definicin del alcance y expectativas: se puede decir que el alcance de un
proyecto es en ocasiones difcil de definir y a raz de este alcance se generan
las expectativas del proyecto.Cuando no existe una adecuada comunicacin
estos dos aspectos pueden variar, y los resultados no cumplen completamente
los requerimientos planteados.
Seguimiento y participacin activa del cliente: el cliente se rene con el
proveedor definen el contrato, se levantan requerimientos, y se presenta un
posible diseo previo.Todo lo anterior se realiza al inicio del proyecto, despus
de esto el cliente no se entera de los siguientes procesos, y en la fecha
de finalizacin del proyecto, despus de mucho tiempo sin comunicacin se
informa que el proyecto est finalizado, o por el contrario que el proyecto
est atrasado y el cliente no sabe la razn de esto. Lo anterior sucede debido
a que el cliente no tiene un control real en el seguimiento del proveedor y,
adems, no est involucrado de manera eficaz ni dominante.
Debido a que el enfoque de esta investigacin se basa en los principios de
diversas metodologas giles, es importante mencionar cul es su relacin con
la tercerizacin. Las metodologas giles nacieron enfocadas al desarrollo de
software, pero con el paso del tiempo se comenzaron a utilizar en otro tipo
de proyectos. Sin excepcin, toda metodologa gil se basa en los principios del
Manifiesto gil(Beck y cols., 2001). Las metodologas giles buscan que los
procesos sean ms eficientes y eliminar aquellos que son innecesarios, es por
esto que se considera que estas metodologas podran dar un gran aporte a las
relaciones con terceros.
Las metodologas 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, revisin, retroalimentacin, aprobacin y ajuste, y tienen
como objetivo generar un entregable tangible al finalizar el ciclo. Las diferencia
en relacin con otras prcticas 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 comunicacin que existe entre clientes, usuarios y desarrolladores
para asegurar el xito y rumbo del proyecto.
En la actualidad existe una gran diversidad de metodologas giles, para
diferentes tipos de proyectos y necesidades. Las metodologas que se estudian a
continuacin fueron elegidas debido a las buenas prcticas, guas y consejos que
brindan y que se ajustan al objetivo de esta investigacin. A continuacin se
muestra un resumen con la informacin ms relevante de cada una de ellas.
Programacin Externa: Esta metodologa se basa en 4 aspectos:
comunicacin, simplicidad, retroalimentacin y coraje. Esta metodologa
busca mantener todo de manera sencilla, para una mejor comprensin,
manteniendo al cliente altamente informado de lo que sucede.
26
Chaves et al.
Scrum: Scrum es una metodologa 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 metodologas, 8 en total, las cuales se basan
y tienen en comn los siguientes aspectos:
Frecuentemente entregados.
Mejoramiento reflexivo.
Comunicacin cercana.
Seguridad Cercana.
Concentracin.
Fcil acceso a usuarios expertos.
Estas familias funcionan en base al tamao y el nivel de criticidad de los
proyectos, segn sea el nivel de estos, as una familia u otra podr ser
implementada.
Lead Development": Esta metodologa tiene como caracterstica el ser ms
una filosofa que un proceso de desarrollo. Esta se basa en algunas buenas
prcticas y buenos principios debido a su naturaleza. Ejemplo de ellas son:
satisfacer al cliente es la mxima prioridad, todo se puede cambiar, una
solucin al 80 % hoy, en vez de una al 100 % maana.
Los puntos claves que se analizaron sobre estas metodologas se muestran de
forma resumida en el cuadro 1.
Metodologa gil
Programacin
extrema
Scrum
Puntos claves
Lanzamientos pequeos y frecuentes.
Reuniones cortas todos los das.
Proyecto dividido en iteraciones
Requisitos de proyecto presentados en
bloques de tiempo cortos.
El avance se muestra al cliente al final de
cada iteracin.
Crystal
Entregas frecuentes.
Acceso a usuarios finales expertos.
Comunicacin cercana.
Lead development
La satisfaccin del cliente es la prioridad.

Activa participacin del cliente.
Brindar soluciones generales y no especificas.
Cuadro 1. Cuadro resumen de metodologas giles.
3.
27
Gestin de proyectos y metodologas giles
Figura 1. Gestin de proyectos de tercerizacin con metodologas giles.
La figura 1 muestra la propuesta de un proceso para la tercerizacin del

proceso de desarrollo de software. La propuesta se divide en las siguientes etapas:
Definicin de requerimientos: es la primera etapa del proceso, se emplea
un marco de referencia denominado como Design Sprint el cual tiene como
objetivo reunir las partes clave 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 comunicacin en esta fase.
Iteraciones: en esta fase se inicia un ciclo que comprende diferentes procesos
hasta que el producto este terminado y sea aprobado por el cliente, las etapas
que comprende son las siguientes:
Ciclos de desarrollo: estos ciclos estn a cargo de los desarrolladores de
software, y comprenden la parte de carpintera del proyecto en la cual se
escribe el cdigo del mismo. Revisin del dueo del producto: El dueo
del producto es quien esta 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: despus de pasar por el desarrollo y su aprobacin
se realiza una reunin rpida con los involucrados para hablar sobre
los avances en el proyecto, que se debe mejorar y cules son las tareas
que se deben realizar, contemplan posibles cambios a la planificacin.
Esta etapa busca impulsar la interaccin continua entre los clientes y los
involucrados en el proyecto.
Aprobacin del cliente: en esta fase el cliente define si el proyecto esta
listo para su lanzamiento o se debe continuar con otra iteracin.
28
Chaves et al.
Ajustes: es la ultima fase de la iteracin y en esta se determinan los ajustes

que se deben realizar en el proyecto para continuar con la siguiente
iteracin.
Lanzamiento: se realiza la entrega del producto final al cliente.
4.
Gua de mejores prcticas para la tercerizacin

de software.
El uso de los elementos claves de las diferentes metodologas giles es

un excelente punto de partida para elaborar una gua que proporcione al
cliente una herramienta para ayudarle a asegurar la finalizacin exitosa de un
proyecto. Con base en esto, a continuacin se presenta dicha gua, tomando en
cuenta la comunicacin, trasferencia de conocimiento, definicin del alcance y
expectativas, el seguimiento de las tareas y la participacin activa del cliente.
4.1.
Comunicacin
La comunicacin 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 das porque que se considera que no es prudente revisar resultados y
avances en ventanas de tiempo mayores. Se recomienda que la duracin de
las reuniones no sea mayor a 30 minutos si solo se presentan actividades de
gestin. Pero las reuniones pueden extenderse ms si es necesaria la discusin,
presentacin y prueba de algn prototipo.
La documentacin de las reuniones se puede realizar de diferentes maneras,
como las siguientes:
Grabacin tanto vdeo como audio.
Minutas o herramientas que utilice la empresa para documentar.
El cliente puede enviar un correo electrnico con la minuta de los puntos
revisados en la reunin.
Reuniones personales: Las reuniones virtuales son un punto clave para
la comunicacin, pero se recomienda realizar reuniones personales. Estas
reuniones son de gran valor para la discusin de ideas del cliente y el
proveedor y son de utilidad para presentar diseos en papel, interpretar
reacciones de las personas y prueba de prototipos.
Se recomienda realizar las reuniones personales en un lugar en el cual
los participantes puedan tener acceso a las herramientas necesarias para
desarrollar la sesin (computadoras, Internet, papel, lpices, pizarras,
marcadores). Esto proporcionar un ambiente donde se puedan clarificar
29
o remarcar aspectos que no estn completamente definidos, inclusive el

proveedor puede sacar ventaja de estas reuniones para mostrar ideas o
diseos 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 (iteracin).
Este tipo de reuniones puede ser documentada con:
Herramientas de documentacin.
Minutas.
Grabacin con cmaras en la sala de reunin.
Escaneo del material que se genere en la reunin 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 algn suceso antes de la fecha establecida, til usar
reportes con informacin breve
Esos reportes pueden, dependiendo en la cantidad y valor de la informacin
sustituir una posible reunin si es aceptado por el cliente.
4.2.
Trasferencia de conocimiento
Otro de los problemas mas 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
realizacin del proyecto, solamente queda en manos del proveedor. Por lo que es
importante considerar un plan que fomente la cooperacin entre ambas partes
para compartir informacin.
Para realizar la transferencia de conocimiento se sugiere la implementacin
de tres conceptos que introduce ITIL en sus buenas prcticas para el manejo de
informacin:
Base de conocimiento: uso de una base de conocimiento1 para almacenar
informacin sobre la resolucin de problemas recurrentes, datos relevantes
sobre sistemas de informacin internos y el uso de metodologas. Este tipo de
base de datos se suele integrar con un sistema de gestin del conocimiento,
el cual se encarga de proporcionar detalles a los usuarios finales de manera
eficiente. Ademas provee una va para que los usuarios generen conocimiento
basado en su experiencia con el proyecto.
Se recomienda utilizar el sistema de gestin del conocimiento para
documentar la informacin relevante que se genere durante el desarrollo y
pueda ser til en el futuro para realizar modificaciones, implementaciones y
solucionar problemas del sistema.
La generacin de conocimiento puede derivarse de diversas formas y deben
documentarse por medio de una herramienta de este tipo:
1
Conocida en ingls como Knowledge Base (KB).
30
Chaves et al.
Errores del sistema y su solucin: durante las pruebas del sistema,

podran 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 solucin deben ser documentados.
Complejidad: los sistemas se componen de varios mdulos los cuales no
funcionan de la misma forma, por los procedimientos para el manejo de
la programacin o mantenimiento de un modulo deben documentarse.
Versiones del software: cada versin 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
versin a otra, estos deben ser registrados.
Otros: pueden existir muchos aspectos que el cliente o proveedor consideren
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
CMDB (Base de datos para la gestin de la configuracin): 2 es una
herramienta que tiene como objetivo el manejo eficiente de los servicios y
activos, que estn conformadas por elementos de configuracin3 .
Soluciones en el mercado:
Cherwell
Servicenow
CMDBuild
DSL (Biblioteca definitiva de software): 4 se refiere a un repositorio central
de software en el cual se pueda gestionan imgenes de software con sus
distintas versiones autorizadas, documentacin, componentes aprobados por
los desarrolladores, licencias y otra informacin relevante.
4.3.
Definicin 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 lmites del proyecto.
Las expectativas que se generan entre las partes involucradas tiene su origine
en la definicin correcta del alcance, el cual cuando es definido de forma
incorrecta se convierte en un grave problema para la tercerizacin de software
(Smuts, van der Merwe, Kotz, y Loock, 2010).
2
3
4
Conocida en ingles como Configuration Management Database

Los elementos de configuracin son conocidos en ingls como Configuration Items.
Conocida en ingles como Definitive Software library
31
Reuniones de diseo
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 diseo, en
las cuales se puede usar como referencia el marco de trabajo denominado como
Desing Sprint. Este marco de trabajo permite disear soluciones a problemas
en un lapso de dos a cinco das, y adems permite la contribucin de diversos
participantes en el proceso, a la vez que facilita la comunicacin y claridad a la
hora de definir las ideas.
El concepto de este marco de trabajo fue tomado de las metodologas giles
y adaptado por Google. En la actualidad el marco de trabajo utiliza un proceso
que se divide en 6 etapas:
Entender: se realiza un proceso para entender que 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, adems de una investigacin
sobre el mercado actual y las capacidades tecnolgicas.
Definir: se determinan las caractersticas que el sistema debe tener y se pide
a los usuarios que definan con tres frases como les gustara que fuese el
sistema, pero adems en esta etapa se crean historias sobre la interaccin de
un usuario con el sistema.
Divergir: se le pide a los usuarios que dibujen 8 ideas en cinco minutos sobre
el sistema, adems de realizar una historieta sobre una de sus ideas.
Decidir: se discute y decide sobre cules ideas podran resultar tiles para el
sistema y a partir de estas se genera la discusin sobre las caractersticas de
un prototipo.
Prototipo: se implementa un prototipo y se obtiene retroalimentacin de los
usuarios expertos.
Validar: el prototipo es probado por los usuarios, a quienes se les hace una serie
de preguntas sobre lo piensan acerca de los prototipos.
Al finalizar estas fases se cuenta con los requerimientos iniciales y la definicin
de los sprints"para las reuniones de diseo. Cabe destacar que al final de cada
etapa se debe realizar un resumen con los resultados, los cuales deben de ser
documentados. Adems, se recomienda que el equipo de trabajo est formado por
diseadores, ingenieros, gerentes de proyecto, expertos y el Maestro de sprint
5
.
4.4.
Participacin activa del cliente
El cliente debe estar informado sobre lo que ocurre en el proyecto, pero

tambin 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.
5
El maestro de sprint.es la persona encargada de disear los retos para cada etapa
del sprint".
32
Chaves et al.
Pruebas con usuarios expertos

En las diferentes reuniones se pueden realizar pruebas que permitan al cliente
observar el estado de producto. Pero se recomienda que estas pruebas no sean
realizadas solo por el proveedor, sino que los usuarios expertos del cliente las
realicen.
Algunos de estos usuarios expertos tambin deben participar en las reuniones
virtuales y presenciales, porque son quienes utilizarn 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 control: 6 este documento consiste de una lista de puntos que el
usuario debe evaluar, marcando o dejando vaco 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 mdulo que se haya
probado.
El usuario podr dar su opinin detallada o mas directa dependiendo del
documento, acerca del avance, lo cual servir como retroalimentacin para el
proveedor.
En estas pruebas el proveedor es un gua y no debe influir al usuario sobre
cmo 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
caractersticas utilizar. Esto es la clave para generar retroalimentacin de valor
para el proveedor.
5.
Discusin y conclusiones
Los problemas que han sido mencionados en este trabajo de investigacin

son conocidos por la mayora de gerentes y administradores relacionados con
los procesos de contratacin 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 anlisis bibliogrfico que se llev a cabo y la
constante preocupacin mostrada por los autores de los trabajos estudiados.
El anlisis de la bibliografa permiti determinar que algunas de las
metodologas giles que se utilizan de forma ms frecuente, permiten gestionar la
relacin con terceros de mejor manera que como se lleva a cabo tradicionalmente.
Sin embargo, es posible mencionar que en diferentes aspectos estas metodologas
6
Lista de Control proviene de la traduccin del ingls checklist".
Referencias
33
no son eficientes. Por lo cual, la gua propuesta tiene como fin combinar las
principales fortalezas en cuanto a la gestin de la relacin con terceros de las
metodologas giles que fueron analizadas.
La gua tom en cuenta las caractersticas particulares de cada una de las
metodologas, y fue elaborada con base en la evidencia del xito que han tenido en
la prctica. De forma que la estructura de la gua es flexible ante las necesidades
que pueda tener el cliente. Lo anterior debido a que la implementacin 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 comunicacin con el
proveedor, puede tomar en cuenta las recomendaciones que se brindan para esa
rea. Si por otro lado, el problema al que se enfrenta la empresa tiene relacin con
la definicin del alcance del proyecto, puede revisar este apartado e implementar
los puntos que corresponden a esa seccin, y de forma similar para cada rea
contemplada en la gua.
Como consecuencia, la principal contribucin de este trabajo consiste en la
propuesta de la gua para apoyar la gestin de las relaciones entre clientes y
proveedores. Aunque conviene mencionar que la validacin prctica de dicha
queda pendiente como un trabajo futuro de investigacin.
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.
Senz, J., Cmara, M. d. l., Calvo-Manzano, J. A., y Arcilla, M. (2014).
Necesitan los proveedores de outsourcing una metodologa para la provisin
de servicios?: Is it needed a methodology for outsourcing service providers?
RISTI-Revista Ibrica de Sistemas e Tecnologias de Informao(SPE1),
6175.
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
34
Chaves et al.
and information technologists (pp. 304313). New York, NY, USA: ACM.
Descargado de http://doi.acm.org/10.1145/1899503.1899537
doi:
10.1145/1899503.1899537
Definicin y Modelado del Proceso de Gestin de

la Demanda para Tecnologa de Informacin
David Rodolfo Camacho Quiros, Reagan Ching Fung,
Julio Crdoba Retana y Antonio Gonzlez Torres
San Jos, Costa Rica
[dcamachoq046, rchingf302, jcordobar022]@ulacit.ed.cr
Resumen En la actualidad las organizaciones se ven en la necesidad

de utilizar mejores prcticas y recomendaciones, por lo que se utilizan
marcos de referencia reconocidos y probados. Por esta razn es de suma
importancia, identificar cules son las prcticas y marcos de referencia
que mejor se adaptan al giro de negocio de la organizacin, lo cual resulta,
en muchos casos, en metodologas hbridas que extraen lo mejor de cada
marco. En el presente artculo se presenta un modelo hbrido del proceso
de Gestin de la Demanda. La definicin de dicho modelo como resultado
del anlisis y comparacin de los marcos de referencia ITIL versin 3 y
COBIT versin 5.
Palabras clave: COBIT5, ITILv3, Gestin de la Demanda, Gestin de
la Capacidad
1.
Introduccin
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 econmicas 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 Tecnologas
de la Informacin (TI) las organizaciones necesitan implementar y mejorar los
procesos de gestin. Entre estos procesos se destaca la gestin de la demanda
de servicios de TI.
La gestin 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 modificacin. Este proceso es el encargado de administrar y
garantizar la disponibilidad de los recursos o servicios que el rea de TI brinda
a la organizacin. Por lo que su implementacin inadecuada o ausencia, provoca
que los proyectos de TI se vean impactados de forma negativa. Esto ocurre
36
Camacho et al.
cuando se carece de los recursos necesarios, debido a que los proyectos sufren
aumentos en los costos y la organizacin debe incurrir en el uso indiscriminado
de recursos e incrementar el presupuesto de los proyectos para compensar los
retrasos.
Para comprender el papel que desempea la gestin de la demanda en las
organizaciones, este trabajo ofrecer una gua sobre cmo se puede llevar a cabo
su implementacin o mejora mediante la definicin de un modelo de gestin de
la demanda. De acuerdo con lo anterior, se realiza una evaluacin de los marcos
de referencia COBIT 5 e ITIL v3 con el fin de definir la gestin de la demanda,
identificar los procesos y actividades pertinentes a la gestin 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.
COBIT 5
ITIL v3
EDM04 - Asegurar la optimizacin de recursos Gestin de la demanda
BAI04 -Gestionar la disponibilidad y capacidad Gestin de la capacidad
Cuadro 1. Procesos de marcos de referencia analizados
En sntesis, este trabajo de investigacin busca identificar un proceso bsico,

que sirva como punto de partida para cualquier organizacin y como una
herramienta a nivel gerencial y operacional para la gestin del proceso de la
gestin de la demanda.
2.
2.1.
Marco Terico
Gestin de la Demanda
La gestin de la demanda es un proceso presente en todas las organizaciones,

aunque no se encuentre identificado como tal o ste implementado de forma
errnea. En general, este proceso permite habilitar o poner en ejecucin un
requerimiento del negocio, en donde se pueden tener varias fuentes que estn
haciendo la peticin de dicho requerimiento, el cual puede ser sencillo o complejo.
Segn la frecuencia y el impacto que se tenga sobre el negocio, cada peticin
requiere que se le asigne un nivel de prioridad.
En este contexto, las solicitudes de cuentas de correo electrnico para los
usuarios nuevos de la organizacin es un ejemplo de la demanda de un servicio,
que requiere tener en consideracin la capacidad de los servidores y el ancho de
banda de la organizacin.
La importancia de la gestin de la demanda radica en la consecucin de
beneficios para los usuarios y la empresa. Por lo que es necesario que se tenga
en cuenta los pasos del ciclo de vida de la demanda, conforme con el nivel de
madurez de la gestin de la demanda (Alonso, Caro, y Verdn, 2008).
De acuerdo con lo anterior, los departamentos de TI que definen y
administran de forma correcta el proceso de gestin de demanda pueden mejorar
Definicin y Modelado del Proceso de Gestin de la Demanda para TI
37
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 seleccin de un marco de referencia para la definicin del
proceso de gestin de la demanda, es fundamental conocer los tres tipos de
demanda existentes (Alonso y cols., 2008):
1. Estratgica: Este tipo de demanda es gestionada a travs del portafolio de
proyectos y contempla la solicitud de nuevos programas para introducir
la innovacin, activar nuevos negocios, productos y servicios . Adems,
representa una oportunidad para la organizacin debido a que se identifican
los objetivos estratgicos 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. Tctica: Esta clase de demanda se gestiona por medio del portafolio de
servicios. Su principal foco es el portafolio de servicio, que brinda su atencin
en el catlogo, para evaluar los flujos de trabajo y se ordena de acuerdo con
las prioridades de la organizacin, para efectos de aprobacin y entrega.
3. Operacional: La demanda operacional es la que gestiona la construccin y
mantenimiento de la infraestructura de TI y tiene como funcin velar por
los servicios, tanto de software y hardware as como cumplir con los planes
de mantenimiento y actualizacin.
2.2.
Marcos de referencia: COBIT e ITIL
COBIT es un conjunto de mejores prcticas que proporcionan un marco

de trabajo con un enfoque tctico que est dirigido, principalmente, a los
administradores, gerentes, auditores y encargados o responsables del rea de
TI (noz Serna y Arias, 2012). Adems, este marco de referencia es utilizado
como herramienta para satisfacer las necesidades del negocio y servir como gua
para los procesos y mtricas de control.
COBIT versin 5 se compone de 5 dominios y 37 procesos que buscan brindar
una serie de normas para el uso eficiente de los recursos. En este punto es
importante anotar que la aplicacin de este marco de referencia conlleva tiempo
y esfuerzo, por lo que debido a las limitaciones de tiempo en la realizacin de
este trabajo, solo se estudian y analizan los siguientes procesos:
1. Asegurar la optimizacin de los recursos
2. Gestionar la disponibilidad y la capacidad
El proceso Asegurar la optimizacin 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 tecnologas) para soportar de forma eficaz los objetivos de
la empresa, a un costo ptimo (Unidad 2.- Marcos de referencia en la gestin de
servicios de TI , s.f.). Adems tiene como propsito asegurar que las necesidades
de recursos de la empresa sean cubiertas de forma adecuada, que el coste de TI
38
Camacho et al.
sea apropiado y que se pueda incrementar la probabilidad de obtener beneficios

as como la preparacin para cambios futuros (ISACA, 2012).
En cuanto al proceso Gestionar la disponibilidad y la capacidad, se encuentra
en el rea de Gestin 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 provisin de servicio efectivo
en costos. Adems, incluye la evaluacin de las capacidades actuales, la previsin
de las necesidades futuras conforme con los requerimientos del negocio, el anlisis
del impacto en el negocio y la evaluacin del riesgo para planificar e implementar
acciones para alcanzar los requerimientos identificados. De forma adicional tiene
como propsito mantener la disponibilidad del servicio, la gestin eficiente de los
recursos y la optimizacin del rendimiento de los sistemas mediante la prediccin
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 guas para agilizar las entregas
de servicios. Este marco proporciona mecanismos para aumentar la interaccin
entre usuarios y clientes, con el fin mejorar la prestacin y calidad de los servicios
(Unidad 2.- Marcos de referencia en la gestin de servicios de TI , s.f.). La versin
3 de ITIL divide el ciclo de vida de los servicios en cinco fases:
1.
2.
3.
4.
5.
Estrategia
Diseo
Transicin
Operacin
Mejora
En este trabajo se profundiza en la fase de Estrategia, especficamente en el

proceso de la Gestin de la Demanda y de forma complementaria en el proceso
de Gestin de la Capacidad (fase de diseo).
El proceso Gestin de la Demanda se encarga de efectuar proyecciones,
regular los ciclos de consumo y adaptar la prestacin 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 organizacin, para extraer los patrones
de las actividades del negocio para prevenir cules servicios son o van a ser
demandados y planificar el alcance de los servicios necesarios y su prioridad
(Quevedo Val, 2009).
El proceso de la Gestin de la Capacidad busca garantizar la capacidad
necesaria para soportar los servicios de TI de acuerdo con las necesidades de
la organizacin (OSIATIS, 2015). El fin de dicho proceso es que los recursos
tecnolgicos estn disponible 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 adquisicin de recursos innecesarios. Por lo que se debe conocer el
estado actual de la organizacin y tener una visin clara sobre su rumbo.
La adecuada gestin de este proceso permite mejorar el rendimiento de los
recursos, planificar de forma adecuada el crecimiento en funcin al negocio,
39
reducir los gastos innecesarios por mantenimiento o adquisicin de nuevos

dispositivos y reducir posibles incompatibilidades y fallas en la infraestructura
(ITIL vs COBIT , s.f.).
3.
Metodologa
El mtodo que se utiliz para desarrollar, definir y modelar la propuesta del

proceso de Gestin 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 correlacin de los componentes especficos
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 hbrido que tiene en cuenta

las actividades de los marcos de referencias de ITIL v3 y COBIT 5 con respecto
a la Gestin de la Demanda y est constituido por nueve actividades (ver Figura
1).
4.1.
Descripcin del proceso
Recopilacin de Informacin: El proceso propuesto inicia con la

recopilacin de informacin3 , en donde el encargado de su ejecucin
es el departamento de TI.
Suministrar planes de negocio y requerimientos: Esta actividad tiene
por objetivo comprender e identificar las actividades del negocio y la forma
como stas inciden en la demanda de los servicios. Las fuentes de informacin
de esta actividad son los planes de negocio, planes de mercadeo, proyecciones
de ventas y solicitudes de nuevos requerimientos.
Anlisis de documentos: Esta actividad debe ser desarrollada por el
departamento de TI4 y tiene como finalidad la identificacin de los patrones
de las actividades del negocio, tambin conocidas como PBAs5 . Adems de
identificar los PBAS, esta actividad define los perfiles de los usuarios o UP6 ,
basndose en sus roles y responsabilidades en la organizacin.
1
2
3
5
6
EDM04 Asegurar la optimizacin de recursos y BAI04 Gestionar la disponibilidad

y capacidad.
Gestin de la demanda y Gestin de la capacidad
La recopilacin de informacin es propuesta con base en el proceso Gestin de
Demanda de ITIL v3.
El diseo de esta actividad se bas en ITIL v3, especficamente en el proceso Gestin
de Demanda.
Patterns of Business Activity, por su acepcin en ingls.
User Profile, en ingls.
40
Camacho et al.
Figura 1. Proceso de modelado de la gestin de la demanda.
41
Analizar la definicin y capacidad del servicio a nivel de recursos:

Esta actividad fue definida tomando como referencia COBIT 5 y los
siguientes procesos:
1. BAI04.02 Evaluar el impacto en el negocio de COBIT 5. Este proceso
tiene como objetivo identificar los servicios importantes para la empresa,
relacionar los servicios y recursos con los procesos de negocio e identificar
las dependencias del negocio.
2. BAI04.03 Planificar requisitos de servicios nuevos o modificados. En el
caso de este procesado est asociado con la planificacin y priorizacin
de la disponibilidad, el rendimiento y la capacidad para realizar cambios
conforme con las necesidades del negocio y los requerimientos de servicio.
3. EDM04.02 Orientar la gestin de los recursos. Este proceso est
relacionado con la adopcin de principios de gestin de recursos para
permitir el uso ptimo de los recursos de TI a lo largo de su ciclo de
vida.
Para esta actividad tambin se us como referencia la actividad Gestin
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 definicin anterior, se generan paquetes de
servicios especficos para los distintos grupos de clientes.
Evaluar 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 relacin con la
disponibilidad, rendimiento y capacidad.
Aprobar 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.
Solicitar 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
organizacin y el desempeo del negocio.
Analizar presupuesto: Si el negocio no aprueba la solicitud de recursos, de
debe de volver a realizar el anlisis de la capacidad y los recursos que requiere
el servicio, de esta manera se puede replantear el alcance de la prestacin
del servicio y ajustarlo al presupuesto con el que se cuenta en ese momento.
Evaluar peridicamente capacidad y disponibilidad del servicio: Esta
actividad invoca a un sub-proceso para dar seguimiento a los servicios y sus
recursos, y se basa en tres procesos de COBIT 5:
1. BAI04.01 Evaluar la disponibilidad, rendimiento y capacidad actual y
crear una lnea de referencia: Este proceso tiene como objetivo asegurar
la disponibilidad, capacidad y rendimiento de los servicios mediante su
evaluacin.
42
Camacho et al.
2. 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. Adems de
identificar desviaciones respecto a las lneas de referencia establecidas
y revisar informes de anlisis de tendencias identificando cualquier
problema o variacin significativa para iniciar las acciones necesarias con
el fin de asegurar que se realiza el seguimiento de todos los problemas
pendientes.
3. EDM04.03 Supervisar la gestin de recursos: Este proceso indica que se
deben supervisar los objetivos y mtricas clave de los procesos de gestin
de recursos, as como establecer la forma en que sern identificados y se
les dar seguimiento a las desviaciones o problemas.
Esta actividad tambin se bas en el proceso Gestin de la Capacidad de
ITIL v3, el cual tiene relacin con el seguimiento y revisin de los informes
de desempeo de los servicios y componentes, adems de reaccionar y
ayudar en la solucin de problemas especficos de rendimiento, si se llegan
a materializar. Otro objetivo de esta actividad es suministrar informacin,
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 anlisis de la documentacin del negocio para
determinar si la capacidad de los recursos est mal definida, si es necesario
gestionar ms 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 organizacin y el mantenimiento
de los servicios. Lo anterior se confirm con el desarrollo de este trabajo, el cual
llev a cabo la correlacin de informacin de ambos marcos de referencia y
permiti la definicin de un proceso de gestin de la demanda.
Lo anterior permite afirmar que la utilizacin mixta de los marcos de
referencia en cuestin es factible y facilita el desarrollo de marcos de trabajo
ajustados a cada organizacin. Por ejemplo, COBIT es un marco de referencia
flexible y adaptable a cualquier organizacin, lo cual es uno de sus aspectos
esenciales, como qued expuesto con el planteamiento del modelo con la gestin
de la demanda.
Cabe sealar que los insumos o documentacin del negocio, a partir de la cual
se realiza la identificacin 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 lnea con lo anterior, es importante tener en cuenta que la evaluacin
continua de los servicios es vital porque los requerimientos del negocio y el
entorno donde se desenvuelve la organizacin est en constante cambio, lo cual
Referencias
43
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 marco se enfoca en la administracin y entrega de los
servicios ofertados, lo cual es un producto del proceso de gestin 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 Verdn, J. C. (2008, Dec). 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). doi: 10.1109/CSSE.2008
.1307
ISACA. (2012). COBIT 5: Procesos Catalizadores. Autor. Descargado de
www.isaca.org
ITIL vs COBIT. (s.f.). Descargado 2016-01-05, de http://www.cntec.mx/
noticias/41/122-itilvscobit.html
noz Serna, R. M., y Arias, M. A. M. (2012). Caracterizacin de procesos
de gestin de ti basados en cobit 5 y mapeo con iso27002, itil, cmmi
dev, pmbok, para la implementacin en la industria editorial colombiana,
apoyando el proceso de transformacin digital.
OSIATIS. (2015, dec). Itil foundation. Descargado de http://itilv3.osiatis
.es/
Quevedo Val, A. M. (2009, sep). Implementacin de una metodologa de
procesos para la mejora de TI en una empresa. Universitat Politcnica de
Catalunya. Descargado de http://upcommons.upc.edu/handle/2099.1/
7599
Unidad 2.- Marcos de referencia en la gestin de servicios
de TI.
(s.f.).
Descargado 2016-01-05, de http://
estrategiasdegestionyserviciosdeti.bligoo.com.mx/unidad-2
-marcos-de-referencia-en-la-gestion-de-servicios-de-ti{\#}
.VoxGOBUX3IW
Recomendaciones para la Gestin de Incidencias

de Tecnologas de la Informacin
Verny Mora Jimnez, Paulo Viales Wahrmann, Julio Crdoba Retana y
San Jos, Costa Rica
[vmor80@hotmail.com,pviales@gmail.com,jcordobar022]@ulacit.ed.cr
Resumen La gestin de incidencias es un proceso crtico en la

administracin de los servicios de Tecnologas de la Informacin (TI),
por el impacto en las operaciones de las organizaciones y la relacin que
se establece entre los usuarios y el departamento de TI. De acuerdo con
esto, este trabajo de investigacin lleva a cabo el anlisis de las principales
actividades asociadas, conforme con los marcos de referencia ITIL,
COBIT y CMMI, y propone un proceso para la gestin de incidencias.
El objetivo es apoyar a los administradores de TI en la definicin e
implementacin de la gestin de incidencias mediante la discusin de
la propuesta y el flujo de las tareas que componen el proceso.
Palabras clave: Gestin de Incidencias, ITIL, COBIT, CMMI
1.
Introduccin
En el contexto actual, las tecnologas de la informacin (TI) son un factor

crtico para el desempeo de las organizaciones, por lo que requieren el correcto
funcionamiento de los sistemas de hardware y software que utilizan. Esto
conlleva que las incidencias1 que se presenten deben 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 organizacin
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 ms eficiente, ayudar a incrementar la productividad de los usuarios,
reducir costos, tiempos de ejecucin 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 prestacin de un

servicio que es soportado por hardware o software.
Recomendaciones para la gestin de incidencias de TI
45
se pueden alcanzar nicamente con fuertes inversiones en tecnologa y personal

cualificado, sino que es necesario contar con una buena gestin y planificacin
a nivel empresarial. Para esto, es recomendable implementar un Sistema de
Gestin de Servicios de TI (SGSTI), potenciar la labor de los gestores y
utilizar mtricas para el seguimiento y control de la resolucin de incidencias
(Mara-Carmen Bauset Carbonell, 2013; Mutafelija y Stromberg, 2008).
Tambin es conveniente tener en cuenta que la gestin de incidencias,
adems del impacto que tiene en la organizacin, determina la relacin 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 resolucin de los problemas
como la forma en que el servicio es percibido por los usuarios y el resto de la
organizacin (Persse, 2013).
De acuerdo con la experiencia de los autores, un gran nmero de
organizaciones no aplican las mejores prcticas de la industria para la gestin
de incidencias, en algunos casos por desconocimiento y en otros por que no le
brindan importancia necesaria. Tomando en cuenta lo anterior, en este trabajo se
estudian y analizan los lineamientos y mejores prcticas que son recomendadas
por COBIT, ITIL y CMMI con el fin de proponer un proceso y una lista de
recomendaciones que sirvan como gua para realizar la gestin de incidencias en
servicios de TI. Dicho proceso pretende contribuir con la deteccin oportuna de
desviaciones en los procedimientos, la correcta clasificacin de las incidencias, la
utilizacin 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 resolucin de incidencias de las organizaciones, en un plazo no
mayor a un ao de la puesta en marcha del proceso.
2.
Marco Terico
Una incidencia es un evento que implica la interrupcin no planificada o la

reduccin de la calidad de un servicio de TI, el cual es soportado por elementos de
hardware o software (Foundation, 2011). Las incidencias pueden ser detectadas
por el personal tcnico, reportadas por herramientas de seguimiento de eventos,
comunicadas por los usuarios de forma telefnica o mediante un sistema de
incidencias o informadas por terceros (e.g., proveedores y socios de negocio2 ).
En tanto, la gestin de las incidencias es el proceso responsable de administrar
el ciclo de vida de cada incidencia (Persse, 2013).
La gestin de incidencias requiere brindar respuesta oportuna y efectiva
a las peticiones de los usuarios relacionadas con la resolucin de problemas
asociados a los servicios de TI, esto con el fin de no afectar los procesos de
la organizacin y cumplir con los compromisos con terceros (Eileen Forrester,
2011). En trminos 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 acepcin en ingls.
46
Mora et al.
los sntomas de las incidencias, as como asignar los recursos necesarios para su
resolucin), 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 resolucin de la
incidencia, cerrar las incidencias y mantener un registro histrico (ver procesos
DSS02 y DSS03 de COBIT 5) (ISACA, 2012; OToole, 2015).
El registro de las peticiones de servicio requiere verificar que estas cumplen
con los criterios mnimos establecidos y que los usuarios que las realizan estn
debidamente autorizados. Cada incidencia debe contar con un nmero nico de
referencia, hora y fecha de registro, identificacin de la persona que realiz el
registro de la incidencia, mtodo de notificaciones del estado de la incidencia,
descripcin de los sntomas.
En cuanto al diagnstico, es necesario contar con toda la informacin
disponible para efectuar una mejor evaluacin del problema para efectuar su
categorizacin, determinar el impacto en el negocio (i.e., nivel de prdida
financiera, el posible efecto en la reputacin del negocio y las regulaciones
del pas) y la urgencia de su resolucin, efectuar una correcta asignacin de
la prioridad, obtener la aprobacin financiera y si se requiere, el cambio de
procedimientos o estndares.
Como parte este proceso se requiere require 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 realizar
antes de asignar a un especialista para realizar un anlisis de mayor profundidad
o que se realicen acciones para restaurar los servicios afectados, con ayuda de
otros especialistas.
En los casos en los que la incidencia es reportada por telfono, se recomienda
efectuar un diagnstico inicial e intentar ofrecer una solucin de forma inmediata,
trabajando junto con el usuario, si es factible. Si no es posible ofrecer una solucin
inmediata, entonces se debe informar al interesado sobre el procedimiento que
se seguir, y darle un nmero de incidencia para que le pueda dar seguimiento.
En lo que respecta a la resolucin de incidencias, conviene tener en cuanta 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 ms alto nivel para resolver el problema) o
jerrquico (se acude a un responsable de mayor autoridad para tomar decisiones
por encima del nivel del personal tcnico involucrado, como la asignacin de
recursos adicionales para la resolucin del 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
organizacin. Pero adems, es necesario que en el transcurso de la resolucin se
le brinde seguimiento al estado de las incidencias hasta que se realice el cierre
de sta. El proceso de seguimiento involucra documentar y revisar las acciones
realizadas, escalar las incidencias segn se requiera y comunicar el estado de la
incidencia a las partes interesadas.
47
En el transcurso de la resolucin de una incidencia puede ser necesario

efectuar procedimientos de recuperacin de los servicios, los cuales dependern
de la naturaleza de esta, y podran involucrar la participacin activa del usuario
en la realizacin de actividades concretas, de forma similar se podra requerir
la participacin 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 satisfaccin, tener en
cuenta los requerimientos de informes de las partes interesadas en la gestin de
incidencias y utilizar criterios de calidad del servicio (Eileen Forrester, 2011).
El cierre de la incidencia debe contemplar la documentacin de las actividades
que se realizaron para resolverla, la fecha de resolucin, la categora de cierre, la
fecha en que se est efectuando el cierre y la resolucin de las causas subyacentes
a la incidencia (Kenett y Baker, 2010). Adems, se requiere documentar
las soluciones identificadas, registrar si se usaron soluciones temporales o
acciones de recuperacin de servicios, determinar las acciones incorrectas que
se llevaron a cabo y comprender el proceso que se sigui durante la resolucin.
Esta informacin permite efectuar el anlisis, evaluacin y clasificacin 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 resolucin y apoyar la bsqueda de mejores prcticas.
3.
Proceso para la Gestin de Incidencias
La definicin de un proceso para la gestin de incidencias requiere que,

en primer lugar, se determinen de forma clara las polticas, procedimientos
y definiciones que sern considerados por este. Conforme con lo anterior, se
recomienda tomar en cuenta los elementos que se presentan en la siguiente lista.
Definicin de una incidencia: Es necesario diferenciar de forma clara entre
una incidencia y una solicitud de servicio. Una incidencia es la interrupcin
no planificada o la reduccin 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 stas no representan la
interrupcin de un servicio (Foundation, 2011).
Categoras: La definicin de categoras es otro elemento fundamental en
la gestin 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
catlogo de categoras de incidencias (Foundation, 2011; Eileen Forrester,
2011). Como recomendacin, se sugiere realizar una lluvia de ideas con
el personal involucrado en la gestin de incidencias (e.g., los tcnicos de
soporte, supervisores de gestin de incidencias y administradores), para crear
una lista preliminar de categoras, que se ponga a prueba por un periodo
corto de tiempo. De forma posterior, se recomienda analizar las incidencias
48
Mora et al.
reportadas durante un periodo de tiempo para afinar la lista de categoras

de incidencias. Como buena prctica, el catlogo de categoras debe ser
analizado de forma peridica, cada 3 o 5 meses, para realizar actualizaciones
y mantenerlo adecuado a las necesidades del negocio.
Responsable de incidencias: La asignacin de responsabilidades es otro
elemento a tener en cuenta. En este aspecto, tanto COBIT ((IGI),
2013) como CMMI (Eileen Forrester, 2011) especifican varios lineamientos
importantes. En general, es necesario especificar cules son las
responsabilidades del tcnico al que se le asigna una incidencia, as como
quin 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.
Asignacin de prioridad: La resolucin de las incidencias requiere contar con
diferentes niveles de prioridad, en funcin de la relevancia e impacto en el
negocio. De acuerdo con el anlisis de COBIT 5, ITIL y CMMI se recomienda
el uso de 5 niveles de prioridad usando valores numricos (e.g., 1 a 5) o
categricos (baja, media, alta, grave, crtica).
Reporte de incidencias: Es importante definir de forma clara los mecanismos
para el reporte de las incidencias 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 (Eileen Forrester, 2011), la actualizacin de los
estados (e.g., abierta, en progreso, resuelta y cerrada) (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
categora y prioridad, y determinar quin ser el responsable que trabajar
en la solucin.
En general, los modelos relacionados con la gestin de las tecnologas de la
informacin coinciden en cuanto a las principales tareas que requiere el proceso
de gestin de incidencias, siendo esas tareas las siguientes:
1.
2.
3.
4.
Registro de incidencias.
Resolucin de incidencias.
Cierre de incidencias.
Seguimiento y anlisis de incidencias.
En consecuencia, este trabajo ha tomado en cuenta la lista de tareas

enunciadas y las mejores prcticas de COBIT ((IGI), 2013), ITIL (Foundation,
2011) y CMMI (Eileen Forrester, 2011), para proponer el proceso que se muestra
49
en la Figura 1. Las tareas ordinarias de dicho proceso son representadas por cajas
rectangulares y las decisiones por rombos, en tanto que las lneas de color rojo
indican el flujo ordinario de las tareas y las lneas 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 identificacin de las incidencias, por
parte de los usuarios de la organizacin o los miembros del departamento de
TI (i.e., por observacin en el campo o por medio del uso de sistemas para
ese propsito). Una vez que la incidencia ha sido identificada, se procede a
registrarla, para luego efectuar el diagnstico (i.e., de forma opcional se puede
usar la base de conocimientos), categorizacin y asignacin de prioridad. Con
base en el diagnstico, se determina si la resolucin de la incidencia requiere de
recursos extraordinarios, y en caso necesario se solicita la aprobacin de esos
recursos al comit ejecutivo. A partir de ese punto, se inicia la recuperacin de
servicios (cuando se requiera) y la resolucin de la incidencia.
Cuando la incidencia ha sido resuelta, de acuerdo con el personal tcnico,
se realizan las pruebas tcnicas necesarias para validar la resolucin. En caso
de que la incidencia se haya resuelto de forma efectiva, se realiza la verificacin
y aceptacin de la solucin con el usuario. Sin embargo, cuando la incidencia
no ha sido resuelta, se verifica si el personal tcnico 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 jerrquico. Cuando el proceso de escalado ha terminado, se verifica
si la incidencia ha sido resuelta, y si es as, se procede a realizar la verificacin y
aceptacin 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 resolucin de la incidencia ha sido resuelta de forma definitiva,
tras efectuar la verificacin y aceptacin con el usuario, se procede a cerrarla y
documentarla.
La descripcin de cada una de las tareas que conforman el proceso propuesto
se detalla en a continuacin.
Identificacin de incidencias: En un escenario ideal, se brinda seguimiento
constante a los recursos y servicios crticos de la organizacin para prevenir la
ocurrencia de incidencias o bien, un gran nmero 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 X, la identificacin de las incidencias, por lo general, es realizada
tanto por los usuarios de la organizacin como por el departamento de TI.
50
Mora et al.
Figura 1. Proceso para la gestin de incidencias de tecnologas de la informacin.
51
Registro de incidencias: El proceso para registrar las incidencias debe poner

a disposicin de los usuarios autorizados tantos medios como sea posible,
incluyendo llamadas telefnicas, registro web y mensajera instantnea.
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 polticas y reglamentos de la organizacin.
Algunos de los principales elementos de informacin para registrar una
incidencia son los siguientes:
1. Nombre de quien registra y quien reporta la incidencia
2. Datos de contacto
3. Descripcin detallada de la incidencia
4. Fecha y hora del reporte (tomada por el sistema)
5. Nmero de referencia (generado por el sistema)
6. Prioridad y categora inicial (ingresada por quien registra la incidencia)
7. Notas sobre el impacto en el negocio
Diagnstico, categorizacin y prioridad: El diagnstico, 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., tambin es posible que la incidencia sea resuelta al
momento de hacer el diagnstico, en el momento en que se recibe el
reporte por telfono). Pero tambin en algunos casos, podra ser necesario
solicitar aprobacin 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 categora y prioridad definitiva a
la incidencia, en funcin del tipo de incidencia, urgencia e impacto.
Autoayuda- BD conocimiento: Los sistemas modernos de gestin de
incidencias utilizan el registro histrico de las incidencias, y toda la
informacin 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 tcnicos realicen los
diagnsticos y resolucin de incidencias de forma ms efectiva, por medio
de informacin relacionada con casos similares que han sido resueltos. En el
caso del proceso propuesto, esta actividad se encuentra ligada al diagnstico,
categorizacin y asignacin de prioridad a las incidencias, as como a la
recuperacin y resolucin de la incidencia, tomando en cuenta lo anterior.
Aprobacin del comit ejecutivo: Cuando se considera que es necesario
utilizar recursos o procedimientos extraordinarios para la resolucin de una
incidencia, se debe contar con la aprobacin del comit ejecutivo. Toda
aprobacin 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).
Recuperacin y resolucin de incidencias: Para realizar esta tarea, el
personal de la mesa de servicio debe contar con el personal capacitado con el
52
Mora et al.
conocimiento y herramientas para determinar el mejor curso de accin para

la resolucin de la incidencia. Entre las tareas que pueden ser necesarias
durante la resolucin de las incidencias se encuentran las siguientes:
1. Realizar la recuperacin 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 estndares sobre caractersticas
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 bitcoras y acciones que fueron realizadas antes y despus 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 cules acciones adicionales pueden ser requeridas
Escalado de incidencias: En el transcurso de la resolucin 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 gestin de incidencias deben encontrarse
especificadas en las polticas, procedimientos o acuerdos formulados por la
organizacin (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
jerrquico (Foundation, 2011), como se muestran en la Figura X y es descrito
a continuacin.
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 participacin de otros grupos con un nivel ms
alto de especializacin, experiencia y capacitacin. 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 stas, sin importar el grupo al que hayan sido
referidas para su resolucin.
Escalado jerrquico: Este tipo de escalado se realiza cuando es necesario
que los mandos superiores estn al tanto de la situacin 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.
Verificacin y aceptacin: Cuando la incidencia ha sido resuelta, la mesa de
servicio procede a realizar la verificacin, junto con los usuarios afectados, de
que el problema se ha solucionado de forma satisfactoria. Si el usuario acepta
la resolucin de la incidencia, se procede a efectuar el cierre y documentacin
53
de sta, de lo contrario, se procede a trabajar en los aspectos necesarios para

resolver la incidencia a satisfaccin del usuario.
Cierre y documentacin: El cierre y documentacin de una incidencia cierra
el ciclo de gestin de incidencias, para esa incidencia en particular. Sin
embargo, la gestin de incidencias es un proceso continuo que comprende
la resolucin de las incidencias, la documentacin de todas las acciones
realizadas y el uso de la informacin que se genera para obtener conocimiento
que permita mejorar la atencin de lo usuarios. De acuerdo con lo anterior, el
cierre de la incidencia requiere verificar y corregir, si es el caso, la categora
y prioridad asignada, y la documentacin de las tareas realizadas.
Aunque algunas organizaciones implementan mecanismos para el cierre
automtico de incidencias despus de un determinado periodo de tiempo, en
este trabajo se recomienda que el cierre de las incidencias sea realizado de
forma explcita por la mesa de servicio. El cierre automtico 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 gestin de incidencias. Es preciso registrar todos los detalles
de las acciones que se realizan en torno a las incidencias (Eileen Forrester, 2011;
Foundation, 2011) y contar con las herramientas apropiadas para alertar al
personal tcnico cuando sea necesario, y tambin para brindarles informacin
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. Pero adems 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 nmero de incidencias por una misma causa.
Un elemento de gran importancia en este proceso es asegurar la satisfaccin
de los usuarios, por lo que se recomienda efectuar encuestas (por medio de correo
o telfono) para determinar su nivel de satisfaccin con los servicios de gestin
de incidecias y tomar las medidas necesarias para corregir los problemas que se
detecten. En lnea con esto, es necesario contar con una poltica y procedimientos
claros en torno a la reapertura de incidencias, en caso necesario. Por lo que es
importante que se brinde capacitacin constante a todo el personal de la mesa
de servicio, tanto sobre aspectos tcnicos como de procedimientos y servicio al
cliente.
4.
Conclusiones
Las organizaciones se enfrentan a retos diversos que requieren el uso de

las mejores prcticas existentes, sobre todo cuando se trata de la gestin de
54
Mora et al.
incidencias de TI, por la alta dependencia que tienen sus actividades de los
sistemas de hardware y software. Por eso la definicin de un proceso de gestin
de incidencias con base en los marcos de referencia COBIT, ITIL y CCMI es
de gran importancia. Sin embargo, es importante considerar que la definicin
de un proceso de esa naturaleza debe tomar en cuenta las particularidades de
cada organizacin 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 definicin del proceso de gestin de incidencias, mediante la propuesta de un
proceso basado en las mejores prcticas de los marcos de referencia mencionados.
La definicin de un proceso de gestin de incidencias requiere estudiar en
detalle cada organizacin 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 nmero de servicios es
reducido, o cuando estos no son complejos, no es necesario definir un proceso
complejo o costoso.
El uso de bibliografa complementaria para definir y justificar la definicin
e implantacin de un proceso de gestin de incidencias, adaptado a las
necesidades de la organizacin, puede ser de gran ayuda. En la literatura
se encuentra documentado que el uso de buenas prcticas ayuda a eliminar
el trabajo redundante, mejora los tiempos de respuesta (i.e., indicadores de
soporte al negocio), y contribuye con la definicin de departamentos de TI
mejor estructurados, ms eficientes y enfocados en los objetivos de la empresa
(Realtimepublishers.com y Herold, 2007). Pero, 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 razn
costo/beneficio, ante la administracin. Adems, se debe tener en cuenta que la
divulgacin, aceptacin y reconocimiento del proceso por parte de la organizacin
toma tiempo y recursos (Quesnel, 2012). Por esa razn, podra ser necesario
implementar un plan piloto que permita demostrar el impacto del proceso
cuando se presentan incidencias que implican la interrupcin de servicios en
departamentos estratgicos.
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 ms alto, con mayor experiencia en
la gestin de incidencias y el uso de buenas prcticas. Lo anterior, debido a que
ofrece recomendaciones (e.g., implementar sistemas de software para la gestin
de incidencias) que no se adaptan a organizaciones con niveles de madurez bajo.
Referencias
55
Referencias
Eileen Forrester, S. S., Brandon Buteau. (2011). Cmmi for services: Guidelines
for superior service. Pearson Education. Descargado de https://books
.google.co.cr/books?id=ywvSVLmQmjoC
Foundation, I. (2011, Julio). Itil v3 2011. Descargado de http://itilv3
.osiatis.es/ ([Web; accedido el 23-11-2015])
(IGI), I. G. I. (2013). Cobit 5. Rolling Meadows.
ISACA. (2012). COBIT 5: Procesos Catalizadores. Autor. Descargado de
www.isaca.org
R for systems
Kenett, R., y Baker, E. (2010). Process improvement and cmmi
and software. CRC Press. Descargado de https://books.google.co.cr/
books?id=a7XS1GmuhWYC
Mara-Carmen Bauset Carbonell, M. R. A. (2013, jan). Gestin de los servicios
de tecnologas de la informacin: modelo de aporte de valor basado en itil
e iso/iec 20000. El profesional de la informacin, 22 (1).
R v1.2
Mutafelija, B., y Stromberg, H. (2008). Process improvement with cmmi
and iso standards. CRC Press. Descargado de https://books.google.co
.cr/books?id=ErVuWU\_U0SwC
OToole, D. (2015). Incident management for i.t. departments. On Demand
Publishing, LLC-Create Space. Descargado de https://books.google
.co.cr/books?id=M2RargEACAAJ
Persse, J. (2013). The it service management process manual. van Haren
Publishing. Descargado de https://books.google.co.cr/books?id=
0FZeAgAAQBAJ
Quesnel, J. (2012). Entender itil 2011: Normas y mejores prcticas para avanzar
hacia iso 20000. d. ENI. Descargado de https://books.google.com/
books?id=Tn2vJvQ3bwwC
Realtimepublishers.com, y Herold, R. (2007). The shortcut guide to improving
it service support through itil. Realtimepublishers.com. Descargado de
https://books.google.com/books?id=BT2bNZ0qYjAC
Diseo de una arquitectura para la comunicacin

entre protocolos en Internet de las Cosas
Marco Crdoba Padilla, Frank Trejos Moya, Fernando Chinchilla Jimnez y
San Jos, Costa Rica
[mcordobap487,ftrejosm824,fchinchillaj980]@ulacit.ed.cr
Resumen El uso de Internet y las tecnologas 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 estn 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 mxima de las posibilidades detrs
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 especficas para resolver problemas particulares.
Por lo que el objetivo de este trabajo de investigacin es proponer el
diseo de una arquitectura de bajo costo basada en una puerta de enlace
para facilitar la interconexin de dispositivos y protocolos diversos. Con
ese fin se lleva a cabo la discusin 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 diseo y se presenta
un posible escenario de uso.
Palabras clave: Internet de las cosas, Protocolos, Comunicaciones
1.
Introduccin
En aos recientes ha surgido un gran nmero de dispositivos que se

caracterizan por sus excelentes capacidades de comunicacin, bajo costo y
consumo energtico, 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
Internet de las Cosas se deriva de Internet of Things en Ingls y se asocia con las
siglas IoT.
Diseo de una arquitectura para la comunicacin entre protocolos
57
la seguridad, la salud, el seguimiento de los signos vitales de las personas, la

inteligencia ambiental, la iluminacin, el control de la temperatura de edificios y
el acceso a reas restringidas. En general su uso est ligado con la bsqueda 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 aos recientes, han surgido de forma masiva tanto fabricantes
como nuevos dispositivos. A finales del 2015 el nmero de desarrolladores de
aplicaciones y soluciones de IoT super los 6, 2 millones (Rana, 2016), y mostr
un crecimiento del 34 % con respecto al ao anterior. Este crecimiento ha sido
empujado por la cada en los costos de los dispositivos y el acceso a Internet.
Lo anterior, ha impulsado la rpida evolucin de nuevas tecnologas, pero
ha originado problemas de integracin e interconexin 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 lo cual tambin ha contribuido la necesidad de desarrollar
dispositivos especializados con caractersticas 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 interconexin, se han establecido varias alianzas para impulsar el
desarrollo y crecimiento de IoT a travs de la investigacin y creacin 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 compaas. Otro caso similar es
la alianza (ZigBee Alliance, 2016) de fabricantes de dispositivos que utilizan el
protocolo inalmbrico ZigBee, y que es conformada por ms de 400 compaas
que utilizan dicho protocolo.
Sin embargo, la necesidad de realizar diseos en los cuales conviven e
interactan diferentes protocolos en un mismo sistema IoT sigue siendo una
prioridad, porque interoperabilidad entre estos (James Manyika y Dobbs, 2016)
puede contribuir a generar ingresos adicionales a la industria por un 40 % .
Este trabajo propone un diseo para que los protocolos ms 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 heterogneos
en el contexto de IoT.
Como consecuencia, la seccin 2 analiza los principales elementos de una
arquitectura de IoT, discute los conceptos relacionados con la interconexin entre
dispositivos y estudia los fundamentos de las puertas de enlace. Con base en
la informacin presentada en la seccin 2, la seccin 3 presenta el diseo de
2
Los dispositivos de Internet de las Cosas, en su mayora, utilizan protocolos simples

que requieren contar con menos capacidad de procesamiento y consumo de energa
que los dispositivos que utilizan TCP/IP.
Las puertas de enlace permiten la comunicacin entre dispositivos en diferentes
segmentos de una red, en los cuales utilizan protocolos diversos.
58
Crdoba et al.
una arquitectura de IoT basada en una puerta de enlace y analiza un escenario

de uso para dicha propuesta. Finalmente, la seccin 4 discute las principales
conclusiones del trabajo.
2.
Antecedentes
La arquitectura de alto nivel de un sistema de IoT es similar a la arquitectura

genrica de cualquier otro sistema, se compone de elementos de entrada,
procesamiento y salida. La diferencia bsica es que la entrada de datos se puede
realizar por medio de sensores y la salida se puede efectuar con actuadores.
As, los datos se adquieren del entorno por medio de sensores, se transmiten
a los dispositivos de control (procesamiento) usando tecnologas y protocolos
de comunicacin, 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 de protocolos de
comunicacin para el intercambio de datos y de algoritmos para su tratamiento
y anlisis. Los algoritmos se encargan de procesar los datos e integrarlos, de
conformidad con las relaciones de comunicacin que se pueden formar entre los
dispositivos y la arquitectura del sistema.
Los sistemas de esta naturaleza tambin pueden recibir entradas de los
usuarios, por lo general en la forma de parmetros de configuracin o de
actuacin con base en los resultados. De forma similar, estos sistemas tambin
pueden producir salidas tradicionales a un monitor o impresora. Por lo que la
interfaz del usuario suele estar vinculada al dispositivo controlador, y es utilizada
para configurar y gestionar el sistema (ver figura 1 y tabla 1).
Figura 1. Elementos de la arquitectura de un sistema IoT
59
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 interaccin con los usuarios (entrada y salida): La
interfaz permite que el usuario configure el sistema, ingrese los parmetros
de operacin, revise resultados y ejecute operaciones. La funcin de la
interfaz es facilitar el control y la administracin 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 solucin
personalizada es necesario desarrollarla de acuerdo con los requerimientos
del sistema.
Adquisicin de datos del entorno (entrada): Captura de datos del
entorno por medio de sensores y los enva a la dispositivo de control para
su procesamiento.
Protocolos de comunicacin (procesamiento): Se
encargan
del
intercambio de informacin entre los dispositivos que conforman el
sistema, y son un elemento crtico para su interconexin.
Equipo o software controlador (procesamiento): Es el equipo que recibe
los datos de los sensores, los procesa y de acuerdo con rutinas pre-establecidas
enva rdenes a los actuadores.
Procesamiento y anlisis de los datos obtenidos (procesamiento): Lo
conforman los algoritmos y mtodos que se encargan del tratamiento y
anlisis 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.
Ejecucin de tareas (salida): Cuando la salida del sistema conlleva una
actuacin sobre el entorno, se ejecutan acciones por medio de actuadores
para modificar determinadas condiciones. Pero cuando se busca modificar
las condiciones del entorno, las tareas que se llevan a cabo pueden consistir
en el anlisis o ejecucin 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 ms compleja es la propuesta por Intel (Intel, 2015), la cual
contempla el uso de un gran nmero de protocolos de comunicacin, conexin a
sistemas de almacenamiento y anlisis y, servidores locales y en la nube.
2.1.
Interconexin de dispositivos
Las topologas de comunicacin 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). Segn el tipo de topologa que se utilice, los datos pueden ser
recibidos, integrados y procesados por solo un dispositivo (el cual cumple la
funcin de controlador general) o por cada dispositivo en el sistema.
60
Crdoba et al.
En cualquiera de las topologas sealadas, los dispositivos receptores y

transmisores conforman segmentos de comunicacin (ver figura 1), que pueden
utilizar diferentes protocolos. La clasificacin genrica 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 caractersticas especficas. Por lo que
es comn que se requiera utilizar dispositivos de varios fabricantes diferentes,
los cuales pueden utilizar protocolos, medios de transmisin y distancias de
cobertura distintas. Entre los protocolos de comunicacin ms utilizados en
IoT se encuentran X10 (Cuevas, Martnez, y Merino, 2002), NFC, ZigBee,
Bluetooth, RFID (Chavarra, s.f.), KNX (Maldonado y Alcibiades, 2015),
Z-Wave (Buxeres Soler, 2014) y SigFox(Crdenes Tacoronte, 2016) (ver tabla
1).
Algunos protocolos mencionados en la tabla 1 comparten ciertas
caractersticas, como el tipo de aplicacin 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
interconexin de dispositivos que usan diferentes protocolos.
2.2.
Puertas de enlace
Las puertas de enlace cumplen varias funciones adems de servir como

intermediarias en la comunicacin entre dispositivos. Esas funciones pueden
incluir el procesamiento de informacin, gestin 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 implementacin 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 cdigo fuente y admite la posibilidad de agregarle funcionalidad a los
protocolos. Estas interfaces son funciones que se pueden invocar desde diferentes
lenguajes de programacin. Por su parte, las puertas de enlace por hardware
sirven como punto de interconexin de dispositivos por medio de interfaces fsicas
o procesadores de comunicaciones inalmbricas de distintos tipos.
El proceso de interconexin que realizan las puertas de enlace por software y
hardware requiere la desencapsulacin y encapsulacin de datos, para decodificar
y codificar la informacin en los formatos que utilizan tanto el origen como el
destino de la comunicacin. Lo que implica que la puerta de enlace debe procesar
las unidades de datos del protocolo (UDP) para cada capa del modelo o estndar
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

Protocolo
X1O
Uso
Frecuencia
Red elctrica 120 KHz
domstica
Cobertura
N/A
NFC
Aplicaciones
con poco
volumen de
datos
Domtica
13,56 MHz
10 cm
N/A
N/A
Datos
inalmbricos
Datos
inalmbricos
868 GHz 915 10 a 75 m

GHz 2,4 GHz
Menos de 1
30 a 200 m
GHz (vara
segn el pas)
2,4 GHz
10 m
KNX
ZigBee
Z-Wave
Bluetooth
Datos
inalmbricos
Datos
inalmbricos
61
Otras caractersticas
Utiliza la red
elctrica domstica
como medio de
transmisin.
Diseado para
aplicaciones de
autenticacin.
Paralelo a la red
elctrica
Diseado para bajo
consumo de energa.
Tranmisin de baja
potencia.
Utiliza enlaces de
frecuencia libre.
RFID
9-135 KHz
2 a 100 m
Tecnologa con
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 opcin para
Smart Cities por la
distancia que logra
abarcar.
Cuadro 1. Comparacin de los protocolos mas utilizados por IoT
cableadas e inalmbricas (DELL, 2016b, 2016a) para interconectar protocolos

como ZigBee, BACnet y ModBus, entre otros. Mientras que Intel IoT
Gatewayonsiste de 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) tambin cuentan con puertas de enlace que tienen
caractersticas similares a las mencionadas.
3.
Propuesta de diseo
Las arquitecturas comerciales de IoT pueden resultar costosas, lo cual pone

de relieve la necesidad de contar con un diseo cuya implementacin sea sencilla y
econmica. Con base en esto, este trabajo propone el diseo de una arquitectura
basada en una puerta de enlace que se compone de un dispositivo de control,
62
Crdoba et al.
mdulos de comunicacin y bibliotecas para el intercambio de informacin entre

el dispositivo de control y los mdulos (ver figura 2).
Figura 2. Arquitectura con dos mdulos de comunicaciones.
El diseo 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 diseo reducido y propiedad registrada, pero de uso
libre, lo cual permite que los usuarios puedan modificar y agregar mdulos de
acuerdo con sus necesidades. As, por ejemplo, es posible que agreguen mdulos
de memoria adicional u otros mdulos para comunicarse con diferentes protocolos
y tecnologas como ZigBee, Z-Wave, RFID, 3G y GSM. Adems, 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 versin adaptada de
Debian, denominada como RaspBian, y el precio de los mdulos de comunicacin
que se le pueden agregar es relativamente bajo. Lo que hace que el costo de
implementacin de esta propuesta sea significativamente bajo, en comparacin
con las opciones de puertas de enlace propietarias que existen en el mercado.
El diseo propuesto contempla el uso de cualquiera de los protocolos de los
mdulos que soporta Raspberry Pi, pero cabe sealar que de acuerdo con la
investigacin realizada, los protocolos ms utilizados por los sistemas IoT son
Z-Wave y RFID.
3.1.
Escenario de uso
Un edificio con un gran nmero de espacios cuenta con puertas de apertura

y cierre automtico, circuitos de iluminacin, sistema de deteccin de incendios
y cmaras de seguridad con sensores de movimiento.
63
Cada da por la maana, se deben abrir las puertas, encender las luces de
cada sitio de manera individual y revisar los videos de las cmaras. Este proceso,
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 maana
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 despus de la hora de
salida oficial. Esto afecta el desarrollo de algunos proyectos de alta prioridad
debido al proceso burocrtico para justificar las razones de una jornada
especial, y como consecuencia se activa un protocolo de seguridad especial.
La revisin de los videos puede tomar varias horas, por lo que es frecuente
que se realice su revisin cuando sucede un incidente.
En general, la administracin no puede conocer detalles sobre los eventos que
se generan en torno a la apertura de puertas, iluminacin, alarmas de incendio y
cmaras porque no cuenta con un sistema de alertas y estadsticas 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 organizacin y el escenario descrito requieren considerar el diseo
e implementacin de los siguientes sistemas:
Control: El fin de este sistema es controlar las luces, sensores de incendios,
cmaras y la apertura de puertas utilizando los protocolos RFID y Z-Wave.
Gestin: El objetivo de este sistema es realizar el procesamiento de la
informacin, enviar notificaciones de emergencia y realizar el anlisis de
patrones de identificacin y comportamiento a partir de la informacin de
los sensores y vdeos.
Conforme con lo anterior, el funcionamiento del subsistema de iluminacin,
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
identificacin, cuya lectura es realizada por un mdulo 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 envo de seales 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 configuracin de la red de dispositivos
Z-Wave de acuerdo con las instrucciones de los fabricantes y programar los
scripts en un lenguaje de programacin, como Python. Las rutinas que deben
comprender los scripts cuando el lector RFID detecta una tarjeta son las
siguientes:
64
Crdoba et al.
Encender los circuitos de luces y abrir la cerradura de las puertas, si la

ltima condicin de las luces es apagado y la condicin de las cerraduras
es cerrado.
Apagar los circuitos de luces y cerrar las puertas si la ltima condicin de
las luces es encendido y la condicin de las cerraduras es abierto.
En cuanto al sistema de gestin de eventos y anlisis de patrones, este se
encuentra conformado por el dispositivo de control y el sistema de anlisis
(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 enva 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 adems enva los datos
de todos los eventos e imgenes que registran las cmaras a un sistema de
anlisis en la nube.
Sistema de anlisis: Este sistema se encuentra en la nube se encarga
de procesar los datos conforme los recibe e integra los resultados del
procesamiento con los resultados histricos. El anlisis 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 anlisis de imgenes captadas por las cmaras con el fin de identificar
personas y sus patrones de comportamiento.
Estadsticas y patrones: Los resultados del anlisis son representados de
forma visual para hacerlos ms comprensibles y tiles para los usuarios.
En cuanto a la implementacin del sistema completo, se requieren los
siguientes componentes de hardware:
Dispositivo de control - Raspberry Pi (PCB): Este
dispositivo
se
describe como una mini-computadora con todas las caractersticas
necesarias para realizar las tareas de control y procesamiento de datos, pero
adems se conecta a la nube para enviar datos para su almacenamiento
y procesamiento. El modelo utilizado debe contar con puerto Ethernet o
conexin usando 802.11n.
Mdulos Z-Wave: Se recomienda utilizar Razberry (RaZberry, 2016), para
permitir la comunicacin 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
cmaras.
Razberry cuenta con una interfaz de usuario que permite su rpida
implementacin, pero tambin facilita el desarrollo de interfaces
personalizadas por encontrarse disponible la documentacin del fabricante
para ese fin.
Mdulo RFID: Este mdulo permite la lectura de las tarjetas RFID y
mantiene activado en modo de lectura al dispositivo de control (Raspberry
Pi) para que capte las seales transmitidas por los tags" RFID.
Referencias
4.
65
Conclusiones
Este trabajo de investigacin llev a cabo una revisin bibliogrfica sobre

los principales protocolos y arquitecturas que se utilizan en IoT. Dicha revisin
permiti analizar y discutir sobre el estado actual de Internet de las Cosas y
las implicaciones que tiene el uso de protocolos diferentes en los procesos de
interconexin y comunicacin.
Como resultado, fue posible conocer con mayor detalle y poner de
manifiesto la relacin que existe entre los protocolos, dispositivos, fabricantes
y arquitecturas en el proceso de comunicacin. Lo cual permiti proponer una
arquitectura de bajo costo para la interconexin de protocolos y dispositivos
heterogneos en sistemas IoT.
Las ventajas del diseo presentado son su sencillez, posibilidades que ofrece
para la interconexin, facilidad de implementacin, bajo costo, gestin de alertas
y anlisis 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 anlisis de informacin que incorpora la propuesta
contempla el 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
adems proporcionar mecanismos de inteligencia para la deteccin de patrones
anormales que pueden requerir la toma de accin inmediata.
Como trabajo futuro, se estar realizando la implementacin de la
arquitectura propuesta y se estarn desarrollando casos de uso de mayor
complejidad para validar la arquitectura y agregar factores de la 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
librera abierta para el uso del protocolo inalmbrico de domtica Z-Wave.
Crdenes Tacoronte, D. (2016). Diseo e implementacin de una herramienta
para la verificacin de cobertura de la red SIGFOX. Estudio de
conectividad en una zona geogrfica de orografa compleja.
Chavarra, D. A. C. (s.f.). Tecnologa de comunicacionn de campo cercano (nfc)
y sus aplicaciones.
Cuevas, J. C., Martnez, J., y Merino, P. (2002). El protocolo x10: una
solucin antigua a problemas actuales. En Simposio de informtica 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
66
Crdoba et al.
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
James Manyika, J. W., y Dobbs, R. (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
Maldonado, J., y Alcibiades, P. (2015). Estudio y diseo de un sistema inmtico
para seguridad, comunicacin y confort, utilizando el protocolo KNX para
el edificio Torre Piamonte ubicado en el sector de Totoracocha de la ciudad
de Cuenca.
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 Geolocalizacin en Imgenes Rster

para la Identificacin de Especmenes Biolgicos
Jonathan Quintana Berros, Esteban Robleto Rodrguez y
San Jos, Costa Rica
[jquintanab798,erobletor703]@ulacit.ed.cr
Resumen La identificacin de especmenes de la flora y fauna ayuda a

conservar la riqueza de los ecosistemas al permitir conocer su composicin
y niveles de riesgo, en trminos de extincin. Por cual es necesario que los
cientficos que llevan a cabo dicha identificacin cuenten con los mtodos
y herramientas necesarias para realizarla de forma efectiva y eficiente.
En este contexto, el objetivo de este trabajo de investigacin es apoyar
la identificacin de especmenes biolgicos mediante el uso de mapas con
informacin georeferenciada, almacenada en imgenes rster. Con ese
fin, se desarroll una prueba de concepto para el procesamiento de la
informacin de georeferenciacin, usando bibliotecas de cdigo 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 contribucin de este trabajo es la implementacin de una
herramienta sencilla para extraer las coordenadas geogrficas de las
localizaciones donde se han recolectado muestras de especies biolgicas.
Palabras clave: Analtica visual, GeoTIFF, GeoKey, Imgenes rster,
Metadatos, SIG
1.
Introduccin
El reconocimiento de especmenes biolgicos representa un reto para los

cientficos (bilogos), debido al nmero de caractersticas que diferencia entre s
a las especies de flora y fauna. En este contexto, el uso de elementos taxonmicos
y claves de identificacin reviste especial importancia porque permite clasificar
a las muestras por medio de su sus caractersticas fsicas visibles.
Los principales elementos que intervienen en el proceso de identificacin,
son los caracteres y los estados de carcter, en donde el trmino carcter hace
referencia a las caractersticas generales de las especies mientras que estados de
carcter se refiere a las caractersticas especficas.
68
Quintana et al.
Las herramientas especializadas para la identificacin de especies que existen,

tanto comerciales como no comerciales, se basan en rboles de decisin que
permiten elegir caracteres y estados de carcter de acuerdo con las caractersticas
de la muestra. Sin embargo, el uso de informacin de geolocalizacin, relacionada
con los lugares donde han sido recolectadas las muestras de una especie, no ha
sido explorada de forma amplia. Por lo que el uso de informacin de georeferencia,
en conjunto con el uso de rboles de decisin, puede contribuir en la mejora del
proceso de identificacin de especmenes biolgicos.
Conforme con lo anterior, este trabajo de investigacin busca apoyar el
desarrollo de Iriria, una herramienta de Analtica Visual1 , mediante el uso de
la informacin georefenciada que se encuentra almacenada en mapas codificados
como imgenes rster2 . Cabe mencionar que los cientficos pueden crear reas
trianguladas, que pueden estar superpuestas, a partir de las localizaciones donde
han encontrado muestras de determinadas especies y que dichas reas pueden
ser almacenadas por mapas rster.
Como consecuencia, la seccin 2 lleva a cabo una revisin detallada sobre
el uso de imgenes rster para la codificacin y decodificacin de informacin
georefenciada, mientras que la seccin 3 presenta los resultados del trabajo
y la seccin 4 discute las principales conclusiones y trabajo futuro de esta
investigacin.
2.
Estado del arte
Los archivos en formato GeoTIFF (Ritter y Ruth, 2000) permiten almacenar

tanto coordenadas geogrficas como metadatos y pueden ser ledos con facilidad
por la mayora de sistemas de informacin geogrfica (SIG). Las imgenes que
utilizan este formato son conocidas como imgenes rster, y almacenan datos
de georeferenciacin en cada uno de los pixeles, los cuales forman parte de
una matriz conformada por cientos de pixeles que en conjunto proporcionan
informacin detallada.
En una imagen rster, por ejemplo, una matriz puede ser bidimensional o
tridimensional, en funcin del tipo de imagen. En el caso de las imagenes en
2D, las coordenadas geogrficas (i.e. latitud y longitud) se almacenan en un
cuadrante x,y de la matriz, mientras que en el caso de las imgenes 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 monocromticos o primarios
(azul,verde y rojo)3 .
1
La Analtica Visual utiliza una combinacin de visualizacin de la informacin,

interaccin persona-computadora y el razonamiento de las personas para la obtencin
de conocimiento (Aigner, Bertone, y Miksch, 2008).
Rster se refiere al trmino ingls raster", que hace referencia a imgenes que
almacenan metadatos relacionados con la representacin grfica que realizan.
Los colores rojo, verde y azul son conocidos por sus siglas en ingls como RGB.
69
Entre los tipos de archivos ms comunes para el almacenamiento de imgenes

rster se encuentran los siguientes:
BMP (bipmap).
TIFF(Tag Image File Format).
GIF(Graphics Interchange Format).
JPEG (Joint Photographics Experts Group).
Para manipular las imgenes rster existe un gran nmero de herramientas
comerciales4 y no comerciales, pero tambin es posible encontrar bibliotecas para
crear aplicaciones propias. En este trabajo de investigacin se est considerando
el uso de bibliotecas de cdigo abierto para la manipulacin de los mapas,
codificados como imgenes rster, para evitar las restricciones que imponen las
licencias de uso comercial.
El tamao de las imgenes puede ser superior a los 4 gygabytes, en funcin
de los metadatos que contengan, lo cual requiere que sean almacenadas en un
formato conocido como BigTiff. Por esa razn, las imagenes se comprimen para
facilitar su manipulacin, pero el tipo de compresin influye en la lectura de
imgenes rster y es necesario efectuar el procesamiento de forma correcta para
no perder informacin. En el caso de la biblioteca de GeoTIFF utiliza el formato
de compresin BitPack".
El almacenamiento de informacin se realiza utilizando bytes en lugar de
bits, lo cual permite tener ms datos comprimidos dentro de un archivo TIFF,
y que a la hora de apuntar a una posicin donde se encuentran agrupados unos
y ceros, se pueda hacer referencia a una posicin dentro del arreglo y no a un
valor particular5 .
En los archivos TIFF la informacin se almacena usando cuadrculas de
cientos o miles de puntos en notacin 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 rster, conocido tambin como R, es importante saber
que los pixeles se ubican dentro de una cuadrcula. 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 estn organizados en un
catlogo de GeoKeys"(GeoKeyDirectoryTag) (Ritter y Ruth, 2000), que se
almacena en el encabezado de los archivos. Las GeoKeysontienen etiquetas
TIFF reservadas que tienen informacin pblica o privada sobre una regin o
lugar especfico y usan un identificador numrico 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 especficos.
Los parmetros del encabezado de los archivos GeoTIFF se basan en una
estructura geogrfica, que fue desarrollada por European Petroleum Survey
Group (EPSG/POSC). Estos parmetros se utilizan para identificar posiciones
4
Entre las herramientas comerciales mejor conocidas para la manipulacin de

imgenes rster se encuentran AutoCad, Adobe Ilustrator y Photoshop.
A esta forma de guardar datos dentro de un TIFF se le conoce como Big and Little
Endian.
70
Quintana et al.
geogrficas en un sistema de coordenadas e implica la utilizacin 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,
tambin 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 estndar de parmetros, para
hacer una proyeccin del mapa de forma plana, usando la representacin de la
tierra por medio de longitudes y latitudes.
3.
Resultados
La implementacin de la herramienta se llev a cabo utilizando

GeoTIFF(Schindler, 2015), una biblioteca en JavaScript para leer los metadatos
contenidos en las imgenes rster(xavier lhomme, 2014).
La lectura de una imagen rster conlleva la identificacin 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 extrados y cargados por la herramienta, lo cual produce un efecto de
cambio de color de la imagen, lo que se debe a que la informacin 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 imgenes que
son procesadas.
Figura 1. Imagen tomada de Open Street Maps (Foundation, 2006)
71
En el contexto de la identificacin de especmenes biolgicos, se requiere leer

las latitudes y longitudes de las ubicaciones geogrficas en las cuales se han
recolectado muestras de las especies biolgicas, por lo que se lee la informacin
que se encuentra almacenada por las GeoKeys y utilizar mapas en formato
plano.
El procesamiento de las imgenes se lleva a cabo usando una funcin
denominada como "loadmaps", la cual carga la imagen de un mapa rster, para
una regin geogrfica seleccionada. Esta funcin utiliza OpenLayers (Kirkman
y Davis, 2014), una biblioteca de cdigo abierto, para ubicar sobre el mapa
(figura 1) la imagen de la zona geogrfica escogida, con base los metadatos de
geolocalizacin.
Una vez que la imagen ha sido cargada y procesada, es posible observar la
informacin que tiene codificada (ver figuras 2 y 3).
Figura 2. Imagen luego de ser mapeada
Los pasos del algoritmo que se sigue una vez que la imagen es cargada son
los siguientes:
72
Quintana et al.
Figura 3. Imagen procesada por las libreras, los colores se encuentran definidos por
las etiquetas y, podran ser utilizados para identificar datos en un mapa
1. Se realiza la bsqueda 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 funcin para obtener un TagName". Esta funcin compara el
valor de la etiqueta y los valores de etiqueta que estn definidas en el cdigo
el cdigo 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 nmero de veces que sea necesario, en funcin de

las GeoKeys.en los metadatos de la imagen.
En el contexto de la identificacin de especmenes biolgicos, para determinar
si una muestra de una especie ha sido recolectada en una regin, se realiza la
lectura de la posicin del puntero del ratn cuando se pasa sobre el mapa6 , y con
base en las coordenadas geogrficas (latitud y longitud), se consulta la base de
datos para conocer obtener una lista de las especies que se encuentran asociadas
a esas coordenadas.
6
La lectura de posiciones geogrficas se realiza mediante el uso del atributo

"mouseposition"
Referencias
4.
73
Conclusiones
El almacenamiento de metadatos en mapas codificados como imgenes rster

es un recurso valioso para asociar datos de diferente ndole a localizaciones
geogrficas especficas. Por lo que en el contexto de la identificacin de
especmenes biolgicos resulta de gran utilidad para obtener detalles acerca de
las especies que se han identificado en una zona o regin particular.
Entre los detalles de las especies que se pueden almacenar en los mapas se
encuentran la fecha en que las muestras fueron recolectadas, quien las recolect
y la institucin a la cual se encuentra vinculado el recolector.
En general el tratamiento de este tipo de imgenes no es un proceso trivial,
se requiere de anlisis y estudio para comprender los conceptos generales y
especficos que luego pueden ayudar a estudiar el cdigo y ejemplos de las
bibliotecas disponibles.
El principal aporte de este trabajo de investigacin consiste en la
documentacin inicial de los conceptos relacionados con imgenes rster y la
implementacin de una prueba de concepto sobre la lectura de este tipo de
imgenes, en el contexto del desarrollo de Iriria.
En lnea con lo anterior, como trabajo futuro se estar ampliando la prueba
de concepto para realizar la escritura de informacin, sobre las muestras de
especies, en las imgenes rster, as como la integracin de la implementacin
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
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
xavier lhomme. (2014, dec). A javascript-based parser for the geotiff image
format. Descargado de https://github.com/xlhomme/GeotiffParser
.js
Caracterizacin de Malware usando Lenguajes de

Intercambio de Inteligencia
Randall Barnett Villalobos, Susan Rodrguez Segura, Julio Chinchilla Moya y
Wilson Acua Araya
San Jos, Costa Rica
[mcordobap487,ftrejosm824,fchinchillaj980]@ulacit.ed.cr
Resumen Para el ao 2015 los laboratorios de Panda Security

procesaron en promedio 230 mil muestras de malware por da, es decir,
84 millones al ao. Eso implic un incremento de 9 millones ms que
en 2014. Es en este escenario que el intercambio de inteligencia en
el rea de la seguridad informtica busca convertirse en un estndar
que permita compartir las caractersticas de las ciberamenazas de una
manera estndar. Con la utilizacin de metalenguajes de comunicacin
y metalenguajes de observabilidad, se logra realizar el intercambio
de informacin sobre amenazas entre distintas fuentes, efectuando la
caracterizacin de los archivos para compartir la informacin obtenida
de forma estndar.
Palabras clave: Internet de las cosas, Protocolos, Comunicaciones
1.
Introduccin
Para la identificacin de nuevas amenazas es necesario profundizar en el tema

de lenguajes de intercambio de inteligencia. La organizacin MITRE propone
varios metalenguajes que permiten aprovisionar al investigador, de un sistema
de caracterizacin y bsqueda entre distintas fuentes de informacin para la
deteccin de vulnerabilidades.
Estos metalenguajes son verstiles, ya que permiten crear herramientas de
software por medio de los APIs de MITRE, para poder consultar la informacin
en tiempo real. Adems, permiten obtener datos de diversas fuentes ya sean
propias o proporcionadas por terceros, que sirven como una base de conocimiento
gratuita para la rpida resolucin de incidentes de ciberseguridad.
La idea central de esta investigacin, es la creacin de una herramienta de uso
libre donde las organizaciones y empresas a nivel global tengan la facilidad de
aprovisionar, consultar y colaborar con informacin de los archivos sospechosos
que detecten en sus sistemas al haber recibido algn ataque. Esta herramienta
posee la capacidad de extraer datos relevantes de archivos sospechosos y
Caracterizacin de Malware usando Lenguajes de Intercambio de Inteligencia
75
comparar la informacin obtenida para la caracterizacin de estas amenazas.

En una segunda etapa, se espera que tenga la capacidad de compartir los datos
importantes de caracterizacin del malware informtico en una base de datos de
conocimiento global.
Para lograr la creacin de esta herramienta, se utilizaron dos grupos de
metalenguajes un framework de intercambio de informacin entre servidores que
las APIs de MITRE ofrecen:
1. Framework de comunicacin: TAXII.
2. Metalenguaje de Comunicacin: STIX.
3. Metalenguajes de Observabilidad: Ac se utilizaron el MAEC, adems de
CybOX.
El intercambio de inteligencia trata del anlisis de la informacin con el fin
de compartir los hallazgos encontrados en artefactos de software, para poder
realizar una caracterizacin de las amenazas. Esto permite: describir el tipo de
ataque ulterior, informacin importante de su origen, especificaciones de cmo
reconocerlo y posteriormente analizar la manera de cmo evitarlo (EclecticIQ,
2016).
Los ataques por medio de la web tienen el objetivo de obtener informacin
o acceso a los sistemas crticos de una organizacin. Para las empresas u
organizaciones es vital tener conocimiento de las amenazas a las que se estn
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
ciber-inteligencia para perfilar y evitar futuras amenazas.
Para realizar este proceso se utilizaron los APIs provistos en Python 2.X para
extraer informacin relevante de los archivos, estandarizarlos y ordenarlos de una
manera comprensible al ser humano, sin importar la fuente de procedencia. Lo
anterior permita realizar la comunicacin y el intercambio de inteligencia de
manera sencilla, prctica 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 accin
y los reportes.
Este metalenguaje muestra la informacin en formato XML fuertemente
tipado, el cual es utilizado para representar los datos adquiridos de una forma
ms legible.
Para hacer uso de STIX se deben importar las siguientes libreras de Python:
import stix.utils as utils
from stix.utils import IDGenerator,
set_id_method
from stix.core import STIXPackage,
76
Barnett et al.
STIXHeader
from stix.indicator import Indicator
from stix.common import InformationSource,
Identity
Adems 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 ac 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 unvoca, hacindolo 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 servirn para poder compartir el objeto observable,
por lo que se debe aadir la fuente de informacin, por lo que se usarn los
parmetros de inicializacin para 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 se inspeccionado por el API y
aadirlo a la coleccin 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.
77
TAXII
TAXII no se refiere a un programa de intercambio, sino a un conjunto de

especificaciones para el intercambio de informacin de amenazas cibernticas y
as ayudar a las organizaciones a compartir informacin relevante sobre estas
amenazas. Este framework trabaja como un mecanismo de transporte para
STIX que estandariza automticamente la informacin sobre amenazas (MITRE,
2014).
TAXII tiene tres modelos de reparto de informacin:
1. Hub and spoke: donde una organizacin funciona como un centro o
repositorio de intercambio de informacin para distintas organizaciones que
ver e incluir informacin.
2. Source/subscriber: donde una organizacin funciona como una nica fuente
de informacin para otras organizaciones donde solamente pueden ver la
informacin.
3. Peer to Peer: donde dos o ms organizaciones comparten informacin entre
s directamente.
TAXII define el comportamiento de cuatro servicios, de cmo esa informacin
ser compartida:
1. Bandeja de entrada: un servicio para recibir contenido insertado, es
bsicamente un oyente de contenido entrante.
2. Encuesta: un servicio para solicitar contenido de una fuente de datos
3. Gestin de cobros: un servicio para conocer y solicitar suscripciones a
colecciones de datos.
4. Descubrimiento: Aprender qu servicios son compatibles y cmo interactuar
con ellos.
Para hacer uso de TAXII se deben importar las siguientes libreras:
libbtaxii que contiene informacin de la versin y mtodos para mensajes de
respuestas HTTP.
libtaxii clients para clientes HTTP y HTTPS.
libtaxii constants que contiene constantes.
libtaxii messages la cual crea, maneja y analiza los mensajes.
El siguente cdigo muestra cla 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)
78
Barnett et al.
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 cdigo 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 viajarn entre servidores que consuman el servicio web que
aprovisione el mensaje.
1.3.
Relacin entre STIX y TAXII
Esta relacin permitir el intercambio y el transporte de informacin sobre

amenazas entre distintas organizaciones. TAXII puede transmitir en su carga
til el paquete de STIX, y definir cmo se va a compartir sta informacin a
travs de la red local o global. En la Figura 1 se muestra como interactuan entre
s los metalenguajes de STIX y TAXII.
79
Figura 1. Interaccin entre STIX y TAXII
2.
Analizador de direcciones IP
El analizador trata de una aplicacin funcional para el anlisis de cualquier

direccin IP en distintas bases de datos, con el fin de obtener informacin de
su estado y ubicacin geogrfica. Adems de analizar la IP deseada, es posible
visualizar y agregar otras direcciones de pginas Web de lista negra a la base de
datos. En la figura 2 se muestra la imagen del resultado obtenido en la aplicacin
Intel-Sharing, donde identifica la informacin, los servidores donde se encuentra
en lista negra y la ubicacin aproximada de la direccin IP ingresada.
Figura 2. Resultado del analizador Web de direcciones IP
3.
Virus total
A la aplicacin 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
80
Barnett et al.
indica la cantidad de detecciones por antivirus, que fueron encontrados en el

archivo analizado.
La herramienta Virus Total tiene la funcin de indicar si el archivo que se est
analizando para ser caracterizado, cuenta con algn tipo de cdigo malicioso, el
cual es detectado por alguno 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 ste mismo dato en virus total donde proporciona el resultado. Luego
de verificar el archivo malicioso se procede a realizar el empaquetado de la
informacin 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 informacin
respectiva en pantalla (Barnum, 2014).
4.
Resultados
El tema de lenguajes de intercambio de informacin an est poco

desarrollado, con la utilizacin de ellos se pueden explorar muchas
funcionalidades tiles para cualquier empresa, sea cual sea la orientacin del
negocio. Existe gran cantidad de informacin que se puede obtener realizando
la caracterizacin de un archivo malicioso. Se logr caracterizar ms de 100
artefactos de software, almacenando la informacin resultante en una base de
datos MySQL, que incluye:
Nmeros de identificacin unvocos.
Listas negras de donde se encuentra el elemento caracterizado y resultados
de escaneos en ms de 60 antivirus por cada artefacto analizado.
Caracterizaciones completas de cada artefacto de software analizado.
Listado de IPs y DNS encontrados en listas negras.
Figura 3. Reporte de aplicacin Intel-Sharing.
Referencias
5.
81
Conclusiones
El tema de metalenguaje de intercambio de informacin an est

poco desarrollado. Con la utilizacin de ellos se pueden explorar muchas
funcionalidades tiles para cualquier empresa, sea cual sea la orientacin del
negocio. Existe gran cantidad de informacin que se puede obtener al realizar la
caracterizacin de un archivo malicioso, el cual conlleva a investigar ms 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 documentacin extensa sobre el
tema, lo que dificulta la implementacin de este tipo de aplicaciones.
6.
Recomendaciones
Esta investigacin sobre lenguajes de intercambio de inteligencia, an debe

ser un tema que se investigue ms a fondo, ya que abarca un sin nmero
de funcionaldades, las cuales no fueron desarrolladas al 100 por ciento en
este proyecto. Es importante seguir desarrollando funcionalidades de CyBOX
y MAEC, as como STIX y TAXII. An se debe modificar la manera de
trabajar de STIX para que reciba la informacin requerida por medio de
parmetros. Un punto importante para aplicar en la siguiente investigacin es
la implementacin 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 caracterizacin completa. Se debe agregar seguridad a la aplicacin e
implementar sockets para mejorar el rendimiento de la aplicacin, para que logre
leer ms de un archivo (por ejemplo una carpeta completa con n cantidad de
archivos). Se debe de continuar con el desarrollo de un servidor TAXII donde se
pueda recibir el paquete que est listo, para ser enviado por la aplicacin 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 (stixTM ). 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 Gonzlez Torres (Ed.)

Tecnologías de La Información y Gestión de Proyectos

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tecnologías de La Información y Gestión de Proyectos

Încărcat de

Drepturi de autor:

Formate disponibile

Dr. Antonio Gonzlez Torres (Ed.

Facultad de Tecnologas de la Informacin

Dr. Antonio Gonzlez Torres (Ed.)

Facultad de Tecnologas de la Informacin

Reservados todos los derechos. Prohibida la reproduccin no autorizada por

A quienes trabajan mientras suean.

Nos complace presentar este primer volumen de publicaciones de las

han sido el compromiso de los profesores investigadores que conforman el

Msc. Edwin Aguilar Snchez

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

Metodologa para la gestin de terceros en procesos de desarrollo de

Metodologa para la gestin de terceros en

Resumen La tercerizacin permite que las empresas reduzcan costos,

La evolucin en los negocios ha propiciado mayor competencia en todos los

Definicin de los requerimientos.

La tercerizacin es conocida en ingls como outsourcing.

Metodologa para la gestin de terceros en procesos de desarrollo de software

metodologa para sintetizar algunas de las mejores prcticas e investigaciones

Estado del arte

Los procesos de tercerizacin del desarrollo de software, por lo general, son

En lnea con lo anterior, un modelo para la administracin del proceso de

Metodologa para la gestin de terceros en procesos de desarrollo de software

Debido a la aceptacin de la tercerizacin como un mtodo eficaz para apoyar

Con base en los conceptos discutidos hasta este punto, y la recopilacin de

Fases para la gestin de terceros en proyectos

En esta seccin se presenta la propuesta de una metodologa para apoyar la

Metodologa para la gestin de terceros en procesos de desarrollo de software

5. Administracin de la relacin con el proveedor.

En las siguientes secciones se explica con detalla las fases contempladas en

Esta fase tiene por fin verificar la necesidad de desarrollar un sistema

Metodologa para la gestin de terceros en procesos de desarrollo de software

Elaboracin de la descripcin general del sistema por medio de reuniones,

Esta fase corresponde a la definicin de los aspectos que se deben de tomar

la gestin de la calidad de software se deben considerar (IEEE Computer

Metodologa para la gestin de terceros en procesos de desarrollo de software

encargado, el cual facilite el proceso y est en disposicin de utilizar

Proceso de escalamiento, con identificacin de los plazos y la cadena de

Metodologa para la gestin de terceros en procesos de desarrollo de software

Establecer y documentar los criterios de aceptacin: Estos

Seleccin y contratacin del proveedor

La fase de seleccin y contratacin conlleva efectuar la recepcin de ofertas,

La fase de ejecucin contempla la etapa de desarrollo del sistema y requiere

La administracin de la relacin con el proveedor enfoca sus esfuerzos en

Metodologa para la gestin de terceros en procesos de desarrollo de software

Figura 2. Diagrama de gestin de calidad

Efectuar por lo menos dos reuniones formales a la semana, siempre y

Figura 3. Diagrama de administracin de la relacin con el proveedor

Metodologa para la gestin de terceros en procesos de desarrollo de software

adems de analizar indicadores con respecto al cronograma, costos, calidad,

La fase de reconsideracin corresponde a una evaluacin con base en la

Conclusiones y trabajos futuros

La gestin de las relaciones con terceros es un elemento crtico cuando

Metodologa para la gestin de terceros en procesos de desarrollo de software

Figura 4. Diagrama propuesto de gestin de terceros para el desarrollo de software

La metodologa es una sntesis de los procesos y mejores prcticas que deben

of 2nd ibero-american symposium on software engineering and knowledge

Gestin de la Relacin con Terceros y

Resumen La tercerizacin del desarrollo de software es una prctica

El creciente y rpido cambio de la tecnologa trae diversos y complejos retos

Gestin de la relacin con terceros y metodologas giles

En la actualidad la tercerizacin de desarrollo de software es de alta relevancia

Estado del arte