Novática nº 211, mayo-junio 2011, año XXXVII · discutible de las redes sociales, de las aplica-ciones de distribución instantánea de con-tenidos, o de todo ese conjunto de aplicacio-nes

Nº 211, mayo-junio 2011, año XXXVII Nº 211, mayo-junio 2011, año XXXVII Nº 211, mayo-junio 2011, año XXXVII Nº 211, mayo-junio 2011, año XXXVII Nº 211, mayo-junio 2011, año XXXVII

Tema del próximo número: "Innovación y emprendimiento en Informática"

editorialEl papel de las TIC en los movimientos sociales > 02en resumenInteligencia de negocios en clave de presente > 02Llorenç Pagés CasasNoticias de IFIPReunión del TC-1 (Foundations of Computer Science) > 03Michael Hinchey,Karin Breitman, Joaquim GabarróReunión anual del TC-10 (Computer Systems Technology) > 04Juan Carlos López LópezActividades de ATIV Edición del Premio Novática > 05

monografíaBusiness Intelligence(En colaboración con UPUPUPUPUPGRADE)Editor invitado: Jorge Fernández GonzálezPresentación. Business Intelligence: analizando datos para extraernueva información y tomar mejores decisiones > 06Jorge Fernández GonzálezBusiness Information Visualization: Representación de la información empresarial > 08Josep Lluís Cano GinerBI Usability: evolución y tendencia > 16R. Dario Bernabeu, Mariano A. García MattíoFactores críticos de éxito de un proyecto de Business Intelligence > 20Jorge Fernández González, Enric Mayol SarrocaModelos de construcción de Data Warehouses > 26José María Arce ArgosData Governance: ¿qué?, ¿cómo?, ¿por qué? > 30Óscar Alonso LlombartBusiness Intelligence y pensamiento sistémico > 35Carlos Luis GómezCaso de estudio: Estrategia BI en una ONG > 39Diego Arenas Contreras

secciones técnicas

ArquitecturasExtensiones al núcleo de Linux para reducir los efectos del envejecimientodel software > 43Ariel Sabiguero, Andrés Aguirre, Fabricio González, Daniel Pedraja, Agustín Van RompaeyDerecho y tecnologíasLa protección de datos personales en el desarrollo de software > 50Edmundo Sáez PeñaEnseñanza Universitaria de la InformáticaReorganización de las prácticas de compiladores para mejorarel aprendizaje de los estudiantes > 56Jaime Urquiza Fuentes, Francisco J. Almeida Martínez, Antonio Pérez CarrascoEstándares WebEspecificación y prueba de requisitos de recuperabilidad entransacciones WS-BusinessActivity > 61Rubén Casado Tejedor, Javier Tuya González, Muhammad YounasReferencias autorizadas > 70

sociedad de la información

Informática prácticaCriptoanálisis mediante algoritmos genéticos de una comunicación cifradaen la Guerra Civil > 71Tomás F. Tornadijo RodríguezProgramar es crearEl problema del decodificador(Competencia UTN-FRC 2010, problema C, enunciado) > 75Julio Javier Castillo, Diego Javier SerranoTriangulo de Pascal y la Potencia Binomial(Competencia UTN-FRC 2010, problema E, solución) > 76Julio Javier Castillo, Diego Javier Serrano, Marina Elizabeth Cardenas

asuntos interiores

Coordinación editorial / Programación de Novática / Socios Institucionales > 77

sumario

NováticaNováticaNováticaNováticaNovática, revista fundada en 1975 y decana de la prensainformática española, es el órgano oficial de expresión y for-mación continua de ATI ATI ATI ATI ATI (Asociación de Técnicos de Infor-mática), organización que edita también la revista REICISREICISREICISREICISREICIS(Revista Española de Innovación, Calidad e Ingeniería delSoftware). Novática Novática Novática Novática Novática co-edita asimismo UPUPUPUPUPGRADE, re-vista digital de CEPIS CEPIS CEPIS CEPIS CEPIS (Council of European ProfessionalInformatics Societies), en lengua inglesa, y es miembro fun-dador de UPUPUPUPUPENET (UPUPUPUPUPGRADE EEEEEuropean NETNETNETNETNETwork).

<http://www.ati.es/novatica/><http://www.ati.es/reicis/>

<http://www.cepis.org/upgrade>

ATIATIATIATIATI es miembro fundador de CEPIS CEPIS CEPIS CEPIS CEPIS (Council of European ProfessionalInformatics Societies) y es representante de España en IFIP IFIP IFIP IFIP IFIP (InternationalFederation for Information Processing); tiene un acuerdo de colaboracióncon ACMACMACMACMACM (Association for Computing Machinery), así como acuerdos devinculación o colaboración con AdaSpainAdaSpainAdaSpainAdaSpainAdaSpain, AI2AI2AI2AI2AI2, ASTICASTICASTICASTICASTIC, RITSI RITSI RITSI RITSI RITSI eHispalinuxHispalinuxHispalinuxHispalinuxHispalinux, junto a la que participa en ProInnovaProInnovaProInnovaProInnovaProInnova.

Consejo EditorialIgnacio Agulló Sousa, Guillem Alsina González, María José Escalona Cuaresma, Rafael Fernández Calvo(presidente del Consejo), Jaime Fernández Martínez, Luís Fernández Sanz, Dídac Lopez Viñas,Celestino Martín Alonso, José Onofre Montesa Andrés, Francesc Noguera Puig, Ignacio PérezMartínez, Andrés Pérez Payeras, Víktu Pons i Colomer, Juan Carlos Vigo López

Coordinación EditorialLlorenç Pagés Casas <[email protected]>Composición y autoediciónJorge Llácer Gil de RamalesTraduccionesGrupo de Lengua e Informática de ATI <http://www.ati.es/gt/lengua-informatica/>AdministraciónTomás Brunete, María José Fernández, Enric Camarero, Felicidad López

Secciones Técnicas - CoordinadoresAcceso y recuperación de la InformaciónJosé María Gómez Hidalgo (Optenet), <[email protected]>Manuel J. Maña López (Universidad de Huelva), <[email protected]>Administración Pública electrónicaFrancisco López Crespo (MAE), <[email protected]>ArquitecturasEnrique F. Torres Moreno (Universidad de Zaragoza), <[email protected]>Jordi Tubella Morgadas (DAC-UPC), <[email protected]>Auditoría SITICMarina Touriño Troitiño, <[email protected]>Manuel Palao García-Suelto (ATI), <[email protected]>Derecho y tecnologíasIsabel Hernando Collazos (Fac. Derecho de Donostia, UPV), <[email protected]>Elena Davara Fernández de Marcos (Davara & Davara), <[email protected]>Enseñanza Universitaría de la InformáticaCristóbal Pareja Flores (DSIP-UCM), <[email protected]>J. Ángel Velázquez Iturbide (DLSI I, URJC), [email protected]>Entorno digital personalAndrés Marín López (Univ. Carlos III), <[email protected]>Diego Gachet Páez (Universidad Europea de Madrid), <[email protected]>Estándares WebEncarna Quesada Ruiz (Virati), <[email protected]>José Carlos del Arco Prieto (TCP Sistemas e Ingeniería), <[email protected]>Gestión del ConocimientoJoan Baiget Solé (Cap Gemini Ernst & Young), <[email protected]>Informática y FilosofíaJosé Angel Olivas Varela (Escuela Superior de Informática, UCLM), <[email protected]>Karim Gherab Martín (Harvard University), <[email protected]>Informática GráficaMiguel Chover Sellés (Universitat Jaume I de Castellón), <[email protected]>Roberto Vivó Hernando (Eurographics, sección española), <[email protected]>Ingeniería del SoftwareJavier Dolado Cosín (DLSI-UPV), <[email protected]>Daniel Rodríguez García (Universidad de Alcalá), <[email protected]>Inteligencia ArtificialVicente Botti Navarro, Vicente Julián Inglada (DSIC-UPV), <{vbotti,vinglada}@dsic.upv.es>Interacción Persona-ComputadorPedro M. Latorre Andrés (Universidad de Zaragoza, AIPO), <[email protected]>Francisco L. Gutierrez Vela (Universidad de Granada, AIPO), <[email protected]>Lengua e InformáticaM. del Carmen Ugarte García (ATI), <[email protected]>Lenguajes informáticosÓscar Belmonte Fernández (Univ. Jaime I de Castellón), <[email protected]>Inmaculada Coma Tatay (Univ. de Valencia), <[email protected]>Lingüística computacionalXavier Gómez Guinovart (Univ. de Vigo), <[email protected]>Manuel Palomar (Univ. de Alicante), <[email protected]>Mundo estudiantil y jóvenes profesionalesFederico G. Mon Trotti (RITSI), <[email protected]>Mikel Salazar Peña (Area de Jovenes Profesionales, Junta de ATI Madrid), <[email protected]>Profesión informáticaRafael Fernández Calvo (ATI), <[email protected]>Miquel Sàrries Griñó (ATI), <[email protected]>Redes y servicios telemáticosJosé Luis Marzo Lázaro (Univ. de Girona), <[email protected]>Juan Carlos López López (UCLM), <[email protected]>RobóticaJosé Cortés Arenas (Sopra Group), <[email protected]>Juan González Gómez (Universidad Carlos III), <[email protected] Areitio Bertolín (Univ. de Deusto), <[email protected]>Javier López Muñoz (ETSI Informática-UMA), <[email protected]>Sistemas de Tiempo RealAlejandro Alonso Muñoz, Juan Antonio de la Puente Alfaro (DIT-UPM),<{aalonso,jpuente}@dit.upm.es>Software LibreJesús M. González Barahona (Universidad Politécnica de Madrid), <[email protected]>Israel Herráiz Tabernero (UAX), <[email protected]>Tecnología de ObjetosJesus García Molina (DIS-UM), <[email protected]>Gustavo Rossi (LIFIA-UNLP, Argentina), <[email protected]>Tecnologías para la EducaciónJuan Manuel Dodero Beardo (UC3M), <[email protected]>César Pablo Córcoles Briongo (UOC), <[email protected]>.Tecnologías y EmpresaDidac López Viñas (Universitat de Girona), <[email protected]>Francisco Javier Cantais Sánchez (Indra Sistemas), <[email protected]>Tendencias tecnológicasAlonso Alvarez García (TID), <[email protected]>Gabriel Martí Fuentes (Interbits), <[email protected]>TIC y TurismoAndrés Aguayo Maldonado, Antonio Guevara Plaza (Univ. de Málaga), <{aguayo, guevara}@lcc.uma.es>

Las opiniones expresadas por los autores son responsabilidad exclusiva de losmismos.Novática Novática Novática Novática Novática permite la reproducción, sin ánimo de lucro, de todos los artículos, amenos que lo impida la modalidad de © o copyright elegida por el autor, debiéndoseen todo caso citar su procedencia y enviar a Novática Novática Novática Novática Novática un ejemplar de la publicación.

Coordinación Editorial, Redacción Central y Redacción ATI MadridPadilla 66, 3º, dcha., 28006 MadridTlfn.914029391; fax.913093685 <[email protected]>Composición, Edición y Redacción ATI ValenciaAv. del Reino de Valencia 23, 46005 ValenciaTlfn./fax 963330392 <[email protected]>Administración y Redacción ATI CataluñaVia Laietana 46, ppal. 1ª, 08003 BarcelonaTlfn.934125235; fax 934127713 <[email protected]>Redacción ATI AragónLagasca 9, 3-B, 50006 Zaragoza.Tlfn./fax 976235181 <[email protected]>Redacción ATI Andalucía <[email protected]>Redacción ATI Galicia<[email protected]>Suscripción y Ventas <http://www.ati.es/novatica/interes.html>, ATI Cataluña, ATI MadridPublicidadPadilla 66, 3º, dcha., 28006 MadridTlnf.914029391; fax.913093685 <[email protected]>Imprenta: Derra S.A., Juan de Austria 66, 08005 Barcelona.Depósito legal: B 15.154-1975 -- ISSN: 0211-2124; CODEN NOVAECPortada: Resolución en marcha - Concha Arias Pérez / © ATIDiseño: Fernando Agresta / © ATI 2003

novática nº 211 mayo-junio 20112

editorial

El papel de las TIC en los movimientos socialesEl papel de las TIC en los movimientos socialesEl papel de las TIC en los movimientos socialesEl papel de las TIC en los movimientos socialesEl papel de las TIC en los movimientos sociales

en resumen Inteligencia de negocios en clave de presente

Llorenç PLlorenç PLlorenç PLlorenç PLlorenç Pagés Casasagés Casasagés Casasagés Casasagés CasasCoordinación Editorial de NováticaNováticaNováticaNováticaNovática

Encontramos constantemente, entre las no-ticias de actualidad, referencias directas oindirectas a actividades relacionadas con elmundo de la informática. Los grandes mo-vimientos sociales, a los que asistimos comoespectadores o participantes, no hubieranpodido producirse sin el protagonismo in-discutible de las redes sociales, de las aplica-ciones de distribución instantánea de con-tenidos, o de todo ese conjunto de aplicacio-nes que surge diariamente alrededor delmundo de la movilidad.

Los sistemas de información, que desde susorígenes no han parado de evolucionar yextenderse en todos los niveles del tejidoempresarial y económico, han irrumpidoahora también en el tejido social comoelemento ya casi indispensable en la vida demuchas personas, en un proceso de evolu-ción continua que genera diariamente nue-vas maneras de entender y utilizar las tecno-logías de la información, haciéndolas, enocasiones, auténticas protagonistas enmuchos de los acontecimientos socialesmás relevantes.

Un reto y una oportunidad en un escenariocaracterizado por un crecimiento exponencialen la diversidad de actores y herramientas alque hemos de adaptarnos, haciéndose necesa-rio un punto de encuentro como ATI, dondedamos protagonismo a quienes lideran loscambios y fomentamos un ecosistema soste-nible en el que convivan armónicamente pro-fesionales de todas las procedencias.

En línea con esta realidad se han creado recien-temente en ATI varios grupos de interés(focalizados en mercado profesional senior,gobierno TI o internacionalización) que servi-rán para que profesionales de todas las edadesamplíen su visión en las ultimas tendencias.

Y creemos en este modelo de crecimientoprofesional porque, inmersos en una carre-ra tecnológica donde lo de ayer ya no vale yel hoy es una versión beta del futuro, loinnovador es la norma y como tal no pode-mos esperar a que madure para adoptarlo.

Volviendo a los titulares de la actualidad,los medios de comunicación nos hablan de

movimientos en la sociedad civil que recla-man una transformación ética. Con unmodelo aún por concretar, asambleario enorigen, ha dejado huella en la política demuchos países, con especial transcendenciaen Egipto y Túnez.

ATI, como asociación, también tiene obje-tivos sociales y desea ser útil a la sociedad.Por esto, apostamos tradicionalmente pormantener canales de comunicación con re-presentantes políticos, sindicales, asocia-ciones empresariales, universidades y otrasentidades docentes u otras asociacionesinformáticas.

Veremos cómo influyen en España los mo-vimientos nacidos alrededor del 15-M, peromás que esperar consecuencias directas ennuestro sector, constatamos que el modeloasociacionista se encuentra de nuevo enauge.

La Junta Directiva General de ATILa Junta Directiva General de ATILa Junta Directiva General de ATILa Junta Directiva General de ATILa Junta Directiva General de ATI

Es sabido que la raíz etimológica del nombrede nuestra revista nos obliga a apuntar haciala presentación de "novnovnovnovnov"edades relacionadascon nuestras tecnologías informáticas y conlas prácticas necesarias para sacar provechode ellas.

Esto, sin duda, nos condiciona en bastantesocasiones a hablar en clave de futuro, ya que loque es "novnovnovnovnov"edad suele tardar un tiempo (aun-que en estos tiempos "vertiginosos" pueda sercada vez menos) en ser llevado a la práctica.

Sin embargo, en la monografía de este núme-ro quizás la principal novedad en cuanto aplanteamiento es que vamos a hablar en ra-bioso presente.

Efectivamente, para hablarnos de "BusinessIntelligence" (un área de trabajo que en caste-llano podría denominarse "inteligencia de ne-gocios" o quizás "inteligencia empresarial") ycon la inestimable ayuda de nuestro editorinvitado Jorge Fernández GonzálezJorge Fernández GonzálezJorge Fernández GonzálezJorge Fernández GonzálezJorge Fernández González (di-rector de Consultoría en Business Intelligencede Abast Systems), hemos optado principal-mente por seleccionar un grupo de destaca-dos profesionales para que nos cuenten sus

experiencias, vivencias y lecciones aprendidassacadas directamente del ámbito empresa-rial.

Y es que los sistemas y herramientas de losque hablamos en esta monografía son direc-tamente herederos de los "antiguos" sistemasde ayuda a la toma de decisiones o sistemasdecisionales que se empezaron a concebirhace ya varias décadas a partir de la apariciónde las hojas de cálculo y de las herramientasgráficas de presentación.

A todos nos habrán contado alguna vez queel modo de construcción de esos sistemasdecisionales (por contraposición con lostransaccionales) suele ser bastante másartesanal de lo habitual. Y así podríamosdecir que cada decisor y cada decisión "son unmundo", hasta llegar a la conclusión de queseguramente el mejor método para ponerse aldía en este tema es acercarse a los expertos dela empresa e irles preguntando uno a uno,"¿Qué tal te va a tí?".

Personalmente, pienso que nos hemos defelicitar por haber conseguido brillantes y bienelaboradas "respuestas" por parte de todos

los autores. Quede constancia por ello denuestro agradecimiento.

Este número se completa además, en el restode bloques, con una rica selección de artículosque tratan desde interesantes reportes de in-vestigación procedentes de congresos en losque ATI es entidad colaboradora, hasta otroscontenidos de carácter más práctico que eneste caso se concretan en un artículo deEdmundo Sáez PeñaEdmundo Sáez PeñaEdmundo Sáez PeñaEdmundo Sáez PeñaEdmundo Sáez Peña conteniendo intere-santes recomendaciones sobre el desarrollode sistemas que cumplan con los requisitos deprotección de datos personales, y un instruc-tivo ejercicio de descifrado de mensajes conconnotaciones históricas a cargo de TomásTomásTomásTomásTomásF. Tornadijo RodríguezF. Tornadijo RodríguezF. Tornadijo RodríguezF. Tornadijo RodríguezF. Tornadijo Rodríguez.

Espero que disfrutéis de esta amplitud detemas... como preámbulo por supuesto demayores disfrutes estivales.

Un fuerte abrazo,

novática nº 211 mayo-junio 2011 3

Noticias de IFIPNoticias de IFIPNoticias de IFIPNoticias de IFIPNoticias de IFIP

El TC-1 se reunió en la Universidad del Sarre,Saarbrücken (Alemania) el 3 de abril de 2011.Ante todo, Michael Hinchey dio la bienvenidaa los asistentes e invitados. Explicó que Fran-cia se ha reincorporado de nuevo a IFIP.

Se trataron los siguientes puntos:1) Se informó sobre la organización de lospróximos WCC (World ComputerCongress). Dicha conferencia ha sidodeficitaria durante los últimos cinco años.Entre las causas se cita el precio de la inscrip-ción, la existencia de múltiples sesiones para-lelas en distintos tópicos y la falta de interéspor los eventos comunes. Como consecuen-cia, IFIP esta replanteándose su formato. Sepiensa en organizarlo contando con la parti-cipación de profesionales de la informática ypolíticos (Comisión Europea) de primer ni-vel. El tema giraría alrededor de una sociedadde la información segura, fiable e innovadora:“Las tecnologías de la información juegan unpapel clave en la sociedad global del siglo 21.La tecnología informática es cada vez más unmotor de la economía, facilita la innovaciónen muchas industrias y organizaciones guber-namentales, entre otras cosas, apoya a lademocracia y al desarrollo personal…”.Maurice Nivat preguntó en qué medida lasociedad de la información constituye real-mente un apoyo (y no lo contrario) a lademocracia. Tras debatir estos temas se su-girió que los grupos TC-9, TC-1.7 y TC-11podrían estudiar este punto.

2) Luego pasó a discutirse el futuro de laconferencia TCS (Theoretical ComputerScience) organizada por TC-1 y hasta ahoraligada a WCC. Michael Hinchey plantea laposibilidad de organizar TCS en Daghstuhl.Jos Baeten sostiene que aunque hay variasconferencias en el área de TCS no hay ningunaque cubra toda la teoría. Con los años TCSha visto una gran asistencia. Cree que hayespacio para organizar TCS con algún otroevento, sugiere organizarla en 2012 coinci-diendo (pero como evento independiente) conel WCC. Todos coinciden en que TCS debeproseguir.

3) Jose Fiadeiro planteó la cuestión de laevaluación de las conferencias y la clasifica-ción de TCS. Actualmente TCS está en la

categoría C, sobre todo debido al hecho deque se ve como parte de WCC. Para asegurarla amplitud de temas, Andrzej Tarlecki co-mentó que no cree que una conferencia quecubra temas muy amplios se pueda organizarsiguiendo el modelo tradicional. Tambiéncree que la co-localización con otros eventoses secundaria. Joaquim Gabarró comentaque sería interesante un debate sobre el futurode las Ciencias de la Computación. ¿Qué nosgustaría que fueran en el futuro? Quizá estoaumentaría el interés de los participantesevitando ponentes que solo están interesadosen presentar su trabajo y que luego desapare-cen.

4) En el siguiente punto se presentaron losinformes de los distintos grupos de trabajo.Cathy Meadows del WG 1.7 informó queTaska es ahora un evento principal en ETAPS.Tienen 3 años para demostrar la viabilidad.

5) Las finanzas fueron el siguiente punto.Mike comenta que varios eventos no enten-dieron que tenían que pagar a IFIP (10 euros/día, 5 euros/día en casos difíciles). De estascuotas el 75% va al TC y 25% para financiarIFIP. Mike también comenta que este modeloestá siendo reconsiderado ya que planteanumerosos problemas. Recordó que cuandoel evento no paga tiene que hacerlo el TC. Otrafuente de ingresos es a través de las publica-ciones. El nuevo modelo, para las publicacio-nes de la serie IFIP, tiene un rendimiento de 3euros por página publicada, donde el 25% sedestina a la cooperación técnica y el 75%restante a IFIP. Se mencionó que este modelopuede incentivar la aceptación de trabajoslargos de calidad dudosa a fin conseguir másdinero.

6) Karin Breitman presentó la versión prelimi-nar del nuevo sitio web de TC-1. Los miem-bros tendrán acceso a fin de poder mandarcomentarios y sugerencias. Se comentó quela manera de ordenar a los miembros, segúnnaciones, siguiendo el criterio IFIP quizá nosea el ideal.

7) El siguiente punto trató de los criteriosnecesarios para ser miembro de un TC. Mikeinformó que IFIP comprobará si los miem-bros de categoría A asisten regularmente.

También se sugirió que los miembros decategoría C se deberían reelegir cada dosaños.

8) Las próximas reuniones del TC-1 tendránlugar en Estonia (marzo de 2012) coincidien-do con ETAPS y en Países Bajos (septiembrede 2012) coincidiendo con TCS.

9) Finalmente, como resultado de las discu-siones planteadas, se decidió crear tres pane-les o grupos de trabajo sobre los temas:Educación, Evaluación y Financiación. Elgrupo de Educación se centrará en la educa-ción informática en secundaria y debería tra-bajar conjuntamente con el TC-3. El grupo deEvaluación se inspira en la comunidad dematemáticos que ha organizado grupos paraestudiar los distintos índices y su importanciaen la evaluación de investigadores individua-les y de los departamentos. Jos Baeten men-cionó que en <http://www.informatics-europe.org/> se puede encontrar un bueninforme. El grupo de Financiación se centraráen el hecho que los presupuestos de los depar-tamentos son cada vez menores. Como con-secuencia la investigación depende cada vezmás en la industria, poniendo en peligro lainvestigación pura. Otra cuestión a tratar esel incremento constante de carga de trabajoacadémico, y el impacto negativo que estotiene sobre las actividades de trabajo volunta-rio, como por ejemplo, revisión de trabajos yorganización de eventos.

Reunión del TC-1(Foundations of Computer Science)

Michael Hinchey1,Karin Breitman2, Joaquim Gabarró3

1Lero, the Irish Software Engineering Research Center, presidente del TC-1; 2Pontificia Universidade do Rio de Janeiro,secretaria del TC-1; 3ALBCOM, Universitat Politècnica de Catalunya, representante de ATI en el TC-1


Noticias de IFIPNoticias de IFIPNoticias de IFIPNoticias de IFIPNoticias de IFIP

El pasado día 15 de marzo de 2011 se celebróen Grenoble (Francia) la reunión anual delComité Técnico 10 (TC 10, ComputerSystems Technology) de IFIP. Esta reunióntuvo lugar coincidiendo con el congreso DATE(Design, Automation and Test in Europe).Asistieron a la reunión el Chairman de estecomité y representante de Suiza, Prof. BernhardEschermann, los representantes de Brasil,Alemania, Dinamarca y República Checa, ylos coordinadores de los WG 10.4 y 10.5.

Tras la aprobación de la agenda de la reunióny del acta de la sesión anterior, se pasa ainformar de distintas acciones consecuenciade la reunión anterior. En particular, el Prof.Franz Rammig informa sobre la decisión deque el congreso BICC (Biologically InspiredCooperative Computing), organizado por elTC 10 y ligado hasta el momento al WCC(World Computer Conference), se celebre,sin embargo, en 2012 junto al DIPES(Distributed and Parallel Embedded Systems).También anuncia la decisión de organizarfinalmente el WCC 2012 con un planteamien-to y esquema completamente diferentes a losseguidos hasta el momento.

Asimismo, el Chairman, Prof. Eschermann,informa sobre la nueva política de patrociniosde congresos que llevará a cabo IFIP. Lospatrocinios que impliquen participar en bene-ficios o pérdidas, la mayoría de los cualesllevan consigo la firma de acuerdos con otrasorganizaciones como IEEE y ACM, se apro-barán a partir de ahora desde la secretaría deIFIP, en un intento de llevar más control ydarle más valor a la marca "IFIP".

Respecto al estado de cuentas del TC 10, seaprueba tanto el resumen financiero de 2010como los presupuestos de 2011.

A continuación se pasa a informar sobre lasactividades de los WGs (Working Groups).Se discute en concreto sobre la necesariareactivación de los mismos. La nueva respon-sable del WG 10.5, Prof. Dominique Borrione,informa de que una de las acciones principalespara llevar a cabo esa reactivación será larenovación de los miembros del WG. El Prof.Ricardo Reis informa sobre las actividadesque se han llevado a cabo en Brasil, lugar en

el que se han localizado últimamente confe-rencias de casi todos los WGs.

Con el propósito de avanzar en los nuevostemas de interés propuestos en reunionesanteriores, se asignan inicialmente CloudComputing al WG 10.4 y Green Computingal WG 10.5.

Seguidamente, se abre un debate sobre laforma de trabajar en el TC 10. Se pone sobrela mesa la necesidad de reuniones técnicas quepermitan reunir a representantes de los distin-tos WGs con la finalidad de aportar nuevasideas y proyectos enmarcados en sus áreas deinvestigación. La organización del WCC 2012puede ser una buena oportunidad para con-tribuir con estas nuevas líneas de trabajo,aunque la lista de temas técnicos planteadoshasta ahora por los organizadores de estecongreso resulta muy limitada en las áreas deinterés del TC 10.

Habiendo finalizado el periodo preceptivo demandato de Vicepresidente y Secretario, seplantea la elección de los mismos. El Prof.Ricardo Reis es reelegido Vicepresidente mien-tras que, dada la ausencia del Prof. PaoloPrinetto, actual Secretario, se decide pospo-ner la elección y realizarla más adelanteelectrónicamente.

Se propone que la próxima reunión se celebre enel marco del WCC 2012 (el lugar sugeridoinicialmente para este congreso es Amsterdam),siempre y cuando sea factible la organización deuna sesión técnica con los objetivos plantea-dos anteriormente. En caso contrario, y conel fin de conseguir una mayor participación,se planteará una audio/vídeo conferencia.Con esta decisión se pone final a la reunión.

Reunión anual del TC-10(Computer Systems Technology)

Juan Carlos López LópezCatedrático de Universidad, Universidad de Castilla-La Mancha; representante de ATI en el TC 10

< j u a n c a r l o s . l o p e z @ u c l m . e s >< j u a n c a r l o s . l o p e z @ u c l m . e s >< j u a n c a r l o s . l o p e z @ u c l m . e s >< j u a n c a r l o s . l o p e z @ u c l m . e s >< j u a n c a r l o s . l o p e z @ u c l m . e s >

Ramon López de Mántaras obtieneel Robert S. Engelmore Award 2011

Ramon López de Mántaras, director delInstituto de Investigación en InteligenciaArtificial del CSIC y representante de ATI enel TC 12 de IFIP, ha sido galardonado conuno de los premios más prestigiosos delmundo en el ámbito de la Inteligencia Arti-ficial, el Robert S. Engelmore Award 2011.

Es la primera persona de fuera de los EEUUque recibe este premio, otorgado por laAsociación Americana de Inteligencia Arti-ficial y la revista AI Magazine.

López de Mántaras ha sido premiado por elconjunto de su trayectoria, y especialmentepor sus investigaciones pioneras para crearmáquinas capaces de aprender a partir desus propias "experiencias".

El premio Robert S. Engelmore, que seconcede desde 2003, se caracteriza por supolítica de distinguir a los grandes pionerosde la investigación en Inteligencia Artificial.En los últimos años has resultado ganado-res, entre otros, Edward Feigenbaum y BruceBuchanan (inventores de los sistemas ex-pertos) y Jim Hendler (inventor de la WebSemàntica junto con Tim Berners-Lee).

Ramon, en nombre de ATI recibe nuestramás cordial enhorabuena por este merecidopremio.

Actividades de AActividades de AActividades de AActividades de AActividades de ATITITITITI

V Edición del Premio Novática

La V Edición del Premio NováticaNováticaNováticaNováticaNovática, destina-do al mejor artículo publicado en 2010 denuestra revista ha tenido como ganador elartículo "AVBOT: Detección y corrección devandalismos en Wikipedia", del que es autorEmilio José Rodríguez PosadaEmilio José Rodríguez PosadaEmilio José Rodríguez PosadaEmilio José Rodríguez PosadaEmilio José Rodríguez Posada.

En el artículo se describe AVBOT, un robotcreado para proteger Wikipedia en español deciertas modificaciones no deseadas, conoci-das como "vandalismos". Aunque en un prin-cipio AVBOT fue desarrollado para Wikipedia,es posible utilizarlo en cualquier sitio web queemplee el motor MediaWiki. Desde que estáen funcionamiento ha demostrado una altaefectividad.

Emilio José Rodríguez PosadaEmilio José Rodríguez PosadaEmilio José Rodríguez PosadaEmilio José Rodríguez PosadaEmilio José Rodríguez Posada, un jo-ven profesional informático socio de ATI, esIngeniero Técnico en Informática de Siste-mas y colaborador de la Oficina de SoftwareLibre y Conocimiento Abierto de la Universi-dad de Cádiz.

El artículo fue publicado en la Sección "Mun-do estudiantil y jóvenes profesionales" del

Emilio José Rodríguez Posada

número 203 (enero-febrero de 2010), en unaedición especial de dicha sección dedicada alos proyectos presentados al Concurso Uni-versitario de Software Libre 2009, del que ATIfue colaborador, y será publicado en inglés enla revista UPUPUPUPUPGRADE dentro del año en curso.

El artículo está disponible en: <http://www.ati.es/novatica/2010/203/203-51-V-Premio-Novatica-ganador.pdf>.

Los artículos finalistas, listados por orden deapellido del primer autor, han sido:

"Crear vínculos basados en el contextopara mejorar las experiencias de los turistas",de Carlos Lamsfus, Christoph Grün,Carlos Lamsfus, Christoph Grün,Carlos Lamsfus, Christoph Grün,Carlos Lamsfus, Christoph Grün,Carlos Lamsfus, Christoph Grün,Aurkene Alzua-Sorzabal y HannesAurkene Alzua-Sorzabal y HannesAurkene Alzua-Sorzabal y HannesAurkene Alzua-Sorzabal y HannesAurkene Alzua-Sorzabal y HannesWerthnerWerthnerWerthnerWerthnerWerthner.

"El test de Turing: historia y significado",de Giusseppe O. LongoGiusseppe O. LongoGiusseppe O. LongoGiusseppe O. LongoGiusseppe O. Longo.

"El contenido de la Profesión Informáti-ca: una visión personal", de Fernando PieraFernando PieraFernando PieraFernando PieraFernando PieraGómez.Gómez.Gómez.Gómez.Gómez.

"Tendencias en Procesamiento del Len-guaje Natural y Minería de Textos", de JavierJavierJavierJavierJavierPueyo y José Antonio Quiles Follana.Pueyo y José Antonio Quiles Follana.Pueyo y José Antonio Quiles Follana.Pueyo y José Antonio Quiles Follana.Pueyo y José Antonio Quiles Follana.

novática nº 211 mayo-junio 20116 monografía

monografía Business Intelligence

Editor invitado

Presentación. Business Intelligence:analizando datos para extraer

nueva información ytomar mejores decisiones

La simplicidad del concepto bajo el que seesconde Business Intelligence es tanta que aveces nos resulta difícil de percibir. Este con-cepto no es otro que el de "incertidumbre". Nosaber las cosas, no tener la certeza de que eslo que ha pasado y que es lo que pasará anuestras empresas y organizaciones. Tal ycomo lo define la Real Academia de la LenguaEspañola.

certeza.(De cierto).1. f. Conocimiento seguro y claro de algo.2. f. Firme adhesión de la mente a algoconocible, sin temor de errar.

Y no es más que eso lo que buscamos bajo laamalgama de conceptos vinculados a Busi-ness Intelligence, lidiar con la incertidumbre ycon el miedo a no poder controlar los proce-sos de nuestra organización. Y es ahora, en elcontexto actual, con la crisis económica y conla incertidumbre de cuando finalizará, es eneste momento cuando los proyectos de Bu-siness Intelligence están más en auge quenunca, y la razón no es otra que el miedo, elmiedo a errar, el miedo a no tener toda lainformación para tomar una decisión, queahora sí, en estos momentos, puede determi-nar la supervivencia o la extinción de nuestraempresa o de nuestro modelo de negocio.

Pero antes de dar un paseo por todo lo que hayque tener en cuenta en todo proyecto deBusiness Intelligence, me gustaría incidir en elsegundo término de nuestro bonito concep-to. El Business Intelligence, es Business perono es seguro que es inteligente.

inteligencia.(Del lat. intelligentia).1. f. Capacidad de entender o comprender.2. f. Capacidad de resolver problemas.3. f. Conocimiento, comprensión, acto deentender.

Las tres primeras acepciones de la definiciónde inteligencia, vemos claro que no las pode-mos aplicar a un sistema de información, elque es inteligente es el analista de negocio,nunca el software o la plataforma, por esoalgunos están adoptando una nueva termi-nología sustituyendo Business Intelligencepor "Business Analytics". Término que no meacaba de convencer tampoco, ya que quizásyo soy un nostálgico de aquella primera defi-nición no tan comercial en la que a los siste-mas que nos ocupan se les llamaba "sistemas

de ayuda a la toma de decisiones", que es loque realmente son y que por mucho marke-ting que le pongan los fabricantes, es lo quesiempre serán. Pero como no queremos vol-ver a los 80, al final hemos llamado a estenúmero especial Business Intelligence. Espe-ro sepáis perdonar los anglicismos que noshemos visto obligados a utilizar.

¿Pero cómo te ayudan estos sistemas a to-mar decisiones? Pues es fácil solo hay dosvías, recopilando datos sobre los que trabajary dotando a los usuarios de negocio de herra-mientas para interrogarlos de forma sencillay útil.

El recorrido al que os invitamos en esteespecial de Business Intelligence, es precisa-mente el contrario, del cerebro del analista aldato del que se nutre.

Cuando estamos creando un reporte, pone-mos sus métricas y sus gráficos explicativos,hemos estado trabajando en él durante mu-cho tiempo y vemos que hemos aportadogran cantidad de información a una proble-mática del negocio que antes era cuantomenos difusa, nos encontramos con el hechode que todo ese trabajo está realizado desdeun punto de vista subjetivo, el nuestro. Esmás, a partir de ese "fantástico" informe quevamos a presentar y que tiene un claro caminoanalítico que nos lleva a conclusiones concre-tas, nos podemos encontrar con que éstas nosean tenidas nunca en cuenta a la hora detomar decisiones en nuestra organización.¿Cómo es eso posible?

Yo fui consciente de este hecho hará unosaños, realizando una consultoría, evaluandolos posibles escenarios finales y los resulta-

dos que se podrían derivar de que un determi-nado indicador/métrica, apareciera en rojo enel cuadro de mando. Mis argumentos eranque si sucedía ese hecho, era un claro indica-dor de que estaba pasando un hecho X y queteníamos obligatoriamente que tomar la de-cisión Y. A lo que un amigo mío me comentóque la decisión Y nunca se tomaría fuese cualfuese el informe, porque iba en contra de lacreencia de la empresa.

¿Qué pasa si de pronto te dicen que la Tierraes plana de nuevo?, ¿qué pasa si la informa-ción que recibes entra en frontal conflicto contu paradigma decisional?, ¿qué pasa si esainformación hace que tengas que tomar unadecisión que está en total disonancia con loque tú realmente piensas?, ¿La tomarás igual-mente o cambiarás el peso que esta informa-ción tiene en tu toma de decisiones?. Eso eslo que se llama disonancia cognitiva y que seresume como:

"Es el conflicto mental que abunda en laexperiencia cuando se presentan evidencias deque una creencia propia o asunción personales incorrecta. La teoría de la disonanciacognoscitiva afirma que hay una tendencia enla gente a reaccionar para reducir tal disonan-cia. Una persona puede evitar la nueva infor-mación o convertirse manipulador de argu-mentos para mantener su creencia o juicios ".

Es en este contexto y no en otro, para quéengañarnos, en el que desarrollamos nuestrotrabajo, aunque siempre tendemos a pensar quelos decisores van a sacar el máximo provecho denuestro trabajo y de los sistemas que desarro-llamos. Al menos éste es nuestro propósito y esen este sentido positivista en el que presentamoslos artículos de esta monografía.

Jorge Fernández GonzálezDirector de Consultoría en BusinessIntelligence de Abast Solutions

< j f e r n a n d @ a b a s t . e s >< j f e r n a n d @ a b a s t . e s >< j f e r n a n d @ a b a s t . e s >< j f e r n a n d @ a b a s t . e s >< j f e r n a n d @ a b a s t . e s >

Jorge Fernández González desarrolla su actividad profesional en dos ámbitos de actuación, el principalde ellos es como profesional de Sistemas de Información. En el que acumula más de 14 años deexperiencia y actualmente ejerce el cargo de Director de Consultoría en Business Intelligence deAbastSolutions. El segundo de sus ámbitos de actuación es el de docente universitario. Actualmente esProfesor Asociado al departamento de ESSI de la UPC y responsable de la asignatura "Sistemas deInformación para las Organizaciones" de la Facultad de Informática de Barcelona. También ha sidocolaborador docente en la Universitat Oberta de Catalunya (UOC), director académico y profesor enmasters y postgrados de la Fundación Politécnica y realiza sesiones como invitado en escuelas denegocio como ESADE , La Salle y EAE . En el ámbito de las publicaciones, ha colaborado con la revistaData TI en múltiples ocasiones, fue redactor de la revista Gestión del Rendimiento, es miembro del grupode expertos en español del portal BeyeNetwork, portal que reúne a los especialistas en BI a nivel mundial,y colabora como experto en todas las ediciones del BARC Business Intelligence Guide.


Business Intelligence monografía

monografía

Referencias útiles sobre "Business Intelligence"

Las referencias que se citan a continua-ción, junto con las proporcionadas encada uno de los artículos, tienen comoobjetivo ayudar a los lectores a profundi-zar en los temas tratados en esta mono-grafía permitiendo contrastar ideas y ob-tener información actualizada.

LibrosLibrosLibrosLibrosLibrosJ. M. CurtoJ. M. CurtoJ. M. CurtoJ. M. CurtoJ. M. Curto. Introducción al Business

Intelligence. Barcelona:Editorial, UOC, 2010.J.L. Cano.J.L. Cano.J.L. Cano.J.L. Cano.J.L. Cano. Business Intelligence: compe-

tir con información. Madrid: Fundación cul-tural Banesto, 2007.

W.H. Inmon.W.H. Inmon.W.H. Inmon.W.H. Inmon.W.H. Inmon. Building the DataWarehouse. Hoboken: John Wiley & Sons,4th Edition, 2005.

B. Kimball.B. Kimball.B. Kimball.B. Kimball.B. Kimball. Data Warehouse ToolkitClassics. Hoboken: John Wiley & Sons, 2009.PortalesPortalesPortalesPortalesPortales

TodoBI.TodoBI.TodoBI.TodoBI.TodoBI. <http://todobi.blogspot.com/>.DataPrix.DataPrix.DataPrix.DataPrix.DataPrix. <http://www.dataprix.com>.

BI-SPAIN.comBI-SPAIN.comBI-SPAIN.comBI-SPAIN.comBI-SPAIN.com. <http://www.bi-spain. com>.

BeyeNetwork Spain.BeyeNetwork Spain.BeyeNetwork Spain.BeyeNetwork Spain.BeyeNetwork Spain. <http://www.beyenetwork.es>.

BlogsBlogsBlogsBlogsBlogsJosep Curto Díaz. Josep Curto Díaz. Josep Curto Díaz. Josep Curto Díaz. Josep Curto Díaz. Information

Management, <http://informationmanagement.wordpress.com>.

Pau Urquizu.Pau Urquizu.Pau Urquizu.Pau Urquizu.Pau Urquizu. BI Fácil, <http://www.businessintelligence.info>.

Rémi Grossat.Rémi Grossat.Rémi Grossat.Rémi Grossat.Rémi Grossat. Inteligencia de negocio,<http://www.intelineg.com>.

Salvador RamosSalvador RamosSalvador RamosSalvador RamosSalvador Ramos. SQL Server Sí!, <http://www.sqlserversi.com>.

Jose María Arce Argos.Jose María Arce Argos.Jose María Arce Argos.Jose María Arce Argos.Jose María Arce Argos. BusinessIntelligence Blog (BIB), <http://josemariaarce.blogspot.com/>.

Aníbal GoicocheaAníbal GoicocheaAníbal GoicocheaAníbal GoicocheaAníbal Goicochea. Tecnologías de lainformación y estrategia. <http://anibalgoicochea.com/>.

Jorge Fernández González.Jorge Fernández González.Jorge Fernández González.Jorge Fernández González.Jorge Fernández González. Sistemas

decisionales, algo mas que BI. <http://sistemasdecisionales.blogspot.com>.

InstitucionesInstitucionesInstitucionesInstitucionesInstitucionesThe Data Warehouse InstituteThe Data Warehouse InstituteThe Data Warehouse InstituteThe Data Warehouse InstituteThe Data Warehouse Institute

(TDWI).(TDWI).(TDWI).(TDWI).(TDWI). <http://www.tdwi.org>.The MDM Institute.The MDM Institute.The MDM Institute.The MDM Institute.The MDM Institute. <http://www.

tcdii.com/>.The Data Governance Institute.The Data Governance Institute.The Data Governance Institute.The Data Governance Institute.The Data Governance Institute.

<http://www.datagovernance.com>.Inmon Institute.Inmon Institute.Inmon Institute.Inmon Institute.Inmon Institute. <http://inmon

institute.com/>.Kimball University.Kimball University.Kimball University.Kimball University.Kimball University. <http://www.

kimballgroup.com/html/kimballu.html>.

El cerebro del analista tiene diferentes formasde entender o desechar la información que sele presenta, es por esto que es muy importantecomo se la presentamos. Por esta razónabrimos este especial con un artículo delprofesor de ESADE Josep Lluis CanoJosep Lluis CanoJosep Lluis CanoJosep Lluis CanoJosep Lluis CanoGinerGinerGinerGinerGiner, titulado "Business InformationVisualization: Representación de la informa-ción empresarial ".

Pero una vez que se nos ha presentado esainformación tenemos que tener herramientasque nos permitan usarla de forma eficiente,sobre esto nos hablarán desde Argentina losautores R. Dario BernabeuR. Dario BernabeuR. Dario BernabeuR. Dario BernabeuR. Dario Bernabeu y MarianoMarianoMarianoMarianoMarianoA. García MattíoA. García MattíoA. García MattíoA. García MattíoA. García Mattío en su artículo "BIUsability: evolución y tendencias".

Aunque para llevar a cabo un proyecto de BIsin contratiempo, lo mejor que podemoshacer es mirar los factores críticos de éxito delBI, para intentar repetirlos en nuestros pro-yectos, eso es lo que abordo junto con elprofesor Enric Mayol SarrocaEnric Mayol SarrocaEnric Mayol SarrocaEnric Mayol SarrocaEnric Mayol Sarroca de la UPCen nuestro artículo homónimo.

Sin embargo, todos los grandes proyectos deBI tienen que tener una sólida base, siendo eldiseño del Data Warehouse una parte funda-mental. Para comprender mejor las raíces delBI contamos con el excelente artículo de JoseJoseJoseJoseJoseMaría Arce ArgosMaría Arce ArgosMaría Arce ArgosMaría Arce ArgosMaría Arce Argos reputado especialistacon muchos años de experiencia y profesorasociado de ESIC, titulado "Modelos deconstrucción de Data Warehouses".

Pero no podemos construir información sintener una política de datos, sin saber losorígenes sobre los que construimos, es poresto que Oscar Alonso LlombartOscar Alonso LlombartOscar Alonso LlombartOscar Alonso LlombartOscar Alonso Llombart, analistade Penteo y con una larga trayectoria en

proyectos de BI, nos muestra todo lo quetenemos que tener en cuenta a la hora degobernar los "ladrillos" de la información, ensu artículo "Data Governance, ¿qué?, ¿cómo?,¿por qué?".

Pero no todos seguimos los mismos cami-nos, y Carlos Luis GómezCarlos Luis GómezCarlos Luis GómezCarlos Luis GómezCarlos Luis Gómez de Ibertia nosmuestra uno nuevo en su artículo "BusinessIntelligence y pensamiento sistémico", un ar-ticulo para leer pensando.

Y por último, desde Chile, Diego ArenasDiego ArenasDiego ArenasDiego ArenasDiego ArenasContrerasContrerasContrerasContrerasContreras comparte su experiencia real, enun caso de estudio de "Estrategia BI en unaONG", explicando como BI puede ayudar aorganizaciones sin ánimo de lucro.

Esperamos que este especial sea de vuestroagrado y que os despierte las ganas de seguiraprendiendo sobre este extraño concepto lla-mado Business Intelligence.

Nota del editor

Como decíamos en la introducción de estenúmero ("En resumen", página 2), no sonmuchas las ocasiones en las que, como haocurrido en esta monografía, podemos conse-guir que un elenco de expertos trabajando enla industria escriban para contarnos, casi diría-mos que "en vivo y en directo", sus vivenciasactuales sobre el tema de que se trate. Lareflexión que viene a continuación está motiva-da por la cuestión de la cantidad de anglicismoscontenida en los distintos artículos y que elpropio editor invitado comenta en esta presen-tación.

No sin antes haberlo pensado bien, e inclusohaberlo comentado en los foros de ATI, hemoscreído oportuno no proceder a ningún tipo decorrección lingüística de los términos conteni-dos en los artículos respetando al 100% losmodos de expresarse de los autores, puestoque entendemos que reflejan con precisión losmodos de expresión y las terminologías usa-das hoy en día en la práctica empresarial. Sinembargo, esperamos que el lector encuentreen las "Notas" añadidas a cada artículo debidarespuesta a las dudas terminológicas que lepuedan surgir a partir del uso de esas palabrasde la jerga técnica que no le resulten conocidaso habituales.

Por último comentar que no va a ser éstesiempre el mismo criterio que usemos enNovática en materia de usos lingüísticos. Paramonografías y temas de carácter más teóricoy "futurista" es lógico que pidamos a los autoresque envíen sus artículos considerando el usode sinónimos en castellano de los términos queaparezcan procedentes de otros idiomas. Deahí, la nota que aparece en la página 77ofreciendo explícitamente la ayuda que el Gru-po de Lengua e Informática de ATI puedeaportar a los autores en este sentido.



Business Information Visualization:Representación de la información

empresarial

1. IntroducciónLas aplicaciones utilizadas por las organiza-ciones cada vez generan mayores cantidadesde información. Esta información se manejaen tiempo real o casi real. Generar conoci-miento y tomar decisiones son las principalesrazones por las que las organizaciones alma-cenan la información, además de soporte a lasoperaciones y para cumplir las obligacioneslegales. Ambas razones dependen del criteriode las personas, que deben extraer de la visua-lización de la información presentada aque-llos aspectos clave que permitan reconocerpatrones o tendencias ocultas. La visualiza-ción se convierte así en la interficie entre losordenadores y las mentes de las personas. Lascapacidades cognitivas de los humanos tie-nen limitaciones, por visualización se entien-de el proceso de transformación de datos,información y conocimiento en una represen-tación para ser usada de manera afín a lascapacidades cognitivas de los humanos.

2. Ejemplos de la historia de lavisualización de informaciónDiversos autores han investigado sobre lahistoria de la visualización de la información.Entre ellos destaca Tufte [1]. Desde tresautores distintos, se han seleccionado tresejemplos correspondientes a tres representa-ciones con el fin de mostrar tanto las bonda-des como los inconvenientes del uso de lavisualización de la información.

En 1786, el ingeniero escocés William Playfairse dió cuenta de que las transacciones econó-micas se podían representar fácilmente demanera gráfica. Además, según su opinión, larepresentación en series temporales y endiagramas de barras simplificaba su com-prensión y retención. El autor publicó el"Commercial and Political Atlas" donde serepresentaba el comercio exterior de Inglate-rra; libro que, además y por primera vez,incluía un nuevo tipo de gráfico: el diagramade pastel. En la figura 1figura 1figura 1figura 1figura 1 se muestra ungráfico de las exportaciones e importacionesentre Inglaterra y Dinamarca junto con No-ruega [2]. En éste claramente se señala elmomento en que el signo del saldo de labalanza comercial entre los países junto conel crecimiento del saldo a favor de Inglaterracambia.

Uno de los ejemplos más famosos de presen-tación de información pertenece a CharlesMinard, un ingeniero civil francés que usó la

Josep Lluís Cano GinerProfesor del Departamento de Dirección deSistemas de Información, ESADE, Universi-dad Ramon Llull

< j o s e p l l u i s . c a n o @ e s a d e . e d u >< j o s e p l l u i s . c a n o @ e s a d e . e d u >< j o s e p l l u i s . c a n o @ e s a d e . e d u >< j o s e p l l u i s . c a n o @ e s a d e . e d u >< j o s e p l l u i s . c a n o @ e s a d e . e d u >

Resumen: Los directivos y directivas cada vez disponen de más información y menos tiempo paraacceder a ella, ya que deben tomar decisiones rápidamente. Su correcta representación se puede conver-tir en una pieza clave a la hora de facilitar la toma de decisiones. En el artículo, se parte de una revisión dela historia y de la importancia de la visualización de la información. Asimismo, se muestra un ejemplo decómo mejorar dicha visualización y se concluye con las nuevas necesidades surgidas en torno a esteaspecto, requeridas tanto por las organizaciones como por sus directivos.

Palabras clave: Business Intelligence, representación gráfica, Sistemas de Información Directivos,visualización de información.

Autor

Josep Lluís Cano Giner es profesor del Departamento de Dirección de Sistemas de Información deESADE desde el año 1989. Licenciado en Ciencias Empresariales y máster en Dirección de Empresas(ESADE). Licenciado en Administración y Dirección de Empresas (Universidad Politécnica de Catalunya).Obtuvo el Diploma de Estudios Avanzados (DEA) por la UPC. En la actualidad, investiga en el campo delos factores que inciden en el aumento del uso de los Sistemas de Información Directivos por parte de losdirectivos. Es consultor de empresas con una dilatada experiencia en la planificación estratégica desistemas de información y en selección de soluciones, especialmente en Business Intelligence. Entre suspublicaciones académicas se encuentran artículos y diversos Business Case, entre ellos: "GovermentIntelligence en las universidades públicas catalanas", "Aventis", "Aguirre&Newman", "Bodegas Torres","Raventos i Blanc at a crossroad". También es el autor del libro "Business Intelligence: Competir conInformación".

visualización para mostrar la historia de latrágica marcha a Moscú de Napoleón1 en1812. En la gráfica de la figura 2figura 2figura 2figura 2figura 2, mostró enuna barra de color (en sombreado claro parael lector de esta revista), cuyo grosor indicabael tamaño del ejército (originalmente de422.000 efectivos), cómo este se iba reducien-do a medida que se acercaba a la capital rusa.A la vez, otra barra, de color negro, indicabalas tropas que regresaron de Moscú (a lallegada eran tan solo 10.000 efectivos). En labase del gráfico se anotaron las temperaturasal aire libre, que fueron el principal problemade los soldados. En el medio del gráfico, sepuede observar cómo la barra de color negrose ensancha, debido a la incorporación deunas tropas rezagadas que habían intentadoavanzar por el flanco izquierdo, así como ladramática disminución del grosor al cruzarun río con aguas heladas. Al final del retorno,se puede comparar el grueso de las dos barras:la de color, los que partieron; y la negra, losque regresaron. Un simple gráfico nos enseña,de una forma muy potente, la historia. RobertSpence [3] se pregunta si se podría escucharla obertura nº 1812 de Tchaikovsky2 combi-nada con la visualización del gráfico.

En 1954, Darrell Huff publicó "How to Liewith Statistics" [4] en el que exponía cómo sepodía manipular la representación gráfica de

las estadísticas para evidenciar diferentes in-tereses, algunas veces contrapuestos. Eviden-temente su gran aportación fue enseñarnos ahacerlo correctamente. En la figura 3figura 3figura 3figura 3figura 3 ofre-cemos un ejemplo de la representación de ungráfico de líneas muy útil para mostrar ten-dencias o predicciones. En el eje de las abscisas(el horizontal) se indican los meses del año;mientras que en el de las ordenadas (el verti-cal) se señala el volumen, por ejemplo, deventas en billones de dólares. En el gráfico dela izquierda la representación de la informa-ción es la correcta, el eje de las ordenadascomienza en 0 y las distancias entre los valoresde los dos ejes son equivalentes; por su parte,en el gráfico de la derecha, el eje de las orde-nadas comienza en 20, con lo que la expresióndel personaje que aparece en el gráfico sevuelve de profunda admiración por los resul-tados obtenidos.

Al repasar tres de los ejemplos históricos dela visualización de la información se ha subra-yado, en el primer caso, la importancia de larepresentación de la información para com-prender qué sucede; en el segundo, que unabuena representación de la información nospermite comprender mejor una realidad; y enel tercero, que si la representación de la infor-mación está manipulada, intencionadamenteo no, nos puede llevar a una interpretación



monografía

Figura 1. Exportaciones e Importaciones de y para Dinamarca y Noruega desde 1700 a 1780.Fuente: W. Playfair.

Figura 2. Mapa de las fuerzas de Napoleón en la campaña de Rusia.Fuente: Charles Minard, 1861.

errónea de los hechos. Si la representación esla adecuada podremos tomar decisiones pero,¿qué sucedería si alguien hubiera manipula-do la representación con otros fines?

3. Visualizando informaciónLa visualización de la información se utilizaen distintos campos, desde la medicina, pa-sando por la ingeniería, la estadística, losnegocios, o incluso en el deporte. De esteúltimo, hemos elegido la figura 4figura 4figura 4figura 4figura 4, publicadaen un reconocido periódico nacional3 , con el

fin de demostrar la dificultad que la presenta-ción de la información en un gráfico albergao puede albergar. En el gráfico publicado semuestran los récords de los 100 metros a lolargo de la historia: los atletas, su nacionali-dad, la fecha en la que se consiguieron y lasmarcas obtenidas. En el gráfico aparecentambién unas barras grises junto a la repre-sentación de un corredor. El lector se puedesorprender al ver que la barra más larga estájunto al menor tiempo. A mí me ocurrió lomismo.

Después de analizar el gráfico durante untiempo me di cuenta de que lo que el autorintentaba representar era cómo hubiera sidola llegada si en la carrera hubieran participadolos 10 corredores que ostentan el récord delmundo de los 100 metros (Carl Lewis y LeroyBurrell lograron dos récords, por lo tantodeberían correr en dos calles).

Trabajando sobre el gráfico anterior, se po-drían proponer algunas mejoras, como porejemplo añadir la línea de llegada en el gráfico



Figura 3. Gráfico en el que se muestra como cambia la figura al cambiar la escala del eje.Fuente: Darrell Huff.

Figura 4. Gráfico de la evolución de los récords de los 100 metros.Fuente: El País, 15/06/2005

y modificar la posición de los tiempos de lasmarcas para facilitar su lectura y comprensión.En la figura 5figura 5figura 5figura 5figura 5 se propone una posible solución.

En el supuesto de que la representación pro-puesta facilite la interpretación de la informa-ción, podríamos cuestionarnos ahora si ladistancia representada entre los corredorescorresponde a la real. A partir de la informa-ción proporcionada podemos calcular que ladistancia entre el primer y el décimo récordsería de 1,81 metros, es decir, en el tiempo de

9,77 segundos en que Asafa Powell recorre100 metros, Jim Hines hubiera recorrido 98,19metros. Así pues, ¿la distancia entre el corre-dor y la línea de meta corresponde a 1,81metros? Para responder a esta pregunta recu-rrimos a representar las distancias valiéndonosde los gráficos4 de una hoja de cálculo. En lafigura 6figura 6figura 6figura 6figura 6 se muestra el resultado obtenido.

A simple vista parece que las distancias entrelos corredores han decrecido en relación conel gráfico original. ¿Qué ha sucedido? En el

gráfico original no se presentan los valores deleje de abscisas, por lo que podríamos pregun-tarnos en qué valor comienza. En la figura 7figura 7figura 7figura 7figura 7se muestran dos gráficos. El de la izquierdacomienza en 97 metros, y el de la derecha en95 metros.

Si cambiamos el límite inferior de las abscisas,al visualizar las gráficas, la persona que lasestá analizando puede interpretarlas de formadistinta, lo que le podría llevar a tomar unadecisión diferente.



monografía

Figura 5. Propuesta de gráfico de la evolución de los récords de los 100 metros.Fuente: Elaboración propia

Figura 6. Gráfico de la evolución de los récords de los 100 metros, comenzandoen 0 metros. Fuente: Elaboración propia

También cabe preguntarse si la distancia re-corrida es, efectivamente, la mejor variablepara representar las diferencias entre los dis-tintos récords del mundo de los 100 metroslisos. O, si bien, podemos recurrir a la veloci-dad, es decir, a los metros por segundo paraevidenciar la diferencia entre los distintoscorredores. En la figura 8figura 8figura 8figura 8figura 8 se muestra lagráfica de las velocidades que se obtuvieron enlos 10 récords. En este caso solo se presentala gráfica en la que el eje de abscisas comienza

con el valor 0, ya que si comenzara por otrosvalores nos sucedería lo mismo que en el casoanterior. La diferencia en metros por segundoes de tan solo 0,19 entre el primero y el último.

Vayamos un poco más allá en el análisis. Siretomamos la perspectiva histórica nos po-dríamos preguntar ¿cuál ha sido la evoluciónde los 10 mejores récords del mundo de los100 metros lisos a lo largo del tiempo?5

Podemos recurrir para ello a un gráfico que

nos indique los valores a lo largo del tiempo.El que nos propone por defecto la hoja decálculo es el mostrado en la figura 9figura 9figura 9figura 9figura 9.

De nuevo, una lectura rápida nos podría llevara una conclusión errónea: ha mejorado mu-cho ya que la pendiente es pronunciada. Perosi representamos en el eje de las ordenadas elvalor 0, el gráfico cambia significativamente(ver figura 10figura 10figura 10figura 10figura 10).

Nos podría parecer que en el gráfico anteriorno se ha representado ninguna marca. Sinembargo, si se observa con atención puedepercibirse que hay una línea entre los valoresde 9 y 10 segundos, con una pendiente nega-tiva pequeña a lo largo de aproximadamenteunos 37 años. Es decir, se han tardado casi 37años en reducir la marca a 18 centésimas desegundo, lo que equivaldría a unas 5 milési-mas de segundo por año. Parece que la segun-da gráfica representa mejor esta realidad quela primera. En el límite, dos representacionesdiferentes de los mismos datos nos puedenllevar a dos conclusiones que incluso se pue-den contradecir entre ellas.

Hemos conseguido, con la representacióngráfica, que aquellas personas que estabaninteresadas en el hecho a analizar hayan com-prendido realmente lo que ha sucedido en losúltimos 10 récords del mundo de 100 metroslisos hasta el año 2005, las pocas diferenciasque hay entre ellos y la dificultad por mejorar-los. Tal vez, hubiera sido mejor echar manode otro tipo de representación gráfica: la tabla



Figura 7. Gráfico de la evolución de los récords de los 100 metros, comenzando en 97 y de 95 metros. Fuente:Elaboración propia

Tabla 2. Principios de Tufte y análisis del gráfico de los récords. Fuente: Elaboración propia

Objetivos de los gráficos Gráfico original de los récords de los 100 metros lisos

1

Sugiere que solo debemos mostrar la información. Algunas veces los que diseñan los gráficos tienden a mostrar agregaciones de información en lugar de la información en sí misma.

Los países de los corredores están junto a los nombres. Si se les hace aparecer en una columna separada facilita la lectura y se muestra mejor la preponderancia de los corredores de EEUU.

2 Sugiere que debemos asegurarnos de que el usuario piense en lo esencial del gráfico, y no en el gráfico en sí mismo.

Para interpretar el gráfico era necesario reconocer que se intentaba representar la llegada a la meta de una carrera hipotética entre los corredores de los 10 últimos récords. Se debería indicar la posición del récord.

3 Evitar todas aquellas decoraciones innecesarias.

La representación de los corredores no es necesaria.

4 Comprimir tanta información como sea posible en el menor espacio posible.

Se hubieran podido incluir los metros recorridos o la velocidad de cada récord.

5 Los gráficos deben ser diseñados para animar al usuario a hacer comparaciones entre las distintas informaciones.

Las marcas, al no estar alineadas, dificultan su comparación.

6 Los gráficos deben proveer vistas de la información a distintos niveles de detalle. Al ser un único gráfico y no interactivo, no aplica.

Tabla 1. Evolución de los récords de los 100 metros. Fuente: Elaboración propia



monografía

con los valores y los cálculos utilizados pararepresentarlos gráficamente. En la tabla 1tabla 1tabla 1tabla 1tabla 1 sehan añadido tres nuevas columnas: la de lamejora del tiempo en porcentaje respecto almejor récord, la velocidad en metros porsegundo, y la de la distancia que habríanrecorrido el resto de corredores en el tiempoque Asafa Powell habría llegado a la meta.

Si la conclusión es que la mejor forma decomprender esta realidad es la tabla con losvalores, entonces resulta la mejor representa-ción. Esta decisión probablemente se relacio-ne con una elección personal, a la vez que seencuentra influida por el conocimiento que lapersona disponga sobre los resultados de laspruebas de 100 metros lisos. Es decir, nodepende tan solo del que representa la infor-mación, sino también del que la visualiza.Nos podríamos preguntar si siempre tienesentido establecer un formato de informeinvariable a lo largo del tiempo, como decidenla mayoría de organizaciones, basándose enque al no cambiar el formato facilita suinterpretación o deberíamos modificarlo paraconseguir una mejora en la visualización siquisiéramos representar mejor algunos cam-bios que se han producido en los datos.

4. Information VisualizationSegún Card et al. [5], la visualización de lainformación se define como: "El uso de repre-sentaciones visuales basadas en ordenadorese interactivas de información abstracta paraamplificar la cognición ".

Los autores la diferencian de la visualizacióncientífica, normalmente basada en informa-ción física.

Los mismos autores han llevado a cabo unarevisión de la literatura6 , a la vez que justi-fican cómo la visualización amplifica la cog-nición, o dicho de otra manera, quee l c o n c e p t o d e c o g n i c i ó n ( d e llatín: cognoscere, "conocer") hace referenciaa la facultad de los seres de proce-sar información a partir de la percepción, elconocimiento adquirido y las característicassubjetivas que permiten valorarla.

Debemos señalar que en la definición pro-puesta se añade el término "interactivas", yaque en la actualidad, normalmente, las repre-sentaciones siempre se basan en el uso deordenadores que permiten la interacción entreel usuario y la aplicación del ordenador.

Para aquellos lectores que quieran profundi-zar en la definición de "visualización", en lasdistintas tecnologías que la soportan o en larelación entre las teorías cognitivas y lastareas de la resolución de problemas, asícomo en las representaciones visuales, pue-den hacerlo en el artículo de Tegarden [6].

En dicho artículo, Tegarden resume los seis

Figura 8. Gráfico de la velocidad de los récords de los 100 metros.Fuente: Elaboración propia

Figura 9. Gráfico de la evolución de los récords de los 100 metros,comenzando en 9,65 segundos. Fuente: Elaboración propia

Figura 10. Gráfico de la evolución de los récords de los 100 metros,comenzando en 0 segundos. Fuente: Elaboración propia



objetivos que todo gráfico debería cumplirsegún Tufte [1][7]. En la tabla 2tabla 2tabla 2tabla 2tabla 2, dichosobjetivos se relacionan con el gráfico originalde los récords de los 100 metros lisos quehemos utilizado como ejemplo:

5. Business Information VisualizationLos directivos necesitan información para latoma de decisiones, y necesitan que se repre-sente de forma que facilite su interpretación.Normalmente, las organizaciones desarro-llan proyectos de Business Intelligence. Unode los aspectos clave de estos proyectos es lacorrecta representación de la información. Enel presente artículo, no nos vamos a referir alos conceptos básicos de la representación dela información. Para ello, se adjuntan referen-cias bibliográficas de distintas obras que tra-tan amplia y profundamente este tema. Noobstante, sí que vamos a incidir en las nuevastendencias y necesidades sobre la visualiza-ción. Entre los autores cabe destacar a StephenFew [8]. Según él, la visualización de infor-

mación del futuro conlleva nuevas necesida-des, entre ellas:

Dashboards o Scorecards: los directivosnecesitan acceder a información que en pocotiempo les permita analizar cuál es la situa-ción, de manera que una vez detectado elproblema, mediante unas pocas pulsacionescon el ratón, puedan descender al nivel dedetalle suficiente para poder comprender quésucede y tomar las medidas correctoras. Enlos scorecards se representan perspectivas deáreas estratégicas, objetivos, medidas yindicadores semafóricos, mientras que en losdashboards la información presentada puedevarias mucho y se suelen incluir representa-ciones gráficas. En los dashboards o cuadrosde mando la complejidad de la visualizaciónde la información aumenta, ya que puedenpresentarse informaciones o gráficos inter-relacionados. Normalmente se debe, además,presentar una gran cantidad de informaciónen un espacio muy limitado (ver figura 11figura 11figura 11figura 11figura 11).

Geo espacial: cuando la información sebasa en el territorio, su visualización sobre elterreno se hace cada vez más necesaria. Desdelos conocidos Geographic InformationSystems (GIS), hasta Google Earth o distin-tos web services encontramos medios que nospermiten relacionar, por ejemplo, las ventas olos gastos con el territorio.

Scatterplots o gráficos animados: en al-gunos casos necesitamos comparar dosmagnitudes, por ejemplo, inversiones en pu-blicidad y ventas a lo largo del tiempo. Paraello es necesario valerse de un nuevo tipo derepresentación que incluye animaciones en eltranscurso temporal. Uno de los mejoresejemplos de representación animada de infor-mación es el caso de www.GapMinder.org, enel que, por ejemplo, se puede ver la relaciónentre los ingresos de los países y su tasa demortalidad infantil a lo largo del tiempo.

Treemaps: un ejemplo de representaciónde este tipo de gráficos es el volumen deoperaciones de la bolsa de Nueva York, agre-gado por industria y de forma que permitecomparar los precios y sus cambios desde eldía anterior (puede verse en www.SmartMoney.com).

Sparklines: son un tipo de representacióngráfica caracterizada por su pequeño tamañoy la densidad de información que contiene.Normalmente se utilizan varias a la vez repre-sentando distinta información que en algu-nos casos puede ser complementaria. El ter-mino sparkline fue propuesto por EdwardTufte, que las describe7 como "pequeñosgráficos, simples, de elevada resolución y deltamaño de un una palabra". En la figura 12figura 12figura 12figura 12figura 12se muestra un ejemplo de un sparkline.

Representación de relaciones: en algunoscasos, necesitamos representar relaciones entreentidades, como en el caso de las Web sites.Cada una de ellas actúa como nodo en una

Figura 11. Cuadro de mando. Fuente: Ejemplo de QlikView.

Figura 12. Tabla de evolución de las cotizaciones.Fuente: <http://www.edwardtufte.com>.



monografía

Referencias

[1] E.R. Tufte. The Visual Display of QuantitativeInformation. Cheshire: Graphics Press, 1983.[2] W. Playfair, H. Wainer, I.Spence. TheCommercial and Political Atlas and StatisticalBreviary. New York: Cambridge University Press,2005.[3] R. Spence. Information Visualization. Essex:ACM Press, 2001.[4] D. Huff. How to Lie with Statistics. Penguin;New Ed edition, 1991.[5] S.K. Card, J.D. Mackinlay, B. Shneiderman.Readings in Information Visualization: Using Visionto Think. San Francisco: Morgan KaufmannPublishers, 1999.[6] D. P. Tegarden. “Business InformationVisualization”. Comunications of AIS, vol.1, art. 4,enero, 1999.[7] E.R. Tufte. Envisioning Information. Cheshire:Graphics Press, 1990.[8] S. Few. Data Visualization, Past, Present, andFuture. Percentual Edge, 2007.

J. Best. Damned Lies and Statistics: UntanglingNumbers from the Media, Politicians, and Activists.Berkeley and Los Angeles: University of CaliforniaPress, 2001.J. Best. More Damned Lies and Statistics: HowNumbers Confuse Public Issues. Berkeley and LosAngeles: University of California Press, 2004.W.S. Cleveland. The Elements of Graphing Data.Summit: Hobart Press, 1994.S. Few. Show Me the Numbers: Designing Tablesand Graphs to Enlighten. Oakland: Analytics Press,2004.S. Few. Information Dashboard Design: The EffectiveVisual Communication of Data. Sebastopol, CA:O’Reilly Media, Inc., 2006.S. Few. Now You See It: Simple VisualizationTechniques for Quantitative Analysis. Oakland:Analytics Press, 2009. J.G. Koomey. Turning Numbers into Knowledge:Mastering the Art of Problem Solving. Oakland:Analytics Press, 2001.D. Niederman, D. Boyum. What the Numbers Say:A Field Guide to Mastering Our Numerical World.New York: Broadway Books, 2003.N.B. Robbins. Creating More Effective Graphs.Hoboken: John Wiley and Sons, Inc., 2005.T. Segaran, J. Hammerbacher. Beautiful Data.O’Reilly Media, 2009.E.R. Tufte. Visual Explanations. Cheshire: GraphicsPress, 1997.E.R. Tufte. Beautiful Evidence. Cheshire: GraphicsPress, 2005.C. Ware. Information Visualization: Perception forDesign, second edition. San Francisco: MorganKaufmann Publishers, 2004.D.W. Wong. The Wall Street Journal Guide toInformation Graphics: The Dos and Don’ts ofPresenting Data, Facts, and Figures. New York: W.W. Norton & Company, 2010.

1 <http://www.math.yorku.ca/SCS/Gallery/images/minard.gif>.2 El lector puede hacer el ejercicio accediendo a<http://www.youtube.com/watch?v=k-vQKZFF-

9s&feature=related> (último acceso 5.1.2011).Esta obertura, Op. 49, fue compuesta para reme-morar la victoriosa resistencia rusa en 1812 frenteal avance de la Grande Armée de NapoleónBonaparte. La obertura fue estrenada en Moscú el20 de agosto de 1882. La obra es reconocida porsu final triunfal, que incluye una salva de disparosde cañón y repique de campanas.3 Artículo “Huracán Powell” aparecido en El Paísel miércoles 15 de junio de 2005. Al pie del gráficose indica el literal “elaboración propia”.4 En todos los gráficos se ha omitido la presenta-ción de los valores para facilitar la comprensión delefecto que se quiere mostrar con el gráfico.5 Sobre la pregunta, debemos señalar que no nosestamos preguntando ¿cuál ha sido la evoluciónde los récords del mundo de los 100 metros lisosa lo largo de la historia? Para responder a estapregunta deberíamos disponer de todos los ré-cords del mundo, y no es el objetivo de este artículoanalizarlos.6 Tabla 1.3 de la página 16 del libro citado en lareferencia [5].7 El lector puede acceder a más ejemplos en:<http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR& topic_id=1>.Bibliografía

Notas

red, y tiene vínculos con otras. Un ejemplo deuso es Vizster de redes entre personas.

6. ConclusiónLas necesidades de visualización de informa-ción han ido cambiando a lo largo de lahistoria. El tiempo del que disponen los direc-tivos y directivas para tomar decisiones cadavez es menor. Además, han aparecido nuevasnecesidades con lo que los investigadores hanpropuesto y propondrán nuevas solucionespara cubrirlas. Una correcta representaciónde la información debería facilitar su interpre-tación y disminuir el tiempo que los directivosinvierten en ella, y este se presenta como elprincipal objetivo de la visualización de infor-mación.

Si la visualización de la información no es lacorrecta puede llevar a los directivos y direc-tivas a tomar decisiones equivocadas. A lolargo del artículo se ha presentado distintosejemplos en los que la representación de infor-mación de una forma "manipulada" podríallevar a interpretaciones erróneas, con lo queel riesgo que los directivos y las directivas seequivoquen aumentan. En todo proyecto deBusiness Intelligence deberíamos asegurarque la representación gráfica es la más ade-cuada, por ello necesitamos especialistas quenos lo aseguren minimizando la visualizaciónde información. Sin una correcta representa-ción, no conseguiríamos aportar el valor quese espera, y difícilmente retendremos el interésde los directivos y las directivas en el uso deesta solución.



1. IntroducciónLo que hoy se conoce con el nombre deBusiness Intelligence (BI), ha tenido un ori-gen y evolución que cabe resaltar a fin deintroducirnos en el concepto que será tratadoen este artículo: "BI Usability".

Uno de los objetivos principales del BI es que losusuarios, encuentren la información que nece-sitan para tomar decisiones en tiempo y "for-ma". La "forma" incluye, entre otras cosas, elformato en que la información se presenta y elnivel de interacción pretendido para obtener elresultado deseado. Son los puntos anterioreslos que conforman el termino "BI Usability".

Usabilidad puede definirse como la facilidadde uso de un software, en la que tambiénintervienen factores como la familiaridad deldiseño, la comodidad, si es atractivo al usua-rio o no, el nivel de interacción que permite, eltiempo de respuesta, etc.

Se han seleccionado varias definiciones deusabilidad para complementar el concepto1 .

La ISO/IEC 9126 define la usabilidadcomo "la capacidad de un software de sercomprendido, aprendido, usado y ser atracti-vo para el usuario, en condiciones específicasde uso". Asimismo, la ISO establece cuatroprincipios básicos en los que se basa lausabilidad: facilidad de aprendizaje, facilidadde uso, flexibilidad y robustez.

Jakob Nielsen, padre de la usabilidad, ladefine como "un atributo de calidad que evalúacuán fácil para su uso son las interfaces deusuario”.

Janice (Ginny) Redish, consultora indepen-diente, define lo que debería permitir una interfaza los usuarios: "encontrar lo que necesiten,entender lo que encuentren y actuar apropiada-mente, dentro del tiempo y esfuerzo que ellosconsideren adecuado para esa tarea".

Business IntelligenceBusiness IntelligenceBusiness IntelligenceBusiness IntelligenceBusiness Intelligence puede definirsecomo un concepto que integra, por un lado elalmacenamiento y por el otro el procesamien-to de grandes cantidades de datos, con elprincipal objetivo de transformarlos en cono-cimiento y en decisiones en tiempo real, através de un sencillo análisis y exploración.Dicho conocimiento debe ser oportuno, rele-vante, útil y debe estar adaptado al contextode la organización2 .

En el marco de estas aproximaciones concep-tuales sobre usabilidad y BI, es posible propo-

BI Usability:evolución y tendencia

R. Dario Bernabeu, MarianoA. García MattíoCofundadores de Grupo eGlu BusinessIntelligence (eGluBI), Córdoba (Argentina)

< { D a r i o S i s t e m a s , m a g m 3 3 3 3 } @ g m a i l . c o m >< { D a r i o S i s t e m a s , m a g m 3 3 3 3 } @ g m a i l . c o m >< { D a r i o S i s t e m a s , m a g m 3 3 3 3 } @ g m a i l . c o m >< { D a r i o S i s t e m a s , m a g m 3 3 3 3 } @ g m a i l . c o m >< { D a r i o S i s t e m a s , m a g m 3 3 3 3 } @ g m a i l . c o m >

Resumen: Este artículo nos introduce inicialmente en los conceptos de usabilidad y Business Intelligence,para luego definir el término "BI Usability". Seguidamente, presenta un gráfico histórico con los hitos mássignificativos, que son antecedentes de lo que en la actualidad se conoce como sistemas BI. Luego, sesistematizan estos hitos, década por década, teniendo en cuenta por un lado, la evolución/innovación enlos sistemas de información BI y por el otro destacando la usabilidad de esa época. Finalmente, describey traza la forma en que BI Usability se fue desarrollando a través del tiempo, y señala tendencias en cuantoa usabilidad.

Palabras clave: BI, evolución histórica, usabilidad.

Autores

R. Dario Bernabeu es Ingeniero en Sistemas por el Instituto Universitario Aeronáutico de Argentina. Hasido cofundador de eGluBI <www.eglubi.com.ar>. Se especializa en el desarrollo e implementación desoluciones OSBI (Open Source Business Intelligence): gestión de proyectos, análisis de requerimientos/necesidades, despliegue y configuración de soluciones BI, confección de procesos de integración dedatos, modelado de Data Warehouse, confección de cubos multidimensionales y Business Models,desarrollo de reportes ad hoc, reportes avanzados, análisis interactivos, dashboards, etc. Es docente,investigador, geek y entusiasta del software libre. Su publicación más destacada es "Data Warehousing:Investigación y Sistematización de Conceptos – HEFESTO: Metodología para la Construcción de un DW".Es coordinador de la red social Red Open BI <www.redopenbi.com> y realiza numerosos aportes endiferentes foros, wikis, blogs, etc.

Mariano A. García Mattío es Ingeniero en Sistemas por el Instituto Universitario Aeronáutico (IUA) deArgentina y Especialista en Sistemas y Servicios Distribuidos por la Universidad Católica de Córdoba(UCC). Profesor titular de: "Bases de Datos 1" y "Bases de datos 2” en el IUA – Facultad de Ingeniería;"Motores de Bases de Datos2" en el IUA – Facultad de Administración; "Paradigma de ProgramaciónOrientada a Objetos" y "Sistemas Distribuidos en la Especialización en Sistemas Embebidos" del IUA. Jefede trabajos prácticos de "Bases de Datos Aplicadas" en la UCC; Codirector del proyecto de investigaciónsobre NTICS (Nuevas TICSs) en la UCC; Integrante del proyecto de investigación "Laboratorios Virtuales"del IUA. Ha sido cofundador de eGlu BI <www.eglubi.com.ar> y es coordinador de la red social RedOpen BI. Se especializa en tecnologías JAVA SE/EE, administración y diseño de Bases de Datos, y OSBI(Open Source Business Intelligence).

ner una conceptualización de BI Usability. BIBIBIBIBIUsabilityUsabilityUsabilityUsabilityUsability se refiere al diseño de softwaresdedicados al BI que cuenten con interfazamigable, intuitiva, fácil de utilizar (y fácil deaprender a utilizarla); interfaz que permita lacreación de nuevos contenidos (análisisinteractivos, reporting, dashboards o table-ros de mando), así como su correspondientenavegación, haciendo énfasis en la presenta-ción de dichos contenidos, todo de maneravisual e interactiva, para que el usuario sesienta cómodo con su herramienta y le saqueel mayor provecho a sus datos.

2. Evolución histórica de lausabilidad en BIA continuación, se enumerarán los hitosprincipales que se fueron sucediendo y queson antecedentes de la forma que hoy hantomado los sistemas BI en cuanto a lausabilidad.

En la figura 1figura 1figura 1figura 1figura 1 puede apreciarse el detalle deeste recorrido histórico.

A continuación se mostrará el impacto de lausabilidad en cada una de estas etapas.

2.1. Años 60Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: En ladécada de los 60, los sistemas estaban basa-dos en archivos y la dependencia con respectodel hardware era casi total. Estaban principal-mente orientados al almacenamiento y altratamiento de datos, pero los mismos siste-mas de almacenamiento secuenciales (cin-tas) impedían, en gran medida, la posibilidadde manejar información3 . El surgimiento delacceso directo, junto con la creación de losprimeros discos rígidos, marcó un hito, apartir del cual el software y el hardware ayu-daban a procesar los datos para obtenerinformación.



monografía

Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Por esosaños, la interacción de los sistemas de infor-mación con los usuarios era bastante preca-ria. Consistía en consolas que mostrabanuna serie de opciones en modo texto queluego el usuario debía seleccionar, en generalse presentaban tantas pantallas como opcio-nes disponibles, y al finalizar la selección seobtenían resúmenes de información impre-sos y/o listados detallados específicos. Por lodefinido anteriormente, no hay lugar a dudasque en esta época no se puede hablar de BI perse.

2.2. Años 70Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: En los70 la tendencia fue marcada por el surgimien-to de los sistemas de gestión de bases de datos(SGBD) y el modelo relacional que fue pre-sentado en 1969 por Edgar Codd (y publicadoformalmente en 1970). En esta década esposible visualizar un salto en la evolución delas bases de datos, ya que hasta entonces lasmismas se basaban en su mayoría en modelosde red, jerárquicos o simplemente archivosestructurados, cuya característica preponde-rante era la inflexibilidad y las relaciones físi-cas entre las entidades.

Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Si bienlas bases de datos tuvieron un gran impulsode la mano del modelo relacional, recién afinales de esta década se construyeron lasprimeras versiones de sistemas que les dabansoporte. Asimismo, se produjeron mejorassustanciales en las respuestas de requerimien-tos de datos e información. La interacción

con el usuario mejoró notablemente y secontaba con interfaces de texto interactivas,esto permitió mejorar la presentación de in-formación por pantalla debido a la posibili-dad de realizar scroll. A pesar de todo, losinformes continuaban siendo estáticos y alta-mente orientados a la informacióntransaccional.

2.3. Años 80Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: En ladécada de los 80, con la aparición en escena delas computadoras personales (PC) se popu-lariza la utilización de los SGBDs y en 1986se estandariza el lenguaje SQL. Además, apa-recen las primeras aproximaciones que trae-rán como consecuencia la posterior defini-ción del concepto de "Data Warehouse"(DW),la que fue construida en 1992 por Bill Inmony Ralph Kimball. En 1989 Howard Dresnerredefine el término Business Intelligence, yaque éste fue utilizado por primera vez en 1958por Hans P. Luhn.

Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Inicial-mente, los proveedores de los primeros DW,solo hacían énfasis en el hardware y en lacapacidad de sus SGBD, y delegaban la crea-ción de las GUI (Graphical User Interfaces) enlos desarrolladores/programadores de cadaempresa. En aquellos años, quienes se encar-gaban de diseñar e implementar los DW, setopaban con muchos inconvenientes y dificul-tades, ya que estas personas estaban acos-tumbradas a trabajar con sistemas transac-cionales/operacionales (OLTP), modeladorelacional y, fundamentalmente, a encarar

proyectos de esa índole. Ese apego a lossistemas tradicionales hizo fracasar un altoporcentaje (algunos hablan de un 80%) de losproyectos de la época, debido a que no secomprendía que el desarrollo e implementaciónde un DW no puede compararse con el de unOLTP, ni mucho menos es viable intentar"adaptar" metodologías y modelos, puestoque para este nuevo concepto deben emplear-se herramientas construidas específicamente.

En cuanto a la interactividad, la mejora fuemuy notable, los lenguajes de programaciónpermitían crear interfaces gráficas y de textomás amenas y orientadas al usuario. Losinformes eran más personalizables y para-metrizables y los primeros gráficos de infor-mación (gráfico de torta, barras, etc.) vieronla luz. Las hojas de cálculo requieren unamención especial, ya que cambiaron radical-mente la interacción entre el usuario final y lainformación, otorgándole la posibilidad demantener e interactuar con sus propios datos.Pero las facilidades que brindaron las hojas decalculo produjeron como resultado cúmulosde datos redundantes y no vinculados entre sí,debido a que no están pensadas para manejarbases de datos. Posteriormente, estos cúmu-los se han ido arrastrando y requieren un granesfuerzo para procesarlos, ordenarlos y con-vertirlos en un conjunto que pueda ser explo-tado de manera segura.

2.4. Años 90Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Sistemas de información de BI: Ladécada de los 90 encuentra a las organizacio-nes/empresas repletas de PCs, SGBDs perso-

Figura 1. Principales hitos en Business Intelligence en comparación con otros hitos históricos.



nales, hojas de cálculo, etc. que conforman unconjunto de datos heterogéneos de informa-ción descentralizada y no conectada. La ar-quitectura conocida como cliente servidor(C/S) posibilitó el surgimiento de un nuevoparadigma en cuanto al funcionamiento ycomunicación de las aplicaciones. Los SGBDsfueron una de las categorías que más aprove-chó esta arquitectura, dando origen a lasbases de datos distribuidas, potenciando laintercomunicación en las organizaciones/empresas y haciendo las bases de datos másconsistentes y provechosas. Sin embargo,existían una serie de formatos heredados(hojas de cálculo, archivos planos, etc.) paralos cuales el aporte de la arquitectura C/S nofue significativo, aunque sí lo fue la idea deestandarizar los procesos de integración dedatos4 .Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Usabilidad de BI en esa época: Lasdiversas publicaciones de Bill Inmon y RalphKimball, donde explicitan cómo construir ydiseñar un DW, además de definir un marcoconceptual acerca del tema, ayudaron aclarificar conceptos y, sobre todo, definenun punto de referencia a partir del cual seconstruirían los DW y las aplicaciones rela-cionadas al BI. Es en este punto en el quesurgen las primeras aplicaciones de soft-ware orientadas a DW, tales como: IBMOLAP Server, Cognos, Business Object,SAS, Microstrategy, Oracle, etc. Estas he-rramientas son las denominadas aplicacio-nes "BI 1.0” y sus rasgos más importanteso destacables se formulan de la siguientemanera:

Limitadas en cuanto a analizar grandesvolúmenes de datos en un tiempo aceptableya que las estructuras de almacenamientofísicas no estaban optimizadas para tal fin.Tampoco existían herramientas para mejo-rar el rendimiento en DW como: clustersmultidimensionales, tablas agregadasautomantenidas, buffers con estructurasmultidimensionales, etc.

Acotadas en cuanto a las fuentes de datosposibles.

Sin consenso general sobre diseño de GUIspara la administración y navegación.

Se puede resumir diciendo que en general laflexibilidad no era una virtud en estas herra-mientas, aunque cumplían con las tareasbásicas inherentes al DW, y más importanteaún, estaban orientadas al DW.

En los primeros años del siglo XXI, hacia elaño 2003 aproximadamente surge el "BI 2.0”con el desarrollo de softwares dedicados al BI,que comienzan a incorporar nuevas funcio-nalidades, características y tecnologías, talescomo: interactividad, exploradores web, JS,Ajax, JSON, flexibilidad, interfaces gráficasde usuario (GUI) intuitivas orientadas alusuario final, Web Services, etc. A estossoftwares dedicados se los conoce comosuites BI.

3. Hechos y sucesosA continuación se describirán los cambios,hechos y sucesos que fueron dando forma alBI Usability.

Se puede decir que con el paso de los años, lasaplicaciones BI 1.0 vieron saldadas cuestio-nes importantes como almacenamiento ma-sivo, velocidad de respuesta, modularidad,etc. Esto fue posible, en gran parte debido alos avances de hardware tales como paralelis-mo, multiprocesamiento, etc., y a arquitectu-ras e implementaciones más robustas de soft-ware como OLEDB, JDBC, middlewares,frameworks, etc. En este contexto y con elpaso del tiempo, el desarrollo de las aplicacio-nes BI fue ganando experiencia y madurandoen consecuencia.

Como ha ocurrido en muchos casos a lolargo de la historia de la informática, una vezsaldadas algunas cuestiones que limitaban elcrecimiento, se priorizaron otras cuestionessoslayadas o dejadas de lado hasta entonces.Una de ellas es la usabilidad. En este punto,comenzó a pensarse en la importancia de quelas aplicaciones BI fuesen más atractivas,intuitivas y sencillas de utilizar para que losusuarios se sintiesen cómodos y pudiesensacar el mayor provecho de sus datos.

Hasta el momento, la gran mayoría de lasaplicaciones BI eran de tipo de escritorio, yaque los usuarios estaban acostumbrados a lavelocidad de respuesta y componentes deinterfaz de usuario (también llamadoswidgets) de este tipo de aplicaciones; aunquealgunas presentaban una interfaz web bastan-te limitada. Las limitaciones de las interfacesweb, estaban caracterizadas por el período enque fueron desarrolladas, "antes de la web2.0”, en el cual las páginas se cargaban deforma total por cada requerimiento, el anchode banda era consumido por los requerimien-tos básicos y los widgets eran muy básicos yno podían competir con las versiones de escri-torio. En definitiva, no eran agradables nifamiliares al usuario.

4. La usabilidad del BI en la actua-lidad y tendencias futurasEn los últimos años, la aparición Ajax5 y conella la maduración y/o creación de tecnolo-gías que permitían representar y transportardatos de manera eficiente y estándar, facilitarla creación de GUIs llamativas y potentes, y lainteracción entre los datos y las GUIs (JSON,Web Services, frameworks JavaScript, flash,CSS, etc.) cambió el paradigma de desarrolloweb, pasando de clientes livianos a clientespesados y con grandes capacidades de proce-samiento, interacción y visualización. Lasaplicaciones desarrolladas con esta técnica seejecutan del lado del cliente (cliente pesado ofat client), el cual solo requiere del servidor loque necesita puntualmente (y no toda lapágina como antes), pudiendo hacerlo de

forma asíncrona, permitiendo de esta maneraque el usuario nunca pierda la interactividadcon la aplicación.

El advenimiento de Ajax y las tecnologíasmencionadas en el párrafo anterior, marcanlo que hoy se conoce como BI 2.0, e inclina labalanza hacia el lado del desarrollo web6 . Lasaplicaciones BI 2.0 se enfocan en el diseño ypresentación de las consultas, reportes, aná-lisis OLAP, etc, a través de gráficosinteractivos, objetos Flash y JavaScript,dashboards personalizados y altamenteparametrizables, etc. Todo esto haciendoénfasis en la interfaz gráfica y en la interactividadcon el usuario.

Actualmente el desarrollo y crecimiento deaplicaciones BI y tecnologías asociadas no hamermado. Por el contrario, continuamenterecibe nuevos impulsos. Algunos de los desa-rrollos que eventualmente podrían marcartendencias de cambio o, porqué no, establecernuevos hitos, son:

Bases de Datos no SQL.Cloud Computing.Sql Streaming.In-Memory OLAP.Tecnologías móviles.Tecnologías basadas en GPS.Tecnologías Touch.Reconocimiento de voz.Prototipado ágil.

Si se habla de tendencias y desarrollo, omitiruna referencia a OSBI (Open Source Busi-ness Intelligence) sería definitivamente undesacierto. En los últimos años, el crecimien-to y aporte de la comunidad de software librey open source en este sentido ha sido cuantio-sa y significativa, logrando que las aplicacio-nes OSBI puedan competir con las aplicacio-nes privativas y, en algunos casos, a marcartendencias e impulsar ideas muy innovadoras.Como es costumbre, y parte de la cultura delsoftware libre y open source, existe un grannúmero de foros, blogs, wikis, redes sociales(por ejemplo Red Open BI7 ), etc., que son degran calidad. Millones de usuarios alrededordel mundo, utilizan estos medios como for-ma primaria para realizar aportes y compartirconocimientos, posibilitando que los diver-sos proyectos crezcan continuamente y sehagan robustos, haciendo de estos softwaresuna opción viable y segura.

El OSBI ha brindado la posibilidad a peque-ñas y medianas empresas de implementarsoluciones de BI, antes denegadas por el altocosto de las herramientas, aumentando nota-blemente la demanda de este tipo de solucio-nes. La demanda no solo se remite a lacantidad, sino al aumento de requerimientosfuncionales y no funcionales como: mejoresinterfaces, mayor interactividad, respuestasen menor tiempo, entrega de información endiversas formas y por diversos canales, etc.



monografía

Notas

5. Conclusiones y trabajo futuroA modo de conclusión, puede remarcarse quela evolución hacia el BI 2.0, y más particular-mente el énfasis hacia la usabilidad, ha idodesarrollándose al compás de los procesos deavance y maduración de las herramientas yaplicaciones, el hardware utilizado, los reque-rimientos de los usuarios en cuanto a lo quese espera de un aplicación BI actual(interactividad, familiaridad, GUI intuitivas,wizards, etc) y el mundo OSBI.

Podemos asumir entonces que el rumbo semantendrá hacia direcciones similares en elcambio de tecnologías. Consideramos queno es descabellado pensar un escenario nomuy lejano en el cual un encargado de stockde supermercado se acerca a una góndola y leordena a su móvil mediante un comando devoz "estado stock", mientras apunta la cáma-ra de tal manera que abarque una serie deproductos distintos; inmediatamente en lapantalla y sobre la imagen que se está captu-rando aparecerían agrupados por coloressemitransparentes, los productos del mismotipo, donde la intensidad del color estaríaindicando el estado del stock. El encargadopodría presionar sobre una de estas áreas, lasque poseen un icono de alerta que le indica lanecesidad de reposición inminente; es posibleenriquecer el ejemplo planteando que, ade-más de estas facilidades, aparecería una pan-talla en el móvil de este encargado mostrandoun gráfico histórico de stock donde se podríaanalizar rápidamente la tendencia y estacio-nalidad (entre otras cosas). Esta informa-ción permitiría a nuestro encargado tomar la

decisión de reposición de stock a través de sumóvil, mediante un comando de voz "realizarpedido"; si esto sucediera aparecería en lapantalla un mensaje preconfigurado para elproveedor más conveniente (por cercanía, porprecio, por eficiencia, etc.) con los datos delpedido y sin más que la orden verbal de"enviar". El trabajo de este proveedor imagi-nario también se realizaría desde y con sumóvil.

El ejemplo anterior no es un relato de cienciaficción ni mucho menos un delirio. Estamosalineados en los rieles de este desarrollo, faltamaduración pero las tecnologías ya existen yson algunas de las mencionadas anterior-mente.

AgradecimientosA Andrea Martino por su colaboración en cuantoal estilo de redacción, ya que de otra manera elartículo hubiese sido demasiado "only-for-geeks".

Bibliografía

W. H. Inmon. Building the Data Warehouse. Wiley,3ª edición, 2002.Ralph Kimball. <http://www.kimballgroup.com/>.C.J. Date. Introducción a los Sistemas de Bases deDatos. Prentice Hall. 6ª edición, Addison-Wesley.G.W. Hansen, J.V. Hansen. Diseño y Administraciónde Base de Datos. Prentice-Hall, 1997.R. Elmasri, S. Navathe. Sistemas de Bases deDatos. Addison-Wesley Iberoamericana, 2ª edición.Rafael Camps Paré. Introducción a las bases dedatos.Dolors Costal Costa. Introducción al diseño de basesde datos.

Dolors Costal Costa. El modelo relacional y el álgebrarelacional.Andrew Tanenbaum, Maarten Van Steen. Distributedsystems - Principles and Paradigms.

1 Las definiciones siguientes fueron tomadas dela Wikipedia: <http://es.wikipedia.org/wiki/Usabilidad>.2 Ing. R. Dario Bernabeu. DATAWAREHOUSING:Investigación y Sistematización de Conceptos -HEFESTO: Metodología para la Construcción de unData Warehouse (Versión 2.0 – 19 de julio de2010) < http://www.dataprix.com/es/data-warehousing-hefesto>.3 Información es un conjunto de datos organiza-dos, ordenados y procesados que constituyen unmensaje que cambia el estado de conocimiento delsujeto o sistema que lo recibe. Fuente: Wikipedia.4 Integración de datos: conjunto de técnicas ysubprocesos que se encargan de extraer datosdesde diferentes orígenes, manipularlos, integrar-los, transformarlos, volcarlos en otra fuente dedatos, etc.5 Ajax, acrónimo de Asynchronous JavaScript AndXML (JavaScript asíncrono y XML), es una técnicade desarrollo web para crear aplicacionesinteractivas o RIA (Rich Internet Applications).Fuente: Wikipedia.6 El término Web 2.0 (2004–actualidad) estácomúnmente asociado con un fenómeno social,basado en la interacción que se logra a partir dediferentes aplicaciones en la web, que facilitan elcompartir información, la interoperabilidad, el di-seño centrado en el usuario y la colaboración enla World Wide Web. Ejemplos de la Web 2.0 sonlas comunidades web, servicios web, aplicacio-nes web, blogs, wikis, plataformas educativas,entornos para compartir recursos, redes sociales.Fuente: Wikipedia.7 Red Open BI es la primera red social en españoldedicada al OSBI, <http://www.redopenbi.com/>.



Factores críticos de éxito de unproyecto de Business Intelligence

1. IntroducciónHoy en día, estamos en el auge del movimien-to de la llamada inteligencia de negocio oBusiness Intelligence (BI). Casi todas lasorganizaciones se esfuerzan por crear y mejo-rar sus procesos y sistemas de toma de deci-sión. Una gran cantidad de nuevos proyectosde BI aparecen constantemente, pero la expe-riencia global en los últimos años no es tanbuena. Algo por lo general va mal en laejecución de proyectos de BI, ya que la mayo-ría de proyectos de BI (85%) no pudo lograrsus objetivos [1].

La disciplina de Business Intelligence es toda-vía un área muy joven [2]. Hemos encontradotrece enfoques metodológicos diferentes paraadministrar un proyecto de BI [3][4][5][6][7][8][9][10][11][12][13][14][15], yla mayoría de ellos se han definido en losúltimos 10 años. Pero, ¿cuáles son las razo-nes de esta tasa tan alta de fracasos frente ala gran cantidad de alternativas meto-dológicas?

De hecho, podríamos decir que la gran diver-sidad y heterogeneidad de enfoquesmetodológicos para proyectos BI muestra lainmadurez que todavía existe en este ámbito.Por lo tanto, elegir una metodología de BI noes una tarea fácil. J. Thomann y D.L. Wells[16] afirman que cada proyecto de BI y cadaorganización debe escoger la metodologíaespecífica que mejor se adapte a la organiza-ción y características del proyecto para tenermás posibilidades de éxito.

2. Enfoques metodológicos deBusiness IntelligenceEn este apartado vamos a revisar muy breve-mente los principales enfoques metodológicosexistentes para proyectos BI, así como susprincipales limitaciones.

El ciclo de vida de un proyecto de BI [17][18]implica múltiples fases, cíclicas y muchasveces ejecutándose en paralelo, de ahí la com-plejidad que puede llegar a tener. Se hanidentificado más de 900 tareas a ejecutar[17][19], cosa que hace que no sea del todosencillo definir una metodología única. Sonmuchos los enfoques metodológicos que laliteratura científica ha tratado. Según R.Cicchetti et al. [20] son éstos:

Jorge Fernández González1,Enric Mayol Sarroca2

1Director de Consultoría en BusinessIntelligence de Abast Solutions; 1,2 Departa-mento de Ingeniería de Servicios y Sistemasde Información (ESSI) de la UniversidadPolitécnica de Catalunya (UPC)

< j f e r n a n d @ a b a s t . e s > ,< j f e r n a n d @ a b a s t . e s > ,< j f e r n a n d @ a b a s t . e s > ,< j f e r n a n d @ a b a s t . e s > ,< j f e r n a n d @ a b a s t . e s > ,< m a y o l @ e s s i . u p c . e d u >< m a y o l @ e s s i . u p c . e d u >< m a y o l @ e s s i . u p c . e d u >< m a y o l @ e s s i . u p c . e d u >< m a y o l @ e s s i . u p c . e d u >

Resumen: El objetivo de encontrar la mejor metodología de Business Intelligence (BI) es difícil o imposi-ble, pero creemos que sí es posible identificar las características que dicha metodología debe cumplir. Eneste artículo hemos analizado las características principales de los proyectos de Business Intelligence ydistintos enfoques metodológicos usualmente utilizados. Este estudio revela que algunas metodologíastienen ciertas debilidades al no estar expresamente definidas para proyectos de BI, y por lo tanto no seajustan a las características específicas del proyecto o a las necesidades de los usuarios. Para ello, hemosidentificado cuales son los principales factores críticos de éxito de estos proyectos que pueden determinarcómo tendría que ser la "Metodología de BI". Hemos realizado un análisis de las principales publicacionesen este dominio anotando los factores que los distintos autores y enfoques de BI identifican comodeterminantes en el éxito y/o fracaso de un proyecto de BI. Hemos propuesto una agrupación de losmismos y una uniformización del vocabulario utilizado, proponiendo finalmente un subconjunto de losfactores críticos de éxito de proyectos de BI más significativos.

Palabras clave: Business Intelligence, Data Warehouse, factores de éxito, metodologías, proyectos.

Autores

Jorge Fernández González desarrolla su actividad profesional en dos ámbitos de actuación, el principalde ellos es como profesional de Sistemas de Información. En el que acumula más de 14 años deexperiencia y actualmente ejerce el cargo de Director de Consultoría en Business Intelligence deAbastSolutions. El segundo de sus ámbitos de actuación es el de docente universitario. Actualmente esProfesor Asociado al departamento de ESSI de la UPC y responsable de la asignatura “Sistemas deInformación para las Organizaciones” de la Facultad de Informática de Barcelona. También ha sidocolaborador docente en la Universitat Oberta de Catalunya (UOC), director académico y profesor enmasters y postgrados de la Fundación Politécnica y realiza sesiones como invitado en escuelas denegocio como ESADE , La Salle y EAE . En el ámbito de las publicaciones, ha colaborado con la revistaData TI en múltiples ocasiones, fue redactor de la revista Gestión del Rendimiento, es miembro del grupode expertos en español del portal BeyeNetwork, portal que reúne a los especialistas en BI a nivel mundial,y colabora como experto en todas las ediciones del BARC Business Intelligence Guide.

Enric Mayol Sarroca es Doctor Ingeniero en Informática desde abril del año 2000 por el programa deSoftware de la Universidad Politécnica de Cataluña y miembro del Departamento de Ingeniería de Serviciosy de Sistemas de Información. Actualmente ocupa la plaza de profesor contratado doctor en dichodepartamento y es profesor de la especialidad de Sistemas de Información del Grado en Informática de laFacultad de Informática de Barcelona, en la misma universidad. Miembro del grupo de investigaciónGESSI (Grupo de investigación en Ingeniería del Software para los Sistemas de Información) y del grupoSUSHITOS (Services for Ubiquitous Social and Humanistic Information Tecnologies and Open SourceResearch Group), participa en distintos proyectos de investigación. Sus intereses de investigación secentran en los Sistemas de Información, Business Intelligence, Gestión de Contenidos Digitales, e-Learning y la Ingeniería de Servicios. Es vocal de la Junta Directiva de la Societat Catalana de Genealogia,Heràldica, Sigil·lografia,Vexil·lologia i Nobiliaria (SCGHSVN) y el dominio de aplicación de su investigaciónse centra en la temática de Sistemas de Información y Genealogía.

Plan-Driven approachPlan-Driven approachPlan-Driven approachPlan-Driven approachPlan-Driven approach o o o o o Requeriment-Requeriment-Requeriment-Requeriment-Requeriment-Driven approachDriven approachDriven approachDriven approachDriven approachEsta metodología más tradicional no pareceadecuada para este tipo de proyectos [7] yaque este enfoque no satisfará las demandasfuturas de los usuarios, y los usuarios difícil-mente son capaces de definir y explicar comotoman sus decisiones.

Demand-Driven o User-Driven oDemand-Driven o User-Driven oDemand-Driven o User-Driven oDemand-Driven o User-Driven oDemand-Driven o User-Driven oPrototype-Driven ApproachPrototype-Driven ApproachPrototype-Driven ApproachPrototype-Driven ApproachPrototype-Driven Approach

Metodologías orientadas hacia la confecciónde prototipos [21] para la obtención de losrequisitos que sean lo suficientemente preci-sos [7]. Así pues, se busca mostrar al usuarioun prototipo funcional [22] para intentarcaptarlos lo mejor posible [23].

El punto débil de este enfoque está en asumirque todos los usuarios conocen la estrategiaempresarial y se comportan de forma cohe-rente con ella, lo cual no siempre es así. Pero



monografía

de serlo, si realmente son ellos los que van atomar las decisiones, son ellos también losque deberían dirigir el proceso de creación delsistema de BI.

La idea se fundamenta en crear un primerprototipo basado en los objetivos empresa-riales y a partir de ahí los usuarios definen lasnecesidades de información, las preguntasque le van a hacer al sistema BI, y el manteni-miento y evolución futura [24] del mismo.

B. Afolabi y O. Thiery [5] nos hablan de laimportancia de usuario para definirlo basán-dose en sus propias fases cognitivas (obser-vación, abstracción elemental, razonamientoy simbolización y creatividad). Se puede adap-tar nuestro sistema de BI al tipo de consultasque nos hará el usuario final (QueryAdaptation) y al tipo de respuestas que esperarecibir (Response Adaptation) [25].

Data-Driven ApproachData-Driven ApproachData-Driven ApproachData-Driven ApproachData-Driven ApproachEste enfoque [7] se centra en los datos: encómo están estructurados, en quién los usa,en la forma en que los usan. Se fija en losdatos con mayor tasa de acceso, aquellos quese consultan con mayor frecuencia, como serelacionan entre ellos, qué consultas suelenvenir asociadas. Son los datos los que dirigenel proceso. Este enfoque se basa en la premisade que los datos nunca mienten, mientras quede los usuarios es difícil de asegurar. Elproblema es que en este enfoque, a priori sedeja de lado a los usuarios, los objetivos dela organización y los futuros requisitos delsistema.

Value-Chain Data ApproachValue-Chain Data ApproachValue-Chain Data ApproachValue-Chain Data ApproachValue-Chain Data ApproachBasado en la cadena de valor del BusinessIntelligence [9], es una evolución del enfoqueData-Driven focalizada en los datos que ge-neraran mayor valor para el negocio, pero noresuelve las limitaciones de su predecesor.

Process-Driven ApproachProcess-Driven ApproachProcess-Driven ApproachProcess-Driven ApproachProcess-Driven ApproachEste enfoque se basa en el análisis de losprocesos de negocio [14], la información quegeneran y la información que consumen. Elproceso es la clave y se estructura la informa-ción según sea el usuario de proceso. Unaspecto que se puede perder de vista en esteenfoque, demasiado centrado en el proceso,es la perspectiva global de la organización ylas relaciones entre procesos, lo cual puedellevar a tener una visión incompleta o erróneade la organización.

Event-Driven ApproachEvent-Driven ApproachEvent-Driven ApproachEvent-Driven ApproachEvent-Driven ApproachEste enfoque propone dividir los procesos denegocio bajo tres puntos de vista: Datos,Función y Organización, cada una de loscuales se conecta entre sí a través de eventos.La gran ventaja de este enfoque es el análisisfuncional de la organización.

V. Stefanov y B. List [6] proponen este mis-

mo modelo extendido con objetos BI yconectores de información BI, como unamanera de rellenar el gap entre el negocio y lossistemas de BI. Este enfoque es muy comple-jo de llevar a la práctica y requiere una granexperiencia y modelos organizacionales muymaduros.

Object-Process Driven ApproachObject-Process Driven ApproachObject-Process Driven ApproachObject-Process Driven ApproachObject-Process Driven ApproachEs una de las variantes metodológicas amedio camino entre el Event-Driven y elProcess Driven [13]. En este enfoque, tantolos objetos como los procesos tienen la mis-ma importancia desde el punto de vistadecisional y por tanto se deben tratar de lamisma manera.

Joint ApproachJoint ApproachJoint ApproachJoint ApproachJoint ApproachEnfoque metodológico centrado en el reco-nocimiento de las arquitecturas funcionalescruzadas de las empresas. Los procesos noson de un solo departamento, sino que existenmuchos puntos de contacto y muchas juntu-ras [11], por lo tanto es donde se tiene quecentrar el esfuerzo. La idea es que la organi-zación es una matriz de procesos con diferen-tes necesidades de información, pero allí don-de se juntan es donde debemos hacer el mayoresfuerzo. La dificultad del enfoque puederadicar en la dificultad en definir los procesosde gestión y control de la información en estospuntos de contacto.

Goal-Driven ApproachGoal-Driven ApproachGoal-Driven ApproachGoal-Driven ApproachGoal-Driven ApproachEste enfoque [7] se centra en el objetivo de losprocesos estratégicos de la organización y sebasa en el análisis de la interacción que tantoclientes como usuarios hacen para conseguirdicho objetivo. A partir de ahí establece nece-sidades de información e interrelaciones entreellas que darán lugar a la estructura delsistema de Business Intelligence. El problemapuede aparecer cuando no existe un conoci-miento o alineamiento preciso entre los pro-cesos estratégicos y los tácticos o opera-cionales.

Triple-Driven ApproachTriple-Driven ApproachTriple-Driven ApproachTriple-Driven ApproachTriple-Driven ApproachVista la inmadurez de las metodologías deBusiness Intelligence, en Y. Guo et al. [12]apuestan por una combinación de las mejoresideas de cada una de las metodologías Goal,Data y User Driven, creando la Triple-Driven,pues se considera que estos tres enfoques sonperfectamente compatibles.

Model Driven ApproachModel Driven ApproachModel Driven ApproachModel Driven ApproachModel Driven ApproachOtra de las metodologías que se han usado enBI es la Model Driven [3][4]. Con ella, sepretende tender un puente entre el negocio y eldepartamento de Informática, intentandoproporcionar la base para desarrollar solu-ciones rápidas, que evolucionen fácilmente yflexibles. Debido a su alto nivel de lareutilización de la abstracción y del código, lametodología MDA (Model-DrivenArchitecture) se ha aplicado extensamente. El

MDA permite reducir tiempo de desarrollo desoftware, la mejora de la calidad y del mante-nimiento de la solución. Pero por el contrario,es difícil definir este modelo simplificado de larealidad y aún es difícil de implantar sobrearquitecturas SOA (Service-OrientedArchitecture) y en organizaciones reales.

Adaptive Business ApproachAdaptive Business ApproachAdaptive Business ApproachAdaptive Business ApproachAdaptive Business ApproachLa metodología Adaptive Business Approach[8] se basa estrictamente en aquellos aspec-tos realmente relevantes para el negocio y suevolución. Se centra en los problemas que elnegocio tiene que resolver para adaptarse alos cambios del mercado y en los datos de quedisponemos para ello. El resultado de lossistemas de Business Intelligence han de ser obien la solución al problema o bien la aporta-ción de más conocimiento sobre el problemapara seguir analizando y tomando decisionespara hallar dicha solución. El centrarse ensolo lo relevante para el cambio, puede dejarde lado o no considerar explícitamente otrosaspectos no tan críticos del negocio, pero quedeterminan o influyen en aspectos más rele-vantes. Por lo tanto estas dependencias tienenque tenerse en cuenta explícitamente y noobviarse.

Agile ApproachAgile ApproachAgile ApproachAgile ApproachAgile ApproachSi este enfoque puede considerarse novel en elárea de ingeniería del software, lo es más en elárea de Business Intelligence. La primerareferencia académica que encontramos refe-rente al uso de las metodologías ágiles en BIes un pequeño articulo divulgativo en el año2001 de apenas 2 páginas en el que L.T. Moss[10] comenta que sería posible realizar pro-yectos de Business Intelligence con rigor usan-do las metodologías ágiles. Posteriormente,J. Fernández et al. [26] analizan la correlaciónentre los principios básicos de lasmetodologías ágiles y las necesidades de unametodología de BI. Entre tanto, algunostrabajos adicionales aparecen, pero sorpren-de la reducida cantidad de trabajos académi-cos del tema respecto al enorme numero deartículos de experiencias reales del tema, cre-ciendo exponencialmente en 2011.

3. Como debe ser la metodologíade BITanta diversidad de enfoques metodológicosdenota la inmadurez que existe en este tipo desoluciones, las interrelaciones no son clarasy elegir una metodología no es nada fácil. Lostrabajos [16][27] nos muestran que paracada proyecto de BI y para cada organizacióndebe seleccionarse la metodología que másposibilidades de éxito tenga.

L.T. Moss [19] nos propone las característi-cas que debería cumplir una metodologíapara este tipo de sistemas decisionales, a lasque hemos incluido las dos característicasfinales:1) Ha de estar orientada al cambio y no a la



consecución de un producto final.2) La gestión del proyecto debe ser de formaglobal y transversal a toda empresa.3) Debe poder manejar múltiples subproyectosa la vez y en paralelo.4) Ha de tener en cuenta todas las tareas/procesos de la empresa, sean o no críticos.5) Debe basarse en la gestión de los caminoscríticos del workflow empresarial.6) Debe estar orientada a las personas yrelaciones entre ellas.7) Ha de estar alineada con las necesidades denegocio de la organización.

Estas características se han sintetizado apartir de la experiencia práctica y la realidad,y se presentan con un enfoque más de divul-gación empresarial que académico o científi-co. Por ello, creemos que un enfoque comple-mentario para determinar cuales son lasmetodologías más adecuadas para la gestiónde un proyecto BI es basarnos en un procesode análisis de factores críticos de éxito de todoproyecto de BI. Por eso es necesario, en primerlugar, analizar cuales son los factores de éxitode los proyectos de BI más citados yreferenciados en la bibliografía académica.Actividad que queremos reflejar en los si-guientes apartados.

4. Factores críticos de éxito (FCE)Un estudio realizado por la Universidad deMonash [1] concluye que el 85% de los pro-yectos de BI han fracasado en la consecuciónde sus objetivos. Así pues, ¿Qué determina eléxito y el fracaso de esos proyectos? A nuestroentender, una análisis de los factores críticosde éxito de estos proyectos ha de dar respuestaa esta pregunta.

Para introducir estos factores de éxito, lospresentamos agrupados por categorías, nume-rados de 1) a 6), según el aspecto del proyectoBI que contemplan. Hemos dejando una últimacategoría para todos aquellos factores identifi-cados en una revisión bibliográfica que hemosrealizado, siendo todos ellos aspectos que losautores aseguran que influyen positivamente onegativamente al éxito o fracaso de un proyectoBI. Este último conjunto de factores, será el queintentaremos reagrupar y priorizar en el siguien-te apartado.

1) Relativos a las herramientas de BI1) Relativos a las herramientas de BI1) Relativos a las herramientas de BI1) Relativos a las herramientas de BI1) Relativos a las herramientas de BI¿Están fallando las herramientas de BI res-pecto a lo que se espera de ellas? En el trabajode B. Azvine et al. [28] se nos dice que lasactuales herramientas de BI han estado fa-llando en tres puntos principales:

En la visualización de la información de loque ha pasado.

En ayudar a comprender la razón o lascausas de lo que ha pasado.

En la predicción de lo que sucederá.

Si realmente depende de la validez de lasherramientas de BI, entonces, no es necesario

preocuparse por la metodología a utilizar. Laverdad es que esta visión [28] podría serdemasiado alarmista. Pero hay que reconocerque las herramientas de BI padecen aún de ungran déficit en los dos últimos puntos, aun-que poco a poco van mejorando su fiabilidad.

2 )2 )2 )2 )2 ) Relativos a la organizaciónRelativos a la organizaciónRelativos a la organizaciónRelativos a la organizaciónRelativos a la organizaciónUna de las características básicas para el éxitodel BI es, sin duda, la cultura organizacionaly el nivel de madurez de la organización. Perola creación y gestión de una cultura y un nivelde madurez requiere mucho tiempo. K.R.Quinn [29] ofrece cinco reglas para el éxito yotras 5 causas del fracaso de los proyectos deBI relacionados con la organización:+ Comprender a los usuarios.+ Utilizar el paradigma de los clicks.+ Distinguir claramente entre usuarios pro-ductores y usuarios consumidores de infor-mación.+ Establecer una cultura organizativa demedición y evaluación.+ Conseguir que el proyecto de BI sea unadecisión estratégica de toda la compañía.- Se desestiman las necesidades y deseos delos usuarios.- Se hace demasiado énfasis en fases menoscríticas.- La información no es auto-explicable,poco énfasis en la semántica.- No se ha establecido una estrategia demedición.- El proyecto BI solo se ha aplicado tácti-camente, no estratégicamente.

3 )3 )3 )3 )3 ) Relativos a la gestión del conoci-Relativos a la gestión del conoci-Relativos a la gestión del conoci-Relativos a la gestión del conoci-Relativos a la gestión del conoci-mientomientomientomientomientoOtro punto a tener en cuenta al evaluar el éxitode las soluciones de BI se encuentra en losdéficits o limitaciones del propio Departa-mento de Sistemas de Información. J. Beckeret al. [30] enumeran las deficiencias en lagestión del conocimiento en los departamen-tos de BI.

La primera limitación que identifican es ladificultad para definir estructuras adecuadaspara la localización de la información. El 30%de los documentos con información relevantese almacena y manipula en ordenadores per-sonales o portátiles aislados por lo que elacceso a dicha información está limitando yaccesible solamente a un conjunto limitadode usuarios en la organización, y no se faci-litan los mecanismos para compartirlos conel resto de personal interesado.

Una segunda limitación es la dificultad delpersonal respecto al acceso al conocimientopara ejercer sus funciones satisfactoriamen-te. Esta adquisición del conocimiento requie-re tiempo y dinero de la empresa repercutidoen las iniciativas de formación, pero estosrecursos son de difícil reutilización. Si a ellose suma una alta rotación de empleados, laspérdidas pueden llegar a ser considerables.

4 )4 )4 )4 )4 ) Relativos a aspectos intangiblesRelativos a aspectos intangiblesRelativos a aspectos intangiblesRelativos a aspectos intangiblesRelativos a aspectos intangiblesEl éxito de la solución del proyecto BI ha detener presente el componente intangible delproyecto que también debe ser evaluado. A.Counihan et al. [31] ya identificaban la difi-cultad de evaluar los aspectos intangibles delos sistemas de información estratégicos. Porotra parte, M. Gibson et al. [32] identificabanseis criterios para evaluar los beneficiosintangibles de los sistemas de BI:

Determinar la criticidad de las cuestionesintangibles.

Separar los requisitos de los usuarios delos aspectos intangibles propios del proyecto.

Convencer de la importancia de losintangibles a los gerentes de la empresa.

Clasificar adecuadamente los intangiblespara hacer más fácil su evaluación.

Gestionar el proyecto orientado a resulta-dos rápidos (quick win).

Medir el nivel de cumplimiento de losintangibles.

5 )5 )5 )5 )5 ) Relativos al personal y al liderazgoRelativos al personal y al liderazgoRelativos al personal y al liderazgoRelativos al personal y al liderazgoRelativos al personal y al liderazgoOtro factor a tener en cuenta que puededeterminar el éxito o el fracaso del proyecto BIes el perfil, experiencia y formación de laspersonas involucradas en el proyecto, la im-plantación y, especialmente en el liderazgo. Eneste sentido, A. Faulkner y A. MacGillivray[33] identifican 12 aspectos o requisitos quedebería satisfacer el líder del proyecto paraasegurar un posible éxito del proyecto BI:

Saber reflexionar antes que actuar sobrelos valores de la organización.

Focalizar los objetivos del proyecto en lasnecesidades más urgentes de la organización,a fin de que los resultados sean visibles lo máspronto posible.

Ser un antropólogo amateur, identifican-do las necesidades del negocio y quienes lasestán gestionando, para proveerles de herra-mientas fáciles de usar según sus habilidades,necesidades y preferencias personales.

Planificar para el éxito. Es decir, compren-der como la organización evalúa el éxito ydirigirse hacia él.

Ser un niño de pequeño, preguntandosiempre el porqué de todo.

Conseguir que el proyecto sea una inicia-tiva de cambio e innovación para toda laorganización.

Dialogar, dialogar y dialogar.Integrar e involucrar a los ejecutivos y

directores intermedios como co-lideres delproyecto, para que sientan el proyecto comosuyo.

Ser proactivo, anticipar la resistencia alcambio y convertirse en el paladín de la causade BI.

Aprender de los demás.Evaluar el coste y el riesgo de la alternativa

a no usar herramientas BI, y usarlo comoargumento.

Tener una mente abierta y una visiónglobal de la evolución que puede tener el BIdentro de la organización.



monografía

Por otro lado, T. Chenoweth et al. [34]afirman que la interacción entre la tecnologíay el contexto social de las empresas claramen-te determina el éxito o el fracaso de un bancode datos común a la organización. Y al mis-mo tiempo, reconocen que esta mismainteracción puede determinar la extensión yevolución de un sistema de BI. En este senti-do, proponen siete intervenciones clave, comouna lista ordenada de preguntas básicas aconsiderar en todo proyecto BI.

¿El proyecto tiene el apoyo de la direc-ción?

¿Los futuros usuarios apoyan el proyec-to?

¿Los usuarios accederán con el sistema aun amplio abanico de datos?

¿Los usuarios necesitan herramientasrestrictivas?

¿Los usuarios entienden la relación exis-tente entre la información que les proporcio-nará el sistema BI y los procesos de negocioque llevan a cabo?

¿Los usuarios perciben al departamentode SI como soporte y ayuda en la realizaciónde sus procesos de negocio?

¿Existen usuarios líderes o ‘power users’?

La principal conclusión en este apartado esque el usuario es el centro de todo, y que laimplicación del usuario en el proyecto BI vaa determinar claramente el éxito o el fracasodel mismo

6 )6 )6 )6 )6 ) Otros factores críticos de éxitoOtros factores críticos de éxitoOtros factores críticos de éxitoOtros factores críticos de éxitoOtros factores críticos de éxitoEn esta sección proporcionamos una listaexhaustiva de FCE obtenida a partir de unarevisión de la literatura científica y académica.En los trabajos analizados, se proponen di-versos FCE sin focalizarlos en temas especí-ficos de Business Intelligence como en lasagrupaciones anteriores. En este caso, sonmás genéricos pero igualmente relevantes ycríticos.

M.D. Solomon M.D. Solomon M.D. Solomon M.D. Solomon M.D. Solomon [35]]]]] nos propone una guíade aspectos a considerar cuando se lleva acabo la implementación de una solución de BIo de Data Warehouse1.• El usuario participa en la definición delnivel de servicio y los requisitos de informa-ción.• Identificar los sistemas de provisión dedatos.• Definir plan de calidad.• Elegir un modelo de diseño adecuado.• Escoger la herramienta ETL (Extract,Transform and Load) a usar.• Realizar cargas de datos incrementalespreferentemente.• Escoger cuidadosamente la plataformade desarrollo BI y el SGBD adecuado.• Realizar procesos de conciliación de da-tos.• Revisar y modificar periódicamente la

planificación.• Proveer soporte al usuario.

L.T. Moss L.T. Moss L.T. Moss L.T. Moss L.T. Moss [19] resume los 10 errores másfrecuentes en la gestión de proyectos de BI yde Data Warehouse.• No usar ninguna metodología.• No disponer del equipo adecuado.• Los usuarios y decisores no participan enel proyecto.• Descomposición del proyecto en etapasinadecuadas.• Inexistencia de una planificación del pro-yecto.• Inexistencia de un plan de calidad.• Pruebas de calidad incompletas o inade-cuadas.• No prever el volumen de datos amonitorizar o depurar.• Ignorar metadatos y semántica de datos.• Depender en exceso (ser esclavo) de laherramienta de gestión del proyecto.

D. Briggs et al. D. Briggs et al. D. Briggs et al. D. Briggs et al. D. Briggs et al. [36][37] proponen lossiguientes FCE para sistemas decisionales:• Patrocinio del proyecto.• Gestión de las expectativas del usuario.• Uso de prototipos.• Búsqueda del resultado rápido (quick win)• Escoger un problema de la organizaciónmedible.• Modelización y diseño del data warehouse.• Selección del caso de negocio adecuado.• Alineación con la estrategia organizativa.• Selección cuidadosa de las herramientas.• Usuarios finales involucrados.• Gestión del cambio organizativo.• Consideración de la cultura de la organi-zación.• Centrarse en la gestión de los datos.• Nivel de escalabilidad y flexibilidad delproyecto y la solución.• Transmitir el conocimiento en proyectossubcontratados.• Uso de estándares.• Aprovechamiento de la experiencia de losmiembros del equipo.• Soporte al usuario final.

B.H. Wixom y H.J. Watson B.H. Wixom y H.J. Watson B.H. Wixom y H.J. Watson B.H. Wixom y H.J. Watson B.H. Wixom y H.J. Watson [38][39]identifican los siguientes factores como losmás relevantes para un proyecto BI:• Apoyo a la gestión de la organización.• Existencia de un líder del proyecto.• Uso adecuado de los recursos.• Participación del usuario final.• Equipo con competencias adecuadas.• Disponer de fuentes de datos adecuadas.• Considerar la información y su análisiscomo parte de la cultura de la organización.• Alineamiento con la estrategia de la orga-nización.• Gestión y control del BI eficaz.

D. Sammon y P. Finnegan D. Sammon y P. Finnegan D. Sammon y P. Finnegan D. Sammon y P. Finnegan D. Sammon y P. Finnegan [40] propo-nen los 10 mandamientos del proyecto BI:• Iniciativa ligada a las necesidades del ne-gocio.• Existencia de patrocinio de la dirección.• Gestión de las expectativas del usuario.• Proyecto transversal a la organización.• Control de calidad.• Flexibilidad del modelo de datos.• Gestión orientada a los datos.• Proceso automático de extracción de da-tos.• Conocimiento.• Experiencia.

R. Weir et al. R. Weir et al. R. Weir et al. R. Weir et al. R. Weir et al. [41] proponen este conjuntode mejores prácticas de BI:• Realizar cambios incrementales.• Construcción del sistema adaptable.• Gestionar expectativas del usuario.• Equipo mixto entre técnicos y usuariosfinales.• Contacto directo con la organización y elnegocio.• No perseguir la perfección.

R.S. Abdullaev y I.S. Ko R.S. Abdullaev y I.S. Ko R.S. Abdullaev y I.S. Ko R.S. Abdullaev y I.S. Ko R.S. Abdullaev y I.S. Ko [42] analizanlas lecciones aprendidas de diversas experien-cias en la construcción de BI:• La centralización de datos en un datawarehouse y su agregación en varios datamarts2 permiten un acceso rápido y de con-fianza a la información solicitada.• La definición de listados estándares paratodos los usuarios favorece el intercambio deinformación entre departamentos de unamanera más clara y consistente.• Algunos modelos de informes predefinidosse han de implementar con el fin de proporcio-nar a los decisores la funcionalidad paraañadir o eliminar elementos necesarios y crearinformes específicos.• Es necesario un equipo responsable dealinear las especificaciones de informesestándar con las necesidades locales y quefacilite la ejecución del proyecto de BI.• Debe existir un fuerte compromiso de ladirección para resolver cualquier conflicto ygestionar los cambios que ocurran durante eldesarrollo del proyecto.• La integración de técnicas "Six Sigma" enla infraestructura TI de la organización con-tribuye a un sistema BI robusto.• La infraestructura TI ha de centrarse enuna sola plataforma proporcionada porproveedores bien conocidos.

I.S. Ko y R.S. Abdullaev I.S. Ko y R.S. Abdullaev I.S. Ko y R.S. Abdullaev I.S. Ko y R.S. Abdullaev I.S. Ko y R.S. Abdullaev [43] identificanlos aspectos especialmente críticos durante eldesarrollo de proyectos de BI:• Requisitos del mercado y del cliente enlugar de requisitos internos.• Disponer de personal representante de cadadepartamento dedicados al proyecto.



• Equipo formado por personal competen-te en el proyecto.• Adopción de una metodología de desa-rrollo de proyectos BI.• Realizar y seguir una planificación delproyecto.• Estandarización de los datos.• Control de calidad de los datos.• Existencia de metadatos.• Usar solo las herramientas necesarias.

W. Yeoh et al. W. Yeoh et al. W. Yeoh et al. W. Yeoh et al. W. Yeoh et al. [44] realizan unarecompilación de FCE para proyectos de BI:• Soporte al proyecto por parte de la altadirección.• Disponer de los recursos adecuados.• Apoyo comprometido por parte de la or-ganización.• Participación formal del usuario a lo lar-go de todo el proyecto.• Soporte, formación y entrenamiento.• Caso de negocio establecido yconsensuado.• Visión estratégica de BI integrada con lasiniciativas de la compañía.• Ámbito del proyecto claramente definido.• Adopción de un enfoque de resultadosincrementales.• Proyecto orientado a resultados rápidos(quick wins).• Equipo poseedor de la perfecta combina-ción de capacidades.• Participación de consultoría externa enfases iniciales del proyecto.• Experiencia en el dominio del negocio.• Equipo multifuncional.• Sistemas proveedores de datos estables.• Entorno técnico estratégico, escalable yextensible.• Prototipo usado como prueba de concep-to.• Disponer de fuentes de datos de calidad.• Métricas y clasificaciones comunes esta-blecidas por la organización.• Modelo de metadatos escalable.• Gobierno de los datos por la organiza-ción.

5. Clasificación y agrupaciónLa revisión bibliográfica realizada para iden-tificar factores críticos de éxito, mejores prác-ticas y recomendaciones de cómo llevar acabo un proyecto BI ha de permitir identificarlos requisitos deseables de la ‘Metodología’más adecuada a un proyecto BI concreto.

En primer lugar hemos analizado, clasificadoy agrupado todos FCE, mejores prácticas yrecomendaciones enumeradas en el apartadoanterior en tres grupos básicos:

Factores Primarios: los aspectos o facto-res propuestos por más de cinco autores.

Factores Secundarios: los aspectos o fac-tores propuestos por más de un y menos de

cinco autores.Factores de Autor: aquellos que sólo han

sido identificados por un solo autor.

Los autores que proponen alguno de losfactores primarios y secundarios, usan termi-nología y semánticas ligeramente distintas. Acontinuación, intentamos describir estos FCEcon una terminología y semántica unificadarespecto a todas las apariciones del factor enla bibliografía consultada.Por lo tanto, un proyecto BI ha de:

Factores PrimariosEstar enfocado a la gestión de datos.Usar una metodología de gestión del pro-

yecto.Considerar primordialmente las necesi-

dades y características del decisor.Ser una herramienta de soporte a la ges-

tión de la organización.Proporcionar resultados rápidos ya en las

primeras fases.Usar herramientas seleccionadas con cui-

dadosamente.Tener los usuarios finales involucrados

en el proyecto.

Factores SecundariosDisponer de recursos adecuados.Contemplar la cultura organizativa.Disponer de un diseño de data warehouse

adecuado.Tener un equipo de trabajo capacitado y

con experiencia y conocimiento.Tener el soporte y apoyo de la organiza-

ción y dirección.Estrategia y dirección del BI alineadas con

estrategia del negocio.Estar orientado a la gestión del cambio de

la organización.Hacer cargas de datos incrementales.Tener una definición clara y precisa de los

resultados e informes para el usuario.

Los Factores Primarios tienen una media de9,4 ocurrencias, mientras que para los Secun-darios la media es de 3,4. El rango de numerode apariciones para los Factores Primarios esde [15, 6] y para los Secundarias es [5, 2]. LosFactores Primarios corresponden al 66% detodos los FCE identificados en la revisiónbibliográfica realizada, mientras que Facto-res Secundarios representan el 33% restante.Por lo tanto, entendemos que la selección delos FCE propuestos es representativo de losFCE de un proyecto BI y que toda metodo-logía de gestión de proyectos BI debería so-portar.

6. ConclusionesCon el surgimiento de la Inteligencia delNegocio o Business Intelligence en los últi-mos años, todas las organizaciones hacenesfuerzos para crear o mejorar sus procesosde decisión y sistemas decisionales. Una grancantidad de nuevos proyectos de Business

Intelligence aparecen constantemente, pero laexperiencia no es tan buena como era deesperar, porque una enorme cantidad de pro-yectos de BI (85%) no alcanzan sus objetivosiniciales.

Una gran diversidad y heterogeneidad de enfo-ques metodológicos para la gestión de pro-yectos BI muestra el estado de la novedad y lainexperiencia que todavía existe en este ámbi-to. Elegir una metodología de BI no es unatarea fácil. La implementación y gestión de unproyecto de BI puede suponer múltiples fasesy más de 900 tareas. Por lo tanto, no es tanfácil de identificar una metodología de sopor-te satisfactoriamente a un proyecto de tantacomplejidad y en todos sus aspectos y dimen-siones.

En este artículo hemos resumido los princi-pales enfoques metodológicos existentes parala gestión e implementación de un proyecto deBI. Hemos detectado las principales limita-ciones de éstas y analizado cuales tendrían deser las características de ‘la metodología deproyectos BI’. Para identificar estas caracte-rísticas, nos hemos basado en los FactoresCríticos de Éxito de proyectos de BusinessIntelligence que han sido propuestos reciente-mente en las publicaciones académicas y cien-tíficas más relevantes.



monografía

Referencias

[1] U.M. Fayyad. Tutorial report. Summer school ofDM. Monash Uni Australia.[2] R. Preston. Business Intelligence Still In ItsInfancy. Information Week. Último acceso: julio2010, <http://www.informationweek.com/story/showArticle.jhtml?articleID=196801521>.[3] P. Chowdhary, G.A. Mihaila, H. Lei. ModelDriven Data Warehousing for Business Perfor-mance Management. ICEBE 2006: pp 483-487.[4] P. Chowdhary, K. Bhaskaran et al. ModelDriven Development for Business PerformanceManagement. IBM Systems Journal, vol 45, nº 3,pp 587-605.[5] B. Afolabi, O. Thiery. Using Users’ Expectationsto Adapt Business Intelligence Systems. Últimoacceso: julio 2010, <http://arxiv.org/ftp/cs/papers/0608/0608043.pdf>.[6] V. Stefanov, B. List. Bridging the Gap betweenData Warehouses and Business Processes: A Bu-siness Intelligence Perspective for Event-DrivenProcess Chains. EDOC 2005: pp. 3-14.[7] J. Rowan. Design Techniques for a BusinessIntelligence Solution. Auerbach Publications 2003.[8] T. Bäck. Adaptive business intelligence based onevolution strategies: some application examples ofself-adaptive software. Inf. Sci. 148(1-4): pp. 113-121.[9] M.K. Brohman, M. Parent, M. Pearce, N. Wade.The Business Intelligence Value Chain: Data-DrivenDecision Support in a Data Warehouse Environment:An Exploratory Study. HICSS 2000.[10] L.T. Moss. Business Intelligence Methodologies,Agile with Rigor. Cutter IT Journal. vol. 14, no 12, pp.19-26.[11] S. March, A.R. Hevner. Integrated decisionsupport systems, A data warehousing perspective.Decision Support Systems, 2005.[12] Y. Guo, S. Tang, Y. Tong, D. Yang. Triple-drivendata modeling methodology in data warehousing: acase study. DOLAP 2006: pp: 59-66.[13] D. Dori, R. Feldman, A. Sturm. An OPM-basedMethod for Transformation of Operational SystemModel to Data Warehouse Model. SwSTE 2005, pp.57-66.[14] C. Kaldeich, J. Oliveira e Sá. Data WarehouseMethodology: A Process Driven Approach. CAiSE2004, pp. 536-549.[15] L. Niu, G. Zhang. A Model of Cognition-DrivenDecision Process for Business Intelligence. WebIntelligence, 2008 pp. 876-879.[16] J. Thomann, D.L. Wells. Implementing DataWarehousing Methodology- Guideline for Success.TDWI 2000.[17] L.T. Moss, Sh. Atre. Business IntelligenceRoadmap: The Complete Project Lifecycle for DecisionSupport Applications. Addison Wesley Longman,2003. ISBN-10: 0201784203.[18] G.R. Gangadharan, S.N. Swami. BusinessIntelligence Systems Design and ImplementationStrategies. IT1 2004, pp. 139-144.[19] L.T. Moss. Ten Mistakes to avoid for DataWarehouse Projects Managers. TDWI’S best ofBusiness Intelligence Vol 3, pp. 16-22.[20] R. Cicchetti et al. (Eds.). A Comparison of DataWarehouse Development Methodologies Case Studyof the Process Warehouse. DEXA 2002, LNCS 2453,pp. 203–215, 2002.[21] T.N. Huynh, J. Schiefer. Prototyping DataWarehouse Systems. DaWaK 2001, pp. 195-207.[22] W. Yang, P. Hou, Y. Fan, Q. Wu. The Researchof an Intelligent Object-Oriented Prototype for DataWarehouse. ICIC (1), 2006, pp. 1300-1305.

[23] R. Winter, B. Strauch. A Method for Demand-driven Information Requirements Analysis in DataWarehousing Projects. Proceedings of the 36thHawaii International Conference on System Sciences(HICSS’03).[24] H. Engström, S. Chakravarthy, B. Lings. AUser-centric View of Data Warehouse MaintenanceIssues. BNCOD 2000, pp. 68-80.[25] D. Schuff, K. Corral, O. Turetken. Comparingthe Effect of Alternative Data Warehouse Schemason End User Comprehension Level. ICIS’05 <http://mis.temple.edu/sigdss/icis05/>.[26] J. Fernández, E. Mayol, J.A. Pastor. AgileBusiness Intelligence Governance: Su justificación ypresentación. ITSMF 2008, <http://www. uc3m.es/portal/page/portal/congresos_jornadas/congreso_itsmf/Agile%20Business%20Intelligence%20Governance.pdf>.[27] J. Thomann, D.L. Wells. Evaluating DataWarehousing Methodologies- An Evaluation Process.TDWI 1999.[28] B. Azvine, Z. Cui, D.D. Nauck. Towards real-time business intelligence. BT Technology Journal Vol23 No 3 July 2005, pp. 214-225.[29] K.R. Quinn. Establishing a culture ofMeasurement, a practical guide to BI. White PaperInformation Builders 2003.[30] J. Becker, L. Vilkov, C. Brelage.Multidimensional Knowledge Spaces for StrategicManagement - Experiences at a Leading Manufacturerof Construction and Mining Equipment. DEXAWorkshops 2004, pp. 482-487.[31] A. Counihan, P. Finnegan, D. Sammon. Towardsa framework for evaluating investments in datawarehousing. Inf. Syst. J. 12(4), pp. 321-338.[32] M. Gibson, D. Arnott, I. Jagielska. Evaluatingthe Intangible Benefits of Business Intelligence:Review & Research Agenda. IFIP TC8/WG8.3International Conference, 2004.[33] A. Faulkner, A. MacGillivray. A business lenson business intelligence – 12 tips for success.ODTUG 2001.[34] T. Chenoweth, K. Corral, H. Demirkan. Sevenkey interventions for data warehouse success.Commun. ACM 49(1), pp. 114-119.[35] M.D. Solomon. Ensuring a successful datawarehouse initiative. ISM Journal winter 2005, pp, 26-36.[36] D. Briggs, D. Arnott. Decision Support SystemsFailure: An Evolutionary Perspective (Working Paper.No. 2002/01). Melbourne, Australia: Decision SupportSystems Laboratory, Monash University.[37] D. Briggs. A Critical Review of Literature on DataWarehouse Systems Success/Failure (WorkingPaper. No. 2004/01). Melbourne, Australia: DecisionSupport Systems Laboratory, Monash University.[38] B.H. Wixom, H.J. Watson. An empiricalinvestigation of the factors affecting data warehousesuccess. MIS Quarieriy Vol. 25 No. 1, pp. 17-41,marzo 2001.[39] B.H. Wixom, H.J. Watson. The Current Stateof Business Intelligence. IEEE Computer (COMPUTER)40(9), pp:96-99.[40] D. Sammon, P. Finnegan. The TenCommandments of Data Warehousing. The DATABASE for Advances in Information Systems, Vol. 31,No. 4.[41] R. Weir, T. Peng, J.M. Kerridge. Best Practicefor Implementing a Data Warehouse: A Review forStrategic Alignment. DMDW 2003.[42] R.S. Abdullaev, I.S. Ko. A Study on SuccessfulBusiness Intelligence Systems in Practice. JCIT 2(2),pp. 89-97.[43] I.S. Ko, R.S. Abdullaev. A Study on the Aspects

Notas

of Successful Business Intelligence SystemDevelopment, Computational Science – ICCS 2007.[44] W. Yeoh, J. Gao, A. Koronios. Towards aCritical Success Factor Framework for ImplementingBusiness Intelligence Systems: A Delphi Study inEngineering Asset Management Organizations.CONFENIS 2007.

1 Un Data Warehouse (DW) es una base de datosusada para generación de informes. Los datos soncargados desde los sistemas operacionales parasu consulta. Pueden pasar a través de un almacénde datos operacional para operaciones adicionalesantes de que sean usados en el DW para lageneración de informes (Traducción libre de laintroducción al concepto que se encuentra en laWikipedia en inglés el 24/6/2011: <http://en.wikipedia.org/wiki/Data_warehouse>). Sesuele considerar que el término equivalente encastellano es "Almacén de datos": "En el contextode la informática, un almacén de datos (del inglésdata warehouse) es una colección de datosorientada a un determinado ámbito (empresa,organización, etc.), integrado, no volátil y variableen el tiempo, que ayuda a la toma de decisionesen la entidad en la que se utiliza. Se trata, sobretodo, de un expediente completo de una organiza-ción, más allá de la información transaccional yoperacional, almacenado en una base de datosdiseñada para favorecer el análisis y la divulgacióneficiente de datos (especialmente OLAP, proce-samiento analítico en línea)". (Wikipedia en cas-tellano 24/6/2011: <http://es.wikipedia.org/wiki/Almac%C3%A9n_de_datos>).2 Un Data mart es una versión especial de almacénde datos (data warehouse). Son subconjuntos dedatos con el propósito de ayudar a que un áreaespecífica dentro del negocio pueda tomar mejo-res decisiones. Los datos existentes en estecontexto pueden ser agrupados, explorados ypropagados de múltiples formas para que diversosgrupos de usuarios realicen la explotación de losmismos de la forma más conveniente según susnecesidades. <http://es.wikipedia.org/wiki/Data_mart>.



1. IntroducciónEs complejo intentar desvelar, a través deunas líneas todo lo que puede incluir unmodelo de Data Warehouse1 (DW) e inclusollegar a un acuerdo en su significado y tipo deestructuración física.

En cualquier caso, a estas alturas de la ma-durez de Business Intelligence (BI) en Espa-ña, todos coincidimos en que el único pilarbásico para el desarrollo de soluciones denegocio es sin lugar a dudas el DW. Almace-namiento pensado, diseñado y construidopor y para unas necesidades agresivas deanálisis, análisis completamente impredeci-bles.

En España llevamos más de 16 años hablan-do de DW y de BI, aunque lamentablementetras las siglas DW se esconde un gran desco-nocido, obviando su objetivo, sus técnicas ysus posibles tipos de modelos. Desconocidoal haberse puesto de moda desde 1998 otros"tecnicismos" informáticos (CustomerIntelligence, BSC, CRM, etc.).

Las nuevas herramientas, más sofisticadas,han derivado erróneamente en profesionalesmás técnicos y con menos visión del negocio,obviando temas muy relacionados con losmodelos de datos de DW y su representaciónformal en un modelo especifico. En cualquiercaso, empecemos por el principio.

Los modelos de un Data Warehouse mantie-nen necesariamente una relación directa conlos tipos de almacenamiento que se determi-nen e incluso deben y pueden ser optimizadossegún decenas de criterios. Los cuales vandesde el tipo de consulta más demandado,optimización de acceso por claves e inclusotablas agregadas, hasta la optimización se-gún la herramienta de explotación utilizada.Por todo ello, no es sencillo establecer unúnico criterio o patrón de cara a la correctaconstrucción de un DW. El presente artículoúnicamente pretender sentar unas bases míni-mas para ayudar a la selección del almacena-miento más adecuado, así como algunosconsejos de cara a realizar un modelo de DWque permita un éxito en su iniciativa de BI, opor lo menos, adquirir algún conocimientopara poder comprender o entender a los con-sultores o responsables de desarrollarlo.

Además, es importante reflejar alguna ideaprevia sobre todo ello. Un buen sistema de BI

Modelos de construcciónde Data Warehouses

José María Arce ArgosGerente de Business Intelligence & CRM enOesía

< c h e m a . a r c e . a r g o s @ g m a i l . c o m >< c h e m a . a r c e . a r g o s @ g m a i l . c o m >< c h e m a . a r c e . a r g o s @ g m a i l . c o m >< c h e m a . a r c e . a r g o s @ g m a i l . c o m >< c h e m a . a r c e . a r g o s @ g m a i l . c o m >

Resumen: A través del presente artículo nos adentraremos en las técnicas, modelos y consejos másbásicos para crear valor en nuestras organizaciones. Todo ello de la mano del Data Warehouse y de susposibles modelos de implementación. El artículo profundiza, comparando algunos de los tipos demodelos posibles y sus consecuencias. Prestando especial atención en la necesidad de las empresas depoder medir, como única salida hacia el éxito empresarial.

Palabras clave: Datawarehouse, modelo en estrella, modelo E-R, modelos multidimensionales.

Autor

José María Arce Argos es Gerente de Business Intelligence & CRM en Oesía. Ha desarrollado su carreraprofesional en empresas tan importantes como Leinsa, IBM, Ernst & Young, SAS Institute, Bull España,Altran SDB e Inad. Cuenta con 22 años de experiencia en consultoría, de los cuales 16 años dedicadosal Business Intelligence. Redactor y colaborador en la revista "Gestión del Rendimiento", colaborador enTodoBI, profesor durante 10 años en el Máster de "Sistemas de Información e Investigación de Mercados"de la Business Marketing School (ESIC), ponente en diversos eventos en IIR, SAS, CUORE Oracle, Univ.de Zaragoza, etc. A lo largo de su trayectoria profesional ha diseñado, coordinado, participado o dirigidoiniciativas de BI en clientes como Publiespaña, British American Tobacco, Halifax, ONT, REE, Continente(Carrefour), Grupo Abengoa, ABN Anro Bank, B. Santander, Open Bank, Ing Direct, Dirección Gral. deEstadística (JCYL), TeleMadrid, Hospital San Cecilio de Granada, DFA, RED.ES, Egailan, INEM, INSS,Policía Municipal de Madrid, Canal de Isabel II, etc. Es autor del Blog BIB: <http://josemariaarce.blogspot.com/>.

requiere de un DW, de hecho casi todas lasiniciativas de BI tienen por debajo o se apoyanmayoritariamente en un DW, aunque no sediga e incluso se oculte. También es cierto quelas herramientas de explotación cada día sonmás poderosas e incluso permiten realizaragrupaciones, desgloses, etc., incluso contraun modelo, digamos cortésmente, poco evo-lucionado. Lo cual posiblemente denota unerror en el planteamiento, pues siempre serámejor que ciertos conceptos figuren en mo-delo que generados al vuelo por una herra-mienta, pues podríamos tener el mismoconcepto "N" veces y calculado de formasdiferentes. En el caso de producirse estasituación implicaría la muerte del sistemaBI, básicamente por la desconfianza sobrela calidad de los datos e incluso por posiblesresultados contradictorios. En este ejem-plo no está fallando el BI, está fallando eldiseño del modelo de DW.

Para acabar esta introducción, comentar queen decenas de clientes hemos escuchandoquejarse de importantes problemas de rendi-miento en sus DW, de la necesidad de ponermás maquina, cambiar de herramienta, meternuevas estructuras más optimizadas, etc. Enla mayoría de los casos los problemas no sesolucionan así. El 90% de los problemas delos sistemas de BI residen en un mal modelode datos (DW).

2. Almacenamientos y alternativasSin entrar en las características que debecumplir un DW, pues creo que ya está todoescrito, mencionar que el DW tiene comoúnica finalidad la capacidad de analizar lainformación de interés desde diversos puntosde vista, a lo largo del tiempo, entre otrasmuchas cosas. Ello obliga a que esté diseña-do y construido de una forma específica,siendo pues necesario cumplir con el términoOLAP (OnLine Analytical Process), en con-tra de los diseños tradicionales, los cualesahora los denominamos OLTP (OnLineTransaction Processing).

Años antes del DW ya se intentaron montareste tipo de sistemas, a base de duplicar elmundo operacional. El tiempo demostró quedicho camino no era el más efectivo y que teníaserias limitaciones, tomando fuerza la nece-sidad de que el DW esté diseñado con carac-terísticas OLAP.

Recordemos que los sistemas OLAP cum-plen con más de 50 posibilidades de "navega-ción" por la información, como rotar, bajar,profundizar, expandir, colapsar, etc. Todoesto y mucho más es simplemente imposibleen los sistemas tradicionales (OLTP), moti-vo extra para olvidarse de replicar sistemas,solución ya probada (años 70) y que no diolos resultados esperados.



monografía

Existen diversas alternativas para la arquitectu-ra de un DW. En cuanto a tipos de almacena-miento, mencionaremos las más habituales:

Solución MMMMMOLAP (MultidimensionalOLAP): Montar el almacenamiento bajo unabase de datos multidimensional propietaria(MDDB de SAS, ESSABE, etc.).

Solución RRRRROLAP (Relacional OLAP):Montar el almacenamiento bajo una base dedatos relacional (SQLServer, Oracle, DB2, etc.).

Soluciones HHHHHibridas, denominadasHOLAP. Las cuales combinan ambas alter-nativas en una única solución, interesante ysabia alternativa según las necesidades.

Debemos considerar que detrás de unas siglasse esconden unas claras diferencias tecnoló-gicas y unas ventajas e inconvenientes quedeben conocerse a priori. Las diferencias másllamativas o significativas las podemos cla-sificar en cuatro puntos:

Necesidades de procesamiento y tiem-Necesidades de procesamiento y tiem-Necesidades de procesamiento y tiem-Necesidades de procesamiento y tiem-Necesidades de procesamiento y tiem-po de respuestapo de respuestapo de respuestapo de respuestapo de respuesta: Como no existen solucio-nes ideales cada una ofrece diversas capacida-des: Mientras los modelos ROLAP debencalcular y buscar los datos al vuelo, lo cualconsume tiempo y retarda la respuesta, losmodelos MOLAP tienen todo precocinado ysus tiempos son mejores. Lógicamente lasnecesidades batch para crear los MOLAP sonclaramente superiores a los ROLAP. Tam-bién mencionar que los volúmenes de datosgestionados en ROLAP son muy, pero quemuy superiores a los MOLAP, a más datosmás tiempo. En algún cliente he intentadocrear MOLAP con importantes volúmenes ysimplemente fue imposible. Cada tecnologíavale para una cosa.

Gestión e incremento en las visionesGestión e incremento en las visionesGestión e incremento en las visionesGestión e incremento en las visionesGestión e incremento en las visionesde negociode negociode negociode negociode negocio: La visiones de negocio o dimen-siones, utilizando términos de BI, son casiinfinitos en el mundo ROLAP, pero no por elcontrario en el mundo MOLAP. Los mode-los MOLAP empiezan a flaquear en la fron-tera de las 10 dimensiones, pues al crear elMOLAP se deben de calcular todos los cruceso combinaciones posibles, por lo tanto ojo alnúmero de combinaciones usadas.

Necesidades cambiantes de agrupa-Necesidades cambiantes de agrupa-Necesidades cambiantes de agrupa-Necesidades cambiantes de agrupa-Necesidades cambiantes de agrupa-ciones o consolidacionesciones o consolidacionesciones o consolidacionesciones o consolidacionesciones o consolidaciones: En este casolos modelos ROLAP tienen una capacidadmás camaleónica, pues todo se calcula alvuelo, siendo más flexibles y potentes. Porcontra, los modelos MOLAP requieren deuna precocina en batch. En general, incluircualquier concepto olvidado en un DW esalgo laborioso, especialmente en función dedonde se deba incluir. Incluir una nueva mé-trica en una tabla de hechos (tabla fact)2 eslo más costoso, pues no vale solo con poner-la, será necesario recargar esa métrica y todosu historial asociado. Es casi mejor pecar porexceso, un olvido en una tabla de hechos sepaga muy caro.

Volúmenes y capacidadesVolúmenes y capacidadesVolúmenes y capacidadesVolúmenes y capacidadesVolúmenes y capacidades: Posiblementeel éxito de los modelos ROLAP viene especial-mente por esta capacidad. Son los únicos quepueden enfrentarse a volúmenes de Gb e inclu-so Teras de información, algo simplementeimposible en el mundo MOLAP. Lo cuallógicamente hace que sus respuestas no ofrez-can unos tiempos óptimos, pero en otrassoluciones simplemente no se pueden hacer.La arquitectura ROLAP es la clara vencedorapor capacidad y flexibilidad. Dejando el mun-do MOLAP a soluciones o necesidades muycontroladas, pequeñas, departamentales o,hablando en cristiano, de "andar por casa". Esnormal encontrarse con evoluciones en basea Data Marts3 , decisión muy extendida eincluso razonable años atrás. Especialmenteusadas en las primeras iniciativas de BI, puesresultan rápidas de desarrollar y nos permitenque en nuestras compañías, "los mayores",entiendan las capacidades y bondades de di-chos sistemas. Les gustarán mucho y obten-dremos financiación para continuar. Perodebemos ser conscientes de las limitacionesque tendremos a medio o largo plazo, puestendremos silos de información y limitadascapacidades de cruces, lo cual terminará obli-gando a desarrollar más y más Data Marts.

Posiblemente habremos salido de una pesa-dilla operacional para entrar en una pesadillainformacional, gracias a la proliferación deData Marts en nuestra organización.

La otra, o mejor dicho, la única alternativaeficaz, flexible y que siempre nos permitirá uncrecimiento y mantenimiento acorde a nues-tras necesidades, si hablamos de DW, enten-diéndolo como una solución integrada, con-solidada y de amplia cobertura empresarial(no me atrevo a decir corporativo, pero lopienso), es montar el DW bajo arquitecturaROLAP, como se ilustra la figura 1figura 1figura 1figura 1figura 1.

Bajo esta figura podemos ofrecer lo mejor deambos mundos. Dado la limitación física delos MOLAP, dejemos los cimientos del BIbajo ROLAP, y diseñemos estructurasMOLAP para accesos controlados, rápidosy eficaces a los departamentos o necesidades

especificas. Como ya hemos comentado, unasolución Hibrida (HOLAP) es una sabiasalida que ofrece lo mejor de cada arquitectu-ra.

Una vez tratado ligeramente el tema de losalmacenamientos posibles y considerandoque nos decantamos por su gestión bajo unmotor relacional, debemos considerar quelos modelos tradicionales no están pensadospara las necesidades que debe de soportar unDW. Lo cual requiere un diseño específico,como ya hemos comentado, el cual permitasu explotación OLAP. Tradicionalmente nosencontramos con dos tendencias: los mode-los en estrellas y los modelos copo de nieve.

3. Tipos de modelos en DWTal vez antes de entrar en faena, me gustaríacomentar que en definitiva hablamos de lomismo, pues de un modelo en estrella llego aun copo de nieve y viceversa, por lo tanto, nomerece la pena pegarse en qué es mejor (gue-rrilla promovida por los fabricantes, a media-dos de los 90, y sus intereses particulares),pues finalmente son más de lo mismo.

Aquellos que han sido alumnos míos durantemis 10 años siendo profesor en un Máster deprestigio sobre "Sistemas de Información eInvestigación de Mercados", bien lo saben y haquedado demostrado. Sin embargo existenimportantes limitaciones e incluso costesocultos, como los asociados a los manteni-mientos, a las mejoras, a la dificultad en losnuevos procesos, etc.

Con independencia de un tipo de modelo uotro, es conveniente quedarnos con algunasideas que nos van a permitir buscar la mejorsolución y evitar algunas trampas en el diseñode un DW. Con el ánimo de ser lo más claroposible evitaré usar tecnicismos. Entre lasmuchas coletillas adquiridas en estos años yrelacionadas con el DW os comentaría:

"Divide y vencerásDivide y vencerásDivide y vencerásDivide y vencerásDivide y vencerás""""": Se puede empezara diseñar un DW sin conocer al 100% lasnecesidades de toda la organización, desglosael gran proyecto por dominios de informacióny "ataca" uno a uno, sin perder la visión delgran sistema. Recuerda: "Piensa en grande,haz en pequeño". También aplicable al "dividey vencerás" a la forma de diseñar las dimensio-nes. Considerando la forma de acceso delusuario final y la "navegación" deseada, con-sidera que cuanto más "normalizado" se dise-ñe tendrás más flexibilidad y un mantenimien-to más sencillo que será más comprensiblepor los DBA más tradicionales.

"""""Diseñar cabezas de ciervoDiseñar cabezas de ciervoDiseñar cabezas de ciervoDiseñar cabezas de ciervoDiseñar cabezas de ciervo""""": Existentrampas en un DW como son las "trampas deabanico" y "trampas de abismo", las cualesexclusivamente ocurren bajo un modelo maldiseño. Un modelo simple, es como la cabezade un ciervo. La cabeza es la tabla que contie-ne los valores numéricos a analizar, las métri-cas o indicadores, la tabla Fact. Mientras los

Figura 1. Arquitectura ROLAP para DataWarehouse.



cuernos son sus dimensiones. Las dimensio-nes jamás se tocan o cruzan entre sí. El únicopunto en común que tienen son la cabeza delciervo. Los cuernos solamente tienen un pun-to de contacto con la cabeza… con este simpley claro ejemplo, nunca tendréis problemas

"""""Si metes basura, sacas basuraSi metes basura, sacas basuraSi metes basura, sacas basuraSi metes basura, sacas basuraSi metes basura, sacas basura""""":Expresión asociada a la importancia de losprocesos ETL (Extract, Transform and Load)para la carga de los datos, a sus controles decalidad del dato, etc. Todos los esfuerzos,todos los diseños y cualquier otra actividadno tendrá ningún valor, sin la credibilidad ycalidad de los datos.

"""""El exceso de análisis conduce a laEl exceso de análisis conduce a laEl exceso de análisis conduce a laEl exceso de análisis conduce a laEl exceso de análisis conduce a laparálisisparálisisparálisisparálisisparálisis""""": Es más que discutible como seabordan algunos proyectos de DW, especial-mente los grandes (corporativos). Como yahemos comentado se debe fragmentar pordominios e irlo abordando o desarrollandopor iteraciones, en caso contrario estamosmuertos, no ofreceremos resultados nunca ytendremos otro bonito fracaso.

4. ¿Qué tipo de modelo diseño?Como hemos comentado, aunque ambosmodelos pueden derivar el uno en el otro, enfunción de aplicar técnicas de normalizacióno desnormalización, el resultado final sí tienesu importancia. Hoy por hoy casi todas lasherramientas de explotación pueden "atacar" acualquier modelo, pero solamente algunas soncapaces de aprovechar al máximo las capacida-des de los modelos copo de nieve, en general,todas se mueven por el mundo de las estrellas.

Tradicionalmente los fabricantes de herra-mientas, basadas en modelos estrellas, hansido especialmente críticos con su competen-cia, pues se posicionaba con otro tipo demodelo. Ello provocó y todavía se nota,mensajes muy erróneos lanzados al mercado.Del mismo modo, actualmente nos quierenvender ideas como: hacer un DW en 10 minu-tos, todo ello sin técnicos, o de la vital impor-tancia de disponer de análisis en un iPad, etc.,cuando la mayoría de los sistemas funcionanpor los pelos y no son adecuadamente explo-tados. En general, las necesidades de losusuarios finales no están alineadas con lasestrategias comerciales de algunos fabrican-tes, mal que les pese.

En función de sus necesidades, conocimien-tos, herramientas y estrategias pueden optarpor un tipo de modelo u otro. La figura 2figura 2figura 2figura 2figura 2

visualiza un modelo en estrella, en el centro latabla de hechos donde se encuentran losindicadores numéricos a analizar, a su alrede-dor una tabla por dimensión o visión delnegocio. Dentro de cada una se encuentrantodos los conceptos asociados a dicha di-mensión.

No soy enemigo de los modelos en estrella,pues mi maestro y casi padrino en BI fueRalph Kimball. También es cierto que poraquellos años, aquella forma de diseñar fueuna revolución en sí misma y tampoco habíamuchas más alternativas.

Puntualizar que en un proyecto de BI, noexiste una sola estrella, de hecho, algunoshablan de constelaciones… En una base dedatos de DW, podríamos encontrar decenasde tablas fact y sus dimensiones asociadas,comunes y no comunes entre diversas tablasfact. Pues en caso contrario, si piensan quecon una estrella lo tienen todo resuelto, per-mítanme dos comentarios:

No malgaste su tiempo y dinero, puesalgo no he sabido explicarle o para usted unfichero texto ya sirve para tomar decisiones.

Hágalo usted mismo, con una tabla diná-mica de Excel.

Queda claro que de cara a intentar explicartemas de modelos, nos apoyamos con laexpresión mínima (una sola tabla de hechosy sus dimensiones), las cual son ilustradas enlas figuras, pero la realidad no es tan simple.La otra opción es el modelo copo de nieve, elcual tiene más o menos la apariencia quemuestra la figura 3figura 3figura 3figura 3figura 3.

Los defensores de los modelos en estrella,modelos completamente desnormalizados,han basado su defensa en algunas afirmacio-nes que vamos a repasar, aunque el tiempo hademostrado que "no es oro todo lo quereluce":

Fácilmente entendible, consultas senci-llas (por usar pocas tablas). Lo comparto,pues casi cualquiera puede entender a simplevista este modelo, digamos que no asusta alverlo. Supongo que su expansión se encuen-tra relacionada con su relativa sencillez aldiseñarlo, pues deja todo el "marrón" a laherramienta, sobre la cual se debe definir lalógica de navegación. Como ya he indicado loconsidero un error potencialmente alto. Lasestrellas simples sobre BBDD relacionalesson lo más parecido conceptualmente a lasBBDD multidimensionales, a los castigadoscubos, e incluso a las tablas dinámicas delExcel, etc. Supongo que por ello, algunosdefienden el Excel como una herramienta deBI, sin más comentarios.

Son más rápidos (por usar pocas tablas,pocos joins). Directamente, es una verdad amedias. Solamente podría ser así con pocovolumen de información. Además, las políti-cas de claves, bajo este tipo de estructuras, nofavorecen las búsquedas, aparte de ser franca-mente difícil planificar a priori la clave o clavesmás adecuadas, pues nunca podemos saberpor dónde nos vendrá la consulta.

Otro problema más serio, y que solamentepor ello debería hacernos replanteardebería hacernos replanteardebería hacernos replanteardebería hacernos replanteardebería hacernos replanteartoda la solucióntoda la solucióntoda la solucióntoda la solucióntoda la solución, es que no es posibleimplementar integridad referencial. Por ellonuestro gestor nunca será capaz de garantizar

Figura 2. Modelo en estrella para un Data Warehouse.



monografía

la consistencia y la calidad del dato. Obligan-do a desarrollar unos procesos ETL muyestudiados y minuciosos.

En resumen, por ahorrar tiempo en el análisis,en el diseño y no complicarse la vida, algunasveces "te entregan unas estrellitas muy mo-nas". Nadie te explicará y te pondrá sobreaviso de que:

Ese tipo de diseño puede implicar perdercalidad y consistencia en los datos, pues nopuedes definir integridad referencial entre cam-pos de una misma tabla.

Ello ocasiona pasar el control de la con-sistencia a los procesos ETL, lo cual implicaun esfuerzo extra y un coste elevado.

Dicha forma de diseñar delega la lógica dela navegación a la herramienta final y no estáimplícita en el modelo, esto es igual a proble-mas tarde o temprano.

Dificultad para determinar índices paramejorar respuesta.

Relaciones padres e hijos no identificados.La velocidad que supuestamente gana-

mos por no hacer joins por diversas tablas, lapodemos perder por el gran volumen de ladimensión (en única tabla) y por la posibleausencia de índices adecuados, etc.

Creo que ello, unido a otros puntos difíciles deexplicar sobre papel nos debería por lo menoscuestionar qué modelo establecer y avisarnossobre todo lo que leemos por Internet. Lo mássensato: Haga una prueba con el escenario másparecido posible a la realidad, también respectoal volumen de información.

5. ConclusiónLos negocios están cambiando constante-

Figura 3. Modelo copo de nieve para un Data Warehouse.

mente debido a cambios económicos, evo-luciones tecnológicas, alteraciones en elmercado, impactados por diversos cam-bios culturales y sociales e incluso porfenómenos meteorológicos.

Todo ello obliga a replantearse las estrate-gias actuales y debería provocar una trans-formación en nuestro propio negocio. Así,un factor clave de éxito, e incluso de super-vivencia, viene derivado de la capacidad delas organizaciones de gestionar de formaeficiente sus datos, y transformarlos eninformación útil y disponible para acertaren las decisiones. Esto y solo esto, es Bu-siness Intelligence.

Business IntelligenceBusiness IntelligenceBusiness IntelligenceBusiness IntelligenceBusiness Intelligence no es tecnolo- no es tecnolo- no es tecnolo- no es tecnolo- no es tecnolo-gía, es negocio y es estrategiagía, es negocio y es estrategiagía, es negocio y es estrategiagía, es negocio y es estrategiagía, es negocio y es estrategia. BIimplica muchas cosas, pasando por la voca-voca-voca-voca-voca-ción de medir para actuar en conse-ción de medir para actuar en conse-ción de medir para actuar en conse-ción de medir para actuar en conse-ción de medir para actuar en conse-cuencia, cuencia, cuencia, cuencia, cuencia, gran problema pendiente en lasorganizaciones.

Actuar no es hacer un informe. Es la capa-cidad de controlar y gestionar las organiza-ciones, basada en datos e informacionesveraces y no en hipótesis. Es la capacidad dealinear la estrategia con las operaciones, esla capacidad de orientarse realmente haciael cliente, es la capacidad de entender, escomprender y transmitir los objetivos em-presariales y su desempeño, es la capacidadde crear consenso en la organización, deri-vando todo ello en un cambio culturalcambio culturalcambio culturalcambio culturalcambio cultural.

En caso contrario, nos quedaremos conunas decenas de informes, tras unas inver-siones muy importantes.

B IB IB IB IB I=====

Cambio CulturalCambio CulturalCambio CulturalCambio CulturalCambio Cultural=====

Capacidad + agilidad + decisionesCapacidad + agilidad + decisionesCapacidad + agilidad + decisionesCapacidad + agilidad + decisionesCapacidad + agilidad + decisiones

Es necesaria la redefinición de las competen-cias del BI dentro de las organizaciones. Puessiendo equipos de vital importancia y estraté-gicos, tan importantes o más que departa-mentos de marketing, financieros, recursoshumanos, etc. suelen brillar por su ausencia.Delegando sus competencias en un equipotécnico más o menos formado pero con unavisión alejada del verdadero sentido del BI.No podemos montar un cambio culturaldonde no existe estrategia, aquellas empresasque han dado el salto y tiene una infraestruc-tura real, tanto en recursos humanos comomateriales, se están posicionando. Ustedesdeciden…

Para terminar les dejo una frase que leí porInternet, la cual tomo prestada (gracias a suautor, aunque no recuerde quien fue): """""En lanueva económica, el grande ya no devorará alchico, sino el ágil le ganará al lento".".".".".

Bienvenido al apasionante mundo de los ne-gocios, bienvenido a Business Intelligence.

Bibliografía

Ralph Kimball. The data warehouse toolkit:Practical techniques for building dimensional datawarehouse, 1996.Bill Inmon. Building the Data Warehouse. 1stEdition. Wiley and Sons, 1992.

1 Un Data Warehouse (DW) es una base de datosusada para generación de informes. Los datos soncargados desde los sistemas operacionales parasu consulta. Pueden pasar a través de un almacénde datos operacional para operaciones adicionalesantes de que sean usados en el DW para lageneración de informes (Traducción libre de laintroducción al concepto que se encuentra en laWikipedia en inglés el 24/6/2011: <http://en.wikipedia.org/wiki/Data_warehouse>).2 En las bases de datos, y más concretamente enun data warehouse, una tabla de hechos (o tablafact) es la tabla central de un esquema dimensio-nal (en estrella o en copo de nieve) y contiene losvalores de las medidas de negocio. <http://es.wikipedia.org/wiki/Tabla_de_hechos>3 Un Data mart es una versión especial de almacénde datos (data warehouse). Son subconjuntos dedatos con el propósito de ayudar a que un áreaespecífica dentro del negocio pueda tomar mejo-res decisiones. Los datos existentes en estecontexto pueden ser agrupados, explorados ypropagados de múltiples formas para que diversosgrupos de usuarios realicen la explotación de losmismos de la forma más conveniente según susnecesidades. <http://es.wikipedia.org/wiki/Data_mart>.

Notas



1. IntroducciónLlegar a obtener el valor real de los datos noes tarea sencilla. Recogemos y almacenamosdatos provenientes de múltiples canales que amenudo se encuentran almacenados en dife-rentes sistemas de información y bases dedatos sobre entornos tecnológicos y formatosheterogéneos. Aunque tengamos acceso di-recto a los datos, es difícil disponer de ellosdónde, cuándo y cómo los necesitamos, peroademás los datos suelen estar "sucios", esdecir, repletos de errores, omisiones e incohe-rencias.

Esta problemática es lo suficientemente im-portante como para hacer fracasar cualquierproyecto TIC (Tecnologías de la Informa-ción y de la Comunicación), iniciativa empre-sarial estratégica o incluso toda una compa-ñía. La capa de datos de una organización esun componente crítico, sobre el que a menudoes fácil hacer suposiciones demasiado opti-mistas sobre su situación o bien ignorar lacalidad real de los datos.

Por una parte existen datos que sólo se utili-zan en un entorno tecnológico restringidopara un proceso o una aplicación con impac-to limitado, y por otra existen una serie dedatos cuya importancia es fundamental por-que definen las identidades más importantes(clientes, productos, empleados, proveedo-res…), y que deben ser compartidos pormúltiples procesos, departamentos y líneasde negocio. Estos datos (los llamados "datosmaestros") deben ser tratados como un acti-vo estratégico.

Garantizar la calidad, integridad y exactitudde los datos es uno de nuestros principalesretos. Obtener la visión única de los datos demanera transversal a través de los departa-mentos de una empresa, las distintas líneas denegocio o las distintas compañías de ungrupo, es un factor crítico para facilitar laconsecución de los objetivos de negocio.

Tener como objetivo unos datos de calidad esuna filosofía que alinea la estrategia, la cul-tura empresarial, y la tecnología con el fin degestionar los datos en beneficio propio. Enpocas palabras, se trata de una auténticaestrategia competitiva, cada empresa tiene laoportunidad de diferenciarse mediante la ca-lidad de sus datos.

¿Pero hasta qué punto afectan los datos

Data Governance:¿qué?, ¿cómo?, ¿por qué?

Óscar Alonso LlombartAnalysis Manager, Penteo

< o . a l o n s o @ p e n t e o . c o m >< o . a l o n s o @ p e n t e o . c o m >< o . a l o n s o @ p e n t e o . c o m >< o . a l o n s o @ p e n t e o . c o m >< o . a l o n s o @ p e n t e o . c o m >

Resumen: La toma de decisiones está basada en la información que obtenemos de los datos empresa-riales. Toda toma de decisiones implica aceptar un riesgo, pero lo cierto es que no siempre es fácildisponer de datos rigurosos… Ante esta situación, ¿cómo podemos alcanzar el auténtico valor de losdatos y ofrecer una visión consistente del rendimiento empresarial?, ¿cómo conseguir un adecuadoanálisis de la información teniendo en cuenta los cambios constantes que ocurren en nuestras organiza-ciones?

Palabras clave: Calidad de datos, Data Governance, data stewardship, gestión de los datos, gobierno delos datos, propiedad de los datos.

Autor

Óscar Alonso Llombart es Ingeniero en Informática de Gestión por la Universidad Autónoma de Barce-lona, Master en Ingeniería del Software por la Universidad Politécnica de Cataluña y Postgrado en DataMining por la Universitat Oberta de Catalunya. Trabaja como Analysis Manager en Penteo. Cuenta conmás de 15 años de experiencia en el ámbito de consultoría tecnológica en áreas como BusinessIntelligence, Datawarehousing, Corporate Performance Management, desarrollos a medida e implanta-ción de metodologías de desarrollo. Es autor de numerosos artículos y estudios sobre la aplicación de lossistemas de inteligencia de negocio a las estrategias empresariales. Twitter: <@oalonsollombart>;Linkedin: <http://www.linkedin.com/in/oscaralonsollombart>.

erróneos a nuestro negocio? Debido a lanaturaleza dinámica de los datos, que típica-mente se generan mediante numerosos proce-sos de negocio y fuentes de información queson combinadas, almacenadas y utilizadas envarios sistemas, es un importante reto esta-blecer métodos para evaluar el impacto de losdatos de poca calidad.

La mala calidad de los datos tiene un costeeconómico real, la eficiencia en los procesosse ve afectada debido a la escasez de datos decalidad, y no se alcanzan los beneficios poten-ciales de los sistemas tanto de los existentescomo de nuevos proyectos.

De las investigaciones realizadas por Penteose desprende que todavía existe un importantegap para conseguir una verdadera inteligenciade negocio. Si bien son muchas las compañíasque han implantando sistemas de inteligenciade negocio en un porcentaje relevante, lo hanhecho con proyectos aislados, dando res-puesta a necesidades muy específicas. En lagran mayoría de las compañías las dificulta-des para encontrar y explotar adecuadamentedatos e información respecto el estado yevolución del propio negocio son un denomi-nador común (ver figura 1figura 1figura 1figura 1figura 1). Esta situaciónimpacta invariablemente en el negocio entérminos de aspectos económicos, confianzasobre los datos, cumplimiento de regulacio-nes, satisfacción y productividad.

2. La gestión de los datosLos procesos de negocio se basan fuertemen-te en los sistemas de información, sistemasque interactúan entre ellos, que comparten lainformación y que deben ser capaces de comu-nicarse para poder prestar un servicio adecua-do y eficiente a la organización. Además setoman decisiones estratégicas basadas en lainformación extraída de los sistemas, y he-mos de disponer de información fiable para labuena gestión corporativa.

En esta situación hemos de ser conscientesque somos dependientes de la calidad de losdatos que tenemos en nuestra organización.Los datos como entidad por sí misma noaportan valor añadido al negocio y las solu-ciones de inteligencia empresarial no son nadasi no disponemos de datos fiables. Sonaquellas compañías que han gestionado ade-cuadamente la calidad de los datos las quehan evitado los problemas derivados de latoma de decisiones basada en informaciónerrónea.

La gestión de los datos es la primera piezasobre la que sustentar una adecuada explota-ción de la información (ver figura 2figura 2figura 2figura 2figura 2), con-siderando los datos y posterior informacióninferida a partir de ellos como activos empre-sariales valiosos. Los datos y la informaciónhan de ser gestionados de manera cuidadosa,como cualquier otro activo, asegurando la



monografía

Figura 1. ¿Cuáles son los principales problemas en la toma de decisiones? Fuente: Penteo.

calidad, seguridad, integridad, disponibilidady uso efectivo.

Los objetivos de la gestión de los datos son:Comprender las necesidades de informa-

ción de la organización.Capturar, almacenar, proteger y asegurar

la integridad de los activos de los datos.Mejorar de manera continua la calidad de

los datos y de la información incluyendo laexactitud, integridad, integración, relevanciay utilidad de los datos.

Asegurar la privacidad y la confidencialidad,y prevenir el uso no autorizado e inapropiadode los datos y la información.

Maximizar el uso efectivo y el valor de losactivos de los datos y la información.

Controlar (y conocer) el coste de la ges-tión de los datos.

Promocionar un uso y un conocimientomás amplio y profundo del valor de los acti-vos de los datos.

Gestionar la información de manera con-sistente a lo largo y ancho de la organización.

Alinear la gestión de los datos y la tecno-logía necesaria con las necesidades del nego-cio.

La gestión de los datos debe ser vista comouna función de negocio, únicamente compar-tiendo la responsabilidad de la gestión de losdatos entre los usuarios propietarios de losdatos y el departamento TIC llegaremos aobtener una auténtica ventaja competitivamediante el adecuado uso de la información.

3. Data Governance (la tecnologíapor sí sola no puede resolver elproblema)Data Governance…1 ¿qué es?, ¿por qué esimportante?, ¿cuál es la relación entre gobier-no y propiedad de los datos?, ¿incluye elconcepto de gestión de los datos el gobiernode los datos?, ¿sabemos en qué costes estáincurriendo nuestra organización por tenerdatos duplicados o por no disponer de defini-ciones estándares de datos comunes? … Si nosomos capaces de contestar a estas cuestio-nes, quizás debamos plantearnos una estra-tegia para hacer frente a la necesidad de com-prender y utilizar los datos de manera másefectiva y eficiente.

Para alcanzar este objetivo las compañías hande implantar proyectos de Data Governance,

un conjunto de políticas y procedimientosque combinados establecen los procesos quesupervisan el uso y gestión de los datos paratransformarlos en un activo estratégico, conel objetivo de llevar a nuestra compañía a unnivel superior de "madurez en el uso de lainformación", mejorar la calidad de los datosy solucionar los posibles inconsistencias,gestionar el cambio en relación con el uso delos datos, y cumplir con regulaciones yestándares internos y externos.

Data Governance es la piedra angular sobre laque sustentar todas las prácticas relaciona-das con la gestión de los datos, que interactúae influencia con todas y cada una del resto deestas, como son los proyectos de calidad delos datos, integración de datos odatawarehousing2 . El gobierno de los datoses el ejercicio de autoridad y control (planifi-cación, monitorización y ejecución) sobre lagestión de los activos de datos, no gobiernalos datos directamente sino que gobiernacómo los usuarios acceden a los datos através de la tecnología.

El programa de Data Governance guía cómohan de actuar el resto de funciones de gestiónde los datos, estableciendo los propietarios delos datos, tanto a nivel ejecutivo como ope-rativo. Además ha de balancear adecuada-mente objetivos contrapuestos como son elcumplimiento de regulaciones, que limitan elacceso a los datos, y los procesos de integra-ción del negocio que amplían el acceso aestos. Las tareas que un programa de DataGovernance ha de llevar a cabo son:

Guiar a los gestores de la información enla toma de decisiones.

Asegurar que la información se define demanera consistente y es comprendida portodos los actores implicados.

Incrementar el uso y confianza de losdatos como un activo de gran valor.

Mejorar la consistencia de los proyectosa lo largo y ancho de la organización.

Asegurar el cumplimiento de regulacio-nes internas y externas.Figura 2. La gestión de los datos y la información. Fuente: Penteo



Eliminar posibles riesgos asociados aluso de los datos.

Los proyectos de implantación de programasde Data Governance son tan únicos como lascompañías que los implantan. Sin embargo,los marcos estructurales que se han utilizadoson en realidad bastante similares entre ellos.Existen componentes fundacionales comu-nes sobre los que construir la iniciativa:

Organización, estructura de recursosresponsables de desplegar las capacidades degobierno y administración de las actividades.

Políticas, principios y estándares, guíaspara la gestión de la información, y principiospara asegurar los estándares de datos y losprocedimientos de gobierno.

Procesos y prácticas, que establecen losprincipios que guían cómo las políticas yprocesos son creados, modificados e implan-tados.

Métricas, medidas para monitorizar elrendimiento de la iniciativa de gobierno yacciones para mejorar de manera continúa lacalidad de los datos.

Arquitectura de los datos, incluyendoestándares corporativos de los datos, diccio-narios de metadatos, y además medidas deseguridad y privacidad.

Herramientas y tecnología, las tareas de-ben ser automatizadas con el uso de softwaresiempre que sea posible, mediante herramien-tas de calidad de datos, data profiling,3 herra-mientas de gestión de metadatos,dashboards4 , etc.

4. Organización de un equipo deData GovernanceNos encontramos ante una iniciativa que nodebe ser contemplada como un proyecto TIC,sino como un proceso continuo de cambio de

la cultura empresarial. Es negocio quien debeliderar la iniciativa, la implantación de DataGovernance es un importante cambio dementalidad que debe transcender a todas lasáreas de la compañía.

La responsabilidad compartida es el sello distin-tivo del gobierno de datos ya que requiere detrabajo a través de fronteras organizativas y desistemas, algunas decisiones son principalmen-te de negocio con aportaciones y guías deldepartamento de TIC, mientras que otras sondecisiones técnicas con aportaciones y guíaspor parte de los usuarios a diferentes niveles.

Las distintas unidades del negocio se erigen enlas "propietarias" de los datos, mientras queel departamento TIC proporciona la estruc-tura y los procesos necesarios. Estos propie-tarios de los datos son expertos en determina-das áreas temáticas, se erigen en representan-tes de los intereses empresariales respecto alos datos y toman la responsabilidad acercade la calidad y uso de estos.

Si con anterioridad a la implantación de lainiciativa de gobierno de datos, han existidoproyectos de Business Intelligence, es muyposible que exista algún tipo de equipo deData Governance. Éste, si bien tendrá uncarácter informal, permitirá mitigar los cos-tes y cambios organizativos que suelen reque-rir este tipo de iniciativas, y seguramente nospermitirá disponer de personas que puedanocupar los perfiles que se precisan.

El personal que forme parte del equipo deData Governance debe saber cómo utilizar yanalizar la información para facilitar la tomade decisiones disponiendo de una mezcla dehabilidades técnicas, analíticas y de negocio:

Conocer el negocio, sus procesos, lascapacidades analíticas de los sistemas, y laestrategia de la compañía para poder estable-cer un plan director de gobierno de datos.

Conocer la organización y canalizar lacultura en el acceso a la información.

Mantenerse al corriente de las nuevas ca-pacidades que la tecnología pueda aportarlea la organización.

Uno de los problemas históricos en los pro-yectos de implantación de iniciativas de DataGovernance es la ausencia de un adecuadoseguimiento; mientras que algunas organiza-ciones han definido correctamente políticas yprocesos de gobiernos, en muchas ocasionesno se ha establecido la estructura organizativanecesaria para hacerlas funcionar adecuada-mente.

El marco organizativo del programa de go-bierno de los datos debe dar soporte a lasnecesidades de todos los participantes a lolargo y ancho de la compañía. Con el adecua-do soporte ejecutivo, el programa de DataGovernance se beneficiará de la participaciónde la empresa en las diferentes funcionesnecesarias, tanto tácticas como son las de losequipos de coordinación de datos y los pro-pietarios de los datos, como estratégicas.

Los roles específicos incluyen (ver figura 3figura 3figura 3figura 3figura 3):Director de Data Governance, responsa-

ble principal de gestionar la iniciativa y asegu-rar la máxima adopción en la organización.Este perfil da soporte a los patrocinadoresejecutivos y ofrece informes periódicos derendimiento del proyecto, además de negociarcon proveedores externos de datos los acuer-dos de niveles de servicio asociados.

Comité de Data Governance, comité es-

Figura 3. Diagrama organizativo del equipo de Data Governance. Fuente: Penteo.



monografía

tratégico multifuncional típicamente com-puesto por el patrocinador ejecutivo, el direc-tor de la oficina de Data Governance, y por elCIO (Chief Information Officer, el lider oresponsable de las Tecnologías de la Infor-mación ) de la compañía. De manera ideal elpatrocinio ejecutivo debería proceder de ne-gocio y no del departamento TIC. Este comi-té revisa y aprueba los procesos, políticas yprocedimientos, gestionando las prioridadesy evaluando su adecuada consecución.

Equipo de coordinación de datos, equipotáctico que asegura que la calidad de datoscumple las expectativas de los clientes y ges-tiona la iniciativa entre las diferentes unidadesde negocio. Es responsabilidad de este equipodetectar y comunicar oportunidades al Co-mité de Data Governance.

Los propietarios de los datos, que gestio-nan el ciclo de vida de los datos y dan soportea la comunidad de usuarios. Estos propieta-rios definen los criterios de calidad de losdatos para cumplir las expectativas de lasunidades de negocio, y reportan las activida-des y problemas al equipo de coordinación delos datos.

5. La necesidad de establecer lapropiedad de los datosUno de los factores clave de éxito enimplantaciones de iniciativas de DataGovernance es el rol de data stewardship o"propiedad de los datos". La propiedad de losdatos es la formalización de las responsabi-lidades que garantizan un control y un usoefectivo de los activos de los datos.

Los propietarios de los datos son usuarios denegocio, expertos en determinadas áreas te-máticas designados como responsables paragestionar los datos en nombre de los demásusuarios. Estos representan los intereses detodas las partes involucradas, incluyendo perono limitándose, a los intereses de sus propiasáreas funcionales y departamentos protegien-do, administrando y reaprovechando los re-cursos de datos.

Estos perfiles deben tener una perspectiva denegocio para garantizar la calidad y el usoeficaz de los datos de la organización. Elproceso de gobierno de los datos involucraráa los propietarios como participantes, peroademás estos serán directamente responsa-bles del éxito de la gestión de los datos en susdominios.

En la práctica no existe un modelo "bala de plata"que encaje para todas las organizaciones. Bási-camente existen cinco modelos de propiedad delos datos que las organizaciones pueden aplicar,siendo cada uno de estos modelos único, consus propios pros y contras:

Modelo 1: propiedad por áreas temáticas.En este modelo cada propietario de los datosgestiona un área temática determinada, asípues el responsable de los datos de los clientes

es diferente del responsable de los datos deproductos, etc. En entornos grandes o com-plejos, puede existir más de un propietariopara cada área temática. Este modelo funcio-na bien en compañías con múltiples departa-mentos que compartan los mismos datos.

Modelo 2: propiedad por funciones denegocio. En este caso el propietario de losdatos se centra en los datos que un departa-mento o línea de negocio utiliza, como pue-den ser los datos relacionados con marketing,finanzas, ventas, etc. Dependiendo del tama-ño de la organización y complejidad en laadministración de los datos puede ser queexistan otros propietarios de datos por áreastemáticas, resultando un modelo híbrido conel anterior.

Modelo 3: propiedad por procesos denegocio. Para cada proceso de negocio seasigna un responsable de los datos, en estecaso los propietarios de los datos son respon-sables sobre múltiples dominios de los datoso aplicaciones que participan sobre un deter-minado proceso de negocio. Nos encontra-mos ante un modelo muy efectivo para com-pañías con una orientación y una definiciónmuy clara de sus procesos de negocio, enorganizaciones en las que no existe una cul-tura de procesos o es inmadura este acerca-miento no es la mejor elección.

Modelo 4: propiedad por sistemas TIC.Los responsables de los datos son asignadosa las aplicaciones que generan los datos queutilizan. Este modelo es una manera de evan-gelizar el concepto de propiedad de los datosdesde el departamento TIC a las distintasunidades de negocio. Los propietarios de losdatos pueden comunicar el progreso de lainiciativa y mostrar como los datos no única-mente van mejorando a lo largo del tiempo,sino que además van afectando a los resulta-dos del negocio.

Modelo 5: propiedad por proyectos. Elasociar el concepto de propiedad de los datosa proyectos es una manera rápida y prácticade introducir la cultura de administración delos datos en la organización. De maneracontraria al resto de modelos comentadosanteriormente ésta es una medida temporal,que suele utilizarse como punto de partidapara el establecimiento de otro modelo for-mal a largo plazo.

El decidir el modelo de propiedad de datosideal para nuestra organización no es unatarea trivial en la que debemos plantearnosuna serie de factores tales como:

Los perfiles y habilidades disponibles en laorganización para la gestión de los datos.

La cultura de la compañía.La reputación de la calidad de los datos.La situación actual respecto a la propie-

dad de los datos.El uso actual de métricas asociadas a la

calidad de los datos.Las necesidades de reutilización de los

datos.

6. ¿Cómo abordar el proyecto deData Governance?Una implantación adecuada de DataGovernance puede llegar a tener un impactodirecto muy positivo en el rendimiento empre-sarial. No obstante, es un auténtico retoalcanzar la combinación idónea de personas,procesos y tecnologías para diseñar una ini-ciativa exitosa.

Para superar este reto debemos construir unaestrategia de gobierno de datos efectiva, diri-gida por los objetivos de negocio, dotando alos interesados con mejores capacidades parala toma de decisiones y ayudando a la com-pañía a alcanzar sus objetivos deseados. Unaestrategia efectiva debe asegurar que los ob-jetivos de la compañía, la estrategia del nego-cio, la inversión y los sistemas de DataGovernance están alineados.

Una iniciativa de Data Governance no es nadasi no está conducida por los objetivos de lacompañía. Los requerimientos del negocio ylos objetivos empresariales deben conducirlas iteraciones del proyecto. Necesitamos elestablecimiento de una estrategia antes deincluir a la tecnología en el proceso.

Incluso antes de empezar a trabajar con laestrategia de gobierno de datos, debemoscomprender y documentar los objetivos gene-rales para ayudar a formular la visión y misióndel gobierno de los datos para el crecimientodel negocio. Después de documentar la listainicial de objetivos se debe trabajar con losprincipales implicados para confirmar la va-lidez de la lista de objetivos y su correctapriorización. Esto asegurará que empeza-mos a construir nuestra estrategia de DataGovernance con una base adecuada alineadacon el negocio y con los usuarios.

Del análisis del mercado y de las mejoresprácticas extraídas de experiencias reales deadopción de Data Governance, se extraen lassiguientes recomendaciones:

Involucrar a unidades de negocio para quelideren la iniciativa. Porque Data Governanceno es únicamente una tecnología sino ade-más un importante cambio de mentalidadque debe trascender a todas las áreas de lacompañía. La gestión del cambio y la comu-nicación desde el inicio del proyecto en estetipo de iniciativas resulta esencial para asegu-rar el éxito. El proyecto debe ser abordadodesde la componente de organización y pro-cesos, aunque tutelado desde cerca por eldepartamento TIC. La existencia histórica dela función de organización se perfila como unclaro facilitador de la adopción de la iniciati-va.

Vender internamente el proceso. Lasimplantaciones de Data Governance suponenun impacto importante en la organización enmuchos sentidos, por lo que los CIOs de lascompañías deben iniciar sus proyectos de



Data Governance cuando han llegado a unconsenso en la decisión con otros cargosdirectivos implicados en el proceso y cuandohan conseguido vender internamente el pro-yecto. De esta forma, la implicación en elproyecto de las distintas áreas de negocioqueda plenamente asegurada de antemano ypor lo tanto el riesgo al abordar el proceso esmucho más controlado.

La adopción de Data Governance no sedebe abordar como un proyecto finito. Elcambio de mentalidad y de cultura, y lareorientación de la compañía a la calidad dela información son los indicadores que iden-tifican el éxito de una iniciativa, por lo que noes usual abordarlo como un proyecto TICtípico.

Gestionar un portafolio de proveedoresestratégicos. La situación del mercado nosobliga a evaluar, monitorizar y gestionar elecosistema de nuestras aplicaciones y la hojade ruta del portafolio de soluciones de losproveedores para estandarizar y reducir elriesgo, la redundancia y los costes. La selec-ción de herramientas tiene menos que ver conlas funcionalidades y más con el hecho que lasherramientas seleccionadas puedan cumplirlos requerimientos específicos de negocio.

Planificar y diseñar antes de implantar.Nos encontramos ante una iniciativa de com-plejidad importante por lo que debemos to-marnos nuestro tiempo para definir exacta-mente las bases de nuestro futuro sistemaorientado a servicios. Debemos esbozar losplanos de cómo serán nuestros sistemas deinformación objetivo y avanzar de formagradual y progresiva en su consecución.

Finalmente, es importante destacar que unaestrategia de Data Governance debe diseñarsepara ser ágil y adaptativa. Ha de ser tratadacomo un ente vivo que evoluciona constante-mente para alcanzar los objetivos empresa-riales. La estrategia debe focalizarse en co-municar qué estamos planificando implan-tar, cómo lo vamos a implantar y cuándo losusuarios verán reflejados sus requerimientosen el sistema. Empecemos con políticas yguías generales y con diagramas de alto nivel,a medida que el ecosistema madura en para-lelo lo hará la documentación formal y el nivelde detalles identificados en la estrategia. Hade ser nuestra intención evolucionar la estra-tegia de gobierno de datos como parte inte-grante de la visión de la compañía a medidaque realizamos iteraciones y obtenemos másy más detalles al respecto. Planifiquemospara evaluar y reinventar continuamente amedida que las necesidades del negocio cam-bian, teniendo en cuenta las tendencias tecno-lógicas actuales y futuras para construir unaestrategia de gobierno de datos exitosa.

7. ConclusionesLos activos tangibles de las organizacionestienen valor y son gestionados mediante sis-temas de información y procesos empresaria-

les. Los datos, precisamente por su naturale-za intangible, no son percibidos en muchasocasiones como activos estratégicos. No obs-tante, los datos de calidad, precisos y dispo-nibles son un prerrequisito para que las ope-raciones de cualquier organización sean efec-tivas.

Las compañías que son capaces de reconocerel valor real de los datos, es decir, que hanestablecido procesos, políticas y procedimien-tos de calidad de datos, que son conscientesde cuáles son los datos realmente importan-tes o útiles para su negocio y, que en defini-tiva, confían en la calidad de sus datos, setransforman en "organizaciones basadas enlos datos". Estas organizaciones se sitúan enuna clara situación de ventaja respecto a sucompetencia gestionando los datos como unactivo estratégico más, pero para alcanzaresta meta es necesaria una adecuada visiónestratégica para mejorar la calidad de la infor-mación.

La implantación de un proyecto de DataGovernance requiere del soporte de todas lasáreas del negocio implicadas. Tomando elcontrol de los datos podemos retener mejora nuestros clientes, aumentar el éxito de estra-tegias de marketing, controlar mejor los ries-gos y, en definitiva, permitir que la empresa segestione de manera más eficaz y eficiente.

Una adecuada implantación de DataGovernance elimina las discrepancias entrelos silos de datos. Sin embargo aquellascompañías que han implantado estos proyec-tos se han dado cuenta en seguida de que losplazos de implantación varían mucho en fun-ción del alcance y que no son simples ejerci-cios tecnológicos.

Cuando se adopta correctamente, DataGovernance es una disciplina que ayuda aalcanzar el verdadero valor de las aplicacionesanalíticas y debe constituirse en los cimientospara todas las iniciativas de gestión de lainformación. Pero para alcanzar una adecua-da gestión de estas entidades es necesaria unaadecuada visión estratégica para mejorar lacalidad de la información.

Son aquellos proyectos que se enfocan demanera iterativa, empezando con aquel con-junto de necesidades y datos que ofrecen elmayor valor al negocio en el menor tiempoposible los más exitosos. ¿Buscamos unamejor toma de decisiones mediante los siste-mas de Business Intelligence? Entonces nues-tro punto de partida deben ser los datosanalíticos. ¿Buscamos conseguir una mayoreficiencia operacional o ganar consistencia enlos procesos a lo largo de diferentes sistemastransaccionales? Entonces empecemos porlos datos operacionales.

Bibliografía

Jill Dyché. Five Models for Data Stewardship.Baseline Consulting, 2009.David Loshin. Data Governance for Master DataManagement and Beyond. DataFlux, 2008.Óscar Alonso. Tendencias en el uso de BI enEspaña 2009. Penteo, 2009.Óscar Alonso. El problema de la gestión de losdatos. Óscar Alonso, Penteo, 2010.

1 Data Governance es una disciplina emergentecon una definición en proceso de evolución. Estadisciplina abarca una convergencia entre calidadde los datos, gestión de los datos, políticas dedatos, gestión de procesos de negocio y gestiónde riesgos alrededor del manejo de los datos enuna organización (Traducción libre de la introduc-ción al concepto que se encuentra en la Wikipediaen inglés el 24/6/2011: <http://en.wikipedia.org/wiki/Data_governance>).2 Un Data Warehouse (DW) es una base de datosusada para generación de informes. Los datos soncargados desde los sistemas operacionales parasu consulta. Pueden pasar a través de un almacénde datos operacional para operaciones adicionalesantes de que sean usados en el DW para lageneración de informes (Traducción libre de laintroducción al concepto que se encuentra en laWikipedia en inglés el 24/6/2011: <http://en.wikipedia.org/wiki/Data_warehouse>). Sesuele considerar que el término equivalente encastellano es "Almacén de datos": "En el contextode la informática, un almacén de datos (del inglésdata warehouse) es una colección de datosorientada a un determinado ámbito (empresa,organización, etc.), integrado, no volátil y variableen el tiempo, que ayuda a la toma de decisionesen la entidad en la que se utiliza. Se trata, sobretodo, de un expediente completo de una organiza-ción, más allá de la información transaccional yoperacional, almacenado en una base de datosdiseñada para favorecer el análisis y la divulgacióneficiente de datos (especialmente OLAP, proce-samiento analítico en línea)." (Wikipedia en cas-tellano 24/6/2011: <http://es.wikipedia.org/wiki/Almac%C3%A9n_de_datos>).3 Data profiling es el proceso de examinar losdatos disponibles en las fuentes existentes (por ej,una base de datos o un fichero) recogiendoestadísticas e información sobre esos datos.(Traducción libre de la introducción al conceptoque se encuentra en la Wikipedia en inglés el 24/6/2011: <http://en.wikipedia.org/wiki/Data_profiling>). En castellano se suele considerar"perfilado de datos" como una traducción adecua-da: "Por perfilado de datos se entiende el análisisde los datos de los sistemas para entender sucontenido, estructura, calidad y dependencias":<http://integraciony calidad.blogspot.com/2008/07/migraciones-fusiones-y-adquisiciones.html>.4 Aunque la palabra inglesa "dashboard" puede serusada en muchos contextos, en el que nos ocupadiríamos que "En gestión de sistemas de informa-ción, un dashboard es un sistema de informaciónejecutivo (similar al tablero de instrumentos de uncoche) que se diseña para ser fácil de leer".(Traducción libre de la introducción al concepto quese encuentra en la Wikipedia en inglés el 24/6/2011:<http://en.wikipedia.org/wiki/Dashboards_(management_information_systems)>). Aunqueen castellano abunda una diversidad de traduccio-nes consecuente con la polisemia del término,"tablero de mandos" parecería la más adecuada eneste contexto.

Notas



monografía

1. Introducción"¿Por qué fallan tantos proyectos de cambioen las organizaciones? Porque están enfoca-dos en conseguir que las personas hagan lascosas mejor y más rápido y no en cambiar el"sistema"sistema"sistema"sistema"sistema". Detrás de esta realidad está la raízdel limitado beneficio, en muchos casos muylejos del potencial esperado, o incluso delfracaso, de muchas iniciativas de Performan-ce Management, Business Intelligence (BI),TQM, BSC, CRM…

Afortunadamente, resulta sorprendente comoel uso del concepto de "sistema" ha demos-trado ser extraordinariamente útil para abor-dar con sencillez situaciones complejas derelaciones sociales, humanas y de negocio.No es de extrañar que esté anunciada poralgunos la superación de la "era de lainformación" para dar paso a la "era de lossistemas".

Una metodología completa de BI debe adqui-rir el valor de la conjunción de dos corrientesmetodológicas:

Metodologías de BI enfocadas al nego-cio.

Metodologías de Pensamiento Sistémico.Reduciremos al mínimo las cuestiones tecno-lógicas de BI, aunque estás también son partedel sistema.

2. Metodologías de BI enfocadasal negocioLas principales causas de fracaso en laimplementación de soluciones de BI no seencuentran en cuestiones técnicas o tecnoló-gicas, sino en aspectos organizacionales y denegocio. Esto puede corroborarse consul-tando numerosos informes de analistas. Lanecesidad de entendimiento y de creación deequipo entre unidades de negocio y Tecnolo-gías de Información se hace aún más relevanteen BI que en otras soluciones tecnológicas.Existen probadas metodologías (Kimball,Inmon, Imholf, híbridas), que bien imple-mentadas resuelven con éxito los aspectostecnológicos de BI. No ocurre lo mismopara los aspectos no tecnológicos.

Por este motivo en los últimos años hansurgido metodologías de BI enfocadas alnegocio. Estas metodologías hacen énfasisen la fase de arquitectura y han establecido lanecesidad de organizar BI en torno a mapasde oportunidades de negocio, alineados conla estrategia de la organización. Un ejemplo

de esta metodología lo encontramos descritoen [1].

Adicionalmente, desde el punto de vistaorganizacional se establece la necesidad decrear programas de BI Governance y estruc-turas organizacionales como Comités yCentros de Competencia de BI (BICC). Es-tos elementos han tenido cierta proliferacióny han paliado muchos de los problemas quesurgen en los proyectos complejos de BI.

Este mayor énfasis en aspectos organi-zacionales y de negocio ha sido unamejora importante en el desarrollo de inicia-tivas de BI. Cualquier metodología actual deBI debe incluir características como:

Organización de BI como un portfolio deservicios enlazados a un mapa de oportunida-des de mejoras de negocio.

Establecimiento de un programa de BIGovernance, incluyendo cuando sea necesa-rio estructuras organizativas como Centrosde Competencias de BI (BICC).

Dirección de programas iterativos, nogestión de un proyecto.

Diseño y arquitectura de información,,,,, node aplicaciones.

Incorporación de metodologías tecnoló-gicas probadas (Kimball, Inmon, Inhoff...).

Pero todos estos componentes siguen siendo"hard systems", salvo en aspectos meramenteorganizacionales. Al introducir a las personasel sistema se nos convierte en un "soft system".El factor humano puede modificar completa-mente el funcionamiento de un sistema, pormuy bien concebida que esté la metodologíadesde un punto de vista "hard system". PeterCheckland [2][4], introduce en su metodolo-gía de sistemas blandos, (Soft SystemsMethodology, SSM), acciones de mejorasen tres frentes: organizacionales, procesos yde comportamiento. SSM ha sido utilizadocon éxito en diferentes entornos de Sistemasde Información [3].

Algunas metodologías de BI [1] para abor-dar el "problema" humano incluyen métodosde "reingeniería de procesos" y de "gestión delcambio" para los usuarios, pero mantienen latendencia generalizada en gestión y recursos

Business Intelligencey pensamiento sistémico

Carlos Luis GómezDirector de Ibertia Tecnología y Negocios

< c l u i s g @ i b e r t i a . e s >< c l u i s g @ i b e r t i a . e s >< c l u i s g @ i b e r t i a . e s >< c l u i s g @ i b e r t i a . e s >< c l u i s g @ i b e r t i a . e s >

Resumen: Este artículo es una invitación a pensar en BI de una forma distinta, pensar sistémicamentecomo complemento a la aproximación analítica habitual. Pensar en sistemas nos permite añadir una visiónholística, "ver el bosque además de ver los árboles". Business Intelligence (BI) necesita adaptarse al usode metodologías de Systems Thinking (pensamiento sistémico) si persigue el propósito de construir un"sistema" real de toma de decisiones. El uso de herramientas y metodologías de Pensamiento Sistémicoen BI no solo multiplica los beneficios potenciales de una solución de BI, complementando o mejorandola solución, sino que la aproximación metodológica más adecuada para construir soluciones de BIenfocadas a la obtención de valor de negocio debe ser en algunos casos necesariamente sistémica. Noestamos hablando solo de futuro sino de presente. Algunos de los beneficios de esta simbiosis estánprobados. Por ejemplo, la superación del balanced scorecard (BSC) llegando al Dynamic BalancedScoreCard (DBSC), o la creación de simuladores completos de negocio, sin los límites del "What If" delas herramientas habituales de BI.

Palabras clave: BI, dinámica, inteligencia, negocio, simulación, sistémico.

Autor

Carlos Luis Gómez es Director de Ibertia Tecnología y Negocios, empresa especializada en soluciones yservicios de Business Intelligence (BI) <http://www.ibertia.es/>. Acumula una experiencia de más de 15años como consultor en BI, Data Warehousing, y Systems-Thinking, cubriendo diferentes sectores de laindustria y muy diversos entornos tecnológicos, y liderando proyectos de ámbito nacional e internacio-nal. Es un experto en metodologías para el desarrollo de oportunidades de negocio sobre BI, y unprestigioso formador y colaborador de distintos medios de comunicación enfocados a BI, liderando ellanzamiento de la revista "Gestión del Rendimiento". Su capacitación técnica está acreditada por distintascertificaciones y programas: "DB2 Info Sphere Warehouse" de IBM, Teradata Professional, Netezza,"Microsoft Performance Point Server", consultor cualificado en España por BARC, analista líder europeoen BI para realizar servicios de selección y análisis de infraestructura tecnológica en BI.



humanos, de usar una aproximación de reso-lución de problemas ("problem-solvingaproach"), hilo conductor de las metodo-logías de gestión técnica. "Si resuelvo losproblemas de cada una de las partes, obtengola solución completa" es la creencia erróneaque sustenta este tipo de métodos. Esto, casinunca sucede.

En contraposición, el pensamiento sistémicoafirma que es necesario abordar la globalidaddel sistema, contemplar la interrelación entrelas partes. Por este motivo una de las reglasde SSM es evitar la palabra "problema" por-que induce a buscar la "solución". Frente aesto hay que contemplar la realidad como"situaciones problemáticas" sobre las queactuar para obtener mejoras deseables y via-bles. Orientado a la acción, SSM busca"acciones de mejora" sobre el sistema global,no soluciones a problemas parciales.

Esta visión de SSM no es contradictoria,encaja de hecho a la perfección con las men-cionadas metodologías de BI enfocadas alnegocio. La diferencia estriba en la aproxima-ción sistémica, no analítica. Las ventajas,sobre todo en cuanto al potencial de éxito yalcance de la solución son considerables.

Antes de definir el concepto de sistema paracomprender esta diferencia, se muestra a conti-nuación un ejemplo de algunas de las indeseadasconsecuencias de la aproximación exclusiva-mente analítica en la toma de decisiones.

3. Mejorar para empeorarLa aproximación analítica, no sistémica, escausa de muchos de los problemas conocidosde BI: silos de información, soluciones depar-tamentales no integradas, poco uso y partici-pación del usuario de negocio, escaso valorestratégico. Realmente no son problemaspropios de BI, sino heredados del modelo deorganización, gestión y negocio.

Sobre todos ellos hay amplia literatura. Seexpone aquí otro ejemplo de error, la sub-optimización, representativo de cómo bue-nas soluciones parciales generan erroressistémicos en la organización y en elnegocio. En estos casos una buena solución

BI lo único que hace es mejorar la enferme-dad, es decir empeorar los malos hábitosdecisionales.

A diferencia de otros males, la organizaciónvíctima no es consciente del problema de sub-optimización, o no desea cambiarlo, incluso lafomenta. La sub-optimización es una de lascausas que erosionan la competitividad de lasempresas y atrofian la posibilidad de desarrollode las mismas. Jamshid Gharajedaghi [5] citalas siguientes causas principales de erosión de lacompetitividad, de menor a mayor impacto:imitación, inercia, sub-optimización, cambiodel juego (en el mercado por ejemplo), despla-zamiento de paradigma.

El problema de la sub-optimización puedenacer de la diferencia de poder real entreunidades de negocio y de las personas en lasempresas. Por ejemplo, una persona en unaorganización se convierte en un héroe al resol-ver un problema crítico de negocio. Estapersona recibe veneración y autoridad queacaban otorgándole mayor poder, convirtién-dole en un decisor clave. Cada vez más deci-siones pasan por sus manos y la tendencianatural es fortalecer su posición. Su departa-mento se hace más poderoso y recibe másrecursos. Los buenos vendedores venden a laspersonas con poder, no a las más necesitadasde solución. Todo contribuye a optimizar eldepartamento más optimizado de la empre-sa. El departamento se hipertrofia.

El círculo vicioso de la sub-optimización seagrava porque, en ambientes de competenciainterna de recursos y poder, otros departa-mentos se atrofian siendo ignorados mien-tras los primeros se desarrollan. Las unidadesde negocio atrofiadas ponen el límite al desa-rrollo del negocio, pero difícilmente recibiránlos recursos que necesitan.

En cuanto a Business Intelligence, el departa-mento hipertrofiado es el máximo candidatopara liderar una solución de BI y en conse-cuencia hacerse con el poder de la informacióny el conocimiento. BI es un contribuyente netoa la sub-optimización y a otros erroressistémicos de las organizaciones, salvo quelas soluciones de BI se aborden con una visión

holística, lo que quiere decir entre otras cosas,con una visión corporativa y estratégica.

La sub-optimización para la organización esen cierto modo el equivalente a las burbujasdel mercado, que hipertrofian temporalmentealgunos sectores generando círculos viciososhasta el colapso.

Es imposible romper un círculo vicioso deeste tipo sin tomar conciencia del mismo.Desde el análisis, desde los datos, es imposi-ble esta toma de conciencia. La única posibi-lidad de abordar estas situaciones es desdeperspectivas sistémicas.

La sub-optimización es solamente un ejem-plo, existen muchos más errores sistémicos,círculos viciosos y virtuosos transparentes,inaccesibles, a un aproximación analítica.

En consecuencia, tal como indicamos en laintroducción, mejorar la infraestructura, lainformación, el conocimiento, las personas,pocas veces contribuye a una mejora globaldel sistema, e incluso tras una aparente me-jora lo empeora en el largo plazo. Para mejo-rar el sistema hay cambiar el sistema.

4. El concepto de "sistema"Nuestra cultura se basa en casi su totalidaden el pensamiento analítico. El éxito del mé-todo científico, basado en la aproximaciónanalítica, ha contribuido a esta situación.La aproximación analítica hacia los proble-mas, también se denomina reduccionista,puesto que divide los problemas en las partesque los componen y establece que resolviendocada una de las partes a las que ha sidoreducido se resuelve el problema completo.

En contraposición al método tradicional surgela aproximación holística. Ésta utiliza el con-cepto de sistema, enunciado por primera vezpor Ludwig von Bertalanffy en 1950, con lasiguiente definición: "un sistema es una entidadque mantiene su existencia a través de la mutuainteracción de sus partes". Una persona, uncoche, una red social, la tierra, por supuestouna organización, son ejemplos de sistemas. Encambio, un montón de arena no es un sistema,no hay interacciones entre sus partes.

Figura 1. Comportamientos dinámicos en los sistemas.



monografía

El lenguaje sistémico hace énfasis en lasinteracciones entre las partes, y no en las partes.En la figura 1figura 1figura 1figura 1figura 1 usamos un ejemplo de diagramascausales de "dinámica de sistemas".

El gráfico nos ilustra la sencillez del lenguajesistémico, una de sus ventajas. Los dos bu-cles mostrados prácticamente son auto-ex-plicativos y nos muestran de forma cualitati-va, el comportamiento dinámico de elemen-tos del sistema. ¿Cuántas palabras y tiemponos llevaría explicar lo mismo que expresanestos diagramas con lenguaje analítico? Mejoraún, pasar de modelos cualitativos a mode-los cuantitativos que permiten la simu-lación es posible y existen herramientas quehacen fácil la tarea.

Se enuncian a continuación algunas caracte-rísticas importantes de los sistemas.

4.1. Propiedades emergentesSon propiedades exclusivas que emergen en elsistema global resultado de la interacción delas partes, que no se pueden encontrar en laspartes. Por ejemplo, la interacción de cuerdasvocales, aire de los pulmones, posición de lalengua, órdenes del cerebro, un código delenguaje producen la voz. La voz es unapropiedad resultado de la interacción. Nopodemos llegar a la voz, por ejemplo su tono,analizando cada una de las partes queinteraccionan para producirla.

4.2. Los sistemas son abiertosLos sistemas se relacionan con otros siste-mas y con su entorno, forman parte de siste-mas más amplios que los contienen. Lasinteracciones más importantes del sistemason las que tiene con su entorno. Tampocopodemos entender el sistema sin este tipo deinteracciones. Por ejemplo, en el sistema Tie-rra existen cuatro estaciones (primavera, ve-rano, otoño, invierno). Podemos obtener elconocimiento de cómo se suceden las estacio-

nes y cuáles son sus características analizan-do los datos registrados año a año. Pero soloestudiando la interacción de la Tierra con elsistema que la contiene, Sistema Solar, enten-demos por qué se producen las estaciones,fruto de la interacción entre sol y tierra.

Afirma Russell Ackoff [6] que la aproximaciónanalítica produce conocimiento, encuentra res-puesta al "¿cómocómocómocómocómo?", mientras la sistémica pro-duce entendimiento, responde al "¿por quépor quépor quépor quépor qué?".Son complementarias, por eso hoy día el pensa-miento sistémico se extiende a todas las discipli-nas científicas. Ackoff establece la comparaciónentre la aproximación analítica y sistémica quese muestra en la tabla 1tabla 1tabla 1tabla 1tabla 1.

El método empírico sigue la aproximaciónanalítica, reproduce experimentos en laborato-rios bajo determinadas condiciones. Los resul-tados obtenidos en el entorno aislado del labo-ratorio se extrapolan a la realidad completa.

Pero con la realidad no podemos experimen-tar. En un entorno de negocio no podemoshacer experimentos de prueba y error condistintas decisiones, ni podemos aislar unaparte del entorno, del mercado, de los proce-sos para que funcionen aisladamente. Elmétodo analítico resulta inadecuado paraabordar la mayoría de las problemáticas denegocio. Ante esto la aproximación sistémicanos ofrece la simulación como herramientade estudio y prueba sin intervenir en la reali-dad, y la visión holística, no aislada, delsistema dentro de su entorno global, como laúnica válida en entornos sociales, económi-cos, de negocio…

4.3. Dinámica compleja y retroali-mentación (feedback)Si volvemos a la figura 1figura 1figura 1figura 1figura 1 podemos extraermás conclusiones. En los dos bucles causalesse produce un mecanismo de retroalimentación(feedback), importantísima característica de

los sistemas. En el primero esta retroalimenta-ción es positiva produciendo un círculo virtuo-so, si suben las ventas, o vicioso si éstas bajan.No hay un límite al crecimiento aparente. Por elcontrario el segundo bucle muestra una retroa-limentación negativa a través de la relación entrenúmero de competidores y precio. El segundobucle mostrará un límite en su crecimiento,tiende a la estabilidad.

En todos los procesos de negocio se producenmecanismos de feedback que afectan a la diná-mica del sistema. El feedback no suele serinmediato, sino que se producen retardos("delays") en estos mecanismos que no solocomplican la dinámica, sino que impiden sudetección incluso con sofisticadas herramien-tas analíticas de BI. Esto provoca efectos denuestras decisiones a largo plazo contrarias odistintas a las que esperadas en el corto plazo.

Cambios constantes, "feedback", "delays", nolinealidades, efectos contra-intuitivos, aco-plamientos… John Sterman en [7] describequé hace compleja la dinámica de los sistemasy de los negocios. Esto, unido a las barrerasde aprendizaje de nuestro cerebro, constituyela causa fundamental de que los expertos denegocio se equivoquen en sus análisis y tomendecisiones erróneas, incluso disponiendo deinformación de calidad proveniente de siste-mas de BI [8].

La forma de superar estas barreras es lamodelización y simulación del negocio. Nohay otra vía. Las herramientas de BI nopueden abordar esta problemática, están con-cebidas para el análisis, no para la síntesis.

5. Pensamiento sistémico en BI Existen distintas metodologías de pensamien-to sistémico: Dinámica de Sistemas, Ciberné-tica, Teoría del Caos, Planificación Inte-ractiva, Soft System Methodology, SystemOf Systems Methodology… Michael C.Jackson [9] hace una detallada descripción ycomparación de estas metodologías.

Describimos aquí la aplicación de dos deestas metodologías a BI. Por un lado comoherramienta de modelización del negocio ysimulación, "Dinámica de Sistemas" [10] esun complemento necesario probado que apor-ta mejoras sustanciales a los beneficios espe-rados típicos de una solución BI. Dos ejem-plos probados de este maridaje son:

Superación de las limitaciones de los cua-dros de mando y un incremento sustancial desu valor de negocio y aplicación práctica. Dehecho hoy día no deberíamos limitarnos adesarrollar Balanced Scorecards (BSC).Cualquier Organización que decida utilizarBSC debería directamente diseñar DynamicBalanced Scorecards (DBSC) que incorpo-ran pensamiento sistémico al BSC. Conmuchas ventajas, más sencillo que el BSCtradicional, permite identificar, cuantificar y

Tabla 1. Comparación entre las aproximaciones analítica y sistémica según Ackoff.

Aproximación Analítica – Fases

Aproximación Sistémica - Fases

1 Toma una parte del todo ¿De qué forma parte? Identificar el todo en el cual está contenido

2 Tratar de entender que hace esa parte

Explicar el comportamiento del todo donde está contenido

3 El conocimiento del todo es el ensamblaje del conocimiento de todas las partes

Identificar el rol o función en el todo de lo que estoy tratando de explicar o estudiar



ponderar métricas y KPIs (Key PerformanceIndicators), y estudiar el comportamientodinámico del cuadro de mando.

Incorporación de modelos dinámicos denegocio, imprescindibles entre otras cosaspara una correcta simulación. La predicciónanalítica, tanto a través de la Minería deDatos, o con el uso de las típicas simulacio-nes "What If" de las herramientas de BI, sonclaramente insuficientes para prever, influir ocontrolar el futuro del negocio o de la orga-nización. Esto es así por razones de diversaíndole que no es posible detallar aquí, tantotécnicas como metodológicas comomuestra Mahesh Raisinghani [11].

Los dos ejemplos anteriores llegan a ser críticosen algunas organizaciones y tienen un futuroasegurado. La simulación está contempladapor Gartner y otros analistas como una tecno-logía clave y de mayor previsión de crecimiento.De la misma forma que antes de lanzar lafabricación un avión se usan los simuladores devuelo para garantizar un correcto diseño y parael aprendizaje sin riesgo por parte de los pilotos,un simulador de negocio nos permite aprendersin riesgo y valorando el impacto de todo tipode decisiones.

Además de la complementariedad técnica queproporciona la Dinámica de Sistemas, la otravía para mejorar los programas de BI la encon-tramos en la mejora metodológica que propor-ciona el pensamiento sistémico. En este sentidoenunciamos una propiedad importante adicio-nal de los sistemas descrita por Peter Checklanden su SSM. Los sistemas actúan conLos sistemas actúan conLos sistemas actúan conLos sistemas actúan conLos sistemas actúan conpropósitos ("propósitos ("propósitos ("propósitos ("propósitos ("purpusefullypurpusefullypurpusefullypurpusefullypurpusefully") ") ") ") ") [2][4]. . . . . Laspersonas, por ejemplo, actúan con intención,con propósitos. Los sistemas complejos, comolos seres humanos, son multipropósito.

Referencias

[1] Steve Williams, Nancy Williams. The profitImpact of Business Intelligence. Elsevier, 2007.[2] Peter Checkland. Systems Thinking, SystemsPractice. Wiley, 1981 [rev 1999 1st ed.]. ISBN-10:0471986062.[3] Peter Checkland, Sue Holwell. Information,Systems and Information Systems. Wiley, 1990.[4] Peter Checkland, John Poulter. Learning ForAction: A Short Definitive Account of Soft SystemsMethodology, and its use Practitioners, Teachersand Students, Wiley, 2006. ISBN-10: 0470025549.[5] Jamshid Gharajedaghi. Systems Thinking:Managing Chaos and Complexity. A Platform forDesigning Business Architecture. Elsevier, 2006.[6] Russel L. Ackoff. Re-Creating The Corporation.Oxford University Press, 1999. ISBN-10:9780195123876.[7] John Sterman. System Dynamics Modelling,Tools For Learning in a Complex World. Californiamanagement review 43 (4): pp. 8–25, 2001.[8] Carlos Luis. Los Hombres Que No Amabana las Decisiones. <http://www.beyenetwork.es/channels/1576/view/11703>, octubre 2009.[9] Michael C. Jackson. Systems Thinking, CreativeHolism for Manager. Wiley, 2003. ISBN-10:0470845228.[10] John D. Sterman. Business Dynamics.McGraw-Hill, 2000. ISBN-10: 007238915X.[11] Mahesh Raisinghani. Business Intelligencein the Digital Economy: Opportunities, Limitations,and Risks. IGI Global, 2004. ISBN-10: 1591402069.

SSM establece que las situaciones problemá-ticas contienen distintos worldviews (visio-nes) de los actores del sistema. Como semencionó, SSM es una metodología orienta-da a la acción. La interacción entre las worldviews define las transformaciones de-seables y viables en esta metodología. SSMacaba definiendo un conjunto de accionespara mejorar representadas en un "modelo deactividades con propósitos" con métricas deeficacia, eficiencia y efectividad. Modelo quesirve no solo para construir, sino como dis-positivo de comunicación entre los actoresdel programa. La figura 2figura 2figura 2figura 2figura 2 muestra lospasos de la metodología SSM. El paso 4define los modelos de actividades.

El enlace de la metodología de BI enfocada alnegocio con SSM puede establecerse fácil-mente. El mapa de oportunidades de negociorepresenta los worldviews y propósitos deSSM, el modelo de actividades con propósitorepresenta el programa iterativo de BI, y lagobernanza se establece a través de las métri-cas de eficacia, eficiencia, efectividad.

6. ConclusiónEl pensamiento sistémico se está extendien-do a multitud de disciplinas, mostrando unacapacidad para afrontar situaciones comple-jas. BI debe beneficiarse de esta aproximacióncomplementaria a la analítica.

Siguiendo los pasos de la metodologíasistémica contemplamos la identificación delsistema superior en la que está contenida laparte en estudio. Business Intelligence es unelemento del sistema de decisiones. Un siste-ma de decisiones consta de dos subsistemasfundamentales, el de información, generada através de los datos obtenidos de la realidad, y

Figura 2. Diagrama de pasos de la Soft Systems Methodology (SSM).

el de los modelos mentales que generan laestrategia y reglas de negocio [9] [10]. BIadquiere el rol del subsistema de informaciónen la toma de decisiones, mientras que pensa-miento sistémico representa el subsistema delos modelos mentales o de negocio. La con-junción de la información de calidad y lamodelización sistémica nos proporciona lacapacidad de simulación cualitativa y cuanti-tativa del negocio. Este es el primer beneficiodel uso de Systems Thinking en BI.

Como segundo beneficio BI puede benefi-ciarse de las mejoras metodológicas aporta-das por el pensamiento sistémico para abor-dar situaciones o programas complejos, per-mitiendo priorizar oportunidades de mejorade negocio con sus métricas y KPIs. BI debeevolucionar de la misma forma que en otrasingenierías han evolucionado con éxito de lasmetodologías duras ("hard") a las meto-dologías suaves o blandas ("soft"). El bene-ficio esperado es un mayor potencial de éxito,al contemplar las acciones necesarias: tecno-lógicas, organizacionales, de proceso y decomportamiento.

Finalmente, destacar que el mayor beneficiodel pensamiento sistémico es el de la creativi-dad y la innovación en cualquier área deactividad en la que se aplique. Creatividad conpropósito es un requerimiento obligado en elentorno de gestión actual.

SituaciónProblemática

No estructurada

Expresiónde la Situación

Problema

Mundo Real

Pensamiento SistémicoAcerca del Mundo Real

Modelo conceptual delos subsistemas Relevantes

4

Comparación deModelos y Mundo Real 5

6 Cambios:Sistémicamente deseables

Culturalmente viables

7 AccionesPara mejorar la situación problema

3Definición raíz de los

Subsistemas relevantes

2

1Situación

ProblemáticaNo estructurada

Expresiónde la Situación

Problema

Mundo Real

Pensamiento SistémicoAcerca del Mundo Real

Modelo conceptual delos subsistemas Relevantes

4

Comparación deModelos y Mundo Real 5

6 Cambios:Sistémicamente deseables

Culturalmente viables

7 AccionesPara mejorar la situación problema

3Definición raíz de los

Subsistemas relevantes

2

1



monografía

1. Introducción y definicionesEste artículo describe cómo implementar unaestrategia de Business Intelligence (BI) enuna Organización No Gubernamental(ONG). Una estrategia se entiende como unplan de acción que permite obtener una ven-taja competitiva respecto a un estado anteriorde la misma organización o en comparacióncon una organización similar. "BusinessIntelligence" se define como el conjunto deherramientas, procesos, técnicas y algoritmosque permiten soportar el proceso de toma dedecisiones en las organizaciones entregandola información correcta a quien correspondey en el momento oportuno.

La ONG donde se aplica la teoría presentadaen este artículo es VE-Global1 (VE), unaorganización que recluta, entrena y organizavoluntarios para trabajar con niños en riesgosocial en Chile. El trabajo realizado con VE esla esencia de este artículo e intenta difundir ycompartir el conocimiento de esta experiencia.VE no contaba con una persona o equipodedicado a temas de tecnologías de informa-ción, si bien estaban las ganas de utilizar mejorla información que tenían, había una oportuni-dad de mejora al contar con habilidades técnicasen tecnologías de información, que fue lo queresultó después de empezar el proyecto.

Una ONG tal como cualquier organizacióninteractúa con personas y otras organizacio-nes generando relaciones y vínculos mutuos.Estas interacciones obligan a las organiza-ciones a tomar mejores decisiones pero sóloalgunas lo hacen basadas en sus datos.

Los datos que las mismas organizacionesgeneran son un activo importante porqueninguna otra organización tiene acceso aellos. Por esto, se deben identificar estosdatos y basar la estrategia sobre ellos. Unaadecuada estrategia de información para unaONG no sólo tiene importancia para la propiainstitución, tiene también un impacto social.

El primer paso es conocer las necesidades deinformación y los objetivos estratégicos de laorganización. Para esto es necesario reunirsecon los directores y generar acuerdos quefinalmente serán la guía para definir la estra-tegia de información.

Una estrategia de información debe plantear-se en función de las capacidades actuales dela organización. Asimismo, es necesario uni-

Caso de estudio:Estrategia BI en una ONG

Diego Arenas ContrerasJefe Soluciones de Business Intelligence enFormulisa, Chile

< d a r e n a s c @ g m a i l . c o m >< d a r e n a s c @ g m a i l . c o m >< d a r e n a s c @ g m a i l . c o m >< d a r e n a s c @ g m a i l . c o m >< d a r e n a s c @ g m a i l . c o m >

Resumen: En todas las organizaciones y en todos los niveles se toman decisiones. El soporte a la tomade decisiones permite mejorar y diferenciarse, facilita la gestión, mejora la eficiencia, entrega un apoyo yuna guía para la continuidad de la organización. Las instituciones sin ánimo de lucro también deben tomardecisiones pero sus datos y su día a día son diferentes, sus problemáticas diversas, pero también puedentomar decisiones basadas en sus datos y generar conocimiento a partir de su información. Este artículomuestra cómo planificar y aplicar una estrategia de Business Intelligence (BI) en organizaciones sin ánimode lucro, partiendo desde el entendimiento de los procesos, identificar las necesidades de información, losdatos disponibles y relevantes y entregar las soluciones precisas a los requerimientos de datos e informa-ción que la organización tiene. La presentación de las ideas está acompañado de un trabajo práctico conuna ONG real en Chile.

Palabras clave: análisis de datos, CRM, factores clave de éxito, indicadores de gestión, ONG, reportes.

Autor

Diego Arenas Contreras estudió Ingeniería Civil en Computación en la Universidad de Talca en Chile.Realizó un Diplomado en Gestión de Negocios con Business Intelligence y le apasiona el mundo de lossistemas de información y la visualización de información. Ha trabajado en diferentes empresas e indus-trias en temas y proyectos de Inteligencia de Negocios, Performance Management y Minería de Datos. Esactualmente Jefe de Soluciones de Business Intelligence en Formulisa, empresa consultora chilenadedicada a entender el comportamiento de los consumidores y a la Inteligencia de Clientes para susclientes. <http://www.formulisa.cl>.

ficar la semántica con la que se trabajará ycontar con una definición clara para los con-ceptos y términos de lenguaje utilizados porlos participantes del proyecto, tener un enten-dimiento de cada concepto simplificará losproblemas de comunicación y dará mayoragilidad al proyecto.

En VE se utilizó un documento compartidocon acceso a los participantes para escribir lasdefiniciones que conocían y agregar los con-ceptos que requerían definición, cada partici-pante podía agregar su entendimiento en unanueva columna hasta llegar a un consenso enla definición. Con esto se aseguró la partici-pación y conocimiento de cada integrante delproyecto y se facilitó la inducción para quie-nes se incorporaron al proyecto después dehaber comenzado; es recomendable tambiénel uso de wikis.

Gracias a los acuerdos semánticos podemosdefinir los términos utilizados en este artículo:

Leads: Personas o instituciones que tie-nen un potencial de relacionamiento mutuocon VE.

Contacto: Persona que tiene una relaciónmutua con la VE, puede ser de diferentes tipos.

Organizaciones: Empresas u organiza-ciones que tienen relación de algún tipo conVE, permiten agrupar los contactos dentro delas organizaciones.

Instituciones: Son los hogares con loscuales VE trabaja directamente a través de susvoluntarios y programas.

Voluntarios: Persona natural que es ca-pacitada y administrada por VE y prestaservicios en instituciones y a VE.

Donaciones: Entregas gratuitas de dine-ro, productos o servicios que recibe VE departe de un contacto y/o organización.

Programa: Plan de instrucción en un temaespecífico para apoyar el desarrollo de los bene-ficiarios de una Institución, por ejemplo: Pro-grama de deportes para fomentar la vida sana yel deporte, programa de lectura para fomentary potenciar las capacidades lectoras.

Así como en VE, habrá términos específicosen cada organización y será necesario definir-los para fomentar una comunicación efecti-va.

Las herramientas utilizadas durante el pro-yecto fueron de tipo colaborativo y opensource, para facilitar la comunicación:

Google Docs, para trabajar documentoscolaborativamente.

Dropbox2 para el intercambio de archi-vos.

GanttProject3 , herramienta open sourcepara llevar la carta Gantt del proyecto.

FreeMind4 para diagramar mapas men-tales y compartir ideas.



Sandbox de Salesforce, ambiente de pruebasproporcionado por Salesforce donde los cam-bios no afectan a los datos de producción.

Como sucede en la mayoría de las organiza-ciones, VE estaba manteniendo diferentesrepositorios de información por lo que elprimer objetivo fue llevar sus datos a un únicosistema operacional que permitiera mantenerlos datos y ser usado como única fuente deinformación, por lo que se acordó potenciary sacar el máximo provecho de su soluciónCRM (Customer Relationship Management)para organizaciones sin ánimos de lucro.

En primer lugar, la estrategia BI debe estaralineada con los objetivos estratégicos, se-gundo se debe trabajar en colaboración conlos responsables de la información y comuni-car los objetivos a todos los involucrados, entercer lugar el análisis de los datos, procesosy flujos de información se hace desde laperspectiva de los objetivos estratégicos decada área de la organización. Lo siguiente esasegurar la calidad de la información a utili-zar asegurando la calidad de los datos, y luegoaplicar la estrategia en función de las capaci-dades de la organización y anticipar los futu-ros requisitos de información basados en losdatos almacenados. Finalmente monitorearel uso y evaluar mejoras.

2. Datos, información y procesosAl inicio del proyecto con VE definimos re-uniones con los directores para conocer losobjetivos estratégicos y las necesidades decada área de la organización. Al principiofueron reuniones tipo entrevista para obtenersu visión y entender los datos que manejan,luego se realizaron sesiones de brainstorming(lluvia o tormenta de ideas) donde se les pidióimaginar el proyecto finalizado con éxito yque imaginaran la información de la quedispondrían para analizar los reportes quepodrían consultar y las decisiones que seríancapaces de tomar basadas en los datos, per-mitiendo identificar las entidades de datospresentes en VE y sus interacciones.

Se obtuvieron dos artefactos desde esta acti-vidad que es el diagrama de alto nivel deentidades y sus relaciones y un documentocon los reportes requeridos. Después de lasreuniones y sesiones de brainstorming, sefijaron reuniones semanales de 30 minutospara comunicar los avances y fijar los objeti-vos semanales. En estas reuniones participa-ron los voluntarios involucrados y el directorejecutivo, que tiene el rol de sponsor delproyecto, y se fijaron reuniones adicionalespara coordinar temas con más profundidaddurante la semana si era necesario.

Durante la detección de las necesidades unose interioriza en la cultura organizacional,con las entrevistas a los directivos se conocenlos datos únicos de la organización, los prin-

cipales procesos y los actores responsables enlos flujos de información y de datos, se palpala realidad de datos que la organización vive.El rol de los expertos en BI es el de guiar ymostrar los beneficios de una solución de BIy recomendar la solución que se ajusta a lasnecesidades de información, definiendo unaestrategia para alcanzar estos fines.

Una vez analizados los procesos y recolectadala información necesaria para planificar unaestrategia de BI debemos dar el paso másimportante de toda nuestra estrategia de BI, queno es otro que generar el entendimiento entretodos los implicados. Para ello debemosconsensuar que todos entendemos lo mismo, ypara ello generamos el primer entregable queserá el pilar de todos los proyectos.

Este primer entregable es el que llamamosdefiniciones organizacionales. . . . . Consiste en uni-ficar el vocabulario y que cada término tengauna definición semántica única y homogénea.La idea es que todo el mundo entienda lo mismoal escuchar términos como "voluntario" o "ins-titución". Con esto se asegura el entendimientoentre los interesados y se define un vocabularioque facilitará la comunicación y el avance en laimplementación exitosa. Si todos hablamos elmismo idioma seguro que no tendremos malosentendidos.

En VE registramos en un documento com-partido los reportes que se necesitaban indi-cando dueño del reporte, nombre del reporte,resumen, razón para el reporte, periodicidadde consulta, campos requeridos en el reportey observaciones que se quisieran agregar.

Se analizó este documento con alrededor de45 definiciones de reportes llevándolo a unmapa mental donde el primer nivel son lasentidades de datos como Leads, Contactos,Organizaciones, Donaciones, Eventos, Cam-pañas y Programas y dentro de cada hoja, querepresenta una entidad, se agrupan los cam-pos que se requieren para satisfacer el reporteagrupando por tipos y temática. Por ejemplo,para los Leads se requiere información básicade contacto donde se agrupan los campos decontacto y campos de metadatos para sabercómo llegó a conocer VE, tipo de lead (leadpara voluntariado, socio potencial de VE,sponsor de VE, etc. (ver figura 1figura 1figura 1figura 1figura 1).

El mapa mental5 con las entidades identifica-das y los campos requeridos para satisfacertodos los reportes es la base sobre la cual seestructura el plan de calidad de datos y seasegura que los campos existan en la base dedatos y sean correctamente llenados. Ade-más, dentro del mapa mental se agrupan losreportes solicitados por temas mostrando asílas grandes áreas de interés para VE las cualesson Contactos, una serie de informes paraconocer las personas y organizaciones quetienen contacto con VE, Donaciones que

principalmente consiste en tener informaciónoportuna acerca de las donaciones recibidas,dónde están, cómo se utilizan, quiénes las hanhecho, etc., y el Rendimiento que es un temaatingente a las empresas para optimizar re-cursos, focalizar los esfuerzos, reducir cos-tos y los beneficios de tomar decisiones basa-das en los datos.

Hay que tener presente y recordar en todomomento que una estrategia de BI no es unproyecto puntual que entregará un productofinal específico como un reporte o undashboard, es un plan que aborda las necesi-dades de información y se encarga de generarlas acciones necesarias para la satisfacción deéstas en función de las capacidades actualesde la organización.

Cada organización produce datos que sonpropios a la actividad y al día a día de lainstitución, estos datos que ninguna otraorganización puede acceder se deben recono-cer como un activo para la organización, yuno de importancia ya que son una fuenteúnica de información y conocimiento. Estosdatos únicos son inherentes a la actividad dela organización, se pueden levantar medianteentrevistas, mirando los reportes existentes yla calidad de datos del modelo de datos.También es posible identificar potencialesdatos que no se están guardando que sonúnicos a la organización, identificar esto esclave para asegurar el registro de estos datosen la estrategia de BI.

En muchas ocasiones las ONG no cuentancon un experto en sistemas de informaciónpor lo que los procesos y datos han sidollevados de la mejor manera de acuerdo a cadapersona encargada de la labor. Esto sumadoa la rotación de voluntarios hace que ladisponibilidad e integración de la informaciónsea mínima. Un tema recurrente es lasubutilización de los sistemas a los cualestienen acceso debido al bajo nivel de configu-ración y adaptación a sus necesidades especí-ficas.

En ONGs la comunicación con su red decontactos representa la continuidad, comu-nicar datos fácticos sobre el trabajo que seestá realizando y medir estos contactos esvalioso. Tener la información disponible paraorganizar eventos en lugares con alta densi-dad de contactos de la organización por ejem-plo, poder entregar estadísticas actuales delas horas de voluntariado, cantidad de gentea la que se está llegando o dependiendo deltipo de organización poder presentar el traba-jo en números actualizados y disponiblespara la comunidad.

Desde el principio de la implementación, sedebe enfocar en la información relevante detodos los datos y procesos que se levanten, sedebe hacer un ranking ordenado por impor-



monografía

Figura 1. Primer nivel del mapa mental con la identificación de los campos mínimos y las temáticas de reportes.

tancia, y focalizar los esfuerzos en satisfacerlas necesidades de información de acuerdo alordenamiento.

3. Planificación e implementaciónde una estrategiaContar con el apoyo directivo y de los actoresprincipales en cada una de las etapas de laimplementación es un factor clave de éxito delproyecto. Enfocarse en la información rele-vante para la organización y asegurarse decubrir los ámbitos más importantes de acuer-do al ranking de importancia de la informa-ción requerida en el levantamiento. Asimis-mo, se debe pensar en cubrir la mayor cantidad

de necesidades de información y los procesosmás importantes o de mayor impacto para laorganización.

Una estrategia de Business Intelligence esindependiente de las herramientas usadas y delos usuarios que participan en la iniciativa, setrata de entregar a todo nivel la informaciónque la organización necesita. La informaciónes como el oxígeno que mantiene a la organi-zación respirando.

La arquitectura es dependiente a las necesida-des de información y se define en torno alresultado del levantamiento. Es importante

que en organizaciones no gubernamentales seutilice un estilo de desarrollo flexible paraalinearse a las necesidades cambiantes deinformación, es decir asegurar el alineamien-to con los objetivos estratégicos de la orga-nización pero también evaluar los nuevosrequerimientos con prontitud. Por ejemplo,se evaluaron e implantaron funcionalidadesnuevas del CRM de módulos que fueronlanzados después del inicio del proyecto, porlo que no fueron considerados en la planifica-ción inicial, pero ofrecían mejoras que sealineaban con los objetivos del proyecto.

Los dueños de la información y de los datos



Bibliografía

Cindi Hudson. Successful Business Intelligence:Secrets to Making BI a Killer App. McGraw-HillOsborne Media, 1 edition. 2007. ISBN-10:9780071498517.Douglas Wubbard. How to Measure Anything:Finding the Value of Intangibles in Business. Wiley;2 edition, 2010. ISBN-10: 9780470539392.Olivia Parr Rud. Business Intelligence SuccessFactors: Tools for Aligning Your Business in theGlobal Economy. Wiley, 2009. ISBN-10:9780470392409.Henri Rouillé D’ Orfeuil. La Diplomacia No Guber-namental. Lom – Chile, 2008. ISBN: 9562829723.

1 <http://www.ve-global.org/>.2 <http://www.dropbox.com/>.3 <http://www.ganttproject.biz/>.4 <http://freemind.sourceforge.net/wiki/index.php/Main_Page>.5 Desarrollado con FreeMind.

Notas

deben estar claramente definidos, y perfecta-mente podrían ser actores diferentes. Evaluarla calidad de datos actual y establecer un plande mejoramiento continuo de la calidad dedatos y de información; además se debe defi-nir la seguridad y los accesos a datos sensi-bles. La planificación de la estrategia debeconsiderar una batería de reportes eindicadores de gestión y la medición de losprocesos importantes y personas al interior dela organización.

En el caso de VE se establecieron las reunio-nes y entrevistas para conocer los procesos,los datos relevantes fueron obtenidos desdelas reuniones y los informes registrados en eldocumento compartido. El mapa mental conlos campos de información más la clasifica-ción de los reportes sentaron la cobertura dedatos mínima que se necesita en el CRM ycada entidad se evaluó en profundidad iden-tificando claramente su campos y relacionescon otras entidades.

Luego se agregaron y validaron los camposen el sistema. Para una aceptable calidad dedatos se parametrizó la mayor cantidad decampos posibles, tratando de minimizar los"datos abiertos" como por ejemplo listadosde países, meses de estadía, preguntas conalternativas, etc. A partir de ahí se analizaronlos cerca de 45 reportes solicitados, parareducir la cantidad de reportes y maximizar lainformación en cada uno de ellos.

Los reportes creados se entregaron a susdueños, los cuales pueden conocer quiénesson los dueños de cada dato, resultando asíque cuando un dato no está bien registrado sepuede gestionar directamente con el respon-sable que se ingrese correctamente.

Durante el proceso se identificaron oportuni-dades de mejora y de optimización de proce-sos en VE, por ejemplo aprovechando lacreación de formularios web que recolectanautomáticamente datos y los ingresan alsistema sin intervención humana, esto reduceel tiempo de ingreso de datos y evita duplicarfuentes de información. Disponer de datosactualizados para consulta y para una mejortoma de decisiones permite a los directores deVE conocer mejor la organización a través desus datos en forma oportuna y eficiente;también mejorar la comunicación con su redde contactos al segmentar y focalizar suscomunicaciones.

Lo recomendable es unificar las fuentes dedatos, tener un solo repositorio y desde ahíconcentrar los requerimientos de informa-ción, como fue el caso de VE que apuntó allevar sus procesos y recolección de datos a susistema CRM. Identificar los procesos per-mite el mejoramiento continuo de los flujosde información mediante la automatizaciónde las tareas repetibles identificadas y la

optimización de procesos que faciliten el ac-ceso a la información y faciliten el ingreso delos datos.

Al momento de la implementación hay queasegurarse de que los usuarios que interactúancon los sistemas operacionales o transac-cionales donde se ingresan los datos requeri-dos, tengan conocimiento del motivo por quélos datos son importantes y que la calidad dedatos y la calidad de la información dependede ellos. Es importante hacer capacitacionesen el uso del sistema y en las capacidades deinformación enfatizando que los usuariosdeben usar correctamente el sistema. A esterespecto, su involucramiento temprano en laimplementación facilita su conocimiento delsistema.

Finalmente, los beneficios son entregar lainformación adecuada a los usuarios que lanecesitan, identificar los datos que son nece-sarios para satisfacer todos los reportes,generar una trazabilidad en los datos en elproceso desde las fuentes de datos hasta losreportes finales, y hacer una reducción al nivelde área interesada, agrupando la mayor can-tidad de información relacionada en la menorcantidad de reportes. Es decir, clasificar lasnecesidades de información similares y agru-parlas en conjuntos, y que los conjuntos denecesidades de información sean lo másheterogéneos posible.

La estrategia de BI mejora la eficiencia y laaccesibilidad de la información a quien lanecesite. También mejora las relaciones conlos socios y amigos de la ONG entregando losdatos para la promoción de esta y el vínculosocial a través de los hechos reflejados en losdatos.

4. Conclusiones y trabajo futuroLas directrices presentadas en este artículopermiten comenzar a liderar una implemen-tación de una estrategia BI en una organiza-ción no gubernamental y ajustarla a las nece-sidades específicas de la organización.

La idea de medir el rendimiento de programasy la efectividad de campañas y acciones de losvoluntarios es extraer el conocimiento parahacerlo repetible en otras ONG que tengan losobjetivos similares, ya que entonces se conocela fórmula de éxito que funciona. Las opor-tunidades de gestionar con información sonmuchas de aquí en adelante, como por ejem-plo conocer los perfiles de su red de apoyo encuanto a personas y empresas; perfilar a losdonantes, voluntarios, y contactos. Analizarlos datos del pasado, poder generar un mode-lo de predicción de donaciones, comunicar ala comunidad los datos reales y actualizadosde trabajo de la organización, tener el pulso decuántos, quiénes, cómo, dónde se está traba-jando, y lo que es más importante optimizarel trabajo en las instituciones donde los vo-

luntarios colaboran a través del análisis dedatos que éstas mismas generan.

AgradecimientosA VE Global por la oportunidad de desarrollareste proyecto con ellos, ha sido un enormeenriquecimiento profesional y personal. A losvoluntarios Bushra Akram y Ben Richman quehan trabajado directamente en la implementacióny hecho realidad el proyecto. A Josh Pilz, Direc-tor Ejecutivo de VE, por su apoyo y entusiasmo,a los directores y colaboradores Annie Rondoni,Mariah Healy, Jamie Ensey, Faith Joseph por sutrabajo y excelente disposición en todo momen-to.


Arquitecturas secciones técnicas

secciones técnicas

1. IntroducciónAlgunas de las razones por las que las imáge-nes del software en ejecución se corrompenson las pérdidas de memoria, bloqueos infi-nitos, bloqueos en memoria compartida, hi-los sin finalizar, fragmentación del almacena-miento, corrupción de los datos, interferenciapor rayos cósmicos, fallos en la disipacióntérmica, entre otros. Este fenómeno es cono-cido como envejecimiento del software1 , y hasido observado en clusters de procesamiento,sistemas de telecomunicaciones, servidoresweb, PC domésticos y otros sistemas. Lasevidencias de sus efectos son más comunes ensistemas que operan de forma ininterrumpi-da, como servidores web y de correo electró-nico, entre otros.

Una forma ingenua, intuitiva y común paracombatir la degradación de la imagen desoftware en ejecución es el reinicio periódicoy preventivo de los sistemas. A esta técnica sela refiere como rejuvenecimiento del soft-ware2 . La técnica trae al centro de cómputosla receta amateur de apagar y encender undispositivo que no responde. Diferentes técni-cas de rejuvenecimiento sugieren estrategiaspara los re-inicios preventivos, brindándonos lasensación de que estamos combatiendo el fenó-meno desde un punto de vista tecnológico.

El presente trabajo analiza y aísla fuentesespecíficas de degradación de la imagen delsoftware en memoria y su efecto en la ejecu-ción de sus respectivos programas. Un pro-fundo análisis de las técnicas de manejo dememoria del sistema operativo nos permiteproponer técnicas de rejuvenecimiento que norequieren el reinicio del sistema. Se presentan,asimismo, los resultados de la implementaciónde un prototipo, así como los datos experi-mentales.

La organización del trabajo se describe acontinuación. La secciónsecciónsecciónsecciónsección 2 provee una in-troducción y análisis del fenómeno del en-vejecimiento del software. La sección sección sección sección sección 3 brin-da una introducción al manejo de memoria enlos sistemas operativos modernos, poniendofoco en el manejo de la memoria de solo-lectura y las técnicas de detección de corrup-ción. Posteriormente, la sección 4sección 4sección 4sección 4sección 4 brindadetalles del prototipo implementado, juntocon resultados experimentales relevantes.

Diferentes líneas de trabajo para el área sonsugeridas en la sección 5sección 5sección 5sección 5sección 5. El trabajo conclu-ye en la sección 6sección 6sección 6sección 6sección 6.

2. Envejecimiento del softwareNo todas las fallas en nuestros sistemas sedeben a software mal construido. De hecho,podríamos tener software perfecto ejecután-dose en un sistema, y dicho sistema podríafallar debido a causas externas. Existe unaalta probabilidad de que en muchos de estosfallos, causas externas afecten el hardware delsistema, y por consiguiente al software queallí se ejecuta. También existe la posibilidadde que ciertas condiciones de hardware osoftware transitorias afecten la ejecución es-perada. El resto de esta sección introduceconceptos relevantes relacionados al enveje-cimiento de software.

2.1. TaxonomíaJim Gray [1] clasifica los errores de softwareen dos categorías distintas, Bohrbugs yHeisenbugs. Esta distinción se basa en lafacilidad de reproducir la falla causada porestos errores.

La primera categoría, los Bohrbugs, que debensu nombre al modelo atómico de Bohr, sonesencialmente errores permanentes en el diseño,y son por naturaleza casi deterministas. Puedenser identificados y corregidos durante la fase depruebas del ciclo de vida del software.

Por otro lado, los Heisenbugs, así nombra-dos por el principio de incertidumbre deHeisenberg, incluyen aquellas fallas internasque son intermitentes. Fallas cuyas condicio-nes de activación ocurren raramente, y por lo

tanto son difíciles de reproducir. Un manejode excepciones incorrecto o incompleto es unclaro ejemplo de Heisenbugs. Estos erroresson más difíciles de detectar durante la fase depruebas que los Bohrbugs.

K. Vaidyanathan y Kishor S. Trivedi [2] agre-gan una tercera categoría a esta clasificación,la cual incluye aquellas fallas causadas por laocurrencia de envejecimiento de software.

Esta categoría de fallas es similar en ciertosaspectos a los Heisenbugs, ya que su activa-ción está determinada por ciertas condicionescomo la falta de recursos del sistema opera-tivo, algo que no es sencillo de reproducir.

Sin embargo, sus métodos de recuperacióndifieren significativamente. Mientras que losHeisenbugs se corrigen mediante técnicaspuramente reactivas, las fallas causadas porel envejecimiento de software pueden ser pre-venidas mediante la aplicación de técnicasproactivas, como puede ser el reinicio perió-dico del software afectado.

Estamos particularmente interesados en loserrores de hardware, especialmente aquellosque ocurren en los chips de memoria de unsistema. Estos errores también son conocidoscomo soft errors [3] y pueden ser clasificadoscomo errores causados por envejecimiento desoftware, aunque no son causados por el enve-jecimiento en sí mismo, sino por causas exter-nas, como pueden ser los rayos cósmicos,temperatura y humedad, entre otros.

2.2. Soft ErrorsComo se mencionó en la sección 2.1sección 2.1sección 2.1sección 2.1sección 2.1., los

Extensiones al núcleo de Linuxpara reducir los efectos delenvejecimiento del software

Ariel Sabiguero, AndrésAguirre, Fabricio González,Daniel Pedraja, Agustín VanRompaeyInstituto de Computación, Facultad de Inge-niería, Universidad de la República, Monte-video (Uruguay)

< { a s a b i g u e , a a g u i r r e } @ f i n g . e d u . u y > ;< { a s a b i g u e , a a g u i r r e } @ f i n g . e d u . u y > ;< { a s a b i g u e , a a g u i r r e } @ f i n g . e d u . u y > ;< { a s a b i g u e , a a g u i r r e } @ f i n g . e d u . u y > ;< { a s a b i g u e , a a g u i r r e } @ f i n g . e d u . u y > ;< { f a b g o n z , d a n i g p c , f e n i x . u y } @ g m a i l . c o m >< { f a b g o n z , d a n i g p c , f e n i x . u y } @ g m a i l . c o m >< { f a b g o n z , d a n i g p c , f e n i x . u y } @ g m a i l . c o m >< { f a b g o n z , d a n i g p c , f e n i x . u y } @ g m a i l . c o m >< { f a b g o n z , d a n i g p c , f e n i x . u y } @ g m a i l . c o m >

Este artículo ha sido seleccionado de entre las mejores ponencias presentadas en la XXXVI ConferenciaLatinoamericana de Informática (XXXVI CLEI), evento anual promovido por el Centro Latinoame-ricano de Estudios en Informática (CLEI), entidad en la cual ATI es el representante de España.

Resumen: Las técnicas actuales de rejuvenecimiento de software atacan diferentes errores transitorios delos sistemas de una forma poco específica: restauración del proceso o sistema completo. Nuestro equipoimplementó un prototipo que ataca el problema con una aproximación más fina. El prototipo implementadodetecta y corrige la corrupción de páginas de memoria de solo-lectura en un sistema GNU/Linux. Elpresente trabajo describe la clase de errores considerados, el mecanismo de corrección de erroresimplementado y su aplicación a la confiabilidad y disponibilidad del sistema. Para evaluar la implementación,realizamos estudios en diferentes contextos de aplicación bajo cargas de trabajo simuladas. Mecanismosde inyección de fallas fueron utilizados para generar y simular errores en el sistema. Los resultadosrelativos a desempeño y mejora en la disponibilidad se presentan también, mostrando que la utilización deesta técnica es adecuada en condiciones generales de un sistema.

Palabras clave: rejuvenecimiento, soft-errors, técnicas de corrección de memoria.


secciones técnicas Arquitecturas

secciones técnicas

soft errors son errores en el hardware dememoria de un sistema. Es importante enfo-carse en ellos, ya que normalmente no setoman en cuenta al momento de diseñarsoftware, y pueden eventualmente causar fa-llas totales en un sistema.

Sería interesante contar con algún tipo deprotección contra estos errores, que no estéconstruida directamente sobre el hardware,como los chips de memoria con código co-rrector de errores (memoria ECC).

Debido a la naturaleza de estos errores, esimposible predecir cuándo ocurrirán, y por lotanto, necesitamos una técnica reactiva quepermita al software recuperarse frente a laaparición de uno de ellos.

Los soft errors pueden ser causados por unavariedad de eventos. James F. Ziegler, uninvestigador de IBM, publicó varios artículosprobando que los rayos cósmicos podían serotra causa de aparición de soft errors [4].

Durante estos experimentos, IBM descubrióque la frecuencia de aparición de soft errors seincrementaba con la altura, duplicándose a800 metros por encima del nivel del mar. Enla ciudad de Denver, a 1.600 metros porencima del nivel del mar, la frecuencia deaparición de soft errors es 10 veces la del niveldel mar.

En otro experimento, descubrieron que lossistemas ubicados bajo tierra experimenta-ban una frecuencia de soft errors muchomenor, y dado que 20 metros de roca puedenbloquear casi la totalidad de rayos cósmicos,concluyeron que dichos rayos cósmicos eranefectivamente una posible causa de apariciónde soft errors.

Otra posible causa de aparición de soft errorses la interferencia electromagnética (EMI).Esta interacción puede causar alteraciones enlos transistores o buses y, con el tiempo,puede causar que su valor lógico cambie. Estetipo de interferencia es común en lugaresdonde operan motores eléctricos de alta fre-cuencia [5].

En entornos industriales donde se utilizaneste tipo de motores y muchos sistemasempotrados controlan la maquinaria, la pro-babilidad de ocurrencia de un soft error esmucho más alta, lo cual puede llevar a dañosen la maquinaria o peor aún, lesiones en losoperarios humanos. Estos factores soncruciales a la hora de considerar aspectos deseguridad.

2.3. Soluciones y técnicas existentesLas técnicas más comunes para combatir loserrores causados por el envejecimiento desoftware se conocen como "técnicas de reju-venecimiento de software".

Existen dos estrategias distintas que puedenutilizarse para determinar el momento ade-cuado para aplicar el rejuvenecimiento.

La primera es conocida como enfoque open-loop [2]. Este método consiste en aplicar elproceso de rejuvenecimiento sin utilizar nin-guna clase de información sobre el desempe-ño del sistema. El rejuvenecimiento se puedeaplicar luego de que una cierta cantidad detiempo ha pasado desde la última aplicación,o cuando el número de trabajos concurrentesdel sistema llega a un cierto número crítico.

Por otro lado, tenemos el enfoque closed-loop [2]. En este método, la salud del sistemaes continuamente monitoreada para detectarla posibilidad de que ocurra un error causadopor el envejecimiento, como la falta de unrecurso particular del sistema, que puedallevar a una disminución del rendimiento o auna falla total del sistema. En este enfoquepodemos clasificar nuestras técnicas según laforma de analizar los datos recolectados.

El análisis offline utiliza datos sobre el rendi-miento del sistema, recolectados durante unextenso período de tiempo (semanas o me-ses) para determinar la frecuencia óptima deejecución del rejuvenecimiento, siendo ade-cuado para sistemas cuyo comportamientoes determinístico.

El análisis online se basa en juegos de datosrecolectados mientras el sistema está en fun-cionamiento, que se combinan con juegos dedatos anteriores, para decidir si es un buenmomento para aplicar rejuvenecimiento, sien-do aplicable para sistemas cuyo comporta-miento es difícil de predecir.

Las técnicas de rejuvenecimiento de softwarese pueden aplicar en distintos niveles degranularidad.

Un ejemplo de rejuvenecimiento aplicado anivel de sistema es un reinicio total dehardware, y a nivel de aplicación el reiniciode procesos afectados es otro ejemplo derejuvenecimiento.

La aplicación de rejuvenecimiento tiene unimpacto negativo en la disponibilidad delsistema rejuvenecido. Por este motivo es muyútil contar con una arquitectura de alta dis-ponibilidad, donde podemos aplicar rejuvene-cimiento a ciertos nodos individuales sinimpactar en la disponibilidad del sistemaglobalmente.

Si diseñamos nuestros sistemas teniendo encuenta todos estos factores, aplicar rejuvene-cimiento ha probado ser una técnica proactivamuy efectiva y de muy bajo costo [6] paraprevenir errores. Con este enfoque no esta-mos mejorando la confiabilidad del sistemapero sí la disponibilidad de los servicios.

3. Considerando los soft errors y lamemoria de solo lecturaLas arquitecturas de hardware y sistemasoperativos modernos proveen mecanismosde protección sobre la memoria disponible,esencialmente, asignando privilegios de acce-so a cada una de las páginas de memoriavirtual. La asignación de privilegios de accesoa las páginas de memoria está directamentesoportada por la mayoría de las arquitectu-ras, debido al soporte provisto por losmicroprocesadores actuales.

A lo largo del presente trabajo nos referimoscon el término memoria de solo-lectura ( ROpor sus iniciales en inglés) a las partes de lamemoria de un sistema a las cuales los me-canismos de protección del sistema operativoprohíben la modificación de su contenido.

De las múltiples facilidades ofrecidas por elsistema de memoria, cabe destacar que encualquier instante del tiempo podemos clasi-ficar las páginas de un proceso en dos catego-rías: solo-lectura y modificables. Las páginasde solo-lectura son constantes a lo largo dela ejecución de un programa.

En base a la definición anterior de memoria desolo-lectura, es directo ver como los cambiosobservados en dichas regiones son interpreta-dos como una falla.

Asumiendo que el mecanismo de protecciónbrindado por el sistema operativo está carentede errores, el único motivo por el que pode-mos encontrar un cambio en la memoria desolo lectura es debido a un soft error. Bajoesta hipótesis asuminos que el uso de técnicasde detección de cambios en memoria de solo-lectura es equivalente a la detección de softerrors.

3.1. Memoria RO en softwareestándarCualquier programa corriendo en un sistemaoperativo estándar actual está conformadopor un conjunto de archivos-objeto, conte-niendo bibliotecas y ejecutables. Compila-dores y enlazadores trabajan en conjunto conel SO para convertir código fuente en códigoobjeto que puede ser cargado y ejecutado ensu plataforma objetivo. Existen muchosformatos diferentes para archivos ejecutables,como ELF (Executable and Linking Format),normalmente utilizado en sistemas GNU/Linux, o PE (Portable Executable) utilizadoen sistemas basados en Windows NT.

La evolución en los lenguajes de programa-ción, verificaciones y restricciones impuestaspor los nuevos compiladores, están convir-tiendo el código ejecutable en un código másseguro. Los ejecutables construidos concompiladores actuales fuerzan la separacióndel código objeto en páginas de solo-lecturay otras con privilegios de escritura.



secciones técnicas

La proporción entre éstas es dependiente delos programas particulares en sí mismos.Programas compactos que manipulan gran-des volúmenes de datos (p.e. software destreaming), presentan una cantidad reducidade páginas de memoria de solo-lectura. Pro-gramas de alta complejidad que manipulanjuegos de datos pequeños (p.e. paquetes deoficina) presentan una tasa mucho mayor depáginas de solo-lectura. Es por esta razón quela cobertura ofrecida por la presente técnicano es la misma en todos los escenarios.Algunos resultados experimentales son pre-sentados en la sección 4.3.sección 4.3.sección 4.3.sección 4.3.sección 4.3.

3.2. Memoria RO en LinuxEl formato estándar de objetos, ejecutables ybibliotecas en GNU/Linux es el formato ELF.

ELF soporta el concepto de secciones, queson colecciones de información de tipos simi-lares. Cada sección representa una porcióndel archivo. A modo de ejemplo menciona-mos que el código ejecutable es colocado enuna sección conocida como .text. Las varia-bles inicializadas por el usuario son coloca-das en una sección denominada .data y losdatos sin inicializar en la sección .bss.

El gestor de memoria puede marcar porcio-nes de memoria como RO de forma tal que losintentos de modificación de las mismas resul-tan en la finalización de la ejecución del pro-grama por parte del sistema operativo. Es porello que, en vez de no esperar que una posiciónde memoria RO cambie como consecuenciade un error en el programa, tenemos la certezade que cualquier intento de modificación deuna posición RO es un error fatal, indicandoun fallo en el software. El sistema operativose encarga de finalizar el programa que ofen-dió la protección.

Dado que deseamos que las porcionesejecutables estén en páginas de memoria ROy las posiciones de memoria modificables enmemoria de lectura-escritura, resulta máseficiente agrupar todas las porcionesejecutables en la sección .text, y todas lasáreas que pueden ser modificadas en lasección .data. Los datos experimentales rela-tivos a un servidor web estándar (LAMP) sonpresentados en las secciones 4.2. y 4.3secciones 4.2. y 4.3secciones 4.2. y 4.3secciones 4.2. y 4.3secciones 4.2. y 4.3.

Los sistemas empotrados representan otroentorno de aplicación en el que GNU/Linuxestá ganando terreno. Estos sistemas empo-trados corren generalmente en plataformasen las que no se dispone de mecanismos dedetección y corrección de errores en memoria.

Los beneficios de una solución estándar,basada en servicios del sistema operativo, sonde gran interés en estos sistemas que correnLinux, en los que las fallas tienen un impactodirecto en características como la confiabilidadde los mismos.

4. Implementación de un prototi-po en GNU/LinuxDescribiremos la implementación de un pro-totipo que hace uso de la hipótesis presentadaen la sección 3sección 3sección 3sección 3sección 3 para combatir los efectos delenvejecimiento en el software causado porerrores en la memoria. La herramienta sedesarrolló como una extensión al núcleo deGNU/Linux, extendiendo la funcionalidaddel subsistema de memoria (Memory Mana-ger).

En la sección 4.1sección 4.1sección 4.1sección 4.1sección 4.1 describimos la funcio-nalidad del prototipo y los detalles más rele-vantes de su implementación. Dado que sufunción se basa en la detección de soft errors,las pruebas de validación requirieron la alte-ración de la memoria, de forma que puedieranser consideradas equivalentes a los erroresque buscamos detectar. Como se describe enla sección 4.2sección 4.2sección 4.2sección 4.2sección 4.2, fue necesario hacer uso detécnicas de inyección de fallos, lo que nospermitió simular errores de hardware de unaforma repetible, económica y segura. Porúltimo, en la sección 4.3 sección 4.3 sección 4.3 sección 4.3 sección 4.3 presentamos losresultados de algunas pruebas funcionales yde desempeño del prototipo ejecutándose enuna instancia concreta de GNU/Linux. Laspruebas de desempeño se basan en pruebasestándar de algunos aplicativos en Linux.

4.1. Detalles de la implementaciónComo parte del trabajo de tesis de González,Pedraja y Van Rompaey [7], se construyó unprototipo basado en Linux. La primera metade este prototipo fue detectar la ocurrencia desoft errors en la memoria física del sistema,sacando provecho de la existencia de regionesde memoria de solo lectura.

Como se vio en la sección 3sección 3sección 3sección 3sección 3, Linux adminis-tra los recursos de memoria con granularidadde páginas, por lo que el primer paso paralograr el objetivo mencionado es identificar elsubconjunto páginas para los que el S.O. nosgarantiza acceso de solo lectura. Este esque-ma de protección es representado por mediode los permisos de acceso de las áreas dememoria virtual que forman parte del espaciode direcciones de un proceso y se hace cumplirpor medio de las tablas de páginas del proce-so. El mecanismo de memoria virtual deLinux hace posible que las páginas de memo-ria sean compartidas entre los espacios dememoria de varios procesos con diferentespermisos de acceso en cada caso. Tomandoesto en cuenta, se puede definir el subconjuntode páginas de solo-lectura como aquellas queestán asignadas al espacio de direcciones deuno o más procesos del espacio de usuario,con permisos de solo-lectura en todos loscasos.

Todos los eventos de cambios en la asigna-ción, y permisos de acceso de las páginas dememoria, fueron analizados. Manejandoestos eventos y manteniendo información de

estado extra, fue posible determinar en cual-quier momento la pertenencia o no de unapágina dada al subconjunto deseado. Loscambios realizados al núcleo se limitaron lomás posible y la mayoría de la funcionalidadfue encapsulada e implementada en un mó-dulo del núcleo (ver figura 1figura 1figura 1figura 1figura 1).

Una vez identificado el subconjunto de pági-nas de solo-lectura, el segundo paso es contarcon un mecanismo de detección de cambiosa nivel de bits sobre sus elementos. Cualquiercambio en un bit en este contexto se puedeinterpretar como la ocurrencia de un softerror.

La solución general para proveer esta clase defuncionalidad es mantener, para cada páginaen el conjunto, un código de redundanciasobre los bytes pertenecientes al rango dememoria que este representa. En el prototipoLinux, esto fue implementado agregando uncódigo de redundancia al estado mantenidopara cada página de memoria. El código teníacomo requerimiento proveer detección de erro-res en múltiples bits de una forma eficiente, esdecir, usando una pequeña cantidad de bits deredundancia para los volúmenes de datosobjetivo (el tamaño de una página de memo-ria va desde 4KB a 4MB).

Luego de evaluar diferentes opciones, el algo-ritmo de detección de errores seleccionadopara esta tarea fue CRC32. La redundanciamantenida debe ser actualizada en los eventosmencionados anteriormente, de forma quesea la correspondiente a los contenidos de lapágina mientras la misma pertenece al con-junto de solo-lectura. La estrategia seguidapara garantizar esto consiste en recalcular yalmacenar el código cada vez que la páginaingresa a un estado que lo posiciona dentrodel conjunto (por ejemplo cuando la primerasignación de solo-lectura es realizada sobreuna página que previamente estaba libre), yborrar (o ignorar) la redundancia en transi-ciones a estados fuera del conjunto (comopuede ser cuándo una asignación de escrituraes agregada a una página que era previamentede solo-lectura). Gracias al estado almacena-do, verificar la existencia de errores es tansimple como recalcular el CRC32 y compa-rarlo con el almacenado.

La herramienta puede ser configurada paraseguir una de tres estrategias de búsqueda deerrores. Para comprender las diferentes estra-tegias, es importante tener en cuenta que,debido a que estamos tratando de reaccionara eventos que ya habrán sucedido, la detecciónde errores será asíncrona a la ocurrencia de losmismos y siempre habrá un retraso entreambos sucesos. Hacer ese intervalo de tiem-po lo más pequeño posible fue la meta alseleccionar las estrategias de búsqueda, pues-to que esto reduce las probabilidades de queun proceso acceda a la sección de memoria



secciones técnicas

Figura 1. Cambios realizados al núcleo de Linux.

corrupta antes de que se puedan tomar accio-nes.

El primer y más simple de los enfoquesimplementado consiste en un hilo del núcleoque chequea continuamente todo el conjuntode páginas de solo-lectura en un ciclo cons-tante. Aunque esta estrategia puede sugeriruna pérdida de desempeño, en la práctica haprobado ser bastante efectiva.

El prototipo brinda algunas funcionalidadesde configuración, las que permiten a un admi-nistrador del espacio de usuarios ajustarla deacuerdo a cada escenario y sus requerimien-tos. Trataremos sobre las mismas luego,pero se da aquí un adelanto sobre el registrode procesos, que es esencial para la existenciade las dos estrategias de búsqueda restantes.El registro de procesos básicamente permiteal administrador configurar la herramienta deforma que ésta enfoque sus esfuerzos en ungrupo indicado de procesos.

Cuando el módulo es configurado para tra-bajar solo con tareas registradas, puede rea-lizar verificaciones de errores de dos maneras.La primera es similar a la estrategia ya expli-cada, solo que en este caso el hilo itera sobre

la lista de tareas registradas chequeando so-lamente aquellas páginas de solo lectura asig-nadas al espacio de memoria de la tareaactual. Esta estrategia ha probado ser consi-derablemente más eficiente que la anterior.

Los experimentos realizados para compararlos retrasos de detección de errores entreambas técnicas mostraron un intervalo detiempo promedio de 275 milisegundos para labásica. Por otro lado, las pruebas indicaronun retraso promedio de 1 milisegundo para laestrategia que usa los procesos registrados,aún cuando se estaba simulando carga alsistema al registrar las tareas del stack LAMP.

La última estrategia de búsqueda de erroresimplementada también trabaja solo con lastareas registradas. La misma fue desarrolla-da modificando el planificador de tareas delnúcleo, para chequear las páginas de solo-lectura asignadas al espacio de memoria de lapróxima tarea a obtener la UCP, justo antesde que realmente obtenga el recurso. La metade esta estrategia es permitir la toma deacciones en todas las secciones de memoriacorruptas pertenecientes al espacio de memo-ria de un proceso, antes de que el mismoobtenga el control de la UCP y logre acceder

a dichas secciones. A diferencia de los dosenfoques presentados previamente, en estecaso el objetivo no es reducir el retraso dedetección de los errores. Esta estrategia haprobado ser efectiva, pero puede tambiénsignificar una importante sobrecarga en laplanificación de procesos, por lo que deberíaser usada con extrema cautela.

El solo hecho de la detección no es suficiente,por lo que se definió una secuencia de accio-nes para el manejo de errores como parte delprototipo. El primer paso consiste en emplearun código corrector de errores, para tratar dearreglar la memoria afectada de forma auto-mática. Existen varios tipos de códigos am-pliamente utilizados para este tipo de tarea,entre los cuales se seleccionó una adaptaciónde los Códigos de Hamming, debido a su fácilimplementación. Los Códigos de Hammingson en realidad el método más comúnmenteusado por los chips de memoria ECC, peroen este caso la corrección de un solo bit queproveen puede no ser suficiente para toda unapágina de memoria. Con diferentes caracte-rísticas de cubrimiento y desempeño, las téc-nicas Reed-Solomon podrían haberse aplica-do, pero las mismas fueron descartadas debi-do a la complejidad de su implementación.



secciones técnicas

La segunda acción tomada para tratar decorregir errores se basó en el concepto derejuvenecimiento, concebido como técnicapro-activa de manejo de fallos, orientada alimpiar el estado interno del sistema paraprevenir la ocurrencia de fallos más severosque provoquen caídas en el futuro. Una po-sible solución para corregir páginas de me-moria de solo-lectura corruptas usando reju-venecimiento, es mantener un respaldo de suscontenidos y recargar el mismo ante errores.La mayoría de las páginas de solo-lectura sonla imagen de un archivo en disco, por lo queel propio archivo se convierte en el respaldorequerido para estas páginas. El prototipoprovee una funcionalidad que recargaautomáticamente la imagen de una páginadesde disco, cuando se detecta un soft errordentro del mismo. Para el caso de páginas novinculadas a archivos (también llamadasanónimas) se debería proveer una implemen-tación de almacén de respaldo, pero su desa-rrollo excedió el alcance del prototipo.

Se encontró una forma de aplicar rejuveneci-miento cuando se ejecuta el núcleo, pero enrealidad la mayoría de la teoría sobre estatécnica apunta al espacio de usuario. Dadoque muchas estrategias de rejuvenecimientose basan en estadísticas de los recursos paradecidir cuándo aplicarlo, se entendió que eneste caso el rol del SO era proveer informaciónsobre la detección de errores y notificaciones,de forma que asista a esas decisiones.

Primero, se decidió brindar notificacionessincrónicas de los errores detectados a losagentes de rejuvenecimiento del espacio deusuario. Esta funcionalidad se implementópor medio de señales de Linux. Cuando unproceso es registrado en la herramienta, seespecifica también otro proceso que toma elrol de agente de rejuvenecimiento de la tarearegistrada. En caso de detección de errores enel espacio de memoria de la tarea, una señalespecífica es enviada a su agente para que éstepueda tomar acciones.

A veces el rejuvenecimiento simplemente con-siste en el reinicio de procesos o incluso detodo el sistema. Sin embargo, si se cuenta conla información adecuada, se pueden tomaracciones de mayor granularidad (por ejem-plo, volver a asignar solo un archivo). Parabrindar a los agentes la oportunidad de reco-nocer tales acciones, el prototipo publica alespacio de usuario información detalladasobre cada error detectado. Estos detallesincluyen para cada proceso (registrado o no),las direcciones física y virtual exactas de losbytes cambiados, el área virtual de memoriaa la cual pertenece la dirección en el espacio dedirecciones del proceso y a qué tipo de vínculo(archivo, anónimo) corresponde. En caso deque el error ocurra en la asignación de unarchivo, se provee también el nombre delarchivo y el rango asignado.

Finalmente, el estado resultante del error(corregido o no) también se muestra. Lainterfaz con el espacio de usuarios selecciona-da para presentar esta información fue siste-ma de archivos virtual /proc, usando carpetasy archivos a nivel de tareas.

Se mencionó que el prototipo también proveealgunas funcionalidades de configuración,como los ya explicados procesos registrados.El módulo soporta además el concepto demodo global el cual está compuesto por unconjunto de banderas. Cada una de estasbanderas permite al administrador activar odesactivar diferentes funcionalidades. Se crea-ron banderas adicionales para poder elegirentre las posibles estrategias de búsqueda deerrores y para encender y apagar las accionesde manejo de errores o incluso todo el módu-lo. La interfaz con el espacio de usuarios parala configuración del modo y las tareas regis-tradas fue implementada también usando elsistema virtual de archivos /proc, mediante laescritura en archivos especiales.

Se ha usado el término módulo a lo largo deesta sección para referirse a la implementacióndel prototipo, pero no se ha explicado comola misma se integra realmente con el núcleo deLinux.

Como el término lo implica, todas lasfuncionalidades presentadas se agrupan enun único módulo en el núcleo. El mismoprovee un grupo de interfaces con un conjun-to de callbacks que le permiten manejar loseventos internos del núcleo y las interfacescon el espacio de usuarios. Estas callbacks sediseñaron para reducir lo más posible el aco-plamiento del núcleo con el prototipo. Cuan-do se dice módulo, no se refiere al conceptode módulo dinámico que soporta el núcleo.Dichos módulos son capaces de agregarfuncionalidad a una instancia activa del nú-cleo y son mayormente usados para desarro-llar controladores de dispositivos. En estecaso, debido a las secciones del núcleo dondelas interfaces del módulo son invocadas, ne-cesitamos agregar funcionalidad al núcleo entiempo de compilación. Debido al tipo defuncionalidad que provee, se decidió incluirlos fuentes del módulo como parte delsubsistema de manejo de memoria del núcleode Linux.

4.2. Pruebas funcionales del prototi-poLa verificación de la correctitud del prototipofue importante por varias razones. Por unlado, siempre está la necesidad de agregarcalidad a la implementación que está siendovalidada, pero, por otra parte, se requeríaseparar los defectos del prototipo de los softerrors en la memoria. Los tests consistieronen alterar valores de memoria localizados enpáginas de solo lectura y verificar que loscambios fueron detectados y corregidos.

Para el diseño de los casos de prueba no secontaba con medios para inyectar errores porhardware en los subsistemas de memoria, porlo que se recurrió a la inyección de errores porsoftware. Los detalles tecnológicos implica-dos están fuera del alcance de este trabajo,pero simplemente podemos mencionar queuna API de alto nivel del núcleo no puede serusada para modificar las páginas de memoriade solo-lectura. Alterar los valores de memo-ria de solo-lectura desde el espacio de usua-rios genera fallos de segmentación. Alterarlos valores de memoria de solo-lectura desdeuna API portable de alto nivel (como ptrace)genera efectos no deseados; el núcleo convier-te la página de solo-lectura en una de lectura-escritura antes de efectivizar el cambio. Tanpronto como la página se convierte en una delectura-escritura, es removida del conjunto depáginas monitoreadas por el prototipo.

La inyección de errores por software debe serhecha en modo supervisor, donde se obtieneacceso sin restricciones a la memoria y lasmodificaciones directas a la misma puedensaltear el esquema de protección de memoriadel núcleo. Se implementó la inyeccióndireccionando la memoria directamente des-de el espacio virtual del núcleo, evitando laslimitaciones de las tablas de páginas de losprocesos de espacio de usuarios. Se expusoesta funcionalidad al espacio de usuarios pormedio de una nueva llamada al sistema (nom-brada sys_kpgsa_inject()) y se desarrolló unavariedad de herramientas de alto nivel. Lasopciones incluyen desde alterar posiciones dememoria de un solo byte, hasta simular fallosde memoria periódicos y aleatorios (lluvia derayos cósmicos).

4.3. Pruebas de desempeñoUn sistema con un buen rendimiento es im-portante, a pesar de las positivas consecuen-cias sobre la confiablidad, disponibilidad yseguridad física (safety) de las técnicas derejuvenecimiento automático y de softwarede propósito general. Con el fin de monitorearlos cambios, la memoria de solo-lectura delsistema debe ser explorada completamente deforma periódica, transformando el prototipoen una aplicación con uso intensivo de UCP,sin impacto en el uso de entrada/salida. Estointroduce competencia por el acceso a memo-ria, y además, pérdida en la localidad.

Se analizaron dos escenarios diferentes deaplicaciones: aplicaciones con uso intensivode UCP y las de uso intensivo de entrada/salida. Como aplicación intensiva en uso deUCP se seleccionó POV-Ray [8] (ver figurafigurafigurafigurafigura22222), y la de uso intensivo en entrada/salida esun servidor LAMP3 .

Para medir el impacto sobre el rendimiento delsistema utilizamos las propias herramientasde benchmarking que incluyen estos paquetesde software, comparando su rendimiento en



secciones técnicas

el mismo sistema, con y sin uso de las rutinasde corrección de corrupción de memoria. Lostests fueron realizados en ambos modos.

Las mediciones de desempeño fueron consis-tentes con la intuición. El impacto en elrendimiento en un servidor LAMP es margi-nal, como puede verse en la figura 3figura 3figura 3figura 3figura 3, mien-tras el impacto en la aplicación de técnicas deraytracing es significativo, como se muestraen la figura 2figura 2figura 2figura 2figura 2.

En otras palabras, las rutinas de corrección decorrupción de memoria prácticamente nocompiten con tareas que hacen un uso inten-sivo de IO mientras si lo hacen con las tareasque hacen uso intensivo de UCP.

Como última observación sobre el impactoen el funcionamiento del software, no todoslos sistemas tienen la misma proporción depáginas de solo-lectura sobre páginas de lec-tura-escritura. En base a los resultados ante-riores analizamos el mecanismo de funciona-miento de Apache y MySQL, y ambos com-parten el paradigma de atención basado enfork. Los procesos padre tienen una tasasuperior a la de los hijos, como se pude ver enla tabla 1tabla 1tabla 1tabla 1tabla 1. Los resultados observados sonconsistentes con el hecho que el proceso padreno almacena datos de ejecución requeridospara contestar a clientes particulares, sinoinformación de gestión global del servicio.

Los procesos que tratan con los pedidos sonlos clientes. Los procesos padres están enejecución durante más tiempo que los hijos eneste escenario, y son estos los procesos quemás se benefician de los algoritmos de correc-ción de corrupción.

El impacto de un soft error no corregido en unproceso hijo podría afectar solamente a unaúnica sesión, mientras que un error similar enun proceso padre podría afectar a la totalidaddel servicio de allí en más. La detección decorrupción toma más relevancia en los proce-sos padre, donde además la tasa RO/RW estambién mayor.

5. Resultados y trabajo futuroQuedan todavía diferentes parámetros deajuste ya identificados que deberían ser agre-gados a la implementación, de forma que sevuelva más adaptable a diferentes escenariosde aplicación. freqd y otros demonios decompensación de UCP (o CPU equalization)tienen que ser considerados para alcanzartambién las plataformas móviles. Laimplementación actual mantendría el UCP deun notebook al 100%, consumiendo la bate-ría demasiado rápido.

Portar el prototipo a diferentes plataformases necesario para acceder al mercado de siste-mas empotrados. Su uso en sistemas empo-trados, donde comúnmente no se cuenta con

memoria ECC, es un área donde el impactopuede ser significativo.

La implementación actual probó su capaci-dad de mejorar la disponibilidad de un servi-dor LAMP, bajo carga pesada y bajo lluviapesada de rayos cósmicos simulada. Un sis-tema sin una implementación de correcciónde corrupción de memoria de solo-lectura,falla luego de unos pocos segundos de mo-dificaciones aleatorias de su memoria. Lacorrección de corrupción de memoria mostróque es posible hacer que un sistema recargueimágenes frescas del software en la RAMcuando ocurre la corrupción, sin impacto enlos servicios que este provee.

Como observación final, todavía tenemosque asegurarnos que la implementación escapaz de detectar y corregir soft errors reales.Nuestras estimaciones [7] indican que ensistemas individuales de vanguardia (4GBDDR2 memory), habrá un error corregible,manejable para nuestro prototipo, cada 22años en promedio por sistema. Todavía nohemos encontrado ningún error en núcleosmodificados ejecutándose en ambientes deproducción. Es deseable obtener acceso aambientes donde la tasa de error es mayor.

6. ConclusionesLa industria ya sabe acerca del software agingo envejecimiento del software: cuando un

Figura 2. POV-Ray: tiempo de render. Figura 3. LAMP: tiempo de servicio.

Tabla 1. Tasa de páginas RO/RW en el software utilizado.

MySQL Apache httpd Padre Hijo Padre Hijo

Páginas de solo lectura 287 47% 614 13% 930 38% 952 23% Páginas de lectura/escritura 330 53% 4235 87% 1487 62% 3245 77%



secciones técnicas

Notas

sistema comienza a tener un comportamien-to errático, lo primero es reiniciarlo.

Las técnicas de rejuvenecimiento de softwarehan ganado un lugar más significativo en laadministración de sistemas en los últimosaños y distintos productos las introducen,con diferentes niveles de granularidad, comoparte de sus soluciones potenciadas para ladisponibilidad. Hasta donde llega nuestroconocimiento, solo el rejuvenecimiento a ni-vel de todo el sistema o todo el proceso hansido presentados hasta el momento.

Nuestro prototipo ha probado que el rejuve-necimiento de granularidad fina es posible,como una herramienta del sistema operativo,en ambientes de aplicación de propósito gene-ral. Aunque la solución implementada solocubre las páginas de memoria de solo lectura,la misma no requiere ningún cambio a nivel dedespliegue, como es el caso de técnicas basa-das en réplicas y balance de carga.

Debido al hecho de que es aplicable a cual-quier pieza de software sin necesidad de rea-lizar cambios, ofrece una forma simple y nointrusiva de reducir los costos de manejo deun ambiente de producción.

Todavía no podemos reemplazar la memoriaECC con una solución por software, peronuestra implementación de corrección de lacorrupción de memoria es capaz de mejorarla disponibilidad de los sistemas donde latecnología ECC no está disponible.

Aunque todavía se requiere más investiga-ción, mostramos que es posible mejorar ladisponibilidad y confiabilidad de aplicacionesarbitrarias con técnicas generales de rejuvene-cimiento de granularidad fina, implementadasa nivel del sistema operativo, con un impactorazonable en el desempeño.

Referencias

[1] Jim Gray. Why do computers stop and what canbe done about it? Tandem Computers. TechnicalReport 85.7, PN 87614, <http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf>, 1985.[2] Kishor S. Trivedi, Kalyanaraman Vaidyanathan,Katerina Goseva-popstojanova. Modeling andanalysis of software aging and rejuvenation.Proceedings of the IEEE Annual Simulation Symposium,pages 270–279, 2000.[3] Actel Corporation. Understanding soft and firm

errors in semiconductor devices. Actel Corporation.51700002-1/12.02, <http://www.actel.com/documents/SER_FAQ.pdf>, 2002.[4] J. F. Ziegler. Terrestrial cosmic rays. IBM J. Res.Dev., 40(1): pp.19–39, 1996.[5] G.L. Skibinski, R.J. Kerkman, D. Schlegel. Emiemissions of modern pwm ac drives. IndustryApplications Magazine, IEEE, 5(6): pp. 47–80, nov/dec 1999.[6] Artur Andrezejak, Monika Moser, Luis Silva.Managing Performance of Aging Applications ViaSynchronized Replica Rejuvenation. En AlexanderClemm, Lisandro Zambenedetti, and Rolf Stadler,editors, (DSOM 2007) Managing Virtualization ofNetworks and Services, ISBN 978-3-540-75693-4,pages 98–109. Springer, 2007.[7] Daniel Pedraja, Fabricio González, Agustín VanRompaey. Herramientas del sistema operativo paracombatir el software aging. Proyecto de grado,<http://www.fing.edu.uy/~asabigue/prgrado/softwareAging.pdf >.[8] Persistence of Vision Raytracer. POV-Ray,<http://www.povray.org>.

1 Del inglés software aging.2 Del inglés, software rejuvenation.3 Linux, Apache, MySQL, PHP.

Las JAIIOs, Jornadas Argentinas de Informática, se realizan desde1961 y son organizadas por SADIO.

En sesiones paralelas se presentan trabajos que se publican en Anales,se discuten resultados de investigaciones y actividades sobre diferentestópicos, desarrollándose también conferencias y reuniones con laasistencia de profesionales argentinos y extranjeros. Las JAIIOs seorganizan como un conjunto de simposios separados, cada unodedicado a un tema específico, de uno o dos días de duración, de talforma de permitir la interacción de sus participantes.

Una lista completa de todos los simposios de las 40 JAIIO se puedenencontrar en: <http://www.40jaiio.org.ar>.

Fecha: del 29 de agosto al 02 de septiembre de 2011Lugar: Ciudad de Córdoba, Argentina (UTN - Facultad Regional de Córdoba).


secciones técnicas Derecho y tecnologías

secciones técnicas

1. IntroducciónUna de las primeras etapas que se llevan acabo durante el proceso de desarrollo desoftware es la que se conoce como análisis delsistema de información, donde se realiza,entre otras tareas, la definición detallada delos requisitos del sistema con el objetivo deobtener un catálogo de requisitos que permi-ta definir con precisión el sistema que sepretende desarrollar. La participación de losusuarios en esta etapa es fundamental, puessus especificaciones sobre lo que esperan quesea el comportamiento del sistema serán lasque posteriormente guíen el proceso de desa-rrollo software.

Si bien los requisitos del sistema son, enmuchos desarrollos, fijados únicamente porlos usuarios en base a sus necesidades, en lossistemas que tratan datos de carácter perso-nal los requerimientos de éstos tienen que serconsiderados conjuntamente con las restric-ciones e imposiciones que exigen tanto la LeyOrgánica de Protección de Datos (LOPD)[1], como el Real Decreto que la desarrolla(RDLOPD) [2]. Por tanto, la libertad delcliente para decidir sobre la funcionalidad desu nuevo sistema encontrará en este casociertos límites.

Más aún, el RDLOPD incorpora una únicadisposición adicional sobre los productos desoftware, la cual estipula que deberá incorpo-rarse, en la descripción técnica de los produc-tos software destinados al tratamiento dedatos de carácter personal, el nivel de seguri-dad, básico, medio o alto, descrito en dichanorma, que permitan alcanzar. Esto implicaque, no sólo es necesario incorporar al siste-ma la funcionalidad necesaria para hacercumplir con las medidas de seguridad del nivelal que vaya dirigido, sino que, además, debequedar constancia en su descripción técnicade que el sistema permite el tratamiento dedatos personales cumpliendo con las medi-das de seguridad del nivel exigido impuestaspor el RDLOPD. Así, en el caso de unahipotética sanción al responsable del ficheropor parte de la Agencia Española de Protec-ción de Datos (AEPD) [3], en la que sedemostrara que la infracción cometida hasido originada por un desarrollo software queno cumple con los preceptos legales en mate-ria de protección de datos, éste podría actuarjudicialmente contra quien hubiera desarro-llado dicho sistema, dado que la descripcióntécnica del mismo establece que cumple con

los requisitos necesarios para tratar datospersonales a determinado nivel de seguridad.Por tanto, es imprescindible tener presente lasimplicaciones de la normativa vigente enmateria de protección de datos personales ala hora de desarrollar un sistema de informa-ción.

Este artículo analiza dichas implicaciones ymuestra como deben trasladarse al sistemade información. Para ello, realiza en primerlugar una descripción de los distintos nivelesde seguridad en que se categorizan los fiche-ros que contienen datos personales. Seguida-mente, analiza las implicaciones que las me-didas de seguridad conllevan en el desarrollode sistemas de información, en función decada uno de los tres niveles de seguridadexistentes. A continuación, se realizan otrasconsideraciones que deben tenerse en cuentaa la hora de diseñar un sistema de informa-ción, no derivadas directamente de las medi-das de seguridad pero sí de otros aspectos dela normativa. Finalmente, se ofrecen unasbreves conclusiones.

2. Niveles de seguridadLa protección de los datos de carácter perso-nal en los sistemas informáticos viene garan-tizada a través de las medidas de seguridadimpuestas por el RDLOPD. La aplicación delas medidas de seguridad se organiza en baseal concepto de nivel de seguridad, de formaque se establecen tres niveles de seguridad:básico, medio y alto. A los ficheros con datosde carácter personal en una organización lescorresponderá siempre uno de estos niveles deseguridad. A la hora de desarrollar un sistemade información es necesario tener claro quétipo de datos van a manejarse y cuál es lafinalidad de estos datos, pues en base a estainformación al fichero resultante le corres-ponderá un determinado nivel de seguridad y,por tanto, el sistema software deberá incor-porar las medidas de seguridad correspon-dientes. La tabla 1tabla 1tabla 1tabla 1tabla 1 ofrece una relación de los

niveles de seguridad que corresponden a cadafichero con datos personales en función de losdatos que contiene y la finalidad de los mis-mos, y constituye una síntesis del artículo 81del RDLOPD.

Una inspección detenida de la tabla 1tabla 1tabla 1tabla 1tabla 1 reflejaque, en principio, cualquier fichero con datosde carácter personal recibe la consideración defichero de nivel básico, y por tanto le corres-ponde adoptar las medidas de seguridad pro-pias de este nivel. Sin embargo, existen deter-minados tipos de datos que se consideranmás sensibles y que, por tanto, merecen unasmedidas de protección más elevadas.

En primer lugar, se encuentran aquellos datosque elevan el nivel de seguridad de un ficherohasta el nivel medio. Como puede verse, sonnumerosos los ficheros a los que les corres-ponde este nivel de seguridad, aunque gene-ralmente su descripción en la tabla permiteidentificarlos con facilidad. Quizás el tipo deficheros que pueden suscitar algún tipo deduda son aquellos que "ofrezcan una defini-ción de las características o de la personalidadde los ciudadanos y que permitan evaluardeterminados aspectos de la personalidad odel comportamiento de los mismos". A esterespecto, el Informe Jurídico 0590/2008 de laAEPD establece que se encuentran dentro dela categoría de este tipo de ficheros todosaquellos que contengan datos "a partir de loscuales puedan deducirse los hábitos, prefe-rencias, aficiones, actividades o posición eco-nómica de los afectados", o bien "datoscurriculares que incluyan información muydetallada sobre el sujeto que permitan deducirun perfil de estudios o de trabajador".

Y en segundo lugar, se encuentran aquellosficheros a los que les corresponde el nivel deseguridad alto. Estos ficheros son aquellosque contienen datos que se denominan espe-cialmente protegidos, recogidos en el artículo7 de la LOPD. Se trata de datos especialmente

La protección de datos personalesen el desarrollo de software

Edmundo Sáez PeñaJunta de Andalucía

< e d m u n d o . s a e z @ j u n t a d e a n d a l u c i a . e s >< e d m u n d o . s a e z @ j u n t a d e a n d a l u c i a . e s >< e d m u n d o . s a e z @ j u n t a d e a n d a l u c i a . e s >< e d m u n d o . s a e z @ j u n t a d e a n d a l u c i a . e s >< e d m u n d o . s a e z @ j u n t a d e a n d a l u c i a . e s >

Resumen: La Ley Orgánica de Protección de Datos de Carácter Personal y su Reglamento de desarrolloimponen una serie de restricciones y medidas de seguridad a los sistemas informáticos que traten datospersonales de forma que el desarrollo de un sistema de estas características debe necesariamenteobservar dicha normativa. A lo largo de este artículo se realiza un análisis de las implicaciones que lanormativa vigente en materia de protección de datos tiene en el desarrollo de software, así como de lasmedidas que dicho software debe implantar con objeto de cumplir con las exigencias legales.

Palabras clave: desarrollo de software, LOPD, protección de datos personales.


Derecho y tecnologías secciones técnicas

secciones técnicas

sensibles, sobre los cuales hay que extremar elcontrol pues su tratamiento no autorizadopodría suponer perjuicios importantes a losafectados. Estos datos son los relativos a laideología, afiliación sindical, religión, creen-cias, origen racial, salud o vida sexual. Portanto, en principio, cualquier fichero que in-cluyera datos de estas categorías debería con-siderarse un fichero de nivel alto. Aquí elproblema suele aparecer cuando no está clarosi un dato determinado se considera o noperteneciente a alguna de las categorías que loconvierten en dato especialmente protegido.En particular, los datos relativos a la saludsuelen ofrecer bastante confusión, motivopor el cual el RDLOPD incluye una definiciónespecífica de datos de carácter personal rela-cionados con la salud, configurándolos como"las informaciones concernientes a la saludpasada, presente y futura, física o mental, deun individuo. En particular, se considerandatos relacionados con la salud de las perso-nas los referidos a su porcentaje dediscapacidad y a su información genética".Aún así, son numerosos los informes jurídi-cos que la AEPD ha tenido que emitir paraaclarar situaciones relacionadas con este tipode datos, como por ej. el Informe Jurídico0445/2009, que viene a establecer que los testpsicotécnicos suponen el tratamiento de da-tos psicológicos, los cuales quedan encua-drados dentro de la categoría de datos desalud, o como el Informe Jurídico 0129/2005,que concluye que el mero hecho de ser o nofumador no puede considerarse dato relativo

a la salud, pues "debería considerarse datodirectamente vinculado con la salud aquelque reflejase, en relación con las sustanciasestupefacientes en general, su mero consu-mo. Sin embargo, en el caso del consumo dealcohol o tabaco el dato referido al meroconsumo, sin especificación de la cantidadconsumida, no sería en principio un datovinculado con la salud, revistiendo tal natu-raleza el dato que reflejase la cantidad consu-mida, en caso de que el mismo significase unconsumo abusivo".

No son los datos de salud los únicos quepresentan esta problemática, aunque sí losque la presentan más frecuentemente. Sinembargo, otros tipos de datos como la pro-fesión pueden convertirse en datos especial-mente protegidos en determinadas circuns-tancias, como la que analiza el Informe Jurí-dico 0044/2004 de la AEPD en la que unfichero que contiene el dato de profesión essusceptible de revelar, en algún momento, lascreencias de una persona, como ocurriría enel caso de que alguien desempeñara la profe-sión de sacerdote.

El citado informe, concluye que "en caso deque los datos (…) puedan revelar la ideolo-gía, afiliación sindical, religión o creencias delos afectados, los mismos tendrán en todocaso la condición de especialmente protegi-dos (…) Por todo ello, ha de concluirse queserá precisa la implantación sobre los ficherosque contengan datos profesionales de los

afectados entre los que pueda encontrarse elde sacerdote de las medidas de seguridad denivel alto".

La interpretación del carácter de dato espe-cialmente protegido puede resultar muy con-trovertida en algunas ocasiones, como laderivada del Informe Jurídico 0524/2009 de laAEPD, en el que se analiza el nivel de seguri-dad que procede aplicar a los ficheros quealmacenan datos relacionados con la activi-dad de asesoramiento fiscal. Concretamente,establece que la decisión de un contribuyentede efectuar un aporte a la Iglesia Católica ensu declaración de IRPF no revela necesaria-mente sus creencias, dado que "la contribu-ción puede traer causa de las relaciones per-sonales o familiares del sujeto o de su cono-cimiento de la obra llevada a cabo por laIglesia, denotando la marcación de la casillaúnicamente la preferencia del contribuyentepor una determinada obra social, sin que elloimplique necesariamente que aquél profesaunas determinadas creencias". Aunque laconclusión más llamativa del informe es larelacionada con el dato que revela el matri-monio entre personas del mismo sexo, afir-mando que "si hasta la Ley 13/2005, de 1 dejulio, por la que se modifica el Código Civilen materia de derecho a contraer matrimonio,los hechos relativos al matrimonio inscritosen el Registro Civil no se consideraban espe-cialmente protegidos, la misma conclusióndebe mantenerse con posterioridad a aquella.En consecuencia el tratamiento de este dato

Tabla 1. Niveles de seguridad de los ficheros con datos de carácter personal.

Nivel básico Nivel medio Nivel alto ● Cualquier fichero con datos de carácter

personal. Fichero con datos de ideología, afiliación sindical, religión, creencias, salud, origen racial o vida sexual cuando

1. Los datos se utilicen con la única finalidad de realizar una transferencia dineraria a las entidades de las que los afectados sean asociados o miembros.

2. Se trate de ficheros o tratamientos en los que de forma incidental o accesoria se contengan aquellos datos sin guardar relación con su finalidad.

● Ficheros o tratamientos que contengan datos relativos a la salud, referentes exclusivamente al grado de discapacidad o la simple declaración de la condición de discapacidad o invalidez del afectado, con motivo del cumplimiento de deberes públicos.

Ficheros relativos a la comisión de infracciones administrativas o penales. Ficheros de prestación de servicios de solvencia patrimonial y crédito. Ficheros de las Administraciones tributarias relacionados con el ejercicio de sus potestades tributarias. Ficheros de las entidades financieras para las finalidades relacionadas con la prestación de servicios financieros. Ficheros de las Entidades Gestoras y Servicios Comunes de la Seguridad Social relacionados con el ejercicio de sus competencias. Ficheros de las mutuas de accidentes de trabajo y enfermedades profesionales de la Seguridad Social relacionados con el ejercicio de sus competencias. Ficheros que ofrezcan una definición de las características o de la personalidad de los ciudadanos y que permitan evaluar determinados aspectos de la personalidad o del comportamiento de los mismos. Ficheros de los operadores de comunicaciones electrónicas, respecto de los datos de tráfico y localización.

Ficheros con datos sobre ideología,afiliación sindical, religión, creencias,origen racial, salud o vida sexual, cuandono proceda adoptar el nivel básico. Ficheros con datos recabados para fines policiales sin consentimiento de los afectados. Ficheros con datos derivados de actos de violencia de género.



secciones técnicas

no requiere la adopción de medidas de segu-ridad de nivel alto".

Además de los datos especialmente protegi-dos, existen otros tipos de datos que tambiénobligan a elevar el nivel de seguridad a altopara el fichero que los contenga, como son losdatos recabados por las Fuerzas y Cuerpos deSeguridad para fines policiales sin consenti-miento de los afectados, o aquéllos derivadosde actos relacionados con la violencia degénero, por el evidente riesgo que para laseguridad de las víctimas supondría su reve-lación no autorizada.

No obstante, el RDLOPD ha venido a rebajarel nivel de seguridad para los ficheros quecontengan ciertos datos en determinadas cir-cunstancias, con objeto de simplificar la ges-tión de la seguridad en determinados ficherosmuy habituales en las organizaciones. Así, losficheros que contengan datos especialmenteprotegidos se considerarán de nivel básico endos circunstancias:a) Cuando los datos se utilicen con la únicafinalidad de realizar una transferencia dinerariaa las entidades de las que los afectados seanasociados o miembros. Éste es el caso de losficheros de nóminas, en el que el dato deafiliación sindical se emplea, únicamente, paradeducir al empleado el importe de la cuotasindical y transferir dicho importe al sindicatodel que éste forma parte.

b) Cuando se trate de ficheros o tratamientosen los que, de forma incidental o accesoria, secontengan aquellos datos sin guardar rela-ción con su finalidad. Éste es el caso de losficheros de control de presencia, pues suelenser ficheros mixtos que, en su parte automa-tizada, almacenan datos no especialmenteprotegidos sobre la ausencia de los trabaja-dores, pero que sin embargo, en la parte noautomatizada, incluyen copias de losjustificantes de ausencia que, en ocasiones,son partes de asistencia médica en los que serefleja la patología por la que el trabajador hasido asistido.

Por otra parte, también se considerarán denivel básico los ficheros que contengan datosrelativos a la salud, referentes exclusivamenteal grado de discapacidad o la simple declara-ción de la condición de discapacidad o invali-dez del afectado, con motivo del cumplimien-to de deberes públicos. Para clarificar esteprecepto, la AEPD ha dictado, entre otros, elInforme Jurídico 0179/2008, que estableceque "serán únicamente exigibles las medidasde seguridad de nivel básico en aquellos fiche-ros que contengan uno o varios de los si-guientes datos:1. La mera indicación del grado o porcentajede minusvalía del afectado o de los miembrosde su unidad familiar a los efectos previstospara el cálculo de las retenciones en la legis-lación reguladora del IRPF.

2. La indicación del dato "apto" o "no apto"de un trabajador a los efectos previstos en laLey de Prevención de Riesgos Laborales.3. Los datos relacionados con las obligacio-nes impuestas al empresario por la legislaciónvigente en materia de seguridad social que selimiten a señalar únicamente la existencia o node enfermedad común, enfermedad profesio-nal o accidente laboral o no laboral, así comola incapacidad laboral del trabajador".

3. Implicaciones de las medidasde seguridadLas medidas de seguridad de implantaciónobligatoria en los sistemas que traten datosde carácter personal pretenden garantizar laconfidencialidad, integridad y disponibilidadde éstos. Su aplicación se realiza en funcióndel nivel de seguridad que corresponde alfichero, pero de forma acumulativa. Esto es,a un fichero de nivel básico corresponderá laaplicación de las medidas de seguridad de nivelbásico, pero a un fichero de nivel mediocorresponderá la aplicación de las medidas denivel básico y de nivel medio. Finalmente, a losficheros de nivel alto les corresponde la apli-cación de las medidas de nivel básico, medioy alto. Por otra parte, las medidas de seguri-dad tienen la condición de mínimos exigibles,por lo que nada impide que se adopten medi-das más rigurosas, siempre y cuando se ga-rantice la adopción de las medidas exigidas enel RDLOPD.

Para la efectiva implantación de estas medi-das es preciso que los sistemas de informa-ción que tratan datos de carácter personalhayan sido diseñados incorporando comorequisitos, además de los propios de la apli-cación, aquellos que permitirán el cumpli-miento de las citadas medidas de seguridad.Si bien no todas las medidas de seguridad sonsusceptibles de ser aplicadas en el momentodel desarrollo del sistema de información,algunas de ellas solo alcanzarán toda suefectividad mediante su consideración en estafase.

A continuación, se relacionan las medidascuya incorporación al sistema como requisi-to durante su desarrollo es necesario, o almenos recomendable. Las medidas se presen-tan organizadas en base al nivel de seguridadque corresponde.

3.1. Nivel básicoLas medidas de seguridad aplicables a losficheros de nivel básico se relacionan en losartículos 89 a 94 del RDLOPD. En relación alcontrol de acceso, es necesario tener en cuentalas siguientes consideraciones:1 .1 .1 .1 .1 . Los usuarios deberán poder acce-Los usuarios deberán poder acce-Los usuarios deberán poder acce-Los usuarios deberán poder acce-Los usuarios deberán poder acce-der únicamente a los recursos necesa-der únicamente a los recursos necesa-der únicamente a los recursos necesa-der únicamente a los recursos necesa-der únicamente a los recursos necesa-rios para el desarrollo de sus funcio-rios para el desarrollo de sus funcio-rios para el desarrollo de sus funcio-rios para el desarrollo de sus funcio-rios para el desarrollo de sus funcio-nes. Deberán establecerse mecanis-nes. Deberán establecerse mecanis-nes. Deberán establecerse mecanis-nes. Deberán establecerse mecanis-nes. Deberán establecerse mecanis-mos para evitar que un usuario puedamos para evitar que un usuario puedamos para evitar que un usuario puedamos para evitar que un usuario puedamos para evitar que un usuario puedaacceder a recursos con derechos dis-acceder a recursos con derechos dis-acceder a recursos con derechos dis-acceder a recursos con derechos dis-acceder a recursos con derechos dis-

tintos de los autorizadostintos de los autorizadostintos de los autorizadostintos de los autorizadostintos de los autorizados. Será precisoestablecer perfiles en la aplicación de formaque cada usuario únicamente tenga acceso aaquella información que le vaya a ser necesa-ria para el desarrollo de sus funciones. Porejemplo, los operadores del sistema infor-mático de un hospital, que asignan citasmédicas a los pacientes, no necesitan teneracceso a la historia clínica de éstos, a diferen-cia de los facultativos. Por ello, la aplicacióndebe estar diseñada de forma que a cadausuario le corresponda un perfil determina-do, de manera que sea imposible el acceso aaquellos datos de carácter personal que notengan relación con el perfil del puesto desem-peñado.2 .2 .2 .2 .2 . Exclusivamente el personal auto-Exclusivamente el personal auto-Exclusivamente el personal auto-Exclusivamente el personal auto-Exclusivamente el personal auto-rizado podrá conceder, alterar o anu-rizado podrá conceder, alterar o anu-rizado podrá conceder, alterar o anu-rizado podrá conceder, alterar o anu-rizado podrá conceder, alterar o anu-lar el acceso autorizado sobre loslar el acceso autorizado sobre loslar el acceso autorizado sobre loslar el acceso autorizado sobre loslar el acceso autorizado sobre losrecursosrecursosrecursosrecursosrecursos. Deberán existir usuarios con elperfil de administradores que sean los únicoshabilitados para modificar los permisos deacceso del resto de los usuarios. Los usua-rios de la aplicación que no tengan este perfilno podrán modificar los accesos autorizadosde los demás usuarios.

Deberá existir una relación actualiza-Deberá existir una relación actualiza-Deberá existir una relación actualiza-Deberá existir una relación actualiza-Deberá existir una relación actualiza-da de usuarios y perfiles de cada uno,da de usuarios y perfiles de cada uno,da de usuarios y perfiles de cada uno,da de usuarios y perfiles de cada uno,da de usuarios y perfiles de cada uno,así como de sus accesos autorizadosasí como de sus accesos autorizadosasí como de sus accesos autorizadosasí como de sus accesos autorizadosasí como de sus accesos autorizados.Se trata de una imposición de la normativaque, si bien puede ser perfectamente alcanza-da al margen del propio sistema informático,facilitaría enormemente su cumplimiento porparte del responsable del fichero que la propiaaplicación pudiera generar dicha relación, porlo que su inclusión como requisito es unaopción a tener en cuenta.

En lo que respecta a la identificación y auten-ticación de los usuarios, deben considerarselos siguientes aspectos:3 .3 .3 .3 .3 . Se establecerá un mecanismo queSe establecerá un mecanismo queSe establecerá un mecanismo queSe establecerá un mecanismo queSe establecerá un mecanismo quepermita la identificación de formapermita la identificación de formapermita la identificación de formapermita la identificación de formapermita la identificación de formainequívoca y personalizada de todoinequívoca y personalizada de todoinequívoca y personalizada de todoinequívoca y personalizada de todoinequívoca y personalizada de todoaquel usuario que intente acceder alaquel usuario que intente acceder alaquel usuario que intente acceder alaquel usuario que intente acceder alaquel usuario que intente acceder alsistema de información y la verifica-sistema de información y la verifica-sistema de información y la verifica-sistema de información y la verifica-sistema de información y la verifica-ción de que está autorizadoción de que está autorizadoción de que está autorizadoción de que está autorizadoción de que está autorizado. Las cuen-tas genéricas están taxativamente prohibidas,dado que posibilitarían el acceso de unamultiplicidad de personas al sistema sin quepuedan quedar identificadas de forma inequí-voca y personalizada. El Informe Jurídico0021/2009 de la AEPD apunta en este sentidoante la consulta de si es posible la utilizaciónde la misma cuenta por parte de varias perso-nas para el acceso a datos personales en unaAdministración pública. La plena consecu-ción de esta medida no es responsabilidadexclusiva de la aplicación, puesto que nadaimpide al administrador de la misma la crea-ción de cuentas cuyas credenciales de accesosean posteriormente distribuidas a variaspersonas. Sin embargo, sí es posible realizarun diseño del módulo de gestión de usuariosque minimice en lo posible estas acciones. Porejemplo, previo a la creación de un nuevo



secciones técnicas

usuario en el sistema, podría mostrarse unmensaje indicando la prohibición de crearcuentas genéricas. Además, podría incluirsecomo dato asociado a la cuenta de usuarioel nombre y apellidos de la persona que loutilizará, de forma que fuera requisito indis-pensable completar esta información paratramitar el alta del nuevo usuario. Menciónespecial merece la cuenta de administrador delsistema, pues conceptualmente se trata deuna cuenta genérica que, además, mantienelos máximos privilegios. Si bien no se tieneconstancia de un dictamen jurídico a esterespecto, parece evidente que una cuenta contales características no debería ser permitida,pues a través de la misma se podría acceder atodos los datos del sistema sin que pudieradeterminarse qué persona en concreto harealizado el acceso. Por tanto, y salvo que sepudiera garantizar que en cada instante una ysólo una persona va a contar con las creden-ciales de administrador, lo recomendable se-ría no contar con cuentas de administracióndel sistema, sino con perfiles de administra-dor que fueran asignados a los usuariosindividuales del sistema. De esa forma po-drían existir varias cuentas de administrador,garantizando que en cada acceso al sistema eltitular de la cuenta queda perfectamente iden-tificado de forma inequívoca.4 .4 .4 .4 .4 . Las contraseñas deberán ser cam-Las contraseñas deberán ser cam-Las contraseñas deberán ser cam-Las contraseñas deberán ser cam-Las contraseñas deberán ser cam-biadas con una periodicidad no supe-biadas con una periodicidad no supe-biadas con una periodicidad no supe-biadas con una periodicidad no supe-biadas con una periodicidad no supe-rior a un añorior a un añorior a un añorior a un añorior a un año. Deberá existir un mecanismoen el sistema que informe al usuario de que sucontraseña está próxima a caducar, impidién-dole el acceso una vez que haya transcurridomás de un año sin que la contraseña haya sidocambiada.

Las contraseñas se almacenarán deLas contraseñas se almacenarán deLas contraseñas se almacenarán deLas contraseñas se almacenarán deLas contraseñas se almacenarán deforma ininteligibleforma ininteligibleforma ininteligibleforma ininteligibleforma ininteligible . El procedimiento dealmacenamiento de las contraseñas debe ga-rantizar que no sea posible, de ninguna mane-ra, la recuperación de éstas. Para conseguirlo,el procedimiento más sencillo es el cifrado delas mismas con algún algoritmo que no per-mita reconstruir la contraseña original, comoMD5 o SHA-1. De esta forma se consigueque ningún atacante que consiguiera teneracceso a las contraseñas cifradas pudieradescifrarlas para suplantar posteriormente alos usuarios mediante la utilización de suscredenciales.

Existirá un procedimiento de asigna-Existirá un procedimiento de asigna-Existirá un procedimiento de asigna-Existirá un procedimiento de asigna-Existirá un procedimiento de asigna-ción, distribución y almacenamientoción, distribución y almacenamientoción, distribución y almacenamientoción, distribución y almacenamientoción, distribución y almacenamientode contraseñas que garantice sude contraseñas que garantice sude contraseñas que garantice sude contraseñas que garantice sude contraseñas que garantice suconfidencialidad e integridadconfidencialidad e integridadconfidencialidad e integridadconfidencialidad e integridadconfidencialidad e integridad. Se deberágarantizar que sólo el usuario conoce sucontraseña de acceso al sistema. Para ello, esrecomendable que la aplicación ofrezca alusuario la posibilidad de cambiar su contra-seña, sin que sea necesaria la intervención deningún administrador u operador. Más aún,puesto que la primera contraseña de un usua-rio en el sistema suele ser fijada por el admi-nistrador, sería conveniente dotar al sistema

de la posibilidad de forzar al usuario el cam-bio de contraseña en el primer acceso alsistema.

Finalmente, las medidas de seguridad de nivelbásico contemplan actuaciones en materia decopias de respaldo. Sería interesante conside-rar la siguiente:5 .5 .5 .5 .5 . Deberá realizarse una copia de res-Deberá realizarse una copia de res-Deberá realizarse una copia de res-Deberá realizarse una copia de res-Deberá realizarse una copia de res-paldo semanal como mínimo, salvopaldo semanal como mínimo, salvopaldo semanal como mínimo, salvopaldo semanal como mínimo, salvopaldo semanal como mínimo, salvoque en dicho periodo no se hubieraque en dicho periodo no se hubieraque en dicho periodo no se hubieraque en dicho periodo no se hubieraque en dicho periodo no se hubieraproducido ninguna actualización deproducido ninguna actualización deproducido ninguna actualización deproducido ninguna actualización deproducido ninguna actualización delos datoslos datoslos datoslos datoslos datos. Por lo general, para alcanzar estamedida de forma satisfactoria no es necesarioplantearla durante el desarrollo del sistema deinformación. Lo habitual es disponer de unapolítica de copia de seguridad global que seencargue de realizar la salvaguarda de toda lainformación corporativa. Sin embargo, esconveniente tener en cuenta esta medida parael caso en que se desarrolle un sistema deinformación para una organización en la queno exista definida una política de copia deseguridad previa. En este caso, podríaincorporársele la funcionalidad consistenteen la realización de una copia de seguridadsemanal de los datos de forma automatiza-da, liberando así al administrador del sistemade la tarea de realizar la copia de seguridadmanualmente cada semana, o de tener quedefinir y poner en marcha una política de copiade seguridad global para todos los activos deinformación, lo cual, por otra parte, sería lorecomendable.

3.2. Nivel medioLas medidas de seguridad aplicables a losficheros de nivel medio se relacionan en losartículos 95 a 100 del RDLOPD. La únicaconsideración aplicable al desarrollo de siste-mas de información que traten datos perso-nales almacenados en ficheros de nivel medioestá relacionada con la identificación y auten-ticación de los usuarios, y es la siguiente:6 .6 .6 .6 .6 . Se establecerá un mecanismo queSe establecerá un mecanismo queSe establecerá un mecanismo queSe establecerá un mecanismo queSe establecerá un mecanismo quelimite la posibilidad de intentar reite-limite la posibilidad de intentar reite-limite la posibilidad de intentar reite-limite la posibilidad de intentar reite-limite la posibilidad de intentar reite-radamente el acceso no autorizado alradamente el acceso no autorizado alradamente el acceso no autorizado alradamente el acceso no autorizado alradamente el acceso no autorizado alsistema de informaciónsistema de informaciónsistema de informaciónsistema de informaciónsistema de información. Deberáimplementarse un mecanismo que, ante unnúmero prefijado de intentos fallidos de acce-so al sistema, bloquee la cuenta de usuario.Para el desbloqueo de la misma, el usuariodeberá personarse ante el administrador delsistema, que comprobará su identidad y lascausas que originaron el bloqueo.

3.3. Nivel altoLas medidas de seguridad aplicables a losficheros de nivel alto se relacionan en losartículos 101 a 104 del RDLOPD. El controlde acceso en los sistemas de información quetratan datos personales almacenados en fi-cheros de nivel alto impone la siguiente con-sideración:7 .7 .7 .7 .7 . Existirá un registro de acceso queExistirá un registro de acceso queExistirá un registro de acceso queExistirá un registro de acceso queExistirá un registro de acceso quealmacenará, como mínimo, la identi-almacenará, como mínimo, la identi-almacenará, como mínimo, la identi-almacenará, como mínimo, la identi-almacenará, como mínimo, la identi-ficación del usuario, la fecha y horaficación del usuario, la fecha y horaficación del usuario, la fecha y horaficación del usuario, la fecha y horaficación del usuario, la fecha y hora

del acceso, el fichero accedido, el tipodel acceso, el fichero accedido, el tipodel acceso, el fichero accedido, el tipodel acceso, el fichero accedido, el tipodel acceso, el fichero accedido, el tipode acceso y si ha sido autorizado ode acceso y si ha sido autorizado ode acceso y si ha sido autorizado ode acceso y si ha sido autorizado ode acceso y si ha sido autorizado odenegado. En caso de que el accesodenegado. En caso de que el accesodenegado. En caso de que el accesodenegado. En caso de que el accesodenegado. En caso de que el accesohaya sido autorizado, será precisohaya sido autorizado, será precisohaya sido autorizado, será precisohaya sido autorizado, será precisohaya sido autorizado, será precisoguardar la información que permitaguardar la información que permitaguardar la información que permitaguardar la información que permitaguardar la información que permitaidentificar el registro accedido. Elidentificar el registro accedido. Elidentificar el registro accedido. Elidentificar el registro accedido. Elidentificar el registro accedido. Elperiodo mínimo de conservación deperiodo mínimo de conservación deperiodo mínimo de conservación deperiodo mínimo de conservación deperiodo mínimo de conservación delos datos registrados será de dos añoslos datos registrados será de dos añoslos datos registrados será de dos añoslos datos registrados será de dos añoslos datos registrados será de dos años.Se trata de una medida que influye de manerasignificativa en el desarrollo del sistema deinformación, pues será preciso crear comoestructura en la base de datos el registro deacceso como tal, y diseñar todas las transac-ciones del sistema que operen sobre datospersonales de forma que dejen constancia dela operación realizada en el registro. En elcaso de consultas masivas de información,teniendo en cuenta que deben almacenarse losdatos que permitan identificar los registrosaccedidos, habrá que tener en cuenta el posibleimpacto sobre el rendimiento que pudieratener esta medida.

En relación a las comunicaciones electróni-cas, es preciso tener en cuenta lo siguiente:8 .8 .8 .8 .8 . La transmisión de datos de carác-La transmisión de datos de carác-La transmisión de datos de carác-La transmisión de datos de carác-La transmisión de datos de carác-ter personal a través de redes públicaster personal a través de redes públicaster personal a través de redes públicaster personal a través de redes públicaster personal a través de redes públicaso redes inalámbricas de comunicacio-o redes inalámbricas de comunicacio-o redes inalámbricas de comunicacio-o redes inalámbricas de comunicacio-o redes inalámbricas de comunicacio-nes electrónicas se realizará cifrandones electrónicas se realizará cifrandones electrónicas se realizará cifrandones electrónicas se realizará cifrandones electrónicas se realizará cifrandodichos datos, o bien utilizando cual-dichos datos, o bien utilizando cual-dichos datos, o bien utilizando cual-dichos datos, o bien utilizando cual-dichos datos, o bien utilizando cual-quier otro mecanismo que garanticequier otro mecanismo que garanticequier otro mecanismo que garanticequier otro mecanismo que garanticequier otro mecanismo que garanticeque la información no sea inteligibleque la información no sea inteligibleque la información no sea inteligibleque la información no sea inteligibleque la información no sea inteligibleni manipulada por tercerosni manipulada por tercerosni manipulada por tercerosni manipulada por tercerosni manipulada por terceros. Esta exigen-cia viene a imponer el uso de protocoloscifrados (como puede ser HTTPS en el casode aplicaciones web) para las aplicaciones quetransmitan datos a través de redes inseguras.La elección del mecanismo de cifrado no estema baladí, como se desprende del Informejurídico 0494/2009 de la AEPD, que estableceque "no sólo es necesario cifrar, sino cifrar deforma que la información no sea inteligible nimanipulada por terceros. Sin esta últimacondición, no se cumplirá lo estipulado en elcitado artículo 104. Esto implica (...) que elsistema de cifrado a emplear no esté compro-metido, es decir, que no se conozca forma deromperlo. (...) tanto el cifrado que ofrecen losproductos que generan archivos PDF o elrealizado por WinZip tienen vulnerabilidadesconocidas y se disponen de herramientas delibre distribución que aprovechan dichas vul-nerabilidades. Más concretamente, no sólo sepueden obtener en Internet fácilmente utilida-des que rompen las protecciones de los archi-vos PDF o ZIP, sino que el propio algoritmoen el que descansa la cifra de documentosPDF, el algoritmo RC4, es manifiestamentevulnerable. Aunque para el uso particularpudieran considerarse adecuadas, no así parael intercambio de información con las garan-tías que se precisan en el Reglamento".

Finalmente, en relación con la gestión y distri-bución de soportes, es conveniente considerarlas siguientes medidas:9 .9 .9 .9 .9 . La distribución de los soportesLa distribución de los soportesLa distribución de los soportesLa distribución de los soportesLa distribución de los soportes



secciones técnicas

que contengan datos de carácter per-que contengan datos de carácter per-que contengan datos de carácter per-que contengan datos de carácter per-que contengan datos de carácter per-sonal se realizará cifrando dichos da-sonal se realizará cifrando dichos da-sonal se realizará cifrando dichos da-sonal se realizará cifrando dichos da-sonal se realizará cifrando dichos da-tos o bien utilizando otro mecanismotos o bien utilizando otro mecanismotos o bien utilizando otro mecanismotos o bien utilizando otro mecanismotos o bien utilizando otro mecanismoque garantice que dicha informaciónque garantice que dicha informaciónque garantice que dicha informaciónque garantice que dicha informaciónque garantice que dicha informaciónno sea accesible o manipulada duran-no sea accesible o manipulada duran-no sea accesible o manipulada duran-no sea accesible o manipulada duran-no sea accesible o manipulada duran-te su transportete su transportete su transportete su transportete su transporte. Si el sistema de informa-ción ofrece la posibilidad de exportar datospara su almacenamiento en soportes, seríaconveniente dotarlo de una opción que permi-ta realizar la exportación de datos de formacifrada, evitando así tener que efectuar unposterior procesamiento para el cifrado dedichos datos. En el proceso de cifrado deberátenerse en cuenta lo anteriormente indicadopor el Informe jurídico 0494/2009 de la AEPDrespecto a la seguridad del algoritmo de cifra-do escogido. Es más, otorgando a la aplica-ción la funcionalidad de exportación cifradade datos se elimina la posibilidad de que elresponsable del fichero utilice mecanismos decifrado inseguros.10. Se cifrarán los datos que conten-10. Se cifrarán los datos que conten-10. Se cifrarán los datos que conten-10. Se cifrarán los datos que conten-10. Se cifrarán los datos que conten-gan los dispositivos portátiles cuan-gan los dispositivos portátiles cuan-gan los dispositivos portátiles cuan-gan los dispositivos portátiles cuan-gan los dispositivos portátiles cuan-do éstos se encuentren fuera de lasdo éstos se encuentren fuera de lasdo éstos se encuentren fuera de lasdo éstos se encuentren fuera de lasdo éstos se encuentren fuera de lasinstalaciones que están bajo controlinstalaciones que están bajo controlinstalaciones que están bajo controlinstalaciones que están bajo controlinstalaciones que están bajo controldel responsable del ficherodel responsable del ficherodel responsable del ficherodel responsable del ficherodel responsable del fichero. Si se prevéque la aplicación y los datos personales quemaneja pudieran ser instalados en un dispo-sitivo portátil, sería una opción a tener encuenta la creación de una versión de la mismaque fuera capaz de trabajar con la base dedatos cifrada, de forma que en caso de roboo pérdida del dispositivo no pudiera accedersea los datos. Al igual que el punto anterior,esta medida puede conseguirse fácilmente aposteriori, sin necesidad de incorporarla en elpropio sistema de información. No obstante,es recomendable considerar su inclusión paraevitar, nuevamente, que el responsable delfichero utilice mecanismos de cifrado insegu-ros del dispositivo portátil.

4. Otras consideracionesSi bien las medidas de seguridad condicionansensiblemente el desarrollo de un sistema deinformación, hay otros aspectos de la norma-tiva que también tienen una influencia decisi-va sobre el proceso de desarrollo. A continua-ción se analizan los más importantes.

4.1. Recogida de datos mediante for-mularios webLa LOPD exige, por norma general, el consen-timiento inequívoco del afectado para el tra-tamiento de sus datos de carácter personal,salvo en una serie de excepciones que seencuentran reguladas en el artículo 6.2 de lanorma. El consentimiento deberá ser libre(obtenido sin intervención de vicio alguno delconsentimiento), específico (referido a unadeterminada operación de tratamiento y parauna finalidad determinada, explícita y legíti-ma del responsable del fichero), informado(el usuario debe conocer, antes de su trata-miento, la existencia y las finalidades para lasque se recogen los datos) e inequívoco (debeexistir expresamente una acción u omisión

que implique la existencia del consentimiento;no se admite el consentimiento presunto). Elartículo 5 de la LOPD es el que establece lainformación que ha de facilitarse al afectadopara que el consentimiento se pueda conside-rar informado y, por tanto, válido.

Cuando el propio afectado facilita sus datospersonales a una aplicación web a través de unformulario deben tenerse en cuenta las consi-deraciones del Informe jurídico 0093/2008 dela AEPD, que establece lo siguiente: "Encuanto al consentimiento informado, éstehabrá de recabarse de tal forma que resulteimposible la introducción de dato alguno sinque previamente el afectado haya conocido laadvertencia que contenga las menciones a lasque nos hemos referido, pudiendo servir comoprueba del consentimiento la acreditación deque el programa impide introducir los datossin antes haber aceptado el aviso legal al quehemos hecho referencia. Todo ello tiene porobjeto asegurar que el consentimiento de losafectados sea efectivamente específico e in-equívoco tal y como exige la Ley". Esto es, noserá suficiente con mostrar una cláusula alpie del formulario informando al usuario delos preceptos que establece el artículo 5 de laLOPD y solicitando el consentimiento para eltratamiento de sus datos, sino que deberáarticularse un mecanismo que impida al usua-rio la introducción de datos en el formulariohasta que éste haya aceptado expresamenteque es consciente de que se van a recoger susdatos, a qué finalidad se van a destinar, losderechos que le amparan, y que consiente enel tratamiento.

4.2. Cancelación de datosEs práctica habitual por parte de las organi-zaciones la conservación indefinida de losdatos a modo de histórico o para la realiza-ción de estudios estadísticos o de mercado.Sin embargo, cuando estos datos son decarácter personal, esta política debe ser revi-sada, pues el mantenimiento de los mismosse encuentra regulado por la normativa deprotección de datos. En particular, el artículo4.5 de la LOPD establece que "Los datos decarácter personal serán cancelados cuandohayan dejado de ser necesarios o pertinentespara la finalidad para la cual hubieran sidorecabados o registrados". El concepto de can-celación se clarifica en el artículo 16.3 de laLOPD, que determina que "La cancelación darálugar al bloqueo de los datos, conservándoseúnicamente a disposición de las Administracio-nes públicas, Jueces y Tribunales, para la aten-ción de las posibles responsabilidades nacidasdel tratamiento, durante el plazo de prescripciónde éstas. Cumplido el citado plazo deberáprocederse a la supresión".

Por tanto, una vez que los datos hayan dejadode ser necesarios para la finalidad que originósu recogida, el sistema debe ofrecer la posibi-lidad de cancelarlos, lo que implica su blo-

queo. El Informe jurídico 0127/2006 de laAEPD viene a aclarar el significado del térmi-no bloqueo, de la siguiente forma: "en cuantoal modo de llevar a cabo el bloqueo, deberáefectuarse de forma tal que no sea posible elacceso a los datos por parte del personal quetuviera habitualmente tal acceso, por ejem-plo, el personal que preste sus servicios en elcentro consultante, limitándose el acceso auna persona con la máxima responsabilidady en virtud de la existencia de un requerimientojudicial o administrativo a tal efecto. De estemodo, pese a permanecer el tratamiento delos datos, el acceso a los mismos quedaríaenteramente restringido a las personas a lasque se ha hecho referencia".

Es decir, el sistema debe estar dotado con unafuncionalidad que permita la cancelación dedatos mediante su bloqueo. De esta forma,únicamente aquellos usuarios que tenganasignado un perfil de máxima responsabili-dad deberían poder acceder a los mismos, nosiendo posible el acceso para el resto deusuarios que, hasta el momento de la cance-lación, podían acceder a los datos sin másrestricciones que las impuestas por las medi-das de seguridad.

Asimismo, el sistema debe permitir la supre-sión definitiva de los datos una vez que elplazo de prescripción de las responsabilidadesnacidas del tratamiento se haya cumplido. Ladeterminación del citado plazo de prescrip-ción es una cuestión puramente normativa,que queda fuera del ámbito de este trabajo.No obstante, y a modo de ejemplo, el citadoInforme jurídico 0127/2006 cita algunos deestos plazos: "podría considerarse que el blo-queo habrá de efectuarse durante los plazosde prescripción de las acciones derivadas de larelación jurídica que funda el tratamiento, enlos términos previstos por la legislación civilo mercantil que resulte de aplicación, asícomo el plazo de cuatro años de prescripciónde las deudas tributarias, en cuanto los datospuedan revestir trascendencia desde el puntode vista tributario (habida cuenta de la obli-gación de conservación que impone el artícu-lo 111 de la Ley General Tributaria y el plazolegal de prescripción de cuatro años previstoen el artículo 24 de la Ley de Derechos yGarantías de los Contribuyentes) (…) o elplazo de prescripción de tres años, previsto enel artículo 47.1 de la propia Ley Orgánica 15/1999 en relación con las conductas constitu-tivas de infracción muy grave".

En caso de que la organización desee conser-var los datos una vez que hayan dejado de sernecesarios para la finalidad que motivó surecogida, y transcurrido el plazo de prescrip-ción de las responsabilidades nacidas del tra-tamiento, sólo podrá conservarlos previa di-sociación de los mismos, salvo la excepciónprevista en el artículo 9 del RDLOPD, consis-tiendo el procedimiento de disociación en



secciones técnicas

"todo tratamiento de datos personales demodo que la información que se obtenga nopueda asociarse a persona identificada o iden-tificable".

4.3. Pruebas con datos realesUna etapa de vital importancia en el desarro-llo de software es la que corresponde a larealización de pruebas para verificar el correc-to funcionamiento del sistema desarrollado.Los sistemas que gestionan datos de carácterpersonal no son distintos al resto de lossistemas, por lo que para garantizar la correc-ción de dichos sistemas antes de su puesta enproducción es necesario realizar las pruebaspertinentes.

Sin embargo, la realización de pruebas enestos sistemas se encuentra limitada por elartículo 94.4 del RDLOPD, que establece que"Las pruebas anteriores a la implantación omodificación de los sistemas de informaciónque traten ficheros con datos de carácterpersonal no se realizarán con datos reales,salvo que se asegure el nivel de seguridadcorrespondiente al tratamiento realizado (…).Si está previsto realizar pruebas con datosreales deberá haberse realizado una copia deseguridad". Es decir, que en la realización depruebas deberán emplearse datos ficticiospreferentemente. Si las características del sis-tema desarrollado exigen la realización depruebas con datos reales, la normativa impo-ne, por una parte, que se asegure el nivel deseguridad correspondiente (acceso a los da-tos por parte del personal autorizado única-mente, transferencia cifrada de informaciónen redes públicas, etc.), y, por otra parte, larealización de una copia de seguridad previaa la ejecución de las pruebas.

5. ConclusionesLa normativa de protección de datos de carác-ter personal ha venido a introducir una seriede consideraciones en el desarrollo de siste-mas software, en forma de requisitos funcio-nales impuestos al sistema, o bien en formade limitaciones a los requerimientos solicita-dos por los usuarios. En este artículo se haefectuado una revisión de los distintos niveles

de seguridad definidos en la norma, así comolas implicaciones que sobre el desarrollo desistemas de información que gestionan datosde carácter personal tienen las medidas deseguridad impuestas por dicha norma.

Si bien, la categorización del nivel de seguri-dad que corresponde a cada fichero está enprincipio bien definida en el RDLOPD, esnecesario poner en común los preceptos de taldisposición con las aclaraciones e interpreta-ciones que la AEPD realiza, contribuyendoasí a aclarar algunas dudas que pueden surgirfácilmente cuando se pretende poner en mar-cha un sistema para la gestión de datospersonales.

Por otra parte, ha quedado establecido quepara el cumplimiento de las medidas de segu-ridad impuestas por la normativa es necesarioincorporar a los sistemas de información,desde su desarrollo, la funcionalidad que lespermita alcanzar el nivel de seguridad al queestán obligados. En función del nivel de segu-ridad, las medidas de seguridad a implantarsupondrán un impacto mayor o menor parael sistema. En concreto, las medidas impues-tas por el nivel de seguridad básico, consisten-tes principalmente en medidas para el controlde acceso, identificación y autenticación delos usuarios, son, en buena parte, medidasque vienen aplicándose habitualmente en eldesarrollo de nuevos sistemas de informa-ción, y que suponen un bajo impacto en elrendimiento del sistema. Sin embargo, lasmedidas impuestas por el nivel de seguridadalto, tales como el registro de accesos o elcifrado de la información en la transferenciaa través de redes inseguras, pueden suponerun impacto mayor en el rendimiento, por loque deben estudiarse con mayor detenimiento.Finalmente, no sólo es necesario tener encuenta las medidas de seguridad impuestaspor el RDLOPD en el desarrollo de sistemasde información. La propia LOPD contienepreceptos que, para ser alcanzados, debenincorporarse a los sistemas durante su desa-rrollo, como los relativos a la obtención dedatos personales desde formularios web o losque afectan a la cancelación de datos.

¿Estudiante de Ingeniería Técnica o Ingeniería Superior de Informática?Puedes aprovecharte de las condiciones especiales para hacerte

socio estudiante de ATIy gozar de los servicios que te ofrece nuestra asociación,

según el acuerdo firmado con la

Asociación RITSI

Infórmate en <www.ati.es>o ponte en contacto con la Secretaría de ATI Madrid

Referencias

[1] BOE. Ley Orgánica 15/1999, de 13 de diciem-bre, de Protección de Datos de Carácter Persona,<http://www.boe.es/boe/dias/1999/12/14/pdfs/A43088-43099.pdf>.[2] BOE. Real Decreto 1720/2007, de 21 dediciembre, por el que se aprueba el Reglamento dedesarrollo de la Ley Orgánica 15/1999, de 13 dediciembre, de protección de datos de carácterpersonal, <http://www.boe.es/boe/dias/2008/01/19/pdfs/A04103-04136.pdf>.[3] AEPD. Agencia Española de Protección deDatos, <http://www.agpd.es>.

Sin duda, el conocimiento de la normativa enmateria de protección de datos personales esun deber que todo aquel que asuma la respon-sabilidad sobre el desarrollo de un sistema deinformación para el tratamiento de datospersonales debe tener presente, de cara a con-seguir sistemas cuyo funcionamiento seadecue a las exigencias legales que afectan aeste tipo de software.


secciones técnicas Enseñanza Universitaria de la Informática

secciones técnicas

1.IntroducciónCompiladores es una de las asignaturas másdifíciles de las titulaciones de Informática.Aparte de basarse en la teoría de lenguajesformales, cuyo grado de abstracción añadealgo de complejidad, la parte práctica sueleser bastante compleja y costosa. Esta prác-tica suele durar la mayor parte del cursorequiriendo cierto grado de planificación ycontinuidad en el trabajo. Por otro lado ocu-rre que las herramientas utilizadas en la prác-tica no tienen una conexión clara con losfundamentos teóricos. En esta comunica-ción presentamos una reorganización de lasprácticas que ayuda a los estudiantes a supe-rar estos problemas.

En la sección 2sección 2sección 2sección 2sección 2 describimos los distintosenfoques que se han utilizado en la enseñanzade la asignatura. A continuación detallamosel contexto educativo de la propuesta. En lasección 4sección 4sección 4sección 4sección 4 especificamos las nuevas prácti-cas integradas en el curso, su tipología ycontenidos. En las secciones 5 y 6secciones 5 y 6secciones 5 y 6secciones 5 y 6secciones 5 y 6 detalla-mos los resultados de esta propuesta, y final-mente exponemos nuestras conclusiones.

2. Trabajos relacionadosLa enseñanza de estas asignaturas se realizade formas muy variadas. Desde el punto devista de los contenidos, hay enfoques centra-dos en la teoría de construcción con unacobertura variada de cada concepto (por ejem-plo en cuanto a algoritmos de análisissintáctico o detalle en la implementación de latabla de símbolos). Otros enfoques se cen-tran en el diseño de lenguajes de programa-ción [1], o incluso en la ingeniería del soft-ware. W.M. Waite [16] describe varios deestos enfoques.

Otro punto importante es la práctica necesa-ria en estas asignaturas. El enfoque típico esuna práctica que dura todo el curso, pero sehan planteado distintas alternativas evitandotener que crear un compilador entero, porejemplo, desarrollar diferentes partes de uno[4] cuya estructura ya está desarrollada, ha-cer pequeñas prácticas que no tienen porquéestar relacionadas entre sí [14] o inclusoexplorar el comportamiento de un compiladorreal con una herramienta de depuración [17].Aún así, la construcción de un compilador

completo sigue siendo interesante [7]. Paraesta opción también existen distintas varian-tes, aunque todas siguen un desarrolloincremental similar: análisis léxico, sintáctico,semántico y generación, incluyendo a veces eldesarrollo de una máquina virtual. H.L. Sathi[14] disminuye la complejidad del compiladora cambio de no usar herramientas generadoras.A.V. Aho [1] pide a los estudiantes quediseñen su propio lenguaje para el que cons-truirán el compilador. Aycock [3] se centra enque los estudiantes puedan probar suscompiladores con programas complejos ypara ellos desarrollan lenguajes especiales.Finalmente, otra variante utiliza lenguajesfuente de ámbitos distintos a la programa-ción [6][8][13][18].

Nosotros hemos decidido implantar las prácti-cas basadas en el desarrollo de una parte signi-ficativa de un compilador a lo largo de todo elcurso. El trabajo lo realizan en grupo y asípueden afrontar la complejidad de un lenguajemás realista. Además, estas prácticas aportanuna visión completa del compilador, y de larelación entre las distintas etapas.

3. Contexto educativoEn esta sección describimos la organizaciónde nuestra asignatura y revisamos el rendi-miento de los estudiantes en la práctica delcurso completo.

Nuestra asignatura es anual y troncal (todoslos estudiantes de la titulación deben apro-barla). Sus contenidos se estructuran de laforma típica. Una introducción general y elanálisis léxico y sintáctico en la primera mitaddel curso, y la traducción dirigida por sintaxis,el análisis semántico y la generación de códigointermedio y final en la segunda.

En nuestra universidad existen dos periodosde evaluación oficiales (junio y septiembre),por lo que la práctica tiene 4 entregas: dosparciales para el analizador léxico y sintácticoy dos finales coincidiendo con los periodos deevaluación oficiales donde se debe completarel resto de la práctica. Antes de realizar ningu-na entrega, los estudiantes deben organizarseen grupos como máximo de 3 personas.

Dado que en nuestra titulación no se puedeasegurar que los estudiantes posean conoci-mientos suficientes de lenguaje ensamblador,la práctica no exige la generación de códigoobjeto. En su lugar usamos lenguajes finalespara los que el esfuerzo de traducción arealizar sea significativo, por ejemplo lengua-jes de medio-bajo nivel con restricciones simi-lares a las existentes en los lenguajesensambladores (expresiones aritméticas conun máximo de dos operandos, sin bucles).

3.1. Retrospectiva de las prácticasHemos analizado el rendimiento de los estu-diantes en las distintas entregas. En las gráfi-cas correspondientes (figuras 1, 2 y 3figuras 1, 2 y 3figuras 1, 2 y 3figuras 1, 2 y 3figuras 1, 2 y 3), lascantidades reflejan el porcentaje de los gruposregistrados que realizaron de forma satisfac-toria cada entrega: AL–análisis léxico, AS–sintáctico, TDS(J)–resto de la práctica enjunio y TDS(S)–resto de la práctica en junioy septiembre acumulados.

No hemos tenido en cuenta el primer año deimpartición de la asignatura, curso 2000-01,por la poca cantidad de estudiantes. Tampo-co hemos tenido en cuenta los cursos 2004-05 y 2005-06, ya que carecemos de los datosnecesarios para el análisis. Así pues estaretrospectiva contempla 5 cursos académi-cos en dos periodos diferentes, 2001-04 y

Reorganización de las prácticasde compiladores para mejorar el

aprendizaje de los estudiantes

Jaime Urquiza Fuentes, Fran-cisco J. Almeida Martínez,Antonio Pérez CarrascoGrupo LITE (Laboratorio de Tecnologías dela Información en la Educación), Universi-dad Rey Juan Carlos

< j a i m e . u r q u i z a @ u r j c . e s > ,< j a i m e . u r q u i z a @ u r j c . e s > ,< j a i m e . u r q u i z a @ u r j c . e s > ,< j a i m e . u r q u i z a @ u r j c . e s > ,< j a i m e . u r q u i z a @ u r j c . e s > ,< f r a n c i s c o . a l m e i d a @ u r j c . e s > ,< f r a n c i s c o . a l m e i d a @ u r j c . e s > ,< f r a n c i s c o . a l m e i d a @ u r j c . e s > ,< f r a n c i s c o . a l m e i d a @ u r j c . e s > ,< f r a n c i s c o . a l m e i d a @ u r j c . e s > ,< a n t o n i o . p e r e z . c a r r a s c o @ u r j c . e s >< a n t o n i o . p e r e z . c a r r a s c o @ u r j c . e s >< a n t o n i o . p e r e z . c a r r a s c o @ u r j c . e s >< a n t o n i o . p e r e z . c a r r a s c o @ u r j c . e s >< a n t o n i o . p e r e z . c a r r a s c o @ u r j c . e s >

Este artículo fue seleccionado para su publicación en NováticaNováticaNováticaNováticaNovática entre las ponencias presentadas alas XVI Jornadas de Enseñanza Universitaria de la Informática (JENUI 2010) celebradas en Santiagode Compostela en julio del pasado año y de las que ATI fue entidad colaboradora.

Resumen: La parte práctica de asignaturas como Compiladores o Procesadores de Lenguajes (lastrataremos como la misma en el resto de la comunicación) suele ser bastante costosa, ya que requierecierto grado de planificación y continuidad en el trabajo de los estudiantes y las herramientas utilizadas notienen una conexión clara con los fundamentos teóricos. Nuestra propuesta estructura estas sesionesprácticas en tres tipos: las que se encargan de enlazar teoría y práctica, las que introducen a losestudiantes las herramientas de generación de compiladores y la final donde se desarrolla un compiladorde cierta complejidad. Con este enfoque hemos mejorado el porcentaje de éxito en la parte práctica hastaun 86%.

Palabras clave: Compiladores, enseñanza de informática, Procesadores de Lenguajes, prácticas.


Enseñanza Universitaria de la Informática secciones técnicas

secciones técnicas

2006-08. Aplicamos la propuesta detalladaen esta comunicación en el curso 2008-09.

Durante los 3 primeros años, el enunciado dela práctica mantenía una parte básica paratodos y a su vez permitía numerosas variantesusando opciones en cuanto a técnicas decompilación (analizadores sintácticos utili-zados y representaciones de código interme-dio) y características del lenguaje fuente acompilar: tipos de datos complejos, senten-cias de control de flujo. La asignación de lasopciones a cada grupo era aleatoria.

Para aprobar la práctica el grupo debíaimplementar las características que se leshabía asignado, los analizadores léxico ysintáctico junto con al menos un tipo de datosy una sentencia de control de flujo. Losincrementos de la calificación se obtenían através de la calidad de la memoria y la amplia-ción de las características implementadas.

El lenguaje fuente que utilizamos fue cam-biando, el primer año en que se impartió laasignatura, 2000-01, utilizamos Java. Des-pués de observar los problemas que tuvieronlos estudiantes decidimos cambiarlo. Así,durante los tres primeros años del periodoanalizado, 2001-04, los lenguajes fuentesfueron: un lenguaje de consultas a bases dedatos estilo SQL que había que traducir aoperaciones de álgebra relacional, y dos va-riantes léxico-sintácticas del lenguaje C conrestricciones semánticas como la eliminaciónde operaciones de punteros.

Como se puede ver en la figura 1figura 1figura 1figura 1figura 1, en los tresaños la cantidad de grupos que completó conéxito la entrega del analizador léxico fue bas-tante importante, una media de 76,9%.

La cantidad de grupos que abandonaron lapráctica después de esa entrega fue muy alta,especialmente el primer año donde entregaronel analizador sintáctico sólo un 37,21%. Enlos otros dos años estuvo alrededor del 56%.

Aún así la cantidad de grupos que continua-ban con la práctica siguió disminuyendo,terminaron con éxito la entrega de junio unamedia del 16,37%. A final de curso, terminó lapráctica una media del 36,02% de los gruposregistrados.

La tasa de abandono fue demasiado alta.Entre las principales causas encontramosuna típica, el proyecto de compiladores es elprimero de larga duración que afrontan losestudiantes de nuestra titulación [14][15]. Apesar de la estructuración en entregas a losestudiantes les costaba establecer objetivosclaros. Además, el hecho de trabajar conenunciados distintos les impedía compartirideas sobre soluciones a problemas que pu-dieran encontrar.

En el siguiente periodo analizado tratamos desolventar estos problemas. En primer lugarpermitimos la selección voluntaria de lasopciones de compilación y características dellenguaje, e introdujimos la defensa presencialpara evitar el plagio entre grupos. En segundolugar definimos unos criterios totalmentedetallados que permitían establecer objetivos

claros para alcanzar las calificaciones de apro-bado, notable o sobresaliente.

Esta vez los lenguajes fuente eran orientadosa objetos. El primer año se pidió traducir unsubconjunto significativo de Java, llamadoSimpleJava, a un subconjunto de SmallTalk,llamado TinyTalk. El segundo año se invirtióel enunciado. La complejidad de los lenguajesfuente seguía siendo similar a otros añosrequiriendo el uso de análisis semántico, ta-blas de símbolos, ámbitos, etc.

En la figura 2figura 2figura 2figura 2figura 2 mostramos los datos de esteperiodo, 2006-08, junto con el periodo ante-rior, 2001-04, resumido por sus medias.Aunque en un principio pudiera parecer queempeoramos resultados, ya que los porcen-tajes de la primera entrega eran menores queen años anteriores, los resultados en la segun-da entrega se acercaron al periodo anterior ymejoraron en las entregas de junio y septiem-bre aproximadamente en un 20%. Creemosque mejoramos la capacidad de los grupos devalorar sus posibilidades a la hora de terminarcon éxito la práctica, ya que la tasa de aban-dono entre entregas es mucho menor, y encómputo global la cantidad de grupos quehicieron la primera entrega es prácticamenteigual a la de grupos que terminaron la prácticaen septiembre.

Sin embargo, el porcentaje de grupos quetermina la práctica a final de curso siguesiendo bajo, una media de 58,73% en esteperiodo. En términos de porcentajes de alum-nos que aprueban la práctica con respecto alos matriculados, en el primer periodo tuvi-mos una media de 33,2% y en el segundo52,43%. Comparando estas cifras con losporcentajes de estudiantes que aprueban laparte teórica, una media del 85,05%, la dife-rencia salta a la vista.

A la luz de estos datos creemos que debemosestablecer mejor el vínculo entre los concep-tos teóricos, que los estudiantes sí dominan,

Figura 1. Gráfica de los años 2001-04.

Figura 2. Gráfica de los años 2006-08 junto al periodo 2001-04 resumidopor sus medias.



secciones técnicas

y los prácticos. Para ello proponemos unareorganización de las sesiones prácticas de laasignatura que refuerce ese vínculo. Aplica-mos la organización en el curso 2008-09.

4. Reorganización de las prácticasNuestra propuesta es salvar el salto entre lateoría (algoritmos y estructuras formales) yla práctica (herramientas de generación eimplementación de estructuras de datos com-plejas) con prácticas más sencillas y cercanasentre ambos extremos. Vamos a integrar en laasignatura otros dos tipos de prácticas: bási-cas y aplicativas, a parte de la práctica final.

Las prácticas básicas tienen carácter volunta-rio y tratan de acercar los conceptos teóricosa la práctica de dos formas diferentes: mos-trando el funcionamiento de los algoritmosvistos en clase mediante herramientas de si-mulación/visualización o relacionando el re-sultado producido por las herramientas degeneración con sus fundamentos teóricos.La duración será de 1 o 2 horas.

El resultado final de este tipo de prácticas esque el estudiante ha visto en funcionamientolos algoritmos, los ha relacionado con suimplementación por parte de las herramientasgeneradoras y ha utilizado éstas una formabásica y tutorizada.

Las prácticas aplicativas son voluntarias eincentivadas. Pueden aumentar 1 punto (so-bre 10) la nota final de la asignatura, siemprey cuando se apruebe la parte teórica. Estasprácticas tratan de involucrar a los estudian-tes en el uso de las herramientas de generaciónresolviendo problemas algo más complejos.La duración será de 3 a 15 días. El resultadofinal de este tipo de prácticas es que losestudiantes aprenden cuándo y cómo aplicarlas funcionalidades de estas herramientas, loque les ayudará a afrontar la realización de lapráctica final.

A continuación describimos las prácticasagrupadas en las tres entregas de la prácticafinal: análisis léxico, sintáctico y traduccióndirigida por la sintaxis (análisis semánticoy generación de código).

4.1. Análisis léxicoDurante la fase de análisis léxico planifica-mos tres prácticas, dos básicas y unaaplicativa. La primera práctica básica es desimulación y trata sobre autómatas y expre-siones regulares. El objetivo de esta prácticaes mostrar el funcionamiento de los funda-mentos teóricos del análisis léxico. Usamosla herramienta JFlap [12] para que los estu-diantes generen autómatas finitos y expresio-nes regulares y experimenten con el proceso dereconocimiento.La segunda práctica básica es sobre herra-mientas generadoras y trata sobre la herra-mienta JFLex [10]. Su objetivo es introducir

a los estudiantes en la utilización de losgeneradores de analizadores léxicos. Lo enfo-camos como un tutorial sobre la herramientacon ejercicios simples, así los estudiantesterminan conociendo las distintas posibilida-des de JFlex. También se les muestra el códigogenerado identificando las tablas de transi-ción del autómata finito. De esta formamostramos la aplicación directa de los con-ceptos teóricos en la práctica.

Finalmente, la práctica aplicativa consiste enimplementar un traductor de código Morse.El objetivo de esta práctica es que los estu-diantes apliquen las posibilidades de traduc-ción de JFlex a un enunciado pseudo-realista.Se les proporciona una descripción del códigoMorse y se les pide que construyan un traduc-tor a/desde caracteres del alfabeto occidental.El plazo de entrega son dos días, debiendoproporcionar la especificación JFlex del tra-ductor. El peso en la nota extra de prácticases de un 10%.

Con estas prácticas conseguimos que losestudiantes se ejerciten en el diseño de autó-matas y expresiones regulares, vean la co-nexión con un generador de analizadores léxi-cos y practiquen con él antes de afrontar laparte del analizador léxico correspondiente ala práctica final.

4.2. Análisis sintácticoDurante la fase de análisis sintáctico planifi-camos ocho prácticas, seis básicas y dosaplicativas. Utilizamos la herramienta JFlap[12] para el trabajo con gramáticas y autó-matas, así como con analizadores LL(1) ySLR(1). Las herramientas generadoras queusamos eran ANTLR [11] para analizadoresdescendentes y CUP [9] para analizadoresascendentes.

La primera práctica básica era de simulacióny trataba de autómatas con pila (AP) y gra-máticas independientes del contexto (GIC).El objetivo de esta práctica es mostrar elfuncionamiento de los fundamentos teóricosdel análisis sintáctico. Los ejercicios son lastípicas descripciones de lenguajes para los quehay que diseñar el AP y la GIC que lo reconoz-ca. En el caso de los APs la comprobación desu funcionamiento es inmediata.

Sin embargo, en el caso de las GICs la herra-mienta debe construir el analizador corres-pondiente, en esta práctica utilizamos el ana-lizador con retroceso. JFlap muestra la ejecu-ción de este algoritmo informando sobre lacantidad de nodos creados durante la ejecu-ción, consiguiendo así que los estudiantessean conscientes de la necesidad de encontrarotros algoritmos de construcción deanalizadores sintácticos más eficientes.

Las dos siguientes prácticas básicas tratan deanalizadores descendentes, la primera es de

simulación y la segunda de generador. Enprimer lugar usamos JFlap para experimentarcon los conceptos teóricos relacionados conlos analizadores LL(1). Esta herramientapermite a los estudiantes explorar de formaactiva el proceso de construcción de los con-juntos cabecera y siguientes de cada símbolono terminal, así como la tabla de análisisLL(1). La exploración activa consiste enpedir al estudiante que especifique el conteni-do de los conjuntos y las celdas de la tabla,indicando los errores cometidos y proporcio-nando las soluciones correctas si así lo nece-sita el estudiante. Finalmente, JFlap constru-ye el analizador y permite que el estudiantevisualice su comportamiento usando suspropias cadenas de entrada.

La práctica básica de generación trata sobreANTLR [11] y su objetivo es doble. Por unlado queremos introducir a los estudiantes enel uso de generadores de analizadoressintácticos descendentes de carácter profe-sional como ANTLR [11]. Por otro lado losestudiantes podrán ver la aplicación prácticade los conceptos teóricos relacionados. Denuevo utilizamos un enfoque de tutorial so-bre la herramienta, construyendo analizadorespara lenguajes simples como los usados en lapráctica sobre APs y GICs. Finalmente losestudiantes explorarán el código fuente genera-do por ANTLR identificando conceptos teóri-cos como las reglas borradoras, los símbolos deanticipación (y su construcción con los conjun-tos cabecera y siguientes), los métodos asocia-dos a no terminales o la detección de terminalesen la cadena de entrada.

Para terminar con los analizadores descen-dentes usamos una práctica aplicativa sobreANTLR. El objetivo de esta práctica es quelos estudiantes diseñen gramáticas no trivia-les teniendo en cuenta las restricciones LL(1).Proponemos a los estudiantes una gramáticade expresiones aritméticas sin precedenciaalguna en los operadores que deben modificarpara que los operadores aritméticos cumplanunas normas de precedencia específicas. Ade-más les pedimos que documenten la solucióncon visualizaciones que justifiquen la existen-cia de estas precedencias en los árbolessintácticos. Las herramientas de visualiza-ción utilizadas son VAST [2] y ANTLRWorks[4]. En concreto, los estudiantes deben mo-dificar la gramática, producir visualizacionesseleccionando ellos mismos las cadenas deentrada y explicar dichas visualizaciones.Además se les pide generar visualizaciones deejemplo para las situaciones erróneas LL(1):fallo con el símbolo director y terminal noencontrado en la cadena de entrada. El plazode entrega fue de tres días, debiendo propor-cionar la especificación ANTLR de la gramá-tica con las precedencias implementadas, asícomo la documentación basada en visualiza-ciones. El peso en la nota extra de prácticas erade un 20%.


Enseñanza Universitaria de la Informática secciones técnicas

secciones técnicas

A continuación pasamos a describir las prác-ticas relacionadas con los analizadores as-cendentes. Tres de ellas básicas, una de simu-lación y dos de generadores, y otra aplicativa.La práctica básica de simulación trata sobreanalizadores SLR(1) con JFlap. Al igual queen la práctica básica de simulación LL(1),JFlap permite la exploración activa del proce-so de construcción de un analizador SLR(1),desde los cálculos de cierres de ítems, hasta laconstrucción de las tablas del autómata. Elestudiante también podrá visualizar el com-portamiento del analizador con sus propiascadenas de entrada.

Las dos prácticas básicas de generación deanalizadores ascendentes usan la herramien-ta CUP [9]. Con ambas prácticas introduci-mos a los estudiantes en el uso de herramien-tas profesionales para la generación deanalizadores sintácticos y les mostramos laaplicación de los conceptos teóricos relativosa analizadores ascendentes. Así, la primerapráctica básica, Analizadores LR(1) con CUP,muestra en el generador CUP los conceptosvistos en la construcción de analizadores LR:conjuntos primeros y siguientes, producciónde ítems, generación de estados del autómataLR, producción de las tablas acción e ir-a yfinalmente conflictos reducción-reducción yreducción-desplazamiento. La segunda prác-tica básica, Herramienta generadora CUP,trata sobre el enlace entre los analizadoresléxico y sintáctico. Los estudiantes aprendencómo usar analizadores léxicos construidoscon JFlex, así como otras funcionalidadesauxiliares que ellos mismos hayan desarrolla-do e integrarlas en la especificación CUP.

La práctica aplicativa sobre generadores deanalizadores ascendentes, Recuperación deerrores con CUP, como su propio nombreindica trata sobre la recuperación de erroressintácticos. CUP utiliza una estrategia de

recuperación en modo pánico similar a YACC,mediante la inserción de puntos de sincroni-zación en la gramática con el símbolo termi-nal "error". En esta práctica se pide a losestudiantes que diseñen recuperaciones paratres errores concretos en una gramática sim-ple (5 no terminales con 9 producciones)procesando la mayor cantidad posible de laentrada. Y finalmente, en una gramática máscompleja (9 no terminales, NT, con 20 reglas)en la que se pide diseñar la mejor recuperaciónde errores posible usando el menor número depuntos de sincronización. El plazo de entregafueron cinco días, debiendo proporcionar lasespecificaciones CUP con las recuperacionesde errores. El peso en la nota extra de prácticasera de un 20%.

En resumen, hemos conseguido que los estu-diantes se ejerciten en el diseño de APs y GICs,vean la conexión con dos generadores deanalizadores sintácticos y practiquen con ellosantes de afrontar la parte del analizadorsintáctico correspondiente a la práctica final.

4.3. Traducción dirigida por la sintaxisEn la fase de traducción dirigida por la sin-taxis (TDS) planificamos una prácticaaplicativa, que cubre dos conceptos impor-tantes: TDS con definiciones dirigidas por lasintaxis con CUP y TDS con esquemas detraducción con ANTLR.

En ambas partes se comienza con un enfoquetutorial explicando cómo añadir accionessemánticas a las producciones y cómo usaratributos asociados a los símbolos no termi-nales. En la parte dedicada a definicionesdirigidas por la sintaxis con CUP se propor-ciona a los estudiantes los analizadores léxicoy sintáctico correspondiente a una gramáticasimple de cálculo de expresiones lógicas (4NTs con 10 reglas). En la parte dedicada aesquemas de traducción con ANTLR se pro-

porciona a los estudiantes la especificaciónANTLR léxica y sintáctica de una gramáticasimple de cálculo de expresiones aritméticas(6 NTs con 12 reglas).

En ambos casos la complejidad no se encuen-tra en el tamaño de la gramática sino en laselección de atributos a usar y la inserción delas acciones semánticas pertinentes. Tambiénse pidió a los estudiantes que documentaransu práctica con animaciones que mostraranel funcionamiento de sus traductores. Final-mente distribuimos estas animaciones paraque, además del profesor de la asignatura, losestudiantes evaluaran de forma anónima lasanimaciones de otros estudiantes. El plazo deentrega fue de 13 días para la entrega de losdos traductores con su documentación yotros 15 para la evaluación de las animacio-nes asignadas, 6 por cada estudiante. El pesoen la nota extra de prácticas era de un 35%.

En resumen, hemos conseguido que los estu-diantes se ejerciten en el diseño de traductoresdirigidos por la sintaxis con ANTLR y conCUP, y que además hagan un esfuerzo dereflexión sobre las soluciones aportadas alevaluar la documentación de otros estudian-tes. Esto les ayudará a la hora de afrontar laparte de traducción dirigida por la sintaxiscorrespondiente a la práctica final.

4.4. Análisis semánticoEn la fase de análisis semántico planificamosuna práctica aplicativa sobre comprobaciónde tipos y manejo de tabla de símbolos. Enesta práctica se pide a los estudiantes quediseñen una acción semántica asociada a unaproducción que representa una llamada a unmétodo de una clase.

En concreto, los estudiantes deben completarla acción semántica dada para que comprue-be que la llamada al método efectuada escorrecta. También deben implementar dentrode dicha acción la propagación del resultadode la acción (devolución de tipo), aportandoademás un mensaje concreto para cada tipode error que pudiera darse. También debenaportar la interfaz de todas las clases adicio-nales que se necesiten (por ejemplo la queimplemente la tabla de símbolos). Estasinterfaces deben contener para cada métodoun detallado comentario que indique lafuncionalidad del método, qué entrada recibey qué salida devuelve.

El plazo de entrega fueron 7 días y el peso enla nota extra de prácticas era de un 15%.

4.5. Distribución temporal de lasprácticasLa planificación de estas prácticas sesincronizó en la medida de lo posible con loscontenidos de las clases de teoría. Así lasprácticas básicas de simulación estaban per-fectamente sincronizadas con las sesiones de

Semana Práctica Tipo 2 AFDs y Expresiones reg. JFlap B 3 Herramienta JFlex B 4 Traductores con JFlex A 4 APs y GICs con JFlap B 8 Analizadores LL(1) con JFLap B 9 Herramienta ANTLR B 10 Analizadores LL(1) con ANTLR A 11 Analizadores SLR(1) con JFLap B 12 Analizadores LR(1) con CUP B 13 Herramienta CUP B 14-15 Recuperación de errores sintácticos en CUP A 17-20 TDS con ANTLR y CUP A 23 Análisis semántico A

Tabla 1. Distribución temporal de las prácticas básicas (B) y aplicativas (A).



secciones técnicas

Referencias

[1] A.V. Aho. Teaching the compilers course.SIGCSE Bulletin 40, 4 (Nov. 2008), pp. 6-8.[2] F.J. Almeida-Martínez, J. Urquiza-Fuentes,J.A. Velázquez-Iturbide. Visualization of SyntaxTrees for Language Processing Courses. Journalof Universal Computer Science, 15(7) (Abr. 2009),pp. 1546-1561.[3] J. Aycock. The ART of compiler constructionprojects. SIGPLAN Not. 38, 12 (Dec. 2003), pp. 28-32.[4] D. Baldwin. A compiler for teaching aboutcompilers. SIGCSE Bull. 35, 1 (Jan. 2003), pp.220-223.[5] J. Bovet. ANTLRWorks: The ANTLR GUIDevelopment_Environment, <http://www.antlr.org/works>, 2010.[6] S. Debray. Making compiler design relevant forstudents who will (most likely) never design acompiler. SIGCSE Bull. 34, 1 (Mar. 2002), pp. 341-345.[7] A. Demaille. Making compiler constructionprojects relevant to core curriculums. SIGCSE Bull.37, 3 (Sep. 2005), pp. 266-270.[8] T. Henry. Teaching compiler constructionusing a domain specific language. SIGCSE Bull.37, 1 (Feb. 2005), pp. 7-11.[9] S. Hudson. LALR Parser Generator in Java,<http://www.cs.tum.edu/projects/cup>, 2010.[10] G. Klein, S. Rowe, R. Décamps. JFlex - TheFast Scanner Generator for Java, <http://jflex.de>,2010.[11] T. Parr. ANTLR Parser Generator, <http://www.antlr.org>, 2010.[12] S.H. Rodger. Learning automata and formallanguages interactively with JFLAP. SIGCSE Bull.38, 3 (Sep. 2006), p. 360.[13] M. Ruckert. Teaching compiler constructionand language design: making the case for unusualcompiler projects with postscript as the targetlanguage. SIGCSE Bull. 39, 1 (Mar. 2007), pp. 435-439.[14] H.L. Sathi. A project-based course in compilerconstruction. SIGCSE Bull. 18, 1 (Feb. 1986), pp.114-119.[15] H.D. Shapiro, M.D. Mickunas. A new approachto teaching a first course in compiler construction.SIGCSE Bull. 8, 1 (Feb. 1976), pp. 158-166.[16] W.M. Waite. The compiler course in today’scurriculum: three strategies. SIGCSE Bull. 38, 1(Mar. 2006), pp. 87-91.[17] E. White, R. Sen, N. Stewart. Hide and show:using real compiler for teaching. SIGCSE Bull. 37,1 (Feb. 2005), pp. 12-16.[18] L. Xu, F.G. Martin. Chirp on crickets: teachingcompilers using an embedded robot controller.SIGCSE Bull. 38, 1 (Mar. 2006), pp. 82-86.

teoría donde se explicaron los algoritmoscorrespondientes.

En la tabla 1tabla 1tabla 1tabla 1tabla 1 se puede ver la planificacióntemporal de las prácticas básicas y aplicativas.Los huecos existentes en las semanas corres-ponden a sesiones dedicadas a la práctica obli-gatoria. Se puede observar que las primeras 16semanas (primer cuatrimestre) tiene muchasmás prácticas que el segundo. Esto se debe a lanecesidad de que los alumnos lleguen al segun-do cuatrimestre con los conceptos relativos alanálisis sintáctico bien asentados.

Las dos primeras entregas de la práctica finalconsisten en generar especificaciones relati-vamente sencillas del analizador léxico ysintáctico. Sin embargo, la tercera entregaconsistía en el analizador semántico y genera-dor de código. Esta entrega es bastante máscompleja y requiere de un esfuerzo de diseñoy programación mucho mayor. Por ello deci-dimos liberar el segundo cuatrimestre de prác-ticas básicas centrándonos en las aplicativas.

5. Resultados de los estudiantesAnalizamos los resultados tras utilizar esteenfoque de práctica final a lo largo del cursojunto con prácticas pequeñas. Como se pue-de ver en la figura 3figura 3figura 3figura 3figura 3, resultados han mejora-do significativamente. Más del 83% de losgrupos registrados entregaron con éxito elanalizador léxico y ninguno abandonó en elsintáctico. La entrega final de junio sí sufrióun poco de abandono, pero al final del cursomás de un 86% de los grupos registradossuperaron la práctica final con éxito.

En cuanto al porcentaje de estudiantes quehan aprobado la práctica, representa un72,27% de los matriculados.

6. ConclusionesHemos presentado nuestra experiencia con la

asignatura de Procesadores de Lenguajes.Uno de los puntos importantes son las prác-ticas. Elegimos la práctica larga porque per-mite a los estudiantes afrontar un problemamás realista y tomar conciencia de las relacio-nes existentes entre las distintas fases de aná-lisis y síntesis.

Al principio los resultados no fueron buenos.Tratamos de mejorarlos modificando ciertosaspectos burocráticos de la práctica. Estoayudó a mejorar la tasa de abandono en casiun 22%. Aún así, en junio los grupos nopasaban del 38,22% y en septiembre del 58,7%.

Llegamos a la conclusión de que la prácticaúnica puede desconectar la teoría y la prácticaen esta asignatura. Por ello la reforzamos conprácticas pequeñas de dos tipos, las que tra-bajan los conceptos teóricos y las que engan-chan la teoría con los generadores deanalizadores.

El efecto ha sido claramente positivo. Hemosconseguido anular la tasa de abandono entreel léxico y el sintáctico, en junio más de un 74%de grupos registrados completaron la prácti-ca con éxito y hasta septiembre más de un86%. Lo que en términos de estudiantes,significa un 72% de los matriculados.

AgradecimientosEste trabajo se ha financiado con el proyectoTIN2008-04103 del Ministerio de Ciencia yTecnología del Reino de España.

Figura 3. Gráfica del año 2008-09. Los datos de 2001-04 y 2006-08,se han resumido con las medias de cada entrega.


Estándares Web secciones técnicas

secciones técnicas

1. IntroducciónLas transacciones son un concepto funda-mental para conseguir fiabilidad en aplicacio-nes distribuidas. Una transacción es un meca-nismo que asegura que los participantes en unproceso finalizan de manera consensuada.Tradicionalmente las transacciones siguie-ron el modelo ACID: Atomicidad, Consis-tencia, Aislamiento y Durabilidad.

En los Servicios Web (SW), las transaccionesson complejas, involucran múltiples partici-pantes, atraviesan diferentes dominios y pue-den tener una larga duración. El estrictomodelo ACID no es apropiado para un entor-no de servicios autónomos e independientesdado que la naturaleza del proceso, (princi-palmente su incrementada duración) haceinviable el bloqueo de recursos imposibilitan-do las acciones de rollback. Este tipo detransacciones con nuevas características sondenominadas de larga duración o larga ejecu-ción [14] diferenciándolas de las anteriores,denominadas transacciones atσmicas. La co-munidad investigadora ha propuesto nuevosmodelos de gestión de transacciones que hansido adaptados para los SW. Estos modelosprincipalmente relajan las políticas deatomicidad y aislamiento de manera que losresultados intermedios de las transaccionesactivas son visibles para otras [24].

Se han propuesto diferentes estándares parasu gestión en SW. Business TransactionProtocol [5], aun pudiendo ser utilizado enSW, no fue originariamente definido paraello. Web Services Composite ApplicationFramework [21] es un estándar para la com-posición de aplicaciones conteniendo un pro-tocolo para las transacciones. Web ServicesBusiness Process Execution Languaje (WS-BPEL) [23] es un lenguaje ejecutable para laespecificación de interacciones entre SW queincorpora un modelo básico para la gestiónde transacciones. WS-Coordination (WS-COOR) [22], WS-AtomicTransactions (WS-AT) [19] y WS-BusinessActivity (WS-BA)[20] son un conjunto de protocolos para lacoordinación de transacciones atómicas y delarga duración. Como indica Curbera [11],WS-COOR, WS-BA y WS-AT complemen-tan WS-BPEL proveyéndole de un verdaderomecanismo transaccional para la coordina-ción de SW.

Especificación y prueba derequisitos de recuperabilidad en

transacciones WS-BusinessActivity

Rubén Casado Tejedor1,Javier Tuya González1,Muhammad Younas2

1 Departamento de Informática, Universidadde Oviedo, 2 Department of Computing andElectronics, Oxford Brookes University,Oxford (Reino Unido)

< r c a s a d o @ l s i . u n i o v i . e s > ,< r c a s a d o @ l s i . u n i o v i . e s > ,< r c a s a d o @ l s i . u n i o v i . e s > ,< r c a s a d o @ l s i . u n i o v i . e s > ,< r c a s a d o @ l s i . u n i o v i . e s > ,< t u y a @ l s i . u n i o v i . e s > ,< t u y a @ l s i . u n i o v i . e s > ,< t u y a @ l s i . u n i o v i . e s > ,< t u y a @ l s i . u n i o v i . e s > ,< t u y a @ l s i . u n i o v i . e s > ,< m . y o u n a s @ b r o o k e s . a c . u k >< m . y o u n a s @ b r o o k e s . a c . u k >< m . y o u n a s @ b r o o k e s . a c . u k >< m . y o u n a s @ b r o o k e s . a c . u k >< m . y o u n a s @ b r o o k e s . a c . u k >

Este artículo fue seleccionado para su publicación en NováticaNováticaNováticaNováticaNovática entre las ponencias presentadas alas VI Jornadas Científico-Técnicas en Servicios Web y SOA (JSWEB2010) celebradas en Valenciay de las que ATI fue entidad colaboradora

Resumen: Las transacciones son un concepto clave en la fiabilidad de aplicaciones basadas en serviciosweb, siendo WS-Coordination y WS-BusinessActivity los más recientes y aceptados estándares para sumanejo. Este artículo aborda la prueba de transacciones en servicios web, tema al que la investigaciónactual ha prestado escasa atención. Se define un modelo para la especificación de requisitos funcionalesde una transacción según el estándar WS-BusinessActivity, así como se propone la utilización de técnicasbasadas en riesgos para la definición de casos de prueba que validen el proceso. Se presenta un caso deestudio para ilustrar el método.

Palabras clave: Transacciones, pruebas de software, servicios web, análisis de riesgo

Aunque la literatura presenta diferentes enfo-ques para la prueba de SW, existe un vacío enla prueba de transacciones [7]. Nuestra inves-tigación aborda la problemática de la pruebade transacciones de larga duración medianteWS-COOR y WS-BA.

En [8] se presentó un marco conceptual parala prueba de este tipo de transacciones. Den-tro de ese trabajo, se estudiaron sus caracte-rísticas desde un punto de vista de las pruebasde software. Basado en él, se definió unconjunto de propiedades [9] (Composición,Orden, Visibilidad, Consistencia, Durabilidad,Coordinación) donde aplicar análisis de ries-gos con el objetivo de identificar escenarios deprueba. Se muestra el uso de la técnica FaultTree Analysis (FTA) [18] para definir especi-ficaciones de casos de prueba.

En este artículo extendemos el trabajo anteriormejorando el modelo para la especificación delos requisitos transaccionales así como la adap-tación del enfoque basado en riesgos para WS-BA. La utilidad se ilustra con un caso de usodonde los requisitos funcionales se especificanguiados por nuestro modelo y se derivan doscasos de prueba usando los escenarios de ries-gos alcanzados en el FTA.

El resto del artículo se organiza así: Lasección 2sección 2sección 2sección 2sección 2 resume el funcionamiento de WS-COOR y WS-BA. La sección 3sección 3sección 3sección 3sección 3 presenta elmodelo y notación para la especificación delos requisitos transaccionales. En la secciónsecciónsecciónsecciónsección44444 se ilustra nuestro enfoque con un caso deestudio. Este caso de estudio se usa paramostrar cómo los casos de prueba para WS-BA se derivan de los escenarios de riesgo en lasección 5sección 5sección 5sección 5sección 5. La sección 6sección 6sección 6sección 6sección 6 compara nuestrotrabajo con otras investigaciones. Algunasconclusiones y líneas de trabajo futuro sedescriben en la sección 7sección 7sección 7sección 7sección 7.

2. WS-Coordination y WS-BusinessActivityWS-COO define un protocolo para la distri-bución del contexto de una transacción atodos los participantes. WS-COO especificala interfaz del coordinador creando uno nue-vo o uniéndose a una transacción ya existente.El coordinador consta de los siguientes ser-vicios:

Activación: creación de un nuevo contexto.Registro: especificación del protocolo a usar.Protocolo: tipo de coordinación (WS-BA

para transacciones de larga duración y WS-ATpara las atómicas).

Cuando un participante inicia una nuevatransacción necesita un nuevo contexto quesolicita a un coordinador usando el serviciode activación. Posteriormente, el participantenotifica al resto reenviando el contexto decoordinación. Cada participante registra suprotocolo en un coordinador usando el ser-vicio de registro. Finalmente, el coordinadorgestiona la transacción intercambiando men-sajes con los participantes mediante el servi-cio de protocolo.

Tanto WS-AT como WS-BA están construi-dos sobre WS-COOR. El propósito de WS-BAes coordinar transacciones de larga duración,compuestas por subtransacciones, utilizandocompensaciones. Una vez que una subtran-sacción finaliza correctamente puede ser deshe-cha mediante la ejecución de una compensa-ción. Imaginemos una aplicación dedicada a lareserva de un viaje compuesto por reservas dehotel, vuelo y alquiler de coche, donde cadareserva la realiza un servicio independiente. Si elvuelo se anula una vez que el hotel fue reservado,esa reserva necesita ser cancelada. Esto significaque la habitación tiene que aparecer comodisponible y el cliente podría tener que pagar unapenalización por la cancelación.


secciones técnicas Estándares Web

secciones técnicas

3. Modelo de transacciónUna transacción de larga duración en SW,denotada por wT, está estructurada comosaga [13], un conjunto de subtransaccionescada cual con una acción compensatoriaasociada. Si una de las subtransacciones de lasecuencia aborta, se ejecutan, en orden inver-so, las acciones compensatorias asociadas atodas las subtransacciones completadas. Seve la importancia de comprobar la recupera-bilidad de cada subtransacción para asegurarla consistencia del proceso. En esta sección sepropone un modelo y notación para la espe-cificación de los requisitos funcionalestransaccionales. Este modelo será usado parala definición de casos de prueba.

Una wT se compone de actividades (subtran-sacciones) ejecutadas por diferentes SW (par-ticipantes) que pueden necesitar una cantidadsubstancial de tiempo para terminar su ac-ción. Una wT queda definida por la quíntuplawT =<S, C, ΨΙ , ΨΕ , ΨC > donde S es elconjunto de subtransacciones, C el de accio-nes compensatorias, ΨI es un conjunto deestados iniciales, ΨE es un conjunto de esta-dos ejecutados y ΨC es un conjunto de estadoscompensados.

El conjunto S={sl , ... , sn} define las subtran-sacciones donde cada si es una transacciónatómica u otra wT’. Una subtransacción esreemplazable si existe otro participante quepueda realizar la misma acción. Unasubtransacción sj es dependiente de otra si ,denotado por sj < si si puede ser ejecutada siy solo si si fue completada.

S tiene un orden de ejecución, denotado porO(S). Se denota si ; sj si la subtransacción si

tiene que finalizar antes de poder ejecutar sj.Se denota si |sj si ambas subtransaccionespueden ser ejecutadas en paralelo. Se usa[si|sj] para especificar subtransaccionesreemplazables que pueden ser ejecutadas enparalelo y finalmente escoger cuál de ellasconfirmar. Se usa [si :sj] para especificar quesi y sj son reemplazables y sj puede ser ejecu-tada si y solo si si falló. Si estrictamente solouna puede ser ejecutada, se denota mediante[si ,sj]. La figura 1figura 1figura 1figura 1figura 1 muestra la notacióngráfica para estas relaciones.

Toda si tiene una acción compensatoria deno-tada por ci . Una ci deshace, semánticamente,las acciones realizadas por si , pero no nece-sariamente retorna al sistema al estado previoa su ejecución. El conjunto de todas lasacciones compensatorias se denota por C={c1, ..., cn }. Toda ci puede ser ejecutada si y solosi si ha sido completada. Cualquier ci puedeser una acción vacía, denotado por λ.

3.1. Participantes y coordinadorUn participante pi es el servicio responsablede ejecutar si y la gestión de ci .

Una notificación de transacción es la comu-nicación entre dos participantes. Se usa lanotación iwT [m1] jwT para especificar que elparticipante pi interviene en wT y envía elmensaje m1 a otro participante pj tambiéninvolucrado en wT. Si el participante es elcoordinador se denota mediante K. Se usaiwT [m1] jwT − lwT [m2 ]OwT − ... − vwT [mn]zwTpara denotar una secuencia de notificacio-nes.

Un coordinador K es el participante encargadode manejar las subtransacciones. Ordena suejecución, gestiona los fallos y compensacionesy recolecta los resultados de los participantespara dejar el sistema en un estado consistentedespués de la ejecución de la transacción.

3.2. Estados en una subtransacciónUn estado inicial σi define los requisitos nece-sarios para que pi pueda ejecutar si . Elconjunto de estados iniciales se denota ΨΙ ={σ1 , ... , σn }.

Un estado ejecutado σ*i define los requisitos

que pi tiene que satisfacer una vez que hacompletado si . El conjunto de todos losestados ejecutados se denota por ΨΕ ={σ∗1, ... , σ∗n}.

Los requisitos especificados en σ∗i puedenestar incluidos en los requisitos necesariospara la ejecución de la siguiente subtransacciónsi+1 definidos en σi+1 .

El estado compensado σ’i define los requisi-tos que pi tiene que satisfacer una vez haejecutado ci . El conjunto de todos los esta-dos compensados se denota por Ψ C = {σ’i ,... , σ’n }.

La acción compensatoria ci deshace semánti-camente las acciones ejecutadas por si . Elsistema cambia hacia σ’i . Este estado no esnecesariamente igual a σi dado la imposibi-lidad de deshacer algunas operaciones (por ej.un email enviado). Se usa

para denotar que, empezando en σi , se alcanzaσ*i después de que la subtransacción se com-pleta y la secuencia de ejecución puede conti-nuar. Se usa

para denotar que, empezando en σ*i , se alcan-za σ’i tras la ejecución de ci y se puedecontinuar con la secuencia de compensacio-nes.

La figura 2figura 2figura 2figura 2figura 2 ilustra los estados de unasubtransacción. Se puede hacer un fácil mapeoentre el modelo de requisitos con el modelo deestados de WS-BA [20]. Nótese que σi puedeser mapeado como el estado Active ya que esel estado anterior a la ejecución de lasubtransacción (mensaje complete). De lamisma manera, σ* está relacionado con elestado Completed mientras que σ’i es alcan-zado a través del mensaje compensated.

4. Caso de estudioServicio de Estancias (SerEs) es una aplica-ción basada en SW dedicada a la gestión de lassolicitudes de estudiantes para hacer estan-cias en otras universidades. El servicio pro-porciona completa funcionalidad para la asig-nación de las becas, registro y reserva dealojamiento en la universidad destino asícomo del pago.

El estudiante envía a la aplicación sus datospersonales, fechas para la estancia y una listaordenada por preferencia de las universidadesen las que está interesado. La aplicación envíasimultáneamente la solicitud al servicio de

Figura 1. Relaciones entre subtransac-ciones.

Figura 2. Estados de una subtransacción.



secciones técnicas

becas así como a todas las universidades(uni) propuestas. Después de ser analizada,el servicio de de becas responde con los deta-lles de la subvención que variará según laduración y lugar de la estancia. Obviamente lasubvención puede ser denegada. Cuando to-das las universidades han respondido, la apli-cación selecciona la mejor acorde con laspreferencias del estudiante y notifica la deci-sión al resto de universidades candidatas. Sila subvención es denegada, o todas las univer-sidades candidatas rechazan la solicitud, elproceso queda cancelado y se notifica alestudiante. Una vez que la universidad aceptala propuesta y se asigna la cuantía de la beca,el estudiante es matriculado en la universidaddestino. Esta acción se compone de reserva dealojamiento en una residencia universitaria(res) y alta en el servicio de investigación (inv).El último paso es cargar el pago de la residen-cia universitaria en la cuenta del estudiante ynotificar al usuario todos los datos de laestancia.

En este ejemplo existen múltiples dependen-cias inter e intra transaccionales. De ahí laimportancia de asegurar la consistencia tantodurante como al final del proceso, tanto sifinaliza correctamente o es cancelado (y recu-perado mediante acciones compensatorias).Incluso asumiendo que todos los serviciosfuncionan correctamente, existen escenariosde riesgo debidos a la naturaleza transaccionaldel proceso. A continuación se presentanalgunos:

Si un estudiante con beca la rechaza yexisten otros estudiantes esperando por una,¿se concede una nueva beca?

Si varias universidades candidatas acep-tan la propuesta, ¿se elige la preferida? ¿Can-celan el resto la propuesta?

Si después de que todo el proceso estéconfirmado el estudiante acorta la duraciónde la estancia, ¿se reclama la parte correspon-diente de la subvención? ¿Cancela la residen-cia de estudiantes el alojamiento?

4.1. Especificación de requisitosEn este apartado se especifican los requisitosfuncionales transaccionales para SerEs. Seasume que el estudiante estaría interesado enhacer la estancia en la Universidad de Oviedo(UO) o en Oxford Brookes University (OBU).Esta transacción se define a continuación:

wTestancia= Sestancia, Cestancia, ΨIestancia, ΨEestancia,ΨCestancia

Participantes={Beca, UOuni, OBUuni,UOres, OBUres, UOinv, OBUinv, Pago, Coor-dinador}Sestancia={sbeca, suo_uni, sobu_uni, suo_res, sobu_res,suo_inv, sobu_inv, spago}Cestancia={cbeca, cuo_uni, cobu_uni, cuo_res, cobu_res,cuo_inv, cobu_inv, cpago}ΨIestancia={σbeca, σuo_uni, σobu_uni, σuo_res, σobu_res,σuo_inv, σobu_inv, σpago}ΨEestancia={σ*beca, σ*uo_uni, σ*obu_uni, σ*uo_res,σ*obu_res, σ*uo_inv, σ*obu_inv, σ*pago}ΨCestancia={σ’beca, σ’uo_uni, σ’obu_uni, σ’uo_res,σ’obu_res, σ’uo_inv, σ’obu_inv, σ’pago}

4.1.1. SubtransaccionesEn SeRes existen requisitos transaccionales quedeben ser cumplidos. Por ejemplo, existe depen-dencia entre la residencia universitaria y el siste-ma de investigación: ambos deben pertenecer ala misma universidad. También existen relacio-nes de reemplazo ya que tanto UO como OBUpueden aceptar una propuesta. Estas relacionesse muestran en la figura 3figura 3figura 3figura 3figura 3.sbeca: Recibe los datos del estudiante, duraciónde la estancia y los detalles de la universidaddestino. Si la beca es concedida, contacta conPago para transferir el dinero a la cuenta delestudiante. Responde con el resultado de lasolicitud.suo_uni , sobu_uni: Reciben la propuesta del estu-diante y responden si es aceptada o no.suo_res , sobu_res: Reciben la aceptación de launiversidad, fechas de reserva y los datos delestudiante. Se reserva una habitación si haydisponible. Notifica a Pago la cuantía. Res-ponde con los detalles de la reserva.

suo_inv , sobu_inv: Reciben los datos del estudiantey fechas de la estancia. Registra al estudianteen el sistema y responde con el resultado.spago:: Recibe los detalles de la cuenta y lacuantía ingresada o adeudada. Responde conel resultado.

4.1.2. Acciones compensatoriascbeca: Cancela la beca otorgada e intenta con-cedérsela a otro estudiante.cuo_uni , cobu_uni: Cancela la aceptación del estu-diante.cuo_res , cobu_res: Cancela la reserva y notifica aPago.cuo_inv , cobu_inv: Da de baja al estudiante delsistema.cpago: Pago cancela la operación.

4.1.3. Estados inicialesσbeca: El servicio debe haber recibido los datosdel estudiante, duración de la estancia y lainformación de la universidad destino.σuo_uni , σobu_uni: Debe haber recibido la pro-puesta del estudiante.σuo_res , σobu_res: Debe haber recibido los datospersonales del estudiante, fechas de la reservay la aceptación de la universidad.σuo_inv , σobu_inv: Debe haber recibido los datospersonales del estudiante, fechas de la estan-cia y la aceptación de la universidad.σ*

pago: La cuantía de la beca debe haber sidodepositada en la cuenta del estudiante. Elpago de la residencia de estudiantes ha sidocargado en la misma cuenta.

4.1.4. Estados ejecutadosσ*

beca: El servicio debe haber notificado ladecisión. Si fue concedida, ha notificado Pagopara la transferencia del dinero.σ*

uo_uni , σ*obu_uni: Debe haber recibido la pro-

puesta del estudiante. Se ha almacenado en elsistema y se ha respondido con la decisióntomada.σ*

uo_res , σ*obu_res: Debe haber notificado el resul-

tado sobre la reserva. Si había habitacionesdisponibles, se registra la reserva acorde conlas fechas recibidas.σ*

uo_inv , σ*obu_inv: El estudiante debe haber sido

dado de alta en el sistema. Se ha creado unperfil y una cuenta de correo usando sus datospersonales. Ha notificado el resultado.σ*

pago: La cuantía de la beca ha sido ingresadaen la cuenta del estudiante. El pago de lareserva del alojamiento ha sido cargado en lamisma cuenta.

4.1.5. Estados compensadosσ’beca: La beca debe haber sido registrada comocancelada en el sistema de becas. Si existealgún estudiante esperando por una y el plazoestá aun abierto, la aplicación ha comenzadoun nuevo proceso de otorgación de beca.σ’uo_uni , σ’obu_uni: El estudiante aceptado debehaber sido borrado del sistema. Si había algúnestudiante rechazado, se puede reabrir algúnproceso para una nueva aceptación.

Figura 3. Relación y orden de ejecución de las subtransacciones.


secciones técnicas Estándares Web

secciones técnicas

σ’uo_res , σ’obu_res: La reserva de la habitacióndebe haber sido cancelada y aparecer comodisponible en el sistema. Pago debe haber sidonotificado.σ’uo_inv , σ’obu_inv: El usuario debe haber sidodado de baja en el sistema, quedando anuladosu perfil y correo.σ’pago: Si el cobro del alojamiento no habíasido cargado aun, debe haber sido anulado.En otro cado, el dinero debe haber sido reem-bolsado. Si el dinero ya había sido ingresado,el servicio debe haber devuelto esa cuantía.

5. Especificación de casos de pruebapara la propiedad de recuperaciónSe define riesgo como un evento indeseadoque representa una amenaza para el correctofuncionamiento de un proceso [4]. El análisisde riesgos es una técnica usada para investigarproblemas y proponer medios para mitigarsus daños. Aunque originalmente fue usadaen industrias como la nuclear o espacial,actualmente también es usada en el desarro-llo de software donde la seguridad puede sermuy importante [3]. Nuestro enfoque usaFTA para derivar jerárquicamente escenariosde riesgo durante el ciclo de vida de una wT.Cada propiedad del sistema es la raíz de unárbol de riesgos que se elabora determinandolas posibles causas hasta alcanzar escenariosindividuales [9].

La figura 4figura 4figura 4figura 4figura 4 ilustra una parte del árbol deriesgos para la propiedad Recuperaciσn. Elárbol comienza con el riesgo principal (falloen el proceso de compensación) que puedeocurrir debido a diferentes causas: la accióncompensatoria no se ha ejecutado (2), se haejecutado de forma incorrecta (3), o hubo unproblema con los mensajes de compensación(4). Para ilustrar este trabajo extendemos larama derivada del nodo (4) hasta alcanzarnodos hoja que serán usados en los siguientesapartados para definir casos de prueba.

El riesgo (4) puede ser debido a problemascon los mensajes del participante (5) o delcoordinador (6). Los problemas con el par-ticipante son: que no reciba el mensaje derecuperación (7), lo reciba cuando no debería(8) o que se reciba con el timeout cumplido(9). Cuando un participante tiene problemasal recibir los mensajes de compensación pue-de ser a que lo recibió estando en un estadoinadecuado y ejecutando erróneamente laacción compensatoria. Significa que el parti-cipante recibe el mensaje sin haber ejecutadosu sub-transacción (10), el participante lorecibe y ya ha abandonado su participación enla transacción (11), lo recibe cuando ya haejecutado la compensación (12) o lo recibecuando no es necesario ejecutar ninguna (13).

Una de las posibles si-tuaciones identifica-das en (10) es que elparticipante esté en elestado failing (14).Esta situación signifi-ca que el participantemientras estaba ejecu-tando su subtran-sacción, alcanzó el es-tado failing debido a laaparición de un fallo.

Una posible situa-ción basada en (11)es que el mensaje decompensación se re-cibe tras la confirma-ción de que la ejecu-ción de su subtran-sacción fue correcta,estando, por tanto, enel estado ended. Elresto de nodos seríandesarrollados de lamisma manera.

Los nodos hojas representan situaciones deposible riesgo que deberían ser probadas.Siguiendo la derivación jerárquica de las cau-sas se pueden definir fácilmente especificacio-nes de casos de prueba para aplicaciones queusan WS-BA. En los siguientes apartados seusan los nodos hojas (14) y (15) para definircasos de prueba para SerEs.

5.1. Escenario failingEste escenario de riesgo se refiere a un partici-pante que ha recibido el mensaje de compensa-ción cuando está en el estado failing (nodo hoja14). Significa que ocurrió un problema mien-tras estaba ejecutando su subtran-sacción, porlo que su acción pudo no haber terminadocompletamente. Si ejecuta la acción com-pensatoria ocurriría que algunas característicasde la subtransacción se desharían cuando real-mente no habían sido realizadas.

En el ejemplo de SerEs se ve la necesidad decomprobar esta situación. La figura 5figura 5figura 5figura 5figura 5 presen-ta el caso de prueba acorde a este riesgo paraevitar que un nuevo estudiante sea aceptadocuando no es posible. Imaginemos que el servi-cio UO_uni notifica un fallo mientras estabaestudiando una propuesta pero, indistintamen-te, no hay plazas disponibles para nuevos estu-diantes. El estudiante original no fue aceptadopero debido a la acción compensatoria ejecuta-da tras la recepción del mensaje, el servicionotifica a un nuevo estudiante su aceptación.Este nuevo estudiante podría rechazar otrasuniversidades creyendo erróneamente que teníaplaza en esta universidad.

5.2. Escenario endedEste escenario se refiere a un participante queha finalizado correctamente su transacción

Figura 4. Árbol de fallos.

Figura 5. Caso de prueba para SerEs según el escenario failing.



secciones técnicas

(nodo hoja 15). Por tanto recibe el mensaje decompensación cuando está en el estado ended.Podría ocurrir debido a un problema delcoordinador, pero el participante debe estarpreparado para ignorar este mensaje ya que silo acepta, la subtransacción sería compensa-da. La figura 6figura 6figura 6figura 6figura 6 muestra un caso de pruebapara SerEs siguiendo este escenario.

Este fallo podría causar que una vez la tran-sacción haya finalizado, el servicio OBU_invborre de su sistema al estudiante. Dado queel participante está en el estado ended, elprotocolo no permitirá notificar esta acciónasí que aparentemente la transacción se com-pletó correctamente. Si OBU_inv ejecuta laacción compensatoria, se borrará el perfil deusuario perdiendo sus correos electrónicos,documentos de trabajo, etc.

6. Trabajos relacionadosLa mayoría de trabajos abordan el modeladode transacciones desde una perspectiva dediseño [1][6]. Chalin [10] usa casos de usospara definir los requisitos transaccionales,mientras que Banagala [2] propone usarProblem Frames Approach.

A diferencia de esos trabajos, nosotros pro-ponemos un sencillo modelo para la defini-ción de requisitos transaccionales en unatransacción WS-BA, facilitando además laderivación de los casos de pruebas.

No se han encontrado trabajos específicospara la prueba de aplicaciones basadas enWS-BA. Algunos esfuerzos existentes estáncentrados en la verificación formal. Lanotte

[16] desarrolló unmodelo para descri-bir transacciones delarga ejecución y laverificación automá-tica de propiedadesusando modelchecking. Emmi [12]propone traducirprocesos con accio-nes compensatoriasen un árbol autσmatapara verificar la ilu-sión de atomicidad.Li [17] presenta unmodelo para la verifi-cación de requisitosde atomicidad relaja-da usando restriccio-nes temporales.

Este trabajo estudiala viabilidad de un en-foque práctico encontraste con otrasinvestigaciones don-de se usan modelosteóricos para una ve-

rificación formal. Nuestro enfoque se basa enla identificación de escenarios de riesgo dondese deben aplicar pruebas dinámicas, siendo elobjetivo la especificación de casos de pruebapara el estándar WS-BA.

7. ConclusionesHemos presentado un enfoque práctico parala prueba de la recuperabilidad en transaccio-nes según el estándar WS-BA. Este trabajopropone un sencillo modelo para la especifi-cación de loa requisitos funcionales. Loscasos de prueba se definen siguiendo losescenarios alcanzados tras un análisis deriesgo usando FTA. La viabilidad de esteenfoque se ilustra con un caso de estudio.Dado que las transacciones se basan en ser-vicios independientes, el objetivo de esta líneade investigación es mejorar las pruebas en lafase de integración. Se necesita más investiga-ción para analizar la relación y complemen-tariedad de este enfoque con otras técnicas.

Un trabajo a corto plazo es ejecutar los casosde prueba definidos en una implementación[15] para medir su calidad. Se trabajará tam-bién en la mejora del modelo para hacerloindependiente del estándar utilizado. El obje-tivo es definir un modelo abstracto que inclu-ya la definición de los requisitos así como losriesgos identificados, facilitando la genera-ción de casos de prueba.

AgradecimientosEste trabajo fue parcialmente financiado por elMinisterio de Ciencia y Tecnología, España,Programa Nacional I+D+I, proyecto Test4DBS(TIN2010-20057-C03-01) y por la beca BES-2008-004355.

Figura 6. Caso de prueba para SerEs según el escenario ended.

Referencias

[1] M. Alrifai, P. Dolog,W. Nejdl. TransactionsConcurrency Control in Web Service Environment.ECOWS, 2006.[2] V. Banagala. Analysis of transaction problemsusing the problem frames approach. IWAAPF, 2006.[3] J. Bennett, G. Bohoris, E. Aspinwall, R. Hall.Risk analysis techniques and their application tosoftware development. EJOR, 1996, 95, pp. 467-475.[4] A. Benoit, M. Patri, S. Rivard. A framework forinformation technology outsourcing risk management.ACM SIGMIS Database, 2005, 36, pp. 9-28.[5] OASIS. Business Transaction Protocol: An OA-SIS Committee Specification, Version 1.0, June2002, <http://www.oasis-open.org/committees/download.php/1184/2002-06-03.BTP_cttee_spec_1.0.pdf >.[6] M. Butler, C. Ferreira , M. Ng. Precise modelingof transactions and its application to BPEL. Journalof Universal Computer Science, 11, 2005.[7] G. Canfora, M. Di Penta. Service-Orientedarchitectures testing: a survey. LNCS, 2009, 5413,pp. 78-105.[8] R. Casado, J. Tuya. "Testing transactions inservice oriented architectures", ICWE, DC, 2009.[9] R. Casado, J. Tuya, M. Younas. Testing long-lived web services transactions using a risk-basedapproach. QSIC, 2010.[10] P. Chalin, D. Sinning, K. Torkzadeh. Capturingbusiness transaction requirements in use casemodels. ACM SAC, 2008.[11] F. Curbera, R. Khalaf, N. Mukhi, S. Tai, S.Weerawarana. The next step in web services.Communications of the ACM, 2003, 46, pp. 29-34.[12] M. Emmi, R. Majumdar. Verifying compensatingtransactions. LNCS, 2007, 4349, pp. 29-43.[13] H. Garcia–Molina, K. Salem. Sagas. ACMSIGMOD, 1987, 16, pp. 249-259.[14] C. Guidi, R. Lucchi, M. Mazzara. A formalframework for web services coordination. ElectronicNotes in Theoretical Computer Science, 2007, 180,pp. 55-70.[15] JBoss Community. <http://www.jboss.org/jbosstm>.[16] R. Lanotte, A. Maggiolo-Schettini, P. Milazzo,A. Troina. Design and verification of long-runningtransactions in a time framework. Science of ComputerProgramming, 2008, 73, pp. 76-94.[17] J. Li, H. Zhu, J. He. Specifying and verifying webtransactions. LNCS, 2008, 5048, pp. 149-168.[18] W. Vesley, F. Goldberg, N. Roberts, D. Haasl.Fault tree handbook. NUREG-0492, U.S. NuclearRegulatory Commission, 1981.[19] OASIS. Web Service Atomic Transactions,<http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-os/wstx-wsat-1.2-spec-os.html>.[20] OASIS. Web Service Business Activity, <http://docs.oasis-open.org/ws-tx/wstx-wsba-1.2-spec-os/wstx-wsba-1.2-spec-os.html>.[21] OASIS. Web Services Composite ApplicationFramework, <http://docs.oasis-open.org/ws-caf/ws-context/v1.0/OS/wsctx.html>.[22] OASIS. Web Service Coordination, <http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-os/wstx-wscoor-1.2-spec-os.html>.[23] OASIS. WS-BPEL, <http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html>.[24] M. Younas, K. Chao, C. Lo, Y. Li. An efficienttransaction commit protocol for composite webservices. AINA, 2006, 1, pp. 591-596.

novática nº 211 mayo-junio 201166 secciones técnicas

refe

renc

ias

auto

rizad

as

Las habituales referencias que desde 1999 nos ofrecen los coordina-dores de las Secciones Técnicas de nuestra revista pueden consultarseen <http://www.ati.es/novatica>.

Sección Técnica "Acceso y recuperación de información"(José María Gómez Hidalgo, Manuel J. Maña López)

Tema: Tema: Tema: Tema: Tema: Taller y colección de datos sobre correcciones ortográficasen búsquedas

Muchos estamos ya habituados a ver sugerencias de Google talescomo: "Quizá quiso decir…". En realidad, esta sugerencia tan útil nopasa de ser un simple corrector ortográfico de búsquedas, contecnología algorítmicamente más simple que, por ejemplo, la correc-ción ortográfica de programas como Open Office Writer o MicrosoftWord. Sin embargo, el método está soportado por los datos acumu-lados de trillones de búsquedas y el análisis del índice de Google.Precisamente Google publicó en 2006 una serie de datos de sus índices,y que utilizan en su traductor automático, en el corrector y en otrostemas. Se trata de un listado de N-gramas (secuencias de N palabras)que aparecen en páginas Web, y sus frecuencias de aparición, paradistintos idiomas (incluyendo el español). Es un corpus de variosGigabytes que se descarga directamente de su Web: <http://googleresearch.blogspot.com/2006/08/all-our-n-gram-are-belong-to-you.html>.

Microsoft Research ha propuesto recientemente una iniciativa rela-cionada, en la que proporciona un corpus extraído de la colecciónTREC 2008 Million Query Track preparado para desarrollar y evaluaralgoritmos de corrección ortográfica de búsquedas. También se haorganizado una competición de algoritmos y un taller para presentarlos resultados de la misma, donde la evaluación final de los algoritmosse realiza sobre búsquedas reales en Bing: <http://web-ngram.research.microsoft.com/spellerchallenge/Default.aspx>.

Tema: Tema: Tema: Tema: Tema: Colletta: una herramienta para búsquedas de escritoriobasada en etiquetas

En los últimos años, la explosión de información se ha extendido deInternet y los medios hasta alcanzar nuestro propio escritorio.¿Cuántas veces hemos acabado desistiendo de encontrar un docu-mento importante en una maraña de carpetas locales y correos? Parasolucionar este tipo de problemas, raramente aliviados por losbuscadores integrados en el escritorio del sistema operativo, hansurgido proyectos y sistemas como Copernic <http://www.copernic.com/>, o la propia búsqueda de Google Desktop Search<http://desktop.google.com/>. Siguiendo esta línea, el proyectoColletta es un prototipo desarrollado por Microsoft ResearchCambridge (MSRC) para ayudar a administrar documentos y otrosrecursos que se utilizan en el puesto de trabajo. Este sistema permiteetiquetar archivos de documentos, carpetas, imágenes, correos elec-trónicos, páginas web y otros objetos. A continuación, se puedeacceder a ellos sin tener que navegar por el sistema de archivos, buscaren Internet, o en las carpetas de correo electrónico.

Colleta permite crear etiquetas que hacen referencia a las actividades,personas, lugares, eventos, etc. Puede asociar múltiples etiquetas alos documentos. El sistema se integra con la mayoría de aplicacionesde Microsoft Office. Para otras aplicaciones, sólo hay que arrastrary soltar un archivo en una etiqueta. Se puede acceder a todas lasetiquetas y los recursos etiquetados de la barra del escritorio Collettao las barras de herramientas Colletta incluidas en Office. <http://research.microsoft.com/en-us/um/cambridge/projects/researchdesktop/projectcolletta/default.htm>.

Sección Técnica "Auditoría SITIC"(Marina Touriño Troitiño, Manuel Palao García-Suelto)

Tema: Tema: Tema: Tema: Tema: Cloud Computing

La divulgación de los procesos de TI bajo un esquema de "cloudcomputing", o de "computación en la nube" se está realizandovertiginosamente, de forma muy similar a las noticias que aparecenen los foros y chats de Internet. Ya se sabe, todo lo que se publica enInternet y si todo el mundo habla de ello (en este caso el sector de TI),es lo que prima. En definitiva, todos hablamos de "cloud computing",pero ¿sabemos realmente de qué estamos hablando? ¿Cuántos denosotros tienen experiencia real y prologada en este tema?

Hoy en día no se sabe muy bien cuán extendida está la contrataciónexterna de este servicio (hay entidades que ya tienen "internamente",con sus propios recursos de TI, un esquema similar de trabajo).Tampoco podemos distinguir con precisión si todos los proveedoresde estos servicios hablan de lo "mismo", es decir si su oferta implicael mismo alcance, procesos y almacenamiento, y un largo etcétera.

Sin dejar de lado el tema de la seguridad y recuperación de los datos,que hasta ahora se "presuponen", pero que no suelen ser específicosen los contratos de "adhesión" de muchos ofertantes de estos servicios(contratos unilaterales). Y sin olvidarnos una cuestión "colateral",pero no menos importante, la transferencia de datos personales fuerade la UE: ¿dónde se alojan realmente los datos?

En los próximos meses, revisando las posibilidades solo en España,se ofrecen decenas de seminarios, charlas, presentaciones relaciona-das con este tema. En su mayoría con una alta participación deproveedores de esta nueva tipología de servicios, de proveedores deseguridad, y de profesionales jurídicos (por cierto en casos de con-trataciones online, ¿cuáles serán los tribunales de referencia en casode reclamaciones, ¿también estarán en la nube?).

En resumen, son muchas las inquietudes con respecto a los serviciosde cloud computing, y por esa razón la aparición de la revista "CloudComputing", <www.revistacloudcomputing.com>, es una muy buenanoticia. Es una buena noticia por muchas razones, entre las que seencuentran:a) Está dirigida por una persona independiente y con una larga yreconocida experiencia en TI, nacional e internacional, FernandoPiera,b) Su suscripción es gratuita,c) Tiene artículos de fondo o editoriales, y además entrevistas a todotipo de profesionales, que esperamos en el futuro se expandan nosolamente a "proveedores o consultores" de tecnologías relacionadascon esta modalidad de los procesos en TI, sino también a "clientes ousuarios" con experiencia en estos temas, para poder contrastarrealidad versus ofertas.

Por lo tanto, hay que dar la bienvenida a la revista que nos puede ayudarmucho a ir desentrañando una serie de dudas que aún están "en la nube".

Fernando Piera dice en uno de sus editoriales: "Aunque la nubeproporciona muchos beneficios para las organizaciones usuarias,también expone los datos y los sistemas a una serie de riesgos.Cualquier organización, antes de entrar a trabajar en la cloud se debeasegurar de que las medidas de seguridad necesarias sean adoptadas."

Y la siguiente pregunta es "cómo se van a calcular los beneficioseconómicos" del uso externalizado de esta tecnología.

Seguiremos atentos a los artículos publicados en esta revista, de fácilacceso, y damos la enhorabuena a su creación.

Sección Técnica "Derecho y Tecnologías"(Elena Davara Fernández de Marcos)

Tema: Tema: Tema: Tema: Tema: Memoria de 2010 que resume la actividad de la APDCM

El derecho fundamental a la protección de datos está garantizado y

novática nº 211 mayo-junio 2011 67secciones técnicas

referencias autorizadas

controlado por la labor de los organismos nacionales y autonómicoscreados al efecto. En el caso de Madrid y dependiendo de la tipologíade los ficheros, el ciudadano puede acudir a la Agencia Española deProtección de Datos o a la Agencia de Protección de Datos de laComunidad de Madrid (APDCM). Y precisamente en relación con laactividad de la Agencia madrileña se ha publicado recientemente laMemoria de actividad del pasado año 2010 en la misma.

Por lo que se refiere a algunos datos relevantes desprendidos delcontenido de la citada Memoria, cabe destacar que el total de ficherosinscritos activos en la Comunidad de Madrid ha sido de 13.965, un1,47% más que en 2009, pero un 11% menos que en 2008. Los ficherosregistrados activos pueden pertenecer a tres tipos de administración:las Administraciones de la Comunidad de Madrid, las personasJurídico-Públicas, o las Entidades Locales. En el año 2010, el númerode ficheros registrados activos propiedad de los sujetos recién men-cionados y en ese mismo orden son: 9.768, 362, 3.835. Con respectoa 2009 estas cifras representan unas variaciones del -1,15%, 6,19%, y10,67% respectivamente. Resulta particularmente llamativo el increí-ble incremento de inscripciones en los últimos 5 años por parte de laspersonas Jurídico-Públicas y de las Entidades Locales: 152 y 236 sonlos tantos por ciento que han aumentado las inscripciones activas porparte de estos dos sujetos de derecho.

Respecto a las finalidades de los ficheros inscritos destacan sobre elresto la de Procedimientos Administrativos, seguida de la de finesHistóricos, Estadísticos, o Científicos, y la de funciones EstadísticasPúblicas. Por último y por lo que se refiere a la actitud de losciudadanos, cabe destacar que durante el pasado año se atendieron1.800 consultas de ciudadanos, realizadas por teléfono y por víaelectrónica, solicitando información de carácter general y sobre elejercicio de sus derechos en protección de datos, <http://www.madrid.org/cs/Satellite?c=PAPD_Generico_FA&cid=1142646717273&language=es&pagename=PortalAPDCM%2FPAPD_Generico_FA%2FPAPD_ficha Publicacion>.

Tema:Tema:Tema:Tema:Tema: Nueva regulación del "servicio universal" en España

La ley 2/2011, de 4 de marzo, de Economía Sostenible incorporónumerosas novedades en materia de protección de datos, comercioelectrónico y propiedad intelectual, entre otras cuestiones relaciona-das con el sector de las Tecnologías de la Información y las Comu-nicaciones. En este sentido, es de destacar el artículo 52 de la conocidacomo "Ley Sinde" donde se exigía la concreción de los términos deincorporación de la banda ancha en el servicio universal así como lanecesidad de transponer los cambios introducidos en el marco delservicio universal por la Directiva 2009/136/CE. Y es en este puntodonde aparece el Real Decreto 726/2011 que modifica el Reglamentosobre las Condiciones para la prestación de servicios de comunicacio-nes electrónicas, el servicio universal y la protección de los usuarios.

Por lo que se refiere al contenido concreto del Real Decreto, el nuevoReglamento incluye dentro del concepto de servicio universal, o lo quees lo mismo dentro del "conjunto definido de servicios cuya prestaciónse garantiza para todos los usuarios finales con independencia de sulocalización geográfica, con una calidad determinada y a un pecioasequible", la banda ancha con conexión a Internet de velocidad de, almenos, 1 Mbit por segundo. Entre las principales novedades del RealDecreto destaca la inclusión como obligación para el operador deofrecer a todos los usuarios, si así lo desean, una media de velocidaden su conexión de al menos un Mbit por segundo. Asimismo, seincorpora en la nueva normativa la posibilidad de tener contratadosdos operadores diferentes para los servicios de conexión a Internet ytelefonía.

Por último, comentar que el objetivo de la nueva normativa es que eloperador de telecomunicaciones cumpla con la obligación de ofreceral ciudadano una cobertura de calidad a todos los usuarios finales,con independencia de su localización geográfica y a un precio asequi-

ble. <http://www.boe.es/boe/dias/2011/05/24/pdfs/BOE-A-2011-9012.pdf>.

Tema:Tema:Tema:Tema:Tema: España sigue entre los países con mayor nivel de piratería

La protección de datos de carácter personal y el comercio electrónicoson cuestiones que ocupan un lugar prioritario dentro del Sector TIC;sin embargo, la propiedad intelectual y la defensa de los derechos deautor es la cuestión que, en los últimos años, ha estado (y aún está)en boca de todos por la cantidad de agentes implicados, la dificultadde regularlo y las recientes leyes de diversos Estados Miembros parareducir (e intentar erradicar de manera definitiva) la piratería de loscontenidos protegidos por derechos de autor.

En el caso de España y pese a la publicación de la Ley de EconomíaSostenible el pasado mes de marzo, la piratería es una realidad muyarraigada. Así lo acredita un reciente informe elaborado por senadoresy miembros de la Cámara de Representantes de EEUU y que colocaa España dentro de los países con más piratería del mundo entre losque destacan Canadá, China, Rusia y Ucrania. Este quinto puesto enel ranking viene avalado por el alto nivel de intercambio de ficheros P2Pen nuestro país, tal y como se afirma en el denominado "CaucusAntipiratería Internacional". El hecho de pertenecer a esta lista noacarrea sanción alguna, y en el citado informe se explica que si bienEspaña se encuentra dando los pasos correctos en materia legislativapara combatir la piratería, aún carece de las herramientas necesariaspara combatir la enorme piratería que representan las descargas P2P.

Finalmente, los responsables del informe hacen un llamamiento algobierno español con la finalidad de que se comprometa a lucharcontra todos los tipos de piratería que se encuentran en la red, paralo que lanza una propuesta que no consiste sino en identificar a losusuarios más habituales del P2P y modificar la legislación para quelos titulares de derechos puedan ejercer acciones civiles contra aque-llos internautas que reincidan en la conducta ilícita. <http://www.lavanguardia.com/internet/20110602/54164682411/ee-uu-situa-a-espana-en-el-top-5-mundial-de-la-descarga-ilegal-de-archivos.html>.

Tema:Tema:Tema:Tema:Tema: Disponibles los certificados de matrimonio y nacimiento víaelectrónica

Hoy en día y desde la publicación de la Ley 11/2007 de manera especial,los ciudadanos reclaman una mayor presencia de las TIC en elconjunto de la Administración, de modo que les permita relacionarsepor vía electrónica en lugar de hacer uso de los medios "tradicionales".Buena muestra de ello es que ya se puede afirmar que la Administra-ción electrónica es una realidad en nuestro país que, poco a poco, vaadquiriendo más protagonismo a través de la incorporación de lasTIC a los diversos trámites y gestiones que los ciudadanos han dehacer con los diversos Ministerios, Ayuntamientos y demás entidadespúblicas, formando así una cultura del uso de las TIC en la Adminis-tración que, además de fomentar el cumplimiento de lo dispuesto porla Ley 11/2007, redunda en beneficio de los ciudadanos por el ahorrode tiempo y papeleo. Si bien son muchos los ejemplos que se puedendestacar, traemos a colación una medida que ha decidido incorporarel Ministerio de Justicia y que afectará a millones de españoles que,por diversos motivos, han de solicitar la expedición de su certificadode matrimonio o nacimiento. Y es que, gracias a esta modernizacióndel Ministerio de Justicia, el Registro Civil podrá expedir, vía telemática,las certificaciones de nacimiento y de matrimonio.

Conviene tener en cuenta que no se trata de la primera iniciativa quese adopta en este sentido puesto que ya desde enero del presente añoexiste la posibilidad de pedir por este mecanismo los certificados deúltimas voluntades, de antecedentes penales y de cobertura de segu-ros. Además, se puede afirmar que su aceptación ha sido más quepositiva ya que en cinco meses se han expedido más de 350.000certificaciones, con el consecuente ahorro de tiempo y papel.


refe

renc

ias

auto

rizad

as

Por último, destacar que los únicos requisitos para hacer uso de lamodalidad electrónica de solicitud es disponer de un ordenador conconexión a Internet y un DNI electrónico, siguiendo los pasos que seindican en el sitio web. <http://www.elpais.com/articulo/sociedad/certificados/nacimiento/matrimonio/traves/Internet/elpepusoc/20110601elpepusoc_13/Tes>.

Sección Técnica "Entorno Digital Personal"(Diego Gachet Páez, Andrés Marín López)

Tema:Tema:Tema:Tema:Tema: Elementos claves en la recuperación de información utilizan-do dispositivos móviles

La recuperación de información a través de dispositivos móviles noes más que un subconjunto de la recuperación de informaciónmediante ordenador, aunque las especiales características de losdispositivos móviles hacen que esta tarea en algunas ocasiones seamás avanzada y otras más primitiva que cuando hablamos de unordenador clásico.

Existen dos conceptos que son clave cuando hablamos de recupera-ción de información mediante dispositivos móviles, uno es la Adap-tación de Contenido y el otro la Atención al Contexto. En un sentidoamplio el primer concepto se refiere a presentar en el dispositivo lainformación de una forma adecuada al usuario y el segundo corres-ponde a analizar la respuesta que se da al usuario a través deldispositivo. La recuperación de información móvil analiza entoncestanto el contenido como el contexto para extraer información útil yrelaciones que la recuperación de información clásica no hace.

Los dispositivos móviles que están en el mercado actualmente disponende una serie de elementos que los ordenadores tradicionales no tienen,incluyendo la posibilidad de disponer de información de localización,cámaras, dispositivos sensores de movimiento, etc. Todos estos elemen-tos permiten el desarrollo de nuevas formas de recuperación de informa-ción que incluyen el tiempo, la localización y la semántica, cada día nosencontramos con más aplicaciones de búsqueda y procesamiento deinformación, específicas para dispositivos móviles, incluyendo por ejem-plo realidad aumentada, geolocalización, etc.

En cuanto a la adaptación de contenido, dado que los dispositivosmóviles tienen en general pantallas de reducido tamaño y una potenciade procesamiento limitada, los esfuerzos se dirigen a procesar y presentarde manera eficiente la información en este tipo de dispositivos. En estetema en concreto se están haciendo esfuerzos destacables que tienen quever con extracción de información basada en contenido indexado, extrac-ción de resúmenes, etc., que permiten vislumbrar en un futuro cercano laaparición de nuevas aplicaciones de búsqueda y recuperación de informa-ción para dispositivos móviles mas eficientes y personalizadas.

Sección Técnica "Informática Gráfica"(Miguel Chover Sellés , Roberto Vivó Hernando)

Tema: Tema: Tema: Tema: Tema: Gráficos 3D con aceleración hardware para Internet

La creación de contenidos gráficos para la Web con inclusión de lasúltimas técnicas en realismo visual será una realidad en los próximosaños. Por un lado con el desarrollo de WebGL que mantiene el grupoKhronos y por otro con la nueva API Molehill que va a presentar Adobeen los próximos meses.

La principal ventaja de WebGL es que se usará en el nuevo canvas dellenguaje HTML 5. Además se ha adelantado en su aparición, ya quela especificación de la versión 1.0 se presentó en febrero de 2011. Laejecución de contenidos en 3D tampoco necesitará de ningún pluginsalvo, probablemente, en el Internet Explorer. El soporte serámultiplataforma, funcionará en distintos navegadores y también endispositivos móviles con Android o iOS (incluyendo iPads, etc.).

Por lo que respecta a Molehill, no es una opción despreciable. El pluginde Flash está desarrollado para cualquier navegador y es usado deforma masiva en el desarrollo web. La librería se espera que inclusodisponga de mayor potencia y robustez que WebGL. La intención esque dependa de DirectX en Windows, de OpenGL 1.3 en Mac OS X yLinux, y de OpenGL ES 2 en las plataformas móviles con Android. Laprimera versión estará disponible con la versión 11 del Flash Player.

En cualquier caso, las dos nuevas librerías son de bajo nivel y en elcontexto de la creación de contenidos será necesario utilizar aplica-ciones y herramientas de autor. En este sentido, han aparecido un grannúmero de motores de juegos que se han desarrollado para usarMolehill como: Alternativa3D, Away3d, CopperCube, Flare3D,Minko, Sophie3D o Yogurt3D. Incluso Unity 3D, uno de los motoresde juegos más usado en el desarrollo web, modificará su plugin parasoportar la librería de Adobe. Lo que nos deparará el futuro es difícilde saber, pero seguro que independientemente de la tecnología queusemos, la Web en 3D será una realidad dando lugar a la apariciónde mundos virtuales que explorar, de forma social y con la últimatecnología de los videojuegos.

Sección Técnica "Ingeniería del Software"(Javier Dolado Cosín, Daniel Rodríguez García)

Tema: Tema: Tema: Tema: Tema: Libros

Peter Smith.Peter Smith.Peter Smith.Peter Smith.Peter Smith. Software Build Systems: Principles and Experience.Addison-Wesley Professional, 583 páginas, 2011. Libro que presenta demanera exhaustiva las cuestiones relativas al proceso de desarrollo de"build systems". A quien le suene raro el término "build system" seguroque encuentra más familiaridad con los términos Ant, SCons, CMake,GNU Make y algún otro y nos estamos refiriendo a las maneras deorganizar procesos que automáticamente nos van a construir un sistemasoftware ejecutable. Este libro nos acerca de manera muy detallada a estostemas a través de sus 19 capítulos: Build System Overview, A Make-basedbuild system, the runtime view of a program, Make, Ant, Eclipse, etc.Recomendable para entender qué es lo que sucede cuando utilizamos"make" o recompilamos una aplicación en nuestro ordenador.

Nuevos libros sobre CMMI del Software EngineeringNuevos libros sobre CMMI del Software EngineeringNuevos libros sobre CMMI del Software EngineeringNuevos libros sobre CMMI del Software EngineeringNuevos libros sobre CMMI del Software EngineeringInstitute.Institute.Institute.Institute.Institute. El SEI ha publicado recientemente tres libros que especia-lizan los conceptos ya conocidos de CMM a tres áreas distintas:adquisición de software, servicios y desarrollo. Los tres libros contie-nen ideas sobre la mejora de procesos que en algunos casos sonidénticas, pero en otros casos están orientadas a los distintos obje-tivos de cada disciplina.Brian Gallaguer, Mike Phillips, Karen Richter, SandraBrian Gallaguer, Mike Phillips, Karen Richter, SandraBrian Gallaguer, Mike Phillips, Karen Richter, SandraBrian Gallaguer, Mike Phillips, Karen Richter, SandraBrian Gallaguer, Mike Phillips, Karen Richter, SandraShrum.Shrum.Shrum.Shrum.Shrum. CMMI for Adquisition: Guidelines for Improving theAcquisition of Products and Services, 2nd Edition. Addison-WesleyProfessional, 2011. Este libro está orientado a las empresas quetrabajan con proveedores de productos o servicios.Mary Beth Chrissis, Mike Konrad, Sandra Shrum.Mary Beth Chrissis, Mike Konrad, Sandra Shrum.Mary Beth Chrissis, Mike Konrad, Sandra Shrum.Mary Beth Chrissis, Mike Konrad, Sandra Shrum.Mary Beth Chrissis, Mike Konrad, Sandra Shrum. CMMIfor Development. Guidelines for Process Integration and ProductImprovement, 3rd Edition, Addison-Wesley Professional, 2011. Orien-tado a las empresas que se centran en el desarrollo de productos yservicios.Elleen Forrester, Brandon Buteau, Sandra Shrum.Elleen Forrester, Brandon Buteau, Sandra Shrum.Elleen Forrester, Brandon Buteau, Sandra Shrum.Elleen Forrester, Brandon Buteau, Sandra Shrum.Elleen Forrester, Brandon Buteau, Sandra Shrum. CMMIfor Services. Guidelines for Superior Service, 2nd Edition. Addison-Wesley Professional, 2011. Orientado a las empresas que se encargande establecer, gestionar y entregar servicios.

Sección Técnica: "Lenguajes de Programación"(Oscar Belmonte Fernández, Inmaculada Coma Tatay)

Tema: Tema: Tema: Tema: Tema: Nace shema.org

Que los buscadores sean la página de inicio seleccionada por muchos

novática nº 211 mayo-junio 2011 69secciones técnicas

referencias autorizadas

usuarios al iniciar su navegador no es casual. En un gran número deocasiones utilizamos un buscador para encontrar información sobreun término en Internet.

Uno de los desafíos actuales en la web es cómo añadir semántica alcontenido de las páginas web para que la información que en ellasaparece pueda ser analizada de forma automática por herramientasinformáticas, como por ejemplo, un buscador.

Conscientes de este problema, tres de los grandes proveedores debuscadores en Internet (Google, Yahoo y Microsoft) se han aliadopara fomentar el etiquetado semántico en páginas web a través deshema.org. La finalidad es proporcionar a los creadores de contenidoen Internet un vocabulario con el que poder añadir contenido semánticoa las páginas escritas en HTML. Así, este vocabulario ayudará a losmotores de búsqueda a clasificar la información que aparece en laspáginas web.

Tema: Tema: Tema: Tema: Tema: Comparación entre lenguajes de programación

Aprovechando el Scala Days 2011, Google ha publicado un artículocomparando diversos aspectos de algunos lenguajes de programa-ción. Dos de ellos son lenguajes que ya podemos considerar clásicoscomo C++ y Java y los otros dos los podemos entrecomillar de"modernos" como Scala y Go. Desde nuestro punto de vista lacomparación hay que cogerla con pinzas, sobre todo la relativa a lasección de rendimiento, en la que, según este artículo, Java tiene untiempo de ejecución casi seis veces mayor que C++.

De todos modos el lenguaje de programación Scala es una aproxima-ción muy interesante al intento de unir los lenguajes de programaciónfuncionales y orientados a objetos, <http://code.google.com/p/multi-language-bench/>.

Tema: Tema: Tema: Tema: Tema: Libro

Desde estas líneas, ya hemos comentado la revolución que va asuponer y que ya está suponiendo la aparición de HTML5. Paraconocer las nuevas capacidades que este lenguaje de marcas va a ponera disposición de los creadores de páginas web es de gran interés el librode Peter Lubbers, Brian Albers y Frank SalimPeter Lubbers, Brian Albers y Frank SalimPeter Lubbers, Brian Albers y Frank SalimPeter Lubbers, Brian Albers y Frank SalimPeter Lubbers, Brian Albers y Frank Salim titulado ProHTML5 Programming.

En este libro se presentan muchas de las APIs que en parte ya estándisponibles en los navegadores web actuales, como por ejemplo el APICanvas, que permite el acceso directo al hardware gráfico, con lo quees posible tener integrado OpenGL en un navegador sin necesidad deinstalar ningún plugin. O el API de Audio y Vídeo, que va a permitirvisualizar vídeo sin necesidad de tener instalado el plugin de Flash.También hay capítulos dedicados al API de Geolocalización quepermitirá ubicar geográficamente un dispositivo aunque éste nodisponga de receptor GPS; el API WebSockets que permitirá establecercomunicación a través de Sockets entre cliente y servidor; y el API deAlmacenamiento que permitirá que los navegadores almacenen datosen el dispositivo cliente.

Sección Técnica "Lingüística computacional"(Xavier Gómez Guinovart, Manuel Palomar)

Tema: Tema: Tema: Tema: Tema: Curso de procesamiento del lenguaje

Steven Bird, Ewan Klein, Edward Loper. Steven Bird, Ewan Klein, Edward Loper. Steven Bird, Ewan Klein, Edward Loper. Steven Bird, Ewan Klein, Edward Loper. Steven Bird, Ewan Klein, Edward Loper. Natural LanguageProcessing with Python. Analyzing Text with the Natural LanguageToolkit. O’Reilly Media, Sebastopol, 2009, 479 páginas. ISBN 978-0-596-51649-9. Este nuevo manual de O’Reilly nos ofrece un cursopráctico y actualizado de procesamiento del lenguaje natural, ema-nado de la docencia impartida por el área de informática de laUniversidad de Pensilvania. La orientación del libro es eminentemente

aplicada, si bien también se explican de forma clara y concisa todoslos conceptos teóricos necesarios para poder seguir el curso conprovecho, incluso sin partir de un conocimiento previo de la materia.

Los capítulos del libro permiten adquirir unas sólidas competenciasen programación lingüística en Python, en los ámbitos de la compi-lación y procesamiento de corpus textuales, del etiquetado morfológicoautomático, de la clasificación de textos, de la extracción de informa-ción textual, del análisis sintáctico automático y de la comprensióndel lenguaje natural. La herramienta didáctica elegida, usada a lolargo de todo el libro en las prácticas de programación, es el paquetede recursos NLTK (Natural Language Toolkit), una distribución decódigo abierto para el procesamiento del lenguaje en Python, queincluye bibliotecas de programación para las tareas más comunes enPLN que pueden ser utilizadas por los estudiantes para escribir suspropios programas. Las tareas propuestas en las prácticas de progra-mación son de gran valor didáctico y el desarrollo escalonado de loscontenidos teóricos permite una progresión en la materia bien fundamen-tada. De este modo, el libro de Bird, Klein y Loper constituye un excelentemanual, imprescindible en cualquier curso de lingüística computacionalde orientación aplicada que adopte Python como lenguaje de programa-ción, <http://oreilly.com/catalog/9780596 516499/>.

Sección técnica "Seguridad"(Javier Areitio Bertolín, Javier López Muñoz)

Tema:Tema:Tema:Tema:Tema: Libros

E. Bertino, K. Takahashi. E. Bertino, K. Takahashi. E. Bertino, K. Takahashi. E. Bertino, K. Takahashi. E. Bertino, K. Takahashi. Identity Management. Concepts,Technologies and Systems. Artech House. ISBN 1608070398, 2011.T. Craig, M.E. Ludloff. T. Craig, M.E. Ludloff. T. Craig, M.E. Ludloff. T. Craig, M.E. Ludloff. T. Craig, M.E. Ludloff. Privacy and Big Data. O´Reilly Media.ISBN 1449305008. 2011.M.K. Denko, L. Wougang, M.K. Denko, L. Wougang, M.K. Denko, L. Wougang, M.K. Denko, L. Wougang, M.K. Denko, L. Wougang, Security in Next Generation Mobile andWireless Networks: A Collaborative Attacks Perspective. 1st Edition.Springer. ISBN 1441961623, 2011.M. Dowding. M. Dowding. M. Dowding. M. Dowding. M. Dowding. Privacy: Defending an Illusion. The Scarecrow Press, Inc.ISBN 0810881020, 2011.W.C. Easttom. W.C. Easttom. W.C. Easttom. W.C. Easttom. W.C. Easttom. Computer Security Fundamentals. 2nd Edition.QUE. ISBN 0789748908. 2011.M. Masud, L. Khan, B. Thuraisingham. M. Masud, L. Khan, B. Thuraisingham. M. Masud, L. Khan, B. Thuraisingham. M. Masud, L. Khan, B. Thuraisingham. M. Masud, L. Khan, B. Thuraisingham. Data Mining Tools inMalware Detection. Auerbach Publications. ISBN 1439854548, 2011.S. Nair, M. Marchetti, J. Hopkinson, S. Fogie. S. Nair, M. Marchetti, J. Hopkinson, S. Fogie. S. Nair, M. Marchetti, J. Hopkinson, S. Fogie. S. Nair, M. Marchetti, J. Hopkinson, S. Fogie. S. Nair, M. Marchetti, J. Hopkinson, S. Fogie. EnterpriseSecurity: Compliance v. Competence, 1st Edition. Springer. ISBN0387744347. 2011.T. Wrightson. T. Wrightson. T. Wrightson. T. Wrightson. T. Wrightson. Wireless Network Security. A Beginners Guide. McGraw-Hill Osborne Media. ISBN 0071760946. 2011.

Tema: Tema: Tema: Tema: Tema: Congresos, conferencias, symposiums

Eurocrypt ‘2012.Eurocrypt ‘2012.Eurocrypt ‘2012.Eurocrypt ‘2012.Eurocrypt ‘2012. Del 15 al 19 de abril 2012. Cambridge, UK.AISC ‘2012 (Australasian Information SecurityAISC ‘2012 (Australasian Information SecurityAISC ‘2012 (Australasian Information SecurityAISC ‘2012 (Australasian Information SecurityAISC ‘2012 (Australasian Information SecurityConference).Conference).Conference).Conference).Conference). Del 30 enero al 3 de febrero 2012. RMIT UniversityMelbourne, Australia.CIBSI ‘2011 (Congreso Iberoamericano de SeguridadCIBSI ‘2011 (Congreso Iberoamericano de SeguridadCIBSI ‘2011 (Congreso Iberoamericano de SeguridadCIBSI ‘2011 (Congreso Iberoamericano de SeguridadCIBSI ‘2011 (Congreso Iberoamericano de SeguridadInformática).Informática).Informática).Informática).Informática). Del 2 al 4 de noviembre 2011. Bucaramang, Santander,Colombia.NDSS ‘2012 (19NDSS ‘2012 (19NDSS ‘2012 (19NDSS ‘2012 (19NDSS ‘2012 (19ththththth Network and Distributed System Security Network and Distributed System Security Network and Distributed System Security Network and Distributed System Security Network and Distributed System SecuritySymposium).Symposium).Symposium).Symposium).Symposium). Del 5 al 8 de febrero 2012. San Diego, California, USA.ICNC ‘2012. Communications and Information Security.ICNC ‘2012. Communications and Information Security.ICNC ‘2012. Communications and Information Security.ICNC ‘2012. Communications and Information Security.ICNC ‘2012. Communications and Information Security.Del 30 de enero al 2 de febrero 2012. Maui, Hawai.

Sección técnica "Sistemas de Tiempo Real"(Alejandro Alonso Muñoz, Juan Antonio de la Puente Alfaro)

Tema:Tema:Tema:Tema:Tema: Libro

Acaba de aparecer el libro Building Parallel, Embedded and Real-Time


refe

renc

ias

auto

rizad

as

Applications with Ada. Sus autores son John McCormickJohn McCormickJohn McCormickJohn McCormickJohn McCormick, FrankFrankFrankFrankFrankSinghoffSinghoffSinghoffSinghoffSinghoff y Jérôme HuguesJérôme HuguesJérôme HuguesJérôme HuguesJérôme Hugues, todos ellos bien conocidos en elmundo del lenguaje Ada. El libro contiene un resumen de la partesecuencial de este lenguaje, para centrarse a continuación en losaspectos relacionados con la concurrencia y los sistemas distribuidos,con una discusión de los modelos definidos en el anexo de sistemasdistribuidos de Ada y en el estándar CORBA. La planificación desistemas de tiempo real y las técnicas de análisis temporal son el objetode un capítulo del libro. Por último se abordan los aspectos prácticosde la programación de sistemas de tiempo real en Ada, y se describenalgunas plataformas, como MaRTE, ORK+ y RTEMS, y algunasherramientas de diseño y análisis temporal.

En suma, se trata sin duda de un texto muy útil para apoyar laenseñanza de los sistemas de tiempo real, tanto en el ámbito industrialcomo en la universidad. El libro ha sido publicado por CambridgeUniversity Press, con ISBN 978-0-521-19176-8.

Sección Técnica: "Tecnología de Objetos"(Jesús García Molina, Gustavo Rossi)

Tema:Tema:Tema:Tema:Tema: Libro

John Watkins.John Watkins.John Watkins.John Watkins.John Watkins. Agile Testing: How to succeed in an extreme testingenvironment. Cambridge University Press, 2009. En entregas anterio-res, nos hemos referido ya a los métodos ágiles y al uso de las pruebasdurante el proceso de desarrollo. Este texto, muy completo y didác-tico, aborda dicho tema desde la perspectiva de las pruebas mismas.

El libro, tal cual expresa su autor, está orientado a desarrolladores,miembros de equipos de desarrollo y pruebas, y también a investiga-dores interesados en métodos ágiles de desarrollo; incluye no solo unabuena descripción de las ideas "teóricas" sino además algunos casosde estudio reales para enfatizar dichas ideas y mostrar su practicidad.

El texto está dividido en tres partes:La primera, "Review of Old Schools and Agile Approaches" es muybreve y describe el lugar de las pruebas en el proceso de desarrollo, tantoen los enfoques más convencionales como en los modernos.

La segunda parte está planteada de manera muy original y es unconjunto de capítulos escritos por diversos autores que discutendiversos puntos de vista respecto al concepto de agilidad en base acasos de estudio reales, todos ellos descritos con el mismo formato,donde cada autor presenta su propia experiencia.

Sin embargo, cada capítulo tiene su propio interés al margen del casode estudio ya que algunos exceden el análisis del caso y son brevesensayos teóricos como el capitulo 4 "From Waterfall to EvolutionaryDevelopment and Test" mientras otros abordan los casos de estudio(muy interesantes y en dominios particularmente críticos como elcapitulo 8 "Testing a Derivatives Trading System in an UncooperativeEnvironment") en forma sucinta.

Algunos capítulos enfocan aspectos más específicos tales comocalidad, proyectos "offshore", automatización de pruebas, etc. Todoslos capítulos merecen ser leídos y representan excelentes puntos departida para profundizar en los temas específicos.

Finalmente, la tercera parte, que representa el corazón del libro, analizalos casos de estudio desde una perspectiva más abstracta demostran-do como cada proyecto puede necesitar un enfoque de pruebas ágilesparticular y de que manera "personalizar" dichos procesos.

Los apéndices presentan desde datos específicos de los casos deestudio hasta plantillas utilizables en los procesos de "agile testing"discutidos en la tercera parte del libro. Si bien el texto se hace algoextenso, es de fácil lectura y muy práctico.

Sección Técnica: "TIC y Turismo"(Andrés Aguayo Maldonado, Antonio Guevara Plaza)

Tema:Tema:Tema:Tema:Tema: Observatorio sobre Viajes e Internet

El Observatorio sobre Viajes e Internet <www.minube.com/observa-torio> nace de la iniciativa de Minube.com, en colaboración con laJunta de Comunidades de Castilla-La Mancha y con la participaciónde la empresa The Cocktail Analysis como consultora, para larealización los estudios de campo, con la misión de presentar de formasemestral las tendencias en Internet de este sector. El objetivo espresentar una perspectiva más ajustada de la nueva realidad de losviajes y compartirlo con todas las instituciones, empresas y particu-lares tanto de España como en foros extranjeros.

Hasta la fecha, se han publicado dos estudios, titulados "Tendenciasdel Nuevo Viajero" y "Tendencias en el uso de Internet en el móvil paralos viajes". El primero de ellos, presentado en junio de 2010, se hacentrado en el propio viajero y aborda los cambios de comportamientoque el viajero habitual ha experimentado con el crecimiento y desarro-llo de Internet. El uso extensivo de la Red en todas las fases del viajele ha llevado a convertirse en el canal más usado para elegir destino,así como el medio idóneo para resolver desde las cuestiones másprácticas de elección de lugares y ruta a seguir, hasta la resolución deproblemas o la creación de contenidos personales para compartir endirecto con los amigos y conocidos.

Las principales conclusiones que se desprenden de este estudioseñalan que el uso de Internet se ha extendido a la totalidad de las fasesdel viaje (elección, preparación, viaje y post viaje) y se erige comofuente más usada y fiable, sobre todo a la hora de seleccionar destinoy comunicar la experiencia del viaje, a través de las redes socialesfundamentalmente. Para el 85% de los encuestados, los amigos eInternet son la fuente de inspiración en el inicio de preparación de unviaje, aunque también tienen gran relevancia las páginas web deldestino.

Durante el viaje, el uso de Internet sigue estando por encima de otrasfuentes a la hora de buscar información. Un 55% de los usuariosacuden a la Red para recabar información durante su viaje; el 36% delos que se conectan a Internet durante su estancia lo hace a través delmóvil y 3 de cada 10 viajeros comparten su experiencia en tiempo real,sobre todo colgando fotos o videos en las redes sociales.

El segundo de los estudios, presentado en diciembre de 2010, se centraen el uso de Internet en el móvil para los viajes y concluye que ochode cada diez internautas en este tipo de dispositivos lo han incorporadoal proceso de preparación de sus viajes, así como al propio desarrollodel mismo para buscar información, cambiar en tiempo real su plande viaje, o incluso, compartir su experiencia con amigos, familiares yotros "compañeros de viaje virtuales". El móvil es la nueva brújula delos viajes para orientarse en la resolución de necesidades comoencontrar hoteles, restaurantes, actividades de ocio, ver fotos, etc.Configurar una experiencia lo más personalizada posible es el objetivoúltimo, así como registrar lo que nos sucede y compartirlo en redessociales. Como elementos que frenan en cierta medida este imparableavance, los usuarios destacan la necesidad de adaptar aún más loscontenidos a las características de los propios terminales y las tarifasde conexión en los desplazamientos internacionales.

Ambos estudios, junto con las encuestas empleadas y los datos enbruto están disponibles en la web de Minube.com.


Informática práctica sociedad de la información


1. IntroducciónEntre los diferentes métodos de cifrado utili-zados durante la Guerra Civil, uno de los másempleados por ambos contendientes fue unavariante del cifrado por tabla de homófonos:el criptógrafo de cinta. Este sistema consisteen una tabla que tiene un alfabeto ordenadoen la fila superior, bajo el que se dispone unacinta móvil con otro alfabeto doble aleatorioque encabeza las columnas de homófonos,que son las cifras de un par de dígitos quesubstituirán a las letras en el mensaje cifrado.

El emisor y el receptor del mensaje convienenuna correspondencia determinada entre unaletra de la primera fila y otra de la fila inferior,desplazando la cinta móvil para alinearlas.Entonces, para cifrar un mensaje se buscacada letra del mismo en la cinta móvil, subs-tituyéndola en el texto cifrado por uno cual-quiera de los homófonos de su columna,variación que hará menos susceptible estacifra a los intentos de ruptura mediante latécnica del análisis de frecuencias.

El 29 de julio de 1936 el general Mola envióal general Franco un radiotelegrama cifradopero con partes del texto en claro, de cuyocontenido se desprende que es un parte deoperaciones de varios teatros bélicos. Esteradio fue interceptado por los republicanos yuna copia del mismo se puede ver en el Tallerde criptografía [1], la extensa página Websobre el particular del profesor ArturoQuirantes Sierra.

El encabezado del mensaje aclara que seutiliza la clave Regidor, que es un cifradohomofónico, sin cinta móvil [2, pág. 43], demodo que las columnas de homófonos secorresponden con un único alfabeto. Vamosa intentar romper la cifra de esta comunica-ción militar utilizando un algoritmo genético,ayudándolo con algún término que podamosconjeturar a partir de los fragmentos de textoen claro.

2. Metodología2.1. Datos de partidaSupondremos que el documento que vamosa tratar de descifrar, está cifrado con una clavehomofónica, de manera que cada número dedos dígitos se corresponde con una única letraen el texto en claro, en tanto que cada letrapuede estar representada por varios números.Los cinco bloques en cifra se agruparán enuno solo para su descifrado.

Por otra parte, se observa que el últimohomófono del mensaje es el 00, que no serepite en ninguna otra posición, por lo queparece razonable suponer que se trate dealgún de indicativo de fin de comunicación,así que se considerará, en principio, que nocodifica ninguna letra.

El mensaje se presenta tal cual se publica en laWeb, no se ha investigado en los archivos mili-tares si el documento está descifrado, ni se habuscado por otros medios la clave del mismo.

2.2. Método de descifradoPara establecer esta correspondencia entrecifras y letras del alfabeto vamos a utilizar unalgoritmo genético, que es un método deataque ampliamente utilizado en el cripto-análisis moderno [3], y que, además, ya hasido aplicado al desencriptado de documen-tos cifrados durante la guerra civil [2].

Sin embargo los esfuerzos desarrollados hastael momento solo permiten atacar con éxitoaquellos documentos cifrados de los que seconozca la tabla de homófonos pero no elalfabeto de cinta móvil, es decir cuando sesabe que cifras van juntas, pero no a que letracorresponden, pues de otra manera el espaciode búsqueda resulta demasiado amplio [2,pág. 17).

Para intentar resolver esta dificultad propo-nemos un algoritmo genético con una fun-ción objetivo que valore la diferencia entre lasfrecuencias encontradas de letras y bigramasy las frecuencias esperadas procedentes de untexto de referencia. Además este algoritmotendrá un operador que permitirá vincularuna palabra o texto corto a un determinadofragmento del mensaje, de forma que si esapalabra o texto corto realmente figurase en eltexto en claro y en esa misma posición, enton-ces los homófonos correspondientes a susletras quedarían bien asignados, resolviéndo-se correctamente otras porciones del mensajey disminuyendo, en principio, la diferencia defrecuencias, mejorándose así el valor de lafunción objetivo.

El programa analizará la palabra clave, colo-cándola sucesivamente en todas las posicio-nes del texto y lanzará el algoritmo genéticopara cada una de ellas, guardando el valor dela función objetivo en una tabla, junto contexto descifrado, para obtener una estadísticadel desempeño.

Finalizado el análisis, comprobaremos si eltexto en claro resulta inteligible, aunque seade forma parcial, para los mejores valores deaptitud conseguidos. Si no es así, pensare-mos en una nueva palabra y prepararemos elprograma para realizar un nuevo análisis.

Hay que observar que este procedimiento essolo semiautomático, pues necesitamos co-nocer ciertos detalles pertenecientes al con-texto del mensaje, por lo que resulta másapropiado para el criptoanálisis de documen-tos que alternen el texto en cifra con zonas enclaro, como es el que nos ocupa.

3. Algoritmo genético3.1. IntroducciónLos algoritmos genéticos son unos métodosheurísticos de búsqueda y optimización, ba-sados en la teoría de la evolución de Darwin,de acuerdo a la cual los individuos con mejorgrado de adaptación al medio (eficacia bioló-gica o fitness) sobreviven en mayor número,transmitiendo a la descendencia los rasgosadaptativos expresados por sus cromosomas.

3.2. Descripción de un algoritmogenéticoLos algoritmos genéticos [4] imitan la acciónde la selección natural a partir de una poblaciónde partida, cuyos individuos codifican en unacadena (cromosoma) una solución inicial a unproblema, normalmente aleatoria. El algorit-mo actúa sobre esta población sometiéndola aunas operaciones similares a los mecanismosevolutivos naturales:

Selección. Los individuos más aptos tie-nen mayor probabilidad de pasar a la siguientegeneración.

Cruce. Consiste en combinar las caracte-rísticas de los cromosomas de dos individuos

Criptoanálisis mediantealgoritmos genéticos de

una comunicación cifradaen la Guerra Civil

Tomás F. Tornadijo RodríguezAnalista informático; Encargado del dpto. deinformática de Cartonajes Vir, S.A.

< t o r n a d i j o @ t e l e c a b l e . e s >< t o r n a d i j o @ t e l e c a b l e . e s >< t o r n a d i j o @ t e l e c a b l e . e s >< t o r n a d i j o @ t e l e c a b l e . e s >< t o r n a d i j o @ t e l e c a b l e . e s >

Resumen: El propósito de este artículo es mostrar la aplicación de un algoritmo genético, asistido coninformación de contexto del mensaje, al desciframiento de un radiotelegrama cifrado mediante una tablade substitución homofónica al comienzo de la guerra civil española.

Palabras clave: Algoritmo genético, cifra homofónica, criptoanálisis.


sociedad de la información Informática práctica


para obtener uno nuevo.Mutación. Con cierta probabilidad se al-

tera aleatoriamente el cromosoma de unindividuo, incrementando con ello la diversi-dad genética de la población.

Un algoritmo genético canónico suele seguirel siguiente esquema:

{Generar la población inicial, Pi

Evaluar aptitud Pi

Repetir hasta g generaciones {Seleccionar los individuos de Pi quepasarán a Pi+1

Cruzar individuos de Pi y colocar en Ptemp

Mutar individuos de Ptemp y colocar en Pi+1

Pi = Pi+1

Evaluar aptitud Pi

}}

Si el algoritmo está correctamente diseñado, lapoblación convergerá hacia el mejor resultadoque quedará registrado en el cromosoma delindividuo más apto de la última generación.

3.3. CodificaciónCada individuo de la población representaráuna posible clave del mensaje, es decir: larelación de la tabla de homófonos con lasletras del abecedario. Los cromosomas esta-rán formados por una cadena de texto contantas letras del abecedario como homófonosdiferentes existan en el mensaje, estando rela-cionada cada posición del cromosoma con

una cifra determinada. Esta representaciónpermitirá al programa atacar indistintamentetanto la cifra homofónica convencional comola de cinta móvil, pues al final ambas no pasande ser una correspondencia donde se relacionacada letra con varias cifras. Por otra parte, alno utilizar todos los números del 0 al 99, sinosolo los presentes en el mensaje, evitaremosgenerar combinaciones improductivas y aho-rraremos tiempo de proceso. En la figura 2figura 2figura 2figura 2figura 2se muestra un ejemplo con los cromosomasde dos individuos.

3.4. SelecciónEl algoritmo emplea una selección por torneobinario determinístico, procedimiento queconsiste en tomar al azar dos individuos de lapoblación seleccionando al más apto de ellos.Además se utiliza el elitismo, para asegurarque los individuos mejor adaptados de unageneración pasen siempre a la siguiente.

3.5. Función objetivoPara evaluar la aptitud de un individuo, elalgoritmo utiliza sus cromosomas comoclave para decodificar el texto cifrado. A con-tinuación, con el texto conseguido, calcula ladiferencia entre las frecuencias encontradasde letras y bigramas y las frecuencias espera-das, procedentes de un texto de referencia (seutilizó la novela La Primera República, de B.Pérez Galdós). Con objeto de disminuir eltiempo de localización de los bigramas seimplementó un procedimiento de búsquedabinaria en un vector ordenado.

La suma de las diferencias de letras y bigramassupone el error entre el texto descifrado y elparadigma, de manera que la idoneidad de laclave analizada, k, vendrá dada por la siguien-te función [3, pág 43]:

Donde A denota el alfabeto [A..Z], K denotalas frecuencias de referencia, D las del textoanalizado, los subíndices u y b las frecuenciasde letras y bigramas respectivamente, en tantoque α y β son los pesos asignados a letras ybigramas, no resultando práctico introducirlas frecuencias de los trigramas [3, pág 43].Para este problema el algoritmo mejora laconvergencia utilizando como pesos los valo-res 1 y 2 respectivamente. Además, para con-seguir una función creciente, a medida quedisminuye el error, se ha aplicado:

Ck = 5 - Ck

3.6. Población inicialRellenaremos cada posición del cromosomacon letras del abecedario tomadas aleato-riamente hasta la última posición, la 50, quees el total de homófonos diferentes (excluyen-do el último, como se ha dicho anteriormen-te) que hay en el mensaje cifrado.

3.7. MutaciónCon cierta probabilidad, un individuo selec-cionado sufre una operación de mutación,que consiste en elegir al azar un gen, uncarácter de su cromosoma, y a continuaciónsubstituirlo por una letra tomada aleatoria-mente del abecedario.

3.8. CruceEl algoritmo utiliza uno de los operadoresmás sencillos, el cruce de un punto, queconsiste en cortar dos cromosomas por unaposición escogida al azar, generando cadauno un segmento de cabeza y otro de cola.Entonces el segmento de cabeza de un proge-nitor y el de de cola de otro se unen para darlugar a un nuevo individuo.

3.9. Texto supuestoUna vía para disminuir el elevadísimo númerode combinaciones con las que tiene que traba-jar el programa consiste en asociar un frag-

Figura 1. Radiotelegrama cifrado. Fuente: Arturo Quitantes [1].

Figura 2. Dos cromosomas.

C A H G I E O D A N K Z B E O S N .. 00 11 12 15 16 17 19 22 23 26 27 28 31 32 34 35 36 ..

A O J E C B V Y S C E I N F E A S .. 00 11 12 15 16 17 19 22 23 26 27 28 31 32 34 35 36 ..


Informática práctica sociedad de la información


mento del mensaje cifrado con un texto enclaro, una palabra o una frase corta supuestaa partir de la información que nos proporcio-nan las zonas en claro del mensaje, un proce-dimiento análogo a los rastreos de conteni-dos estereotipados que efectuaban loscriptoanalistas británicos en los partes me-teorológicos cifrados de la marina alemanadurante la segunda guerra mundial, con ladiferencia de que, en este caso, no podemossaber donde está ese fragmento de texto, porlo que probaremos en todas las posiciones,lanzando el algoritmo genético para cada unade ellas, de acuerdo al siguiente esquema:

{ t = longitud del texto cifrado b = longitud del texto de búsqueda x = 0 Repetir hasta que x = t - b + 1 {x = x + 1 Lanzar algoritmo genético [x, texto debúsqueda] Guardar x Guardar aptitud Guardar texto en claro }}

Además el algoritmo genético cuenta con unoperador adicional que modifica los cromo-somas de los individuos en cada nueva genera-ción, de forma que el mensaje en claro contengael texto supuesto en la posición indicada.

4. Ajuste4.1. EnsayosPara ajustar los parámetros del algoritmogenético, se codificó un mensaje de la mismalongitud que el radiotelegrama analizado,utilizando una clave con el mismo número dehomófonos, y se ejecutó el programa (sinproporcionarle un texto supuesto) para untotal de cinco combinaciones de pesos, con-tando la cantidad de letras coincidentes entreel mensaje descifrado por el programa y eltexto original sin cifrar, con la intención deobtener un valor real de aptitud. Para cadacombinación se ejecutó el algoritmo 50 veces,

calculando el valor medio de la función decoste (ver figura 3figura 3figura 3figura 3figura 3).

Los valores de las combinaciones primera ycuarta (ver figura 3figura 3figura 3figura 3figura 3) muestran una mejoradel valor de la función de coste cuando au-menta el peso asignado a los bigramas, lo queresulta coincidente con los estudios de Clark& Dawson [3, pág 44] y otras experiencias [5,pág 19]. Usaremos la mejor combinación,con los valores α = 1 y β = 2.

Asimismo se comprobó que el algoritmo secomportaba bien con un valor de mutaciónalto: 0,008, y con un reparto de individuos ygeneraciones no muy elevado, de 500 y 50,respectivamente (ver figura 4figura 4figura 4figura 4figura 4). Todos estosparámetros serán los que utilicemos en eldescifrado del mensaje de la guerra civil.

5. ResultadosLas primeras pruebas se realizaron sin pro-porcionar al algoritmo un texto supuesto,pero se observó que, aunque convergía ade-cuadamente consiguiendo generación trasgeneración valores de aptitud crecientes, eltexto en claro obtenido al final del procesonunca resultaba legible.

Como en una de las zonas no cifradas deltelegrama se hace mención a la columna delgeneral Miguel Ponte y Manso de Zúñiga, quepor aquellas fechas intentaba abrirse paso hacia

Madrid por la Sierra de Guadarrama, se consi-deró posible que el texto cifrado contuviesealguna mención a la ciudad de Madrid, objetivoúltimo de la citada columna, información quehabría resultado igualmente obvia para algúncriptoanalista coetáneo al mensaje.

Sin embargo las pruebas realizadas con esostextos supuestos resultaron infructuosas, yno se pudo obtener ningún texto legible.Otros intentos utilizando algunas palabrastípicas de la terminología militar, como bom-bardeo, artillería, aviación, posición, etc.,tampoco arrojaron resultados satisfactorios.

Otro de los párrafos en claro hace referenciaa la columna del capitán Pablo DíazDuñabeitia, que por entonces operaba enGuipuzcoa, lo que hacía verosímil la presen-cia en el texto cifrado de alguna alusión a lacapital de la provincia, San Sebastián, dondea la sazón se estaban produciendo importan-tes acontecimientos.

En este caso, con el valor de aptitud más altoconseguido cuando el texto se asocia a partirde la posición 158 del mensaje cifrado (verfigura 5figura 5figura 5figura 5figura 5), se obtuvo el siguiente resultado,donde se leen algunas palabras (en negrita) ydonde se sugiere alguna otra más: MOMQJASAPBTANORHANKPBREBSIALATQQ/QARAOYONCOLSOBRETPODALROUO/AUENAMALERIANC/UDQFPUNADEANOMERNODCALAFIBODEO/MLKQTACO SNLOCAOSPEDIDEMVBABELSERENDICONSESCLOSAUITOSDESANSEBASTIANDESOQALELIEKDOTENIENTELORONE FZAVESQIN

Podríamos intentar mejorar la solución me-diante un reproceso con un mayor número degeneraciones para esta posición del texto debúsqueda, pero también podemos intentarromper la cifra usando las nuevas palabrasque conocemos, realizando un criptoanálisisclásico. Por ejemplo, podemos completarTENIENTE CORONEL, que parece unasuposición bastante obvia a partir del textoque sigue a TENIENTE, lo que nos propor-ciona el siguiente mensaje, compuesto única-mente con las letras que hemos ido fijando:*O***A*A*BTAN***AN**BREB*I**A***/

Figura 3. Aptitud real en función de los pesos α y β.

Figura 4. Aptitud en función del número de generaciones.


sociedad de la información Informática práctica


*ARA***N***SOBRE***DA*R***/A*ENA*A*ER*AN*/***L**NA*EANO*ERNO**A*A*IB*DEO/*EC**TA*O*N***AO**EDI*E**BABE*SERENDI*ON*ES**O*A*I*OSDESANS EBASTIANDES**A*ECIE*DOTENIENTECORONEL*A*ES*INTENIENTECORONEL*A*ES*INTENIENTECORONEL*A*ES*INTENIENTECORONEL*A*ES*INTENIENTECORONEL*A*ES*IN

El párrafo en negrita es claro que solo puedereferirse al teniente coronel Vallespín, oficialal mando de los cuarteles de Loyola en aque-lla época. Completando VALESPIN, tene-mos: *O***A*A* BTAN***AN**BREB*I**A***/PARA***N***SOBRE***DA*R***/A*ENA*A*ER*AN*/***L**NA*EANO*ERNO**A*A*IB*DEO/*EC*PTA*O*N***AO**EDI* E*LBABE*SERENDI*ON* ES**ONA*I*OSDESANSEBASTIANDES*PA*ECDES*PA*ECDES*PA*ECDES*PA*ECDES*PA*ECIE*D OIE*D OIE*D OIE*D OIE*D OTENIENTE CORONEL VALESPIN

Completando DESAPARECIENDO: *O***A*A*BTANA**ANN*BREB*I*RA***/PARAA*AN*ARA*AN*ARA*AN*ARA*AN*ARA*AN*ARSOBRE**ADARRA*A**ADARRA*A**ADARRA*A**ADARRA*A**ADARRA*A/A*ENA*ARER*AN*/***L**NA*EANO*ERNO**ARA*IBADEO*IBADEO*IBADEO*IBADEO*IBADEO/*ECNPTA*O*NRA*AO**EDI*E*LBABERSEREND I*ON *ES* RONA*I*OSDESANSEBASTIANDESAPARECIENDOTENIENTECORONELVALESPIN

Completando AVANZAR GUADARRAMAY RIBADEO: *O***A*A*BTANA**ANN*BREB*I*RAG**/PARAAVANZARSOBREGUADARRAMA/A*ENA*ARER*AN*/***********LUMNALUMNALUMNALUMNALUMNA*EANO*ERNO*ZARA*ERNO*ZARA*ERNO*ZARA*ERNO*ZARA*ERNO*ZARARIBADEO/*ECNPTA*O*N*ECNPTA*O*N*ECNPTA*O*N*ECNPTA*O*N*ECNPTA*O*NRA*AO*UEDI*E*LBABERSERENDI*ON*ESZRONAMIGOSDESANSEBASTIANDESAPARECIENDOTENIENTECORONELVALESPIN

Completamos COLUMNA, PERNOCTARA,DETECTADO, UN y vemos que hay varioshomófonos confundidos en el texto cifrado:*O*O*A*A*BTANA**ANN*BREBUI*RABUI*RABUI*RABUI*RABUI*RAGOGOGOGOGOOPARAAVANTARSOBREGUADA RRA

MA/A*ENA*ARER*AN*/*COLUMNACEANO PERNOCTARARIBA DEO/DECNPTADOUNRADAOQUEDI CEDLBABERSERENDIDONUESTRONAMIGOSDESANSEBASTIANDESAPAR ECIEN DOTE NIENTECORONELVALESPIN

Completamos BUITRAGO: *O*O*A*A*BTANA**ANN*BREBUITRA GOO/PARAAVANTARSOBREGUADARRAMA/A*A*A*A*A*ENA*AENA*AENA*AENA*AENA*ARER*AN*/*COLUMNACEANOPERNOCTARARIBADEO/DECNPTADOUNRADAOQUEDICEDLBABERSERENDIDONUESTRONAMIGOSDESANSEBASTIANDESAPARECIENDOTENIENTECORONELVALESPIN

Completamos AMENAZA: *OZO*A*A*BTANA**ANN*BREBUITRAGOO/PARAAVANTARSOBREGUADA RRAMA/AMENAZARER*AN*RER*AN*RER*AN*RER*AN*RER*AN*/*COLUMNACEANOPERNOCTAR ARIBADEO/ DE CNPTADOUNRADA OQUEDICE DLBA BERSERENDIDONUESTRONAMIGOSDESANSEBASTIANDESAPARECIENDOTENIENTE CORONELVALESPIN

Completamos HERNANI, nuevamente sehan confundido homófonos: *OZO*A*OZO*A*OZO*A*OZO*A*OZO*A*A*BTANA**ANN*BREBUITRAGOO PARAAVANTARSOBREGUADARRAMA/AMENAZARERNANI*COLUMNACEANOPERNOCTARARIBADEO/DECNPTADOUNRADAOQUEDICEDLBABERSERENDIDONUESTR ONAMIGOSDESANSEBASTIANDESAPARECIENDOTENIENTECORONELVALESPIN

Completamos LOZOYA, por ser el valledonde está Buitrago: LOZOYA*A*BTANA**ANN*BREBUITRAGOO/PARAAVANTARSOBREGUADARRAMA/AMENAZARERNANI/*COLUMNACEANOPER

NOCTARARIBADEO/DECNPTADOUNRADAOQUEDICEDLBABERSERENDIDONUESTRONAMIGOSDESANSEBASTIANDESAPARECIENDOTENIENTECORONELVALESPIN

El párrafo entre LOZOYA y BUITRAGO nose ha podido resolver, tal vez por la existenciade más errores. El texto descifrado,interpolando los errores evidentes, quedaríaasí: LOZOYA*****************BUITRAGO*/PARA AVANZARSOBREGUADARRAMA/AMENAZAHERNANI/*COLUMNACEANOPERNOCTARARIBADEO/DETECTADOUNRADIOQUEDICEDEHABERSERENDIDONUESTROSAMIGOSDESANSEBASTIANDESAPARECIENDOTENIENTE CORONELVAL LES PIN*

6. ConclusionesSe ha conseguido romper la cifra de estemensaje y descifrarlo en su mayor parte y,aunque el método aplicado no puede consi-derarse una solución general para la rupturade las cifras homofónicas, sí puede resultar deayuda en los casos en los que se disponga dealguna información sobre el contenido o elcontexto del mensaje. Como desarrollos fu-turos cabe imaginar un programa capaz deprobar no una, sino varias palabras clave,tomándolas desde una base de datos, a costade un importante tiempo de proceso.

Figura 5. Aptitud en función de la posición del texto supuesto.

Referencias

[1] A. Quirantes Sierra. Taller de criptografía,2010, [2-12-2010]. Disponible en <http://www.cripto.es>.[2] A.S. Gascón González. Aplicación de algoritmosgenéticos en el ataque de textos cifrados durantela guerra civil española. Proyecto Fin de Carrera,2010. <http://www.iit.upcomillas.es/pfc/resumenes/4c8615ad0a2b6.pdf>.[3] Bethany Delman. Genetic Algorithms inCryptography, 2004,<https://ritdml.rit.edu/bitstream/handle/1850/263/thesis.pdf?sequence=1>.[4] J.H. Holland. Adaptation in Natural and Arti-ficial Systems. Ann Arbor: The University ofMichigan Press, 1975.[5] Pallavi Kanagalakatte Basavaraju. HeuristicSearch Cryptanalysis of the Zodiac 340 Cipher.Master’s Projects. Paper 56, 2009. <http://scholarworks.sjsu.edu/etd_projects/56>.

A. Clark, Ed. Dawson. Optimisation Heuristics forthe Automated Cryptanalysis of Classical Ciphers.Journal of Combinatorial Mathematics andCombinatorial Computing, 28, 1998, pp. 63-86.J. García Carmona. Tratado de criptografía conaplicación especial al ejército.Madrid: Sucesoresde Rivadeneyra, 1894.R. Otéeme, S. Arumugam. Applying GeneticAlgorithms for Searching Key Space ofPolyalphabetic Substitution Ciphers. TheInternational Arab Journal of Information Technology,vol. 5 (1), 2008.

Bibliografía


Programar es crear sociedad de la información


La codificación es el proceso mediante el cual ciertos símbolos seconvierten en otros símbolos en un sistema de representación deter-minado, aplicando ciertas reglas de codificación. La decodificaciónpuede definirse como el proceso inverso en el cual se conviertensímbolos en información entendible por el receptor.

En este problema se requiere decodificar cierta información provistacomo entrada mostrando el mensaje decodificado en la salida.

Se sabe que el mensaje original es una frase en Español. Se conocetambién que la frase no contiene los símbolos ‘(‘, ’)’, ’{‘, ’}’, ‘[‘, ‘]’,‘,’, y ‘_’.

Se nos informa que se aplicaron las siguientes reglas de codificaciónsucesivamente al mensaje original en este orden:1) Se rota cada palabra del mensaje original. Ejemplo: "Hola" secodificó como "aloH".2) Se aplica la siguiente función de transformación f, a cada palabra

de longitud n, y k=g(n), donde un carácter de dicha palabra, donde:

3) Si el mensaje (luego de los pasos 1 y 2) presenta palabras de doscaracteres, entonces se amplían esas palabras a cuatro caracteresduplicando cada carácter, por ejemplo "de" se ampliaría a "ddee" y "la"a "llaa".4) Si en el paso 3 se generó una cantidad par positiva de palabrasentonces, se toman cada una de estas palabras y se reemplazan todaslas vocales ‘a’ por ‘e’, las ‘e’ por ‘i’, las ‘i’ por ‘o’, las ‘o’ por ‘u’, y las‘u’ por ‘a’, simultáneamente.5) Los caracteres ‘p’ se reemplazan por ‘_’ (guion bajo).

Se deben mostrar en la salida el mensaje original.

Entrada:Cada caso de prueba se recibe en una línea que contiene una frasecodificada finalizada con punto (‘.’). El fin de entrada estará dado poruna cadena vacía en la línea final.

Salida:Por cada caso de prueba se debe imprimir una línea con el mensajeoriginal (decodificado), respetando los espacios entre palabras en elmensaje original.

Ejemplo:

Entrada: laHo donmu elucr.taEs ssee anu eba_ru.uuNN ssii eell 1 zev euq ala iivv.

Salida: Hola mundo cruel.Esta es una prueba.No es la 1 vez que ala ve.

El problemadel decodificador

Julio Javier Castillo, Diego Javier SerranoLaboratorio de Investigación de Software MsLabs, Dpto. Ing. enSistemas de Información, Facultad Regional Córdoba - UniversidadTecnológica Nacional (Argentina) < j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< d i e g o j s e r r a n o @ g m a i l . c o m >< d i e g o j s e r r a n o @ g m a i l . c o m >< d i e g o j s e r r a n o @ g m a i l . c o m >< d i e g o j s e r r a n o @ g m a i l . c o m >< d i e g o j s e r r a n o @ g m a i l . c o m >

Esta es una adaptación del enunciado del problema C de los planteados enla Segunda Competencia de Programación de la Facultad Regional deCórdoba (Universidad Tecnológica Nacional, Argentina) UTN-FRC celebrada el 24 de noviembre de 2010.

Nivel del problema:Nivel del problema:Nivel del problema:Nivel del problema:Nivel del problema: Medio


sociedad de la información Programar es crear


Para resolver este problema nos basaremos en la observación de queel Triángulo de Pascal puede ser convenientemente representado de lasiguiente forma que se visualiza en la figura 1figura 1figura 1figura 1figura 1.

11 11 2 11 3 3 11 4 6 4 11 5 10 10 5 1

Figura 1. Coeficientes binomiales representados mediante unamatriz triangular izquierda.

Esta forma de representar los coeficientes binomiales constituye unamanera casi directa de implementación algorítmica empleando matri-ces.

El programa presentado a continuación ha sido modelado utilizandoel paradigma orientado a objetos. Sin embargo, dada la simplicidaddel problema y su resolución netamente algorítmica, la codificaciónde la solución se realizó solamente en una clase Main utilizando dosmétodos estáticos. Por ello, la implementación de esta solución seríamuy similar a la necesaria en un lenguaje de programación como C/C++ u otros lenguajes imperativos.

La clase Main contiene el método principal "main()" mediante el cualsolicitaremos el ingreso de datos por la entrada estándar. Se realizala lectura de tres números enteros: a, b, y n (donde: n<= 10, y que 0<=a, b <= 4) correspondientes a la fórmula (a + b)(a + b)(a + b)(a + b)(a + b)nnnnn. De esta manera,la salida esperada del programa será el valor de (a + b)(a + b)(a + b)(a + b)(a + b)n n n n n seguido delos coeficientes binomiales del n-ésimo nivel del triángulo.

Dicho programa contiene un segundo método llamado"calcularTriangulo()" que implementa el cálculo de las 10 primerasfilas (ya que n<=10) de la matriz de coeficientes binomiales (verfigura 1figura 1figura 1figura 1figura 1). Nótese también que, tanto la fila 0 como la diagonal dela matriz, tendrán siempre asignado el valor 1 siguiendo la ecuaciónde la potencia del binomio que se corresponde con elevar un númeroa la potencia 0. El cálculo del valor del coeficiente para la i-ésima filase realiza en base a la suma del valor de los coeficientes de la filainmediatamente anterior (i-1), el valor de la columna actual (j) y el dela columna anterior (j-1). Esta matriz es necesaria para poder imprimirlos coeficientes binomiales del n-ésimo nivel del triángulo de Pascal.

Posteriormente, una vez construida esta matriz solo resta imprimir elvalor de (a + b)(a + b)(a + b)(a + b)(a + b)nnnnn y luego los coeficientes correspondientes de ese nivel.

Para imprimir dicho valor tenemos dos alternativas:- La primera es simplemente computar este valor ya que los valoresde las variables a, b y n son conocidos.- La segunda alternativa es seguir la definición y calcular

que es el valor de la expresión generalizada de la potencia binomial.Se proveen ambas alternativas en el código, y se comentan las líneasde código correspondientes a la segunda alternativa. Cabe destacarque entre ambas opciones es preferible la alternativa 1 ya que utilizainformación conocida del problema y tiene una complejidad temporalde O(k) frente a la segunda alternativa cuya complejidad es O(n).

Finalmente, es necesario imprimir el valor de los coeficientes binomiales,para lo cual basta con recorrer la n-ésima fila de la matriz denominada"pascal" en el código fuente.

A continuación se provee el código fuente de la solución:

import java.util.Scanner;

public class Main{

static int[][]pascal = new int[10][10];public static void main(String[] args){

calcularTriangulo();int a, b, n;Scanner sc = new Scanner(System.in);

while (sc.hasNextInt()){

a = sc.nextInt();b = sc.nextInt();n = sc.nextInt();

int suma = 0;

//Alternativa 1suma=(int)Math.pow(a+b,n);

//Alternativa 2://for(int k = 0; k <= n; k++)// suma += (int)(pascal[n][k] *

Math.pow(a,n-k) * Math.pow(b,k));

System.out.print(suma);for (int k = 0; k <= n; k++)

System.out.print(“ “ +pascal[n][k]);

System.out.println();}return;

}

static void calcularTriangulo(){

int i,j;pascal[0][0] = 1;for (i = 1; i < 10; i++){

pascal[i][0] = 1;for (j = 1; j < i; j++){

pascal[i][ j] = pascal[i - 1][j -1] + pascal[i - 1][j];

}pascal[i][j] = 1;

}

Triangulo de Pascaly la Potencia Binomial

Julio Javier Castillo, Diego Javier Serrano,Marina Elizabeth CardenasLaboratorio de Investigación de Software MsLabs, Dpto. Ing. enSistemas de Información, Facultad Regional Córdoba - UniversidadTecnológica Nacional (Argentina) < j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< j o t a c a s t i l l o @ g m a i l . c o m > ,< d i e g o j s e r r a n o @ g m a i l . c o m > ,< d i e g o j s e r r a n o @ g m a i l . c o m > ,< d i e g o j s e r r a n o @ g m a i l . c o m > ,< d i e g o j s e r r a n o @ g m a i l . c o m > ,< d i e g o j s e r r a n o @ g m a i l . c o m > ,

El enunciado de este problema apareció en el número 209 de NováticaNováticaNováticaNováticaNovática(enero-febrero 2011, p. 76).


Socios institucionales de ati

Según los Estatutos de ATI, pueden ser socios institucionales de nuestraasociación "las personas jurídicas, públicas y privadas, que lo solicitena la Junta Directiva General y sean aceptados como tales por la misma".

Mediante esta figura asociativa, todos los profesionales y directivosinformáticos de los socios institucionales pueden gozar de los beneficiosde participar en las actividades de ATI, en especial congresos, jornadas,cursos, conferencias, charlas, etc. Asimismo los socios institucionalespueden acceder en condiciones especiales a servicios ofrecidos por laasociación tales como Bolsa de Trabajo, cursos a medida, mailings,publicidad en Novática, servicio ATInet, etc.

Para más información dirigirse a <[email protected]> o a cualquiera de las sedesde ATI. En la actualidad son socios institucionales de ATI las siguientesempresas y entidades:

AGENCIA DE INFOR. Y COMUN. COMUNIDAD DE MADRID

AGROSEGURO, S.A.

AIGÜES TER LLOBREGAT

ALC ORGANIZACIÓN Y SISTEMAS,S.L.

ALMIRALL, S.A.

AVANTTIC, CONSULTORÍA TECNOLOGICA, S.L.

CENTRO DE ESTUDIOS VELAZQUEZ S.A. (C.E. Adams)

CETICSA, CONSULTORIA Y FORMACIÓN

CONSULTORES SAYMA, S.A.

COSTAISA, S.A

DEPARTAMENT DÉNSENYAMENT DE LA GENERALITAT

ELOGOS, S. L.

EPISER, S.L.

ESPECIALIDADES ELÉCTRICAS, S.A. (ESPELSA)

ESTEVE QUÍMICA, S.A.

FUNDACIÓ BARCELONA MEDIA - UNIVERSITAT POMPEU FABRA

FUNDACIÓ CATALANA DE LÉSPLAI

FUNDACIÓ PRIVADA ESCOLES UNIVERSATÀRIES GIMBERNAT

IN2

INFORMÁTICA Y COMUNICACIONES AVANZADAS, S.L.

INSTITUT D'ESTUDIS CATALANS

INSTITUT MUNICIPAL DÍNFORMÀTICA

INVERGAMING GRUP

KRITER SOFTWARE, S.L.

MUSEU DÁRT COMTEMPORANI DE BARCELONA - MACBA

ONDATA INTERNATIONAL, S.L.

PRACTIA CONSULTING, S.L.

QRP MANAGEMENT METHODS INTERNATIONAL

RCM SOFTWARE, S.L.

SADIEL, S.A.

SCATI LABS, S.A.

SISTEMAS DATASIX

SISTEMAS TÉCNICOS LOTERIAS ESTADO (STL)

SOCIEDAD DE REDES ELECTRÓNICAS Y SERVICIOS, S.A.

SQS, S.A

TRAINING & ENTERPRISE RESOURCES

T-SYSTEMS ITC Services España S.A.

UNIVERSIDAD ANTONIO DE NEBRIJA

UNIVERSITAT DE GIRONA

UNIVERSITAT OBERTA DE CATALUNYA

Coordinación Editorial

Oferta de colaboración del Grupo de Lengua e Informática deATI a los autores de Novática

El Grupo de Lengua e Informática de ATI, una de cuyas áreas detrabajo trata sobre el uso de la lengua en la Informática <http://www.ati.es/spip.php?rubrique65>, ofrece su colaboración a aquellosautores de Novática Novática Novática Novática Novática a quienes, a la hora de redactar sus artículos,les surjan dudas sobre cómo trasladar al castellano términoso expresiones procedentes de otras lenguas, y cuya traducción oadopción todavía no esté asentada en este dinámico ámbito de laterminología informática.

Para más información, por favor contactar con Carmen Ugarte<[email protected]>, coordinadora del citado Grupo de Trabajo.

Cambios en Secciones Técnicas

Después de varios años contribuyendo a enriquecer Novática Novática Novática Novática Novática através de la sección técnica "Informática y Filosofía", y en razón a quesus numerosos proyectos personales no le permiten seguir con estadedicación, Karim Gherab MartínKarim Gherab MartínKarim Gherab MartínKarim Gherab MartínKarim Gherab Martín deja la labor de coordinación dela citada sección técnica.

Le sustituye Roberto Feltrero OrejaRoberto Feltrero OrejaRoberto Feltrero OrejaRoberto Feltrero OrejaRoberto Feltrero Oreja, profesor de la UNED, y cuyacarta de presentación en Novática Novática Novática Novática Novática es el artículo que publicó en 2008en nuestra revista ("Prácticas Científicas y Sociedad del Conocimien-to: el ejemplo de las comunidades FLOSS" - Novática Novática Novática Novática Novática 192). Robertocompartirá a partir de ahora con José Ángel Olivas Varela José Ángel Olivas Varela José Ángel Olivas Varela José Ángel Olivas Varela José Ángel Olivas Varela laslabores de coordinación de "Informática y Filosofía".

Karim, muchas gracias por tu dedicación y ¡mucha suerte en tusproyectos!

Roberto, bienvenido a este grupo de quienes contribuimos a hacerposible NováticaNováticaNováticaNováticaNovática. ¡Espero que estés muy a gusto entre nosotros!

Programación de Novática

Por acuerdo de los Consejos Editoriales de NováticaNováticaNováticaNováticaNovática y UPUPUPUPUPGRADE,los temas y editores invitados de las monografías restantes de 2011serán, salvo causas de fuerza mayor o imprevistos, los siguientes:

Nº 212 (julio-agosto): Número especial de verano sobre "Innovacióny emprendimiento en las TIC".

Nº 213 (septiembre-octubre): "Informática verde". Editores invitados:Juan Carlos López LópezJuan Carlos López LópezJuan Carlos López LópezJuan Carlos López LópezJuan Carlos López López (Director del Grupo de InvestigaciónARCO, Universidad de Castilla-La Mancha), Lasse Natvig Lasse Natvig Lasse Natvig Lasse Natvig Lasse Natvig (Uni-versidad de Ciencia y Tecnología de Noruega -NTNU-) y GiovannaGiovannaGiovannaGiovannaGiovannaSissa Sissa Sissa Sissa Sissa (Universidad de Milán, Italia).

Nº 214 (noviembre-diciembre): "Gestión de riesgos". Editor invitado:Darren Dalcher Darren Dalcher Darren Dalcher Darren Dalcher Darren Dalcher (((((Middlesex University; ; ; ; ; Director del National

Documents

Novática nº 211, mayo-junio 2011, año XXXVII · discutible de las redes sociales, de las aplica-ciones de distribución instantánea de con-tenidos, o de todo ese conjunto de aplicacio-nes