Libro Informática

TECNOLOGAS DE
LA INFORMACIN
Y GESTIN DE PROYECTOS
Dr. Antonio Gonzlez Torres (Ed.)
Facultad de Tecnologas de la Informacin

ULACIT
Dr. Antonio Gonzlez Torres (Ed.)
Tecnologas de la Informacin
y Gestin de Proyectos
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.
TECNOLOGAS DE LA INFORMACIN Y GESTIN DE PROYECTOS
Prefacio
Nos complace presentar este primer volumen de publicaciones de las investigaciones realizadas
por profesores y estudiantes de ULACIT de la carrera de Ingeniera Informtica, en las que se
abordan aspectos interesantes de la tecnologa de informacin y la gestin informtica. Estos
artculos 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 la comunidad de estudiantes
de bachillerato, licenciatura y maestra en Ingeniera Informtica.
Se responde as al desafo formidable que enfrentan las universidades privadas para realizar in-
vestigacin cientfica en ingeniera, ciencias naturales o ciencias sociales, por la escasez de recur-
sos 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.
La investigacin cientfica en ingeniera en general y en tecnologa de informacin en parti-

cular busca encontrar soluciones eficaces y eficientes a problemas simples o complejos, apli-
cando sistemticamente el conocimiento cientfico y las herramientas tecnolgicas, para crear el
diseo de la solucin; y para desarrollar y construir dispositivos, estructuras y procesos, bajo res-
tricciones y requisitos impuestos por la tecnologa disponible y por consideraciones econmicas,
legales, ambientales y humanas.
Las publicaciones que se presentan en este primer volumen buscan hallar el camino para esta-
blecer un pequeo universo de lneas de investigacin que puedan consolidarse y profundizarse
en el tiempo, y 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 y recursos tecnolgicos y financieros, han sido: el compromiso de
los profesores investigadores que conforman el equipo de investigacin, la seriedad con que los
estudiantes han abordado sus labores de investigacin y el compromiso de las autoridades de la
Universidad para apoyar este esfuerzo.
El objetivo es formar a los profesores y estudiantes de la carrera de Ingeniera Informtica con las
competencias requeridas para efectuar investigacin cientfica en este campo, que propicie la
produccin de publicaciones que incrementen su desarrollo acadmico y proyecten a la Univer-
sidad en respuesta a las necesidades de talento de la economa costarricense. En este momento,
el sector industrial tecnolgico del pas (en diseo, manufactura y servicios tecnolgicos), com-
puesto por empresas trasnacionales y nacionales de base tecnolgica, emplea a ms de 50.000
ingenieros, de los cuales ms de 4.000 laboran a tiempo completo en equipos de investigacin
que buscan mejorar las cadenas de valor, 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
7
se expandan en el pas, pero estn enfrentando escasez de ingenieros con formacin en inves-
tigacin en ingeniera. De igual forma, las empresas le estn haciendo frente a la falta de lderes
de equipos de investigacin y administradores de investigacin, por lo que han manifestado que
necesitan 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 com-
petentes 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.
M.Sc. Edwin Aguilar Snchez

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

tica 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 informa-

cin 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
9
ndice general
Metodologa para la gestin de terceros en procesos de desarrollo de

software 12
Yeison Nez Snchez y Antonio Gonzlez Torres*
Gestin de la relacin con terceros y metodologas giles 33

Fabin Chaves Serrano, David Mora Solano y Antonio Gonzlez Torres
Definicin y modelado del proceso de gestin de la demanda para tecnologa de

informacin45
David Rodolfo Camacho Quirs, Reagan Ching Fung, Julio Crdoba Retana y Antonio
Gonzlez Torres
Recomendaciones para la gestin de incidencias de tecnologas de la

informacin54
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 cosas65
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 76
Jonathan Quintana Berros, Esteban Robleto Rodrguez y Antonio Gonzlez Torres
Caracterizacin de malware usando lenguajes de intercambio de

inteligencia82
Randall Barnett Villalobos, Susan Rodrguez Segura, Julio Chinchilla Moya y Wilson Acua
Araya
10
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, Urbaniza-

cin 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 pro-
ducto 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 utiliza-
das 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 estratgicos del negocio. Con ese fin utilizan como alternativa la terceriza-
cin1 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 iden-
tificar inconvenientes que se presentan durante su implementacin, debido a una deficiente
1 La tercerizacin es conocida en ingls como outsourcing.
12 | Metodologa para la gestin de terceros en procesos de desarrollo de software

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. Esto tiene como consecuencia que el producto final no respon-
da a las necesidades o no se ajuste a los requerimientos definidos por el cliente (Erazo-Paruma,
Guerrero-Mera y Correa-Pino, 2014).
Este tipo de inconvenientes suelen presentarse cuando la empresa contratante no realiza de for-
ma adecuada las siguientes tareas:
1. Definicin de los requerimientos.

2. Seleccin y contratacin del proveedor (Erazo-Paruma et al., 2014).
3. Identificacin del alcance del proyecto.
4. Definicin de la metodologa de desarrollo.
5. Participacin activa de los clientes o usuarios finales en el proceso de desarrollo.
6. Adecuada administracin y comunicacin con el proveedor.
A esto 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 (Selleo, 2016).
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 embar-
go, 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 tanto, los objetivos de este trabajo de investigacin
consisten en identificar el flujo del proceso de administracin de la relacin con terceros y propo-
ner una 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 de-
sarrollar una metodologa con las mejores prcticas para la gestin de proyectos de software en pro-
cesos de tercerizacin (seccin 3) y, finalmente, presenta las conclusiones y trabajos futuros (seccin 4).
Metodologa para la gestin de terceros en procesos de desarrollo de software | 13

2. Estado del arte

Los procesos de tercerizacin del desarrollo de software, por lo general, son complejos, y aun-
que 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 quines estarn involucrados
durante su desarrollo. Con base en esto, es relevante 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 proyec-
tos que se desea tercerizar y la naturaleza de estos.
Qu se requiere hacer? La respuesta a esta pregunta tiene por fin definir de forma precisa qu
es lo que se requiere hacer y cules son sus requerimientos.
Cmo cmo se llevarn a cabo las tareas o el proyecto? Por su parte la respuesta a esta
pregunta involucra no solo la metodologa por utilizar sino tambin la estructura del equipo de
trabajo que va a participar en su desarrollo.
Quin estarn involucrados? Es importante conocer quines sern los usuarios del sistema, los
gerentes o ejecutivos que apoyarn el desarrollo y quines 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 entien-
de de la siguiente forma:
Benchmarking interno: consiste en analizar las competencias centrales de la empresa y la

identificacin de los procesos que sern tercerizados, conforme 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.
En lnea con lo anterior, un modelo para la administracin del proceso de tercerizacin pue-
de contemplar (Erazo-Paruma et al., 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 acepta-
cin en conjunto con el plan de adquisicin, por lo que se procede a efectuar la planifica-
cin 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 nego-
ciados con el proveedor, y 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 cumpli-
miento 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 eva-
luar. para tomar acciones correctivas en caso de incumplimiento (Franceschini et al., 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 pueden agrupar en 5
grandes fases: preparacin, seleccin del proveedor, transicin, administracin de las relaciones
y reconsideracin (Perunovic y Pedersen, 2007). En estas fases se describen actividades que res-
ponden 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. Esta relacin es influenciada por la importancia de la ac-
tividad 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 cua-
les 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 res-
ponsabilidades, 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 quelos con-

tratos 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 (Cabi-
netOffice, 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 Ma-
nagement Institute, 2013).
Entonces, tomando como base las mejores prcticas de PMI y 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 usua-
rios mediante la adecuada definicin de requerimientos.
Gestin de las comunicaciones: este tipo de gestin es necesaria para propiciar una co-
municacin 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 or-
ganizaciones 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 usua-
rios. 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 con el proyecto, en torno a los elementos de calidad de sof-
tware (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 sof-
tware, 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 pro-
ducto y como consecuencia no se pueden desvincular (Mendoza et al., 2005). Por consiguiente,
el aseguramiento de la calidad se debe realizar durante todo el proceso, con la finalidad de que
se puedan corregir de inmediato las disconformidades (CENDITEL, Fundacin, 2013).
Con base en los conceptos discutidos hasta este punto, y la recopilacin de normas e investiga-
ciones con respecto a las evaluaciones de calidad Mendoza et al. (Mendoza et al., 2005) propo-
nen 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 as-
pectos 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 asegura-
miento 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 pro-
ducto 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 pro-
cesos de tercerizacin, usando como referencia la revisin y el anlisis efectuado en la seccin 2.
La metodologa propuesta se divide en 7 fases:
1. Inicio.
2. Planificacin.
3. Seleccin y contratacin del proveedor.
4. 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, adminis-
tracin 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 objetivo 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 busca 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 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 explican con detalle las fases contempladas en la figura 1.

3.1. Inicio
Esta fase verifica la necesidad de desarrollar un sistema por medio de la 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. Algunas 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 pro-
blema 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 Manage-
ment 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 provee-
dor en el cumplimiento de las expectativas del proyecto, las posibilidades de que ayude a
generar valor y contribuya a satisfacer las necesidades del cliente.
Riesgos asociados al desarrollo del proyecto: realiza una 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 objetivo 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.
Individualizacin de los proyectos a tercerizar: esta tarea tiene por fin comparar la efi-
ciencia de las actividades o procesos que realiza la organizacin, usando como base posi-
bles 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 encarga-
dos de la organizacin con la intencin de 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 in-

ternas que pueden ser beneficiadas o perjudicadas con el desarrollo del sistema. Esta
tarea busca garantizar la participacin de esas personas en el proceso.
3.2. Planificacin
Esta fase corresponde a la definicin de los aspectos que se deben tomar en cuenta para con-
trolar la ejecucin del proyecto y obtener el producto deseado, por lo que se debe efectuar la
definicin adecuada del alcance, los requerimientos, los elementos de calidad que se deben eva-
luar, el recurso humano necesario, las formas de comunicacin con el proveedor, la definicin de
criterios de seleccin de proveedor, el tipo de contrato a utilizar y el contenido presupuestario.
Como consecuencia, estas tareas se pueden desarrollar de la siguiente manera:
Definicin del alcance: brinda el panorama de alto nivel de los requerimientos del sistema,
por lo que es necesario detallar (Selleo, 2016):
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 por 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 de-
finir 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, a fin de no afectar los costos o el producto final.
Anlisis y definicin de requisitos funcionales y no funcionales: se establecen los re-

querimientos 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.
Realizacin del presupuesto: para identificar la inversin que se debe efectuar para el
desarrollo del software.
Definicin del plan de aseguramiento de la calidad: se encarga de planificar los proce-

sos, requerimientos, salidas y canales de retroalimentacin de la calidad del sistema duran-
te el ciclo de vida del proyecto. Para realizar 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 selec-
cionado 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 et al.,
2002) que se desea evaluar:
Funcionalidad: la capacidad de cumplir con los requerimientos o necesidades para las cua-
les 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 diferen-

tes ambientes operativos o plataformas sin necesidad de realizar cambios.
El procedimiento establece la seleccin de un mximo de tres categoras, de las cuales es obli-

gatorio seleccionar la evaluacin de la funcionalidad, debido a que evala el cumplimiento de
los requerimientos definidos. La recomendacin de seleccionar un mximo de tres categoras
se debe a que la eleccin de un nmero mayor puede desencadenar que la evaluacin de una
categora entre en conflicto con la evaluacin de otra categora. La seleccin de las otras dos ca-
tegoras 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 seleccio-
nan las mtricas cuantitativas que permitirn realizar la evaluacin y estimacin de la calidad del
producto.
Planificacin de la gestin de recursos humanos: es necesario planificar los roles necesarios

para la gestin del proyecto y el desarrollo exitoso del sistema (Erazo-Paruma et al., 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 la tabla 1.

Tabla 1. Roles de participantes en el proceso de tercerizacin de software
Puesto/Rol Descripcin de responsabilidad

Director (Dir) Es la persona con conocimiento de los procesos de la organiza-
cin y tiene la responsabilidad de administrar el proyecto.
Encargado de adquisicio- Es el encargado de realizar, coordinar y efectuar la contratacin
nes (EA) del proveedor, con base en los parmetros definidos, y es el con-
tacto directo entre el cliente y el proveedor, con el fin de centrali-
zar la comunicacin y el flujo de informacin.
Programador o ingeniero Es la persona o grupo de personas que colaboran en la defini-
de software (IS): cin de los alcances y requerimientos del sistema. Esta persona
puede ser el contacto tcnico para comunicaciones con el pro-
veedor cuando se est ejecutando el proyecto.
Encargado de contrata- Es la persona o grupo con conocimientos en aspectos legales
cin (EC): para el establecimiento y negociacin del contrato, con base en
las necesidades definidas por el director y los usuarios.
Ingeniero de calidad de Es la persona o grupo encargado de participar, verificar, asegu-
software (QA): rar, probar, controlar y comunicar la calidad del proceso y pro-
ducto 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 (I): Son las personas interesadas o afectadas por el desarrollo del
sistema y se debe procurar su compromiso de participacin en el
proceso para asegurar su satisfaccin con el producto final.
Elaboracin del 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 encargado, que 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 presupues-

to.
Procesode 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.
Mtodopara actualizar y refinar el plan de gestin de las comunicaciones a medida que el

proyecto avanza y se desarrolla.
Glosario de terminologa comn.
Diagramasdel 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.
Definicin del tipo de contrato por 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 duran-
te 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 dostipos 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 es-
fuerzo y genere un producto de calidad.
Establecimiento de los criterios de seleccin del proveedor: esta tarea realiza la identi-
ficacin de los criterios bsicos con lo cuales sern evaluados y seleccionados los provee-
dores. 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.
Identificacin de los proveedores potenciales: corresponde a la identificacin de los pro-

veedores que pueden desarrollar el sistema con base en la experiencia de expertos, la
experiencia de proyectos anteriores y el anlisis del mercado.
Establecimiento y documentacin de los criterios de aceptacin: Estos criterios corres-

ponden 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.
Realizacin del enunciado del trabajo: este documento contempla la informacin del al-
cance 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 reque-
rido. Este tipo de documento es necesario para solicitar propuestas a los posibles provee-
dores 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 evalua-
cin segn los criterios definidos, proceder con la seleccin del proveedor, preparar el contrato y
formalizar la relacin contractual (Erazo-Paruma et al., 2014), pasos que 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 provee-
dores y garantizar la mejor seleccin.
Preparacin y negociacin del contrato: esta tarea debe contemplar al menos la defini-
cin 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 provee-

dores (SLA2), 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, lo cual da lugar al inicio formal del
desarrollo del producto especificado.
3.4. Ejecucin
La fase de ejecucin contempla la etapa de desarrollo del sistema y requiere la participacin ac-
tiva del cliente y es necesario ejecutar el plan de control de la calidad. Este plan recibe como en-
trada los elementos del plan de aseguramiento de la calidad y se encarga de realizar la evaluacin
de criterios mediante revisiones, auditorias e inspecciones (vase la figura 2). Estas evaluaciones
se realizan en todo el ciclo del desarrollo del sistema para asegurar un producto de calidad (IEEE
Computer Society, 2014) y comprenden:
Revisionesde administracin: se encargan de monitorear el progreso del proyecto, y del

cronograma, y la efectividad de la gestin del proceso de desarrollo realizando compara-
ciones con lo planificado.
Revisionestcnicas: se encargan de realizar una evaluacin del producto con base en las
categoras de evaluacin definidas y verificacin de acuerdo con las mtricas establecidas.
Evaluacinde tcnicas estticas: son responsables de examinar la documentacin (requeri-

mientos, diseo y modelo, entre otros aspectos) y el cdigo fuente del software sin proce-
der con su ejecucin.
Evaluacinde 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 usua-
rios finales en el equipo de desarrollo, con el fin de alcanzar mayor entendimiento, compresin
y solucin de las necesidades (vase la 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 y de idioma, y acercar a
los participantes del cliente y el proveedor. Esta fase se encarga de gestionar los posibles pro-
blemas que se puedan presentar por cambios o diferencias de criterios durante el desarrollo del
proyecto. Las tareas que sustentan esta fase son las siguientes:
Efectuar el plan de gestin de comunicaciones: se recomienda llevar a cabo las activida-

des del plan de gestin de comunicaciones, gestionar las reuniones, comunicacin y parti-
cipacin activa de los interesados e involucrar a los usuarios en el proceso de desarrollo, as
como desarrollar las siguientes actividades de apoyo:

Figura 2. Diagrama de gestin de calidad
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.
Efectuar por lo menos dos reuniones formales a la semana, siempre y cuando las ubicacio-
nes 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 por la ubicacin de los equipos en diferen-
tes localidades, es necesario ajustar el nmero de reuniones fsicas para que sea requerido
realizar al menos una reunin 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 co-
rreos electrnicos, nmeros de telfono de los encargados, direcciones de contacto para
realizar videoconferencias e informacin de las reuniones presenciales.

Figura 3. Diagrama de administracin de la relacin con el proveedor
Esimportante que los mensajes que se intercambien sean concretos, coherentes, comple-
tos, 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 puedan observar cules son las labores que estn pen-
dientes, 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 presentacio-
nes) 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 puede comparar el cumplimiento de los requerimientos para
comprender y comunicar el avance, el desempeo y el cumplimiento del proyecto me-
diante el anlisis de curvas de eficiencia, 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 ac-
ciones correctivas que le permitan cumplir con todas las metas y entregables del proyecto.
Presentar los 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 comunicar, controlar y brindarles segui-
miento 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 pro-
yecto, as como los cambios que provocaron incidentes.
Evaluar 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 pro-
yecto.
3.6. Aceptacin y cierre

Esta 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 (Erazo-Paruma et al., 2014) son las siguientes:
1. Recibir la entrega parcial o final del sistema, realizar las pruebas al sistema, valorar los resul-
tados y tomar en cuenta los criterios de aceptacin para el cumplimiento satisfactorio del
producto.
2. Cuando en el proceso de pruebas se identifiquen no conformidades, realizar el reporte

para proceder con las correcciones necesarias, en caso contrario, proceder con la acepta-
cin del entregable.
3. Administrar los contratos y facturas canceladas o pendientes de pago para el proveedor.
4. Confirmar al final del proyecto que todos los entregables sean aceptados.

5. Al cerrar las adquisiciones, proceder con la conclusin del contrato, evaluacin general del
proveedor y el registro de experiencias aprendidas para utilizarlas en futuros proyectos.
3.7. Reconsideracin
La fase de reconsideracin corresponde a una evaluacin con base en la experiencia e informa-
cin suministrada durante el desarrollo del proyecto, y considera efectuar las siguientes activida-
des:
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 re-
torno 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 del servicio y el
cumplimiento de criterios y evolucin del proyecto, pero existe una percepcin de insa-
tisfaccin final, 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 esta 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 satis-
factoria, 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 consis-
te en reintegrar el proceso tercerizado a lo interno de la empresa, si se cuenta con las ca-
pacidades 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 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 metodo-
loga 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 secuen-

cial, debido a que contiene las fases de ejecucin, aceptacin y cierre y reconsideracin. Adicio-
nalmente, 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.

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

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 este trabajo contempl la
elaboracin de una metodologa para realizar la gestin adecuada de un proyecto de terceriza-
cin.
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 etapas de un proyecto de esta naturaleza. Por lo tanto 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 re-
levancia 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 brinda un panorama claro de la ruta y actividades que se pueden con-
siderar. Esto tiene por fin facilitar la comprensin del proceso, y 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 (2.a ed.).
CENDITEL, Fundacin. (2013). Aseguramiento de calidad en el desarrollo de software libre. Ve-
nezuela.
Erazo-Paruma, L. R., Guerrero-Mera, G. L. y Correa-Pino, F. J. (2014). Mtodo para la adquisicin
de software en pequeas organizaciones. Revista UIS Ingenieras, 13 (1).
Franceschini, F., Galetto, M., Pignatelli, A. y Varetto, M. (2003). Outsourcing: guidelines for a struc-
tured 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.
Recuperado de https://www.computer.org/web/swebok
McIvor, R. (2005). The influence of transaction cost economics and the resource based view on the

outsourcing process. En Sixteenth Annual Conference of POMS, Chicago.

Mendoza, L. E., Prez, M. A., Grimn, A. y Rojas, T. (octubre de 2002). Algoritmo para la evaluacin
de la calidad sistmica del software. En Proceedings of Second Ibero-American Symposium
on Software Engineering and Knowledge Engineering (JIISIC02), Salvador, Brasil, 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.
Perunovic, Z. & Pedersen, J. L. (mayo de 2007). Outsourcing process and theories. En Procee-
dings of the Eighteenth Annual Conference (POMS), vol. 3.
Project Management Institute, I. (2013). Gua de los fundamentos para la direccin de proyectos
(gua del PMBOK) (5.a ed.).
Selleo. (2016). A practical guide to outsourcing your software development. Recuperado 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

cin Tournn, 10235-1000
San Jos, Costa Rica [fchavess976,dmoras530]@ulacit.ed.cr

agonzalez@ulacit.ac.cr
Resumen La tercerizacin del desarrollo de software es una prctica comn entre muchas em-
presas. 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 co-
nocimiento, 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 pro-
veedores. Como consecuencia, el objetivo de este trabajo de investigacin es proponer un mo-
delo 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 imple-
mentar 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 su estructura de costos.
En los ltimos aos la tercerizacin ha crecido de forma considerable y se ha expandido de ma-

nera rpida para brindar servicios de toda ndole, incluyendo desarrollo de software, soporte
tcnico, reclutamiento de personal, finanzas y contabilidad, entre otros.
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
Gestin de la relacin con terceros y metodologas giles | 33

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 participa-
cin activa de los clientes y la creacin de falsas expectativas.
El objetivo de este trabajo de investigacin es preparar una gua de mejores prcticas, toman-
do 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 activi-
dad 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 exter-

nalizacin al extranjero, los cuales funcionan de forma diferente:
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 proce-

sos 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 qu beneficios les puede traer y qu impacto tiene.
Esta metodologa trae consigo diversos beneficios y puede mejorar el valor de la firma del
cliente de muchas maneras, como por ejemplo el acceso a la base de la competencia. Re-
cientes 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
34 | Gestin de la relacin con terceros y metodologas giles

si una relacin estrecha, donde el flujo de informacin es vasta y se comparte informacin

de los procesos centrales del negocio. De esta manera el vendedor con todo este conoci-
miento 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 ven-
dedor, limitando su libertad de accin, los costos generados por el vendedor pueden llegar
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 pro-

ducto o una parte del producto se soluciona a travs de la tercerizacin en otro pas y este
por consecuencia termina siendo ms barato. Esto causa que una vez que 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 ge-
neracin 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 los que 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; y pocas veces se re-
nen 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 transmi-

te de manera adecuada al cliente. Si bien es cierto que se entrega documentacin como
manuales tcnicos y de usuario, esto no es suficiente, porque durante el desarrollo del pro-
yecto, pudieron existir diversos escenarios que recibieron atencin especfica, adems de
complicaciones que se resolvieron con ideas innovadoras, y todo esto se traslapa 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 re-
sultados no cumplen completamente los requerimientos planteados.
Seguimiento y participacin activa del cliente: el cliente se rene con el proveedor, de-

finen 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 si-
guientes 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 clien-
te 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 metodolo-
gas 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 et al., 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, apro-
bacin 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 de-
bido 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 cuatro aspectos: comunicacin, simplici-

dad, retroalimentacin y coraje. Esta metodologa busca que todo se realice de manera sencilla,
para una mejor comprensin, manteniendo al cliente altamente informado de lo que sucede.
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, ocho 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 con base en el 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. Se basa en algunas buenas prcticas y buenos principios debido a su na-
turaleza. 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.
Tabla 1. Cuadro resumen de metodologas giles
Metodologa gil Puntos claves

Programacin extrema Lanzamientos pequeos y frecuentes.
Reuniones cortas todos los das.
Proyecto dividido en iteraciones.
Scrum 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.
3. Gestin de proyectos y metodologas giles

La figura 1 muestra la propuesta de un proceso para la tercerizacin del 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 Design Sprint, el cual tiene como objetivo reunir las partes claves en
el proyecto, tanto del lado del cliente como del proveedor, para crear un prototipo y definir
los requerimientos iniciales del proyecto, eliminando los problemas de comunicacin en
esta fase.
Iteraciones: en esta fase se inicia un ciclo que incluye diferentes procesos hasta que el
producto est terminado y sea aprobado por el cliente. Las etapas que comprende

son las siguientes:
Ciclos de desarrollo: estos ciclos estn a cargo de los desarrolladores de software, y com-
prenden la parte de carpintera del proyecto en la cual se escribe el cdigo.
Revisin del dueo del producto: el dueo del producto es quien est a cargo de los re-
sultados 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 reu-

nin rpida con los involucrados para hablar sobre los avances en el proyecto, qu se debe
mejorar y cules son las tareas que se deben realizar, as como los 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 est listo para su lanza-
miento o se debe continuar con otra iteracin.
Ajustes: es la ultima fase de la iteracin y en esta se determinan los ajustesque se deben

realizar en el proyecto para continuar con la siguiente iteracin.
Lanzamiento: se realiza la entrega del producto final al cliente.
Figura 1. Gestin de proyectos de tercerizacin con metodologas giles
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 le proporcione al cliente una herramienta para ayudarle a ase-
gurar 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 reunio-

nes 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 de 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 si-
guientes:
Grabacin tanto de vdeo como de 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 probar prototipos.
Se recomienda realizar las reuniones personales en un lugar en que los participantes pue-
dan tener acceso a las herramientas necesarias para desarrollar la sesin (computadoras,
Internet, papel, lpices, pizarras, marcadores). Esto proporcionar un ambiente donde se
puedan clarificar o remarcar aspectos que no estn completamente definidos, incluso el
proveedor puede sacar ventaja de estas reuniones para mostrar ideas o diseos que pue-
dan 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 suce-
so 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 esto es aceptado por el cliente.
4.2. Trasferencia de conocimiento

Otro de los problemas ms comunes cuando se contrata a un tercero para el desarrollo de sof-
tware, 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 informa-
cin 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. Adems proporciona 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 informa-

cin relevante que se genere durante el desarrollo y que pueda ser til en el futuro para
realizar modificaciones, implementaciones y solucionar problemas del sistema.
La generacin de conocimiento puede derivarse de diversas formas y deben documentarse por

medio de una herramienta de este tipo:
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 que no funcionan de la misma

forma, por lo que los procedimientos para el manejo de la programacin o mantenimiento
de un mdulo deben documentarse.
Versiones del software: cada versin del sistema evoluciona de acuerdo con el avance
1 Conocida en ingls como Knowledge Base (KB).

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 que deben
ser documentados, y que deben establecerse de manera conjunta para que sea realizado
de manera correcta. Entre las opciones disponibles se encuentran las siguientes:
Soluciones en el mercado:
Novo Solutions
KBPublisher
XWiki
CMDB2: es una herramienta que tiene como objetivo el manejo eficiente de los servicios y
activos, que estn conformadas por elementos de configuracin2.
Soluciones en el mercado:
Cherwell
Servicenow
CMDBuild
DSL (Biblioteca definitiva de software): se refiere a un repositorio central de software para

gestionar 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 origen 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).
Reuniones de diseo
Es importante establecer desde un inicio, de forma clara y eficiente, lo que se espera del pro-
veedor, por lo que se deben realizar reuniones de diseo, en las cuales se puede usar como
referencia el marco de trabajo denominado Design 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.
2 Los elementos de configuracin son conocidos en ingls como configuration items.

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 seis etapas:
Entender: se realiza un proceso para entender qu es lo que el usuario necesita, e involucra

a los usuarios expertos para que expliquen en qu consiste el negocio o proceso que se
pretende mejorar, adems de una investigacin sobre el mercado actual y las capacidades
tecnolgicas.
Definir: se determinan las caractersticas que el sistema debe tener y se les pide a los usua-
rios que definan con tres frases cmo les gustara que fuese el sistema; adems, en esta
etapa se crean historias sobre la interaccin de un usuario con el sistema.
Divergir: se les pide a los usuarios que dibujen ocho ideas en cinco minutos sobre el siste-
ma, 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 ex-

pertos.
Validar: el prototipo es probado por los usuarios, a quienes se les hace una serie de pre-
guntas sobre lo que 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 ser documentados. Adems, se recomienda que el equipo
de trabajo est formado por diseadores, ingenieros, gerentes de proyecto, expertos y el maes-
tro de sprint 3 .
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 pro-
veedor de forma constante, dando seguimiento a los avances, problemas y resultados.
Pruebas con usuarios expertos
En las diferentes reuniones se pueden realizar pruebas que le permitan al cliente observar el esta-
do del 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 presen-
ciales, 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 efec-
3 El maestro de sprint es la persona encargada de disear los retos para cada etapa del sprint.

tiva, se recomienda que el proveedor cree y facilite documentos de control como:
Lista de control6: este documento consiste en una lista de puntos que el usuario debe
evaluar, marcando o dejando 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 ms directa dependiendo del documento, acer-
ca del avance, lo cual servir como retroalimentacin para el proveedor.
En estas pruebas el proveedor es un gua y no debe influir en el usuario sobre cmo utilizar el
sistema. El proveedor no debe indicar acciones que conduzcan al usuario por una ruta determi-
nada, 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 de-
sarrollo 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 preocu-
pacin mostrada por los autores de los trabajos estudiados.
El anlisis de la bibliografa ayud a 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 no son efi-
cientes. Por lo tanto, la gua propuesta tiene como fin combinar las principales fortalezas en cuan-
to a la gestin de la relacin con terceros de las metodologas que fueron analizadas.
La gua tom en cuenta las caractersticas particulares de cada una de las metodologas, y fue ela-
borada con base en la evidencia del xito que han tenido en la prctica. La estructura de la gua
es flexible ante las necesidades que pueda tener el cliente, 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 otra parte, 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 dicho instrumento 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. Recuperado de http://www.agile-
manifesto.org/iso/es/
Bersin, J. (2005). Business process outsourcing: Pros and cons. Chief Learning Officer, 4 (4),
34 - 40. Recuperado de http://search.ebscohost.com/login.aspx?direct=true&db=bu-
h&AN=16479531&lang=es&site=ehost-live
Dolgui, A. & Proth, J.-M. (2013). Outsourcing: definitions and analysis. International Journal of
Production Research, 51 (23/24), 6769 - 6777.
Girotra, K. & Netessine, S. (2012, oct). Why Apple has to manufacture in China. Recuperado de
https://hbr.org/2012/10/why-apple-has-to-manufacture-i
Kakumanu, P. & Portanova, A. (2006). Outsourcing: Its benefits, drawbacks and other related is-
sues. 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 methodo-
logy for outsourcing service providers? RISTI-Revista Ibrica de Sistemas e Tecnologias de
Informao(SPE1), 6175.
Smuts, H., van der Merwe, A., Kotz, P. & Loock, M. (2010). Critical success factors for information
systems outsourcing management: A software development lifecycle view. En Proceedings
of the 2010 annual research conference of the south african institute of computer scientists
and information technologists (304313). New York, NY, USA: ACM. Recuperado 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 Quirs, Reagan Ching Fung, Julio Crdoba Retana y Antonio Gon-
zlez Torres

[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 utili-
dades 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 en-
tran 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 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.
Definicin y modelado del proceso de gestin de la demanda para tecnologa de informacin | 45

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 me-
diante la definicin de un modelo de gestin de la demanda. De acuerdo con lo anterior, se rea-
liza 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.
Tabla 1. Procesos de marcos de referencia analizados
COBIT 5 ITIL v3
EDM04 - Asegurar la optimizacin de recursos Gestin de la demanda
BAI04 -Gestionar la disponibilidad y capacidad Gestin de la capacidad
En sntesis, este trabajo de investigacin busca identificar un proceso bsico, que sirva como pun-
to 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. Marco terico
2.1. Gestin de la demanda
La gestin de la demanda es un proceso presente en todas las organizaciones, aunque no se en-
cuentre identificado como tal o est 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 son 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 tengan 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 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.
46 | Definicin y modelado del proceso de gestin de la demanda para tecnologa de informacin

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 et al.,
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, y 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 soli-
citudes 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 prin-
cipal 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
como de 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 enfo-
que tctico que est dirigido, principalmente, a los administradores, gerentes, auditores y encar-
gados o responsables del rea de TI (Muoz-Serna y Martnez-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 cinco dominios y treinta y siete procesos que buscan brindar
una serie de normas para el uso eficiente de los recursos. En este punto es importante anotar
que la 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 de 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 (Ministerio de Tecnologas de la
Informacin y las Comunicaciones, s.f.). Adems, tiene como propsito asegurar que las necesi-
dades de recursos de la empresa sean cubiertas de forma adecuada, que el coste de TI sea apro-
piado 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 Ges-

tin y pertenece al dominio Construir, adquirir e implementar.
Este proceso se encarga de equilibrar las necesidades actuales y futuras de disponibilidad, ren-
dimiento y capacidad, con una provisin de servicio efectivo en costos. Adems, incluye la eva-
luacin 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 adi-
cional, 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 rendimien-
to 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 presta-
cin y calidad de los servicios (Ministerio de Tecnologas de la Informacin y las Comunicaciones,
s.f.). La versin 3 de ITIL divide el ciclo de vida de los servicios en cinco fases:
1. Estrategia
2. Diseo
3. Transicin
4. Operacin
5. Mejora
En este trabajo se profundiza en la fase de Estrategia, especficamente en elproceso de la Ges-

tin 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, a fin de extraer los
patrones de las actividades del negocio y prevenir cules servicios son o van a ser demandados y
planificar el alcance de los servicios necesarios y su prioridad (Quevedo, 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 disponibles cuando los usuarios as lo
requieran. Para ello, es indispensable que este proceso se encuentre alineado con el negocio,
con el fin de evitar la 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, reducir los gastos innecesarios por man-
tenimiento 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 y los marcos de referencia, con el fin de identificar similitudes y diferen-
cias para realizar el modelado.
4. Resultados y aportes
El principal aporte de este trabajo es un proceso hbrido que tiene en cuentalas 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 (vase la Figura 1).
4.1. Descripcin del proceso

Recopilacin de informacin: El proceso propuesto inicia con la recopilacin de informacin3,
cuyo encargado de su ejecucin es el departamento de TI.
Suministro de planes de negocio y requerimientos: Esta actividad tiene por objetivo com-
prender e identificar las actividades del negocio y la forma como estas 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 conoci-
das como PBAs5. Adems de identificar los PBA, esta actividad define los perfiles de los usuarios
o UP 6, basndose en sus roles y responsabilidades en la organizacin.
Definicin y modelado del proceso de gestin de la demanda para TI
Anlisis de la definicin y capacidad del servicio a nivel de recursos:
Esta actividad fue definida tomando como referencia COBIT 5 y los siguientes procesos:
BAI04.02: Evaluar el impacto en el negocio de COBIT 5. Este proceso busca identificar los
servicios importantes para la empresa, relacionar los servicios y recursos con los procesos
de negocio e identificar las dependencias del negocio.
BAI04.03: Planificar requisitos de servicios nuevos o modificados. En el caso de este proce-

sado est asociado con la planificacin y priorizacin de la disponibilidad, el rendimiento y
1 EDM04 Asegurar la optimizacin de recursos y BAI04 Gestionar la disponibilidad y capacidad.

2 Gestin de la demanda y Gestin de la capacidad
3 La recopilacin de informacin es propuesta con base en el proceso Gestin de demanda de ITIL v3.
4 El diseo de esta actividad se bas en ITIL v3, especficamente en el proceso Gestin de demanda.
5 Patterns of Business Activity, por su acepcin en ingls.
6 User Profile, en ingls.

la capacidad para realizar cambios conforme con las necesidades del negocio y los reque-
rimientos de servicio.
EDM04.02: Orientar la gestin de los recursos. Este proceso est relacionado con la adop-
cin 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.
Evaluacin de la disponibilidad de recursos: Esta actividad se basa en el proceso BAI04.05

Investigar y abordar cuestiones de disponibilidad, rendimiento y capacidad de COBIT 5, el cual
permite abordar desviaciones de los servicios investigando y resolviendo los problemas identifi-
cados en relacin con la disponibilidad, rendimiento y capacidad.
Aprobacin de mejoras y puesta en marca: Si la capacidad del servicio, con base en la dispo-
nibilidad de recursos, puede satisfacer la demanda, el flujo continua con la actividad del proceso
Aprobar mejoras y puesta en marcha.
Solicitud de recursos: En caso de que la capacidad y los recursos no puedan satisfacer la de-
manda, se procede a gestionar y solicitar los recursos. Dicha solicitud se realiza al negocio, debi-
do a que involucra al rea financiera de la organizacin y el desempeo del negocio.
Anlisis de 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.
Evaluacin peridica de capacidad y disponibilidad del servicio: Esta actividad invoca a un

subproceso para dar seguimiento a los servicios y sus recursos, y se basa en tres procesos de
COBIT 5:
BAI04.01: Evaluar la disponibilidad, rendimiento y capacidad actual y crear una lnea de

referencia. Este proceso tiene como objetivo asegurar la disponibilidad, capacidad y rendi-
miento de los servicios mediante su evaluacin.
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 esta-
blecidas y revisar informes de anlisis de tendencias identificando cualquier problema o va-
riacin significativa para iniciar las acciones necesarias con el fin de asegurar que se realiza
el seguimiento de todos los problemas pendientes.

Figura 1. Proceso de modelado de la gestin de la demanda

EDM04.03: Supervisar la gestin de recursos. Este proceso indica que se deben supervisar
los objetivos y mtricas claves 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 proble-
mas.
La evaluacin peridica de capacidad y disponibilidad del servicio tambin se bas en el

proceso Gestin de la capacidad de ITIL v3, el cual tiene relacin con el seguimiento y revi-
sin 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 apo-
yan 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 iden-
tificacin 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 requiere que la capacidad para satisfacer la demanda se ajuste
a las necesidades actuales.
Como trabajo futuro se recomienda evaluar el marco de referencia CMMi para servicio, debido
a que este se enfoca en la administracin y entrega de los servicios ofertados, lo cual es un pro-
ducto del proceso de gestin de la demanda.
Para optimizar el proceso planteado en este trabajo, se requiere incorporar un estudio de conti-
nuidad, 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, dic). The importance of it strategic demand ma-
nagement in achieving the objectives of the strategic business planning. En International
Conference on Computer Science and Software Engineering, vol. 2, 235-238.
ISACA. (2012). COBIT 5: Procesos Catalizadores. Recuperado de www.isaca.org
ITIL vs COBIT. (s. f.). Recuperado de http://www.cntec.mx/noticias/41/122-itilvscobit.html
Ministerio de Tecnologas de la Informacin y las Comunicaciones. (s. f.). Marco de referencia:
arquitectura TI de Colombia.
Muoz-Serna, R., y Martnez-Arias, M. A. (2012). Caracterizacin de procesos de gestin de TI
basados en COBIT 5 y mapeo con ISO27002, ITIL.
CMMI DEV. (s. f.). PMBOK, para la implementacin en la industria editorial colombiana, apoyando
el proceso de transformacin digital.
OSIATIS. (2015). ITIL Foundation. Recuperado de http://itilv3.osiatis.es/
Quevedo, A. M. (2009). Implementacin de una metodologa de procesos para la mejora de TI
en una empresa. Universitat Politcnica de Catalunya. Recuperado de http://upcommons.
upc.edu/handle/2099.1/7599

Recomendaciones para la gestin de

incidencias de tecnologas de la informacin
Verny Mora Jimnez, Paulo Viales Wahrmann, Julio Crdoba Retana y Antonio Gonzlez
Torres

cin Tournn, 10235-1000, 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 re-
lacin que se establece entre los usuarios y el departamento de TI. De acuerdo con esto, este tra-
bajo 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 desem-
peo de las organizaciones, por lo que requieren el correcto funcionamiento de los sistemas de
hardware y software que utilizan. Esto conlleva a que las incidencias1 que se presenten deban ser
resueltas de forma oportuna, tanto a usuarios internos como externos, por lo que es necesario
que las incidencias se gestionen de forma adecuada, para evitar que se transformen en riesgos
para la continuidad de la organizacin.
En este punto resulta indispensable tener en cuenta que los servicios de TI deben ofrecer ser-
vicios 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 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 empresa-
rial. 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
1 Se denomina como incidencia a un problema que sobreviene en la prestacin de un servicio que es soportado por
hardware o software.
54 | Recomendaciones para la gestin de incidencias de tecnologas de la informacin

de incidencias (Bauset-Carbonell y Rodenes-Adam, 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 organi-
zacin (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 desconoci-
miento y en otros por que no le brindan la importancia necesaria. Tomando en cuenta lo anterior,
en este trabajo se estudian y analizan los lineamientos y mejores prcticas que son recomenda-
das 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 de 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 (ITIL Foundation,
2011). Las incidencias pueden ser detectadas por el personal tcnico, reportadas por herramien-
tas 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, con el fin de
no afectar los procesos de la organizacin y cumplir con los compromisos con terceros (Forrester,
Buteau y Shrum, 2011). En trminos generales, este proceso contempla registrar las peticiones de
servicio, diagnosticar el problema de forma precisa (i.e., identificar y describir 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 resolu-
cin de la incidencia, cerrar las incidencias y mantener un registro histrico (vase los procesos
DSS02 y DSS03 de COBIT 5) (ISACA, 2012; OToole, 2015).
El registro de las peticiones de servicio requiere verificar que estas cumplan con los criterios
2 Conocidos como partners, por su acepcin en ingls.
Recomendaciones para la gestin de incidencias de tecnologas de la informacin | 55

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 y 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 priori-
dad, obtener la aprobacin financiera y si se requiere, el cambio de procedimientos o estndares.
Como parte de este proceso, se requiere utilizar la base de datos de conocimiento, si existe, para
determinar si el problema est asociado a un error conocido, o si este ha sido resuelto anterior-
mente. Este paso se debe efectuar antes de asignar a un especialista para realizar un anlisis de
mayor profundidad o que se lleven a cabo acciones para restaurar los servicios afectados, con
ayuda de otros especialistas.
En los casos en los que la incidencia es reportada por telfono, se recomienda efectuar un diag-
nstico inicial e intentar ofrecer una solucin de forma inmediata, trabajando junto con el usua-
rio, 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 cuenta la posibilidad de se-

guir 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 responsa-
ble de mayor autoridad para tomar decisiones por encima del nivel del personal tcnico involu-
crado, como la asignacin de recursos adicionales para la resolucin de la incidencia).
En todo caso, es recomendable resolver cada incidencia en el menor tiempo posible, para restau-
rar o normalizar el servicio y salvaguardar los intereses de la organizacin. 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 esta. El proceso de seguimiento involucra documentar y revisar las ac-
ciones realizadas, escalar las incidencias segn se requiera y comunicar el estado de la incidencia
a las partes interesadas.
En el transcurso de la resolucin de una incidencia puede ser necesario efectuar procedimien-

tos 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 pro-
veedores externos.
Una vez que la incidencia ha sido resuelta, se deben hacer las comprobaciones necesa-
rias con el usuario para cerrar el caso, medir la satisfaccin, tener en cuenta los requerimien-
tos de informes de las partes interesadas en la gestin de incidencias y utilizar criterios de

calidad del servicio (Forrester et al., 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 esta-
blecer tendencias, encontrar patrones de asuntos recurrentes e infracciones a los procedimien-
tos, 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 de-
terminen 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 estas no representan la interrupcin de
un servicio (ITIL Foundation, 2011).
Categoras: La definicin de categoras es otro elemento fundamental en la gestin de inci-

dencias, 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 (ITIL Foundation, 2011; Forrester et al.,
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 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 (IT Governance Institute, 2013) como CMMI (Forrester et
al., 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 y se-
guimiento 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 usua-
rios (Forrester et al., 2011), la actualizacin de los estados (e.g., abierta, en progreso, resuelta y
cerrada) (ITIL Foundation, 2011) y seguimiento de las acciones realizadas durante el ciclo de vida
de las incidencias.
Reapertura de incidencias: En algunos casos es posible que una incidencia no haya sido resuelta
por completo y sea necesario reabrirla, por lo que se requiere definir las reglas para reabrir inci-
dencias, 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 coinci-
den en cuanto a las principales tareas que requiere el proceso de gestin de incidencias, siendo
esas tareas las siguientes:
1. Registro de incidencias.
2. Resolucin de incidencias.
3. Cierre de incidencias.
4. Seguimiento y anlisis de incidencias.
En consecuencia, este trabajo ha tomado en cuenta la lista de tareas enunciadas y las mejores
prcticas de COBIT (IT Governance Institute, 2013), ITIL (ITIL Foundation, 2011) y CMMI (Forrester
et al., 2011), para proponer el proceso que se muestra en la figura 1. Las tareas ordinarias de dicho
proceso son representadas por cajas rectangulares y las decisiones por rombos, en tanto que las
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 recursos extraordinarios, y en caso necesa-
rio 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 hace 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 nece-
sario 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 servi-
cio 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 a con-
tinuacin.
Identificacin de incidencias: En un escenario ideal, se brinda seguimiento constante a los re-

cursos 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 1, la identificacin de las incidencias, por lo general, es realizada tanto por los
usuarios de la organizacin como por el departamento de TI.
Recomendaciones para la gestin de incidencias de TI
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 usua-
rios 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 si-
guientes:
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 du-
rante este proceso, con asistencia de una base de datos de conocimiento, el problema sea solu-
cionado 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 procedi-
mientos 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 re-

gistro 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 re-
solucin 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 pro-
cedimientos extraordinarios para la resolucin de una incidencia, se debe contar con la aproba-
cin 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, la mesa de servicio debe
contar con el personal capacitado 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 cuan-

do 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 (ITIL
Foundation, 2011), como se muestran en la Figura 1 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 inci-
dencia 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 infor-
mados a los usuarios y efectuar el cierre de estas, sin importar el grupo al que hayan sido referi-
das para su resolucin.
Escalado jerrquico: Este tipo de escalado se realiza cuando es necesario que los mandos su-
periores 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 efecta el cierre y
documentacin, 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 concluye el ciclo de ges-

tin de incidencias, para una 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 inciden-

cias 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.

Figura 1. Proceso para la gestin de incidencias de tecnologas de la informacin

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 (Forrester et al., 2011; ITIL Foundation, 2011) y contar con las herramien-
tas 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 recu-
rrentes, su naturaleza y causa. 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 ni-
vel 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 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 pro-
puesta 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 organi-

zacin 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 ne-
cesario 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 efi-

cientes y enfocados en los objetivos de la empresa (Herold, 2007). No obstante, las justificaciones
basadas en la literatura (e.g., modelos de referencia, y casos de estudio) suelen ser insuficientes,
porque es necesario justificar con evidencia sustancial la razn costo/beneficio, ante la adminis-
tracin. 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 recomenda-
ciones (e.g., implementar sistemas de software para la gestin de incidencias) que no se adaptan
a organizaciones con niveles de madurez bajo.
Referencias
Bauset-Carbonell, M. C., y Rodenes-Adam, M. (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).
Forrester, E., Buteau, B. & Shrum, S. (2011). CMMI for services: Guidelines for superior service.
Pearson Education.
Herold, R. (2007). The shortcut guide to improving it service support through ITIL. Realtimepubli-
shers.com.
ISACA. (2012). COBIT 5: Procesos Catalizadores. Recuperado de www.isaca.org
IT Governance Institute. (2013). Cobit 5. Rolling Meadows.
ITIL Foundation. (2011). ITIL v3. Recuperado de http://itilv3.osiatis.es/
Kenett, R. y Baker, E. (2010). Process improvement and cmmi for systems and software. CRC
Press.
Mutafelija, B. & Stromberg, H. (2008). Process improvement with cmmi v1.2 and iso standards.
CRC Press.
OToole, D. (2015). Incident management for IT departments. Demand Publishing, LLC-Create
Space.
Persse, J. (2013). The IT service management process manual. van Haren Publishing.
Quesnel, J. (2012). Entender ITIL 2011: Normas y mejores prcticas para avanzar hacia ISO 20000.
d. ENI.

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 Gonz-
lez Torres

[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 impor-
tancia con una gran cantidad de dispositivos y aplicaciones para ofrecer servicios y solucio-
nes 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.
Ante este escenario, 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 exce-
lentes capacidades de comunicacin, bajo costo y consumo energtico, y sus capacidades redu-
cidas 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, la
seguridad, la salud, el seguimiento de los signos vitales de las personas, la inteligencia ambien-
tal, 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.
1 El trmino 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 en internet de las cosas | 65
Conforme el concepto de internet de las cosas (Ashton, 2009) ha tomado fuerza en aos recien-
tes, 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 proble-

mas 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 esto 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 interco-
nexin, 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 (Zig-
Bee 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 pro-
tocolos en un mismo sistema IoT sigue siendo una prioridad, porque la interoperabilidad entre
estos (Manyika et al., 2016) puede contribuir a generar ingresos adicionales a la industria por un
40 %.
Este trabajo propone un diseo para que los protocolos ms utilizados en IoT puedan comunicar-
se 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 funda-
mentos de las puertas de enlace. Con base en la informacin presentada en la seccin 2, la sec-
cin 3 presenta el diseo de 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 con-
clusiones del trabajo.
2. Antecedentes
La arquitectura de alto nivel de un sistema de IoT es similar a la arquitectura genrica de cual-
quier otro sistema; se compone de elementos de entrada, procesamiento y salida. La dife-
rencia bsica es que la entrada de datos se puede realizar por medio de sensores y la salida
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.
3 Las puertas de enlace permiten la comunicacin entre dispositivos en diferentes segmentos de una red, en los cua-
les utilizan protocolos diversos.
66 | Diseo de una arquitectura para la comunicacin entre protocolos en internet de las cosas
se puede efectuar con actuadores.
As, los datos que se adquieren del entorno por medio de sensores se transmiten a los dispo-
sitivos 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 protocolos de comunicacin para el in-

tercambio 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 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.
De forma que la interfaz del usuario suele estar vinculada al dispositivo controlador, y es utilizada
para configurar y gestionar el sistema (vase la figura 1).
Figura 1: Elementos de la arquitectura de un sistema IoT
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 inter-
faz 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 informa-

cin 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 preestablecidas, enva rdenes a los
actuadores.
Procesamiento y anlisis de los datos obtenidos (procesamiento): Lo conforman los al-

goritmos 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 con-
diciones. Sin embargo, 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 simple-
mente 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 almacena-
miento 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 topolo-
ga 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.
En cualquiera de las topologas sealadas, los dispositivos receptores y transmisores conforman

segmentos de comunicacin (vase la 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 y es comn que se requiera utilizar dispositi-
vos 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 (Jara-Maldonado, 2015), Z-Wave (Buxeres-Soler, 2014) y SigFox(Crdenes-Tacoronte, 2016)
(vase la tabla 1).
Tabla 1. Comparacin de los protocolos ms utilizados por IoT
Protocolo Uso Frecuencia Cobertura Otras caractersticas
X1O Red elctrica 120 KHz N/A Utiliza la red elctrica

domstica domstica como
medio de transmisin.
NFC Aplicaciones 13,56 MHz 10 cm Diseado para

con poco aplicaciones de
volumen de autenticacin.
datos
KNX Domtica N/A N/A Paralelo a la red

elctrica.
ZigBee Datos 868 GHz 915 10 a 75 m Diseado para bajo

inalmbricos GHz 2,4 GHz consumo de energa.
Z-Wave Datos Menos de 1 30 a 200 Tranmisin de baja

inalmbricos GHz (vara m potencia.
segn el pas)
Bluetooth Datos 2,4 GHz 10 m Utiliza enlaces de

inalmbricos frecuencia libre.
RFID Datos 9-135 KHz 2 a 100 m Tecnologa con mayor

inalmbricos rango de aplicaciones
13,56 MHz por las frecuencias en
las que opera.
433 MHz y
860-960MHz
2,45-5GHz
SIGFOX Smart Cities 868 o 902 MHz 3 a 5 Km Se considera la mejor

opcin para Smart
Cities por la distancia
que logra abarcar.
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 co-
municacin 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 funcio-
nalidad 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 comunicacio-
nes 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 hard-
ware. Dell Edge Gateway permite varias conexiones cableadas e inalmbricas (Dell, 2016b, 2016a)
para interconectar protocolos como ZigBee, BACnet y ModBus, entre otros. Mientras que Intel
IoT Gateway es una familia de productos (Intel, 2016) que permiten comunicar dispositivos por
medio de ZigBee, Bluetooth, USB, VPN y Wi-Fi. Por su parte, Texas Instruments (Texas Instru-
ments 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 en evidencia la nece-
sidad 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 com-
pone de un dispositivo de control, mdulos de comunicacin y bibliotecas para el intercambio de
informacin entre el dispositivo de control y los mdulos (vase la figura 2).
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 pro-
piedad 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 so-
porta 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 rela-
tivamente bajo.
Diseo de una arquitectura para la comunicacin entre protocolos
Figura 2: Arquitectura con dos mdulos de comunicaciones
Esto 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 sopor-
ta 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.
Cada da por la maana, se deben abrir las puertas, encender las luces de cada sitio de manera
individual y revisar los vdeos 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 jus-
tificar las razones de una jornada especial y, como consecuencia, se activa un protocolo de
seguridad especial.
La revisin de los vdeos puede tomar varias horas y 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 noti-

ficaciones 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:
Elpersonal 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 co-
rrespondiente, 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:
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 fun-
cionamiento 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 y 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 mi-
nicomputadora 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 co-
municacin 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 se mantiene activado
en modo de lectura al dispositivo de control (Raspberry Pi), para que capte las seales trans-
mitidas por las etiquetas RFID.
4. Conclusiones
En este trabajo de investigacin se llev a cabo una revisin bibliogrfica sobre los principales
protocolos y arquitecturas que se utilizan en IoT. Dicha revisin permiti analizar y discutir el es-
tado 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 comunica-
cin. Esto 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 interco-
nexin, 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 especiali-
zado y sin necesidad de incurrir en altos costos.
El subsistema de anlisis de informacin que incorpora la propuesta contempla el uso de servido-

res 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 escalabilidad a la propuesta.
Referencias
Ashton, K. (2009, June). That Internet of Things thing. Recuperado 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 oro-
grafa compleja.
Chavarra, D. A. (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. Recuperado de http://www.dell.com/us/business/p/ed-
ge-gateway?s=bsd
Dell. (2016b). Edge Gateway 5000. Recuperado de http://www.dell.com/us/business/p/dell-ed-
ge-gateway-5000/pd?ref=PD_OC
Eurotech. (2016a). IoT Gateways: multi service IoT gateways. Recuperado de https://www.euro-
tech.com/en/products/devices/iot+gateways
Eurotech. (2016b). ReliaGATE 10-11: compact Multi-Service IoT gateway, industrial-grade, TI
AM3352. Recuperado de https://www.eurotech.com/en/products/ReliaGATE%2010-11
Intel. (2015). Intel IoT Platform Reference Architecture. Recuperado de http://www.intel.com.au/
content/dam/www/public/us/en/documents/white-papers/iot-platform-reference-architec-
ture-paper.pdf
Intel. (2016). Intel IoT gateway technology. Recuperado de https://www-ssl.intel.com/content/
www/us/en/embedded/solutions/iot-gateway/overview.html
Jara-Maldonado, P. A. (2015). Estudio y diseo de un sistema inmtico para seguridad, comuni-
cacin y confort, utilizando el protocolo KNX para el edificio Torre Piamonte ubicado en el
sector de Totoracocha de la ciudad de Cuenca.
Manyika, J., Chui, M., Bisson, P., Woetzel, J., Dobbs, R., Bughin, J. y Aharon, D. (2016). Unloc-
king the potential of the Internet of Things. Recuperado de http://www.mckinsey.com/bu-
siness-functions/business-technology/our-insights/the-internet-of-things-the-value-of-digi-
tizing-the-physical-world
Pacelle, M. (2014, April). 3 topologies driving IoT networking standards. Recuperado 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. Recuperado de http://www.
evansdata.com/press/viewRelease.php?pressID=237
Raspberry Pi Foundation. (2016). Raspberry Pi Foundation. Recuperado de https://www.raspbe-
rrypi.org/
RaZberry. (2016). RaZberry Project. Recuperado de https://razberry.z-wave.me/
Texas Instruments Incorporated. (2016). HVAC Gateway. Recuperado de http://www.ti.com/solu-
tion/iot_gateway
The Z-Wave Alliance. (2016). The Internet of Things is powered by Z-Wave. Recuperado de ht-
tp://z-wavealliance.org/
ZigBee Alliance. (2016, July). The ZigBee Alliance creates IoT standards that help control your
world. Recuperado 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 Antonio Gonzlez Torres

[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 lo que 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 biol-
gicos mediante el uso de mapas con informacin georeferenciada, almacenada en imgenes
rster, para lo cual se desarroll una prueba de concepto para el procesamiento de la informa-
cin 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 he-
rramienta 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 las diferencia entre s a las especies de flora y fauna. En
este contexto, el uso de elementos taxonmicos y claves de identificacin reviste especial im-
portancia, porque permite clasificar las muestras por medio de 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 carcterhace referencia a las caractersticas generales
de las especies, mientras que estados de carcterse refiere a las caractersticas especficas.
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
76 | Etiquetas de Geolocalizacin en imgenes rster

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 la utilizacin de informacin de
georeferencias, en conjunto con el uso de rboles de decisin, puede contribuir con el 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 encuen-
tra almacenada en mapas codificados como imgenes rster2. Cabe mencionar que los cientficos
pueden crear reas trianguladas, las cuales podran estar superpuestas, a partir de las localiza-
ciones donde han encontrado muestras de determinadas especies y que es posible almacenarlas
en 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 sec-
cin 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 im-
genes 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.
Entre los tipos de archivos ms comunes para el almacenamiento de imgenes rster se encuen-
tran los siguientes:
BMP (bitmap).
TIFF(Tag Image File Format).
GIF(Graphics Interchange Format).
JPEG (Joint Photographics Experts Group).
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).
2 Rster se refiere al trmino ingls raster, que hace referencia a imgenes que almacenan metadatos relacionados con
la representacin grfica que realizan.
3 Los colores rojo, verde y azul son conocidos por sus siglas en ingls como RGB.
Etiquetas de Geolocalizacin en imgenes rster | 77

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 gigabytes, 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 co-
rrecta para no perder informacin. En el caso de la biblioteca de GeoTIFF, esta utiliza el formato
de compresin BitPack.
El almacenamiento de informacin se realiza utilizando bytes en lugar de bits, lo cual permite te-
ner 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 particular 5.
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 GeoKeys contienen etiquetas TIFF reservadas que tienen informacin pblica o privada so-
bre 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 el European Petroleum Survey Group (EPSG/POSC). Estos parmetros
se utilizan para identificar posiciones geogrficas en un sistema de coordenadas e implica la uti-
lizacin 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 de-
finido 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.
4 Entre las herramientas comerciales mejor conocidas para la manipulacin de imgenes rster se encuentran Auto-
Cad, Adobe Ilustrator y Photoshop.
5 A esta forma de guardar datos dentro de un TIFF se le conoce como Big and Little Endian.

3. Resultados
La implementacin de la herramienta se llev a cabo utilizando GeoTIFF (Schindler, 2015), una bi-
blioteca en JavaScript para leer los metadatos contenidos en las imgenes rster (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 herra-
mienta, lo cual produce un efecto de cambio de color de la imagen, debido 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)
En el contexto de la identificacin de especmenes biolgicos, se requiere leer las latitudes y lon-

gitudes 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 se
utilizan mapas en formato plano.
El procesamiento de las imgenes se lleva a cabo usando una funcin denominada 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 en los metadatos de geo-
localizacin.
Una vez que la imagen ha sido cargada y procesada, es posible observar la informacin que tiene
codificada (vanse las figuras 2 y 3).

Figura 2. Imagen luego de ser mapeada
Los pasos del algoritmo que se siguen una vez que la imagen es cargada, son los siguientes:
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 eti-
queta y los valores de etiqueta que estn definidas en 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.
Figura 3. Imagen procesada por las libreras, los colores se encuentran definidos por las etiquetas y, podran ser utili-
zados para identificar datos en un 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 obtener una lista de las especies que se encuentran
asociadas a esas coordenadas.
4. 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, quin 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 an-

lisis 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. & Miksch, S. (2008). Introduction to visual analytics. Danube University
Krems, Austria.
Foundation, O. (2006). Openstreetmap. Recuperado de https://www.openstreetmap.org/
Kirkman, R. & Davis, T. (2014). Openlayers 3. Recuperado de https://github.com/openlayers/ol3
lhomme, X. (2014, dec). A javascript-based parser for the geotiff image format. Recuperado de
https://github.com/xlhomme/GeotiffParser.js
Ritter, N. & Ruth, M. (2000). Geotiff format specification: Geotiff revision 1.0. Recuperado de
http://www.remotesensing.org/geotiff/spec/geotiffhome.html
Schindler, F. (2015). Read raw data from geotiff files. Recuperado de https://github.com/constan-
tinius/geotiff.js
6 La lectura de posiciones geogrficas se realiza mediante el uso del atributo mouseposition.

Caracterizacin de malware usando lenguajes

de intercambio de inteligencia
Randall Barnett Villalobos, Susan Rodrguez Segura, Julio Chinchilla Moya y Wilson Acua
Araya

[rbarnettv200,srodriguezs044,jchinchillam135,lacunaa475]@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 millo-
nes ms que en el 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 comuni-
cacin 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 API de MITRE, para poder consultar la informacin en tiempo real. Adems, permiten ob-
tener 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 colabo-
rar 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 sos-
pechosos y 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.
82 | Caracterizacin de malware usando lenguajes de intercambio de inteligencia

Para lograr la creacin de esta herramienta, se utilizaron dos grupos de metalenguajes un fra-
mework de intercambio de informacin entre servidores que las API de MITRE ofrecen:
1. Framework de comunicacin: TAXII.

2. Metalenguaje de comunicacin: STIX.
3. Metalenguajes de observabilidad: Se utilizaron MAEC y 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, tener informacin importante de su
origen, crear especificaciones de cmo reconocerlo y posteriormente analizar la manera de cmo
evitarlo (EclecticIQ, 2016).
Los ataques por medio de la web buscan obtener informacin o acceso a los sistemas crticos de
una organizacin. Para las empresas u organizaciones es vital tener conocimiento de las amena-
zas 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 ciberinteligencia para perfilar
y evitar futuras amenazas.
Para realizar este proceso se utilizaron los API provistos en Python 2.X para extraer informacin
relevante de los archivos, estandarizarlos y ordenarlos de una manera comprensible al ser huma-
no, sin importar la fuente de procedencia.
Lo anterior permite 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 estructura-
da. 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 utiliza-
do 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,
STIXHeader
from stix.indicator import Indicator
from stix.common import InformationSource,
Identity
Caracterizacin de malware usando lenguajes de intercambio de inteligencia | 83

Adems se debe crear un CybOX File Object, el cual va a contener un hash del archivo a carac-
terizar, como parte de un identificador nico (Security Intelligence, IBM, 2015). A partir de esto se
construye el paquete STIX y se adjunta el hash:
def add_stix_ciq_identity(file, hash):

stix_package = STIXPackage()
file.add_hash(hash)
Un paso importante para crear un indicador que identifique el artefacto de software de forma
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, para lo cual se usarn los parmetros de inicializacin a fin de es-
tablecer los nombres de las herramientas y de los proveedores del hallazgo. Es necesario, como
todo XML fuertemente tipado, darle las cabeceras adecuadas para que sea inspeccionado por el
API y 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. 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 compar-
tir 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 inter-
cambio de informacin para distintas organizaciones que pueden 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.
Peer to Peer: donde dos o ms organizaciones comparten informacin entre s directamente.
TAXII define el comportamiento de cuatro servicios, con respecto a 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: Un servicio para aprender cules servicios son compatibles y cmo inte-
ractuar 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: contiene constantes.
libtaxii messages: crea, maneja y analiza los mensajes.
El siguiente cdigo muestra la forma de construir el mensaje:
import libtaxii as t
import libtaxii.clients as tc
import libtaxii.messages as tm11
from libtaxii.constants import *
def add_taxii(stix_file):
content_block_bindings =
tm.ContentBinding(BIND_ID, None)
content_block =
tm.ContentBlock(content_block_bindings,
stix_file,
None, None)
content_block_list = [content_block]
message = tm.InboxMessage(

MESSAGE_ID, None, None, None, None,

None, None, None, content_block_list)
# Respuesta de servidor
return message
El siguiente 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 men-
saje.
1.3. Relacin entre STIX y TAXII

Esta relacin permitir el intercambio y el transporte de informacin sobre amenazas entre distin-
tas organizaciones. TAXII puede transmitir en su carga til el paquete de STIX, y definir cmo se
va a compartir esta informacin a travs de la red local o global. En la figura 1 se muestra cmo
interactan entre s los metalenguajes de STIX y TAXII.
2. Analizador de direcciones IP
El analizador es una aplicacin funcional para el anlisis de cualquier direccin IP en distintas ba-
ses 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 1. Interaccin entre STIX y TAXII
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 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 de los
motores de antivirus con los que cuenta el API.
Primero se procede a verificar el hash en la base de datos local, luego se verifica este mismo
dato en Virus Total, el cual proporciona el resultado. Luego de verificar el archivo malicioso, se
procede a realizar el empaquetado de la 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 su utiliza-
cin 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 direcciones IP y DNS encontrados en listas negras.
Figura 3. Reporte de aplicacin Intel-Sharing

5. Conclusiones
El tema de los metalenguajes para el intercambio de informacin an est poco desarrollado.
Con su utilizacin 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 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
Los lenguajes de intercambio de inteligencia, deben ser investigados ms a fondo, debido a que
abarcan un sinnmero de funcionalidades, las cuales no fueron desarrolladas en su totalidad en
este proyecto. Es importante seguir desarrollando funcionalidades de CyBOX y MAEC, as como
STIX y TAXII.
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 dis-
tintos 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 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). Standardizing cyber threat intelligence information with the structured threat
information expression (stix). Recuperado de http://stixproject.github.io/getting-started/
whitepaper/
EclecticIQ. (2016). Stix and taxii threat intelligence analysis. Recuperado de https://www.eclecti-
ciq.com/stix-taxii.html
MITRE. (2014). Taxii-specifications. Recuperado de https://github.com/TAXIIProject/TAXII-Speci-
fications
Security Intelligence, IBM. (2015). Stix, taxii and cybox can help with standardizing threat in-
formation. Recuperado de https://securityintelligence.com/how-stix-taxii-and-cybox
-can-help-with-standardizing-threat-information/


Libro Informática

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Libro Informática

Cargado por

Copyright:

Formatos disponibles

TECNOLOGAS DE

Dr. Antonio Gonzlez Torres (Ed.)

Facultad de Tecnologas de la Informacin

Facultad de Tecnologas de la Informacin

Lugar de edicin: San Jos, Costa Rica

La investigacin cientfica en ingeniera en general y en tecnologa de informacin en parti-

M.Sc. Edwin Aguilar Snchez

Este trabajo es producto de varios trabajos presentados en el Workshop en Ingeniera Inform-

En este volumen se incluyen los trabajos presentados en el marco de la tecnologa de la informa-

Edwin Aguilar Snchez

Antonio Gonzlez Torres

Randall Barnett Villalobos

Julio Crdoba Retana

Metodologa para la gestin de terceros en procesos de desarrollo de

Gestin de la relacin con terceros y metodologas giles 33

Definicin y modelado del proceso de gestin de la demanda para tecnologa de

Recomendaciones para la gestin de incidencias de tecnologas de la

Diseo de una arquitectura para la comunicacin entre protocolos en internet de

Etiquetas de Geolocalizacin en imgenes rster para la identificacin de

Caracterizacin de malware usando lenguajes de intercambio de

Metodologa para la gestin de terceros en

Yeison Nez Snchez y Antonio Gonzlez Torres*

Escuela de Ingeniera, Universidad Latinoamericana de Ciencia y Tecnologa, ULACIT, Urbaniza-

Palabras clave: Gestin de terceros, outsourcing, tercerizacin, adquisicin de software

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

gestin de las relaciones entre las partes.

1. Definicin de los requerimientos.

A esto se debe agregar la ausencia de sistemas de apoyo al proceso de desarrollo y gestin, as

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

2. Estado del arte

Lo anterior se puede realizar despus de efectuar bechmarking interno y externo (Franceschini,

Benchmarking interno: consiste en analizar las competencias centrales de la empresa y la

Benchmarking externo: se utiliza para analizar, identificar y seleccionar al proveedor, as

Planificacin: en esta etapa se determina la necesidad de adquisicin, los requisitos del

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

Anuncio: se encarga de dar a conocer la necesidad y requerimientos del producto a los

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

Otro referente utilizado en la planificacin de proyectos es el Project Management Institute (PMI),

El resultado final de la tercerizacin del desarrollo de software es la entrega de un sistema que

La incorporacin de la calidad en la elaboracin de productos o prestacin de servicios por lo

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

Nivel 1: en este nivel se definen 6 categoras de evaluacin para el producto y 5 categoras

3. Fases para la gestin de terceros en proyectos de

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

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

Capacidades esenciales de la organizacin: este factor hace nfasis en la verificacin de

Comparacin de la capacidad interna y los proveedores: tiene por objetivo determinar si

Enunciado del proyecto o desarrollo del acta de constitucin: se encarga de determinar

Historias de usuario. Elaboracin de la descripcin general del sistema por medio de

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

Identificacin de los interesados: corresponde a la identificacin de las personas in-

Como consecuencia, estas tareas se pueden desarrollar de la siguiente manera:

La visin general de la aplicacin o producto deseado.

La lista de funcionalidades, caractersticas del producto y usuarios que lo usarn.

Los requisitos de desempeo, velocidad, disponibilidad, volumen y fiabilidad.

La tecnologa por utilizar, la integracin de requisitos como el lenguaje de desarrollo, el

Anlisis y definicin de requisitos funcionales y no funcionales: se establecen los re-

Definicin del plan de aseguramiento de la calidad: se encarga de planificar los proce-

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

Aseguramiento: esta actividad se encarga de asegurar la calidad mediante la definicin

Fiabilidad: se refiere al correcto funcionamiento del sistema.

Usabilidad:corresponde con la facilidad de uso, comprensin y aprendizaje por parte de

Portabilidad: corresponde a la posibilidad de que el sistema pueda ser utilizado en diferen-

El procedimiento establece la seleccin de un mximo de tres categoras, de las cuales es obli-