Tecnologías de la Información y Gestión de ProyectosasInformaciónGestiónProyectos.pdf · prácticas para la gestión de proyectos de software en procesos de tercerización

Dr. Antonio González Torres (Ed.)

Tecnologías de la Informacióny Gestión de Proyectos

Facultad de Tecnologías de la InformaciónULACIT

2016

Dr. Antonio González Torres (Ed.)

Tecnologías de la Informacióny Gestión de Proyectos

Facultad de Tecnologías de la InformaciónULACIT

2016

ISBN: 978-9977-37-006-4Primera edición, 2016Universidad Latinoamericana de Ciencia y TecnologíaULACIT

Lugar de edición: San José, Costa RicaEditorial: Universidad Latinoamericana de Ciencia y TecnologíaTeléfono: 2523-4000Impreso en Costa Rica

Reservados todos los derechos. Prohibida la reproducción no autorizada porcualquier medio, mecánico o electrónico del contenido total o parcial de estapublicación.

A quienes trabajan mientras sueñan.

Prefacio

Nos complace presentar este primer volumen de publicaciones de lasinvestigaciones realizadas por profesores y estudiantes de ULACIT de la carrerade Ingeniería Informática, en las que se abordan aspectos interesantes de latecnología de información y la gestión informática. Representan el resultado deun esfuerzo sostenido de la Facultad de Tecnologías de Información por construiruna estructura permanente de investigación que haga escuela para la formaciónde investigadores dentro de nuestra Facultad docente y comunidad de estudiantesde bachillerato, licenciatura y maestría en Ingeniería Informática.

Este libro es la respuesta a un desafío formidable que enfrentan lasuniversidades privadas para realizar investigación científica en ingeniería,ciencias naturales o ciencias sociales, por la escasez de recursos humanosy materiales, dado su alto costo en esfuerzo, tiempo y calidad. Para losespecialistas, es reconocida la gran dificultad que existe en estas institucionespara articular investigadores experimentados y docentes en un programa deinvestigación que arranca desde cero, con el propósito de ser permanente yriguroso en su contenido.

En los procesos de investigación de las ciencias naturales y sociales, se extraeinformación y conocimiento a partir de la observación directa o indirecta delobjeto en estudio, para confirmar o refutar hipótesis de trabajo planteadas,siguiendo el llamado método científico. En ingeniería, por el contrario, nose persigue como fin la descripción o explicación del objeto como tal, sinoencontrar la solución a un problema u optimizar una solución. Esto puedeimplicar iterar planteamientos o realizar experimentos y simulaciones, utilizandoobjetos de estudio físicos o abstractos (ej. Máquinas de turing), para inferirun planteamiento que satisfaga las restricciones y requisitos que imponga elcontexto. Es así como se utiliza el llamado método de investigación de ingeniería,diferente del método científico.

La investigación científica en ingeniería en general y en tecnología deinformación en particular, busca encontrar soluciones eficaces y eficientes aproblemas simples o complejos, aplicando sistemáticamente el conocimientocientífico y las herramientas tecnológicas, para crear el diseño de la solución;desarrollar y construir dispositivos, estructuras y procesos, bajo restriccionesy requisitos impuestos por la tecnología disponible y por consideracioneseconómicas, legales, ambientales y humanas.

Las publicaciones que se presentan en este primer volumen representan estaclase de investigación científica que aborda la solución de problemas de ingenieríainformática, buscando hallar el camino para establecer un pequeño universo delíneas de investigación que puedan consolidarse y profundizarse en el tiempo yque nos permitan concentrar recursos y esfuerzos para ganar en profundidad yrigor científico.

Los factores claves para crear en tan poco tiempo la estructura deinvestigación de académicos, estudiantes y recursos tecnológicos y financieros,han sido el compromiso de los profesores investigadores que conforman elequipo de investigación; la seriedad con que han abordado sus trabajos deinvestigación los estudiantes, autores de las publicaciones presentadas, y elcompromiso de las autoridades de la Universidad para apoyar la construcciónde la estructura de investigación en ingeniería de ULACIT, cuyo objetivoes formar a los profesores y estudiantes de la carrera Ingeniería Informáticacon las competencias para efectuar investigación científica en este campo, quepropicie la producción de publicaciones que incrementen su desarrollo académicoy proyecten a la universidad en respuesta a las necesidades de talento de laeconomía costarricense.

En este momento, el sector industrial tecnológico del país (diseño,manufactura y servicios tecnológicos) emplea a más de 25.000 ingenieros, delos cuales más de 3.000 laboran a tiempo completo en equipos de investigación,como parte de los procesos que buscan mejorar las cadenas de valor y optimizarlos procesos que la componen, así como en innovar productos y servicios. Hastaahora las empresas han encontrado el talento que requieren para hacer que susprocesos se expandan en el país, pero están enfrentando escasez de ingenieroscon formación en investigación en ingeniería. De igual forma, las empresas estánhaciendo frente a la falta de líderes de equipos de investigación y administradoresde investigación, por lo que han manifestado que necesitan apoyo académico einstitucional para el desarrollo de estas capacidades y habilidades en el personalque requieren contratar.

Hemos observado que la demanda de ingenieros competentes para participaren equipos de investigación de ingeniería está en aumento desde hace cinco años,aproximadamente. Es un requerimiento emergente, que no está siendo atendidopor la academia en la medida necesaria para apoyar el desarrollo de un sectorindustrial tecnológico, más allá de la manufactura, que ha encontrado en eltalento costarricense el capital humano para establecerse y expandirse en el país.

M.Sc. Edwin Aguilar SánchezDecanoFacultad de Ingeniería Informática

Setiembre del 2016

Comité Evaluador

Este trabajo es producto de varios trabajos presentados en el Workshop enIngeniería Informática y Tecnologías de la Información que es organizado por laFacultad de Ingeniería Informática de la Universidad Latinoamerica de Cienciay Tecnología (ULACIT).

En este volumen se incluyen los trabajos presentados en el marco de latecnología de la información y gestión de proyectos informáticos.

El comité evaluador de los trabajos presentados estuvo constituido por lossiguientes profesores:

Edwin Aguilar SánchezAntonio González TorresRandall Barnett VillalobosJulio Córdoba Retana

Índice general

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

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

Gestión de la relación con terceros y metodologías ágiles . . . . . . . . . . . . . . . 22Fabián Chaves Serrano, David Mora Solano y Antonio GonzálezTorres∗

Definición y modelado del proceso de gestión de la demanda paratecnología de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

David Rodolfo Camacho Quiros, Reagan Ching Fung, Julio CórdobaRetana y Antonio González Torres

Recomendaciones para la gestión de incidencias de tecnologías de lainformación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Verny Mora Jiménez, Paulo Viales Wahrmann, Julio CórdobaRetana y Antonio González Torres

Diseño de una arquitectura para la comunicación entre protocolos eninternet de las cosas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Marco Córdoba Padilla, Frank Trejos Moya, Fernando ChinchillaJiménez y Antonio González Torres

Etiquetas de Geolocalización en imágenes ráster para la identificaciónde especímenes biológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Jonathan Quintana Berríos, Esteban Robleto Rodríguez, AntonioGonzález Torres

Caracterización de malware usando lenguajes de intercambio deinteligencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Randall Barnett Villalobos, Susan Rodríguez Segura, JulioChinchilla Moya y Wilson Acuña Araya

Metodología para la gestión de terceros enprocesos de desarrollo de software

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

Escuela de Ingeniería,Universidad Latinoamericana de Ciencia y Tecnología,

ULACIT, Urbanización Tournón, 10235-1000San José, Costa Rica

[email protected]@ulacit.ac.cr∗

http://www.ulacit.ac.cr

Resumen La tercerización permite que las empresas reduzcan costos,optimicen el uso de sus recursos, brinden mayor valor agregado en laentrega de servicios y se concentren en alcanzar los objetivos estratégicosdel negocio. Sin embargo, el desconocimiento de cuáles elementos esnecesario considerar en la planificación de los procesos de tercerizaciónha contribuido al fracaso de un gran número de proyectos de desarrollo desoftware. Entre los elementos que por lo general se omiten se encuentranaspectos de aseguramiento de la calidad tanto del producto como delproceso, la falta de participación activa de los clientes y usuariosfinales durante todas las etapas del proceso y la falta de seguimientoy comunicación con el proveedor. Como consecuencia, el objetivo de estetrabajo de investigación es proponer una metodología para la gestiónde la relación entre clientes y proveedores durante los procesos detercerización del desarrollo de sistemas. Por lo que se realiza una síntesisde los procesos y mejores prácticas que deben contemplarse en la gestiónde terceros con el fin de facilitar los procesos de tercerización, mejorarlos resultados que se obtienen y contribuir con la generación de valoragregado tanto para el cliente como para el proveedor. Como resultado,este trabajo presenta una metodología que contempla 7 fases, las cualesa su vez comprenden entradas, tareas y salidas que son utilizadas por lasfases subsiguientes.

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

1. Introducción

La evolución en los negocios ha propiciado mayor competencia en todos losámbitos de los mercados de bienes y servicios, por lo que las organizacionesbuscan utilizar mejor sus recursos económicos y humanos para brindar valoragregado a sus clientes, a la vez que se concentran en alcanzar los objetivos

2 Núñez y González

estratégicos del negocio. Con ese fin utilizan como alternativa la tercerización1

de servicios, la cual consiste en la contratación de un proveedor para que ejecutealgunas funciones específicas que, por lo general, no son parte de las actividadescentrales de la empresa.

Aunque se considera que los beneficios de la tercerización son numerosos,se han logrado identificar inconvenientes que se presentan durante suimplementación, debido a una deficiente gestión de las relaciones entre las partes.De acuerdo con algunos estudios, alrededor de un 30% de las empresas cancelansus contratos de tercerización de forma prematura; entre el 20 y 25% fracasandurante los primeros dos años del contrato y el 50% fracasa en los primeroscinco años de vigencia (Grossi y Calvo-Manzano, 2012). Cabe resaltar que loscasos de mayor incertidumbre e inconvenientes se presentan en los procesos detercerización de software, debido a la complejidad y naturaleza de los tipos deproyectos.

Los problemas que se asocian con la tercerización del desarrollo de software sepresentan por el desconocimiento de los factores que se deben contemplar durantela etapa de planificación para adquirir productos de software. Esto tiene comoconsecuencia que el producto final no responda a las necesidades o no se ajustea los requerimientos definidos por el cliente (Erazo-Paruma, Guerrero-Mera yCorrea-Pino, 2014).

Este tipo de inconvenientes suelen presentarse cuando la empresa contratanteno realiza de forma adecuada las siguientes tareas:

1. Definición de los requerimientos.2. Selección y contratación del proveedor (Erazo-Paruma et al., 2014).3. Identificación del alcance del proyecto.4. Definición de la metodología de desarrollo.5. Participación activa de los clientes o usuarios finales en el proceso de

desarrollo.6. Adecuada administración y comunicación con el proveedor.

A esto se debe agregar la ausencia de sistemas de apoyo al proceso dedesarrollo y gestión, así como de herramientas y métricas de control para elaseguramiento de la calidad (Selleo, 2016).

Como consecuencia, se han preparado diversos documentos e investigacionesque detallan las mejores prácticas para mitigar estos problemas y apoyar elproceso de tercerización. Sin embargo, la información se encuentra dispersa endiversas fuentes, y no existe una presentación visual e integral del proceso parafacilitar la planificación de la calidad y gestión de la comunicación para guiar deforma apropiada a los gerentes y directores de proyectos.

El proceso de tercerización requiere el cumplimiento de ciertas pautas y pasospara disminuir los riesgos durante el desarrollo de los productos, a la vez quese aumenta la posibilidad de éxito y maximizan los beneficios económicos. Portanto, los objetivos de este trabajo de investigación consisten en identificar elflujo del proceso de administración de la relación con terceros y proponer una1 La tercerización es conocida en inglés como outsourcing.

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

metodología para sintetizar algunas de las mejores prácticas e investigacionesrealizadas sobre el tema.

Con ese fin, este trabajo de investigación lleva a cabo una revisión debibliografía (sección 2) para desarrollar una metodología con las mejoresprácticas para la gestión de proyectos de software en procesos de tercerización(sección 3) y, finalmente, presenta las conclusiones y trabajos futuros (sección4).

2. Estado del arteLos procesos de tercerización del desarrollo de software, por lo general, son

complejos, y aunque existe bibiliografía para apoyar a los gestores de estosprocesos, aún persiste una serie de desafíos que requieren atención.

Las actividades de alto nivel de un proceso de tercerización contempla laidentificación del tipo de proyecto que se quiere llevar a cabo, pero de formaconcreta y detallada también toma en cuenta qué es lo que se va a desarrollar,cómo se va a llevar a cabo y quiénes estarán involucrados durante su desarrollo.Con base en esto, es relevante considerar los siguientes puntos (Selleo, 2016)cuando se desea iniciar un proceso de tercerización:

¿Cuáles tareas o proyectos se van a tercerizar? Debe existir claridadsobre las tareas o proyectos que se desea tercerizar y la naturaleza de estos.

¿Qué se requiere hacer? La respuesta a esta pregunta tiene por fin definir deforma precisa qué es lo que se requiere hacer y cuáles son sus requerimientos.

¿Cómo cómo se llevarán a cabo las tareas o el proyecto? Por su partela respuesta a esta pregunta involucra no solo la metodología por utilizarsino también la estructura del equipo de trabajo que va a participar en sudesarrollo.

¿Quién estarán involucrados? Es importante conocer quiénes serán losusuarios del sistema, los gerentes o ejecutivos que apoyarán el desarrollo yquiénes estarán participando en el proyecto, tanto en la etapa de definiciónde requerimientos como de seguimiento y aceptación.

Lo anterior se puede realizar después de efectuar bechmarking interno yexterno (Franceschini, Galetto, Pignatelli y Varetto, 2003). En este contexto,estos dos tipos de benchmarking se entiende de la siguiente forma:

Benchmarking interno: consiste en analizar las competencias centrales de laempresa y la identificación de los procesos que serán tercerizados, conformecon los resultados de un análisis que evidencia la reducción de costos o la faltade habilidades de los empleados. En esta etapa se define el tipo de relaciónque se establecerá con la empresa proveedora, de acuerdo con los interesesdel cliente. La relación que se establece puede ser tradicional, temporal,estratégica o de red organizacional.

Benchmarking externo: se utiliza para analizar, identificar y seleccionar alproveedor, así como para definir los niveles del acuerdo de servicios.


En línea con lo anterior, un modelo para la administración del proceso detercerización puede contemplar (Erazo-Paruma et al., 2014) los siguientes pasos:

Planificación: en esta etapa se determina la necesidad de adquisición, losrequisitos del software a adquirir, la identificación de los proveedorespotenciales y criterios de aceptación en conjunto con el plan de adquisición,por lo que se procede a efectuar la planificación definiendo sus prioridades yel orden de su desarrollo.

Anuncio: se encarga de dar a conocer la necesidad y requerimientos delproducto a los posibles proveedores que fueron identificados.

Selección del proveedor: en esta etapa se lleva a cabo la selección delproveedor que mejor se ajusta al desarrollo del sistema y el cumplimiento delos requerimientos.

Contratar: es la etapa durante la cual se establecen de manera formal losacuerdos negociados con el proveedor, y se formaliza la relación entre elcliente y el proveedor que incluye la celebración del contrato.

Monitoreo: tiene como fin dar seguimiento al progreso de los proveedores en elcumplimiento de las metas, y efectúa una revisión del avance del proveedorde acuerdo con los costos y plazos acordados.Esto se lleva a cabo de acuerdo con los niveles del acuerdo de servicios.Uno de los fines de esta etapa es medir el desempeño del proveedormediante curvas de eficiencia. Éstas curvas consisten en establecer porcada acuerdo de servicio dos líneas. La primera línea se relaciona con losobjetivos que se busca lograr y la segunda línea refleja los resultados delrendimiento del proveedor y sirve para determinar las brechas en el procesode implementación mediante dos ejes de evaluación (tiempo y nivel deacuerdo de servicio), los cuales son evaluados en función de la cantidadde fases que se desean evaluar. para tomar acciones correctivas en caso deincumplimiento (Franceschini et al., 2003).

Aceptación: durante esta etapa se lleva a cabo la evaluación del producto,aplicando las pruebas y criterios de aceptación establecidos.

Cierre: es la etapa encargada de verificar que todos los entregables del productohan sido aceptados de forma satisfactoria.

Seguimiento: en esta ultima etapa se realiza el monitoreo del desempeño delsistema y de los tiempos de respuesta del proveedor.

En general, las tareas y pasos que contempla el proceso de tercerizaciónse pueden agrupar en 5 grandes fases: preparación, selección del proveedor,transición, administración de las relaciones y reconsideración (Perunović yPedersen, 2007). En estas fases se describen actividades que responden a unao varias preguntas claves para el desarrollo de cada una de las fases.

La planificación para la tercerización debe ser integral y debe definir eltipo de relación que se desea tener con la empresa proveedora. Esta relaciónes influenciada por la importancia de la actividad y los riesgos de realizar latercerización, lo cual se puede representar mediante una matriz según el tipode relación: colaboración competitiva, colaboración cercana, muchos suplidoreso suministros seguros (McIvor, 2005).


Debido a la aceptación de la tercerización como un método eficaz para apoyara los negocios, varias organizaciones internacionales han desarrollado pautas yrecomendaciones, entre las cuales se encuentran estrategias para identificar losprocesos que se pueden tercerizar, establecer aspectos de coordinación entre losprocesos del cliente y el proveedor, determinar roles y responsabilidades, el tipode información que se debe comunicar y factores para la gobernanza del proceso(CabinetOffice, 2011). En la misma dirección, también se busca asegurar quelos contratos estén alineados con las necesidades del negocio, administrar elrendimiento, negociar y formalizar los contratos y mantener políticas para lagestión del ciclo de vida del proyecto (CabinetOffice, 2011).

Otro referente utilizado en la planificación de proyectos es el ProjectManagement Institute (PMI), el cual establece procesos para planificar, efectuary dar seguimiento a un proyecto (Project Management Institute, 2013).Entonces, tomando como base las mejores prácticas de PMI y los problemasque se presentan durante la gestión de terceros en los procesos de desarrollo desoftware, es importante resaltar los siguientes puntos:

Gestión del alcance: se deben incluir las características y funciones querequieren los usuarios mediante la adecuada definición de requerimientos.

Gestión de las comunicaciones: este tipo de gestión es necesaria parapropiciar una comunicación eficaz entre quienes participan en el proyecto,tanto del lado cliente como proveedor, por los diferentes niveles deexperiencia, perspectivas e intereses que pueden influir y tener impacto enlos resultados de los proyectos.

Gestión de los interesados: incluye procesos para identificar a las personas,grupos u organizaciones que pueden afectar o ser afectados por el proyecto.Es preciso analizar aspectos relacionados como las expectativas de losinteresados y lograr su participación en las decisiones y ejecución deproyectos.

El resultado final de la tercerización del desarrollo de software es la entregade un sistema que cumpla aspectos de calidad y satisfaga las expectativas ynecesidades planteadas por los usuarios. Por esa razón es importante considerardesde el inicio del proceso la ausencia de defectos, la aptitud para el uso, laseguridad, la confiabilidad, el cumplimiento de especificaciones y los elementosnecesarios, de acuerdo con el proyecto, en torno a los elementos de calidad desoftware (Mendoza, Pérez y Grimán, 2005).

La incorporación de la calidad en la elaboración de productos o prestaciónde servicios por lo general se incorpora en las etapas finales del proceso dedesarrollo del software, por ejemplo: en las pruebas finales de los entregables.Sin embargo, la calidad es un proceso que se construye desde que inicia unproyecto de software, y no es un elemento que pueda ser agregado de formaposterior, durante el proceso o mediante una evaluación final. La calidad delproceso de desarrollo garantiza la calidad del producto y como consecuencia nose pueden desvincular (Mendoza et al., 2005). Por consiguiente, el aseguramientode la calidad se debe realizar durante todo el proceso, con la finalidad de que


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

Con base en los conceptos discutidos hasta este punto, y la recopilación denormas e investigaciones con respecto a las evaluaciones de calidad Mendozaet al. (Mendoza et al., 2005) proponen un marco de evaluación dividido en lossiguientes niveles:

Nivel 0: este nivel contempla el valor más alto en la jerarquía y se correspondecon los aspectos externos e internos tanto del proceso como del producto.

Nivel 1: en este nivel se definen 6 categorías de evaluación para el producto y5 categorías para el proceso de desarrollo.

Nivel 2: este nivel relaciona las características de cada unas de las categoríasque definen las áreas claves para satisfacer, lograr, asegurar y controlar lacalidad tanto del producto como del proceso.

Nivel 3: en este otro nivel se asocian las métricas utilizadas para medircuantitativamente cada una de las características que fueron definidas conel fin de determinar si la calidad planificada es satisfactoria o no.

La estimación adecuada de la calidad realiza cálculos tanto para estimar lacalidad del software como producto como del proceso, y contribuye a identificarlas características que no han sido satisfechas por el sistema desarrollado(Mendoza, Pérez, Grimán y Rojas, 2002). Este proceso se divide en tres fases, endonde la primera fase se corresponde con la evaluación del proceso de desarrollo,la segunda fase con la valoración del sistema y la tercera fase con la integraciónde los resultados que combinan ambas etapas.

De acuerdo con el análisis realizado, varios trabajos de investigaciónsugieren diferentes fases para el proceso de tercerización. Sin embargo, lostrabajos estudiados no contemplan aspectos relacionados con la gestión de lascomunicaciones, la gestión de los interesados y el aseguramiento de calidad, loscuales son aspectos que deben estar presentes en la definición de una metodologíapara gestionar la relación con terceros durante los procesos de tercerización.

Como consecuencia, la metodología que se propone en la siguiente secciónsintetiza las fases fundamentales que se deben tomar en cuenta en los procesosde tercerización y tiene presentes aspectos para mejorar la comunicación, laparticipación activa de las partes y la calidad del producto final.

3. Fases para la gestión de terceros en proyectosde desarrollo de software

En esta sección se presenta la propuesta de una metodología para apoyar lagestión de los procesos de tercerización, usando como referencia la revisión y elanálisis efectuado en la sección 2. La metodología propuesta se divide en 7 fases:

1. Inicio.2. Planificación.


3. Selección y contratación del proveedor.4. Ejecución.5. Administración de la relación con el proveedor.6. Aceptación y cierre.7. Reconsideración.

La relación entre las fases mencionadas con los procesos aseguramiento dela calidad, administración de la relación y gestión de la comunicación se puedeobservar en la figura 1, además de los vínculos que existen entre estos.

La gestión de la comunicación se debe desarrollar durante casi todas las fasesde la tercerización (con excepción de las fases Inicio y Planificación), e incluyela administración de la relación y el aseguramiento de la calidad. El objetivo deeste proceso es garantizar una mejor comunicación entre el cliente y el proveedorpor medio de herramientas, métodos y técnicas que faciliten el intercambio deinformación desde las etapas iniciales del desarrollo del sistema.

Por su parte, la administración de la relación busca mejorar la relaciónentre el proveedor, usuarios e interesados para garantizar la comprensiónde necesidades, efectuar el seguimiento del avance del proyecto medianteevaluaciones durante el desarrollo y durante la entrega del producto. En cuantoal aseguramiento de la calidad, esta debe estar presente desde el inicio de laejecución o desarrollo del sistema, y juega un papel preponderante en la fase deaceptación y cierre.

Figura 1: Relación entre las fases y procesos para la gestión de terceros durante eldesarrollo de software.


En las siguientes secciones se explican con detalle las fases contempladas enla figura 1.

3.1. InicioEsta fase verifica la necesidad de desarrollar un sistema por medio de la

tercerización, y si dicha verificación es positiva, justificar su desarrollo, obtenerel apoyo interno, y formalizar el inicio del proceso de contratación con el apoyode los ejecutivos y directores. Algunas de las tareas que es necesario contemplaren esta fase son las siguientes:

Análisis, ¿desarrollo interno o externo?: se debe realizar la evaluaciónobjetiva del problema que se requiere resolver, para verificar si es posibleefectuar el desarrollo de forma interna o si se requiere apoyo externo. Existenfactores que pueden influir (Project Management Institute, 2013) en estadecisión:Capacidades esenciales de la organización: este factor hace énfasis en

la verificación de las capacidades centrales del negocio y su principalactividad económica, para delegar a terceros las funciones que no generanvalor agregado o sobre las cuales se cuenta con poco conocimiento yexperiencia.

Valor proporcionado por los proveedores: consiste en analizar lacapacidad del proveedor en el cumplimiento de las expectativas delproyecto, las posibilidades de que ayude a generar valor y contribuyaa satisfacer las necesidades del cliente.

Riesgos asociados al desarrollo del proyecto: realiza una evaluaciónpara identificar los riesgos que conlleva efectuar el desarrollo del sistemaa lo interno de la empresa. Si los riesgos identificados son significativos,tienen alta probabilidad de concretarse y pueden ocasionar perjuiciosgraves, es conveniente considerar la tercerización del desarrollo paradelegar la responsabilidad en una organización experimentada que puedaasegurar el éxito y lograr una rentabilidad efectiva con el desarrollo delproyecto.

Comparación de la capacidad interna y los proveedores: tiene porobjetivo determinar si las herramientas, conocimientos, experiencia,capacidad de administración y capacidades técnicas de los proveedoresson mayores a las capacidades internas de la organización para llevar acabo el desarrollo exitoso del proyecto.

Individualización de los proyectos a tercerizar: esta tarea tiene por fincomparar la eficiencia de las actividades o procesos que realiza laorganización, usando como base posibles pérdidas de dinero, gastos excesivoso ausencia de habilidades para el desarrollo del sistema, con el objetivo deidentificar los proyectos que se pueden tercerizar.

Enunciado del proyecto o desarrollo del acta de constitución: seencarga de determinar la necesidad de adquisición de una forma general, parapresentar el proyecto a los encargados de la organización con la intención de


obtener su aceptación y compromiso. Esta tarea se puede realizar mediantediferentes técnicas:

Historias de usuario.Elaboración de la descripción general del sistema por medio de reuniones,sesiones, foros, talleres o lluvia de ideas que involucren no solo a los altosjerarcas sino también a los usuarios finales.

Identificación de los interesados: corresponde a la identificación de laspersonas internas que pueden ser beneficiadas o perjudicadas con eldesarrollo del sistema. Esta tarea busca garantizar la participación de esaspersonas en el proceso.

3.2. PlanificaciónEsta fase corresponde a la definición de los aspectos que se deben tomar en

cuenta para controlar la ejecución del proyecto y obtener el producto deseado,por lo que se debe efectuar la definición adecuada del alcance, los requerimientos,los elementos de calidad que se deben evaluar, el recurso humano necesario, lasformas de comunicación con el proveedor, la definición de criterios de selecciónde proveedor, el tipo de contrato a utilizar y el contenido presupuestario.

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

Definición del alcance: brinda el panorama de alto nivel de los requerimientosdel sistema, por lo que es necesario detallar (Selleo, 2016):

La visión general de la aplicación o producto deseado.El propósito del nuevo sistema, así como el problema (objetivo onecesidad) que busca resolver y su definición para alcanzar el éxito.La lista de funcionalidades, características del producto y usuarios quelo usarán.Los requisitos de desempeño, velocidad, disponibilidad, volumen yfiabilidad.La tecnología por utilizar, la integración de requisitos como el lenguajede desarrollo, el sistema operativo y sistemas que deben trabajar enconjunto con la nueva aplicación.

Existen circunstancias en las cuales según el tipo de sistema, no se tieneclaridad para definir el alcance al inicio de la planificación. En estosescenarios, es conveniente abordarlo y completarlo en las etapas claves,por ejemplo, en las iteraciones o aceptaciones de los entregables. De formaadicional, se debe tomar en cuenta la selección del tipo de contrato paraestos escenarios, a fin de no afectar los costos o el producto final.

Análisis y definición de requisitos funcionales y no funcionales: seestablecen los requerimientos de bajo nivel del sistema y contempla ladefinición de todas las necesidades que debe satisfacer para alcanzar elproducto deseado, según los objetivos planteados y el problema que buscaresolver.

Realización del presupuesto: para identificar la inversión que se debeefectuar para el desarrollo del software.


Definición del plan de aseguramiento de la calidad: se encarga deplanificar los procesos, requerimientos, salidas y canales de retroalimentaciónde la calidad del sistema durante el ciclo de vida del proyecto. Para realizarla gestión de la calidad de software se deben considerar (IEEE ComputerSociety, 2014) las siguientes fases:Planificación: esta tarea consiste en determinar cuál o cuáles estándares se

desean incluir en el proceso de desarrollo, definir los objetivos de calidad,estimar los costos y definir el cronograma para realizar las actividadesde revisión de la calidad del software.

Aseguramiento: esta actividad se encarga de asegurar la calidad mediantela definición de las actividades para satisfacer los requerimientos,necesidades y costos en tiempo, de acuerdo con el cronograma delproyecto. Pero además define y evalúa si el proceso seleccionado parael desarrollo es apropiado, contempla la definición de los objetivos decalidad e identifica las medidas técnicas y los procedimientos para elreporte de problemas y la ejecución de acciones correctivas.

Con base en lo anterior, se recomienda seleccionar las categorías de calidad(Mendoza et al., 2002) que se desea evaluar:

Funcionalidad: la capacidad de cumplir con los requerimientos onecesidades para las cuales el sistema fue desarrollado.Fiabilidad: se refiere al correcto funcionamiento del sistema.Usabilidad: corresponde con la facilidad de uso, comprensión yaprendizaje por parte de los usuarios.Eficiencia: consiste en el rendimiento apropiado en escenarios condemandas 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 serutilizado en diferentes ambientes operativos o plataformas sin necesidadde realizar cambios.

El procedimiento establece la selección de un máximo de tres categorías,de las cuales es obligatorio seleccionar la evaluación de la funcionalidad,debido a que evalúa el cumplimiento de los requerimientos definidos. Larecomendación de seleccionar un máximo de tres categorías se debe a quela elección de un número mayor puede desencadenar que la evaluación deuna categoría entre en conflicto con la evaluación de otra categoría. Laselección de las otras dos categorías adicionales depende de la estrategia ynecesidades que la organización busca satisfacer con el sistema. Por último,en esta fase y con base en las categorías seleccionadas, se seleccionan lasmétricas cuantitativas que permitirán realizar la evaluación y estimación dela calidad del producto.

Planificación de la gestión de recursos humanos: es necesario planificarlos roles necesarios para la gestión del proyecto y el desarrollo exitoso delsistema (Erazo-Paruma et al., 2014). Estos roles pueden variar de acuerdocon el tipo de organización y proyecto, pero se recomienda tener en cuentalos roles que se presenta en la tabla 1.


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

Puesto/Rol Descripción de responsabilidadDirector (Dir) Es la persona con conocimiento de los procesos de la

organización y tiene la responsabilidad de administrar elproyecto.

Encargado deadquisiciones (EA)

Es el encargado de realizar, coordinar y efectuar la contratacióndel proveedor, con base en los parámetros definidos, y es elcontacto directo entre el cliente y el proveedor, con el fin decentralizar la comunicación y el flujo de información.

Programador oIngeniero desoftware (IS):

Es la persona o grupo de personas que colaboran en ladefinición de los alcances y requerimientos del sistema. Estapersona puede ser el contacto técnico para comunicaciones conel proveedor cuando se esté ejecutando el proyecto.

Encargado decontratación (EC):

Es la persona o grupo con conocimientos en aspectos legalespara el establecimiento y negociación del contrato, con base enlas necesidades definidas por el director y los usuarios.

Ingeniero de calidadde software (QA):

Es la persona o grupo encargado de participar, verificar,asegurar, probar, controlar y comunicar la calidad del procesoy producto con base en lo planificado y acordado con elproveedor. Envía información a los interesados sobre el estadodel proyecto para identificar atrasos, disconformidades obrechas que puedan existir con el fin de que se pueda realizarla toma de decisiones de forma oportuna.

Usuario/interesado(I):

Son las personas interesadas o afectadas por el desarrollo delsistema y se debe procurar su compromiso de participación enel proceso para asegurar su satisfacción con el producto final.

Elaboración del plan de comunicaciones: contempla determinar el flujo decomunicación entre el cliente y el proveedor para garantizar la participaciónactiva de los interesados y canalizar la información por medio de unencargado, que facilite el proceso y esté en disposición de utilizar lasherramientas para hacer la gestión adecuada de la comunicación. Loselementos básicos que debe tener el plan de comunicaciones (ProjectManagement Institute, 2013) son los siguientes:

Requisitos de comunicación de los interesados.Tipo de información que debe ser comunicada, incluidos el idioma,formato, contenido y nivel de detalle.Motivo para distribuir dicha información.Plazos y frecuencia para la distribución de la información y recepción delas confirmaciones o respuestas.Responsable de comunicar la información.Responsable de autorizar la divulgación de información confidencial.Persona o grupos que recibirán la información.Métodos o herramientas utilizadas para transmitir la información, talescomo memorandos, correo electrónico o comunicados de prensa.


Recursos asignados para las actividades de comunicación, incluidos eltiempo y presupuesto.Proceso de escalamiento, con identificación de los plazos y la cadena demando (nombres) para el escalado de los incidentes que no se puedanresolver a un nivel inferior.Método para actualizar y refinar el plan de gestión de las comunicacionesa medida que el proyecto avanza y se desarrolla.Glosario de terminología común.Diagramas del flujo que sigue la información del proyecto, flujos detrabajo con la posible secuencia de autorizaciones, lista de informes yplanes de reuniones.Restricciones en materia de comunicación que se derivan de la legislacióno normativa, la tecnología o las políticas de la organización.

Definición del tipo de contrato por utilizar: La definición del tipo decontrato a utilizar se debe basar en el tipo de producto y proyecto (ProjectManagement Institute, 2013), y podría ser alguno de los siguientes:

Contratos de precio fijo: este tipo de contrato establece un precio finalque es fijo y es adecuado cuando la especificación de requerimientos esprecisa, aunque por lo general establecen que si se realiza un cambioposterior se dará un aumento en los costos.

Contratos de costos reembolsables: se realizan los pagos por los costosincurridos durante el desarrollo del sistema, más los honorarios delproveedor. Este tipo de contratos ofrece flexibilidad para reorientar alproveedor si el alcance del trabajo no se puede definir con precisión alinicio y requiere modificaciones.

Contrato por tiempo y materiales: corresponde a un híbrido de los dostipos anteriores y se utiliza cuando se necesita aumentar el personal,contratar expertos o cualquier tipo de apoyo externo en los casos enque no es posible establecer con prontitud, al inicio del proyecto, éstainformación en el enunciado del trabajo.

Es importante que de forma independiente al tipo de contrato seleccionado,se puedan contemplar incentivos para motivar al desarrollador o proveedora que inviertar mayor esfuerzo y genere un producto de calidad.

Establecimiento de los criterios de selección del proveedor: esta tarearealiza la identificación de los criterios básicos con lo cuales seránevaluados y seleccionados los proveedores. Algunos criterios (Grossiy Calvo-Manzano, 2012) que pueden ser considerados son: el precio,la calidad, tiempo de entrega, flexibilidad, capacidad técnica, riesgo,reputación, posición en la industria, comprensión de las necesidades,garantía presentada, referencias, desempeños anteriores, posición financiera,capacidad de respuesta, experiencia, recursos humanos, participación demercado, administración, organización y soporte. Es importante establecer,según las prioridades de la organización, el peso relativo de cada criterio paracalcular la calificación final.


Identificación de los proveedores potenciales: corresponde a laidentificación de los proveedores que pueden desarrollar el sistema conbase en la experiencia de expertos, la experiencia de proyectos anteriores yel análisis del mercado.

Establecimiento y documentación de los criterios de aceptación:Estos criterios corresponden a la especificación de las necesidades,requerimientos, capacidades técnicas y de calidad que el cliente establececomo mínimos para aceptar los entregables y el producto final.

Realización del enunciado del trabajo: este documento contempla lainformación del alcance y requerimientos del sistema con suficiente detallepara permitir que los proveedores realicen el análisis y determinen si estánen condiciones de proporcionar el sistema requerido. Este tipo de documentoes necesario para solicitar propuestas a los posibles proveedores y realizar elanuncio formal de la solicitud de tercerización.

3.3. Selección y contratación del proveedor

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

Anunciar la tercerización: con base en el enunciado del proyecto, seanuncia la necesidad de contratar a un proveedor (i.e. mediante licitación,contratación directa o invitación).

Recepción de las ofertas: una vez transcurrido el plazo definido, se recibenlas propuestas de los proveedores interesados.

Evaluar las ofertas: para garantizar el beneficio de la organización, se realizala selección del proveedor con base en los criterios de selección establecidos ysegún la estrategia de la organización con respecto al peso en la calificaciónde cada criterio.

Selección del proveedor: se recomienda utilizar una matriz de calificacióncuantitativa con los resultados de las evaluaciones de los criterios, paraobtener la calificación de los proveedores y garantizar la mejor selección.

Preparación y negociación del contrato: esta tarea debe contemplar almenos la definición del alcance, requisitos de rendimiento, cronograma,acuerdos y responsabilidades, información de puntos de contacto, periodo ylugar de ejecución, canales y frecuencia de las comunicaciones, estructura delprecio, términos de pago, criterios de inspección y aceptación de entregables,garantías presentadas por el proveedor, acuerdos de servicio y soporte,proceso para hacer cambios al proyecto, confidencialidad, derechos de autory propiedad intelectual, derechos de terminación, criterios de rendimiento delos proveedores (SLA2), informes de desempeño, incentivos y penalizaciones(Project Management Institute, 2013) .

2 SLA se refiere Service Level Agreement en su acepción del inglés.


Adjudicación del contrato: se establece un acuerdo contractual con elproveedor y se formaliza mediante la firma de las partes interesadas, lo cualda lugar al inicio formal del desarrollo del producto especificado.

3.4. EjecuciónLa fase de ejecución contempla la etapa de desarrollo del sistema y requiere

la participación activa del cliente y es necesario ejecutar el plan de control de lacalidad. Este plan recibe como entrada los elementos del plan de aseguramientode la calidad y se encarga de realizar la evaluación de criterios medianterevisiones, auditorias e inspecciones (véase la figura 2). Estas evaluaciones serealizan en todo el ciclo del desarrollo del sistema para asegurar un producto decalidad (IEEE Computer Society, 2014) y comprenden:

Revisiones de administración: se encargan de monitorear el progreso delproyecto, y del cronograma, y la efectividad de la gestión del proceso dedesarrollo realizando comparaciones con lo planificado.Revisiones técnicas: se encargan de realizar una evaluación del producto conbase en las categorías de evaluación definidas y verificación de acuerdo conlas métricas establecidas.Evaluación de técnicas estáticas: son responsables de examinar ladocumentación (requerimientos, diseño y modelo, entre otros aspectos) yel código fuente del software sin proceder con su ejecución.Evaluación de técnicas dinámicas: determinan el cumplimiento de lasmedidas o niveles de calidad deseados del software, ejecutando el códigoprevio a realizar el lanzamiento.

3.5. Administración de la relaciónLa administración de la relación con el proveedor enfoca sus esfuerzos en

la participación de los interesados del proyecto y la empresa proveedora paramaximizar la presencia de los usuarios finales en el equipo de desarrollo, con elfin de alcanzar mayor entendimiento, compresión y solución de las necesidades(véase la figura 3). Además, contempla realizar evaluaciones del avance delproyecto mediante el uso de herramientas colaborativas y representacionesgráficas de cumplimientos de tareas para reducir las distancias físicas, culturalesy de idioma, y acercar a los participantes del cliente y el proveedor. Esta fasese encarga de gestionar los posibles problemas que se puedan presentar porcambios o diferencias de criterios durante el desarrollo del proyecto. Las tareasque sustentan esta fase son las siguientes:

Efectuar el plan de gestión de comunicaciones: se recomienda llevar acabo las actividades del plan de gestión de comunicaciones, gestionar lasreuniones, comunicación y participación activa de los interesados e involucrara los usuarios en el proceso de desarrollo, así como desarrollar las siguientesactividades de apoyo:


Figura 2: Diagrama de gestión de calidad

Maximizar la presencia física de los interesados o usuarios finalesen el equipo de desarrollo, para lograr mayor cumplimiento de losrequerimientos, proporcionar retroalimentación y resolver ambigüedadesen los requerimientos.Efectuar por lo menos dos reuniones formales a la semana, siempre ycuando las ubicaciones físicas del cliente y el proveedor lo permitan,contemplando una reunión presencial y otra virtual entre los interesadosy el equipo de desarrollo para solucionar inconvenientes, verificarlos avances, el cumplimiento de objetivos, así como de los acuerdosalcanzados con base en las sesiones anteriores y responder inquietudes.Cuando no sea posible realizar reuniones físicas semanales entre losinteresados y el equipo de desarrollo debido a limitaciones geográficaspor la ubicación de los equipos en diferentes localidades, es necesarioajustar el número de reuniones físicas para que sea requerido realizar almenos una reunión al mes y efectuar por lo menos una reunión virtuala la semana.Obtener información de las direcciones de contacto del proveedor comogrupos de correos electrónicos, números de teléfono de los encargados,direcciones de contacto para realizar videoconferencias e información delas reuniones presenciales.


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

Es importante que los mensajes que se intercambien sean concretos,coherentes, completos, claros, concisos y correctos, sin importar el mediode comunicación que se utilice.Representar de forma visual el flujo de trabajo es una de las mejoresopciones y formas de mantener la comunicación. Por lo que se recomiendausar un tablero de Kanban para que ambas empresas de manera visualpuedan observar cuáles son las labores que están pendientes, cuáles seestán ejecutando para preparar y efectuar las evaluaciones de calidad,así como cuáles están en proceso de pruebas o completamente listas.Utilizar herramientas de trabajo colaborativo para la comunicación entrelas organizaciones (chats y correos electrónicos), gestión del conocimiento(wikis, gestión de notas, gestión de fotos, almacenamiento en línea,ediciones colaborativas, publicación de documentos y presentaciones) yla gestión del proyecto (control del calendario, seguimiento de reuniones,eventos, controlar los hitos, las tareas pendientes, herramientas deresponsabilidades y distribución del trabajo). Además, es importanteelaborar mapas mentales y tableros colaborativos, por ejemplo, mediante


el uso de conceptboard para la inclusión de comentarios y notas ocorkboard para incluir notas a los participantes del proyecto.

Informar el desempeño del proveedor: se encarga de recopilar y distribuirinformación de desempeño, por lo que se puede comparar el cumplimientode los requerimientos para comprender y comunicar el avance, el desempeñoy el cumplimiento del proyecto mediante el análisis de curvas de eficiencia,además de analizar indicadores con respecto al cronograma, costos, calidad,trabajos completados, pendientes, estado de los incidentes y riesgos.Si existen brechas entre lo alcanzado y lo esperado, es necesario analizar lasrazones por las cuales se presentan y comunicarse con el proveedor para quesuministre los planes de acciones correctivas que le permitan cumplir contodas las metas y entregables del proyecto.

Presentar los hallazgos: los informes de desempeño y la participación delos interesados en el proceso permiten realizar revisiones de incidentes,problemas, retroalimentación u oportunidades de mejora, las cuales esnecesario comunicar, controlar y brindarles seguimiento para asegurar suresolución satisfactoria.

Identificar afectaciones: en conjunto con los interesados, es necesarioidentificar cambios importantes que puedan afectar el servicio durante lasiguiente fase de ejecución del proyecto, así como los cambios que provocaronincidentes.

Evaluar aspectos ajenos al proceso: esta tarea se encarga de evaluar loseventos clave que requieren atención especial por parte del proveedor.

Gestionar la resolución de conflictos: tiene por fin solucionar lasdiscrepancias de puntos de vista, renegociar aspectos necesarios conbase en hallazgos presentados y administrar variaciones por cambios nocontemplados que alteren el alcance de los objetivos del proyecto.

3.6. Aceptación y cierre

Esta fase hace énfasis en la recepción por parte del usuario e interesados delos entregables parciales y finales para evaluarlos con base en los criterios deaceptación acordados, los cuales deben estar alineados con las características decalidad planificadas y las pruebas de evaluación. Las tareas básicas de esta fase(Erazo-Paruma et al., 2014) son las siguientes:

1. Recibir la entrega parcial o final del sistema, realizar las pruebas al sistema,valorar los resultados y tomar en cuenta los criterios de aceptación para elcumplimiento satisfactorio del producto.

2. Cuando en el proceso de pruebas se identifiquen no conformidades, realizarel reporte para proceder con las correcciones necesarias, en caso contrario,proceder con la aceptación del entregable.

3. Administrar los contratos y facturas canceladas o pendientes de pago parael proveedor.

4. Confirmar al final del proyecto que todos los entregables sean aceptados.


5. Al cerrar las adquisiciones, proceder con la conclusión del contrato,evaluación general del proveedor y el registro de experiencias aprendidaspara utilizarlas en futuros proyectos.

3.7. ReconsideraciónLa fase de reconsideración corresponde a una evaluación con base en la

experiencia e información suministrada durante el desarrollo del proyecto, yconsidera efectuar las siguientes actividades:

1. Realizar revisiones del servicio, alcance y contratos de forma anual, paracompararlos con las necesidades actuales del negocio y asegurar que se brindeun verdadero valor de retorno a la inversión o realizar los cambios y ajustesnecesarios para alinearlos a los objetivos estratégicos.

2. Cuando el proveedor lleva a cabo su trabajo de acuerdo con los niveles delservicio y el cumplimiento de criterios y evolución del proyecto, pero existeuna percepción de insatisfacción final, verificar el ajuste de las métricasde evaluación debido a que puede ser la consecuencia de una inapropiadadefinición de los criterios en la planificación.

3. Reconsiderar continuar o cambiar de proveedor (en caso de incumplimientoscomprobados y verificables), y evaluar el impacto del costo que esta decisiónpueda provocar a la empresa contratante.

4. En los escenarios donde el proveedor cumpla con sus funciones correctamentey tanto los acuerdos de nivel de servicio y los tiempos de verificación seancumplidos de forma satisfactoria, pero se comprueba que el desarrollo de estetipo de sistemas no agrega valor al negocio o retorno de la inversión, se puedeconsiderar realizar el backsourcing, que consiste en reintegrar el procesotercerizado a lo interno de la empresa, si se cuenta con las capacidadessuficientes. Sin embargo, es importante evaluar el impacto en costos yrecursos que esta operación pueda significar para la organización.

La figura 4 presenta de manera visual las fases definidas para la gestión deterceros durante los procesos de desarrollo de software. En esta figura se puedennotar en primera instancia los roles mínimos que se consideran necesarios para eldesarrollo de cada una de las fases. Esta metodología individualiza las entradasy subprocesos y define las salidas que se espera obtener.

Como se mencionó, la fase de administración de la relación no es una fasede ejecución secuencial, debido a que contiene las fases de ejecución, aceptacióny cierre y reconsideración. Adicionalmente, en el diagrama se hace referencia ala utilización de una base de datos para almacenar datos relacionados con lagestión, evaluación del proveedor y experiencias aprendidas durante el proyectoo proyectos previos.

Metodología

parala

gestiónde

tercerosen

procesosde

desarrollode

software

19

Figura 4: Diagrama propuesto de gestión de terceros para el desarrollo de software


4. Conclusiones y trabajos futuros

La gestión de las relaciones con terceros es un elemento crítico cuandose realiza la contratación de proveedores para el desarrollo de sistemas desoftware,por lo que este trabajo contempló la elaboración de una metodologíapara realizar la gestión adecuada de un proyecto de tercerización.

La metodología es una síntesis de los procesos y mejores prácticas que debencontemplarse en la gestión de terceros y resume aspectos fundamentales sobre lasfases, tareas y salidas que se esperan en cada una de las etapas de un proyectode esta naturaleza. Por lo tanto se espera que sea una herramienta útil paraorientar y brindar una visión general a los especialistas, de los aspectos quedeben contemplar durante la planificación y desarrollo de proyectos de softwarecontratados a terceros.

La incorporación de aspectos como la planificación de la administración dela relación con los proveedores, la gestión de la comunicación y el aseguramientode la calidad durante todo el proceso, desde la concepción del sistema hasta suaceptación, son los elementos de mayor relevancia en la metodología, debido asu transcendencia para el éxito del desarrollo de sistemas de calidad.

Cabe resaltar que una de las virtudes de la metodología desarrollada es lasíntesis visual que ofrece del proceso, lo cual brinda un panorama claro de la rutay actividades que se pueden considerar. Esto tiene por fin facilitar la comprensióndel proceso, y la comunicación con la gerencia, y mejorar la aplicación delproceso.

Como trabajo futuro se recomienda evaluar el uso de herramientascolaborativas y de gestión de proyectos, e identificar las mejores opcionesdisponibles para ser integradas en un proceso de tercerización. Además, tambiénse recomienda desarrollar una metodología que contribuya con el correctolevantamiento de requerimientos para el desarrollo de sistemas, tomando encuenta la participación activa de usuarios e interesados.

Referencias

CabinetOffice. (2011). ITIL service strategy (segunda ed.).CENDITEL, Fundación. (2013). Aseguramiento de calidad en el desarrollo de

software libre. Venezuela.Erazo-Paruma, L. R., Guerrero-Mera, G. L. y Correa-Pino, F. J. (2014). Método

para la adquisición de software en pequeñas organizaciones. Revista UISIngenierías, 13 (1).

Franceschini, F., Galetto, M., Pignatelli, A. y Varetto, M. (2003). Outsourcing:guidelines for a structured approach. Benchmarking: An InternationalJournal , 10 (3), 246–260.

Grossi, L., y Calvo-Manzano, J. A. (2012). Mejora de procesos en el Ámbitode adquisición: Un modelo de decisión para la selección de proveedores deti. CISTI (Iberian Conference on Information Systems & Technologies /

Referencias 21

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

IEEE Computer Society. (2014). SWEBOK, guide to the software engineeringbody of knowledge. Descargado de https://www.computer.org/web/swebok

McIvor, R. (2005). The influence of transaction cost economics and the resourcebased view on the outsourcing process. En Sixteenth Annual Conferenceof POMS, Chicago.

Mendoza, L. E., Pérez, M. A., Grimán, A. y Rojas, T. (2002). Algoritmo para laevaluación de la calidad sistémica del software. En Proceedings of SecondIbero-American Symposium on Software Engineering and KnowledgeEngineering (JIISIC’02), Salvador, Brasil, octubre, 2002 (pp. 85–96).

Mendoza, L. E., Pérez, M. A. y Grimán, A. C. (2005). Prototipo de modelosistémico de calidad (mosca) del software. Computación y sistemas, 8 (3),196–217.

Perunović, Z., y Pedersen, J. L. (2007). Outsourcing process and theories. EnProceedings of the Eighteenth Annual Conference (POMS), 4 a 7 de mayo,Dallas, Texas, 2007 (Vol. 3).

Project Management Institute, I. (2013). Guía de los fundamentos para ladirección de proyectos (guía del PMBOK®) (quinta ed.). Autor

Selleo. (2016). A practical guide to outsourcing your software development.Descargado 09-08-2016, de http://selleo.com/wp-content/uploads/2014/08/software-outsourcing-guide.pdf

Gestión de la relación con terceros ymetodologías ágiles

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


ULACIT, Urbanización Tournón, 10235-1000San José, Costa Rica [fchavess976,dmoras530]@ulacit.ed.cr

[email protected]∗


Resumen La tercerización del desarrollo de software es una prácticacomún entre muchas empresas. Sin embargo, con frecuencia el resultadofinal no satisface las necesidades del cliente debido a la malacomunicación, creación de falsas expectativas, deficiente transferenciadel conocimiento, la inadecuada definición del alcance del proyecto yel escaso involucramiento del cliente. A lo anterior se debe agregarque los modelos y estándares más utilizados no contemplan detallessobre la forma en que se puede gestionar la relación que establecen losclientes y proveedores. Como consecuencia, el objetivo de este trabajo deinvestigación es proponer un modelo que sirva como guía para apoyar lagestión de las relaciones con terceros, utilizando como base los principiosde las metodologías ágiles más importantes, las cuales contemplan el usode microciclos y la constante comunicación con los usuarios y clientes.

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

1. IntroducciónEl creciente y rápido cambio de la tecnología trae diversos y complejos retos

a las empresas para llevar a cabo de manera eficiente y eficaz sus procesos denegocios, lo cual requiere la constante evolución de los servicios y productos queofrecen las compañías. Esto implica que deben contar con personal capacitadopara enfrentarse a esos retos y mantenerse en el mercado. Pero, en ocasiones,ante la ausencia de ese personal, se enfrentan a problemas presupuestarios alimplementar nuevas tecnologías, por los problemas que se originan en la malagestión y deficiencias técnicas. Por esa razón, la tercerización ha sido vista comouna posible solución para mejorar la capacidad de respuesta de los negocios ysu estructura de costos.

En los últimos años la tercerización ha crecido de forma considerable y se haexpandido de manera rápida para brindar servicios de toda índole, incluyendodesarrollo de software, soporte técnico, reclutamiento de personal, finanzas ycontabilidad, entre otros.

Gestión de la relación con terceros y metodologías ágiles 23

En la actualidad la tercerización de desarrollo de software es de alta relevanciay muy popular; países como India y China son grandes exponentes de estatendencia. Sin embargo, el número de casos donde el producto no se entregaa tiempo es elevado, el intercambio de información entre las partes es deficientey no se cumple con la mayoría de los requerimientos establecidos. En algunoscasos las causas son las barreras culturales y de idioma, un inadecuado controlde los procesos dentro del ciclo de desarrollo del software, la mala comunicación,la falta de participación activa de los clientes y la creación de falsas expectativas.

El objetivo de este trabajo de investigación es preparar una guía demejores prácticas, tomando como base los principios de las metodologíaságiles. El fin de esta guía es contribuir con la disminución de los efectosnegativos de la tercerización de desarrollo de software y facilitar la adecuadacomunicación, transferencia de conocimiento, establecimiento de expectativas yel entendimiento y control entre los clientes y los proveedores.

2. Estado del arteLa tercerización consiste en el traslado de la ejecución de parte de los procesos

del negocio a otra empresa, la cual cuenta con la especialización y capacidadespara desarrollar dicha actividad como un servicio a más bajo costo y de formamás eficiente que la empresa contratante. La tercerización se ha convertido paramuchas compañías en una solución práctica para mejorar su funcionamiento.Los procesos que se transfieren no forman parte del núcleo del negocio, noson esenciales ni críticos, aunque en algunos casos documentados (Girotra yNetessine, 2012) se ha evidenciado que estos también son transferidos a tercerasempresas.

La tercerización suele confundirse con la subcontratación, subcontratacióninternacional y externalización al extranjero, los cuales funcionan de formadiferente:

Subcontratación: consiste en que parte del trabajo se transfiere a otra empresala cual contrata a otra que tiene habilidades o recursos que le permitenrealizar tareas claramente especificadas en especiales y mejores condiciones(Dolgui y Proth, 2013).

Subcontratación internacional: cuando una compañía trasladacompletamente sus procesos de negocio a otro país distinto al de origen, sehabla de subcontración internacional. Esta situación es relativamente raraya que es arriesgada (Dolgui y Proth, 2013).

Externalización al extranjero: la empresa contratada se encuentra en unpaís diferente al de la empresa que contrata. Así que la localización diferenciael concepto (Dolgui y Proth, 2013).

Debido al auge de la tercerización, muchas compañías buscan comoimplementarlo en sus negocios. Estas empresas investigan qué beneficios lespuede traer y qué impacto tiene. Esta metodología trae consigo diversosbeneficios y puede mejorar el valor de la firma del cliente de muchas maneras,

24 Chaves et al.

como por ejemplo el acceso a la base de la competencia. Recientes investigacionesencontraron que la reducción de costos se sitúa en la posición más alta entre otrosbeneficios de la tercerizacion (Kakumanu y Portanova, 2006; Bersin, 2005).

Por otra parte la tercerización trae consigo algunas desventajas como lassiguientes:

El dilema de la competencia: se genera cuando el cliente y el vendedorestablecen entre si una relación estrecha, donde el flujo de información esvasta y se comparte información de los procesos centrales del negocio. De estamanera el vendedor con todo este conocimiento estará listo para competircon el cliente (Kakumanu y Portanova, 2006).

Pérdida de la iniciativa por el cliente: el cliente genera una elevadadependencia del vendedor, limitando su libertad de acción, los costosgenerados por el vendedor pueden llegar a ser altos, pero debido a ladependencia no se puede prescindir de estos.

La tercerización fuera de las fronteras a países desarrollados: segenera cuando un producto o una parte del producto se soluciona através de la tercerización en otro país y este por consecuencia terminasiendo más barato. Esto causa que una vez que el producto se venda,tendrá repercusiones en el mercado para compañías locales, las cuales nopodrían “competir” con dichos precios.También, si la misma compañíafabrica productos similares pero de manera local, se verán afectados por losproductos que fueron tercerizados.

La tercerización de software trae consigo diferentes problemas, esto causa quealgunos proyectos no sean exitosos. Diversas investigaciones han determinado quelos problemas más comunes son la mala comunicación, la ausencia del clientedurante el proyecto y la generación de falsas expectativas. Al respecto, existe ungran número de casos en los cuales los procesos no han sido exitosos. Sobre esteparticular, KPMG, Dreischmeier y Deloitte han observado diferentes aspectospor los cuales la tercerización no ha funcionado como se desea, entre los que seencuentran los objetivos, la relación entre el cliente y el proveedor, la calidaddel servicio, los problemas de comunicación y la mala gestión (Sáenz, Cámara,Calvo-Manzano y Arcilla, 2014).

El análisis de los procesos de tercerización muestra que en múltiples ocasiones(Bersin, 2005) falta:

Comunicación: frecuentemente las partes que intervienen en los procesos detercerización se excluyen mutuamente de la comunicación. No intercambianinformación constante de avances o dudas que se generan; se basan solo enuna reunión inicial; y pocas veces se reúnen para revisar, clarificar, preguntar,y redefinir tanto aspectos técnicos como de gestión en relación al proyecto.

Transferencia del conocimiento: la información generada por el proveedorno se transmite de manera adecuada al cliente. Si bien es cierto que seentrega documentación como manuales técnicos y de usuario, esto no essuficiente, porque durante el desarrollo del proyecto, pudieron existir diversos


escenarios que recibieron atención específica, además de complicaciones quese resolvieron con ideas innovadoras, y todo esto se traslapa con los manualesantes mencionados.

Definición del alcance y expectativas: se puede decir que el alcance de unproyecto es en ocasiones difícil de definir y a raíz de este alcance se generanlas expectativas del proyecto. Cuando no existe una adecuada comunicaciónestos dos aspectos pueden variar, y los resultados no cumplen completamentelos requerimientos planteados.

Seguimiento y participación activa del cliente: el cliente se reúne con elproveedor, definen el contrato, se levantan requerimientos y se presenta unposible diseño previo.Todo lo anterior se realiza al inicio del proyecto, despuésde esto el cliente no se entera de los siguientes procesos, y en la fechade finalización del proyecto, después de mucho tiempo sin comunicación seinforma que el proyecto está finalizado, o por el contrario que el proyectoestá atrasado y el cliente no sabe la razón de esto. Lo anterior sucede debidoa que el cliente no tiene un control real en el seguimiento del proveedor y,además, no está involucrado de manera eficaz ni dominante.

Debido a que el enfoque de esta investigación se basa en los principios dediversas metodologías ágiles, es importante mencionar cuál es su relación conla tercerización. Las metodologías ágiles nacieron enfocadas al desarrollo desoftware, pero con el paso del tiempo se comenzaron a utilizar en otro tipode proyectos. Sin excepción, toda metodología ágil se basa en los principios del“Manifiesto ágil” (Beck et al., 2001). Las metodologías ágiles buscan que losprocesos sean más eficientes y eliminar aquellos que son innecesarios, es poresto que se considera que estas metodologías podrían dar un gran aporte a lasrelaciones con terceros.

Las metodologías ágiles buscan flexibilidad y efectividad cuando se desarrollaun proyecto de software o de otra índole. Se realizan iteraciones incrementalesconocidas como Sprint, las cuales comprenden dos semanas y consisten en ciclosde desarrollo, revisión, retroalimentación, aprobación y ajuste, y tienen comoobjetivo generar un entregable tangible al finalizar el ciclo. Las diferencia enrelación con otras prácticas es la posibilidad de generar cambios durante el ciclodel proyecto, sin afectar de manera agresiva su proceso.

Otro aspecto importante que se debe tomar en cuenta es la continuavisibilidad y comunicación que existe entre clientes, usuarios y desarrolladorespara asegurar el éxito y rumbo del proyecto.

En la actualidad existe una gran diversidad de metodologías ágiles, paradiferentes tipos de proyectos y necesidades. Las metodologías que se estudian acontinuación fueron elegidas debido a las buenas prácticas, guías y consejos quebrindan y que se ajustan al objetivo de esta investigación. A continuación semuestra un resumen con la información más relevante de cada una de ellas.

Programación externa: Esta metodología se basa en cuatro aspectos:comunicación, simplicidad, retroalimentación y coraje. Esta metodologíabusca que todo se realice de manera sencilla, para una mejor comprensión,manteniendo al cliente altamente informado de lo que sucede.

26 Chaves et al.

Scrum: Scrum es una metodología que se basa en iteraciones dividiendo elproyecto en partes, donde se realizan entregas incrementales al cliente,basandose siempre en buenas practicas.

Crystal: Crystal es una familia de metodologías, ocho en total, las cuales sebasan y tienen en común los siguientes aspectos:

Frecuentemente entregados.Mejoramiento reflexivo.Comunicación cercana.Seguridad cercana.Concentración.Fácil acceso a usuarios expertos.

Estas familias funcionan con base en el tamaño y el nivel de criticidad delos proyectos, según sea el nivel de estos, así una familia u otra podrá serimplementada.

Lead Development : Esta metodología tiene como característica el ser más unafilosofía que un proceso de desarrollo. Se basa en algunas buenas prácticas ybuenos principios debido a su naturaleza. Ejemplo de ellas son: satisfacer alcliente es la máxima prioridad, todo se puede cambiar, una solución al 80%hoy, en vez de una al 100% mañana.

Los puntos claves que se analizaron sobre estas metodologías se muestran deforma resumida en el cuadro 1.

Metodología ágil Puntos clavesProgramaciónextrema

Lanzamientos pequeños y frecuentes.Reuniones cortas todos los días.Proyecto dividido en iteraciones.

Scrum Requisitos de proyecto presentados enbloques de tiempo cortos.El avance se muestra al cliente al final decada iteración.

Crystal Entregas frecuentes.Acceso a usuarios finales expertos.Comunicación cercana.

Lead development La satisfacción del cliente es la prioridad.Activa participación del cliente.Brindar soluciones generales y no especificas.

Tabla 1: Cuadro resumen de metodologías ágiles.


3. Gestión de proyectos y metodologías ágiles

Figura 1: Gestión de proyectos de tercerización con metodologías ágiles.

La figura 1 muestra la propuesta de un proceso para la tercerización deldesarrollo de software. La propuesta se divide en las siguientes etapas:

Definición de requerimientos: es la primera etapa del proceso, se emplea unmarco de referencia denominado Design Sprint, el cual tiene como objetivoreunir las partes claves en el proyecto, tanto del lado del cliente como delproveedor, para crear un prototipo y definir los requerimientos iniciales delproyecto, eliminando los problemas de comunicación en esta fase.

Iteraciones: en esta fase se inicia un ciclo que incluye diferentes procesos hastaque el producto esté terminado y sea aprobado por el cliente. Las etapas quecomprende son las siguientes:Ciclos de desarrollo: estos ciclos están a cargo de los desarrolladores de

software, y comprenden la parte de carpintería del proyecto en la cual seescribe el código.

Revisión del dueño del producto: el dueño del producto es quien estáa cargo de los resultados de los desarrolladores y es quien se encarga degestionar a los interesados, por lo que en esta fase se toma la tarea derevisar el producto de la fase anterior.

Retroalimentacion: después de pasar por el desarrollo y su aprobaciónse realiza una reunión rápida con los involucrados para hablar sobrelos avances en el proyecto, qué se debe mejorar y cuáles son las tareasque se deben realizar, así como los posibles cambios a la planificación.Esta etapa busca impulsar la interacción continua entre los clientes y losinvolucrados en el proyecto.

Aprobación del cliente: en esta fase el cliente define si el proyecto estálisto para su lanzamiento o se debe continuar con otra iteración.

28 Chaves et al.

Ajustes: es la ultima fase de la iteración y en esta se determinan los ajustesque se deben realizar en el proyecto para continuar con la siguienteiteración.

Lanzamiento: se realiza la entrega del producto final al cliente.

4. Guía de mejores prácticas para la tercerizaciónde software

El uso de los elementos claves de las diferentes metodologías ágiles esun excelente punto de partida para elaborar una guía que le proporcione alcliente una herramienta para ayudarle a asegurar la finalización exitosa de unproyecto. Con base en esto, a continuación se presenta dicha guía, tomando encuenta la comunicación, trasferencia de conocimiento, definición del alcance yexpectativas, el seguimiento de las tareas y la participación activa del cliente.

4.1. ComunicaciónLa comunicación es un factor clave entre el cliente y el proveedor (Bersin,

2005). Sin embargo, esta no suele ser gestionada de manera correcta, por lo quese propone realizar:

Reuniones constantes: El cliente debe crear un cronograma donde seestablezcan reuniones constantes con el proveedor. Estas reuniones debenprogramarse de acuerdo con la conveniencia de ambas partes y pueden servirtuales para evitar el traslado del personal. La frecuencia debe ser menora 15 días, porque que se considera que no es prudente revisar resultados yavances en ventanas de tiempo mayores. Se recomienda que la duración delas reuniones no sea mayor de 30 minutos si solo se presentan actividades degestión. Pero las reuniones pueden extenderse más si es necesaria la discusión,presentación y prueba de algún prototipo.La documentación de las reuniones se puede realizar de diferentes maneras,como las siguientes:

Grabación tanto de vídeo como de audio.Minutas o herramientas que utilice la empresa para documentar.El cliente puede enviar un correo electrónico con la minuta de los puntosrevisados en la reunión.

Reuniones personales: Las reuniones virtuales son un punto clave parala comunicación, pero se recomienda realizar reuniones personales. Estasreuniones son de gran valor para la discusión de ideas del cliente y elproveedor, y son de utilidad para presentar diseños en papel, interpretarreacciones de las personas y probar prototipos.Se recomienda realizar las reuniones personales en un lugar en que losparticipantes puedan tener acceso a las herramientas necesarias paradesarrollar la sesión (computadoras, Internet, papel, lápices, pizarras,marcadores). Esto proporcionará un ambiente donde se puedan clarificar


o remarcar aspectos que no estén completamente definidos, incluso elproveedor puede sacar ventaja de estas reuniones para mostrar ideas odiseños que puedan surgir durante el proyecto.Estas reuniones se pueden realizar para discutir el avance actual y lospuntos importantes pendientes, así como cada vez que se produzca un avanceimportante en el desarrollo (iteración).Este tipo de reuniones puede ser documentada con:

Herramientas de documentación.Minutas.Grabación con cámaras en la sala de reunión.Escaneo del material que se genere en la reunión para compartirlo yarchivarlo de forma digital.

Reportes: Las reuniones tanto virtuales como personales, son sumamenteenriquecedoras, pero cuando no se cuenta con material suficiente, o esnecesario informar sobre algún suceso antes de la fecha establecida, útil usarreportes con información breveEsos reportes pueden, dependiendo en la cantidad y valor de la información,sustituir una posible reunión, si esto es aceptado por el cliente.

4.2. Trasferencia de conocimiento

Otro de los problemas más comunes cuando se contrata a un tercero parael desarrollo de software, es que el conocimiento no se transfiere al cliente dela manera adecuada. Por ejemplo, el conocimiento que se adquiere durante larealización del proyecto, solamente queda en manos del proveedor, por lo que esimportante considerar un plan que fomente la cooperación entre ambas partespara compartir información.

Para realizar la transferencia de conocimiento se sugiere la implementaciónde tres conceptos que introduce ITIL en sus buenas prácticas para el manejo deinformación:

Base de conocimiento: uso de una base de conocimiento1 para almacenarinformación sobre la resolución de problemas recurrentes, datos relevantessobre sistemas de información internos y el uso de metodologías. Estetipo de base de datos se suele integrar con un sistema de gestión delconocimiento, el cual se encarga de proporcionar detalles a los usuariosfinales de manera eficiente. Además proporciona una vía para que los usuariosgeneren conocimiento basado en su experiencia con el proyecto.Se recomienda utilizar el sistema de gestión del conocimiento paradocumentar la información relevante que se genere durante el desarrollo y quepueda ser útil en el futuro para realizar modificaciones, implementaciones ysolucionar problemas del sistema.La generación de conocimiento puede derivarse de diversas formas y debendocumentarse por medio de una herramienta de este tipo:

1 Conocida en inglés como Knowledge Base (KB).

30 Chaves et al.

Errores del sistema y su solución: durante las pruebas del sistema,podrían generarse errores que son producto de la propia naturaleza delsoftware, por lo cual son resueltos de manera especifica, y tanto el errorcomo la solución deben ser documentados.

Complejidad: los sistemas se componen de varios módulos que nofuncionan de la misma forma, por lo que los procedimientos para elmanejo de la programación o mantenimiento de un módulo debendocumentarse.

Versiones del software: cada versión del sistema evoluciona de acuerdocon el avance del proyecto; si existen aspectos que cambian radicalmenteo que son fundamentales en la herramienta y son cambiados de unaversión a otra, estos deben ser registrados.

Otros: pueden existir muchos aspectos que el cliente o proveedor considerenque deben ser documentados, y que deben establecerse de maneraconjunta para que sea realizado de manera correcta. Entre las opcionesdisponibles se encuentran las siguientes:

Soluciones en el mercado:Novo SolutionsKBPublisherXWiki

CMDB2: es una herramienta que tiene como objetivo el manejo eficiente de losservicios y activos, que están conformadas por elementos de configuración3.

Soluciones en el mercado:CherwellServicenowCMDBuild

DSL (Biblioteca definitiva de software)4: se refiere a un repositorio centralde software para gestionar imágenes de software con sus distintas versionesautorizadas, documentación, componentes aprobados por los desarrolladores,licencias y otra información relevante.

4.3. Definición del alcance y expectativasEl alcance del sistema debe ser definido por el cliente de forma inicial y tiene

que ser comunicado al proveedor para tener claros los límites del proyecto.Las expectativas que se generan entre las partes involucradas tiene su origen

en la definición correcta del alcance, el cual cuando es definido de formaincorrecta se convierte en un grave problema para la tercerización de software(Smuts, van der Merwe, Kotzé y Loock, 2010).

Reuniones de diseño

Es importante establecer desde un inicio, de forma clara y eficiente, lo quese espera del proveedor, por lo que se deben realizar reuniones de diseño, en las3 Los elementos de configuración son conocidos en inglés como configuration items.


cuales se puede usar como referencia el marco de trabajo denominado DesignSprint. Este marco de trabajo permite diseñar soluciones a problemas en un lapsode dos a cinco días, y además permite la contribución de diversos participantesen el proceso, a la vez que facilita la comunicación y claridad a la hora de definirlas ideas.

El concepto de este marco de trabajo fue tomado de las metodologías ágilesy adaptado por Google. En la actualidad el marco de trabajo utiliza un procesoque 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 elnegocio o proceso que se pretende mejorar, además de una investigaciónsobre el mercado actual y las capacidades tecnológicas.

Definir: se determinan las características que el sistema debe tener y se lespide a los usuarios que definan con tres frases cómo les gustaría que fuese elsistema; además, en esta etapa se crean historias sobre la interacción de unusuario con el sistema.

Divergir: se les pide a los usuarios que dibujen ocho ideas en cinco minutossobre el sistema, además de realizar una historieta sobre una de sus ideas.

Decidir: se discute y decide sobre cuáles ideas podrían resultar útiles para elsistema y a partir de estas se genera la discusión sobre las características deun prototipo.

Prototipo: se implementa un prototipo y se obtiene retroalimentación de losusuarios expertos.

Validar: el prototipo es probado por los usuarios, a quienes se les hace una seriede preguntas sobre lo que piensan acerca de los prototipos.

Al finalizar estas fases se cuenta con los requerimientos iniciales y la definiciónde los sprints para las reuniones de diseño. Cabe destacar que al final de cadaetapa se debe realizar un resumen con los resultados, los cuales deben serdocumentados. Además, se recomienda que el equipo de trabajo esté formado pordiseñadores, ingenieros, gerentes de proyecto, expertos y el maestro de sprint5.

4.4. Participación activa del clienteEl cliente debe estar informado sobre lo que ocurre en el proyecto, pero

también debe participar de forma activa. Esto se convierte en un punto clave,porque el cliente debe trabajar con el proveedor de forma constante, dandoseguimiento a los avances, problemas y resultados.

Pruebas con usuarios expertos

En las diferentes reuniones se pueden realizar pruebas que le permitan alcliente observar el estado del producto. Pero se recomienda que estas pruebas no5 El maestro de sprint es la persona encargada de diseñar los retos para cada etapadel sprint.

32 Chaves et al.

sean realizadas solo por el proveedor, sino que los usuarios expertos del clientelas realicen.

Algunos de estos usuarios expertos también deben participar en las reunionesvirtuales y presenciales, porque son quienes utilizarán el sistema una vez que estéfinalizado.

Con el fin de que los usuarios expertos formen parte de las sesiones de pruebade manera efectiva, se recomienda que el proveedor cree y facilite documentosde control como:

Lista de control6: este documento consiste en una lista de puntos que elusuario debe evaluar, marcando o dejando vacío el punto correspondiente.

Evaluar cumplimiento de requerimientos: este documento detalla losrequerimientos que se deben evaluar. El usuario debe indicar si elrequerimiento ha sido cumplido o no, con base en los requerimientos inicialesy las expectativas.

Documento de observaciones: En este documento el usuario tiene completalibertad para exponer sus observaciones con respecto al módulo que se hayaprobado.

El usuario podrá dar su opinión detallada o más directa dependiendo deldocumento, acerca del avance, lo cual servirá como retroalimentación para elproveedor.

En estas pruebas el proveedor es un guía y no debe influir en el usuario sobrecómo utilizar el sistema. El proveedor no debe indicar acciones que conduzcanal usuario por una ruta determinada, y el usuario debe ser quien decida quécaracterísticas utilizar. Esto es la clave para generar retroalimentación de valorpara el proveedor.

5. Discusión y conclusionesLos problemas que han sido mencionados en este trabajo de investigación

son conocidos por la mayoría de gerentes y administradores relacionados conlos procesos de contratación del desarrollo de sistemas de software. Sin embargo,estos problemas no han sido abordados con la amplitud y profundidad requerida.Lo anterior se puede deducir del análisis bibliográfico que se llevó a cabo y laconstante preocupación mostrada por los autores de los trabajos estudiados.

El análisis de la bibliografía ayudó a determinar que algunas de lasmetodologías ágiles que se utilizan de forma más frecuente, permiten gestionar larelación con terceros de mejor manera que como se lleva a cabo tradicionalmente.Sin embargo, es posible mencionar que en diferentes aspectos estas metodologíasno son eficientes. Por lo tanto, la guía propuesta tiene como fin combinar lasprincipales fortalezas en cuanto a la gestión de la relación con terceros de lasmetodologías que fueron analizadas.

La guía tomó en cuenta las características particulares de cada una de lasmetodologías, y fue elaborada con base en la evidencia del éxito que han tenidoen la práctica. La estructura de la guía es flexible ante las necesidades que pueda

Referencias 33

tener el cliente, debido a que la implementación de cada uno de los puntos noes obligatoria, porque el escenario de cada empresa no es el mismo. Así, cuandouna empresa tiene problemas de comunicación con el proveedor, puede tomaren cuenta las recomendaciones que se brindan para esa área. Si por otra parte,el problema al que se enfrenta la empresa tiene relación con la definición delalcance del proyecto, puede revisar este apartado e implementar los puntos quecorresponden a esa sección, y de forma similar para cada área contemplada enla guía.

Como consecuencia, la principal contribución de este trabajo consiste en lapropuesta de la guía para apoyar la gestión de las relaciones entre clientes yproveedores, aunque conviene mencionar que la validación práctica de dichoinstrumento queda pendiente como un trabajo futuro de investigación.

ReferenciasBeck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W.,

Fowler, M., . . . Thomas, D. (2001). Manifiesto por el desarrollo Ágilde software. Descargado de http://www.agilemanifesto.org/iso/es/

Bersin, J. (2005). Business process outsourcing: Pros and cons. Chief LearningOfficer , 4 (4), 34 - 40. Descargado de http://search.ebscohost.com/login.aspx?direct=true&db=buh&AN=16479531&lang=es&site=ehost-live

Dolgui, A., y Proth, J.-M. (2013). Outsourcing: definitions and analysis.International Journal of Production Research, 51 (23/24), 6769 - 6777.

Girotra, K., y Netessine, S. (2012, oct). Why apple has to manufacturein china. Descargado de https://hbr.org/2012/10/why-apple-has-to-manufacture-i

Kakumanu, P., y Portanova, A. (2006). Outsourcing: Its benefits, drawbacksand other related issues. Journal of American Academy of Business,Cambridge, 9 (2), 1 - 7.

Sáenz, J., Cámara, M. d. l., Calvo-Manzano, J. A. y Arcilla, M. (2014).Necesitan los proveedores de outsourcing una metodología para la provisiónde servicios?: Is it needed a methodology for outsourcing service providers?RISTI-Revista Ibérica de Sistemas e Tecnologias de Informação(SPE1),61–75.

Smuts, H., van der Merwe, A., Kotzé, P. y Loock, M. (2010). Criticalsuccess factors for information systems outsourcing management: Asoftware development lifecycle view. En Proceedings of the 2010 annualresearch conference of the south african institute of computer scientistsand information technologists (pp. 304–313). New York, NY, USA: ACM.Descargado de http://doi.acm.org/10.1145/1899503.1899537 doi:10.1145/1899503.1899537

Definición y modelado del proceso de gestión dela demanda para tecnología de información

David Rodolfo Camacho Quiros, Reagan Ching Fung,Julio Córdoba Retana y Antonio González Torres∗



[dcamachoq046, rchingf302, jcordobar022]@[email protected]∗


Resumen En la actualidad las organizaciones se ven en la necesidadde utilizar mejores prácticas y recomendaciones, por lo que se utilizanmarcos de referencia reconocidos y probados. Por esta razón es de sumaimportancia, identificar cuáles son las prácticas y marcos de referenciaque mejor se adaptan al giro de negocio de la organización, lo cual resulta,en muchos casos, en metodologías híbridas que extraen lo mejor de cadamarco. En el presente artículo se presenta un modelo híbrido del procesode gestión de la demanda. La definición de dicho modelo como resultadodel análisis y comparación de los marcos de referencia ITIL versión 3 yCOBIT versión 5.

Palabras clave: COBIT5, ITILv3, gestión de la demanda, gestión de lacapacidad

1. IntroducciónLas organizaciones realizan grandes inversiones en aplicaciones,

infraestructura y personal, con el fin de obtener ventajas competitivas enel mercado, optimizar procesos, obtener mayores utilidades económicas odisminuir los gastos en el corto o mediano plazo. De forma que para alinear ydisminuir las brechas que existen entre las áreas de negocio y las tecnologíasde la información (TI), las organizaciones necesitan implementar y mejorar losprocesos de gestión. Entre estos procesos se destaca la gestión de la demandade servicios de TI.

La gestión de la demanda de servicios de TI comprende desde las peticionesde soporte que entran en una mesa de asistencia, hasta la solicitud de nuevasaplicaciones o su modificación. Este proceso es el encargado de administrar ygarantizar la disponibilidad de los recursos o servicios que el área de TI brindaa la organización, por lo que su implementación inadecuada o ausencia, provocaque los proyectos de TI se vean impactados de forma negativa. Esto ocurre

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

cuando se carece de los recursos necesarios, debido a que los proyectos sufrenaumentos en los costos y la organización debe incurrir en el uso indiscriminadode recursos e incrementar el presupuesto de los proyectos para compensar losretrasos.

Para comprender el papel que desempeña la gestión de la demanda en lasorganizaciones, este trabajo ofrecerá una guía sobre cómo se puede llevar a cabosu implementación o mejora mediante la definición de un modelo de gestión dela demanda. De acuerdo con lo anterior, se realiza una evaluación de los marcosde referencia COBIT 5 e ITIL v3, con el fin de definir la gestión de la demanda,identificar los procesos y actividades pertinentes a la gestión de la demanda, ymodelar el proceso mencionado. La tabla 1 muestra los procesos de los marcosde referencia mencionados, que son tomados en cuenta para el desarrollo de estetrabajo.

Tabla 1: Procesos de marcos de referencia analizadosCOBIT 5 ITIL v3EDM04 - Asegurar la optimización de recursos Gestión de la demandaBAI04 -Gestionar la disponibilidad y capacidad Gestión de la capacidad

En síntesis, este trabajo de investigación busca identificar un proceso básico,que sirva como punto de partida para cualquier organización y como unaherramienta a nivel gerencial y operacional para la gestión del proceso de lagestión de la demanda.

2. Marco teórico

2.1. Gestión de la demanda

La gestión de la demanda es un proceso presente en todas las organizaciones,aunque no se encuentre identificado como tal o esté implementado de formaerrónea. En general, este proceso permite habilitar o poner en ejecución unrequerimiento del negocio, en donde se pueden tener varias fuentes que esténhaciendo la petición de dicho requerimiento, el cual puede ser sencillo o complejo.Según la frecuencia y el impacto que se tenga sobre el negocio, cada peticiónrequiere que se le asigne un nivel de prioridad.

En este contexto, las solicitudes de cuentas de correo electrónico para losusuarios nuevos de la organización son un ejemplo de la demanda de un servicio,que requiere tener en consideración la capacidad de los servidores y el ancho debanda de la organización.

La importancia de la gestión de la demanda radica en la consecución debeneficios para los usuarios y la empresa. Por lo que es necesario que se tenganen cuenta los pasos del ciclo de vida de la demanda, conforme con el nivel demadurez de la gestión de la demanda (Alonso, Caro y Verdún, 2008).

De acuerdo con lo anterior, los departamentos de TI que definen yadministran de forma correcta el proceso de gestión de demanda pueden mejorar

36 Camacho et al.

los servicios que ofrecen. Esto conlleva la necesidad de determinar el grado demadurez de dicho proceso y se recomienda el uso de ITIL v3 y COBIT 5.

Con respecto a la selección de un marco de referencia para la definición delproceso de gestión de la demanda, es fundamental conocer los tres tipos dedemanda existentes (Alonso et al., 2008):

1. Estratégica: Este tipo de demanda es gestionada a través del portafolio deproyectos y contempla la solicitud de nuevos programas para introducirla innovación, y activar nuevos negocios, productos y servicios. Además,representa una oportunidad para la organización debido a que se identificanlos objetivos estratégicos de cada unidad de negocio. Las solicitudes de estanaturaleza son analizadas, clasificadas y priorizadas, teniendo en cuenta suinfluencia en la toma de decisiones.

2. Táctica: Esta clase de demanda se gestiona por medio del portafolio deservicios. Su principal foco es el portafolio de servicio, que brinda su atenciónen el catálogo, para evaluar los flujos de trabajo y se ordena de acuerdo conlas prioridades de la organización, para efectos de aprobación y entrega.

3. Operacional: La demanda operacional es la que gestiona la construcción ymantenimiento de la infraestructura de TI y tiene como función velar porlos servicios, tanto de software como de hardware así como cumplir con losplanes de mantenimiento y actualización.

2.2. Marcos de referencia: COBIT e ITIL

COBIT es un conjunto de mejores prácticas que proporcionan un marcode trabajo con un enfoque táctico que está dirigido, principalmente, a losadministradores, gerentes, auditores y encargados o responsables del área deTI (Muñoz-Serna y Martínez-Arias, 2012). Además, este marco de referencia esutilizado como herramienta para satisfacer las necesidades del negocio y servircomo guía para los procesos y métricas de control.

COBIT versión 5 se compone de cinco dominios y treinta y siete procesosque buscan brindar una serie de normas para el uso eficiente de los recursos. Eneste punto es importante anotar que la aplicación de este marco de referenciaconlleva tiempo y esfuerzo, por lo que debido a las limitaciones de tiempo en larealización de este trabajo, solo se estudian y analizan los siguientes procesos:

1. Asegurar la optimización de los recursos2. Gestionar la disponibilidad y la capacidad

El proceso de Asegurar la optimización de los recursos se encuentra en el áreade Gobierno y pertenece al dominio evaluar, orientar y supervisar. Este procesose encarga de asegurar que se asigna la capacidad adecuada y suficiente (e.g.,personas, procesos y tecnologías) para soportar de forma eficaz los objetivos dela empresa, a un costo óptimo (Ministerio de Tecnologías de la Informacióny las Comunicaciones, s.f.). Además, tiene como propósito asegurar que lasnecesidades de recursos de la empresa sean cubiertas de forma adecuada, que


el coste de TI sea apropiado y que se pueda incrementar la probabilidad deobtener beneficios así como la preparación para cambios futuros (ISACA, 2012).

En cuanto al proceso Gestionar la disponibilidad y la capacidad, se encuentraen el área de Gestión y pertenece al dominio Construir, adquirir e implementar.Este proceso se encarga de equilibrar las necesidades actuales y futuras dedisponibilidad, rendimiento y capacidad, con una provisión de servicio efectivoen costos. Además, incluye la evaluación de las capacidades actuales, la previsiónde las necesidades futuras conforme con los requerimientos del negocio, el análisisdel impacto en el negocio y la evaluación del riesgo para planificar e implementaracciones para alcanzar los requerimientos identificados. De forma adicional, tienecomo propósito mantener la disponibilidad del servicio, la gestión eficiente de losrecursos y la optimización del rendimiento de los sistemas mediante la prediccióndel rendimiento futuro y los requerimientos de capacidad (ISACA, 2012).

ITIL es un marco de trabajo que busca apoyar a la gerencia y a los encargadosde las áreas de soporte de TI por medio de guías para agilizar las entregas deservicios. Este marco proporciona mecanismos para aumentar la interacción entreusuarios y clientes, con el fin mejorar la prestación y calidad de los servicios(Ministerio de Tecnologías de la Información y las Comunicaciones, s.f.). Laversión 3 de ITIL divide el ciclo de vida de los servicios en cinco fases:

1. Estrategia2. Diseño3. Transición4. Operación5. Mejora

En este trabajo se profundiza en la fase de Estrategia, específicamente en elproceso de la Gestión de la demanda y de forma complementaria en el procesode Gestión de la capacidad (fase de diseño).

El proceso Gestión de la Demanda se encarga de efectuar proyecciones,regular los ciclos de consumo y adaptar la prestación de servicios a los picosde mayor exigencia, para asegurar que se puedan seguir prestando de acuerdocon tiempos y niveles de calidad aceptables (OSIATIS, 2015). Para esto esfundamental analizar las actividades de la organización, a fin de extraer lospatrones de las actividades del negocio y prevenir cuáles servicios son o van aser demandados y planificar el alcance de los servicios necesarios y su prioridad(Quevedo, 2009).

El proceso de la Gestión de la capacidad busca garantizar la capacidadnecesaria para soportar los servicios de TI de acuerdo con las necesidades dela organización (OSIATIS, 2015). El fin de dicho proceso es que los recursostecnológicos estén disponibles cuando los usuarios así lo requieran. Para ello, esindispensable que este proceso se encuentre alineado con el negocio, con el finde evitar la adquisición de recursos innecesarios. Por lo que se debe conocer elestado actual de la organización y tener una visión clara sobre su rumbo.

La adecuada gestión de este proceso permite mejorar el rendimiento de losrecursos, planificar de forma adecuada el crecimiento en función al negocio,

38 Camacho et al.

reducir los gastos innecesarios por mantenimiento o adquisición de nuevosdispositivos y reducir posibles incompatibilidades y fallas en la infraestructura(ITIL vs COBIT , s.f.).

3. MetodologíaEl método que se utilizó para desarrollar, definir y modelar la propuesta del

proceso de Gestión de la demanda, se basó en el estudio de cada una de lasactividades que tienen los procesos seleccionados de COBIT 51 e ITIL v32. Deacuerdo con ese estudio se realizó la correlación de los componentes específicosy los marcos de referencia, con el fin de identificar similitudes y diferencias pararealizar el modelado.

4. Resultados y aportesEl principal aporte de este trabajo es un proceso híbrido que tiene en cuenta

las actividades de los marcos de referencias de ITIL v3 y COBIT 5 con respectoa la Gestión de la demanda y está constituido por nueve actividades (véase laFigura 1).

4.1. Descripción del procesoRecopilación de información: El proceso propuesto inicia con la recopilación

de información3, cuyo encargado de su ejecución es el departamento de TI.Suministro de planes de negocio y requerimientos: Esta actividad tiene

por objetivo comprender e identificar las actividades del negocio y la formacomo estas inciden en la demanda de los servicios. Las fuentes de informaciónde esta actividad son los planes de negocio, planes de mercadeo, proyeccionesde ventas y solicitudes de nuevos requerimientos.

Análisis de documentos: Esta actividad debe ser desarrollada por eldepartamento de TI4 y tiene como finalidad la identificación de los patronesde las actividades del negocio, también conocidas como PBAs5. Además deidentificar los PBA, esta actividad define los perfiles de los usuarios o UP6,basándose en sus roles y responsabilidades en la organización.

1 EDM04 Asegurar la optimización de recursos y BAI04 Gestionar la disponibilidady capacidad.

2 Gestión de la demanda y Gestión de la capacidad3 La recopilación de información es propuesta con base en el proceso Gestión dedemanda de ITIL v3.

4 El diseño de esta actividad se basó en ITIL v3, específicamente en el proceso Gestiónde demanda.

5 Patterns of Business Activity, por su acepción en inglés.6 User Profile, en inglés.

Definición

ymodelado

delprocesode

gestiónde

ladem

andapara

TI

39Figura 1: Proceso de modelado de la gestión de la demanda.

40 Camacho et al.

Análisis de la definición y capacidad del servicio a nivel de recursos:Esta actividad fue definida tomando como referencia COBIT 5 y lossiguientes procesos:BAI04.02: Evaluar el impacto en el negocio de COBIT 5. Este proceso

busca identificar los servicios importantes para la empresa, relacionarlos servicios y recursos con los procesos de negocio e identificar lasdependencias del negocio.

BAI04.03: Planificar requisitos de servicios nuevos o modificados. En elcaso de este procesado está asociado con la planificación y priorizaciónde la disponibilidad, el rendimiento y la capacidad para realizar cambiosconforme con las necesidades del negocio y los requerimientos de servicio.

EDM04.02: Orientar la gestión de los recursos. Este proceso estárelacionado con la adopción de principios de gestión de recursos parapermitir el uso óptimo de los recursos de TI a lo largo de su ciclo devida.

Para esta actividad también se usó como referencia la actividad Gestiónbasada en la demanda de ITIL v3 que busca asegurar que los planes denegocio de los consumidores se encuentren sincronizados con el manejo delos planes del servicio que los atiende. Con base en los patrones de demandase desarrolla la oferta, y se puede dividir en dos grandes grupos de servicios:esenciales y de soporte. Con la definición anterior, se generan paquetes deservicios específicos para los distintos grupos de clientes.

Evaluación de la disponibilidad de recursos: Esta actividad se basa enel proceso BAI04.05 Investigar y abordar cuestiones de disponibilidad,rendimiento y capacidad de COBIT 5, el cual permite abordar desviacionesde los servicios investigando y resolviendo los problemas identificados enrelación con la disponibilidad, rendimiento y capacidad.

Aprobación de mejoras y puesta en marca: Si la capacidad del servicio,con base en la disponibilidad de recursos, puede satisfacer la demanda, elflujo continua con la actividad del proceso Aprobar mejoras y puesta enmarcha.

Solicitud de recursos: En caso de que la capacidad y los recursos no puedansatisfacer la demanda, se procede a gestionar y solicitar los recursos. Dichasolicitud se realiza al negocio, debido a que involucra al área financiera de laorganización y el desempeño del negocio.

Análisis de presupuesto: Si el negocio no aprueba la solicitud de recursos, dedebe de volver a realizar el análisis de la capacidad y los recursos que requiereel servicio, de esta manera se puede replantear el alcance de la prestacióndel servicio y ajustarlo al presupuesto con el que se cuenta en ese momento.

Evaluación periódica de capacidad y disponibilidad del servicio: Estaactividad invoca a un subproceso para dar seguimiento a los servicios y susrecursos, y se basa en tres procesos de COBIT 5:BAI04.01: Evaluar la disponibilidad, rendimiento y capacidad actual y

crear una línea de referencia. Este proceso tiene como objetivo asegurarla disponibilidad, capacidad y rendimiento de los servicios mediante suevaluación.


BAI04.04: Supervisar y revisar la disponibilidad y la capacidad. En elcaso de este proceso, se enfoca en supervisar, medir, analizar, informary revisar la disponibilidad, el rendimiento y la capacidad; además deidentificar desviaciones respecto a las líneas de referencia establecidasy revisar informes de análisis de tendencias identificando cualquierproblema o variación significativa para iniciar las acciones necesarias conel fin de asegurar que se realiza el seguimiento de todos los problemaspendientes.

EDM04.03: Supervisar la gestión de recursos. Este proceso indica que sedeben supervisar los objetivos y métricas claves de los procesos de gestiónde recursos, así como establecer la forma en que serán identificados y seles dará seguimiento a las desviaciones o problemas.

La evaluación periódica de capacidad y disponibilidad del servicio tambiénse basó en el proceso Gestión de la capacidad de ITIL v3, el cual tiene relacióncon el seguimiento y revisión de los informes de desempeño de los serviciosy componentes, además de reaccionar y ayudar en la solución de problemasespecíficos de rendimiento, si se llegan a materializar.

Otro objetivo de esta actividad es suministrar información, con la cual sepueda determinar si el nivel de demanda del servicio está sobre pasando lacapacidad si el servicio se encuentra subutilizado. Si el funcionamiento delservicio es normal, se termina el flujo; en caso contrario, se procede a realizarel análisis de la documentación del negocio para determinar si la capacidad delos recursos está mal definida, si es necesario gestionar más recursos o se debeincentivar a los usuarios para que utilicen el servicio.

5. Conclusiones

Los marcos de referencia ITIL v3 y COBIT 5 se complementan entre sí,debido a que ambos apoyan el crecimiento de la organización y el mantenimientode los servicios. Lo anterior se confirmó con el desarrollo de este trabajo, el cualllevó a cabo la correlación de información de ambos marcos de referencia ypermitió la definición de un proceso de gestión de la demanda.

Lo anterior permite afirmar que la utilización mixta de los marcos dereferencia en cuestión es factible y facilita el desarrollo de marcos de trabajoajustados a cada organización. Por ejemplo, COBIT es un marco de referenciaflexible y adaptable a cualquier organización, lo cual es uno de sus aspectosesenciales, como quedó expuesto con el planteamiento del modelo con la gestiónde la demanda.

Cabe señalar que los insumos o documentación del negocio, a partir de la cualse realiza la identificación de la demanda de los servicios, es de suma importancia,porque sin estos no es posible conocer los servicios que se requieren, ni las salidasy demandas esperadas.

En línea con lo anterior, es importante tener en cuenta que la evaluacióncontinua de los servicios es vital porque los requerimientos del negocio y el

42 Camacho et al.

entorno donde se desenvuelve la organización está en constante cambio, lo cualrequiere que la capacidad para satisfacer la demanda se ajuste a las necesidadesactuales.

Como trabajo futuro se recomienda evaluar el marco de referencia CMMipara servicio, debido a que este se enfoca en la administración y entrega de losservicios ofertados, lo cual es un producto del proceso de gestión de la demanda.Para optimizar el proceso planteado en este trabajo, se requiere incorporar unestudio de continuidad, y CMMi para servicios puede ofrecer el apoyo necesariopara optimizar el proceso.

ReferenciasAlonso, I. A., Caro, E. T. y Verdún, J. C. (2008, dic). The importance of it

strategic demand management in achieving the objectives of the strategicbusiness planning. En International Conference on Computer Science andSoftware Engineering, 2008 (Vol. 2, p. 235-238).

ISACA. (2012). COBIT 5: Procesos Catalizadores. Autor. Descargado dewww.isaca.org

ITIL vs COBIT. (s.f.). Descargado de http://www.cntec.mx/noticias/41/122-itilvscobit.html

Ministerio de Tecnologías de la Información y las Comunicaciones. (s.f.). Marcode referencia: arquitectura TI de Colombia.

Muñoz-Serna, R., y Martínez-Arias, M. A. (2012). Caracterización de procesosde gestión de TI basados en COBIT 5 y mapeo con ISO27002, ITIL,CMMI DEV, PMBOK, para la implementación en la industria editorialcolombiana, apoyando el proceso de transformación digital.

OSIATIS. (2015, dic). ITIL Foundation. Descargado de http://itilv3.osiatis.es/

Quevedo, A. M. (2009, set). Implementación de una metodología de procesos parala mejora de TI en una empresa. Universitat Politècnica de Catalunya.Descargado de http://upcommons.upc.edu/handle/2099.1/7599

Recomendaciones para la gestión de incidenciasde tecnologías de la información

Verny Mora Jiménez, Paulo Viales Wahrmann, Julio Córdoba Retana yAntonio González Torres∗



[[email protected],[email protected],jcordobar022]@[email protected]∗


Resumen La gestión de incidencias es un proceso crítico en laadministración de los servicios de tecnologías de la información (TI),por el impacto en las operaciones de las organizaciones y la relación quese establece entre los usuarios y el departamento de TI. De acuerdo conesto, este trabajo de investigación lleva a cabo el análisis de las principalesactividades asociadas, conforme con los marcos de referencia ITIL,COBIT y CMMI, y propone un proceso para la gestión de incidencias.El objetivo es apoyar a los administradores de TI en la definición eimplementación de la gestión de incidencias mediante la discusión dela propuesta y el flujo de las tareas que componen el proceso.

Palabras clave: Gestión de Incidencias, ITIL, COBIT, CMMI

1. Introducción

En el contexto actual, las tecnologías de la información (TI) son un factorcrítico para el desempeño de las organizaciones, por lo que requieren el correctofuncionamiento de los sistemas de hardware y software que utilizan. Estoconlleva a que las incidencias1 que se presenten deban ser resueltas de formaoportuna, tanto a usuarios internos como externos, por lo que es necesario quelas incidencias se gestionen de forma adecuada, para evitar que se transformenen riesgos para la continuidad de la organización

En este punto resulta indispensable tener en cuenta que los servicios de TIdeben ofrecer servicios de calidad con alta disponibilidad; utilizar los recursosde forma más eficiente; ayudar a incrementar la productividad de los usuarios;reducir costos, tiempos de ejecución de procesos y riesgos; y alinearse a losprocesos del negocio. Sin embargo, los altos niveles de calidad de los servicios no1 Se denomina como incidencia a un problema que sobreviene en la prestación de unservicio que es soportado por hardware o software.

44 Mora et al.

se pueden alcanzar únicamente con fuertes inversiones en tecnología y personalcualificado, sino que es necesario contar con una buena gestión y planificación anivel empresarial. Para esto, es recomendable implementar un sistema de gestiónde servicios de TI (SGSTI), potenciar la labor de los gestores y utilizar métricaspara el seguimiento y control de la resolución de incidencias (Bauset-Carbonelly Rodenes-Adam, 2013; Mutafelija y Stromberg, 2008).

También es conveniente tener en cuenta que la gestión de incidencias,además del impacto que tiene en la organización, determina la relación de losdepartamentos de TI con los usuarios, y en cierta forma se convierte en un reflejode la calidad de los servicios que estos ofrecen. Cabe resaltar que la calidad de losservicios implica tanto el nivel de efectividad de la resolución de los problemascomo la forma en que el servicio es percibido por los usuarios y el resto de laorganización (Persse, 2013).

De acuerdo con la experiencia de los autores, un gran número deorganizaciones no aplican las mejores prácticas de la industria para la gestiónde incidencias, en algunos casos por desconocimiento y en otros por que no lebrindan la importancia necesaria. Tomando en cuenta lo anterior, en este trabajose estudian y analizan los lineamientos y mejores prácticas que son recomendadaspor COBIT, ITIL y CMMI, con el fin de proponer un proceso y una lista derecomendaciones que sirvan como guía para realizar la gestión de incidencias enservicios de TI. Dicho proceso pretende contribuir con la detección oportuna dedesviaciones en los procedimientos, la correcta clasificación de las incidencias, lautilización de procedimientos de escalado y el cierre adecuado de las incidencias.El fin de este planteamiento es contribuir con la mejora de los porcentajes deefectividad en la resolución de incidencias de las organizaciones, en un plazo nomayor de un año de la puesta en marcha del proceso.

2. Marco teórico

Una incidencia es un evento que implica la interrupción no planificada o lareducción de la calidad de un servicio de TI, el cual es soportado por elementosde hardware o software (ITIL Foundation, 2011). Las incidencias pueden serdetectadas por el personal técnico, reportadas por herramientas de seguimientode eventos, comunicadas por los usuarios de forma telefónica o mediante unsistema de incidencias o informadas por terceros (e.g., proveedores y socios denegocio2). En tanto, la gestión de las incidencias es el proceso responsable deadministrar el ciclo de vida de cada incidencia (Persse, 2013).

La gestión de incidencias requiere brindar respuesta oportuna y efectiva a laspeticiones de los usuarios relacionadas con la resolución de problemas asociadosa los servicios de TI, con el fin de no afectar los procesos de la organizacióny cumplir con los compromisos con terceros (Forrester, Buteau y Shrum,2011). En términos generales, este proceso contempla registrar las peticiones deservicio, diagnosticar el problema de forma precisa (i.e., identificar y describir

2 Conocidos como partners, por su acepción en inglés.

Recomendaciones para la gestión de incidencias de TI 45

los síntomas de las incidencias, así como asignar los recursos necesarios parasu resolución), determinar la prioridad de la incidencia, resolver las incidencias(i.e., determinar las posibles causas, efectuar escalaciones y recuperar el servicio,en caso necesario), documentar y registrar de forma exhaustiva la resolución dela incidencia, cerrar las incidencias y mantener un registro histórico (véase losprocesos DSS02 y DSS03 de COBIT 5) (ISACA, 2012; O’Toole, 2015).

El registro de las peticiones de servicio requiere verificar que estas cumplancon los criterios mínimos establecidos y que los usuarios que las realizan esténdebidamente autorizados. Cada incidencia debe contar con un número único dereferencia, hora y fecha de registro, identificación de la persona que realizó elregistro de la incidencia, método de notificaciones del estado de la incidencia ydescripción de los síntomas.

En cuanto al diagnóstico, es necesario contar con toda la informacióndisponible para efectuar una mejor evaluación del problema para efectuar sucategorización, determinar el impacto en el negocio (i.e., nivel de pérdidafinanciera, el posible efecto en la reputación del negocio y las regulacionesdel país) y la urgencia de su resolución, efectuar una correcta asignación dela prioridad, obtener la aprobación financiera y si se requiere, el cambio deprocedimientos o estándares.

Como parte de este proceso, se requiere utilizar la base de datos deconocimiento, si existe, para determinar si el problema está asociado a un errorconocido, o si este ha sido resuelto anteriormente. Este paso se debe efectuarantes de asignar a un especialista para realizar un análisis de mayor profundidado que se lleven a cabo acciones para restaurar los servicios afectados, con ayudade otros especialistas.

En los casos en los que la incidencia es reportada por teléfono, se recomiendaefectuar un diagnóstico inicial e intentar ofrecer una solución de forma inmediata,trabajando junto con el usuario, si es factible. Si no es posible ofrecer una solucióninmediata, entonces se debe informar al interesado sobre el procedimiento quese seguirá, y darle un número de incidencia para que le pueda dar seguimiento.

En lo que respecta a la resolución de incidencias, conviene tener en cuenta laposibilidad de seguir el procedimiento para efectuar el escalado de la incidencia.Este tipo de procedimiento usualmente contempla el escalado funcional (sesolicita el apoyo de un especialista de más alto nivel para resolver el problema) ojerárquico (se acude a un responsable de mayor autoridad para tomar decisionespor encima del nivel del personal técnico involucrado, como la asignación derecursos adicionales para la resolución de la incidencia).

En todo caso, es recomendable resolver cada incidencia en el menor tiempoposible, para restaurar o normalizar el servicio y salvaguardar los intereses dela organización. Además, es necesario que en el transcurso de la resolución sele brinde seguimiento al estado de las incidencias hasta que se realice el cierrede esta. El proceso de seguimiento involucra documentar y revisar las accionesrealizadas, escalar las incidencias según se requiera y comunicar el estado de laincidencia a las partes interesadas.

46 Mora et al.

En el transcurso de la resolución de una incidencia puede ser necesarioefectuar procedimientos de recuperación de los servicios, los cuales dependeránde la naturaleza de esta, y podrían involucrar la participación activa del usuarioen la realización de actividades concretas; de forma similar se podría requerirla participación de otros especialistas e incluso de consultores o proveedoresexternos.

Una vez que la incidencia ha sido resuelta, se deben hacer las comprobacionesnecesarias con el usuario para cerrar el caso, medir la satisfacción, tener encuenta los requerimientos de informes de las partes interesadas en la gestión deincidencias y utilizar criterios de calidad del servicio (Forrester et al., 2011).

El cierre de la incidencia debe contemplar la documentación de las actividadesque se realizaron para resolverla, la fecha de resolución, la categoría de cierre, lafecha en que se está efectuando el cierre y la resolución de las causas subyacentesa la incidencia (Kenett y Baker, 2010). Además, se requiere documentarlas soluciones identificadas, registrar si se usaron soluciones temporales oacciones de recuperación de servicios, determinar las acciones incorrectas quese llevaron a cabo y comprender el proceso que se siguió durante la resolución.Esta información permite efectuar el análisis, evaluación y clasificación deincidencias para establecer tendencias, encontrar patrones de asuntos recurrentese infracciones a los procedimientos, reducir la ocurrencia de incidencias similaresen el futuro, mejorar su resolución y apoyar la búsqueda de mejores prácticas.

3. Proceso para la gestión de incidencias

La definición de un proceso para la gestión de incidencias requiere que,en primer lugar, se determinen de forma clara las políticas, procedimientosy definiciones que serán considerados por este. Conforme con lo anterior, serecomienda tomar en cuenta los elementos que se presentan en la siguiente lista.

Definición de una incidencia: Es necesario diferenciar de forma clara entreuna incidencia y una solicitud de servicio. Una incidencia es la interrupciónno planificada o la reducción de la calidad de un servicio de TI. Si bienlas solicitudes de servicio deben ser reportadas de forma similar que lasincidencias a la mesa de servicio, la diferencia es que estas no representan lainterrupción de un servicio (ITIL Foundation, 2011).

Categorías: La definición de categorías es otro elemento fundamental enla gestión de incidencias, para ubicar y asignar los recursos humanos ymateriales de forma correcta cuando una incidencia es reportada. Sobre esteparticular, tanto ITIL como CMMI ofrecen recomendaciones para realizarun catálogo de categorías de incidencias (ITIL Foundation, 2011; Forresteret al., 2011). Como recomendación, se sugiere realizar una lluvia de ideascon el personal involucrado en la gestión de incidencias (e.g., los técnicosde soporte, supervisores de gestión de incidencias y administradores), paracrear una lista preliminar de categorías, que se ponga a prueba por un periodocorto de tiempo. De forma posterior, se recomienda analizar las incidencias


reportadas durante un periodo de tiempo para afinar la lista de categoríasde incidencias.Como buena práctica, el catálogo de categorías debe ser analizado de formaperiódica, cada 3 o 5 meses, para realizar actualizaciones y mantenerloadecuado a las necesidades del negocio.

Responsable de incidencias: La asignación de responsabilidades es otroelemento a tener en cuenta. En este aspecto, tanto COBIT (IT GovernanceInstitute, 2013) como CMMI (Forrester et al., 2011) especifican varioslineamientos importantes. En general, es necesario especificar cuáles sonlas responsabilidades del técnico al que se le asigna una incidencia, asícomo quién es el responsable de supervisar, dar seguimiento al estado delas incidencias, efectuar los procesos de escalado y realizar la transferenciade responsabilidades entre pasos o procesos.

Asignación de prioridad: La resolución de las incidencias requiere contar condiferentes niveles de prioridad, en función de la relevancia e impacto en elnegocio. De acuerdo con el análisis de COBIT 5, ITIL y CMMI se recomiendael uso de 5 niveles de prioridad usando valores numéricos (e.g., 1 a 5) ocategóricos (baja, media, alta, grave, crítica).

Reporte de incidencias: Es importante definir de forma clara los mecanismospara el reporte y seguimiento de las incidencias, sin importar si se realizade forma manual o automatizada. En todo caso, las personas que reportanlas incidencias deben encontrarse autorizadas, exceptuando los casos en quese demuestre que peligra la vida de las personas o que la continuidad delnegocio está siendo afectada.En general, se recomienda contar con un sistema que facilite el reporte deincidencias a los usuarios (Forrester et al., 2011), la actualización de losestados (e.g., abierta, en progreso, resuelta y cerrada) (ITIL Foundation,2011) y seguimiento de las acciones realizadas durante el ciclo de vida de lasincidencias.

Reapertura de incidencias: En algunos casos es posible que una incidenciano haya sido resuelta por completo y sea necesario reabrirla, por lo quese requiere definir las reglas para reabrir incidencias, asignarles una nuevacategoría y prioridad, y determinar quién será el responsable que trabajaráen la solución.

En general, los modelos relacionados con la gestión de las tecnologías de lainformación coinciden en cuanto a las principales tareas que requiere el procesode gestión de incidencias, siendo esas tareas las siguientes:

1. Registro de incidencias.2. Resolución de incidencias.3. Cierre de incidencias.4. Seguimiento y análisis de incidencias.

En consecuencia, este trabajo ha tomado en cuenta la lista de tareasenunciadas y las mejores prácticas de COBIT (IT Governance Institute, 2013),

48 Mora et al.

ITIL (ITIL Foundation, 2011) y CMMI (Forrester et al., 2011), para proponerel proceso que se muestra en la figura 1. Las tareas ordinarias de dicho procesoson representadas por cajas rectangulares y las decisiones por rombos, en tantoque las líneas de color rojo indican el flujo ordinario de las tareas y las líneaspunteadas de color negro muestran la secuencia alternativa, en donde el flujopuede seguir uno u otro camino con base en las decisiones que se han tomado.

El proceso propuesto comienza con la identificación de las incidencias porparte de los usuarios de la organización o los miembros del departamento deTI (i.e., por observación en el campo o por medio del uso de sistemas paraese propósito). Una vez que la incidencia ha sido identificada, se procede aregistrarla, para luego efectuar el diagnóstico (i.e., de forma opcional se puedeusar la base de conocimientos), categorización y asignación de prioridad. Conbase en el diagnóstico, se determina si la resolución de la incidencia requiererecursos extraordinarios, y en caso necesario se solicita la aprobación de esosrecursos al comité ejecutivo. A partir de ese punto, se inicia la recuperación deservicios (cuando se requiera) y la resolución de la incidencia.

Cuando la incidencia ha sido resuelta, de acuerdo con el personal técnico,se realizan las pruebas técnicas necesarias para validar la resolución. En casode que la incidencia se haya resuelto de forma efectiva, se hace la verificacióny aceptación de la solución con el usuario. Sin embargo, cuando la incidenciano ha sido resuelta, se verifica si el personal técnico a cargo puede terminar desolucionarla o si es necesario solicitar el escalado de la incidencia. En caso de quesea necesario escalar la incidencia, se determina si el escalado que se requiere esfuncional o jerárquico. Cuando el proceso de escalado ha terminado, se verificasi la incidencia ha sido resuelta, y si es así, se procede a realizar la verificación yaceptación con el usuario. En caso de que la incidencia no haya sido resuelta trasel proceso de escalado, se determina si el equipo de la mesa de servicio puedeterminar de resolverla o si es necesario volver a seguir el proceso de escalado.Una vez que la resolución de la incidencia ha sido resuelta de forma definitiva,tras efectuar la verificación y aceptación con el usuario, se procede a cerrarla ydocumentarla.

La descripción de cada una de las tareas que conforman el proceso propuestose detalla a continuación.

Identificación de incidencias: En un escenario ideal, se brinda seguimientoconstante a los recursos y servicios críticos de la organización para prevenir laocurrencia de incidencias o bien, un gran número de incidencias es detectadopor el departamento de TI en el momento en que se presentan, incluso antesde que los usuarios se den cuenta de los eventos. Sin embargo, como muestrala figura 1, la identificación de las incidencias, por lo general, es realizadatanto por los usuarios de la organización como por el departamento de TI.

Recom

endacionespara

lagestión

deincidencias

deTI

49

Figura 1: Proceso para la gestión de incidencias de tecnologías de la información.

50 Mora et al.

Registro de incidencias: El proceso para registrar las incidencias debe ponera disposición de los usuarios autorizados tantos medios como sea posible,incluyendo llamadas telefónicas, registro web y mensajería instantánea.Cabe recalcar que tanto el reporte como el registro de incidencias debeser efectuado por usuarios que se encuentren autorizados, conforme a loestablecido por las políticas y reglamentos de la organización.Algunos de los principales elementos de información para registrar unaincidencia son los siguientes:1. Nombre de quien registra y quien reporta la incidencia2. Datos de contacto3. Descripción detallada de la incidencia4. Fecha y hora del reporte (tomada por el sistema)5. Número de referencia (generado por el sistema)6. Prioridad y categoría inicial (ingresada por quien registra la incidencia)7. Notas sobre el impacto en el negocio

Diagnóstico, categorización y prioridad: El diagnóstico, dependiendo dela naturaleza de la incidencia, se puede realizar de forma paralela a suregistro. En algunos casos es posible que durante este proceso, con asistenciade una base de datos de conocimiento, el problema sea solucionado porel usuario que está efectuando el reporte o por quien está registrandola incidencia (e.g., también es posible que la incidencia sea resuelta almomento de hacer el diagnóstico, en el momento en que se recibe elreporte por teléfono). Pero también en algunos casos, podría ser necesariosolicitar aprobación para proceder, por razones financieras, de riesgo en losprocedimientos o para solicitar apoyo adicional de otras áreas. En todo caso,en esta etapa del proceso debe asignar la categoría y prioridad definitiva ala incidencia, en función del tipo de incidencia, urgencia e impacto.

Autoayuda- BD conocimiento: Los sistemas modernos de gestión deincidencias utilizan el registro histórico de las incidencias, y toda lainformación relacionada con el seguimiento, para crear bases de datos deconocimiento que orientan al usuario sobre las posibles acciones que puedenseguir para resolver las incidencias por su cuenta. antes de realizar un reporte.De forma similar, este tipo de sistemas permite que los técnicos realicen losdiagnósticos y resolución de incidencias de forma más efectiva, por mediode información relacionada con casos similares que han sido resueltos. En elcaso del proceso propuesto, esta actividad se encuentra ligada al diagnóstico,categorización y asignación de prioridad a las incidencias, así como a larecuperación y resolución de la incidencia, tomando en cuenta lo anterior.

Aprobación del comité ejecutivo: Cuando se considera que es necesarioutilizar recursos o procedimientos extraordinarios para la resolución de unaincidencia, se debe contar con la aprobación del comité ejecutivo. Todaaprobación debe ser documentada en formato papel o digital, y se debeevidenciar la firma del responsable del comité (i.e., se recomienda el uso defirma digital).

Recuperación y resolución de incidencias: Para realizar esta tarea, lamesa de servicio debe contar con el personal capacitado y herramientas para


determinar el mejor curso de acción para la resolución de la incidencia. Entrelas tareas que pueden ser necesarias durante la resolución de las incidenciasse encuentran las siguientes:1. Realizar la recuperación de uno o varios servicios asociados.2. Efectuar el reemplazo de equipos, dispositivos o partes (i.e., en algunas

ocasiones puede ser necesario cambiar los estándares sobre característicasde equipos de la empresa para resolver una incidencia).

3. Cambiar procedimientos internos o utilizar procedimientosextraordinarios.

4. Solicitar personal de otras áreas o personal adicional.5. Revisar las bitácoras y acciones que fueron realizadas antes y después de

reportada la incidencia. Esto tiene como fin determinar los cambios quehan sufrido tanto el servicio afectado como otros servicios asociados, asícomo determinar cuáles acciones adicionales pueden ser requeridas.

Escalado de incidencias: En el transcurso de la resolución de incidencias, esfrecuente que cuando no pueden ser resueltas por la mesa de servicio, serecurra a los procedimientos de escalado.Las reglas de escalado y gestión de incidencias deben encontrarseespecificadas en las políticas, procedimientos o acuerdos formulados por laorganización (e.g., acuerdo de nivel de servicio, acuerdo de nivel operacionaly contrato de apoyo) con los grupos de apoyo internos y externos. En elcaso concreto de este trabajo, se toman en cuenta el escalado funcional yjerárquico (ITIL Foundation, 2011), como se muestran en la Figura 1 y esdescrito a continuación.Escalado funcional: Este tipo de escalado es utilizado para resolver una

incidencia de forma apropiada, en el tiempo requerido, y tiene como finapoyar al grupo que tiene a cargo una incidencia cuya complejidad yprioridad demanda la participación de otros grupos con un nivel másalto de especialización, experiencia y capacitación. Los grupos de apoyopueden ser internos o externos, como proveedores de software, fabricantesde hardware o personal de mantenimiento.Por lo general, la mesa de servicio es la encargada de escalar lasincidencias al nivel funcional apropiado, pero se recomienda que sea laresponsable de darles seguimiento, mantener informados a los usuariosy efectuar el cierre de estas, sin importar el grupo al que hayan sidoreferidas para su resolución.

Escalado jerárquico: Este tipo de escalado se realiza cuando es necesarioque los mandos superiores estén al tanto de la situación por el impactoen el negocio, cuando se requiere su apoyo para coordinar con otrosdepartamentos o es necesario contar con recursos adicionales, internos oexternos.

Verificación y aceptación: Cuando la incidencia ha sido resuelta, la mesa deservicio procede a realizar la verificación, junto con los usuarios afectados,de que el problema se ha solucionado de forma satisfactoria. Si el usuarioacepta la resolución de la incidencia, se efectúa el cierre y documentación,

52 Mora et al.

de lo contrario, se procede a trabajar en los aspectos necesarios para resolverla incidencia a satisfacción del usuario.

Cierre y documentación: El cierre y documentación de una incidenciaconcluye el ciclo de gestión de incidencias, para una incidencia en particular.Sin embargo, la gestión de incidencias es un proceso continuo que comprendela resolución de las incidencias, la documentación de todas las accionesrealizadas y el uso de la información que se genera para obtener conocimientoque permita mejorar la atención de lo usuarios. De acuerdo con lo anterior, elcierre de la incidencia requiere verificar y corregir, si es el caso, la categoríay prioridad asignada, y la documentación de las tareas realizadas.Aunque algunas organizaciones implementan mecanismos para el cierreautomático de incidencias después de un determinado periodo de tiempo, eneste trabajo se recomienda que el cierre de las incidencias sea realizado deforma explícita por la mesa de servicio. El cierre automático de las incidenciasno es adecuado porque puede ocasionar distorsiones sobre las incidencias quehan sido resueltas de forma satisfactoria y las que se pueden haber dejadoen el olvido por su baja prioridad.

El seguimiento de las incidencias es una tarea que se encuentra presente entodo el proceso de gestión de incidencias. Es preciso registrar todos los detallesde las acciones que se realizan en torno a las incidencias (Forrester et al., 2011;ITIL Foundation, 2011) y contar con las herramientas apropiadas para alertaral personal técnico cuando sea necesario, y también para brindarles informaciónconstante sobre el estado de las incidencias, así como sobre las interrelaciones einteracciones que tienen entre sí.

De forma posterior al cierre de las incidencias, se deben estudiar y analizarlos problemas recurrentes, su naturaleza y causa. Además, se recomiendadeterminar, con los grupos de soporte involucrados, si las causas de este tipode incidencias han sido resueltas, y la posibilidad de que se vuelvan a presentarotras incidencias relacionadas con esas mismas causas. Esto tiene como fin, tomarmedidas para eliminar o reducir el número de incidencias por una misma causa.

Un elemento de gran importancia en este proceso es asegurar la satisfacciónde los usuarios, por lo que se recomienda efectuar encuestas (por medio de correoo teléfono) para determinar su nivel de satisfacción con los servicios de gestiónde incidecias y tomar las medidas necesarias para corregir los problemas que sedetecten. En línea con esto, es necesario contar con una política y procedimientosclaros en torno a la reapertura de incidencias, en caso necesario, por lo que esimportante que se brinde capacitación constante a todo el personal de la mesade servicio, tanto sobre aspectos técnicos como de procedimientos y servicio alcliente.

4. Conclusiones

Las organizaciones se enfrentan a retos diversos que requieren el uso delas mejores prácticas existentes, sobre todo cuando se trata de la gestión de

Referencias 53

incidencias de TI, por la alta dependencia que tienen sus actividades de lossistemas de hardware y software. Por eso, la definición de un proceso de gestiónde incidencias con base en los marcos de referencia COBIT, ITIL y CCMI esde gran importancia. Sin embargo, es importante considerar que la definiciónde un proceso de esa naturaleza debe tomar en cuenta las particularidades decada organización con respecto a metas, objetivos y recursos. Conforme con loanterior, el fin de este trabajo ha sido orientar a los administradores de TI enla definición del proceso de gestión de incidencias, mediante la propuesta de unproceso basado en las mejores prácticas de los marcos de referencia mencionados.

La definición de un proceso de gestión de incidencias requiere estudiar endetalle cada organización y analizar los servicios de TI con los cuales cuenta.En general, para implementar de forma exitosa y eficiente un proceso de estanaturaleza, es necesario comprender los procesos de negocio y la forma en queson soportados por los servicios de TI, para definir de forma adecuada las tareasy actividades que se requieren. En todo caso, cuando el número de servicios esreducido, o cuando estos no son complejos, no es necesario definir un procesocomplejo o costoso.

El uso de bibliografía complementaria para definir y justificar la definicióne implantación de un proceso de gestión de incidencias, adaptado a lasnecesidades de la organización, puede ser de gran ayuda. En la literaturase encuentra documentado que el uso de buenas prácticas ayuda a eliminarel trabajo redundante; mejora los tiempos de respuesta (i.e., indicadores desoporte al negocio); y contribuye con la definición de departamentos de TImejor estructurados, más eficientes y enfocados en los objetivos de la empresa(Herold, 2007). No obstante, las justificaciones basadas en la literatura (e.g.,modelos de referencia, y casos de estudio) suelen ser insuficientes, porque esnecesario justificar con evidencia sustancial la razón costo/beneficio, ante laadministración. Además, se debe tener en cuenta que la divulgación, aceptación yreconocimiento del proceso por parte de la organización toma tiempo y recursos(Quesnel, 2012). Por esa razón, podría ser necesario implementar un plan pilotoque permita demostrar el impacto del proceso cuando se presentan incidenciasque implican la interrupción de servicios en departamentos estratégicos.

Finalmente, cabe mencionar que los marcos de referencia, aunque tienenobjetivos similares, sugieren estrategias diferentes para alcanzarlos. Por ejemplo,las organizaciones con un nivel de madurez bajo, pueden utilizar ITIL comoreferencia, debido al grado de detalle que ofrece y el enfoque orientado a tomaren cuenta los factores internos de cada entidad. Por su parte, CMMI puede serusado por empresas con un nivel de madurez más alto, con mayor experiencia enla gestión de incidencias y el uso de buenas prácticas. Lo anterior, debido a queofrece recomendaciones (e.g., implementar sistemas de software para la gestiónde incidencias) que no se adaptan a organizaciones con niveles de madurez bajo.

Referencias

Bauset-Carbonell, M. C., y Rodenes-Adam, M. (2013, jan). Gestión de los

54 Mora et al.

servicios de tecnologías de la información: modelo de aporte de valor basadoen itil e iso/iec 20000. El profesional de la información, 22 (1).

Forrester, E., Buteau, B. y Shrum, S. (2011). CMMI for services: Guidelinesfor superior service. Pearson Education.

Herold, R. (2007). The shortcut guide to improving it service support throughitil. Realtimepublishers.com.

ISACA. (2012). COBIT 5: Procesos Catalizadores. Autor. Descargado dewww.isaca.org

IT Governance Institute. (2013). Cobit 5. Rolling Meadows.ITIL Foundation. (2011, Julio). Itil v3 2011. Descargado de http://itilv3

.osiatis.es/Kenett, R., y Baker, E. (2010). Process improvement and cmmi® for systems

and software. CRC Press.Mutafelija, B., y Stromberg, H. (2008). Process improvement with cmmi® v1.2

and iso standards. CRC Press.O’Toole, D. (2015). Incident management for i.t. departments. On Demand

Publishing, LLC-Create Space.Persse, J. (2013). The it service management process manual. van Haren

Publishing.Quesnel, J. (2012). Entender itil 2011: Normas y mejores prácticas para avanzar

hacia iso 20000. Éd. ENI.

Diseño de una arquitectura para la comunicaciónentre protocolos en internet de las cosas

Marco Córdoba Padilla, Frank Trejos Moya, Fernando Chinchilla Jiménez yAntonio González Torres∗



[mcordobap487,ftrejosm824,fchinchillaj980]@[email protected]∗


Resumen El uso de internet y las tecnologías relacionadas se haincrementado con el paso del tiempo. En ese contexto, internet de lascosas (IoT ) ha entrado a jugar un papel de importancia con una grancantidad de dispositivos y aplicaciones para ofrecer servicios y solucionesnovedosas, que en muchos casos están atadas a protocolos y fabricantesparticulares. De forma que la principal riqueza de IoT (la variedadde dispositivos, protocolos y fabricantes) se ha convertido en el mayorreto para garantizar la utilidad máxima de las posibilidades detrásde este concepto. La diversidad de IoT permite solucionar problemasde diferentes maneras, con costos y calidad variable, pero introducedificultades relacionadas con la compatibilidad cuando se intentanrealizar combinaciones específicas para resolver problemas particulares.Ante este escenario, el objetivo de este trabajo de investigación esproponer el diseño de una arquitectura de bajo costo basada enuna puerta de enlace para facilitar la interconexión de dispositivos yprotocolos diversos. Con ese fin se lleva a cabo la discusión sobre losdiferentes elementos que componen la arquitectura de un sistema IoT, seestudian los principios de las puertas de enlace, se realiza la propuestadel diseño y se presenta un posible escenario de uso.

Palabras clave: internet de las cosas, protocolos, comunicaciones

1. IntroducciónEn años recientes ha surgido un gran número de dispositivos que se

caracterizan por sus excelentes capacidades de comunicación, bajo costo yconsumo energético, y sus capacidades reducidas tanto de procesamiento comode almacenamiento. Estos dispositivos han sido agrupados bajo el conceptode internet de las cosas1 y se usan en áreas tan diversas como el transporte,1 El término internet de las Cosas se deriva de Internet of Things en inglés y se asociacon las siglas IoT.

56 Córdoba et al.

la seguridad, la salud, el seguimiento de los signos vitales de las personas, lainteligencia ambiental, la iluminación, el control de la temperatura de edificios yel acceso a áreas restringidas. En general, su uso está ligado con la búsqueda demejoras a los procesos de las organizaciones y la calidad de vida de las personas.

Conforme el concepto de internet de las cosas (Ashton, 2009) ha tomadofuerza en años recientes, han surgido de forma masiva tanto fabricantescomo nuevos dispositivos. A finales del 2015, el número de desarrolladores deaplicaciones y soluciones de IoT superó los 6, 2 millones (Rana, 2016), y mostróun crecimiento del 34% con respecto al año anterior. Este crecimiento ha sidoempujado por la caída en los costos de los dispositivos y el acceso a internet.

Lo anterior, ha impulsado la rápida evolución de nuevas tecnologías, peroha originado problemas de integración e interconexión entre los dispositivosproducidos por diferentes fabricantes, debido a la ausencia de un protocoloo pila de protocolos dominante, como el caso de TCP/IP en las redestradicionales2. A esto también ha contribuido la necesidad de desarrollardispositivos especializados con características propias y diferenciadas, pararesolver problemas particulares y complejos que, por lo general, requieren eluso de dispositivos de varios fabricantes.

Como parte de los esfuerzos que realizan los fabricantes para lograr mayorcapacidad de interconexión, se han establecido varias alianzas para impulsar eldesarrollo y crecimiento de IoT a través de la investigación y creación de nuevosproductos. Tal es el caso de Z-Wave Alliance (The Z-Wave Alliance, 2016), lacual impulsa el desarrollo del protocolo con el mismo nombre, y que desde suestablecimiento en el 2005 ha incorporado a 375 compañías. Otro caso similar esla alianza (ZigBee Alliance, 2016) de fabricantes de dispositivos que utilizan elprotocolo inalámbrico ZigBee, y que es conformada por más de 400 compañíasque utilizan dicho protocolo.

Sin embargo, la necesidad de realizar diseños en los cuales conviven einteractúan diferentes protocolos en un mismo sistema IoT sigue siendo unaprioridad, porque la interoperabilidad entre estos (Manyika et al., 2016) puedecontribuir a generar ingresos adicionales a la industria por un 40%.

Este trabajo propone un diseño para que los protocolos más utilizados enIoT puedan comunicarse usando una arquitectura basada en una puerta deenlace3, por lo que el principal aporte del trabajo realizado es la propuesta de unaarquitectura de bajo costo para comunicar dispositivos y protocolos heterogéneosen el contexto de IoT.

Como consecuencia, la sección 2 analiza los principales elementos de unaarquitectura de IoT, discute los conceptos relacionados con la interconexión entredispositivos y estudia los fundamentos de las puertas de enlace. Con base en lainformación presentada en la sección 2, la sección 3 presenta el diseño de una

2 Los dispositivos de internet de las cosas, en su mayoría, utilizan protocolos simplesque requieren contar con menos capacidad de procesamiento y consumo de energíaque los dispositivos que utilizan TCP/IP.

3 Las puertas de enlace permiten la comunicación entre dispositivos en diferentessegmentos de una red, en los cuales utilizan protocolos diversos.

Diseño de una arquitectura para la comunicación entre protocolos 57

arquitectura de IoT basada en una puerta de enlace y analiza un escenariode uso para dicha propuesta. Finalmente, la sección 4 discute las principalesconclusiones del trabajo.

2. Antecedentes

La arquitectura de alto nivel de un sistema de IoT es similar a la arquitecturagenérica de cualquier otro sistema; se compone de elementos de entrada,procesamiento y salida. La diferencia básica es que la entrada de datos se puederealizar por medio de sensores y la salida se puede efectuar con actuadores.Así, los datos que se adquieren del entorno por medio de sensores se transmitena los dispositivos de control (procesamiento) usando tecnologías y protocolosde comunicación, y una vez que son procesados, el resultado es enviado a losactuadores para modificar, si es el caso, las condiciones del entorno.

El procesamiento de datos en un sistema IoT requiere protocolos decomunicación para el intercambio de datos y de algoritmos para su tratamientoy análisis. Los algoritmos se encargan de procesar los datos e integrarlos, deconformidad con las relaciones de comunicación que se pueden formar entre losdispositivos y la arquitectura del sistema.

Los sistemas de esta naturaleza también pueden recibir entradas de losusuarios, por lo general en forma de parámetros de configuración o de actuacióncon base en los resultados. De forma similar, estos sistemas también puedenproducir salidas tradicionales a un monitor o impresora. De forma que la interfazdel usuario suele estar vinculada al dispositivo controlador, y es utilizada paraconfigurar y gestionar el sistema (véase la figura 1).

Figura 1: Elementos de la arquitectura de un sistema IoT.

58 Córdoba et al.

Conforme con lo anterior, la arquitectura de un sistemas de IoT, por logeneral, se compone de los siguientes elementos o dispositivos:

Interfaz para la interacción con los usuarios (entrada y salida): Lainterfaz permite que el usuario configure el sistema, ingrese los parámetrosde operación, revise resultados y ejecute operaciones. La función de lainterfaz es facilitar el control y la administración de los dispositivos queconforman un sistema IoT. Cuando se adquiere un sistema de IoT, la interfazde usuario puede venir incluida; pero cuando se desarrolla una soluciónpersonalizada, es necesario desarrollarla de acuerdo con los requerimientosdel sistema.

Adquisición de datos del entorno (entrada): Captura de datos delentorno por medio de sensores y los envía a la dispositivo de control parasu procesamiento.

Protocolos de comunicación (procesamiento): Se encargan delintercambio de información entre los dispositivos que conforman elsistema, y son un elemento crítico para su interconexión.

Equipo o software controlador (procesamiento): Es el equipo que recibelos datos de los sensores, los procesa y de acuerdo con rutinas preestablecidas,envía órdenes a los actuadores.

Procesamiento y análisis de los datos obtenidos (procesamiento): Loconforman los algoritmos y métodos que se encargan del tratamiento yanálisis de los datos. Los sistemas IoT pueden utilizar servicios en la nubepara almacenar y acceder recursos como bases de datos (e.g., SQL, NoSQLy NewSQL), servicios web y servidores.

Ejecución de tareas (salida): Cuando la salida del sistema conlleva unaactuación sobre el entorno, se ejecutan acciones por medio de actuadores paramodificar determinadas condiciones. Sin embargo, cuando se busca modificarlas condiciones del entorno, las tareas que se llevan a cabo pueden consistiren el análisis o ejecución de tareas adicionales de procesamiento.

Despliegue de resultados (salida): Los resultados se pueden desplegar enun monitor para que el usuario tenga conocimiento de las actuaciones querealiza el sistema, o simplemente para que el usuario tenga conocimiento delresultado del procesamiento, de forma similar a los sistemas tradicionales.

Una arquitectura más compleja es la propuesta por Intel (Intel, 2015), la cualcontempla el uso de un gran número de protocolos de comunicación, conexión asistemas de almacenamiento y análisis, y servidores locales y en la nube.

2.1. Interconexión de dispositivos

Las topologías de comunicación de los sistemas IoT se pueden clasificar comouno a uno (punto a punto), uno a muchos (estrella) y muchos a muchos (malla)(Pacelle, 2014). Según el tipo de topología que se utilice, los datos pueden serrecibidos, integrados y procesados por solo un dispositivo (el cual cumple lafunción de controlador general) o por cada dispositivo en el sistema.


En cualquiera de las topologías señaladas, los dispositivos receptores ytransmisores conforman segmentos de comunicación (véase la figura 1), quepueden utilizar diferentes protocolos. La clasificación genérica de estos segmentoses la siguiente:

Sensor - dispositivo de controlDispositivo de control – actuador

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

Tabla 1: Comparación de los protocolos más utilizados por IoT.Protocolo Uso Frecuencia Cobertura Otras característicasX1O Red eléctrica

doméstica120 KHz N/A Utiliza la red

eléctrica domésticacomo medio detransmisión.

NFC Aplicacionescon pocovolumen dedatos

13,56 MHz 10 cm Diseñado paraaplicaciones deautenticación.

KNX Domótica N/A N/A Paralelo a la redeléctrica.

ZigBee Datosinalámbricos

868 GHz 915GHz 2,4 GHz

10 a 75 m Diseñado para bajoconsumo de energía.

Z-Wave Datosinalámbricos

Menos de 1GHz (varíasegún el país)

30 a 200 m Tranmisión de bajapotencia.

Bluetooth Datosinalámbricos

2,4 GHz 10 m Utiliza enlaces defrecuencia libre.

RFID Datosinalámbricos

9-135 KHz13,56 MHz433 MHz y860-960MHz2,45-5GHz

2 a 100 m Tecnología conmayor rango deaplicaciones por lasfrecuencias en lasque opera.

SIGFOX Smart Cities 868 o 902MHz

3 a 5 Km Se considera lamejor opción paraSmart Cities por ladistancia que lograabarcar.

60 Córdoba et al.

Algunos protocolos mencionados en la tabla 1 comparten ciertascaracterísticas, como el tipo de aplicación o frecuencias de comunicaciones queutilizan, pero difieren en otras. Esto conlleva problemas de compatibilidad queles impiden interconectarse, y requiere el uso de puertas de enlace para lainterconexión de dispositivos que usan diferentes protocolos.

2.2. Puertas de enlace

Las puertas de enlace cumplen varias funciones además de servir comointermediarias en la comunicación entre dispositivos. Esas funciones puedenincluir el procesamiento de información, gestión de la seguridad y controlador oadministrador del sistema.

Las puertas de enlace puede ser implementadas por medio de software ohardware. En el caso de la implementación por software, por lo general se llevaa cabo usando bibliotecas internas. Estas bibliotecas se componen de interfacesprogramadas por los mismos desarrolladores de los protocolos, o por terceros,cuando el código fuente y admite la posibilidad de agregarle funcionalidad a losprotocolos. Estas interfaces son funciones que se pueden invocar desde diferenteslenguajes de programación. Por su parte, las puertas de enlace por hardwaresirven como punto de interconexión de dispositivos por medio de interfaces físicaso procesadores de comunicaciones inalámbricas de distintos tipos.

El proceso de interconexión que realizan las puertas de enlace por software yhardware requiere la desencapsulación y encapsulación de datos, para decodificary codificar la información en los formatos que utilizan tanto el origen como eldestino de la comunicación. Lo que implica que la puerta de enlace debe procesarlas unidades de datos del protocolo (UDP) para cada capa del modelo o estándarde comunicaciones que utilizan los dispositivos en un segmento.

En el mercado se encuentran disponibles varias puertas de enlace, tanto desoftware como hardware. Dell Edge Gateway permite varias conexiones cableadase inalámbricas (Dell, 2016b, 2016a) para interconectar protocolos como ZigBee,BACnet y ModBus, entre otros. Mientras que Intel IoT Gateway es una familiade productos (Intel, 2016) que permiten comunicar dispositivos por mediode ZigBee, Bluetooth, USB, VPN y Wi-Fi. Por su parte, Texas Instruments(Texas Instruments Incorporated, 2016) y EuroTech (Eurotech, 2016a, 2016b)también cuentan con puertas de enlace que tienen características similares a lasmencionadas.

3. Propuesta de diseño

Las arquitecturas comerciales de IoT pueden resultar costosas, lo cual poneen evidencia la necesidad de contar con un diseño cuya implementación seasencilla y económica. Con base en esto, este trabajo propone el diseño de unaarquitectura basada en una puerta de enlace que se compone de un dispositivode control, módulos de comunicación y bibliotecas para el intercambio deinformación entre el dispositivo de control y los módulos (véase la figura 2).


Figura 2: Arquitectura con dos módulos de comunicaciones.

El diseño propuesto toma ventaja de la arquitectura de Raspberry Pi(Raspberry Pi Foundation, 2016) y lo utiliza como dispositivo de control, porser una computadora de diseño reducido y propiedad registrada, pero de usolibre, lo cual permite que los usuarios puedan modificar y agregar módulos deacuerdo con sus necesidades. Así, por ejemplo, es posible que agreguen módulosde memoria adicional u otros módulos para comunicarse con diferentes protocolosy tecnologías como ZigBee, Z-Wave, RFID, 3G y GSM. Además, es importantedestacar que Raspberry Pi soporta el uso de Python, C, C++ y Ruby paraprogramar diferentes algoritmos.

El sistema operativo oficial de Raspberry Pi es una versión adaptada deDebian, denominada como RaspBian, y el precio de los módulos de comunicaciónque se le pueden agregar es relativamente bajo. Esto hace que el costo deimplementación de esta propuesta sea significativamente bajo, en comparacióncon las opciones de puertas de enlace propietarias que existen en el mercado.

El diseño propuesto contempla el uso de cualquiera de los protocolos de losmódulos que soporta Raspberry Pi, pero cabe señalar que de acuerdo con lainvestigación realizada, los protocolos más utilizados por los sistemas IoT sonZ-Wave y RFID.

3.1. Escenario de uso

Un edificio con un gran número de espacios cuenta con puertas de aperturay cierre automático, circuitos de iluminación, sistema de detección de incendiosy cámaras de seguridad con sensores de movimiento.

Cada día por la mañana, se deben abrir las puertas, encender las luces decada sitio de manera individual y revisar los vídeos de las cámaras. Este proceso,

62 Córdoba et al.

lo realiza solo una persona autorizada por razones de seguridad, pero presentalos siguientes inconvenientes:

La apertura de puertas y encendido de luces toma 10 minutos en la mañanay 10 minutos por la tarde.El personal que trabaja en las instalaciones no puede ingresar antes de suhora de entrada oficial, ni puede quedarse trabajando después de la hora desalida oficial. Esto afecta el desarrollo de algunos proyectos de alta prioridaddebido al proceso burocrático para justificar las razones de una jornadaespecial y, como consecuencia, se activa un protocolo de seguridad especial.La revisión de los vídeos puede tomar varias horas y es frecuente que serealice su revisión cuando sucede un incidente.

En general, la administración no puede conocer detalles sobre los eventos quese generan en torno a la apertura de puertas, iluminación, alarmas de incendio ycámaras, porque no cuenta con un sistema de alertas y estadísticas eficiente. Estoimpide que los administradores puedan reaccionar a tiempo ante emergencias ovariaciones en los patrones de comportamiento de los funcionarios y visitantes,por lo que la organización y el escenario descrito requieren considerar el diseñoe implementación de los siguientes sistemas:

Control: El fin de este sistema es controlar las luces, sensores de incendios,cámaras y la apertura de puertas utilizando los protocolos RFID y Z-Wave.

Gestión: El objetivo de este sistema es realizar el procesamiento de lainformación, enviar notificaciones de emergencia y realizar el análisis depatrones de identificación y comportamiento a partir de la información delos sensores y vídeos.

Conforme con lo anterior, el funcionamiento del subsistema de iluminación,apertura y cierre de puertas para este escenario se plantea de la siguiente forma:

El personal autorizado cuenta con una tarjeta RFID como medio deidentificación, cuya lectura es realizada por un módulo RFID.Una vez que la persona ha sido identificada, el sistema realiza la aperturade las puertas y el encendido de las luces mediante el envío de señales a losdispositivos 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 personalesdel empleado correspondiente, realizar la configuración de la red de dispositivosZ-Wave de acuerdo con las instrucciones de los fabricantes y programar losscripts en un lenguaje de programación, como Python. Las rutinas que debencomprender los scripts cuando el lector RFID detecta una tarjeta son lassiguientes:

Encender los circuitos de luces y abrir la cerradura de las puertas, si laúltima condición de las luces es “apagado” y la condición de las cerradurases “cerrado”.


Apagar los circuitos de luces y cerrar las puertas si la última condición delas luces es “encendido” y la condición de las cerraduras es “abierto”.

En cuanto al sistema de gestión de eventos y análisis de patrones, este seencuentra conformado por el dispositivo de control y el sistema de análisis(localizado en la nube). La secuencia de funcionamiento y procesamiento deeste sistema se realiza de acuerdo con la siguiente secuencia de pasos:

Dispositivo de control: Este dispositivo recibe datos de los diferentesdispositivos y envía notificaciones a las personas designadas por medio deun APP, de acuerdo con las reglas que tiene configuradas.

Procesamiento en la nube: El dispositivo de control además envía los datosde todos los eventos e imágenes que registran las cámaras a un sistema deanálisis en la nube.

Sistema de análisis: Este sistema se encuentra en la nube y se encargade procesar los datos conforme los recibe e integra los resultados delprocesamiento con los resultados históricos. El análisis que realiza estesistema contempla desde los eventos relacionados con la apertura y cierrede puertas, encendido de luces y movimientos registrados por los sensoreshasta el análisis de imágenes captadas por las cámaras con el fin de identificarpersonas y sus patrones de comportamiento.

Estadísticas y patrones: Los resultados del análisis son representados deforma visual para hacerlos más comprensibles y útiles para los usuarios.

En cuanto a la implementación del sistema completo, se requieren lossiguientes componentes de hardware:

Dispositivo de control - Raspberry Pi (PCB): Este dispositivo sedescribe como una minicomputadora con todas las características necesariaspara realizar las tareas de control y procesamiento de datos, pero ademásse conecta a la nube para enviar datos para su almacenamiento yprocesamiento. El modelo utilizado debe contar con puerto Ethernet oconexión usando 802.11n.

Módulos Z-Wave: Se recomienda utilizar Razberry (RaZberry, 2016), parapermitir la comunicación de sensores y actuadores que usan Z-Wave. Enconcreto, los dispositivos que utilizaran Z-Wave son los apagadores de luces,los elementos de cierre y apertura de puertas, los sensores de incendios y lascámaras.Razberry cuenta con una interfaz de usuario que permite su rápidaimplementación, pero también facilita el desarrollo de interfacespersonalizadas por encontrarse disponible la documentación del fabricantepara ese fin.

Módulo RFID: Este módulo permite la lectura de las tarjetas RFID y semantiene activado en modo de lectura al dispositivo de control (RaspberryPi), para que capte las señales transmitidas por las etiquetas RFID.

64 Córdoba et al.

4. Conclusiones

En este trabajo de investigación se llevó a cabo una revisión bibliográficasobre los principales protocolos y arquitecturas que se utilizan en IoT. Dicharevisión permitió analizar y discutir el estado actual de internet de las cosasy las implicaciones que tiene el uso de protocolos diferentes en los procesos deinterconexión y comunicación.

Como resultado, fue posible conocer con mayor detalle y poner demanifiesto la relación que existe entre los protocolos, dispositivos, fabricantesy arquitecturas en el proceso de comunicación. Esto permitió proponer unaarquitectura de bajo costo para la interconexión de protocolos y dispositivosheterogéneos en sistemas IoT.

Las ventajas del diseño presentado son su sencillez, posibilidades que ofrecepara la interconexión, facilidad de implementación, bajo costo, gestión de alertasy análisis de patrones. Esto lo hace ideal para resolver problemas de poca y mediacomplejidad, con personal poco especializado y sin necesidad de incurrir en altoscostos.

El subsistema de análisis de información que incorpora la propuestacontempla el uso de servidores locales o en la nube, y tiene por fin brindardetalle sobre los eventos y procesos que han sido atendidos y procesados por elsistema. Pero además proporcionar mecanismos de inteligencia para la detecciónde patrones anormales que pueden requerir la toma de acción inmediata.

Como trabajo futuro, se estará realizando la implementación de laarquitectura propuesta y se estarán desarrollando casos de uso de mayorcomplejidad para validar la arquitectura y agregar factores de escalabilidad ala propuesta.

Referencias

Ashton, K. (2009, June). That ’Internet of Things’ thing. Descargado de http://www.rfidjournal.com/articles/view?4986

Buxeres-Soler, A. (2014). Estudio y desarrollo de un sistema basado en unalibrería abierta para el uso del protocolo inalámbrico de domótica Z-Wave.

Cárdenes-Tacoronte, D. (2016). Diseño e implementación de una herramientapara la verificación de cobertura de la red SIGFOX. Estudio deconectividad en una zona geográfica de orografía compleja.

Chavarría, D. A. (s.f.). Tecnología de comunicacionón de campo cercano (nfc)y sus aplicaciones.

Cuevas, J. C., Martínez, J. y Merino, P. (2002). El protocolo x10: unasolución antigua a problemas actuales. En Simposio de informática ytelecomunicaciones (sit).

Dell. (2016a). Dell edge gateways for IoT. Descargado de http://www.dell.com/us/business/p/edge-gateway?s=bsd

Dell. (2016b). Edge Gateway 5000. Descargado de http://www.dell.com/us/business/p/dell-edge-gateway-5000/pd?ref=PD_OC

Referencias 65

Eurotech. (2016a). IoT Gateways: multi service IoT gateways. Descargado dehttps://www.eurotech.com/en/products/devices/iot+gateways

Eurotech. (2016b). ReliaGATE 10-11: compact Multi-Service IoT gateway,industrial-grade, TI AM3352. Descargado de https://www.eurotech.com/en/products/ReliaGATE%2010-11

Intel. (2015). Intel IoT Platform Reference Architecture. Descargado de http://www.intel.com.au/content/dam/www/public/us/en/documents/white-papers/iot-platform-reference-architecture-paper.pdf

Intel. (2016). Intel IoT gateway technology. Descargado de https://www-ssl.intel.com/content/www/us/en/embedded/solutions/iot-gateway/overview.html

Jara-Maldonado, P. A. (2015). Estudio y diseño de un sistema inmótico paraseguridad, comunicación y confort, utilizando el protocolo KNX para eledificio Torre Piamonte ubicado en el sector de Totoracocha de la ciudadde Cuenca.

Manyika, J., Chui, M., Bisson, P., Woetzel, J., Dobbs, R., Bughin, J. yAharon, D. (2016). Unlocking the potential of the Internet of Things.Descargado de http://www.mckinsey.com/business-functions/business-technology/our-insights/the-internet-of-things-the-value-of-digitizing-the-physical-world

Pacelle, M. (2014, April). 3 topologies driving IoT networkingstandards. Descargado de http://radar.oreilly.com/2014/04/3-topologies-driving-iot-networking-standards.html

Rana, M. (2016, June). Thirty-four percent rise in IoT development. Descargadode http://www.evansdata.com/press/viewRelease.php?pressID=237

Raspberry Pi Foundation. (2016). Raspberry Pi Foundation. Descargado dehttps://www.raspberrypi.org/

RaZberry. (2016). RaZberry Project. Descargado de https://razberry.z-wave.me/

Texas Instruments Incorporated. (2016). HVAC Gateway. Descargado dehttp://www.ti.com/solution/iot_gateway

The Z-Wave Alliance. (2016). The Internet of Things is powered by Z-Wave.Descargado de http://z-wavealliance.org/

ZigBee Alliance. (2016, July). The ZigBee Alliance creates IoT standardsthat help control your world. Descargado de http://www.zigbee.org/zigbeealliance/

Etiquetas de Geolocalización en imágenes rásterpara la identificación de especímenes biológicos

Jonathan Quintana Berríos, Esteban Robleto Rodríguez yAntonio González Torres∗



[jquintanab798,erobletor703]@[email protected]∗


Resumen La identificación de especímenes de la flora y fauna ayuda aconservar la riqueza de los ecosistemas al permitir conocer su composicióny niveles de riesgo, en términos de extinción, por lo que es necesarioque los científicos que llevan a cabo dicha identificación cuenten con losmétodos y herramientas necesarias para realizarla de forma efectiva yeficiente. En este contexto, el objetivo de este trabajo de investigaciónes apoyar la identificación de especímenes biológicos mediante el usode mapas con información georeferenciada, almacenada en imágenesráster, para lo cual se desarrolló una prueba de concepto para elprocesamiento de la información de georeferenciación, usando bibliotecasde código abierto. Esto permite obtener detalles sobre las zonas y áreasen las cuales se han encontrado muestras de una especie en particular.Como consecuencia, la principal contribución de este trabajo es laimplementación de una herramienta sencilla para extraer las coordenadasgeográficas de las localizaciones donde se han recolectado muestras deespecies biológicas.

Palabras clave: Analítica visual, GeoTIFF, GeoKey, imágenes ráster,metadatos, SIG

1. IntroducciónEl reconocimiento de especímenes biológicos representa un reto para los

científicos (biólogos), debido al número de características que las diferenciaentre sí a las especies de flora y fauna. En este contexto, el uso de elementostaxonómicos y claves de identificación reviste especial importancia, porquepermite clasificar las muestras por medio de sus características físicas visibles.

Los principales elementos que intervienen en el proceso de identificación,son los caracteres y los estados de carácter, en donde el término “carácter"hacereferencia a las características generales de las especies, mientras que “estadosde carácter"se refiere a las características específicas.

Etiquetas de geolocalización en imágenes ráster 67

Las herramientas especializadas para la identificación de especies que existen,tanto comerciales como no comerciales, se basan en árboles de decisión quepermiten elegir caracteres y estados de carácter de acuerdo con las característicasde la muestra. Sin embargo, el uso de información de geolocalización, relacionadacon los lugares donde han sido recolectadas las muestras de una especie, no hasido explorada de forma amplia, por lo que la utilización de información degeoreferencias, en conjunto con el uso de árboles de decisión, puede contribuircon el proceso de identificación de especímenes biológicos.

Conforme con lo anterior, este trabajo de investigación busca apoyar eldesarrollo de Iriria, una herramienta de analítica visual1, mediante el uso dela información georefenciada que se encuentra almacenada en mapas codificadoscomo imágenes ráster2. Cabe mencionar que los científicos pueden crear áreastrianguladas, las cuales podrían estar superpuestas, a partir de las localizacionesdonde han encontrado muestras de determinadas especies y que es posiblealmacenarlas en mapas ráster.

Como consecuencia, la sección 2 lleva a cabo una revisión detallada sobreel uso de imágenes ráster para la codificación y decodificación de informacióngeorefenciada, mientras que la sección 3 presenta los resultados del trabajoy la sección 4 discute las principales conclusiones y trabajo futuro de estainvestigación.

2. Estado del arte

Los archivos en formato GeoTIFF (Ritter y Ruth, 2000) permiten almacenartanto coordenadas geográficas como metadatos y pueden ser leídos con facilidadpor la mayoría de sistemas de información geográfica (SIG). Las imágenes queutilizan este formato son conocidas como imágenes ráster, y almacenan datosde georeferenciación en cada uno de los pixeles, los cuales forman parte deuna matriz conformada por cientos de pixeles que en conjunto proporcionaninformación detallada.

En una imagen ráster, por ejemplo, una matriz puede ser bidimensional otridimensional, en función del tipo de imagen. En el caso de las imagenes en2D, las coordenadas geográficas (i.e. latitud y longitud) se almacenan en uncuadrante x, y de la matriz, mientras que en el caso de las imágenes en 3D losdatos se almacenan en un cuadrante x, y, z para representar la profundidad dela imagen. De forma adicional, los valores contenidos dentro de los cuadrantes,se despliegan usando colores, los cuales pueden ser monocromáticos o primarios(azul, verde y rojo)3.

1 La analítica visual utiliza una combinación de visualización de la información,interacción persona-computadora y el razonamiento de las personas para la obtenciónde conocimiento (Aigner, Bertone y Miksch, 2008).

2 Ráster se refiere al término inglés raster, que hace referencia a imágenes quealmacenan metadatos relacionados con la representación gráfica que realizan.

3 Los colores rojo, verde y azul son conocidos por sus siglas en inglés como RGB.

68 Quintana et al.

Entre los tipos de archivos más comunes para el almacenamiento de imágenesráster se encuentran los siguientes:

BMP (bitmap).TIFF (Tag Image File Format).GIF (Graphics Interchange Format).JPEG (Joint Photographics Experts Group).

Para manipular las imágenes ráster existe un gran número de herramientascomerciales4 y no comerciales, pero también es posible encontrar bibliotecas paracrear aplicaciones propias. En este trabajo de investigación se está considerandoel uso de bibliotecas de código abierto para la manipulación de los mapas,codificados como imágenes ráster, para evitar las restricciones que imponen laslicencias de uso comercial.

El tamaño de las imágenes puede ser superior a los 4 gigabytes, en funciónde los metadatos que contengan, lo cual requiere que sean almacenadas en unformato conocido como BigTiff. Por esa razón, las imagenes se comprimen parafacilitar su manipulación, pero el tipo de compresión influye en la lectura deimágenes ráster y es necesario efectuar el procesamiento de forma correcta parano perder información. En el caso de la biblioteca de GeoTIFF, esta utiliza elformato de compresión “BitPack”.

El almacenamiento de información se realiza utilizando bytes en lugar debits, lo cual permite tener más datos comprimidos dentro de un archivo TIFF,y que a la hora de apuntar a una posición donde se encuentran agrupados unosy ceros, se pueda hacer referencia a una posición dentro del arreglo y no a unvalor particular5.

En los archivos TIFF la información se almacena usando cuadrículas decientos o miles de puntos en notación hexadecimal, y los agrupa en un arreglobidimensional usando grupos de 8, 16 y 32 bits. Para poder ubicar un valor en unarreglo dentro del espacio ráster, conocido también como R, es importante saberque los pixeles se ubican dentro de una cuadrícula. El área de pixeles se definepor medio de las coordenadas i (fila) y j (columna) para recorrer el arreglo.

Los metadatos que almacena el formato GeoTIFF están organizados enun catálogo de GeoKeys (GeoKeyDirectoryTag) (Ritter y Ruth, 2000), que sealmacena en el encabezado de los archivos. Las GeoKeys contienen etiquetasTIFF reservadas que tienen información pública o privada sobre una región olugar específico y usan un identificador numérico que se encuentra en un rangode 0 a 65535. No todas las GeoKeys se pueden utilizar de forma libre, debido aque pueden estar reservadas para usos específicos.

Los parámetros del encabezado de los archivos GeoTIFF se basan en unaestructura geográfica, que fue desarrollada por el European Petroleum SurveyGroup (EPSG/POSC). Estos parámetros se utilizan para identificar posiciones4 Entre las herramientas comerciales mejor conocidas para la manipulación deimágenes ráster se encuentran AutoCad, Adobe Ilustrator y Photoshop.

5 A esta forma de guardar datos dentro de un TIFF se le conoce como Big and LittleEndian.


geográficas en un sistema de coordenadas e implica la utilización de un sistemade estructuras elipsoides u ovaladas para identificar puntos dentro de la tierra,basados en referencias verticales u horizontales (Geodetic datums). Estos puntos,también conocidos como ejes, permiten definir tanto la latitud como la longitud,tomando en cuenta el paralelo 0 (conocido como Ecuador) para el caso de lalatitud y el meridiano de Greenwich para la longitud (Ritter y Ruth, 2000).

Como consecuencia, los archivos GeoTIFF requieren de un parGeoKey/nombre que está definido en la lista estándar de parámetros, para haceruna proyección del mapa de forma plana, usando la representación de la tierrapor medio de longitudes y latitudes.

3. Resultados

La implementación de la herramienta se llevó a cabo utilizando GeoTIFF(Schindler, 2015), una biblioteca en JavaScript para leer los metadatoscontenidos en las imágenes ráster (lhomme, 2014).

La lectura de una imagen ráster conlleva la identificación de las GeoKeysque se encuentran en la imagen en formato TIFF, lo cual requiere recorrer lospixeles de la imagen para obtener los metadatos. Una vez que se localizan losmetadatos, estos son extraídos y cargados por la herramienta, lo cual produce unefecto de cambio de color de la imagen, debido a que la información almacenadaen los metadatos es mostrada.

Las pruebas realizadas durante este trabajo utilizaron como referencia elmapa que se muestra en la figura 1, sobre la cual se proyectan las imágenes queson procesadas.

Figura 1: Imagen tomada de Open Street Maps (Foundation, 2006)

70 Quintana et al.

En el contexto de la identificación de especímenes biológicos, se requiere leerlas latitudes y longitudes de las ubicaciones geográficas en las cuales se hanrecolectado muestras de las especies biológicas, por lo que se lee la informaciónque se encuentra almacenada por las GeoKeys y se utilizan mapas en formatoplano.

El procesamiento de las imágenes se lleva a cabo usando una funcióndenominada loadmaps, la cual carga la imagen de un mapa ráster, para unaregión geográfica seleccionada. Esta función utiliza OpenLayers (Kirkman yDavis, 2014), una biblioteca de código abierto, para ubicar sobre el mapa (figura1) la imagen de la zona geográfica escogida, con base en los metadatos degeolocalización.

Una vez que la imagen ha sido cargada y procesada, es posible observar lainformación que tiene codificada (véanse las figuras 2 y 3).

Figura 2: Imagen luego de ser mapeada

Los pasos del algoritmo que se siguen una vez que la imagen es cargada, sonlos siguientes:


Figura 3: Imagen procesada por las librerías, los colores se encuentran definidos por lasetiquetas y, podrían ser utilizados para identificar datos en un mapa

1. Se realiza la búsqueda de una GeoKey dentro de los metadatos de la imagen,usando una variable denominada como fieldTagName.

2. Se obtienen los valores almacenados en la etiqueta asociada a la GeoKey.3. Se ejecuta una función para obtener un TagName. Esta función compara el

valor de la etiqueta y los valores de etiqueta que están definidas en el códigodel programa.

4. Se procede a buscar, mediante la variable fieldTypeNames, una GeoKey queindica el tipo de llave que contiene esa etiqueta.

5. El proceso utiliza una variable para guardar los valores obtenidos, para luegomostrarlos en el mapa.

La secuencia se repite el número de veces que sea necesario, en función delas GeoKeys en los metadatos de la imagen.

En el contexto de la identificación de especímenes biológicos, para determinarsi una muestra de una especie ha sido recolectada en una región, se realiza lalectura de la posición del puntero del ratón cuando se pasa sobre el mapa6, ycon base en las coordenadas geográficas (latitud y longitud), se consulta la basede datos para obtener una lista de las especies que se encuentran asociadas aesas coordenadas.

6 La lectura de posiciones geográficas se realiza mediante el uso del atributomouseposition.

72 Quintana et al.

4. ConclusionesEl almacenamiento de metadatos en mapas codificados como imágenes ráster

es un recurso valioso para asociar datos de diferente índole a localizacionesgeográficas específicas, por lo que en el contexto de la identificación deespecímenes biológicos resulta de gran utilidad para obtener detalles acerca delas especies que se han identificado en una zona o región particular.

Entre los detalles de las especies que se pueden almacenar en los mapas seencuentran la fecha en que las muestras fueron recolectadas, quién las recolectóy la institución a la cual se encuentra vinculado el recolector.

En general, el tratamiento de este tipo de imágenes no es un proceso trivial,se requiere de análisis y estudio para comprender los conceptos generales yespecíficos que luego pueden ayudar a estudiar el código y ejemplos de lasbibliotecas disponibles.

El principal aporte de este trabajo de investigación consiste en ladocumentación inicial de los conceptos relacionados con imágenes ráster y laimplementación de una prueba de concepto sobre la lectura de este tipo deimágenes, en el contexto del desarrollo de Iriria.

En línea con lo anterior, como trabajo futuro se estará ampliando la pruebade concepto para realizar la escritura de información, sobre las muestras deespecies, en las imágenes ráster, así como la integración de la implementacióncomo parte de Iriria.

ReferenciasAigner, W., Bertone, A. y Miksch, S. (2008). Introduction to visual analytics.

Danube University Krems, Austria.Foundation, O. (2006, aug). Openstreetmap. Descargado de https://www

.openstreetmap.org/Kirkman, R., y Davis, T. (2014). Openlayers 3. Descargado de https://

github.com/openlayers/ol3lhomme, X. (2014, dec). A javascript-based parser for the geotiff image format.

Descargado de https://github.com/xlhomme/GeotiffParser.jsRitter, N., y Ruth, M. (2000, dec). Geotiff format specification: Geotiff

revision 1.0. Descargado de http://www.remotesensing.org/geotiff/spec/geotiffhome.html

Schindler, F. (2015). Read raw data from geotiff files. Descargado de https://github.com/constantinius/geotiff.js

Caracterización de malware usando lenguajes deintercambio de inteligencia

Randall Barnett Villalobos, Susan Rodríguez Segura, Julio Chinchilla Moya yWilson Acuña Araya



[rbarnettv200,srodriguezs044,jchinchillam135,lacunaa475]@ulacit.ed.crhttp://www.ulacit.ac.cr

Resumen Para el año 2015, los laboratorios de Panda Securityprocesaron en promedio 230 mil muestras de malware por día, es decir,84 millones al año. Eso implicó un incremento de 9 millones más queen el 2014. Es en este escenario que el intercambio de inteligencia enel área de la seguridad informática busca convertirse en un estándarque permita compartir las características de las ciberamenazas de unamanera estándar. Con la utilización de metalenguajes de comunicacióny metalenguajes de observabilidad, se logra realizar el intercambiode información sobre amenazas entre distintas fuentes, efectuando lacaracterización de los archivos para compartir la información obtenidade forma estándar.

Palabras clave: Internet de las cosas, protocolos, comunicaciones

1. IntroducciónPara la identificación de nuevas amenazas es necesario profundizar en el tema

de lenguajes de intercambio de inteligencia. La organización MITRE proponevarios metalenguajes que permiten aprovisionar al investigador, de un sistemade caracterización y búsqueda entre distintas fuentes de información para ladetección de vulnerabilidades.

Estos metalenguajes son versátiles, ya que permiten crear herramientas desoftware por medio de los API de MITRE, para poder consultar la informaciónen tiempo real. Además, permiten obtener datos de diversas fuentes, ya seanpropias o proporcionadas por terceros, que sirven como una base de conocimientogratuita para la rápida resolución de incidentes de ciberseguridad.

La idea central de esta investigación es la creación de una herramienta de usolibre donde las organizaciones y empresas a nivel global tengan la facilidad deaprovisionar, consultar y colaborar con información de los archivos sospechososque detecten en sus sistemas al haber recibido algún ataque. Esta herramientaposee la capacidad de extraer datos relevantes de archivos sospechosos y

74 Barnett et al.

comparar la información obtenida para la caracterización de estas amenazas.En una segunda etapa, se espera que tenga la capacidad de compartir los datosimportantes de caracterización del malware informático en una base de datos deconocimiento global.

Para lograr la creación de esta herramienta, se utilizaron dos grupos demetalenguajes un framework de intercambio de información entre servidores quelas API de MITRE ofrecen:

1. Framework de comunicación: TAXII.2. Metalenguaje de comunicación: STIX.3. Metalenguajes de observabilidad: Se utilizaron MAEC y CybOX.

El intercambio de inteligencia trata del análisis de la información con el finde compartir los hallazgos encontrados en artefactos de software, para poderrealizar una caracterización de las amenazas. Esto permite: describir el tipo deataque ulterior, tener información importante de su origen, crear especificacionesde cómo reconocerlo y posteriormente analizar la manera de cómo evitarlo(EclecticIQ, 2016).

Los ataques por medio de la web buscan obtener información o acceso alos sistemas críticos de una organización. Para las empresas u organizaciones esvital tener conocimiento de las amenazas a las que se están enfrentando, por lotanto, a la hora de ocurrir un evento es obligatorio tener una base de datos deconocimiento con reportes detallados sobre determinados hallazgos de ataquesanteriores, propios o de terceros, lo que permite generar ciberinteligencia paraperfilar y evitar futuras amenazas.

Para realizar este proceso se utilizaron los API provistos en Python 2.X paraextraer información relevante de los archivos, estandarizarlos y ordenarlos deuna manera comprensible al ser humano, sin importar la fuente de procedencia.Lo anterior permite realizar la comunicación y el intercambio de inteligencia demanera sencilla, práctica y ordenada.

1.1. STIX

Este metalenguaje estandarizado presenta los datos de las amenazas deuna manera estructurada. Está compuesto por distintos objetos, a saber: losobservables, indicadores, incidentes, TTP, objetivos de exploits, cursos de accióny los reportes.

Este metalenguaje muestra la información en formato XML fuertementetipado, el cual es utilizado para representar los datos adquiridos de una formamás legible.

Para hacer uso de STIX se deben importar las siguientes librerías de Python:

import stix.utils as utilsfrom stix.utils import IDGenerator,set_id_methodfrom stix.core import STIXPackage,STIXHeader

Caracterización de malware usando lenguajes de intercambio de inteligencia 75

from stix.indicator import Indicatorfrom stix.common import InformationSource,

Identity

Además se debe crear un CybOX File Object, el cual va a contener unhash del archivo a caracterizar, como parte de un identificador único (SecurityIntelligence, IBM, 2015). A partir de esto se construye el paquete STIX y seadjunta 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 desoftware de forma unívoca, haciéndolo observable, se hace de la siguiente manera:

indicator = Indicator()indicator.title ="observable indicator" +file.file_nameindicator.description ="An indicator containing the observable"indicator.set_producer_identity("ULACIT Costa Rica")indicator.set_produced_time(utils.dates.now())indicator.add_object(file)

Los pasos subsecuentes servirán para poder compartir el objeto observable,por lo que se debe añadir la fuente de información, para lo cual se usarán losparámetros de inicialización a fin de establecer los nombres de las herramientasy de los proveedores del hallazgo. Es necesario, como todo XML fuertementetipado, darle las cabeceras adecuadas para que sea inspeccionado por el API yañadirlo a la colección de paquetes de STIX :

stix_header.information_source =InformationSource()tool = ToolInformation(

tool_name="Intel-Sharing",tool_vendor="The MITRE Corporation"

)stix_package.stix_header = stix_headerstix_package.add(indicator)return stix_package.to_xml()

1.2. TAXII

TAXII no se refiere a un programa de intercambio, sino a un conjunto deespecificaciones para el intercambio de información de amenazas cibernéticas

76 Barnett et al.

y así ayudar a las organizaciones a compartir información relevante sobreestas amenazas. Este framework trabaja como un mecanismo de transportepara STIX que estandariza automáticamente la información sobre amenazas(MITRE, 2014).

TAXII tiene tres modelos de reparto de información:

1. Hub and spoke: donde una organización funciona como un centro orepositorio de intercambio de información para distintas organizaciones quepueden ver e incluir información.

2. Source/subscriber : donde una organización funciona como una única fuentede información para otras organizaciones donde solamente pueden ver lainformación.

3. Peer to Peer : donde dos o más organizaciones comparten información entresí directamente.

TAXII define el comportamiento de cuatro servicios, con respecto a cómoesa información será compartida:

1. Bandeja de entrada: un servicio para recibir contenido insertado, esbásicamente un oyente de contenido entrante.

2. Encuesta: un servicio para solicitar contenido de una fuente de datos.3. Gestión de cobros: un servicio para conocer y solicitar suscripciones a

colecciones de datos.4. Descubrimiento: Un servicio para aprender cuáles servicios son compatibles

y cómo interactuar con ellos.

Para hacer uso de TAXII, se deben importar las siguientes librerías:

libbtaxii que contiene información de la versión y métodos para mensajes derespuestas HTTP.libtaxii clients: para clientes HTTP y HTTPS.libtaxii constants: contiene constantes.libtaxii messages: crea, maneja y analiza los mensajes.

El siguiente código muestra la forma de construir el mensaje:

import libtaxii as timport libtaxii.clients as tcimport libtaxii.messages as tm11from 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 servidorreturn message

El siguiente código es la respuesta del estado del mensaje proporcionado porTAXII.

HTTP/1.1 200 OKDate: Fri, 19 Ene 2016 13:22:04 GMTServer: Apache/2.2 (Linux Kali)X-TAXII-Protocol:urn:taxii.mitre.org:protocol:http:1.0X-TAXII-Content-Type:urn:taxii.mitre.org:message:xml:1.1X-TAXII-Services:urn:taxii.mitre.org:services:1.1Content-Type: application/xmlTransfer-Encoding: chunkedConnection: keep-aliveProxy-Connection: keep-alive

<taxii_11:Status_Messagexmlns:taxii_11="http://taxii.mitre.org/messages/taxii_xml_binding-1.1"message_id="59222"in_response_to="36508"status_type="SUCCESS"/>

Estas cabeceras viajarán entre servidores que consuman el servicio web queaprovisione el mensaje.

1.3. Relación entre STIX y TAXII

Esta relación permitirá el intercambio y el transporte de información sobreamenazas entre distintas organizaciones. TAXII puede transmitir en su cargaútil el paquete de STIX, y definirá cómo se va a compartir esta información através de la red local o global. En la figura 1 se muestra cómo interactúan entresí los metalenguajes de STIX y TAXII.

2. Analizador de direcciones IPEl analizador es una aplicación funcional para el análisis de cualquier

dirección IP en distintas bases de datos, con el fin de obtener información de

78 Barnett et al.

Figura 1: Interacción entre STIX y TAXII

su estado y ubicación geográfica. Además de analizar la IP deseada, es posiblevisualizar y agregar otras direcciones de páginas web de lista negra a la base dedatos. En la figura 2 se muestra la imagen del resultado obtenido en la aplicaciónIntel-Sharing, donde identifica la información, los servidores donde se encuentraen lista negra y la ubicación aproximada de la dirección IP ingresada.

Figura 2: Resultado del analizador Web de direcciones IP

3. Virus total

A la aplicación de intercambio de inteligencia se le incluyó el API oficialde Virus Total, con el cual se le aplica un valor agregado a los reportes, dondese indica la cantidad de detecciones por antivirus que fueron encontrados en elarchivo analizado.

La herramienta Virus Total tiene la función de indicar si el archivo que seestá analizando para ser caracterizado cuenta con algún tipo de código malicioso,


el cual es detectado por alguno de los motores de antivirus con los que cuenta elAPI.

Primero se procede a verificar el hash en la base de datos local, luego severifica este mismo dato en Virus Total, el cual proporciona el resultado. Luegode verificar el archivo malicioso, se procede a realizar el empaquetado de lainformación con STIX, se prepara el paquete STIX con las cabeceras TAXIIpara el intercambio, se guarda el resultado en la base de datos dejando el archivoresultante en formato XML en el servidor y, por último, muestra la informaciónrespectiva en pantalla (Barnum, 2014).

4. Resultados

El tema de lenguajes de intercambio de información aún está pocodesarrollado, con su utilización se pueden explorar muchas funcionalidades útilespara cualquier empresa, sea cual sea la orientación del negocio. Existe grancantidad de información que se puede obtener realizando la caracterización deun archivo malicioso. Se logró caracterizar más de 100 artefactos de software,almacenando la información resultante en una base de datos MySQL, queincluye:

Números de identificación unívocos.Listas negras de donde se encuentra el elemento caracterizado y resultadosde escaneos en más de 60 antivirus por cada artefacto analizado.Caracterizaciones completas de cada artefacto de software analizado.Listado de direcciones IP y DNS encontrados en listas negras.

Figura 3: Reporte de aplicación Intel-Sharing.

80 Barnett et al.

5. ConclusionesEl tema de los metalenguajes para el intercambio de información aún está

poco desarrollado. Con su utilización se pueden explorar muchas funcionalidadesútiles para cualquier empresa, sea cual sea la orientación del negocio. Existegran cantidad de información que se puede obtener al realizar la caracterizaciónde un archivo malicioso, el cual conlleva investigar más a fondo para sacarlemayor provecho a estos metalenguajes. Actualmente se desconoce o no se manejamuy bien el concepto de este tipo de herramientas (las cuales se pueden utilizarde manera gratuita), y no existe documentación extensa sobre el tema, lo quedificulta la implementación de este tipo de aplicaciones.

6. RecomendacionesLos lenguajes de intercambio de inteligencia, deben ser investigados más a

fondo, debido a que abarcan un sinnúmero de funcionalidades, las cuales nofueron desarrolladas en su totalidad en este proyecto. Es importante seguirdesarrollando funcionalidades de CyBOX y MAEC, así como STIX y TAXII.Aún se debe modificar la manera de trabajar de STIX para que reciba lainformación requerida por medio de parámetros. Un punto importante paraaplicar en la siguiente investigación es la implementación de un analizador demalware como Anubis, el cual brindará un informe en distintos formatos quepuede ser relacionado con MAEC y así lograr la caracterización completa. Sedebe agregar seguridad a la aplicación e implementar sockets para mejorar elrendimiento de la aplicación, para que logre leer más de un archivo (por ejemplouna carpeta completa con n cantidad de archivos). Se debe continuar con eldesarrollo de un servidor TAXII donde se pueda recibir el paquete que estálisto, para ser enviado por la aplicación y de esta manera realizar el procesocompleto de intercambio de inteligencia.

ReferenciasBarnum, S. (2014, feb). Standardizing cyber threat intelligence information

with the structured threat information expression (stix™). Descargado dehttp://stixproject.github.io/getting-started/whitepaper/

EclecticIQ. (2016, apr). Stix and taxii threat intelligence analysis. Descargadode https://www.eclecticiq.com/stix-taxii.html

MITRE. (2014, jan). Taxii-specifications. Descargado de https://github.com/TAXIIProject/TAXII-Specifications

Security Intelligence, IBM. (2015, mar). Stix, taxii and cyboxcan help with standardizing threat information. Descargado dehttps://securityintelligence.com/how-stix-taxii-and-cybox-can-help-with-standardizing-threat-information/

Tecnologías de la Informacióny Gestión de ProyectosDr. Antonio González Torres (Ed.)

Documents

Tecnologías de la Información y Gestión de ProyectosasInformaciónGestiónProyectos.pdf · prácticas para la gestión de proyectos de software en procesos de tercerización