Plataforma de Computación Urbana en Entornos de Living Labs

Transcripción

1 Plataforma de Computación Urbana en Entornos de Living Labs Claudia Zúñiga, Alexander García Andrés Millán, Zeida Solarte Andrea Arteaga, Lina Escobar

2 Claudia Zúñiga, Alexander García Andrés Millán, Zeida Solarte Andrea Arteaga, Lina Escobar Plataforma de Computación Urbana en Entornos de Living Labs Cali Colombia

3 Plataforma de Computación Urbana en Entornos de Living Labs / Claudia Liliana Zúñiga Cañón [et al.]. Cali: Universidad Icesi, p.:il. 1. Computación Urbana Investigaciones. 2. Living Labs Investigaciones. 3. Smart Cities Investigaciones. 4. Plataformas Urbanas Investigaciones. I. Zúñiga-Cañón, Claudia Liliana. Plataforma de Computación Urbana en Entornos de Living Liliana Zúñiga García Felipe Millán María Solarte Arteaga Escobar Paz Primera Edición, 2013 Gestión Editorial Programa Editorial Universidad Icesi El contenido de esta publicación no compromete el pensamiento de la Institución, es responsabilidad absoluta de sus autores. Este libro no podrá ser reproducido en todo o en parte, por ningún medio impreso o de reproducción sin permiso escrito del titular del Copyright. Impreso en Colombia Printed in Colombia 2

4 Agradecimientos Esta publicación fue elaborada como un documento de resultados de investigación por los grupos COMBA I+D, GITI e I2T de las Universidades Santiago de Cali, Autónoma de Occidente e Icesi (respectivamente), que se unieron para la realización del proyecto de investigación Plataforma de Computación Urbana (Urb@naLab) para ofrecer servicios orientados al ciudadano en entornos urbanos inalámbricos que favorezcan un enfoque de LivingLabs en las ciudades colombianas., el cual fue cofinanciado bajo la modalidad de recuperación contingente por el instituto Colombiano para el Desarrollo de la Ciencia y la Tecnología (COLCIENCIAS, código del proyecto ). Agradecemos a todas las anteriores instituciones por su valioso apoyo. Esta publicación y el desarrollo del proyecto fueron posibles gracias al apoyo económico de COLCIENCIAS. 3

5 Autores Claudia Liliana Zúñiga Cañón Candidata a Doctora en ingeniería Telemática de la universidad de Vigo (España). Master en Estudios Avanzados en Ingeniería Telemática de la Universidad de Vigo. Ingeniera de Sistemas y telemática de la universidad Santiago de Cali. Directora del Grupo de Investigación COMBA I+D, donde ha participado en proyectos de investigación nacionales e internacionales. Es Profesora de la Facultad de Ingeniería de la Universidad Santiago de Cali. Miembro fundador del Consorcio de Investigación en Computación Móvil I2COMM. Actualmente es la Presidente del Capítulo IEEE Computer Society para Colombia. Sus áreas de investigación son la computación urbana, el desarrollo de modelos para sistemas en entornos urbanos, el diseño de arquitecturas y plataformas de computación pervasiva, las ciudades ubicuas, las metodologías de Living Labs, y los contextos inteligentes. clzuniga@ieee.org Alexander García Dávalos Es Ingeniero de Sistemas de la Universidad Estatal de la Aviación Civil de Moscú (Federación Rusa) y Magister en Ciencias Computacionales del Instituto Tecnológico y de Estudios Superiores de Monterrey (México) y la UNAB. Es Docente Tiempo Completo de la Facultad de Ingeniería de la Universidad Autónoma de Occidente. Actualmente es Director del Grupo de Investigación en Telemática e Informática Aplicada (GITI), en el cual ha participado en proyectos de investigación cofinanciados por Colciencias y por la Universidad Autónoma de Occidente. Miembro fundador del Consorcio de Investigación en Computación Móvil I2COMM. Miembro de IEEE y ACM. Sus áreas de interés son la Computación móvil y ubicua, la Internet de las Cosas, la convergencia de redes y el Software Libre. agdavalos@uao.edu.co Andrés Felipe Millán Cifuentes Es Candidato a Doctor en Ingeniería Telemática de la Universidad de Vigo. Es Magister en Sistemas y Redes de Comunicaciones de la Universidad Politécnica de Madrid y es Ingeniero de Sistemas de la Universidad Icesi. Es Profesor Tiempo Completo de la Facultad de Ingeniería de la Universidad Santiago de Cali. Miembro fundador del Consorcio de Investigación en Computación Móvil I2COMM. Miembro de IEEE Communications. Par evaluador en tecnologías de la información y comunicaciones de proyectos y productos de investigación para varias universidades y agencias promotoras 4

6 de investigación (Colciencias). Sus principales campos de investigación son las redes municipales y la computación urbana que hacen uso de las tecnologías inalámbricas y de banda ancha para ofrecer nuevos servicios a los ciudadanos como gobierno electrónico, entretenimiento en línea, tele-medicina y tele-educación. afmillan@ieee.org Zeida María Solarte Astaiza Es Ingeniera en Electrónica de la Universidad del Cauca en Popayán, Colombia. En el 2005 obtuvo su Título de Especialista en Redes y Servicios Telemáticos, de la misma Universidad. Magister en Telemática de la Universidad del Cauca. Se desempeña como Profesora Tiempo Completo y Directora de la Especialización en Telemática en la Universidad Autónoma de Occidente en Cali. Hace parte del Grupo de Investigación en Telemática e Informática Aplicada (GITI) de la Universidad Autónoma de Occidente y del Consorcio de Investigación en Computación Móvil I2COMM. Sus áreas de interés son la computación móvil y ubicua, las aplicaciones y servicios telemáticos y los servicios en redes de nueva generación. zsolarte@uao.edu.co Andrea Arteaga Palacios Es Ingeniera de Sistemas de la Universidad Santiago de Cali. Investigador Asistente del Grupo de Investigación COMBA I+D de la Universidad Santiago de Cali. Ha participado en proyectos de Investigación del Grupo COMBA I+D cofinanciados por Colciencias y la Universidad Santiago de Cali. andreaarteagap@yahoo.com Lina Marcela Escobar Paz Es Ingeniera Informática de la Universidad Autónoma de Occidente. Fue becaria del programa jóvenes investigadores e innovadores de Colciencias bajo la tutoría del Grupo de Investigación en Telemática e Informática Aplicada (GITI) de la Universidad Autónoma de Occidente. Ha participado en proyectos de investigación del grupo GITI cofinanciados por Colciencias y la Universidad Autónoma de Occidente. lescobarpaz86@gmail.com 5

7 Contenido Capítulo 1 Arquitectura de software basada en el enfoque de Living Labs para ofrecer servicios orientados a los ciudadanos.. 8 Claudia L. Zúñiga Alexander García D. Lina M. Escobar Paz Grupo de Investigación COMBA I+D, Universidad Santiago de Cali Grupo de Investigación GITI, Universidad Autónoma de Occidente Capítulo 2 Plataforma Urb@naLab Claudia L. Zúñiga Andrés Millán Andrea Arteaga P. Josymar de León Cristián Chaparro Leonardo Vargas B. Grupo de Investigación COMBA I+D, Universidad Santiago de Cali Grupo de Investigación i2t, Universidad Icesi Capítulo 3 Acceso Móvil a la Plataforma Urb@naLab Alexander García Dávalos. Leonardo Saavedra Munar. Juan David Trejos Polania. Grupo de Investigación GITI, Universidad Autónoma de Occidente 6

8 Capítulo 4 Servicios en Living Labs 92 Leonardo Saavedra Zeida María Solarte Grupo de Investigación GITI, Universidad Autónoma de Occidente Capítulo 5 Implementación y Pruebas de la Plataforma Urb@naLab Claudia L. Zúñiga Andrés Millán Andrea Arteaga P. Juan David Millán Grupo de Investigación COMBA I+D, Universidad Santiago de Cali 7

9 Capítulo 1 Arquitectura de software basada en el enfoque de Living Labs para ofrecer servicios orientados a los ciudadanos Claudia L. Zúñiga 1 Alexander García D. 2 Lina M. Escobar Paz 3 Abstract. Los modelos de innovación y desarrollo tecnológico de las ciudades colombianas siguen esquemas tradicionales que son poco dinámicos. Lo anterior se refleja en la poca participación de usuarios y emprendedores en la generación de nuevas aplicaciones y servicios orientados hacia los ciudadanos. En este capítulo se propone el desarrollo de una plataforma de software, cuya arquitectura sirve de base para fomentar iniciativas urbanas lideradas por comunidades de usuarios, empresas privadas o públicas, y operadores de telecomunicaciones en ciudades colombianas. La nueva plataforma llamada Urb@naLab usa el concepto de Living Labs para crear nuevos 1 Directora Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. claudia.zuniga00@usc.edu.co 2 Director del Grupo de Investigación en Telemática e Informática Aplicada (GITI), Facultad de Ingeniería, Universidad Autónoma de Occidente. agdavalos@uao.edu.co 3 Grupo de Investigación en Telemática e Informática Aplicada (GITI), Facultad de Ingeniería, Universidad Autónoma de Occidente. lmescobar@uao.edu.co 8

10 sistemas de innovación basados en las Tecnologías de la Información y las Comunicaciones (TIC). A. Introducción Actualmente se plantean a nivel mundial proyectos de ciudades digitales o territorios digitales que intentan promover el uso de las TIC (Tongia, 2007) por parte de los ciudadanos, con el objetivo de lograr una sociedad de la información más efectiva en estos entornos. Esta necesidad es aún más sentida en países de economías emergentes como Colombia, que presentan una brecha digital amplia. De allí, que se requieran nuevas herramientas que favorezcan el desarrollo de Living Labs en los municipios y regiones colombianas, en especial al existir iniciativas de proyectos de ciudades digitales en las principales ciudades del país (p.ej. Bogotá, Medellín, Pereira, Cali). Este capítulo presenta el diseño de la arquitectura de una plataforma Web y móvil llamada Urb@naLab, que responde a la necesidad de desarrollar una plataforma de servicios orientada a ciudadanos, que permita generar un espacio virtual para mejorar la interacción entre los usuarios y desarrollar un laboratorio bajo el concepto de Living Labs. Aunque se desconoce de proyectos similares en Colombia, una investigación preliminar ha permitido identificar que ya se han desarrollado plataformas similares en otros países como Idearium, Xpertum e InnoJam (Ståhlbröst et al., 2010), que han permitido desarrollar estrategias similares dentro del proyecto denominado COLLABS, el cual fue cofinanciado por la Comunidad Europea (Open Living Labs [ENoLL], 2009), y que ahora cuenta con la participación de más de 200 ciudades europeas. A este proyecto se han unido iniciativas en Brasil, África y Asia, lo cual demuestra el amplio interés que tiene el tema entre la comunidad científica internacional. Otro referente importante del estado del arte de la investigación es que varios gobiernos internacionales han emprendido ambiciosos programas para construir Ciudades Inteligentes (Smart Cities), por ejemplo, algunos proyectos piloto de ciudades inteligentes en Europa como Peripheria, People y Open Cities (ENoLL, 2009), han sido lanzados en el año 2010 con el objetivo de acelerar la implantación de tecnologías innovadoras basadas en Internet y servicios en las ciudades. En cada uno de los proyectos piloto se aplican procesos de innovación abierta dirigidos los usuarios finales a través de redes de 9

11 ciudades inteligentes, las cuales integran a los ciudadanos como coproductores de contenidos y servicios. La plataforma Urb@naLab será una herramienta importante para promover el desarrollo de nuevos sistemas de innovación basados en las TIC en las ciudades colombianas. En este sentido, es relevante el diseño de la arquitectura de la plataforma de software, ya que debe permitir el desarrollo del concepto de Living Labs ampliamente, desde la generación y especificación de ideas de servicios en diferentes sectores productivos, tales como la salud, la industria, el turismo, etc., hasta la validación y evaluación de las mismas. Urb@naLab actuará en el mejor interés de las personas y empresas de las diferentes ciudades de Colombia; puesto que el proponer soluciones a los problemas cotidianos puede mejorar la calidad de vida de los ciudadanos, y al mismo tiempo, generar nuevas y exitosas oportunidades de negocio. Este capítulo está organizado de la siguiente manera: En la sección B se presenta la definición del concepto de Living Labs y la revisión de algunas soluciones de Living Labs y ejemplos típicos de aplicaciones y servicios ofrecidos a los usuarios finales, así como también las arquitecturas de software propuestas para la implementación de estos entornos. En la sección C se describe la arquitectura de software de la plataforma Urb@naLab y el enfoque metodológico usado para su desarrollo. Finalmente, las conclusiones son dadas en la sección D. B. Antecedentes Los modelos de innovación y desarrollo de las ciudades modernas requieren de nuevas metodologías de innovación e investigación en entornos múltiples y emergentes, que tengan un alto grado de observación y creatividad. Una de las metodologías más reconocidas y aceptadas por la comunidad científica es la que se denomina Living Labs. 1. Qué es un Living Labs? El concepto de Living Labs tiene su origen en el Instituto Tecnológico de Massachusetts (MIT) con el Profesor William Mitchel (Almirall, 2008) del MediaLab, quien estaba interesado en cómo los ciudadanos podían participar más activamente en la planeación urbana y el diseño de las ciudades. Los primeros Living Labs fueron creados como casas inteligentes donde el principal objetivo era observar los patrones de vida de las personas por un periodo de 10

12 tiempo. Luego el concepto se reinventó y materializó en otros ambientes de colaboración donde participan diferentes actores (Empresas - Ciudadanos - Gobierno - Academia) con el fin de generar oportunidades de innovación más equitativas, flexibles y multicontexto, que permitan el desarrollo de las ciudades, las regiones o las empresas (Svensson, Eriksson & Ebbesson, 2010; Bergvall- Kåreborn, Holst & Stahlbrost, 2009). La idea de involucrar al usuario final en el proceso de diseño fue adoptada, posteriormente, en Europa por diversas comunidades de investigación. Un pequeño número de Living Labs, creados en Europa en el año 2005, formó la Red Europea de Living Labs (ENoLL) en el Desde entonces, nuevos Living Labs con una variedad de características diferentes han sido creados y, en el año 2010, por ejemplo, ya habían 15 Living Labs en el Reino Unido y más de 250 Living Labs en toda Europa y más allá (Mulvenna et al., 2010). Los Living Labs son una metodología de desarrollo e investigación centrada en el usuario para crear, experimentar y probar nuevos e innovadores productos y servicios TIC en contextos reales y cotidianos (Fahy et al., 2007; Følstad, 2008). En este sentido, los Living Labs son entornos de experimentación y validación caracterizados por la participación temprana de los usuarios, que trabajan conjuntamente con los desarrolladores y otros stakeholders (actores involucrados), y que concluye en ciclos rápidos de innovaciones. La Figura 1 muestra una visión general de la estructura y funcionamiento de los Living Labs. Figura 1. Enfoque de Living Labs como proveedor de servicios de innovación (Thoben, 2006) 11

13 Un Living Lab puede ser visto como un conjunto de infraestructuras, métodos, herramientas, servicios y recurso humano. Aquí, el usuario identifica y define problemas, así como diseña y plantea estrategias de acción para resolverlos (entradas). A través de diversos métodos y herramientas destinadas a optimizar la sinergia y el trabajo en red de los actores clave (apropiación de las TIC), se promueve la innovación abierta y participativa para crear nuevos productos, servicios y modelos de negocios (salidas) centrados en los usuarios, que respondan a las características y expectativas de la comunidad. Los Livings Labs permiten a investigadores y gestores de negocio analizar la aceptación de las soluciones generadas por parte del usuario, así como su grado de usabilidad, y valorar la viabilidad de llevar el producto al mercado. Esto se plantea de forma totalmente natural, ya que es el propio usuario quien identifica las necesidades, define los requisitos, y prueba los resultados en su entorno real, participando en todas la fases del ciclo de vida del desarrollo. Los Living Labs proporcionan un gran abanico de servicios, y juegan diferentes roles a la hora de fomentar la participación de los usuarios, desde apoyar a emprendedores (lead users) hasta servicios de estudios de mercado u observación de usuarios. El objetivo de este tipo de iniciativas es la creación de plataformas de innovación abierta de co-creación y co-diseño con los usuarios. Los Living Labs se caracterizan por estar dotados con las últimas TIC, que en la mayoría de los casos constan de conexiones de banda ancha en todos los hogares, fibra óptica perteneciente a la ciudad para evitar redundancia, y cobertura inalámbrica 3G, TV digital y Wi- Fi, entre otros (Eriksson, Veli-Pekka & Kulkki, 2005). Toda esta infraestructura se proporciona para el uso generalizado de los usuarios, quienes ofrecen y crean servicios especializados. Los stakeholders de un típico Living Lab son: los usuarios finales, los organismos públicos, las pequeñas y medianas empresas (PYME), y la academia. Cada actor contribuye a la creación y sostenibilidad del Living Lab, y como tal, espera beneficiarse de sus resultados. 2. Soluciones de Living Lab Existen diversos proyectos que proponen soluciones de Living Labs para resolver problemas específicos que se presentan en situaciones reales (p.ej. barrios, ciudades, pueblos, áreas rurales y zonas 12

14 industriales). En la Tabla 1 se presentan algunos de los principales proyectos que se han llevado a cabo en el ámbito mundial. Tabla 1. Proyectos asociados con Living Labs Nombre Ubicación Descripción Plataforma tecnológica Helsinki Living Lab - Arabianranta (1998) Botnia Living Lab (2000) Mobile City Bremen (2001) Helsinki, Finlandia Luleå, Suecia Bremen, Alemania Arabianranta-Helsinki es un proyecto destinado a permitir la creación de nuevos productos, servicios e infraestructuras sociales a través de la investigación en un contexto real, situando al usuario final en el centro del proceso, como co-creador. Botnia Living Lab ofrece un entorno para la investigación centrada en el usuario, y el desarrollo y la innovación (RDI) de nuevas ideas y servicios basados en las TIC, instrumentado por métodos, herramientas y expertos, y un portal Web para la interacción de los grupos de usuarios. Es el primer portal europeo sobre gobierno electrónico especializado en servicios públicos que utilizan tecnología móvil. Mobile City Bremen se centra en el diseño, desarrollo, validación y promoción de productos/servicios móviles y aplicaciones para cuidados médicos. - Red inalámbrica en toda el área, a través de la cual los residentes cuentan con acceso de banda ancha a Internet y a la Intranet comunitaria. - Ofrece conexiones de fibra óptica a 10 MB en cada domicilio, IPTV y teléfonos VoIP. - Red de servicios a la que los proveedores pueden conectar fácilmente sus servidores de aplicaciones o tener acceso a través de Internet. - Existe una red de proveedores de tecnología y contenidos: acceso a banda ancha, TV digital, diferentes sistemas celulares, entre otros. El programa Mobile City ha implementado una infraestructura de telecomunicaciones para brindar acceso a la banda ancha móvil (GSM - GPRS - UMTS - HSDPA). También ha desplegado con éxito nuevas aplicaciones móviles para ciudadanos y visitantes. IBBT-iLab.o (2006) Bruselas, Bélgica Las actividades y la experiencia de ilab.o se centran en las aplicaciones y servicios móviles e inalámbricos (web), las aplicaciones y servicios de la ciudad (móviles), los servicios basados en la ubicación y el contexto, y las aplicaciones y servicios e-health. - Utiliza un piloto de red WiFimesh (UrbiZone) con más 75 antenas. - El acceso a la infraestructura de banda ancha es de 1 GB. - Infraestructura SIP propia para VoIP móvil. - Infraestructura RFID (limitada) consistente de etiquetas RFID y sensores. - Cuidado de mayores: Se les dota de un media center, teléfonos 3G y webcams, además de acceso a banda ancha. - Tecnologías hospitalarias: Se instala sensorización RFID, webcams en habitaciones y oficinas, y acceso a banda ancha. Living Lab Salud Andalucía (2008) Sevilla, España El Living Lab Salud Andalucía (LLSA) es una red abierta de innovación basada en entornos, plataformas y recursos para fomentar el desarrollo y la validación de diferentes soluciones tecnológicas a problemas sociosanitarios concretos. 13

15 Todos los proyectos mencionados anteriormente han creado un gran impacto social, tecnológico y ambiental dentro de las comunidades donde se aplican. Tal es el caso del Proyecto conocido como Helsinki Living Lab (Helsinki Living Lab, 2007), el cual planea la regeneración de un antiguo y contaminado emplazamiento industrial en Helsinki mediante la construcción de nuevas infraestructuras, productos y servicios, situando a los usuarios finales en el centro del proceso. Este proyecto proporciona un portal de servicios a los estudiantes, empresas y residentes de Arabianranta. También hay una red de fibra óptica de banda ancha ofreciendo una conexión de 10 megabytes en cada hogar, IPTV y teléfonos VoIP. La innovación más reciente consiste en pantallas virtuales "Helsinki Virtual Village" situadas en avenidas, colegios y parques empresariales. Los proyectos mencionados utilizan el modelo de Triple Hélice de relaciones entre universidad, industria y gobierno (Etzkowitz, 2011), con la participación activa de los diferentes actores en el proceso de creación de nuevos productos, servicios e infraestructuras sociales. Una de las principales especificaciones de estos Living Labs es ver la tecnología como un medio para servir al uso y desarrollo de servicios para toda la población en el territorio: avances tecnológicos que pueden incluir conexiones a Internet de alta velocidad y nuevos servicios, así como acceso a banda ancha para la población rural. El diseño de la plataforma Urb@naLab ha sido basado sobre este marco teórico, esperando que proyectos específicos en ciudades o regiones colombianas piensen en cómo desarrollar verdaderos entornos de innovación y desarrollo a través del uso de las TIC, a la vez que sectores productivos puedan fortalecer sus cadenas de valor mediante la implementación de Living Labs específicos. Urb@naLab incluye un conjunto de varios usuarios en el proceso de diseño y creación de nuevos servicios, que eventualmente podrían beneficiar a la sociedad. A diferencia de otras soluciones de Living Labs que concentran su infraestructura y metodología en la creación de productos y servicios innovadores para un sector en particular, Urb@naLab ofrece un entorno para desarrollar servicios en diferentes dominios de aplicación, tales como e-salud, e-gobierno, turismo, transporte, entre otros. Otro caso similar es la iniciativa Mobile City Bremen (Mobile City Bremen, 2004), la cual busca fomentar el crecimiento económico, el buen gobierno y el desarrollo del recurso humano mediante el diseño, 14

16 desarrollo y promoción de servicios públicos que utilicen tecnología móvil. A través de un portal Web, que actúa como un banco de pruebas para servicios móviles, los usuarios finales (PYME y ciudadanos) pueden probar y desarrollar sus ideas. Las mejores propuestas de proyectos pueden ser seleccionadas y financiadas por el gobierno de la ciudad, en particular aquellas que incluyan el desarrollo de nuevos servicios m-government. Los elementos clave de Mobile City Bremen son el Mobile Research Center, que proporciona diversos entornos de hardware y condiciones reales para llevar a cabo las pruebas funcionales de las soluciones móviles propuestas, y el Mobile Solution Group, el cual ofrece los servicios en relación con la venta y comercialización de los productos elaborados dentro del Living Lab. Otro caso particular es el Living Lab Salud Andalucía (Living Lab Salud Andalucia, 2008), un proyecto que facilita la creación de una comunidad de innovación abierta para los diferentes miembros que la componen (Administración, Universidad, Empresas TIC y Usuarios finales). LLSA consiste de entornos, plataformas y recursos para fomentar el desarrollo de tecnologías, productos y servicios innovadores en el ámbito de la Salud. Su infraestructura tecnológica permite disponer de un entorno mantenido de forma continua, para las pruebas, validación y refinamiento, con usuarios cuyo perfil está incluido en adultos mayores, pacientes crónicos, personas con algún tipo de discapacidad y usuarios de instalaciones hospitalarias. Por ejemplo, en el caso del cuidado de los adultos mayores (Teleasistencia), se les dota de un media center, teléfonos 3G y webcams, además de acceso a banda; y en cuanto a las instalaciones hospitalarias, se instala sensorización RFID por las dependencias, webcams en habitaciones y oficinas, y acceso a banda ancha. 3. Aplicaciones y Servicios Existe un gran número de Living Labs, con una variedad de diferentes características, alrededor de todo el mundo (ENoLL, 2009). Algunos Living Labs se centran en una tecnología en particular, como las comunicaciones móviles o RFID (Radio Frequency Identification), otros por su parte, se centran en un grupo de servicios para ciudadanos locales o en un sector productivo concreto, sólo por mencionar algunas de estas características. A continuación se describen algunos ejemplos típicos de aplicaciones y servicios ofrecidos a través de los Livings Labs (European Commission, 2009). 15

17 a) e-services en áreas rurales o en desarrollo Debido a las altas tasas de crecimiento económico y demográfico en los países emergentes, los procesos socio-económicos son esencialmente dinámicos, encontrándose en continuo estado de cambio. Esto genera la necesidad de diseñar, implementar y evaluar los avances tecnológicos en la estructura social de un país. Lo anterior se aplica especialmente en países territorialmente grandes y de gran diversidad regional, económica y social. Los primeros pilotos de e- services (Servicios electrónicos) en zonas o áreas rurales (Collaboration at Rural, 2007), muestran los beneficios y las ventajas de la interconectividad y las redes de Living Labs, en términos de reutilización de componentes y plataformas, co-innovación e interoperabilidad, para la creación de nuevos bienes y servicios, o mejora de los ya existentes. b) e-democracy and e-governance En ambos dominios, los Living Labs pueden desempeñar un papel importante en la e-participation (Participación electrónica), para ampliar y profundizar la participación política de los ciudadanos. Los servicios de e-governance (Gobierno electrónico) y e-democracy (Democracia electrónica) tienen potencial para mejorar la rendición de cuentas y la transparencia en los procesos gubernamentales. Los principales objetivos de este tipo de servicios son: 1) Promover la participación activa de los ciudadanos en los asuntos públicos y, por tanto, en la política; 2) Conectar a los ciudadanos entre sí y con sus representantes electos; y 3) Mejorar la prestación de servicios públicos. Sin embargo, uno de los mayores obstáculos para el avance en estos aspectos son los costos asociados a la infraestructura de telecomunicaciones y el capital humano requerido para su desarrollo. c) e-wellbeing El uso de soluciones digitales en el cuidado de la salud y bienestar, conocido como e-wellbeing, también está generando una administración más eficiente y optimizada en tiempos de espera de atención a los pacientes. En un dominio como este, las redes de Living Labs pueden facilitar el desarrollo y la validación de diferentes productos, servicios y soluciones tecnológicas para resolver problemas específicos vinculados con la salud, el bienestar social y la calidad de vida de los ciudadanos. Algunos proyectos de Living Labs existentes en este ámbito (Living Lab Salud Andalucia, 2008; Gil-Castineira et al., 2011), se enfocan principalmente en temas como el seguimiento 16

18 de nuevos productos, servicios y/o procesos lanzados, la prevención y el cuidado de los pacientes. 4. Arquitecturas de Software Propuestas para el Despliegue de Living Labs Existen diversas soluciones de Living Labs que promueven la creación de componentes de software reutilizables que, a través de su combinación, permitan la construcción de una gran variedad de aplicaciones y servicios basados en los requerimientos de los usuarios finales (CoreLabs, 2007). Esto requiere de componentes estándar e independientes, interfaces estandarizadas entre los componentes, un repositorio central de componentes públicos y procedimientos estandarizados para la selección e implementación de las aplicaciones y servicios. El enfoque debe ser los procesos de negocios y el desarrollo de software orientado a los procesos, separando la lógica de negocio de la aplicación de software (Verloop, Wolfert & Beulens, 2009). En este sentido, un enfoque importante es el concepto de Gestión de Procesos de Negocio (BPM), el cual se basa en una Arquitectura Orientada a Servicios (SOA). SOA es una arquitectura de software donde la funcionalidad se agrupa alrededor de los procesos de negocio y se empaqueta como servicios autónomos e interoperables. El objetivo es facilitar el acoplamiento de los servicios con sistemas operativos, lenguajes de programación y otras tecnologías que subyacen en las aplicaciones (Li & Wu, 2009). Una arquitectura técnica basada en SOA consiste de tres capas (Erl, 2005), tal como se muestra en la Figura 2: una capa de gestión de procesos de negocio, que coordina la ejecución de servicios de negocio; una capa de servicios de negocio, que entrega los servicios de información a los procesos de negocio; y una capa de servicios de aplicación de negocio, que ejecuta la lógica de la aplicación y se encarga del almacenamiento de los datos. 17

19 Figura 2. Arquitectura SOA para componentes del sector agrícola (Wolfert et al., 2010) La modularidad de los componentes de software y la interoperabilidad abierta que ofrece SOA, ha permitido crear diversas soluciones de Living Labs altamente escalables, las cuales combinan dos enfoques: por un lado el enfoque orientado al usuario, para el desarrollo de nuevos servicios y productos en torno a las necesidades de los usuarios, y por otro, el enfoque co-creativo, para asegurar la participación activa de los usuarios a través de todo el proceso de innovación. La Figura 3 muestra la inclusión de una estructura SOA en la arquitectura de un entorno de Living Lab. 18

20 Figura 3. Arquitectura de Living Lab basada en SOA (CoreLabs, 2007) Los módulos de servicio (MS) son pequeños componentes autónomos y reutilizables, utilizados para crear aplicaciones y servicios personalizados (p.ej. e-government, e-business, e-learning, e-health, e-agriculture, entre otros). Un componente Middleware, situado entre la Capa de Aplicación y la Capa de Red, hace posible la integración de los módulos de servicio, los cuales están distribuidos sobre plataformas de servicios heterogéneas. Con el fin de eliminar las barreras de interoperabilidad y facilitar las experiencias de uso de los usuarios finales, la arquitectura debe soportar estándares abiertos donde sea posible construir, desplegar y gestionar las aplicaciones y servicios. A continuación se presentan algunos ejemplos de arquitecturas propuestas para la implementación de soluciones de Living Labs. a) C@R (Collaboration and Rural) C@R (Collaboration at Rural, 2007) es un proyecto de colaboración para entornos rurales en el que se plantea la creación de Living Labs para promover el desarrollo sostenido a través de servicios TIC innovadores subyacentes a las nuevas formas de colaboración en el 19

21 trabajo y los negocios. C@R introduce un nuevo enfoque para la creación de ecosistemas de innovación llamado Living Labs Rurales (RLL), en el que los usuarios rurales y stakeholders se unen para desarrollar e implementar innovaciones que permitan acelerar el desarrollo socio-económico de las zonas rurales. La arquitectura de C@R proporciona una plataforma para Ambientes de Trabajo Colaborativos (CWE) orientados al usuario, los cuales se usan para crear una red de conocimiento distribuido en las ambientes rurales. El enfoque de la arquitectura se basa en una Arquitectura Abierta Orientada a Servicios (OSOA) y soporta la reutilización, contextualización y personalización de componentes de software para construir servicios y aplicaciones para el usuario final (Schaffers et al., 2010). El esquema de la arquitectura de C@R se muestra en la Figura 4. La arquitectura se basa en un modelo de tres capas. Figura 4. Arquitectura en capas de C@R (Dörflinger & Louw, 2008) De abajo hacia arriba, los componentes de Servicios Básicos de Colaboración (CSS) en la Capa 1 son recursos independientes, los cuales serán orquestados por un Middleware, representado en la Capa 2, usando scripts de servicios y funciones de colaboración (Capacidades de Orquestación) dentro de las Herramientas Software 20

22 de Colaboración (SCT) en la Capa 3. Estas SCT serán instanciadas dentro de las aplicaciones y servicios utilizadas en los Living Labs Rurales (RLL), formando parte de los CWE. Un componente principal en la arquitectura de C@R es el Bus de Control, que se encuentra en la Capa 2. Este actúa como un agente, permitiendo al sistema buscar recursos y gestionar sus interconexiones. Los CCS se implementan como servicios web reutilizables que encapsulan una funcionalidad básica (p.ej. conectividad 3G y Wi-Fi, función GPS, entrega de SMS, etc.). Estos se registran al Bus a través de una interfaz definida para ofrecer su funcionalidad a los CWE. Las Capacidades de Orquestación (OC): Conocimiento del Contexto, Estaciones de Trabajo Distribuidas y Servicios Avanzados, actúan como componentes de software, proporcionando servicios comunes para todos los SCT. Las OC se pueden implementar como servicios web (siguiendo el diseño de los CCS) o como librerías estáticas desplegadas junto con el Bus. Las SCT son aplicaciones para el usuario final que cubren las necesidades de los RLL. Estas son descritas a través scripts e interpretadas por el Motor de Composición de la Capa 2. Los scripts contienen las especificaciones de todos los elementos necesarios (CCS), los flujos de trabajo, así como las interacciones y llamadas a las funciones de colaboración y librerías proporcionadas por los componentes OC. Adicional a las tres capas básicas, se introduce una Capa Web 2.0 y una Capa Semántica para enfrentar los problemas de infraestructura y medio ambiente en las zonas rurales. La Capa Web 2.0 está ubicada en la Capa 3 para mejorar la funcionalidad y comportamiento de las SCT, las aplicaciones de usuario instanciadas en los RLL. Mientras que la Capa Semántica es una capa horizontal que proporciona funcionalidades a todas las capas. La arquitectura de C@R ha sido implementada en varias zonas rurales (seis en Europa y uno en África del Sur), y se ha puesto a prueba en diferentes sectores como la pesca, la agricultura y el gobierno. b) Wireless Playground Wireless Playground es un entorno de pruebas abierto que permite validar dispositivos, servicios y aplicaciones novedosas con el fin de realizar mejoras a las infraestructuras inalámbricas existentes, utilizando un enfoque de Living Labs (Ponce de Leon et al., 2006). La arquitectura de Wireless Playground proporciona a los usuarios 21

23 (investigadores, desarrolladores y usuarios finales) diversas funcionalidades para realizar pruebas que no sólo se limitan a la validación de dispositivos y servicios, sino también a los distintos protocolos de red que soportan las redes inalámbricas. Como se ilustra en la Figura 5, Wireless Playground está organizado utilizando el patrón de arquitectura en capas, conectando varios planos de gestión distribuidos, que combinan bancos de pruebas inalámbricos heterogéneos, ubicados geográficamente en diferentes lugares. Figura 5. Arquitectura de Wireless Playground (Ponce de Leon, 2009) El banco de pruebas incluye tecnologías de acceso como GSM/GPRS, UMTS, WLAN, W-MAN, Bluetooth, WLL (Wireless Local Loop) y conexiones a redes principales que soportan protocolos IPv4, IPv6, Mobile IP, y DVB-T (terrestre) y DVB-S (satelital). Estas tecnologías de acceso son usadas por los usuarios finales para acceder a los servicios y aplicaciones (p.ej. m-health, m-learn, m- Government, m-banking, etc.) en cualquier momento y lugar. Para una mayor agilidad en el acceso a los servicios, el banco de pruebas usa tecnologías y protocolos estándar como SIP, OSA Parlay, Parlay X, 22

24 IMS (IP Multimedia Subsystem) y Push-to-Talk. La idea principal es poder compartir esta plataforma de servicios y componentes Middleware dentro de la red. También, se dispone de un conjunto de herramientas y métodos de evaluación para realizar pruebas técnicas y humanas relacionadas con desempeño de las aplicaciones y servicios. El banco de prueba incluye dentro de sus procesos de validación, pruebas de conformidad, interoperabilidad, rendimiento y escalabilidad. Las tecnologías para la administración y control de la red se concentran en una plataforma innovadora que soporta diferentes estrategias de gestión y provee la administración cooperativa entre varios sistemas de gestión. A esto se puede acceder por medio de la Interfaz de Monitoreo Remota, la cual proporciona acceso tanto a usuarios individuales, como a sistemas de monitoreo que realicen tareas de administración conjuntas. En la Figura 6 se muestra un ejemplo de aplicación de Wireless Playground con dos planos de gestión. Cada banco de pruebas tiene un perfil que se encuentra en un Repositorio de Archivos (DR), el cual contiene toda información acerca de las tecnologías de acceso, los protocolos de transporte y las plataformas de servicio soportadas por un banco de pruebas específico. Figura 6. Wireless Playground (Ponce de Leon et al., 2006) 23

25 En el sitio A, el perfil consiste de la plataforma de servicios Parlay X, soportada por los protocolos Mobile IPv6, IPv6 y SIP; mientras que el sitio B soporta la plataforma de servicios OSA Parlay con los protocolos DVB (Digital Video Broadcasting), IPv6 e IPv4. El perfil también describe las diferentes redes de acceso para cada sitio de prueba (p.ej. el sitio A soporta las tecnologías GPRS y WLAN, mientras que el sitio B soporta las tecnologías WMAN, Bluetooth, y UMTS). Cada tecnología de acceso tiene su propio Gestor de Conmutación (SM), el cual se encarga de administrar de forma individual las instancias de llamado a cada tecnología, acoplándose a los diferentes medios de comunicación (circuitos conmutados o flujos IP). Los usuarios pueden visualizar el perfil y las capacidades de los diferentes bancos de pruebas y seleccionar el más apropiado para sus necesidades. Una vez seleccionado, el código heredado puede ser enviado a los repositorios (Repositorio de Servicios - SR) y ejecutar su código mientras que se realiza el seguimiento a sus capacidades de forma remota, a través de las Instalaciones de Control (MF). Gracias a que los bancos de pruebas usan tecnologías y protocolos estándar, es posible compartir las plataformas de servicios y Middleware dentro de la red, por ejemplo, si un usuario necesita evaluar un servicio específico en OSA Parlay y Parlay X, puede probarlo tanto en el sitio A como en el B. Por cada prueba el usuario puede analizar el desempeño a través de la Interfaz de Monitoreo Remota (RMI) durante su ejecución. El proyecto OPIUM (OPIUM, 2001) es un ejemplo de la integración de varios bancos de pruebas inalámbricos, cuyo objetivo es apoyar el despliegue de servicios comerciales de telefonía móvil en Europa, centrándose en la validación de aspectos claves como la interoperabilidad, el roaming y la facturación antes de ser liberados, a través de la interconexión de plataformas Middleware abiertas basadas en OSA/Parlay. 5. Beneficios y Limitaciones de las Soluciones de Living Labs Propuestas Las soluciones de Living Labs revisadas en esta sección son modelos que se pueden tomar como referencia inicial para construir otras soluciones de Living Labs, considerando el éxito que han tenido dentro de sus campos de aplicación (servicios, negocios y desarrollo de tecnología). Sin embargo, también se debe considerar el hecho de que es necesario utilizar técnicas, herramientas y procesos de desarrollo y 24

26 administración específicos para implementar algunas tecnologías y estándares, como es el caso de SOA y todos sus componentes (Enterprise Services Bus - ESB, Web Services, BPM, entre otros), los cuales pueden llegar a ser muy maduras y complejas para los propósitos del entorno de Living Lab que se desea construir. En este sentido, otra alternativa que compite con SOA es REST (Representational State Transfer), un estilo de arquitectura de software que tiene un diseño simple y utiliza técnicas de desarrollo informales (no requiere de herramientas adicionales) para construir grandes sistemas distribuidos. Tanto SOA como REST tienen sus ventajas y desventajas, por lo que la selección de una de estas dos alternativas se debe basar en el contexto en el que se quiera implantar. C. Arquitectura de Software de Urb@nalab El concepto de Living Lab, entendido como una estrategia centrada en el usuario, basada en la Web y en las redes sociales móviles, que facilita la generación de nuevas oportunidades de innovación (open innovation), las interacciones tecnológicas y la experimentación de nuevos productos/servicios, se integra al diseño de la arquitectura de la plataforma Urb@naLab. 1. Enfoque Metodológico El enfoque metodológico recomendado por Almirall (2008) and Schaffers (2008) divide el concepto de Living Labs en tres espacios: Un espacio de generación o especificación de ideas, el cual permite la interacción entre los diferentes los actores que participan en el proceso (universidad-empresa-usuarios-gobierno), aportando al diseño y la creación de ideas, que apuntan al desarrollo de nuevos productos, servicios y sistemas innovadores en diferentes contextos de la vida real. Un espacio de colaboración, que permite el trabajo en equipo y la comunicación constante entre los actores involucrados. Es así, como se logra aprovechar el conocimiento y la potencialidad de los diferentes sectores y ámbitos de una sociedad. Un espacio de evaluación y validación, en el que los usuarios finales experimentan aplicaciones o tecnologías, por ejemplo, la computación ubicua, conectividad móvil, apropiación de las TIC en la Educación (e-learning), la Salud (e-salud), el Turismo (e- Turismo), etc., con el fin de evaluar las nuevas ideas y conceptos 25

27 innovadores, su uso, experiencias de usuario y oportunidades. Basándose en este enfoque se plantearon las actividades requeridas para el desarrollo de la plataforma Urb@naLab, que cubre estos tres espacios desde la perspectiva de las necesidades de los entornos urbanos de una ciudad colombiana. 2. Visión General de Urb@naLab Como se muestra en la Figura 7 la plataforma Urb@naLab proporciona un medio para que los ciudadanos tengan una voz en las iniciativas de la ciudad. Los usuarios interactúan entre ellos y con otros componentes de infraestructura externos, como terminales móviles, a través de un sitio Web disponible para definir, probar, desarrollar y evaluar innovadoras ideas de servicios. Los usuarios deben registrase con un nombre de usuario y una contraseña antes de usar el sitio, el cual incluye una versión especial para dispositivos móviles. Figura 7. Visión general de Urb@naLab 26

28 Una vez registrados, los usuarios pueden ver su perfil y acceder a una variedad de características y recursos dependiendo de su rol (p.ej. ciudadanos registrados, investigadores y proveedores de servicios). La plataforma Urb@naLab concibe un aprendizaje de los gustos y las características de los ciudadanos, que pueden ser obtenidos a partir de fuentes externas como sitios de redes sociales tales como Facebook, o directamente desde la plataforma de computación urbana. El usuario y su intervención harán posible la definición de servicios, dando paso a la co-creación presente en los Living Labs. Esto permitirá a los proveedores construir servicios dentro de áreas de dominio específicas, los cuales posteriormente serán liberados para los ciudadanos a través de la plataforma. Por ejemplo, servicios de e- Salud que mejoren la calidad de los procesos clínicos utilizados por las entidades de salud, los pacientes y consumidores, o servicios de e- Gobierno que permitan la participación de los ciudadanos en los proceso de gobierno en cualquier momento y lugar. 3. Planteamiento de la Arquitectura de Urb@naLab El planteamiento de una arquitectura flexible y extensible que permita el despliegue de servicios orientados al ciudadano, supone una abstracción por capas en la que se considera la co-creación en espacios de generación de ideas, de colaboración, y de validación. Para cumplir con la metodología se han definido una serie de componentes que permitirán un alto grado de observación y creatividad en los entornos de interacción de los ciudadanos, dando como resultado la arquitectura que se plantea en la Figura 8. 27

29 Figura 8. Componentes de El componente de creación de ideas permite la presentación de ideas por parte de los proveedores de servicios. Aquí la comunidad podrá conocer las ideas calificadas por sector y retroalimentar la concepción de la idea a través de la red social. Este componente también es el responsable de entregar la información necesaria para la construcción del prototipo del servicio (componente de prototipado). Una vez la idea ha sido evaluada por la comunidad, el sistema permitirá la publicación de un prototipo del servicio, que será nuevamente compartido a los usuarios de la red social, con el fin de obtener la segunda evaluación de la misma. El componente de publicación fija los parámetros básicos que permitirán a los proveedores de servicios publicar los pilotos y servicios terminados. Mientras que el componente de validación, valida y condensa los resultados obtenidos en los entornos de interacción. Finalmente, el componente de etiquetado clasifica, mediante etiquetas, las ideas, prototipos, pilotos y servicios. Además, permite clasificar los gustos y preferencias de los usuarios. 28

30 4. Vistas de la Arquitectura La arquitectura de la plataforma hace uso del esquema 4+1 vistas de Arquitectura (Kruchten, 1995) y de las principales características de SOA (Arquitectura Orientada a Servicios). La plataforma Urb@naLab se concibe desde una Arquitectura Funcional, una Arquitectura de Desarrollo, una Arquitectura de Procesos y una Arquitectura de Implementación, tal y como se muestra en la Figura 9. Figura 9. Vistas de la Arquitectura La Arquitectura Funcional de la plataforma Urb@naLab, se presenta en la Figura 10. Esta arquitectura define los sistemas, subsistemas y componentes. En ella, se plantea un Urb@na Studio, donde se concentrará todo el trabajo de creación de los ciudadanos para la generación y especificación de las ideas, un Urb@na Mobile, que proporcionará ubicuidad a la plataforma, y un Urb@na Repository, que será el motor de la plataforma. La comunicación se establecerá a través del Urb@na Context. 29

31 Figura 10. Arquitectura Funcional En la Arquitectura de Desarrollo se han definido las capas, los componentes y las invocaciones. Para ello se hace uso de un esquema de capas (layering) descrito en PoEAA (Patterns of Enterprise Application Architecture) por Fowler (2003). Así mismo, se han definido varios tipos de componentes y frameworks para construir los tipos de componentes para cada una de las capas (ver Figura 11). Figura 11. Arquitectura de Desarrollo 30

32 Como esquema para el desarrollo de la solución se plantea: Uso de Java Enterprise Edition JEE6 para el manejo de la lógica de negocio, por su madurez (es la versión más reciente de Java), escalabilidad y confiabilidad de la misma. Uso de Portal Liferay para la presentación (portlets para la interfaz de usuario), considerando la integración de servicios y funcionalidades relacionadas con la seguridad y de redes sociales. Uso de JSF/IceFaces para el manejo de la interfaz de usuario, dada la variedad de componentes visuales, y el soporte a múltiples portlets con AJAX y comunicación entre portlets. En la Figura 12 se presenta la Arquitectura de Procesos, en la cual se establecen los procesos, las capas y las comunicaciones. Dentro de los servidores/software a usar se encuentran: Portal: Liferay Portal Community Edition v6.0 GA4 Servidor de aplicaciones: Glassfish v3.1 Sistema de Base de Datos: Postgress Sistema de Directorio: OpenLDAP v (Apache Directory) Figura 12. Arquitectura de Procesos Finalmente, la Arquitectura de Despliegue (ver Figura 13), permite modelar la disposición física o topológica de la plataforma Urb@naLab. En ella se muestra el hardware usado y los componentes instalados en el hardware. También se muestran las conexiones físicas entre el hardware y las relaciones entre los componentes. 31

33 Figura 13. Arquitectura de Despliegue El diseño de la plataforma se podrá adaptar por componentes a diferentes tipos de ciudades, y se espera que pueda ser transferida a proyectos de Living Labs a nivel local o regional, para contribuir de manera decisiva a resolver problemas y mejorar situaciones en la mayoría de los sectores (p.ej. salud, turismo, educación, entre otros), con necesidades y aplicaciones tecnológicas particulares. D. Conclusiones Los Living Labs han sido utilizados en numerosos proyectos relacionados con el trabajo colaborativo, la co-creación, experimentación y pruebas de nuevos productos y/o servicios. Las características más importantes de los Living Labs como plataformas de innovación abierta son: la participación balanceada de los distintos actores en todas las etapas de la cadena de innovación, la disponibilidad de la infraestructura tecnológica necesaria para investigar y experimentar sobre las TIC, y el establecimiento de una organización estable que asegura la sostenibilidad de las soluciones TIC creadas y los servicios proporcionados por la infraestructura de 32

34 los Living Labs. Todas estas características convierten el enfoque de Living Labs en una práctica muy atractiva para aplicar en iniciativas de innovación centradas en los ciudadanos y soportadas por las TIC. Este capítulo presenta el diseño de una nueva plataforma de software llamada Urb@naLab, que usa el concepto de Living Lab para facilitar la investigación e innovación de cadenas de valor, especialmente en las actividades de co-creación. El diseño de la plataforma Urb@naLab se basó en un marco teórico que incluyó la revisión de algunas soluciones de Living Labs y arquitecturas de software propuestas para la implementación de este tipo de entornos. Esta revisión permitió conocer los antecedentes de la investigación, fijar conceptos claves e identificar las ventajas y limitaciones del desarrollo de las diferentes soluciones de Living Labs. Una de las ventajas más importantes de Urb@naLab es la integración de las necesidades e intereses de los usuarios finales y otros actores en la generación de ideas y especificación de servicios para diferentes sectores productivos (p.ej. la salud, la industria, el turismo, etc.), yendo más allá de otras soluciones de Living Labs que enfocan su infraestructura y metodología en la creación de productos y servicios innovadores para un sector en particular. Por otra parte, gracias al diseño de una arquitectura abierta y flexible, Urb@naLab podrá adaptarse por componentes a diferentes tipos de ciudades generando el mismo impacto tecnológico y de innovación en la población. E. Referencias Almirall, E. (2008) Living Labs and Open Innovation. Open Innovation and Renewal. CKIR Workshop 2008, Helsinki. Bergvall-Kåreborn, B., Holst, M., & Stahlbrost, A. (2009) Concept Design with a Living Lab Approach. Proceedings of 42rd Hawaii International Conference on System Sciences (HICSS 09), January 2009, pp Collaboration and Rural (2007) [Online] Available from [Accessed May 12, 2011]. CoreLabs (2007) Building Sustainable Competiveness - Living Labs Roadmap Luleå University of Technology, Centre for Distance-Spanning Technology, Luleå, Sweden. Dörflinger, J., & Louw, R. (2008) Open SOA Value Add for Collaborative Services Delivery to Rural SMMEs. Proceedings of the IST Africa, May Eriksson, M., Veli-Pekka, N., & Kulkki, S. (2005) State of the Art in Utilizing Living Labs Approach to User- Centric ICT Innovation - A European Approach [Unpublished working paper]. Erl, T. (2005) Service-Oriented Architecture: Concepts, Technology, and Design. New Jersey, USA: Prentice Hall. Etzkowitz, H. (2003). Innovation in Innovation: The Triple Helix of University-Industry-Government Relations. Social Science Information, 42(3), pp European Commission (2009) Living Labs for User-Driven Open Innovation. An Overview of the Living Labs 33

35 Methodology, Activities and Achievements. Fahy, C., Ponce de Leon, M., Ståhlbröst, A., Schaffers, H., & Hongisto, P. (2007) Services of Living Labs and their Networks. Proceedings of the echallenges 2007 Conference, October Følstad, A. (2008) Living Labs for Innovation and Development of Information and Communication Technology: A Literature Review. Electronic Journal for Virtual Organizations and Networks (ejov), Special Issue on Living Labs, 10, pp Fowler, M. (2003) Patterns of Enterprise Application Architecture. Boston, MA: Addison-Wesley. Gil-Castineira, F., Costa-Montenegro, E. Gonzalez-Castano, F.J., Lopez-Bravo, C., Ojala, T., & Bose, R. (2011) Experiences inside the Ubiquitous Oulu Smart City. IEEE Computer Society, 4(6), pp Helsinki Living Lab (2007) [Online] Available from [Accessed June 15, 2011]. Kruchten, P. (1995) The 4+1 View Model of Architecture. IEEE Software, 12(6), pp Li, H., & Wu, Z. (2009) Research on Distributed Architecture Based on SOA. IEEE Symposium International Conference on Communication Software and Networks, January 2009, pp Living Lab Salud Andalucia (2008) [Online] Available from [Accessed June 19, 2011]. Mobile City Bremen (2004) [Online] Available from [Accessed June 19, 2011]. Mulvenna, M., Bergvall-Kåreborn, B., Wallace, J., Galbraith, B., & Martin, S. (2010) Living Labs as Engagement Models for Innovation. Proceedings of the echallenges 2010 Conference, Paul Cunningham and Miriam Cunningham (Eds), IIMC International Information Management Corporation, pp Open Living Labs (2009) European Network of Living Labs [Online] Available from [Accessed May 26, 2011]. OPIUM (2007) Open Platform for Integration of UMTS Middleware [Online] Available from [Accessed May 12, 2011]. Ponce de Leon, M., Balasubramaniam, S., & Donnelly, W. (2006) Creating a Distributed Mobile Networking Testbed Environment - Through the Living Labs Approach. Proceeding of the 2nd International IEEE/Create-Net Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities, March 2006, pp Schaffers, H. (2008) Living Labs Methodological Approach and e-democracy. CKIR, Helsinki School of Economics. Schaffers, H., Merz, C., García Guzman, J., & Navarro, M. (2010) Living Labs and Rural Development: Overview of the C@R Project. Electronic Journal for Virtual Organizations and Networks (ejov), 11, pp.2-8. Ståhlbröst, A., Lievens, B., Merz, C., & Turkama, P. (2010) A Catalogue of state-of-the-art concepts, existing tools and lessons learned for cross-border Living Lab networks. Advanced Pilots of Living Labs Operating in Networks (Apollon), May Svensson, J., Eriksson, C., & Ebbesson, E. (2010) User Contribution in Innovation Processes - Reflections from a Living Lab Perspective. Proceedings of 43rd Hawaii International Conference on System Sciences (HICSS 10), January 2010, pp Thoben, K.-D. (2006) The Living Labs Approach as a Service Provision Paradigm. German Living Labs Day, September Tongia, R. (2007) Connectivity in Emerging Regions: The Need for Improved Technology and Business Models. IEEE Communications Magazine, Special Issue on New Directions in Networking Technologies in Emerging Economies, 45, pp Verloop, C.M., Wolfert, J., & Beulens, A.J.M. (2009) Living Lab: Information Management in Agri-Food Supply Chain Networks. Proceedings of the 7th EFITA Conference, July 2009, pp Wolfert, J., Verdouw, C.N., & Verloop, C.M., Beulens, A.J.M. (2010) Organizing Information Integration in Agri- Food: A Method based on a Service-Oriented Architecture and Living Lab Approach. Computers and Electronics in Agriculture, 70(2), pp

36 Capítulo 2 Plataforma Urb@naLab Claudia L. Zúñiga 4 Andrés Millán 5 Andrea Arteaga P. 6 Josymar de León 7 Cristián Chaparro 8 Leonardo Vargas B. 9 Abstract. La Plataforma Urb@naLab, es una plataforma de computación urbana que sigue la metodología de Living Labs, y sirve como base tecnológica para el despliegue en ciudades, permitiendo la interacción de los ciudadanos en un entorno social y la cocreación de servicios. En este capítulo se presenta el diseño, las herramientas tecnológicas utilizadas y desarrollo de la Plataforma Urb@naLab. A. Introducción Las propuestas de innovación en ciudades digitales han permitido definir un nuevo enfoque de interacción entre los habitantes, las 4 Directora Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. claudia.zuniga00@usc.edu.co 5 Investigador Principal del Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. afmillan@ieee.org 6 Investigador Asistente del Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. andreaarteagap@yahoo.com 7 Desarrollador del Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. jossydeleon@gmail.com 8 Desarrollador del Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. ca.chaparro@hotmail.com 9 Auxiliar de Investigación del Grupo de Investigación en Informática y Telecomunicaciones i2t, Facultad de Ingeniería, Universidad Icesi. lvargas@icesi.edu.co. 35

37 empresas y el gobierno, enmarcado en el concepto de Living Labs, cuyo objetivo es favorecer el desarrollo económico y social a través de la generación de nuevas aplicaciones y servicios orientados hacia los ciudadanos. Los Living Labs tienen su origen en el Profesor William Mitchel (Almirall, 2008), quien lo planteó como una metodología de investigación para probar, validar, realizar prototipos y refinar soluciones complejas en entornos reales. De esta manera el grupo investigador desarrollo una investigación en entornos urbanos abiertos como son las ciudades usando la metodología de Living Labs, dando como resultado el desarrollo de la Plataforma de Computación Urbana Urb@naLab (Zúñiga et al., 2011). La Plataforma UrbanaLab permite el desarrollo de cadenas de innovación que requieren la colaboración de múltiples actores en diferentes contextos, dentro de entornos inalámbricos y móviles. Su objetivo es servir como mediadora de iniciativas urbanas fomentadas por las comunidades de usuarios, las empresas privadas o públicas y los operadores de telecomunicaciones, que generen nuevos sistemas de innovación basados en tecnologías de información y comunicaciones. La plataforma tiene 4 componentes. El primero, denominado Módulo de Ideas, es un espacio que permite la formulación de ideas de servicios por parte de los actores sociales involucrados en el Living Lab; esas ideas pueden clasificarse y recibir aportes de terceros para enriquecer su contenido y para fortalecer aspectos relacionados con el público objetivo y con las estrategias para su ejecución. Constituye el primer nivel de colaboración en la estructura. El segundo, denominado Módulo de Prototipos, permite la exploración de implementaciones tempranas de los servicios y su validación mediante la participación activa de usuarios objetivo. A diferencia del módulo de ideas, este presenta documentos multimedia que facilitan la evaluación de las propuestas por parte de los interesados, y permite definir aspectos como la arquitectura, la experiencia de usuario y las herramientas necesarias para construir un aplicativo estable que pueda desplegarse para un grupo de usuarios piloto. El tercer componente es el Módulo de Pilotos, que permite la evaluación en campo de los aplicativos con un grupo controlado de usuarios en un ambiente urbano-experimental. En esta etapa se recogen datos relacionados con la ejecución del servicio: los 36

38 componentes más utilizados, los reportes de fallas y las posibles mejoras. Es la última etapa antes de liberar el servicio y por eso incluye componentes de interoperabilidad con herramientas para despliegue de aplicaciones de tipo PaaS, para registrar evaluaciones desde espacios externos a la plataforma. Transversal a los módulos descritos anteriormente está el Módulo de Validación, que permite explorar los avances y eventos de una propuesta conforme pasa por las etapas del Living Lab. Su objetivo es validar el aporte de la interacción de los actores sociales en la construcción de servicios orientados al ciudadano y la influencia de las cadenas de innovación y de colaboración en la creación de iniciativas urbanas, es decir, medir la efectividad del Living Lab. B. Diseño de la Plataforma Urb@naLab 1. Vistas de Arquitecturas La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo funciones especiales según los requerimientos, interfaces y la forma de comunicación entre ellos. A su vez esta arquitectura debe ser implantada en una arquitectura física, donde se define los servidores de aplicaciones, servidores de base de datos y servidores web. De acuerdo al análisis y diseño realizado por los desarrolladores del Grupo de investigación, se definen las siguientes vistas de arquitectura para los módulos de la Plataforma Urb@naLab. Tabla 1. Vistas de Arquitectura Vista de Arquitectura Descomposición Funcional Observaciones Específico para los módulos de la plataforma Urb@naLab Capas y componentes Modelo estándar para los módulos de la plataforma Urb@naLab Distribución Física Modelo estándar para aplicaciones desarrolladas bajo la tecnología de portales en Java a) Vista de Descomposición Funcional La plataforma Urb@naLab al adoptar la metodología de Living Labs 37

39 y computación Urbana, requiere de componentes que estén ligados con la parte social y la caracterización del usuario, En realidad, la definición de la arquitectura se basa en un conjunto de diferentes perspectivas del sistema que ofrecen información diversa de los componentes. La documentación de la arquitectura de software se basa en la presentación de las vistas relevantes y en documentar la información que aplica a ellas. Es por ello que se definen varios módulos de interacción: Figura 1. Módulos de la Plataforma Urb@naLab 38

40 Figura 2. Componentes de la Plataforma Cada uno de los módulos incluye funcionalidades diferentes que permiten dar solución a los requerimientos definidos para el proyecto. En la sección de Requerimientos fueron descritas las funcionalidades que van a tener cada uno de los módulos. Figura 3. Sub Módulos Módulo de Servicios (Prototipado) 39

41 Figura 4. Sub Módulos Módulo De Redes Sociales. b) Vista de Capas y Componentes La plataforma Urb@naLab se basa en un modelo de arquitectura de 3 capas (Ver Figura 5): Capa de presentación: es la encargada de la visualización de datos, interfaz gráfica y el manejo de eventos realizados por el usuario. Capa de lógica de dominio: encargada del manejo de las validaciones y las reglas y procesos del negocio. Capa de acceso a datos: encargada del acceso a la base de datos. Figura 5. Vista de Capas 40

42 Figura 6. Vista de Capas y Flujo entre ellas Con el fin de facilitar el desarrollo y contar con un mecanismo simple de despliegue y operación, el modelo se basa en objetos planos conocidos como POJOs (Plain Old Java Objects), y no en un esquema basado en componentes empresariales (EJB, Enterprise Java Beans) o en un Bus de Servicios (ESB, Enterprise Service Bus). El esquema basado en objetos planos, permite desarrollar toda la aplicación empleando un esquema basado en objetos de entidad transversales a todas las capas. Los objetos de entidad que se obtienen a partir de la capa de acceso a datos, pueden ser utilizados en las capas de lógica de dominio y de presentación.para hacer uso del esquema basado en objetos planos, se usan librerías que soportan este modo de operación: Una serie de componentes en PrimeFaces, para la visualización y edición de las hojas de cálculo directamente en el navegador web. Java Server Faces (JSF), para la generación de pantallas y el manejo de los eventos de la interfaz de usuarios. El modelo de Expresiones de JSF o Spring, para el manejo de las configuraciones de la lógica de negocio. JPA con Hibérnate, para el manejo de la persistencia de los datos. En particular, para el acceso a los metadatos y la actualización de la base de datos. 41

43 La capa de presentación se construye basada en el uso de Java Server Faces (JSF). Cada una de las pantallas de la aplicación es construida en un archivo separado empleando una página Java Server Pages (JSP) con los componentes Java Server Faces (JSF). Por cada uno de los formularios, con el archivo JSP con JSF, se cuenta con un objeto plano con el manejo de los campos y los eventos asociados a los formularios. Este objeto conocido como un Backing Bean, es un objeto que se maneja a nivel de petición web (request). Los formularios y pantallas, cuando requieren datos de la aplicación o que son mantenidos en memoria, hacen uso de otros objetos planos conocidos como Managed Beans. Estos objetos representan el Modelo, la representación de los datos que se obtiene de la lógica de dominio y el acceso a datos. Estos objetos se manejan a nivel de sesión de usuario (session). Figura 7: Capa de Presentación. Las pantallas JSP/JSF al momento de visualizar las hojas de cálculo, interactúan con unas librerías y componentes en Javascript para tal fin. Las pantallas envían la información al navegador en un conjunto de datos XML y los componentes en Javascript se encargan de visualizar el contenido. Cuando los objetos de la capa de presentación requieren ejecutar alguna operación sobre la lógica de dominio, hacen uso de una serie de objetos delegados para tal fin. Los objetos delegados son definidos a partir de una Interfaz establecida que puede ser implementada de diversas formas. El delegado es obtenido a partir de una fábrica que revisa la configuración del sistema y retorna un objeto de la clase apropiada. Este mecanismo permite aislar la capa de presentación de la implementación del manejo de la lógica de dominio, permitiendo que 42

44 pueda realizarse localmente empleando objetos planos o remotamente usando componentes de servidor (EJBs) o servicios web. El acceso a datos se realiza empleando el manejador de sesiones y de transacciones establecido en Hibérnate con los objetos planos definidos como objetos de entidad. Figura 8. Capa de Acceso a Datos. Figura 9. Flujo entre Capas. Patrones y Arquitectura de Software De acuerdo al modelo de arquitectura seleccionado por el grupo de desarrollo para la construcción de los módulos que conforman la 43

45 plataforma, se seleccionan un conjunto de patrones y arquitecturas de software, brindando solución a problemas comunes y facilitando el desarrollo de aplicaciones. Los patrones de software proporcionan componentes reusables y permiten la estandarizar la forma se realiza el diseño de las aplicaciones, por ello se definen los siguientes patrones utilizados en el desarrollo de los módulos de la plataforma Urb@naLab. c) Modelo Vista Controlador Para el diseño de aplicaciones con interfaces graficas se utiliza el patrón de diseño Modelo-Vista-Controlador el cual es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. En el desarrollo de los módulos de la Plataforma Urb@naLab el cual son pequeñas aplicaciones web independientes (Portlets) tienen vistas en formato JSP, el modelo es el encargado de enviar y recibir datos del Servicio Web (Rest) que define la lógica del negocio y el acceso Base de Datos y validación de cada componente que lo necesite; y el controlador es el responsable de recibir los eventos de entrada desde la vista. (Sauter, 2005). Figura 10. Modelo Vista Controlador El modelo es el responsable de acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento, también define las reglas de negocio (la funcionalidad del sistema). El controlador es responsable de recibir los eventos de entrada (un clic, un cambio en un campo de texto) y contiene reglas de gestión de eventos, estas acciones pueden suponer peticiones al modelo o a las vistas. Las vistas son las encargadas de recibir datos del modelo y mostrarlos al usuario. 44

46 d) Rest (Representational State Transfer) Para la capa de Acceso a datos se utilizan la tecnología de Servicios Web basados en Rest, una arquitectura de software para ambientes distribuidos, permitiendo separar la lógica de acceso a la Base de datos de la lógica del desarrollo de cada módulo. REST es un modelo orientado a recursos. Básicamente significa que cada URL es la representación de un objeto o recurso. Por su parte, cada recurso tiene representaciones posibles, puede ser XML o Json. (Gregorio, 2004). Se decide adoptar el uso de esta arquitectura (REST), permitiendo la construcción de toda la lógica del negocio de Urb@naLab y publicarlas como servicio web, con el fin de que futuros desarrolladores puedan acceder a estos servicios ya construidos en instalados en un servidor de aplicaciones diferente a donde se aloja el portal. e) Patrón DAO (Objeto de Acceso a Datos) El uso de un lenguaje de orientado a objetos como lo es Java y el uso de un sistema de base de datos relacional llevo al Grupo de Investigación al uso del Patrón DAO, el cual es un componente que suministra una interfaz común entre la aplicación y uno o más dispositivos de almacenamiento de datos, tales como una Base de datos o un archivo. El Patrón DAO es la solución al problema diferencial de impedancia entre un programa escrito en un lenguaje de programación orientado a objetos y el uso de una base de datos relacional. Una restricción al usar este patrón es que solo las interfaces pueden comunicarse con la base de datos (Oracle, 2011). Es aquí donde resulta interesante, el uso del patrón MVC y Rest, la aplicación es modular y es el modelo quien mediante de un controlador HTTP se comunica al DAO para obtener datos almacenados en la base de datos. f) Vista de Distribución Física La Plataforma Urb@naLab se basa en un modelo de arquitectura orientado a virtualización, es decir en un gran servidor (hardware) se alojan 4 máquinas virtuales. El modelo consta de 5 niveles: Clientes: es donde se ejecuta la aplicación en navegadores web. En el caso de la plataforma Urb@naLab los equipos corren los sistemas operativos: Windows, Linux y Mac. 45

47 Máquina virtual Servidor de Aplicaciones: donde funciona toda la plataforma web y cada uno de los módulos que la conforman. Máquina virtual Servidor LDAP: donde funciona un directorio activo para la autenticación de usuarios en la plataforma. Máquina virtual Servidor de Base de datos: en donde funciona el motor de base de datos y donde se encuentra todo el repositorio de información. Figura 11. Arquitectura Física de Urb@naLab Para la ejecución del proyecto Urb@naLab se definen 3 entornos de operación: Entorno de desarrollo: utilizado por los desarrolladores para la construcción de módulos de la plataforma Urb@naLab. Este entorno es configurado muy similar a la arquitectura física propuesta, para la facilidad de desarrollo, depuración y pruebas de unidad. 46

48 Figura 12. Componentes Máquina de Desarrollo Entorno de pruebas: utilizado para hacer pruebas de integración de software y pruebas generales con usuarios. Los componentes utilizados son una réplica de cada una de las Máquinas virtuales definidas en la Figura 11. Entorno de producción: utilizado para poner en funcionamiento, la Plataforma Urb@naLab con todos los módulos integrados. Los componentes y aplicaciones de software utilizados se describen en la Figura 11. C. Desarrollo de la Plataforma Urb@naLab 1. Tecnologías El núcleo de Urb@naLab está construido bajo el lenguaje de programación orientado a objetos Java, que a su vez está desarrollado en un ambiente de Portales Web permitiendo definir una Plataforma colaborativa e intuitiva para los usuarios, ofreciendo mayor interacción. 2. Portal Web Liferay Un Portal Web se define como una plataforma de software útil para la construcción de aplicaciones y sitios web. Los portales web permiten, el uso de comunidades, diferentes páginas para usuarios anónimos, autenticados y elementos de colaboración social (Liferay, 2011). 47

49 Liferay es un gestor de portales Java Open Source, el cual permite realizar portales totalmente configurables, con una perfecta gestión de roles, usuarios, comunidades, etc., donde la necesidad de comunicación e integración de servicios es fundamental pues además de proporcionar una solución óptima a estos problemas, permite la perfecta incorporación de los servicios Web 2.0. Liferay soporta múltiples tecnologías, redes sociales, acceso desde dispositivos móviles y es compatible con la mayoría de servidores de aplicaciones y de base de datos en la actualidad (Shum, 2011). Liferay por ser un portal web requiere del uso de componentes llamados Portlets, estos de describen como mini aplicaciones que siguen los estándares JSR 168 y 286 (JCP, 2011). Por esta razón los portlets desarrollados para otras plataformas son adaptables a Liferay, mientras que los hooks son una forma de modificar comportamientos del portal sin necesidad de recompilar el portal completo, útil para la modificación de componentes que vienen por defecto y que son útiles utilizar pero con nuevas funcionalidades. Por su parte, los temas son quienes deciden los colores, menús y formato de la página, dando todo el aspecto visual que debe tener. Estas tres herramientas son la ficha clave del desarrollo de la Plataforma Urb@naLab, ya que permiten la creación de nuevos componentes y la reutilización de servicios que vienen por defecto, permitiendo así crear un portal totalmente configurable y adaptable según sean las necesidades y requerimientos. 3. Estándar para el uso de Portales Web Definido Java como lenguaje de programación nativo del portal y útil para el desarrollo de pequeños componentes o módulos para la Plataforma Urb@naLab, un reto para los desarrolladores del Grupo de Investigación COMBA I+D fue Cómo desarrollar nuevos componentes de forma transparente e interoperables con el portal?. Sun MicroSystem ahora propiedad de Oracle define dos estándares para el desarrollo de componentes para un portal (Portlets) el JSR 168 y JSR 268. a) JSR 168 Define la comunicación entre Portlets y un contenedor de Portlets definidos por un conjunto de APIs de Java. Gracias a este estándar los desarrolladores pueden intercambiar componentes web y ser 48

50 desplegados en cualquier portal web que cumpla con los estándares. Los Portlets pueden ser mostrados por el contenedor de Portlets, sin modificar el código fuente (JCP, 2011), además define diferentes mecanismos para que el Portlet acceda a datos transitorios y persistentes, útil para el paso de información desde otros Portlets construidos por los diferentes desarrolladores del grupo. El Portlet puede colocar y obtener datos transitorios en los siguientes escenarios: Request: la petición tiene datos incluidos, como los parámetros y atributos de la petición, similar a la petición del servlet. La petición puede contener propiedades para permitir que la extensión y los encabezados del cliente sean transportados del portal al Portlet y recíprocamente. Session: el Portlet puede guardar datos en la sesión con alcance global, para dejar que otros componentes de la aplicación web tengan acceso a los datos, o en el alcance del Portlet, el cual es de acceso restringido al Portlet. Context: el Portlet puede guardar datos en el contexto de la aplicación web, así como lo hacen los servlets (Montañez, 2011). b) JSR 286 Es la especificación versión 2 de Portlets definiendo el contrato entre los contenedores de Portlets y los Portlets. Se trata de una evolución de JSR 168. El JSR 286 permite que los Portlets puedan compartir datos relacionados con el periodo de sesiones. El JSR 286 introduce el modelo de eventos tales como: Un Portlet puede declarar eventos que quiere emitir y que desea recibir. El contenedor de Portlet actuará como intermediario y distribuirá los eventos en consecuencia. Permite la conexión de Portlets en tiempo de ejecución. Una de las mejoras importantes referente al estándar JSR 168 es la comunicación entre Portlets a través de Eventos y parámetros públicos: Uno de los problemas que tenía la versión anterior era que la comunicación entre Portlets era muy rudimentaria. Ahora ya es posible pasar parámetros de un Portlet a otro sin necesidad de utilizar la sesión. (Montañez, 2011; Weiss, 2011), solución que permite a los desarrolladores compartir la información mucho más fácil, cuando se requiere que dos módulos hablen entre sí. 49

51 4. Directorio Activo LDAP (OpenDS) OpenDS es una implementación del servidor LDAP de código abierto desarrollado por Sun MicroSystem y adquirida por Oracle. Un servidor LDAP ofrece un servicio de directorio en red. Este tipo de servicio es de interés para usos como una guía de contactos, guía telefónica, directorio de correo electrónico, servidor de DNS o autenticación de usuarios. Las características que destacan en un servidor LDAP son: la alta velocidad en lectura de datos y la baja velocidad en escritura y modificación. Estas características hacen que este tipo de servidor sea interesante para almacenar información relativamente estática, pero de muchas lecturas. El protocolo que utiliza el servidor LDAP está orientado a trabajar en red y presenta características de entorno distribuido, que facilita la replicación de la información a múltiples servidores Liferay (Liferay, 2011) al mismo tiempo, es decir, que se pueden actualizar los datos en diversos servidores LDAP al mismo tiempo. LDAP se organiza por medio de una estructura jerárquica orientada a representar y contener objetos y elementos. LDAP no es más que una base de datos, pero su protocolo orientado a funciones de directorio en red y su optimización para lectura unido a la estructura jerárquica, hacen de este sistema uno de los más instalados para la gestión de usuarios y agendas de contactos, a la vez que, la convierte en poco eficiente para almacenar otros tipos de datos. Esta estructura jerárquica aumenta notablemente los tiempos de escritura, pero facilita la lectura. Por ese motivo, los datos que se guardan en este tipo de servidor son información que se consulta un gran número de veces, pero se escribe poco. LDAP incorpora un mecanismo de autenticación para el cliente que quiere acceder a la información contenida en el servidor LDAP. De esta forma se limita el acceso a los datos que contiene. Un directorio LDAP se compone de un árbol ordenado de entradas pudiendo representar algunas dependencias entre ellos a nivel conceptual. Las entradas del árbol constan de un nombre que los identifica de forma única y una serie de atributos. Los atributos están formados por un nombre que ejerce de llave y uno o varios valores para ese atributo. 5. Framework de Desarrollo Como se ha mencionado en los apartados anteriores, para el desarrollo de la Plataforma Urb@naLab, se han utilizado las 50

52 tecnologías de los portales web, el uso de estándares, patrones y arquitecturas de software. Combinando todas estas tecnologías se pueden desarrollar componentes, pero sería es muy tedioso comenzar un desarrollo implementado arquitecturas y patrones desde cero, por eso es importante el uso de framework que puedan facilitar el uso de estas implementaciones. a) Spring Framework Spring Framework es un marco de aplicaciones Java que facilita enormemente la implementación de distintos patrones de diseño y la integración con una gran cantidad de tecnologías. Este framework ha venido a revolucionar la manera de programar aplicaciones Java debido a la facilidad de crear componentes reutilizables [9]. Spring está basado en la técnica de inversión de control (loc) promoviendo el bajo acoplamiento a partir de la inyección de dependencias. IoC se conoce como el Principio de Inversión de Dependencia, Inversión of Control" (IoC) o patrón Hollywood ("No nos llames, nosotros le llamaremos"), es decir se reduce la instanciación y creación de nuevos objetos. Spring Framework es bastante grande y por ello está divido en varios módulos, por lo que no es obligación usarlos todos a la vez. Spring en su marco de trabajo ofrece varias arquitecturas, incluyendo las mencionadas en el apartado B de este capítulo. Figura 13. Arquitectura del Framework Spring (Spring Documentation Framework, 2011) 51

53 b) Spring PortletMVC Spring Portlet MVC hace parte del módulo Web MVC del gran Framework Spring y permite el desarrollo de Portlets con el estándar JSR-168 y JSR-286. Este módulo está basado en la arquitectura (modelo vista controladora) (Spring Framework, 2011). El modulo está diseñado en torno a un DispatcherPortlet que envía peticiones a los controladores, con asignaciones de controlador configurable y generación de las vistas, al igual que lo hace el DispatcherServlet en el marco web. (Weiss, 2011). Arquitectura Portlet MVC La Figura 14 muestra la arquitectura del módulo Portlet MVC donde (ATI, 2011): El cliente hace un llamado mediante una solicitud a la página. El motor del Portal web invoca el Portlet Dispatcher. El Portlet Dispatcher envía las solicitudes a los controladores de ActionRequest y RenderRequest. El controlador RenderRequest devuelve el Modelo y la Vista. El Portlet Dispatcher resuelve y hace la vista. E Portal web agrega el contenido de Portlet y devuelve la respuesta al cliente. Figura 14. Arquitectura Framework Portlet MVC (ATI, 2011) 52

54 D. Desarrollo de los Módulos de la Plataforma 1. Interfaz de Interacción a) Modulo Controlador Presenta la interfaz de Interacción del Usuario con la Plataforma, dándole a conocer a los usuarios una descripción del proyecto y del portal de la plataforma. Figura 15. Módulo de Autenticación con la Plataforma y Facebook 2. Registro y Autenticación a) Módulo de Autenticación de Usuario Permite verificar que el usuario exista en la plataforma, para acceder a su perfil e interactuar con la aplicación. También puede autenticarse utilizando su cuenta de Facebook. 53

55 Figura 16. Módulo de Autenticación con la Plataforma y Facebook El módulo de autenticación, permite a los usuarios que realizaron su registro de forma básica, poder fusionar su cuenta con los datos del Facebook, de manera que puede hacerse antes de registrarse en la plataforma o después. Figura 17. Módulo de autenticación con Facebook b) Módulo de Registro Permite a los visitantes, registrarse en la plataforma, ingresando los datos básicos: nombre, apellidos, alias, correo electrónico entre otros. 54

56 Figura 18. Módulo de Registro 3. Caracterización del Usuario a) Módulo de Perfil Permite a los usuarios registrados, poder caracterizarse dentro de la plataforma con datos personales adicionales y seleccionar una variedad de gustos e intereses que ofrece Urb@naLab. Figura 19. Perfil Creado 55

57 4. Espacio de Interacción Urbana Espacios Colaborativos a) Componentes de Interacción y Gestión de la Comunidad Figura 20. Interacción y Comunidad 5. Cocreación a) Módulo Registro y Publicación de Servicios (Prototipado y Validación) Permite a los usuarios registrados con el rol de administrador o proveedor, crear servicios para ser compartidas con todos los usuarios de la comunidad, que a su vez podrán calificarlas y comentarlas. Al momento de crear un servicio se carga un logo y sus datos básicos: nombre, descripción, etiquetas entre otras. Figura 21. Creación de Servicios: Cargar Imagen o Logo 56

58 Figura 22. Creación de Servicios: Datos Básicos Figura 23. Creación de Servicios, Panel de Servicios Registrados Figura 24. Creación de Servicios, Visor de Servicios 57

59 b) Módulo Contenedor de Servicios (Prototipado y Validación) Figura 25. Módulo Contendor de Servicios Vista Principal 58

60 Figura 26. Filtros de Contenido del Contenedor. Figura 27. Detalle del Servicio. 59

61 Figura 28. Módulo de Evaluación del Servicio. Figura 29. Módulo Contenedor de Prototipos y los Diferentes Sectores Ofrecidos en la Plataforma. 60

62 c) Módulo de Creación de Ideas El Componente de Creación de Ideas es integrado a la Plataforma Urb@naLab y permite a los usuarios registrados con el rol de administrador o proveedor, crear ideas para ser compartidas con todos los usuarios de la comunidad, que a su vez podrán calificarlas y comentarlas. Al momento de crear una idea se carga un logo y sus datos básicos: nombre, descripción, etiquetas entre otras. Figura 30. Creación de Ideas: Cargar Imagen o Logo Figura 31. Creación de Ideas: Categorización 61

63 Figura 32. Creación de Ideas: Panel de Ideas Registradas Figura 33. Creación de Ideas: Visor de Ideas E. Conclusiones El desarrollo de una plataforma de Computación Urbana, supone varios retos importantes, y se debe ser cuidadoso para escoger tecnologías que permitan desarrollar una plataforma flexible y adaptable, que sea capaz de soportar la interacción de los individuos, así como crear espacios de colaboración y cocreación de servicios, propiciando la innovación y la integración de los diferentes actores involucrados en una ciudad. 62

64 La Plataforma hace uso de la metodología de Living Labs, permitiendo la creación y especificación de ideas, el prototipado, el desarrollo de pilotos y el despliegue de servicios orientados a los ciudadanos en diferentes sectores de aplicación. La Plataforma es desarrollada de forma modular, lo que permite armar de forma flexible toda la fase de desarrollo de un servicio. Así mismo involucra un componente de interacción social que le permite al ciudadano establecer relaciones con los demás individuos de la comunidad. Urb@naLab permite identificar los gustos y preferencias de los ciudadanos, induciendo de manera directa a la participación activa de los ciudadanos en los canales de innovación tecnológica, permitiendo el desarrollo e integración de servicios en diferentes campos de acción dentro de un contexto urbano. F. Referencias Almirall, E. (2008) Living Labs and Open Innovation. Open Innovation and Renewal. CKIR Workshop 2008, Helsinki. ATI. (2011) Portlets, Sitio web [En Línea] Disponible desde Gregorio, J. (2004) How to create a REST Protocol. XML.com website. JCP. (2011) Community Development of Java Technology Specifications, sitio web [En Línea] Disponible desde Liferay. (2011) What is a portal?, sitio web [En Línea] Disponible desde: Montañez, S. (2011) Modelo de Portal para el acceso a una Grid de Geosensores, Documento [En Línea] Disponible desde Oracle. (2011) Core J2EE Patterns - Data Access Object, Sitio web [En Linea] Disponible desde: Shum, J. (2011) Liferay Portal Overview, documento [En Línea] Disponible desde: Sauter, P. (2005) A Model View Controller extension for pervasive multi-client user interfaces. ACM Spring Framework. (2011) Sitio Web [En Línea] Disponible desde: Spring Documentation Framework. (2011) Sitio web [En Línea] Disponible desde Weiss, M. (2011) Portlet Estándar JSR 168/JSR 286, Documento [En Línea] Disponible desde Zúñiga, C. et al. (2011) Software platform for services in Colombian cities using the Living Labs approach. IEEE GLOBECOM Workshops (GC Wkshps) 2011, December 2011, pp.1258,

65 Capítulo 3 Acceso Móvil a la Plataforma Urb@naLab Alexander García Dávalos. 10 Leonardo Saavedra Munar. 11 Juan David Trejos Polania. 12 Abstract. El continuo crecimiento de usuarios de telefonía móvil es cada vez mayor, ya sea en dispositivos o en los servicios que éstos ofrecen y que combinan hardware, software y redes. Los dispositivos móviles se han convertido en una herramienta esencial en cualquier aspecto (social, profesional, personal, etc.). Con base en lo anterior, la plataforma Urb@naLab incluye una versión especial para dispositivos móviles que les permite a los usuarios, dentro de entornos inalámbricos, evaluar innovadoras ideas y prototipos de servicios. En este capítulo se presenta el desarrollo de las aplicaciones de software implementadas para permitir el acceso móvil a la plataforma Urb@naLab A. Introducción Gracias a los avances de la microelectrónica, la nanotecnología, las redes inalámbricas (WWAN/WLAN/WPAN) y el software, los teléfonos móviles se han convertido en una herramienta muy versátil y 10 Director del Grupo de Investigación en Telemática e Informática Aplicada (GITI), Facultad de Ingeniería, Universidad Autónoma de Occidente. agdavalos@uao.edu.co 11 Grupo de Investigación en Telemática e Informática Aplicada (GITI), Facultad de Ingeniería, Universidad Autónoma de Occidente, lsaavedra@uao.edu.co 12 Grupo de Investigación en Telemática e Informática Aplicada (GITI), Facultad de Ingeniería, Universidad Autónoma de Occidente, juan_david.trejos@uao.edu.co 64

66 poderosa para los usuarios móviles. Actualmente, los teléfonos móviles están dotados de cámaras digitales, múltiples interfaces de red (soporte 3G, Wi-Fi, GPS y Bluetooth) y reproductores de diversos formatos de audio, video e imagen (p.ej. MPEG-4, H.264, MP3, AAC, AMR, JPG, PNG, GIF). Es decir, con la evolución tecnológica los teléfonos móviles pasaron de ser simples dispositivos, que sólo sirven para realizar y recibir llamadas, a ser dispositivos dotados de una variedad de aplicaciones y servicios, que se soportan en plataformas operativas desarrolladas especialmente para ellos. Con el paso del tiempo y la llegada de nuevos interesados en sumarse al auge que vivían las aplicaciones móviles, como es el caso de Sun Microsystems, que introdujo una versión de la máquina virtual de Java para dispositivos móviles llamada Java Micro Edition (Sun Developer Network, 2006), se logró expandir la comunidad de desarrolladores móviles. Sin embargo, las aplicaciones Java para dispositivos móviles o MIDlets, no tenían acceso de bajo nivel al hardware, por lo cual no aprovechaban todo el potencial de los dispositivos en los que se ejecutaban (Meier, 2009). En medio de este escenario, se introdujeron nuevas plataformas operativas para dispositivos móviles, entre las que se encuentra Android, una plataforma desarrollada por Google como parte de su estrategia para introducirse en el mercado de las aplicaciones y servicios móviles (Meier, 2009; Ryan, 2009). El lanzamiento oficial de la plataforma fue en Noviembre de 2007, y desde entonces se han publicado varias versiones. En esta nueva era de los dispositivos móviles, el interés por el desarrollo Web móvil es cada vez mayor. Actualmente, es común que los desarrolladores utilicen técnicas basadas en el Responsive Web Design (Marcotte, 2011) o Diseño Web Adaptable, para crear aplicaciones Web capaces de adaptar su contenido y diseño en función del dispositivo móvil en el que se estén utilizando. Por otro lado, existen frameworks JavaScripts, como XUI, JQPad y JQuery Mobile, orientados exclusivamente al desarrollo de aplicaciones Web para móviles. Es así, como el uso masivo de las redes inalámbricas y la alta tasa de penetración de los dispositivos y aplicaciones móviles, ha planteado nuevos retos y desafíos para los desarrolladores. Uno de los problemas de investigación más estudiados en la actualidad en el 65

67 campo de las redes de datos inalámbricas, es el Handoff Vertical (VH, por sus siglas en inglés). Diversos algoritmos de handoff vertical (VHA) han sido propuestos en la literatura especializada. La mayoría de estos algoritmos han sido probados en entornos simulados usando diferentes herramientas software de simulación (p.ej. NS-2, OMNeT++ y NCTUns), pero sólo unos pocos han sido probados en un entorno real. Uno de los objetivos más importantes de la plataforma Urb@naLab, es que sus contenidos sean accesibles por la mayor cantidad de usuarios posibles mediante el uso de dispositivos móviles, como por ejemplo smartphones y tablets. Para lograr dicho objetivo, se propuso el desarrollo de dos aplicaciones de software, a saber: un componente o plugin, llamado Cliente Universal, que permite la re-selección de redes inalámbricas WiFi/redes celulares disponibles en el área en la que se encuentra un dispositivo móvil en un momento determinado; y una aplicación Web, llamada Cliente Móvil, que permite el acceso a la plataforma a través de dispositivos móviles. Este capítulo está organizado de la siguiente manera. En la sección 2.2 se presenta el modelo propuesto para el acceso a la plataforma Urb@naLab. En la sección 2.3 se presenta la implementación del Cliente Universal y sus respectivas pruebas de funcionamiento. En la sección 2.4 se presenta el desarrollo y la implementación del Cliente Móvil, y las pruebas concepto del sistema móvil en general. Finalmente, las conclusiones son dadas en la sección B. Modelo de Acceso a la Plataforma Gracias a los avances de la microelectrónica, la nanotecnología, las redes inalámbricas (WWAN/WLAN/WPAN) y el software, los teléfonos móviles se han convertido en una herramienta muy versátil y poderosa para los usuarios móviles. Actualmente, los teléfonos móviles están dotados de cámaras digitales, múltiples interfaces de red (soporte 3G, Wi-Fi, GPS y Bluetooth) y reproductores de diversos formatos de audio, video e imagen (p.ej. MPEG-4, H.264, MP3, AAC, AMR, JPG, PNG, GIF). Es decir, con la evolución tecnológica los teléfonos móviles pasaron de ser simples dispositivos, que sólo sirven para realizar y recibir llamadas, a ser dispositivos dotados de una variedad de aplicaciones y servicios, que se soportan en plataformas operativas desarrolladas especialmente para ellos. Con el paso del tiempo y la llegada de nuevos interesados en 66

68 sumarse al auge que vivían las aplicaciones móviles, como es el caso de Sun Microsystems, que introdujo una versión de la máquina virtual de Java para dispositivos móviles llamada Java Micro Edition (Sun Developer Network, 2006), se logró expandir la comunidad de desarrolladores móviles. Sin embargo, las aplicaciones Java para dispositivos móviles o MIDlets, no tenían acceso de bajo nivel al hardware, por lo cual no aprovechaban todo el potencial de los dispositivos en los que se ejecutaban (Meier, 2009). En medio de este escenario, se introdujeron nuevas plataformas operativas para dispositivos móviles, entre las que se encuentra Android, una plataforma desarrollada por Google como parte de su estrategia para introducirse en el mercado de las aplicaciones y servicios móviles (Meier, 2009; Ryan, 2009). El lanzamiento oficial de la plataforma fue en Noviembre de 2007, y desde entonces se han publicado varias versiones. En esta nueva era de los dispositivos móviles, el interés por el desarrollo Web móvil es cada vez mayor. Actualmente, es común que los desarrolladores utilicen técnicas basadas en el Responsive Web Design (Marcotte, 2011) o Diseño Web Adaptable, para crear aplicaciones Web capaces de adaptar su contenido y diseño en función del dispositivo móvil en el que se estén utilizando. Por otro lado, existen frameworks JavaScripts, como XUI, JQPad y JQuery Mobile, orientados exclusivamente al desarrollo de aplicaciones Web para móviles. Es así, como el uso masivo de las redes inalámbricas y la alta tasa de penetración de los dispositivos y aplicaciones móviles, ha planteado nuevos retos y desafíos para los desarrolladores. Uno de los problemas de investigación más estudiados en la actualidad en el campo de las redes de datos inalámbricas, es el Handoff Vertical (VH, por sus siglas en inglés). Diversos algoritmos de handoff vertical (VHA) han sido propuestos en la literatura especializada. La mayoría de estos algoritmos han sido probados en entornos simulados usando diferentes herramientas software de simulación (p.ej. NS-2, OMNeT++ y NCTUns), pero sólo unos pocos han sido probados en un entorno real. Uno de los objetivos más importantes de la plataforma Urb@naLab, es que sus contenidos sean accesibles por la mayor cantidad de usuarios posibles mediante el uso de dispositivos móviles, como por ejemplo smartphones y tablets. Para lograr dicho objetivo, se propuso 67

69 el desarrollo de dos aplicaciones de software, a saber: un componente o plugin, llamado Cliente Universal, que permite la re-selección de redes inalámbricas WiFi/redes celulares disponibles en el área en la que se encuentra un dispositivo móvil en un momento determinado; y una aplicación Web, llamada Cliente Móvil, que permite el acceso a la plataforma a través de dispositivos móviles. Figura 1. Modelo de acceso a Urb@naLab Este capítulo está organizado de la siguiente manera. En la sección 2.2 se presenta el modelo propuesto para el acceso a la plataforma Urb@naLab. En la sección 2.3 se presenta la implementación del Cliente Universal y sus respectivas pruebas de funcionamiento. En la sección 2.4 se presenta el desarrollo y la implementación del Cliente Móvil, y las pruebas concepto del sistema móvil en general. Finalmente, las conclusiones son dadas en la sección 2.5. Cuando el acceso a la plataforma se hace a través de un dispositivo móvil, como por ejemplo un smartphone, intervienen dos aplicaciones de software: el Cliente Universal, que debe instalarse en el dispositivo móvil (componente de software), para proveer conectividad Wi-Fi o 3G al usuario; y el Cliente Móvil, responsable de visualizar y gestionar la adaptación de la plataforma Urb@naLab para dispositivos móviles. 2. Cliente Universal En esta sección se presenta la estructura y funcionamiento de un componente de software, llamado Cliente Universal, que permite re- 68

70 seleccionar las redes inalámbricas WiFi/redes celulares, que están disponibles en el ambiente en el cual se encuentra el dispositivo móvil en un momento determinado. Este componente consistente en un algoritmo de handoff o traspaso vertical (Vertical Handoff) controlado desde un teléfono móvil, fue implementado bajo la plataforma Android y probado en un ambiente real con disponibilidad de conexión a redes inalámbricas de tecnología Wi-Fi y 3G. c) Plataforma Android Android es una plataforma de software para dispositivos móviles que incluye un sistema operativo, un Middleware y un conjunto de aplicaciones (Android Developers, 2012). Android incluye un Kit de Desarrollo de Software o SDK (Software Development Kit) y otros elementos que lo hace atractivo para los desarrolladores de software de dispositivos móviles, quienes pueden crear aplicaciones sofisticadas (p.ej. aplicaciones 3D, basadas en mapas y geolocalización, de realidad aumentada, entre otras) escritas en lenguaje C u otros lenguajes, y compilarlas a código nativo de ARM (API de Android). La Figura 2 muestra una visión general de la arquitectura de Android. Los componentes principales de la plataforma son descritos a continuación (Android Developers, 2012). 69

71 Figura 2. Arquitectura general de Android. Fuente: Adaptación de Android Developers, What is Android? Aplicaciones: Las aplicaciones base incluyen un cliente de correo electrónico, programa de SMS, calendario, mapas, navegador, contactos y otros servicios mínimos. Todas las aplicaciones están escritas en lenguaje Java. Framework de aplicaciones: Los desarrolladores tienen acceso completo a las mismas APIs usadas por las aplicaciones base. La arquitectura de Android está diseñada para simplificar la reutilización de componentes, de tal manera que cualquier aplicación puede publicar sus capacidades, y cualquier otra puede hacer uso de estas (sujeto a las reglas de seguridad del framework). Este mismo mecanismo permite que los componentes puedan ser reemplazados por el usuario. 70

72 Librerías: Android incluye un conjunto de librerías, escritas en lenguaje C/C++, que son usadas por varios componentes de la plataforma. Estas librerías se exponen a los desarrolladores a través del framework de aplicaciones de Android. Algunas de estas librerías son: la librería estándar del lenguaje C (libc), SSL (seguridad en Internet), OpenGL (gráficos 2D y 3D), SQLite (bases de datos relacionales), FreeType (mapa de bits y vectores de la renderización de fuentes), reproducción de medios (video y sonido), WebKit (motor de renderización de contenidos web), entre otros. Entorno de ejecución (Runtime): Se compone de un conjunto de librerías (algunas librerías del núcleo de Java y de la máquina virtual Dalvik) que proveen funcionalidades básicas y la máquina virtual, denominada Dalvik, para la ejecución de las aplicaciones. A cada aplicación que se lanza a ejecución, se le crea su propio proceso en una instancia propia de la máquina virtual Dalvik, que es en realidad una máquina virtual Java, pero optimizada en cuanto al consumo de memoria. Kernel de Linux: Android depende de Linux para los servicios típicos de un sistema operativo, a saber, la seguridad, la gestión de memoria y procesos, la gestión de energía y controladores (drivers) para la interacción con el hardware del dispositivo móvil. El kernel o núcleo (versión 2.6) es el componente que sirve como una capa de abstracción entre el hardware y las capas de software de la plataforma. Todas las aplicaciones bajo Android tienen las mismas condiciones, y tanto las aplicaciones de terceros como las nativas, se construyen usando las mismas APIs y son ejecutadas en el mismo entorno de ejecución, tal y como se muestra en la Figura 1. Pero por seguridad, cada aplicación se ejecuta en su propio espacio, aunque pueden comunicarse con otras aplicaciones y acceder a datos almacenados en el dispositivo (p.ej. la agenda de contactos, el registro de llamadas, etc.). Android está respaldado por la OMA (Open Handset Alliance), que es un consorcio compuesto por más de 40 compañías del mundo de las tecnologías para dispositivos móviles lideradas por Google y entre 71

73 las que se destacan HTC, Motorola, Intel, Qualcomm, Vodafone, Acer y Samsung. El objetivo principal de este consorcio (Open Mobile Alliance, 2012) es la promoción de estándares abiertos para dispositivo móviles, de ahí la importancia que representa para el futuro de Android, ya que únicamente el apoyo de Google no será suficiente para su éxito en el competido mundo de las plataformas para dispositivos móviles. Adicionalmente, en la Tabla 1 se una presenta breve descripción de los paquetes de Android más importantes para el acceso a la información de redes inalámbricas (Android Developers, 2012; Komatineni, MacLean & Hashimi, 2011), los cuales están incluidos en el SDK de Android. Tabla 1. APIs para acceder a la información de redes inalámbricas. Nombre del paquete Descripción Android.location Contiene las clases que definen los servicios de Android basados en la localización y otros afines. Estas clases son: Address, Criteria, Geocoder, GpsSatellite, GpsStatus, Location, LocationManager, y LocationProvider. Android.net Permite el acceso a la red, a nivel básico, a través de sockets (API de red). Las clases primarias son: Uri, ConnectivityManager, LocalSocket, y LocalServerSocket. Android.net.http Contiene las clases para la manipulación de los certificados SSL (Secure Sockets Layer). Algunas de estas son: AndroidHttpClient, HttpResponseCache, packagesummary, y SslCertificate. Android.net.wifi Administra la conectividad Wi-Fi. Las clases primarias incluyen a WifiManager y WifiConfiguration. La clase WifiManager es responsable de mostrar las redes configuradas y la actual red Wi-Fi activa. Android.telephony Contiene las clases que permiten identificar la información básica de teléfono (p.ej. ubicación, número, nombre del operador de red, tipo de teléfono y de red, etc.). Las clases principales son: CellLocation, PhoneNumberUtils, y TelephonyManager. Android.telephony.gsm Contiene las clases que permiten utilizar las características básicas de la telefonía GSM, como por ejemplo, los datos y mensajes SMS en formato PDU (Protocol Description Unit). Estas clases son: GsmCellLocation, SmsManager, SmsMessage, y SmsMessage.SubmitPdu. Android, es actualmente una de las plataformas operativas para teléfonos móviles más usadas junto con iphone (Apple), Windows Mobile (Microsoft), BlackBerry (RIM) y Symbian (Nokia). Estas plataformas se caracterizan por proveer entornos de desarrollo sofisticados, que simplifican la creación de aplicaciones móviles y permiten explotar los aditamentos y servicios de los dispositivos móviles actuales (cámaras, GPS, giroscopio, SMS, redes sociales, etc.). Sin embargo, algunos autores (Oliver, 2008; Woodbridge et al., 2009) afirman que esta heterogeneidad de plataformas operativas genera a 72

74 los desarrolladores de aplicaciones un incremento en los costos de producción y frena la evolución tecnológica del software para teléfonos móviles. De igual manera, manifiestan la necesidad de una API común que integre la conectividad de red, la gestión del consumo de energía y la experiencia del usuario. A diferencia de otras plataformas propietarias, Android fue concebido bajo la idea del Software Libre y la premisa de que las aplicaciones de terceros deben tener las mismas posibilidades que las aplicaciones nativas, entre ellas, el acceder al hardware de los dispositivos usando las mismas APIs que usan las aplicaciones nativas. Sin embargo, cabe mencionar que por seguridad, el acceso a las APIs más sensibles (p.ej. conexión a la red inalámbrica) está controlado a través de permisos. Es así, como el desarrollador deberá especificar en el archivo manifiesto i de la aplicación, que está accederá a una API específica, por ejemplo, la API que permite el acceso a redes inalámbricas Wi-Fi (Enck, Ongtang & McDaniel, 2009). d) Handoff Vertical en Dispositivos Móviles El hecho de que los usuarios móviles puedan desplazarse en zonas cubiertas por redes de acceso inalámbrico de diferente tipo, alcance, tecnología y capacidad, genera la necesidad de que el dispositivo o terminal móvil pueda realizar cambios de canal entre las distintas redes de forma casi imperceptible para el usuario, aun si se efectúa en medio de una sesión que cursa tráfico. La selección de una nueva conexión para el terminal móvil es una decisión que debe ser enfrentada permanentemente por el sistema y que tiene efectos positivos o negativos para el servicio y para la red misma, lo cual depende del acierto con que sea tomada (Ríos López, C.A., 2009). El problema del Handoff Vertical (VH) ha sido estudiado de manera amplia. En este sentido, se han propuesto diversas soluciones (Nasser, Hasswa & Hassanein, 2006; Kassar, Kervella & Pujolle, 2008; Yan, Sekercioglu & Narayanan, 2010; Márquez-Barja et al., 2011) conocidas como mecanismos de traspaso o Handoff Vertical (en literatura europea es común el término Handover), cuyo elemento central son los algoritmos que se encargan de realizar los pasos necesarios para que el terminal móvil pueda cambiar de conexión entre redes inalámbricas de diferente tecnología, las más comunes son WLAN, GSM, Bluetooth y WiMAX. Sin embargo, la mayoría de estas soluciones son netamente teóricas, y sólo unas pocas han sido implementadas y probadas en ambientes de prueba reales (García & 73

75 Jiménez, 2008). La Figura 3 muestra un ejemplo sencillo de un Handoff Horizontal y Vertical. En a) el Handoff Horizontal se encuentra representado por dos puntos de acceso (Access Point, AP) conectados a un mismo router, formando un dominio de red. Un AP da cobertura a toda una zona, a la que se le conoce como conjunto de servicios básicos (Basic Service Set, BSS). En este caso, un terminal móvil (Mobile Host, MH) cambia su conexión de un AP a otro, donde ambos tienen la misma tecnología de red (p.ej. AP basados en redes IEEE ); para esto sólo necesita de una interfaz de red. Figura 3. Handoff Horizontal y Vertical Por otra parte, en b), se muestra el proceso de Handoff Vertical que se produce por el cambio de conexión de un terminal móvil entre dos AP de diferentes tecnologías de red (p.ej. un AP de una red IEEE y una estación base - BS, de una red móvil celular 3G); para lo cual se requiere de una interfaz de red por cada tecnología de red que necesite utilizar. En el proceso de Handoff Vertical, se identifican tres fases fundamentales (Kassar, Kervella & Pujolle, 2008): 1) Fase de descubrimiento: En esta fase se monitorea y determina que redes están disponibles en el entorno y sus características (o parámetros) estáticas y dinámicas. Algunos ejemplos de métodos utilizados para la identificación de estos parámetros son la predicción de micro-movilidad y la probabilidad de salir de una microcelda. 74

76 2) Fase de selección de red: En esta fase se evalúa la conveniencia de realizar un cambio de red, y se escoge la nueva. Existen métodos y técnicas para realizar la selección de la red candidata: cadenas de Markov, el uso de redes neuronales, lógica difusa, función de costo, procesos analíticos jerárquicos (AHP, por sus siglas en inglés, Analytic Hierarchy Process) y toma de decisiones multi-atributo (MADM, por sus siglas en inglés, Multiple Attribute Decisión Making). 3) Ejecución del traspaso: En esta fase se realiza el cambio de red, es decir, la conexión se conmuta de la red actual a la red seleccionada. El objetivo de esta fase es minimizar el tiempo de latencia y la pérdida de paquetes. Cada red define la mecánica para realizar la decisión del handoff entre los elementos del sistema. Según la distribución de los roles en la realización del handoff se plantea la siguiente clasificación (Marichamy, Chakrabati & Maskara, 1999; Tarkoma & Lagerspetz, 2011): Handoff Controlado por la Red (Network Controlled Handoff, NCHO): La red se encarga de las mediciones y de la decisión misma. Handoff Asistido por el Móvil (Mobile Assisted Handoff, MAHO): El móvil realiza las mediciones periódicas (p.ej. intensidad de la señal), pero la red es responsable de la decisión. Handoff Controlado por el Móvil (Mobile Controlled Handoff, MCHO): El móvil controla todo el proceso, es decir, obtiene las mediciones de la red, del móvil mismo y realiza la decisión. Aunque las soluciones de VH controladas por el móvil son más flexibles y reducen la complejidad de la red (Tarkoma & Lagerspetz, 2011), éstas requieren que los parámetros de red sean accesibles para el software del terminal móvil que se encarga del proceso de traspaso. Así mismo, este tipo de Handoff Vertical permite no solamente analizar los parámetros de red para tomar la decisión de traspaso, sino también, que el algoritmo de handoff vertical (VHA), que se ejecuta en el terminal móvil, pueda considerar las preferencias del usuario móvil. Para este tipo de soluciones, es importante que la plataforma operativa del dispositivo permita el acceso a las APIs nativas, a través 75

77 de las cuales se puede obtener la información necesaria para determinar la necesidad del traspaso. Esto, con el fin de no tener que desarrollar APIs adicionales o adquirir soluciones propietarias. En este sentido, Android es una plataforma operativa que permite el acceso al hardware a través de sus APIs, por lo tanto, se convierte en una buena opción para implementar soluciones de VH controladas por el móvil. e) Estructura y Funcionamiento del Cliente Universal En trabajos previos de investigación (García & Jiménez, 2008) se propuso un VHA del tipo MCHO, que permite el traspaso entre redes inalámbricas heterogéneas para dispositivos móviles que cuenten con múltiples interfaces de red, considerando las preferencias de usuario y su nivel de movilidad. Este algoritmo fue implementado y probado bajo la plataforma Windows Mobile. Sin embargo, esta plataforma operativa presentó algunos inconvenientes para su desarrollo, principalmente en lo relacionado con el acceso al hardware durante la fase de descubrimiento del sistema. Con base en los resultados anteriores, se decidió adaptar el VHA propuesto para ser implementado bajo Android, una de las plataformas más usadas en los dispositivos móviles actualmente, debido a su gran acogida por parte de los fabricantes. (1) Descripción del Algoritmo El VHA usa una función de costo de escala relativa, propuesta por Márquez-Barja et al. (2011), para el proceso de selección de la interfaz de red. A esta función de costo se le adicionó un parámetro que considera el contexto de movilidad del usuario y se plantea de la siguiente manera: Para el caso de ambientes de media o alta movilidad, la función de costo se calculará así: f i W b 1 ln B i W p ln P i W c ln C i 1 ln V En el caso de ambientes de baja movilidad, la función de costo se calculará con la formulación inicial: 76

78 f i W b ln 1 B i W p ln P i W c ln C i Donde, Wb, es el peso asociado al parámetro ancho de banda. Wp, es el peso asociado al parámetro de consumo de la batería. Wc, es el peso asociado al parámetro del costo de conexión. B, ancho de banda. P, poder de consumo de la batería. C, costo económico de conexión a la red. V, velocidad de desplazamiento. La adición del parámetro de movilidad en la función de costo se hizo considerando la importancia que representa como elemento que afecta la calidad de servicio (QoS) de las redes inalámbricas, ya que éstas son dependientes del área de cobertura, la cual está condicionada por la movilidad del usuario (Márquez-Barja et al., 2011). Para evitar procesos de selección de red innecesarios o erróneos, se adicionaron dos elementos de estabilización (García & Jiménez, 2008), a saber: Dwell-Timer: La función de esta medida es establecer un tiempo de espera (cuenta regresiva) que permita, una vez cumplido el tiempo, nuevamente calcular el valor de costo para la red con opción de conexión y verificar si las condiciones de la red son estables para realizar el cambio de conexión. En este caso particular, el tiempo designado para extender la permanencia de la conexión a la red actual estará regido por el parámetro de la movilidad, y los valores a usar se presentan en la tabla 2. Los valores de los tiempos definidos son formulados considerando el área de cobertura de cada tecnología inalámbrica, y son estáticos y tentativos. 77

79 Tabla 2. Intervalos de tiempo del Dwell-Timer Movilidad Alta Media Baja DWT (segundos) Margen de Histéresis: Su función es adicionar un pequeño valor de holgura (valor de costo), que permita a la red en uso mejorar su valor de costo, y que en el proceso de selección, la red actual tenga cierta ventaja respecto a las redes con opción de selección. Para la definición de este mecanismo fue necesario tomar como referencia un parámetro asociado a las condiciones de la red, como es el caso de la potencia de la señal (RSS). En la Tabla 3 se presentan los valores definidos para el margen de histéresis de acuerdo con la potencia de la señal. Tabla 3. Margen de histéresis asignado en relación con la potencia de transmisión del AP Calidad de la Señal Excelente Muy Buena Buena Baja Histéresis Los pasos definidos en el VHA propuesto son los siguientes: Paso 1: Se obtiene la información sobre las redes inalámbricas disponibles, pesos de parámetros, contexto de movilidad (alta, media, baja). Paso 2: Se evalúan las redes disponibles considerando el tipo (WLAN o WWAN) y la movilidad asociada a cada tecnología inalámbrica, en la función de costo correspondiente. Paso 3: Se realiza la selección de la red inalámbrica a utilizar, considerando aquella cuyo valor de costo sea menor. Para esta selección se tienen en cuenta las siguientes consideraciones: Cuando se comparen las redes disponibles con la red actual (considerando el margen de histéresis), si el valor de costo de la nueva red es menor que el de la actual, se lanzará un temporizador o dwell-timer para verificar que las condiciones son estables para la red. Si durante este tiempo las condiciones no varían, se selecciona como mejor opción la nueva red, en caso contrario se deja la red actual. 78

80 (2) Prototipo de Software A continuación se da una breve descripción de cada componente principal del Cliente Universal (Céspedes et al., 2008): Agente/Sistema/Operativo: Es el encargado de todas las interacciones que requiere el sistema con los recursos de hardware, tales como solicitar los adaptadores de red, características de redes disponibles, realizar la conmutación de una red a otra, entre otras. Monitor: Debe detectar, periódicamente y en forma autónoma, todas las redes disponibles en todas las interfaces de red que estén activas en el dispositivo móvil, así como sus características de desempeño en el momento de la detección. Optimizador: Es el responsable de realizar la evaluación de las redes disponibles reportadas por el Monitor, compararlas y finalmente postular la que ofrezca mejores condiciones de servicio. Selector: Controla todo el traspaso general de traspaso de una red a otra, el cual empieza cuando el Monitor le notifica las redes disponibles que ha descubierto, y termina con la solicitud al Conmutador de que haga efectivo el cambio a la red propuesta por el Optimizador. Conmutador: Recibe del Selector la solicitud de conmutación a la red seleccionada, con lo cual inicia el proceso de establecer la comunicación hacia la nueva red, sin afectar la conexión a la red activa en ese momento. Autenticador: Administra las credenciales del usuario y las usa para validar su acceso ante el operador de la red a la cual necesite conectarse, de acuerdo a los parámetros de seguridad que se hayan establecido para la misma. CliUAdmin: Es el responsable de leer los parámetros de configuración del sistema, tales como el grado de movilidad y la plataforma operativa, crear y configurar las instancias de clases respectivas a la plataforma, lanzar el proceso autónomo del hilo del componente Monitor, y en general, realizar las tareas de gestión de los parámetros de configuración del sistema. 79

81 La configuración del Cliente Universal se realiza a través de una GUI (ver Figura 4), la cual permite al usuario seleccionar la importancia o prioridad (peso numérico) de los parámetros que son considerados para seleccionar la red candidata. Cada uno de los parámetros de configuración que se muestran en la Figura 4, representan una de las cuatro variables incluidas en (1), así pues, la Batería representa a la variable Wp, el Ancho de Banda a Wb, el Costo a Wc y la Movilidad a V. Figura 4. Interfaz de configuración de prioridades f) Pruebas de Funcionamiento Las pruebas de funcionamiento del Cliente Universal se llevaron a cabo en un escenario que dispone de redes WLAN con puntos de acceso inalámbricos ubicados en lugares estratégicos (bibliotecas, cafeterías, auditorios, etc.) de un campus universitario. Adicionalmente, se contó con el acceso a la red 3G de uno de los operadores celulares que ofrecen este servicio en Colombia. También, se utilizaron dos terminales móviles: un teléfono Sony Ericsson Xperia X10, y un teléfono HTC Google Nexus One, ambos con el sistema operativo Android v2.2. A través de las pruebas realizadas, en un ambiente real con redes inalámbricas heterogéneas, se verificaron las tres fases del proceso de VH (descubrimiento, evaluación y selección) y se constataron los siguientes criterios: 80

82 La red seleccionada se ajusta a los parámetros de configuración del usuario (preferencias). No ocurren procesos de handoff innecesarios. El traspaso se hace de forma trasparente para el usuario, sin perturbar la conexión del dispositivo móvil. La Tabla 4 muestra las configuraciones empleadas en las pruebas para los pesos asociados a los parámetros de red. Tabla4. Valores de los pesos asociados a los parámetros de configuración Escenario Ancho de Banda Batería Costo Movilidad Durante las pruebas el parámetro Movilidad tuvo que ser forzado, debido a que no se contaba con un escenario lo suficientemente amplio para permitir una movilidad óptima. Los valores para la movilidad se definieron de la siguiente manera: Movilidad Alta = 3; Movilidad Media = 2; y Movilidad Baja = 1. (1) Resultados Obtenidos Las Figuras 5 y 6 presentan los resultados obtenidos durante las pruebas para los Escenarios 1 y 2, y los Escenarios 3 y 4, respectivamente. En ellas, se consideraron cuatro casos específicos: Caso A: VHA con los todos elementos de estabilización (dwell-timer e histéresis). Caso B: Evaluación teniendo en cuenta sólo el dwell-timer. Caso C: Evaluación teniendo en cuenta sólo la histéresis. Caso D: No se consideran elementos de estabilización 81

83 Figura 5. Resultados de las pruebas para los Escenarios 3 y 4 Figura 6.Resultados de las pruebas para los Escenarios 1 y 2 Los resultados obtenidos en las pruebas de funcionamiento del Cliente Universal, permitieron concluir que: Selección de la interfaz de red: En el proceso de selección de red se obtuvieron resultados satisfactorios, considerando los pesos asociados a los parámetros de red. Esto se puede observar en las diferencias encontradas en las Figuras 5 y 6, ya que para los Escenarios 3 y 4, los pesos asociados al costo de la red y al ancho de banda son mayores en comparación a los asociados a estos mismos en los Escenarios 1 y 2, situación que permitió obtener el acceso a la red de datos del operador celular a través de la tarjeta de datos del dispositivo móvil (existe un costo asociado al acceso). 82

84 Handoffs innecesarios: El proceso de selección de una nueva interfaz de red fue ejecutado de forma satisfactoria, ya que el ambiente de inestabilidad presentado por las redes disponibles se manejó de manera efectiva usando los elementos de estabilización (dwell-timer e histéresis), lo cual contrarresta la posibilidad de traspasos innecesarios. La histéresis representa la medida de estabilización más crítica (ver Figura 5), debido a que su uso impide que se presente el efecto ping-pong (cambio constante de una red a otra) en la selección de la red. Este efecto se presenta en los casos B y D. No se presentaron perturbaciones en la conectividad del dispositivo móvil, lo que significa que el proceso de re-selección de red fue transparente para el usuario. El desarrollo de las pruebas ha demostrado, que la plataforma Android se puede usar en ambientes académicos para la experimentación de conceptos que requieran del acceso al código fuente de las APIs o incluso al mismo sistema operativo, lo cual no es posible en las plataformas propietarias actuales, que normalmente son muy restrictivas. Por otra parte, uno de los beneficios más grandes que ofrece Android a los desarrolladores, es la facilidad con que se puede instalar y ejecutar su plugin sobre Eclipse Helios y Netbeans IDE V 7.0.1, así como también la independencia respecto al sistema operativo sobre el que se instalan los IDES (Windows XP y Ubuntu). 3. Cliente Móvil En esta sección se presenta el desarrollo y la implementación de una aplicación Web móvil, llamada Cliente Móvil, que permite el acceso a la plataforma Urb@naLab a través de dispositivos móviles a) Implementación del Cliente Móvil Para la implementación del Cliente Móvil se propuso generar una vista o interfaz gráfica de usuario (GUI), mediante el framework JQuery Mobile, y usar JQuery para consumir los servicios Web ofrecidos por la plataforma JQuery es una librería (o framework) de JavaScript diseñada para simplificar el uso de documentos HTML, el manejo de eventos, 83

85 desarrollo de animación y la adición de interactividad a las páginas Web mediante AJAX. Las características más destacadas de JQuery incluyen (JQuery, 2012): Acceso a cualquier elemento de un documento HTML, mediante un lenguaje de selectores. Manipulación de cualquier elemento de un documento HTML (a través del DOM). Manejo de eventos. Efectos visuales y animaciones de la mayoría de los elementos de un documento HTML. AJAX (provee algunas funciones para manipular HTML o JSON). Simplifica tareas básicas de JavaScript, por ejemplo, obtener información del navegador, operar con objetos y vectores, entre otras. Extensión de la librería a través de plugins. Compatibilidad con los navegadores más comunes, al menos con todos los que soportan JavaScript, como Mozilla Firefox 2.0+, Internet Explorer 6+, Safari 3+, Opera y Google Chrome 8+. JQuery consiste en un único archivo JavaScript que contiene las funcionalidades comunes del DOM, eventos, efectos y AJAX. La característica principal de JQuery es que permite cambiar el contenido de una página web, sin necesidad de recargarla, mediante la manipulación del árbol DOM y peticiones AJAX. Otra de las posibilidades que ofrece JQuery, y quizás la más atractiva para los desarrolladores, es la selección y manipulación de cualquier elemento HTML a través de una especificación CSS (Selector API), lo que hace que la consulta sea más sencilla y ligera. Adicional a esto, JQuery permite manipular los elementos a través de comandos encadenados (unión de varios selectores), esto significa, que es posible agregar sobre la estructura base de una declaración, cualquier otra función necesaria para realizar varias operaciones en una sola sentencia. Todas las características mencionadas se pueden obtener de forma gratuita, ya que JQuery tiene licencia para usarse en cualquier tipo de plataforma, personal o comercial. Para esto, sólo se debe incluir en la aplicación Web un script JavaScript que contiene el código de JQuery. El servidor enviará al cliente el archivo de JQuery la primera vez que este acceda a la aplicación Web. Para las siguientes páginas, el cliente ya tendrá el archivo por lo que no será necesario transferirlo sino 84

86 utilizarlo de la caché. JQuery Mobile es un framework de JavaScript basada en JQuery creada específicamente para implementar aplicaciones Web en dispositivos móviles, compatibles con una amplia gama de dispositivos y navegadores (JQuery Mobile, 2012). Este framework proporciona una serie de herramientas, incluyendo el manejo del DOM de un documento HTML, el control de eventos, la comunicación con el servidor a través de AJAX, así como los efectos de animación y de imágenes para páginas Web. Las características básicas de jquery Mobile incluyen: Facilidad de uso: Provee mucha facilidad para el desarrollo de interfaces de usuario de dispositivos móviles. Soporte HTML5: Soporta las últimas tecnologías de HTML5, CSS3 y JavaScript. Tamaño pequeño: El tamaño de la versión comprimida de JQuery Mobile es de 12kb. Tematización: Proporciona una herramienta (ThemeRoller) para el anejo de temas (themes) o estilos. Componentes de UI: Provee soporte para diferentes tipos de elementos de Interfaz de Usuario (UI) como barras de herramientas, botones, pestañas, menús pop-ups, diálogos, transiciones, paneles de edición y elementos de formulario. Multiplataforma: Es compatible con las principales plataformas móviles y de escritorio: Apple ios, Android, Windows Mobile, BlackBerry, Palm WebOS, Nokia/Symbian, entre otros. Para soportar las necesidades básicas y específicas del desarrollo móvil, JQuery Mobile utiliza la técnica Progressive Enhancement o Mejora Progresiva, una estrategia para el diseño Web cuyo enfoque principal es diseñar una página Web a partir de elementos básicos (HTML estático y semántico), que pueda ser ejecutada por cualquier navegador, e incluir luego las novedades y mejoras para navegadores específicos que las soporten (David, 2011). Con esto, JQuery Mobile asegura la posibilidad de que el contenido de una aplicación Web pueda ser visualizado y accedido desde cualquier plataforma. Por sus diversas características y ventajas de implementación, JQuery Mobile es una buena alternativa para desarrollar aplicaciones 85

87 Web para móviles. Inicialmente, se había propuesto desarrollar un componente de software bajo Android que permitiera el acceso a la plataforma Urb@naLab a través de dispositivos móviles, esto considerando el hecho de que el componente de re-selección de redes inalámbricas también había sido desarrollado sobre esta plataforma. Sin embargo, y después de revisar algunos artículos de interés sobre el tema, se decidió estudiar la posibilidad de desarrollar una aplicación Web multiplataforma capaz de funcionar en una amplia gama de plataformas móviles. En la Tabla 4 se presentan las diferencias más representativas de Android y JQuery Mobile (Firtman, 2012; Butler, 2011). Tabla 4. Comparación de Android y JQuery Mobile Característica Android JQuery Mobile Entorno de Desarrollo Eclipse, usando el plugin de Herramientas El framework se descarga de de Desarrollo de Android (ADT). manera independiente y proporciona una serie de herramientas para el desarrollo de aplicaciones web móviles. Despliegue Terminales móviles que funcionen bajo Soporta las principales esta plataforma. plataformas móviles y navegadores de escritorio: ios, Android, BlackBerry, WebOS, Symbian, Windows Phone 7, entre otros. Actualización Cada vez que se genere una nueva Las aplicaciones solo se versión de la aplicación, el usuario debe actualizan en el servidor y los descargar el instalador al dispositivo clientes tendrán acceso a la última versión Como se ha indicado anteriormente, el desarrollo de un componente de software en Android, limitaría su uso sólo a plataformas Android, mientras que una aplicación Web en JQuery Mobile sería compatible con un gran número de plataformas móviles, incluyendo aquellas que no soportan JavaScript. Por esta razón y la facilidad para la actualizacion de las aplicaciones, se tomó la decision de usar jquery Mobile como herramienta para desarrollar la aplicación móvil que permite el acceso a la plataforma Urb@naLab. b) Funcionamiento del Cliente Móvil En general, el funcionamiento del Cliente Móvil (ver Figura 7) se puede resumirse en lo siguiente: 86

88 El usuario solicita un recurso, a través de la URL, al servidor de Urb@naLab. El servidor recibe la solicitud o petición y la redirige a un espacio, en el mismo servidor, dedicado al Cliente Móvil. Dependiendo de la petición del usuario, el Cliente Móvil consume uno de los servicios Web ofrecidos por la plataforma, por ejemplo el servicio de autenticación o consulta de información de ideas, y retorna el recurso solicitado mediante una página Web que se mostrará en el navegador. Figura 7.Funcionamiento del Cliente Móvil El Cliente Móvil sólo provee algunas funcionalidades básicas de la plataforma principal (Urb@naLab Web), esto con el fin de hacerlo mucho más liviano. El componente o módulo de Urb@naLab que se seleccionó fue Creación de Ideas. Luego, se seleccionaron los casos de uso más representativos de este módulo y se implementaron usando jquery (ver Tabla 5). Tabla 5. Casos de uso que implementa el Cliente Móvil Módulo Creación de Ideas Casos de Uso CU1: Consultar ideas propias. CU2: Ver información de mi idea. CU3: Consultar todas las ideas. CU4: Ver información de una idea. c) Pruebas de Despliegue Las pruebas de la aplicación móvil desarrollada se realizaron en un ambiente de laboratorio usando dispositivos móviles tipo Smartphone con conectividad a redes inalámbricas WiFi y 3G. A continuación se presentan imágenes que ilustran la GUI de los 87

89 casos de uso implementados usando jquery Mobile: autenticación de usuarios móviles y consulta de ideas. Figura 8. Autenticación de usuario Figura 9. Respuesta a la autenticación de usuario exitosa 88

90 Figura 10. Consulta de ideas publicadas en la plataforma C. Conclusiones Para el proceso de implementación del Cliente Universal, se utilizaron las APIs nativas de Android, y se diseñó un caso de estudio, que permitió probar el componente en un ambiente real soportado por redes inalámbricas de tecnología Wi-Fi y 3G. El desarrollo de las pruebas permitió corroborar que Android se puede usar en ambientes académicos para la experimentación de conceptos que requieran del acceso al código fuente de las APIs o incluso al mismo sistema operativo, lo cual no es posible en las plataformas propietarias actuales, que normalmente son muy restrictivas. Por otra parte, uno de los beneficios más grandes que ofrece Android a los desarrolladores, es la facilidad con que se puede instalar y ejecutar su plugin sobre Eclipse y Netbeans IDE V 7.0.1, así como también la independencia respecto al sistema operativo sobre el que se instalan los IDEs (Windows XP y Ubuntu) Con respecto al acceso desde los dispositivos móviles a la plataforma Urb@naLab, éste se realiza a través de una aplicación móvil, que fue desarrollada en la herramienta de programación jquery Mobile. A pesar de que Android es la plataforma operativa dominante en los dispositivos móviles tipo Smartphone, el desarrollo de la aplicación móvil bajo este sistema operativo limitaría el acceso a Urb@naLab 89

91 desde dispositivos con otras plataformas operativas (p.ej. ios, Blackberry, Windows, entre otras). Ante esta situación, se decidió desarrollar la aplicación móvil bajo un enfoque web móvil que facilita el acceso a Urb@naLab desde diferentes tipos de plataformas operativas y la actualización hacia nuevas versiones. D. Referencias Android Developers, What is Android? (2012) Retrieved May 28, 2012, from Butler, M. (2011) Android: Changing the Mobile Landscape. IEEE Pervasive Computing, 10(1), pp Céspedes, S., García, A., Jiménez, O., Millán, A., Navarro, A., Solarte, Z., Tamura, G., & Zúñiga, C. (2008) Sistema Universal para Portabilidad de Dispositivos Móviles en Ambientes de Redes Inalámbricas Heterogéneas. Cali, Colombia: Universidad Autónoma de Occidente. David, M. (2011) Getting Started with JQuery Mobile, Retrieved June 22, 2012, from Enck, W., Ongtang, M., & McDaniel, P. (2009) Understanding Android Security. IEEE Security and Privacy, 7(1), pp Firtman, M. (2012) JQuery Mobile: Up and Running. CA, USA: O'Reilly Media. García, A., & Jiménez, O. (2008, September). Prototipo de Software de Re-Selección de Red en Ambientes de Redes Inalámbricas Heterogéneas. paper presented at the IEEE Colombian Communications Conference (IEEE COLCOM 2008), Cali, Colombia. JQuery, Documentation (2012), Retrieved May 31, 2012, from JQuery Mobile, Documentation (2012), Retrieved June 22, 2012, from Kassar, M., Kervella, B., & Pujolle, G. (2008) An Overview of Vertical Handover Decision Strategies in Heterogeneous Wireless Networks. Computer Communications, 31(10), pp Komatineni, S., MacLean, D., & Hashimi, S. (2011) Pro Android 3. New York, USA: Apress. Marcotte, E. (2011) Responsive Web Design. New York, USA: A Book Apart. Marichamy, P., Chakrabati, S., & Maskara, S.L. (1999). Overview of Handoff Schemes in Cellular Mobile Networks and their Comparative Performance Evaluation. IEEE Vehicular Technology Conference, 3, pp Márquez-Barja, J., Calafate, C.T., Cano, J.C., & Manzoni, P. (2011) An Overview of Vertical Handover Techniques: Algorithms, Protocols and Tools. Computer Communications, 34(8), pp Meier, R. (2009) Professional Android Application Development. Indianapolis, Indiana, USA: Wiley Publishing, Inc Nasser, N., Hasswa, A. & Hassanein, H. (2006) Handoffs in Fourth Generation Heterogeneous Networks. IEEE Communications Magazine, 44(10), pp Oliver, E. (2008) A Survey of Platforms for Mobile Networks Research. ACM SIGMOBILE Mobile Computing and Communications Review, 12(4), pp Open Mobile Alliance (2012), Retrieved May 28, 2012, from Ríos López, C.A. (2009) Traspasos Verticales: Visión general e Innovaciones. Revista Sistemas y Telemática, 7(14), pp Ryan, P. (2009), Dream(sheep++): A Developer's Introduction to Google Android, Retrieved May 28, 2012, from Sawyer, S., & Tapia, A. (2005). The sociotechnical nature of mobile computing work: Evidence from a study of policing in the United States. International Journal of Technology and Human Interaction, 1(3), Sun Developer Network, Java ME (2006), Retrieved May 28, 2012, from Tarkoma, S., & Lagerspetz, E. (2011) Arching over the Mobile Computing Chasm: Platforms and Runtimes. IEEE Computer, 44(4), pp

92 Woodbridge, J., Nahapetian, A., Noshadi, H., Sarrafzadeh, M., & Kaiser, W. (2009, April). Wireless Health and the Smart Phone Conundrum. Proceedings of the 2nd Joint Workshop on High Confidence Medical Devices, Software, and Systems and Medical Device Plug-and-Play Interoperability (HCMDSS/MDPnP 2009), San Francisco, CA, USA. Yan, X., Sekercioglu, A., & Narayanan, S. (2010) A Survey of Vertical Handover Decision Algorithms in Fourth Generation Heterogeneous Wireless Networks. Computer Networks, 54(11), pp

93 Capítulo 4 Servicios en Living Labs Leonardo Saavedra 13 Zeida María Solarte 14 Abstract. En el siguiente documento se presenta un resumen detallado de los servicios telemáticos, su taxonomía, las tendencias en la prestación de dichos servicios dentro de los Living Labs, el análisis de los servicios que podrían ser desplegados sobre la Plataforma de Computación Urbana (Urb@naLab) y los aspectos que se deben de tener en cuenta al momento de evaluar dichos servicios.introducción A. Introducción Los Living Labs se definen como entornos experimentales de validación basados en actividades de innovación de las tecnologías de la información y las comunicaciones (TIC). Estos se caracterizan por la participación de las comunidades de usuarios, permitiendo una cooperación entre estos y los desarrolladores y facilitando una mayor eficiencia en los ciclos de aprendizaje de los procesos de innovación (Gyann et al). Gracias a esto, el desarrollo de plataformas para la prestación de servicios (como por ejemplo Urb@naLab) se llevan a cabo teniendo en cuenta las necesidades y observaciones de los ciudadanos que harán uso de las mismas. Es por esto que antes de 13 Joven Investigador del Grupo de Investigación en Telemática e Informática Aplicada (GITI), Facultad de Ingeniería, Universidad Autónoma de Occidente. lsaavedra@uao.edu.co 14 Investigadora del Grupo de Investigación en Telemática e Informática Aplicada (GITI), Facultad de Ingeniería, Universidad Autónoma de Occidente. zsolarte@uao.edu.co 92

94 definir el tipo de servicios que se van a desplegar en una plataforma de este tipo, se hace indispensable conocer las tendencias a nivel mundial en dichos servicios y la forma como se podrían acoplar dichas tendencias a cada entorno. En los siguientes apartados de este documento se presenta una definición concreta de servicios de telecomunicaciones y la taxonomía de los servicios telemáticos, además las tendencias en servicios para Living Labs y los aspectos de evaluación tenidos en cuenta para estos, así mismo, se presentará la definición de los servicios propuestos que podrán ser desplegados sobre la Plataforma de Computación Urbana (Urb@naLab). B. Servicios de Telecomunicaciones Los servicios de telecomunicaciones son aquellas acciones tendentes a satisfacer una necesidad de comunicaciones mediante el intercambio, almacenamiento y tratamiento de información requerida por un usuario (Comisión del Mercado de las Telecomunicaciones, 2001). Por servicio de telecomunicaciones se entiende a la capacidad de transporte de información, que en algunos casos puede suponer el tratamiento y/o almacenamiento de la misma, ofrecida por un proveedor de servicios de telecomunicaciones a los usuarios a través de las redes de telecomunicaciones. Los servicios de telecomunicaciones se pueden dividir en (Pascual, 2000): Servicios Portadores: Son el resultado de la capacidad que tiene la red para transferir información extremo a extremo, independientemente del servicio final que soporte. Mediante estas capacidades portadoras de la red se prestan los servicios finales. Servicios Suplementarios (servicios de valor añadido): Aportan información adicional al proceso de transferencia de información entre los puntos A y B, cabe tener en cuenta que esta información no es imprescindible para la comunicación. Algunos ejemplos son la tarificación detallada, información del número llamante, entre otros. Servicios Finales o Tele-servicios: Son los servicios que suplen las necesidades específicas que tienen los usuarios como por ejemplo una conversación telefónica o el envío de un fax a través de una red de telecomunicaciones. 93

95 C. Taxonomía de un Servicio Telemático Los servicios telemáticos son aquellos servicios que utilizando como soporte servicios básicos, permiten el intercambio de información entre terminales con protocolos establecidos para sistemas de interconexión abiertos (Pedraza, 2003) 4. Clasificación de los servicios Telemáticos según áreas de interés Los servicios Telemáticos se clasifican en 2 áreas de interés, servicios superiores y servicios al consumidor, la Tabla 1 presenta una descripción detallada de estos tipos de servicios (Hernández, 2007). Los servicios del consumidor o servicios del cliente son definidos por los conceptos de Servicio Temático Virtual VTS (Virtual Thematic Service) y Servicio Temático Virtual Integrado o IVTS (Integrated Virtual Thematic Services). El VTS es un servicio de Internet que está diseñado para servir a una comunidad virtual de usuarios específica (VCU). Los IVTS corresponden a la integración de todos los VTS necesarios para satisfacer a una VCU específica Los servicios telemáticos en Internet se pueden clasificar según su tipo como servicios de comunicación y servicios de información (Hawa, 2000). Los Servicios de comunicación son utilizados para establecer la comunicación entre las personas. Algunos de los criterios que se deben de tener en cuenta a la hora de clasificar los servicios de comunicación son: Comunicación en tiempo real o en tiempo diferido Comunicación uno-a-uno, uno a muchos, muchos a muchos, o de difusión Comunicación simplex o dúplex Comunicación en formato texto, audio, vídeo, icónica, pictográfica o tipo 3D Comunicación centralizada o distribuida Comunicación pública o privada Comunicación administrada o libre Comunicación con conexión o sin conexión Comunicación cifrada o no cifrada 94

96 Tabla 1. Clasificación de los servicios. (Hernandez, 2007) Los Servicios de Información son utilizados para que las personas accedan a una fuente de información. Los criterios que se deben de tener en cuenta para clasificar estos servicios son: Información centrada en base de datos, centrada en fichero o centrada en mensajes Información pull o push Información simple o múltiple Información en formato texto, audio, vídeo, icónica, pictográfica o 3D Información en formato estándar o propietario Información centralizada o distribuida Información jerárquica o heterárquica Información que permite consultas o que no permite consultas Información pública o privada Información cifrada o no cifrada 95

97 Información comprimida o no comprimida 5. Clasificación de servicios en SOA SOA se centra básicamente en la infraestructura funcional y sus servicios de negocio. La clasificación de los servicios se lleva a cabo según el tipo y las características que tienen distinto significado desde el punto de vista del diseño, la implementación y la gestión del proyecto. En SOA se debe llevar a cabo una división en dos partes, aplicaciones frontend y backend. Las aplicaciones frontend no son servicios, pero son elementos activos de SOA, reciben los resultados e inician todos los procesos, algunos ejemplos de estas son: GUI y procesos Batch. En el backend hay servicios y estos se clasifican en servicios básicos, servicios intermediarios, servicios centrados en procesos y servicios empresariales públicos. Los servicios básicos son la base de SOA debido a que son servidores puros, están divididos en servicios centrados en los datos y servicios centrados en la lógica. Los servicios centrados en los datos tienen como propósito manejar los datos persistentes, almacenamiento, recuperación, mecanismos de bloqueo y gestión transaccional. Por su parte, los servicios centrados en la lógica proveen el encapsulamiento para cálculos complejos o reglas del negocio que son tradicionalmente encapsulados en bibliotecas y frameworks del negocio. Los servicios intermediarios hacen de puente entre las inconsistencias técnicas y discrepancias conceptuales en el diseño. Son clientes y servidores en la SOA mediando entre los distintos elementos que deben funcionar juntos, pero no son iguales a los servicios técnicos de infraestructura, ya que estos proveen un API técnica mientras que los intermediarios proveen un API orientada a negocios. Los servicios intermediarios se dividen en (Drafzig, 2005): Puertas de Enlace: Hacen de intermediarios para sus servicios de negocio y representan la funcionalidad de los servicios que están por debajo en un ambiente que es distinto tecnológicamente que el ambiente de ejecución del servicio de negocio original. Adaptadores: Este servicio intermediario se encarga de mapear las 96

98 firmas y formatos de los mensajes de un servicio a los requerimientos de un cliente. Por ejemplo si se tienen dos empresas cada una con una aplicación que resuelve la misma necesidad, con un adaptador para cada uno en cada sentido de los pedidos, se mapean los requerimientos de la aplicación que usa un servicio en el otro y viceversa. Fachadas: Proveen una vista distinta de uno o más servicios existentes, debido a esto, también pueden actuar como Tecnología de puerta de enlace o adaptadores. Puede actuar como capa para simplificar el acceso a los servicios básicos de un proyecto, aunque esto puede generar una capa monolítica de acceso a los servicios, lo que dificultará el reuso de los mismos que están por debajo por parte de otros proyectos. Agregadores de funcionalidad: se usa cuando se quieren agregar funcionalidades a un servicio existente sin cambiar el mismo. Este tipo de servicios se pueden utilizar por ejemplo con terceras partes sin código disponible como primer paso en la implementación de un servicio existente, servicio original en desarrollo por una parte del equipo u otro proyecto en la empresa. Los servicios centrados en procesos actúan tanto de clientes como servidores en una SOA, manteniendo el estado del proceso para sus clientes. Básicamente se encargan de encapsular el conocimiento de los procesos del negocio de la organización, controlan y mantienen el estado del proceso en ejecución. Definen sus procesos de negocio y su control con base en la orquestación de los servicios existentes (Drafzig, 2005). Es en este tipo de servicios en los que aparecen los conceptos de BPMS (Business Process Management System), BPML (Business Process Modeling Language) y BPEL4WS (Business Process Excecution Language for Web Services), para la orquestación de los servicios utilizados. Los servicios empresariales públicos son servicios que una empresa ofrece a socios y clientes para su consumo. Estos servicios tienen requerimientos específicos de interface, desacoplamiento, seguridad y facturación de uso, ya que las empresas deben acordar claramente cómo se realiza el uso de los mismos (Drafzig, 2005). D. Servicios en Living Labs Un Living Lab se define como una plataforma metodológica de 97

99 experimentación y co creación con participación de usuarios y/o ciudadanos reales, en entornos reales para la investigación científica y tecnológica, desarrollo e innovación (I+ D+ i) utilizada para especificar, crear prototipos, validar y perfeccionar soluciones complejas en entornos de la vida real donde los usuarios, investigadores, empresas e instituciones públicas trabajan en equipo para crear nuevas soluciones, productos, servicios y modelos de negocio (Fernández et al). Los Living Labs buscan contribuir a un nuevo sistema de innovación donde los usuarios y ciudadanos se convierten en actores activos y dejan de ser receptores pasivos. Las actividades principales de un Living Lab son las siguientes: Co Creación: Co diseño realizado por los usuarios y productores. Exploración: Descubrir nuevos usos, comportamientos y oportunidades del mercado. Experimentación: Permite a los usuarios estar presentes en la implementación real de las actividades del Living Lab. Evaluación: Evaluación de conceptos, productos y servicios de acuerdo con criterios socio ergonómicos, socio cognitivos y socio económicos. En otras palabras, un Living Lab se relaciona con la participación activa de los ciudadanos con un territorio para llevar a cabo innovación, la cual integra las TIC de manera eficiente, intensiva y productiva, en los diversos sectores y ámbitos de la sociedad, permitiendo la producción de resultados a partir de la Investigación, Desarrollo e Innovación (I + D + i) de productos y servicios, mediante la apropiación colectiva de la Ciencia, Tecnología e Innovación (CT + I), involucrando al ciudadano en todo el proceso de innovación de la cadena de valor del producto y/o servicio (Roldán Francisco, 2011). 6. Tendencias en servicios orientados a Living Labs En la actualidad, los Living Labs son utilizados en diversos campos, puesto que su enfoque colaborativo entre los usuarios y los desarrolladores se ha convertido en un método llamativo para la implementación de servicios en muchas áreas de conocimiento. Actualmente, los proyectos que utilizan un Living Lab como herramienta de co creación se enfocan principalmente en las siguientes áreas. (Europe s Information Society): E - Salud: Este campo refleja la atención del estado físico y 98

100 sicológico de las personas, centrándose en la prevención y cuidado de los usuarios. Los Living Lab ofrecen las condiciones perfectas para reducir los riesgos que se presentan en el lanzamiento de los servicios, tanto desde el punto de vista de los negocios como el de la salud pública, esto debido a que la tolerancia de fallos debe ser nula. La complicación del desarrollo de servicios para este campo radica en que las necesidades se generan de acuerdo a la actualidad del mercado, y dichos servicios deben ser prácticamente personalizados para que sean bien recibidos por los usuarios de Living Lab (Fernández L et al). Democracia y gobierno en línea: Este tipo de servicios le permiten a los usuarios tener una amplia participación electrónica en temas relacionados con la democracia y la política, teniendo como requisito una legislación organizada para el correcto funcionamiento de los mismos. Desarrollo de zonas rurales: Debido a las altas tasas de crecimiento de las economías, los procesos socioeconómicos son extremadamente dinámicos y los requisitos de los mismos cambian constantemente. Las estructuras sociales reflejan la diversidad cultural y esto crea la necesidad de diseñar, desarrollar y validar los avances tecnológicos en todo tipo de entornos, es por esto, que se hace necesario poner en práctica estas tecnologías particularmente en las regiones con diferentes características económicas y sociales, permitiendo el desarrollo de zonas urbanas, pero especialmente el desarrollo de las zonas rurales 7. Evaluación de Living Labs Una vez un Living Lab ha sido creado, se hace indispensable evaluar el potencial del mismo. Vontas et al en el documento Evaluating Living Labs Core Competences and Assets sugieren los siguientes parámetros de evaluación: Operación: Este punto hace referencia a la forma en la cual funciona un Living Lab, los servicios que presta, el modelo de negocio, las técnicas utilizadas para la construcción y gestión del mejoramiento ciudadano, y el nivel de éxito de los puntos anteriormente mencionados. Interoperabilidad: Se refiere a las perspectivas de integración en términos de métodos, herramientas, infraestructuras, aplicaciones, etc. Análisis del impacto de las actividades del Living Lab, servicios y resultados en los sistemas de innovación: Este punto hace 99

101 referencia a todo lo relacionado con el nivel de desempeño, la eficacia, la eficiencia, la calidad y la evaluación comparativa con otros productos, así como la normalización y acreditación en mejores prácticas. Compatibilidad: Se refiere a la capacidad para acoplarse a la normatividad internacional, así como también al apoyo en actividades de proyectos que faciliten la investigación, desarrollo e innovación (I+ D + I). También es necesario evaluar el impacto causado por el Living Lab a nivel de innovación. En la tabla 2 se presentan las áreas y las competencias que se deben de tener en cuenta a nivel de innovación. Tabla 2. Competencias básicas a nivel de innovación de un Living Lab. (Adaptado de Vontas et al) Elementos Principales de la Innovación en Living Lab Social Político Mercado Operacional Tecnológico Competencias Sensibilización de la comunidad Participación de los usuarios Conocimientos especializados en cuestiones legales Impacto en gobiernos regionales y actividades locales Financiamiento - Fondos de recaudo Comercialización - Explotación de negocios Gestión de proyectos Infraestructura + logística Métodos y herramientas Trasmisión de información - infraestructura de internet Servicios de internet Internet de las cosas (IoT) Internet Móvil Seguridad De igual forma se hace indispensable conocer el punto de vista de los usuarios que hacen uso de los servicios del Living Lab, es por esto que los parámetros para su evaluación que comúnmente son tenidos en cuenta son: 100

102 Pertinencia del nombre del servicio: El nombre del servicio es acorde a la funcionalidad del mismo. Usabilidad: El servicio es intuitivo, las secuencias de las acciones sobre el servicio están diseñadas de manera correcta, las opciones presentadas en el servicio son claras y no confunden a los usuarios que ingresan por primera vez (González et al). Otros aspectos a tener en cuenta en la usabilidad son la facilidad de aprendizaje, facilidad y eficiencia de uso, facilidad de recordar cómo funciona, frecuencia y gravedad de errores y la satisfacción subjetiva (Gobierno de Chile, Guía Web 2.0). Calidad del servicio: El servicio cumple con las especificaciones dadas y las herramientas que provee son las adecuadas. Movilidad: El servicio es accesible desde cualquier lugar, en cualquier momento. También cabe aclarar que dicha evaluación debe variar dependiendo de las características de los usuarios, puesto que la percepción de un adulto mayor generalmente es diferente a la de un adolescente o un adulto joven (Moumtzi et al). 8. Living Labs a nivel mundial Los Living Labs se están implementando en diferentes partes del mundo, algunos de los más reconocidos son: a) Citilab Cornella Este Living Lab está localizado en la ciudad de Barcelona (España) y su característica principal es que se presenta como un híbrido entre centro de investigación, centro de formación y una incubadora de iniciativas empresariales y sociales, enfocando sus actividades al mejoramiento social, cultural y económico de la ciudad. Este centro para la innovación social aplicada tiene como método de trabajo ubicar al ciudadano como centro del proceso, explotando y difundiendo el impacto digital en el pensamiento creativo, el diseño y la innovación que surgen de la cultura digital como medio para innovar de forma colaborativa e integradora con el ciudadano. Un aspecto relevante de Citilab son los contenidos que se proponen y la actividad ciudadana que estos generan. Las áreas de acción de Citilab replican la dinámica de creación o recepción de proyectos, aprendizaje e investigación. Innovación, territorio y ciudadanía: Su objetivo es el diseño 101

103 participativo en proyectos que tengan que ver con el ámbito territorial y urbano. Educación, formación e innovación: Exploración de las nuevas metodologías que utilizan las tecnologías de la información y las comunicaciones para una óptima prestación del servicio de educación. Nuevas medias sociales: Se enfoca en las nuevas formas de producción audiovisual. Innovación en economía y sociedad: Investigación e innovación en el ámbito empresarial y social. Nuevos sistemas de R+D+i basados en los usuarios: investigación relacionada con los nuevos mecanismos de innovación social. b) Living Lab Salud Andalucía (LLSA) Este Living Lab es una red abierta de innovación entre el gobierno Español, la universidad, las empresas TIC y los usuarios (ciudadanos, pacientes y profesionales del sector salud). Está basada en entornos, plataformas y recursos para fomentar el desarrollo de productos, tecnologías, servicios e iniciativas innovadoras en el sector de la salud. Su origen se da debido a una iniciativa en conjunto de la consejería de economía, innovación y ciencia, así como también de la consejería de salud de la junta de Andalucía (España), la cual fue materializada el 24 de noviembre de 2008en un convenio macro que participaron inicialmente 44 entidades públicas y privadas del sector tecnológicosanitario, para facilitar el desarrollo y validación de diferentes soluciones tecnológicas a problemas socio sanitarios concretos, con el objeto de mejorar la calidad de vida de la sociedad en general y utilizando para ello un sistema abierto de innovación. c) Centro de Investigación Experimental en Aplicaciones y Servicios de Inteligencia Ambiental (CIAMI) Este Living Lab es una infraestructura que combina una simulación de un espacio físico habitable donde cualquier persona podría vivir con tecnologías integradas en el entorno. Su principal objetivo es ofrecer un ambiente inteligente en el cual se realicen las pruebas de los prototipos tecnológicos con usuarios reales. 102

104 Este Living Lab ha sido diseñado para poner en práctica las siguientes investigaciones y desarrollos: Fomentar la colaboración activa con organizaciones que representan a los usuarios finales (ancianas, pacientes con discapacidades o enfermedades crónicas y ciudadanos en general), con el objetivo de que el trabajo en equipo culmine con la aceptación de las soluciones tecnológicas innovadoras y la capacidad para que estas se adapten a las necesidades y condiciones del entorno de los usuarios. Desarrollo de soluciones tecnológicas innovadoras, asequibles y aceptables relacionadas con el apoyo de atención médica y servicios de asistencia social en el país (España). Evaluación de las soluciones tecnológicas provenientes de la industria y de otras iniciativas de investigación promovidas por el equipo de desarrollo que posee este Living Lab. Evaluación intensiva de aplicaciones y servicios en el largo plazo, haciendo énfasis en el uso y la aceptación por parte de los usuarios para ser entregado como un producto confiable en el mercado. d) Habitat Living Lab (Habitat Living Lab, 2008) El objetivo principal de este Living Lab es el desarrollo de tecnologías que sean amigables con las comunidades de bajos ingresos, permitiendo el mejoramiento de las condiciones de vida de los ciudadanos de dichos entornos. Las tecnologías generalmente están centradas en: Soluciones de bajo costo y mantenimiento para viviendas de bajos ingresos: En este punto se tienen en cuenta desarrollos tecnológicos relacionados con iluminación, fuentes renovables de energía, materiales de construcción alternativos o reciclados, residuos sólidos, suministro de aguas, entre otros. Cuidado del medio ambiente y vida en el campo: En este aspecto se tienen en cuenta soluciones para la eliminación de residuos animales y sólidos, uso de pesticidas, tratamiento de aguas residuales, entre otros. e) Aware Home in Georgia (Living Lab, USA) 103

105 Este Living Lab se enfoca en la exploración multidisciplinaria de las nuevas tecnologías y servicios basados en el hogar, permitiendo simular y evaluar la experiencia del usuario con las tecnologías de última generación. Entre sus campos de actuación se encuentran (Living Labs, USA): Sistemas para controlar automáticamente las cortinas ahorrando costos de energía eléctrica y permitiendo mantener una óptima iluminación en el hogar. Robótica en casa: Este campo de la investigación permite que los robots utilizados lleven a cabo las labores del hogar 9. Living Labs en Colombia Para poder hablar de los Living Labs en Colombia, primero hay que hablar de los territorios del conocimiento, los cuales se definen como la apropiación de la ciencia, tecnología e innovación abierta y colaborativa, haciendo uso intensivo, productivo y eficiente de las TIC como medio, donde el ciudadano participa de manera más directa en el desarrollo de los productos y servicios potenciando la creatividad y el talento de la población de dicho territorio para darle sostenibilidad al conocimiento tácito y crear conocimiento a partir de la investigación, desarrollo e innovación (I+D+i). Según Francisco Javier Roldán Velásquez fundador y presidente de la fundación país del conocimiento, en Colombia, la iniciativa de los Living Labs es liderada por esta fundación cuyo objetivo principal es coordinar la estrategia para construir un país del conocimiento que articule a todos los departamentos y regiones del país como territorios del conocimiento a través de Living Labs. Su visión es buscar que todos los ciudadanos de Colombia hagan uso adecuado, productivo, intenso, innovador y eficiente de las tecnologías de la información y las comunicaciones (TIC), a partir de la educación pertinente con la apropiación de la ciencia, tecnología e innovación para alcanzar la prosperidad colectiva mediante una mayor competitividad y productividad del país, con el fin de mejorar la forma en que se comunican, viven, estudian, trabajan, recrean, gobiernan, dirigen, se divierten, compran y viajan, sin exclusiones de ningún tipo para nadie, donde la cultura, el arte, el emprendimiento y el fortalecimiento del empresarismo jueguen un rol determinante. A continuación se muestran los Living Labs más relevantes de 104

106 Colombia. a) Antioquia Departamento del Conocimiento En el departamento de Antioquia, los avances en la apropiación de la ciencia, tecnología e innovación, permiten que las condiciones para estructurar y poner en marcha el proyecto Antioquia Departamento del Conocimiento a través de un Living Lab con el apoyo de la Red Europea de Living Labs se puedan dar. Esto debido a que se cuenta con una sólida red institucional que evoluciona cada día y une esfuerzos con el estado, la academia, las organizaciones no gubernamentales (ONG) y el sector privado, permitiendo que el usuario desempeñe un rol relevante en los temas de investigación e innovación, trabajando de forma colectiva y participativa en todos los temas que permiten que la ciudad de Medellín y el Departamento de Antioquia (Colombia) sean modelos de apropiación de la tecnología, innovación y uso de las TICs. Gracias a estas características, este proyecto fue seleccionado y certificado por la ENoLL (European Network of Living Labs) el día 22 de Abril de 2011, permitiendo así que el departamento de Antioquia se convierta en miembro de dicha red internacional, con el propósito de estructurar y poner en marcha el proyecto Antioquia Departamento del Conocimiento mediante la creación de ecosistemas de creación abierta y colaborativa, compartiendo, co-diseñando, co-creando y experimentando buenas prácticas de networking con los mejores de Europa y otros países que tienen proyectos certificados por ENoLL (Roldan Francisco, 2011). b) Living Lab Cluster TIC Bogotá Este Living Lab es un cluster que involucra a las empresas del sector de las tecnologías de la información y las comunicaciones, así como también a aquellas cuyo nicho de trabajo es la Animación Digital y Videojuegos (ADVJ) en Colombia, beneficiando a las PYMES (Pequeñas y Medianas Empresas) y a la industria nacional e internacional. Las ideas innovadoras presentes en este Living Lab se pueden ver reflejadas en la aplicación de tecnologías emergentes, gestión del conocimiento (Coaching), transferencia tecnológica y la formación de alianzas con entidades gubernamentales, la industria, la educación y los agentes académicos. Como su objetivo principal presenta la búsqueda del mejoramiento 105

107 en el entorno social con iniciativas basadas en la aplicación de tecnologías actuales que permitan soportar sectores económicos como el turismo, cosméticos, las tecnologías de la información y las comunicaciones y las ADVJ. Este proyecto fue certificado el día 22 de Abril de 2011 por la ENoLL. c) Otros Living Labs Adicionalmente, en Colombia existen 4 proyectos más que fueron certificados por la ENoLL, estos son: Ciudad Bolívar Localidad Digital: Presentado por la Universidad Distrital de Bogotá. Red Salvavidas: Presentado por RedSalvavidas Inteligencia Colectiva: Presentado por Knowledge Factory Medellín Digital: Presentado por Medellín Digital 10. Servicios en la Plataforma de Computación Urbana (Urb@nalab) De acuerdo al estudio realizado sobre la taxonomía de los servicios telemáticos se decidió que la tipología de los servicios que se pueden desarrollar para la plataforma Urb@nalab estaría enmarcada en servicios Telemáticos y dada la naturaleza del proyecto estos servicios serian Ubicuos. Dado el enfoque de la computación urbana, los servicios se prestarían para grupos de personas, lo que implica un entorno interactivo, y debido que estos grupos de personas pueden tener diferentes intereses y características y una gran movilidad dentro del ambiente, se estaría hablando de un espacio creativo. Con respecto a la caracterización de los servicios ubicuos, dado que se ha seleccionado un ambiente interactivo, que se presta a grupos de personas con diferentes intereses y características, se tendrían servicios en la dimensión general y móvil, los cuales podrían ser constantes o temporales. Una vez caracterizado el tipo de servicio que va a abordar la plataforma Urb@naLab, se deben tener en cuenta las temáticas que serán abordadas por los equipos de trabajo, estas temáticas son: educación, gobierno, salud, seguridad ciudadana, turismo, empresas e innovación. Es por esto, que cualquier servicio relacionado con estas temáticas y que cumpla con la caracterización de los mismos, podría hacer uso 106

108 de la plataforma Teniendo en cuenta que los servicios deben suplir las necesidades de los usuarios, los equipos de trabajo determinaron desarrollar servicios que sean sugeridos en los Grupos de Discusión (Focus Group) de las diferentes Universidades (Universidad Autónoma de Occidente, Universidad Icesi y la Universidad Santiago de Cali). Para llevar a cabo este proceso se llevaron a cabo los siguientes pasos: Se crearon grupos de apoyo compuestos por estudiantes y docentes de las diferentes universidades. Se recopiló la información relacionada con los servicios por medio de una encuesta en la que se les pedía información relacionada con el tipo de servicio al que deseaban acceder por medio de la plataforma, así como también los medios de comunicación por los que se debería acceder a los mismos. Se llevó a cabo el proceso de selección de los servicios a desplegar sobre la plataforma, para esto, se realizó un trabajo conjunto entre los investigadores de Urb@naLab y expertos seleccionados en las temáticas de salud, gobierno, turismo y desarrollo rural, dando como resultado, la selección de los servicios presentados en los siguientes apartados. (Saavedra et al) a) Servicio de participación en debates (Gobierno) Este servicio de Urb@naLab es una aplicación móvil interactiva que permite a los ciudadanos participar activamente en debates políticos, calificando y opinando sobre los comentarios de los actores del debate. Podrán seguir cada momento de la discusión y expresar su opinión sobre lo que acontece en ella, al tiempo que realimentan el actuar político en su comunidad. Con este servicio, Urb@naLab promovería la participación civil en la política local debido a que acerca los ciudadanos a sus dirigentes. Y de igual forma, les permite a los actores políticos enterarse de las opiniones que suscitan sus propuestas, para reforzaras o para proponer nuevas alternativas. b) Información para grupos específicos en el sector de la salud (Salud) Este servicio de información le permitiría a las empresas del sector 107

109 Salud ingresar información relacionada con cada grupo de usuarios de sus servicios, es decir, le permitirá el ingreso de información para el grupo relacionado con Diabetes, Embarazadas, Cáncer, etc. Así mismo, los usuarios relacionados con estos grupos de salud, podrían ingresar a la plataforma y una vez registrados, seleccionarían la información que desean recibir (relacionada con su grupo), así como también el medio por el cual les gustaría recibir la misma (Correo Electrónico, Mensajes de Texto o ambos). Con este tipo de servicios, Urb@naLab llegaría a todos los sectores sociales, promoviendo la masificación de la información y facilitando la entrega de la misma. c) Servicio de información al usuario sobre promociones turísticas de la región del Valle del Cauca (Turismo) Hay que tener en cuenta que existen varias clases de turismo, por ejemplo: Rural, ecológico, urbano, cultural, Sol y playa, Deportivo, Convenciones, salud, entre otros. Este servicio de información incluye información sobre servicios adicionales al visitarlo, tales como: Costo de entrada, planes vacacionales, tarifas para temporada baja y alta, descuentos para: (grupos, visitas pedagógicas para instituciones educativas públicas y privadas, grupos de la tercera edad, etc.), servicios de cafetería, transporte, pasaporte (es decir, costos de afiliación), esto con el fin de realizar una tarea de mercadeo de fidelización de clientes. El servicio interactivo de Planes permitiría a los usuarios realizar búsquedas de los planes turísticos de su interés y posibilita realizar reservas, abonos y/o pagos (teniendo en cuenta que es necesaria la implementación de transacciones seguras y alianzas con entidades financieras, para el pago en línea a través de diferentes medios de pago electrónico). La información sería entregada a los usuarios por medio del correo electrónico. E. Conclusiones La implementación de plataformas que permitan el despliegue de servicios orientados al ciudadano ha permitido el desarrollo del concepto de Living Lab y con esto, ha involucrado a los usuarios finales de dichas plataformas en la elaboración de las mismas, logrando así, un óptimo cumplimiento de las necesidades de los clientes. 108

110 Al momento de evaluar los servicios prestados en un Living Lab, se recomienda seguir el lineamiento presentado en el punto 4 de este documento, sin embargo, también es indispensable tener en cuenta el tipo de usuario final al que van a ser presentados estos servicios, puesto que las características como la edad y la formación académica van a afectar el criterio de evaluación de los mismos. Las tendencias en servicios telemáticos están orientados a los campos de E Salud, desarrollo de zonas rurales, democracia y gobierno en línea, lo que indica que las decisiones tomadas al momento de hacer la selección de las áreas de interés de la Plataforma de computación urbana (Urb@naLab) fueron acertadas, puesto que en dicho proyecto las áreas de interés son el gobierno, la salud, el turismo, la educación, la innovación y la seguridad. A nivel nacional, se están implementando soluciones orientadas al uso de Living Labs, permitiendo con esto un mayor desenvolvimiento de los ciudadanos en las cadenas de I + D + i y las TIC, obteniendo productos y/o servicios que cumplen con los requerimientos de los usuarios. F. Referencias CMT Comisión del Mercado de las Telecomunicaciones. Definición de los Servicios. Servicios Telemáticos e Interactivos. Disponible en Internet: Drafzig, D, Banke, K, Slama, D.(2005) Enterprise SOA Service Oriented Architecture Best Practices. Pearson Education, Inc. ISBN Europe s Information Society. Living Lab for User Driven Innovation. Disponible en Internet: Fernández L. Del Arbol L. Romo P. Telefónica. Living Labs Incorporación de los usuarios finales en el proceso de innovación. Julio de Disponible en Internet: &activo=4.do?elem=6814. Gobierno de Chile. Guia Web 2.0 Usabilidad y Utilidad. Disponible en Internet: González A. Acosta Y. Moyares Y. Propuesta de un manual de usabilidad y accesibilidad para el desarrollo de personalizaciones de la plataforma de teleformacion Moodle. Universidad de las Ciencias Informáticas. Cuba. Diciembre de Gyan N. Bon A. Allen M. Adapting Living Labs Methodology for Information Systems in Rural Areas: The Case of Mobile Voice Technology in Mali. Octubre 10 de Habitat Living Lab. Purpuse of Habitat Living Lab Disponible en Internet: Hawa, M. (2000) La Red a la Carta: Las Comunidades Virtuales de Usuarios y los Servicios Telemáticos Temáticos Integrados. Universidad Politécnica de Valencia. Disponible en Internet: 109

111 Hernández, J.: (2007) La Localización de las Actividades de los Servicios Superiores en el Centro de la Ciudad: Un Análisis Estático del Patrón de Localización de los Bancos y Servicios Especializados en la Ciudad de Puebla, Edición electrónica gratuita. Texto completo en Living Labs: USA. Aware Home in Georgia. Ambient Assisted Living Deutchland (AAL). Disponible en Internet: Pascual, J. (2000). Introducción a la Telemática y a las Redes de Datos. Servicios de Información. Telefónica España. Pedraza, W. (2003) Clasificación de los servicios de Telecomunicaciones. Servicios Telemáticos y de Valor Agregado. Ministerio de Comunicaciones, Republica de Colombia. Disponible en Internet: 20PDF/Clasificacion%20de%20los%20Servicios%20de%20Telecomunicaciones.pdf Roldán Francisco. Antioquia Living Lab. Fundación país del conocimiento Disponible en Internet: Roldán Francisco. Qué son los Living Labs?. Fundación país del conocimiento Disponible en Internet: Roldán Francisco. Que son los territorios del conocimiento? Fundación país del conocimiento. Disponible en Internet: Moumtzi V. Wills C. Utilizing Living Labs Approach for the Validation of Services for the Assisting Living or Elderly People. IEEE International conference of digital ecosystems and technologies Saavedra L. Vargas L. Caldas M. Entregable E3.2. Plataforma de computación urbana (Urb@naLab) para ofrecer servicios orientados al ciudadano en entornos urbanos inalámbricos que favorezcan un enfoque de living labs en las ciudades Colombianas. (2011). Vontas A. Protogeros N. Evaluating Living Labs Core Competences and Assets. Universidad de Macedonia IEEE International conference on Digital Ecosystems and Technologies. 110

112 Capítulo 5 Implementación y Pruebas de la Plataforma Urb@naLab Claudia L. Zúñiga 15 Andrés Millán 16 Andrea Arteaga 17 Juan David Millán 18 Abstract. El proceso de implementación y puesta en marcha de una plataforma de computación urbana requiere de la implementación de pruebas a través de mecanismos que permitan la evaluación y el mejoramiento de los procesos desarrollados, con el propósito de brindar un producto estable, usable y adaptado a las necesidades de los ciudadanos dentro de un entorno urbano. Este capítulo presenta la descripción de las pruebas desarrolladas para la Plataforma Urb@nalab en un entorno controlado y en un entorno real a través de grupos focales definidos que permitieron la retroalimentación y mejoramiento de la calidad de la Plataforma Urbanalab desarrollada. 15 Directora Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. claudia.zuniga00@usc.edu.co 16 Investigador Principal del Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. afmillan@ieee.org 17 Investigador Asistente del Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. andreaarteagap@yahoo.com 18 Investigador Asistente del Grupo de Investigación en Computación Móvil y Banda Ancha COMBA I+D, Facultad de Ingeniería, Universidad Santiago de Cali. juanmillan85@gmail.com 111

113 A. Introducción Las pruebas de software son una parte clave de la construcción de la Plataforma que se ofrecerá a los usuarios finales, ya que se realizan para evaluar la calidad de un producto, y/o mejorarlo, por medio de la identificación de problemas y defectos. Tanto la Implementación como las Pruebas de la Plataforma Urb@naLab, fueron desarrolladas dentro de un ambiente controlado (Grupo de Testeo: Miembros de la Comunidad de la Universidad Santiago de Cali). Debido a que las pruebas requieren un proceso organizado para realizarse exitosamente, es necesario contar con grupos de colaboración para testear el producto, con ello se examina el comportamiento de Urb@naLab sobre un conjunto finito de casos de prueba, y luego comparándolos con el resultado esperado, se prosigue a realizar las respectivas mejoras y brindar a los usuarios un software confiable. B. Antecedentes El software conlleva una serie de especificaciones con relación a la calidad. La calidad queda definida por un nivel de abstracción, constituido por seis características: Funcionalidad: Pertenecen todas aquellas necesidades declaradas o implícitas. Dentro de las cuales se permite calificar si un producto de software opera de manera adecuada el conjunto de funciones que satisfagan dichas necesidades para las cuales fue diseñado (adecuación, exactitud, interoperabilidad, seguridad, conformidad). Fiabilidad: Indica la capacidad del software referente a la mantención de su nivel de rendimiento, bajo condiciones normales en un lapso de tiempo establecido (nivel de madurez, tolerancia a fallas, recuperación, conformidad). Usabilidad: Se evalúa el esfuerzo necesario con respecto al uso del sistema por parte del usuario (facilidad de aprender, operabilidad). Portabilidad: Capacidad del software en caso de ser transferido de un entorno a otro (adaptabilidad, facilidad de instalación, conformidad, capacidad de reemplazo, compresibilidad, atracción). 112

114 Mantenibilidad: Hace referencia al esfuerzo necesario para llevar a cabo modificaciones específicas al software, ya sea por la corrección de errores o el incremento de funcionalidad (capacidad de análisis, capacidad de modificación, estabilidad, facilidad de prueba). Eficiencia: En este caso se permite evaluar la relación entre el nivel de funcionamiento del software, frente a la cantidad de recursos utilizados. Los puntos exactos de la evaluación son el comportamiento con respecto al tiempo y comportamiento con respecto a recursos. C. Implementación y pruebas de la plataforma Urb@naLab La plataforma Urb@naLab fue implementada en la infraestructura física del Laboratorio de Computación Móvil y Banda Ancha (Universidad Santiago de Cali), en este espacio se dispuso de servidores propios del Grupo de Investigación COMBA I+D, para albergar la Plataforma y así realizar su despliegue en un ambiente controlado, de esta manera se obtuvo información de pruebas de campo real, lo que permitió una correcta implementación en el servidor del cliente, brindando un servicio apropiado y de utilidad para el usuario final. El testeó de la Plataforma Urb@naLab en primera instancia se realizó con la comunidad de la Universidad Santiago de Cali, con personas de diversos programas (jóvenes y mayores), de las cuales se obtuvieron resultados, donde se recopilaron las primeras fallas, errores, recomendaciones de usabilidad de la Plataforma, entre otras. Con base a los resultados obtenidos, se realizaron los ajustes correspondientes, para así obtener un software de Calidad. La Calidad de Software se llevó a cabo por el área indicada, del Grupo de Investigación COMBA I+D de la Universidad Santiago de Cali, donde se aplicaron Pruebas Funcionales, Pruebas de Usabilidad, Revisión de Estructura Interna y Revisión de Diseño, a través de todo el ciclo de desarrollo para obtener Funcionamiento, Funcionalidad y Usabilidad del producto, entre tanto, los desarrolladores se encargaron de realizar las Pruebas Técnicas (Pruebas de Unidad), esto con el fin de brindar un software que tenga las funcionalidades que requiere el cliente. 113

115 11. Implementación y pruebas internas sobre la plataforma Urb@naLab La implementación de la plataforma para la realización de las pruebas, y ajustes necesarios antes de ser liberado para el servicio del usuario final, fue realizado sobre un servidor propio del Grupo de Investigación COMBA I+D, configurado con los programas requeridos para el funcionamiento de la Plataforma. En este escenario de ambiente controlado, se desarrolló en la Universidad Santiago de Cali, dos pruebas con la comunidad estudiantil y docentes. Así mismo se desarrollaron un segundo grupo de pruebas bajo un ambiente real realizado con la comunidad del Municipio de Guacarí, lo que permitió identificar y solucionar los errores reportados en la Plataforma. 12. Diseño de la Prueba Las pruebas de la Plataforma están orientadas a la evaluación que se realiza sobre un producto (en nuestro caso, software) o servicio, por parte del grupo focal, para brindar satisfacción al usuario final. De esta manera un grupo focal es definido como un conjunto de personas reunidas para llevar a cabo las pruebas correspondientes del producto o servicio, en un ambiente de prueba determinado, el cual es un ámbito dotado con los recursos necesarios para la ejecución de la prueba. a) Definición de los grupos focales para la prueba de la Plataforma Urb@naLab El Grupo Focal es una herramienta muy útil para la planificación de los sistemas y la evaluación de los mismos, donde se provee participación a las personas involucradas en los respectivos programas. Esta actividad puede ser dirigida por cualquier persona que sea adiestrada, adquiera las destrezas requeridas y tenga un interés genuino en llevar a cabo la mencionada dinámica grupal. La técnica de los Grupos Focales es una reunión con modalidad de entrevista grupal abierta y estructurada, en donde se procura que un grupo de personas seleccionadas por el grupo de investigación discutan, elaboren, expresen su opinión sobre diferentes aspectos de interés, en un ambiente abierto para el libre intercambio de ideas, desde la experiencia personal, sobre una temática o hecho social, en este caso, el grupo evaluará el funcionamiento de la adaptación de 114

116 una nueva Plataforma, generando de esta manera a los investigadores, resultados confiables en poco tiempo, sobre la funcionalidad y usabilidad de la Plataforma. La definición de un Grupo Focal se hizo necesaria para la evaluación y testeo de la Plataforma, con el objetivo de poder retroalimentar al Grupo Investigador, y así aplicar los ajustes requeridos para el buen desempeño del sistema. Planificación del grupo focal Es necesario determinar el propósito de la actividad. Entre otras cosas se debe establecer la razón por la cual se va a llevar a cabo el estudio, a quienes les interesa la información, los tipos de información que son importantes, quiénes van a ser los usuarios de la información, determinar el tipo de información y la razón por lo que es requerida. Determinar la población a participar. Entre estos pueden ser los miembros de grupos específicos, consejos asesores, empleados, consumidores o clientes de algún producto o programa específico. Se espera que los participantes en un mismo grupo sean lo más homogéneos posibles y no se conozcan entre sí. Especificación del grupo focal definido para las Pruebas en un entorno real La Plataforma Urb@naLab fue adaptada por el Grupo de Investigación COMBA I+D de la Universidad Santiago de Cali, para el municipio de Guacari bajo el auspicio del Banco Interamericano de Desarrollo (BID), bajo la dirección de la Gobernación del Valle de Cauca en Colombia. Este escenario permitió desarrollar una segunda fase de pruebas bajo un entorno real, dando de esta manera una retroalimentación completa sobre todo el ciclo desarrollado en la Plataforma de Computación urbana para la cocreación de servicios. Las características del Grupo Focal utilizado para el testeo y evaluación de la Plataforma se detallan a continuación: Características del Grupo Focal Las característica a considerar sobre los miembros del Grupo 115

117 Focal para el correspondiente estudio fueron: Edad, Para la realización de esta fase de prueba en grupos focales, fue importante definir cuatro grupos organizados en cuatro rangos, de acuerdo a las edades de los participantes: o o o o Grupo 1: De 18 a 27 años. Grupo 2: De 28 a 37 años. Grupo 3: De 38 a 47 años. Grupo 4: De 48 a 57 años. Nota: Se consideró que el Grupo Focal estuviera constituido por 16 personas en su totalidad, los cuales para cada grupo por rango de edad lo conformaran por 4 personas. Perfil, Se estimó que el perfil de los participantes en el Grupo Focal fuera: o Nivel de escolaridad: Bachiller o Profesional. o Roles: Habitante de Guacarí, Miembro de la Gobernación, Investigador o Funcionario del BID (Banco Interamericano de Desarrollo). Evaluación La evaluación desarrollada con el Grupo Focal, tuvo como base los siguientes interrogantes a mencionar: o Qué tan bien pueden los usuarios finales utilizar la funcionalidad que la Plataforma ofrece? o Es Urb@naLab una plataforma fácil de utilizar? La prueba realizada por el Grupo Focal sobre la Plataforma Urb@naLab, estimó las siguientes categorías a considerar: o o o o o o Página de Inicio (elementos contenidos al ingresar a la Plataforma.) Orientación de tareas (diferentes pasos a seguir para realizar una tarea.) Navegación. Formularios. Confianza y Credibilidad (Contenido del Sitio.) Calidad Contenido. 116

118 o o o Diagramación y Diseño. Ayuda, Retroalimentación y Errores. Usabilidad (Utilidad, facilidad de uso, facilidad de aprendizaje, apreciación.) El tiempo de Evaluación de la Plataforma por parte del Grupo Focal se consideró entre 25 y 30 días. Resultados Se obtuvieron calificaciones de facilidad de uso, percepciones cualitativas y pruebas de integración. Etapas Las etapas desarrolladas durante la prueba fueron tres: o o o Definición de los objetivos. Documentación de errores. Chequeo de experiencias. D. Socialización con los Grupos Focales en un entorno real Dentro del Municipio de Guacari se desarrollaron pruebas de despliegue y evaluación de la Plataforma a través de dos grupos focales. 1. Descripción del Trabajo desarrollo con el Grupo Focal No. 1 del Municipio de Guacari. El 10 de mayo de 2012, se llevó a cabo la socialización del Proyecto Urb@naLab con el Primer Grupo Focal (conformado por habitantes de Guacarí, representantes de la Gobernación Valle del Cauca y la Alcaldía del municipio), además se brindó capacitación frente al uso de la Plataforma y se probaron funcionalidades de los componentes, para que el Grupo en el lapso de tiempo estipulado, evaluara la Plataforma de Urb@naLab y brindara al Equipo Investigador su colaboración y retroalimentación a través de los registros de sus pruebas. 117

119 Figura 1. Los Ingenieros Andrés Millán C. y Claudia Zúñiga C., socializan con el Grupo Focal - Guacarí el Proyecto Urb@naLab. Figura 2. Entrega de documentos físicos y capacitación para el Grupo Focal, acerca de sus registros de pruebas sobre la Plataforma Urb@naLab. A cargo de los Ingenieros Andrea Arteaga P. y Juan David Millán C. 118

120 Figura 3. Conformación del Primer Grupo Focal - Guacarí. Habitantes del Municipio, Grupo de Investigación COMBA I+D (Universidad Santiago de Cali), representantes de la Gobernación Valle del Cauca y la Alcaldía de Guacarí. 2. Descripción del Trabajo desarrollado con el Grupo Focal No. 1 y No. 2 del Municipio de Guacari El 11 de julio de 2012, se hizo la socialización sobre Urb@naLab con el Segundo Grupo Focal (conformado por 18 estudiantes, grado 11, cuyas edades se encuentran en promedio entre los 15 y 18 años, del Liceo Comercial San Juan Bautista - Guacarí), a quienes se les habló sobre el Proyecto en el que se está trabajando, por qué la Plataforma se estaba ejecutando en Guacarí, los servicios que hacen parte de la Plataforma, se dio la inducción a nivel con respecto al uso de Urb@naLab, el objetivo de ellos frente a las pruebas que iban hacer, la importancia del testeo, entre otros puntos, para que de esta manera pudieran retroalimentar al Equipo Investigador con los resultados que arrojen de esta prueba. 119

121 Figura 4. Miembros del Grupo de Investigación COMBA I+D de la Universidad Santiago de Cali, brindando orientación a los integrantes del Grupo Focal. Figura 5. Grupo Focal - Estudiantes del Liceo Comercial San Juan Bautista e integrantes del Grupo de Investigación COMBA I+D (Universidad Santiago de Cali). 120

122 E. Resultados obtenidos en la pruebas realizadas con los grupos focales en el entorno real (Municipio de Guacari) Con base a las pruebas diseñadas entregadas al grupo focal, se obtuvieron los resultados presentados a continuación. 1. Resultados del Ambiente de Prueba Navegador usado por los usuarios para la prueba Figura 6. Resultados acerca del navegador más utilizado por el Grupo Focal para esta prueba. Navegador que se usaron los usuarios para la prueba 13 5 Chrome No Respondieron Sistema Operativo usado por los usuarios para la prueba Figura 7. Resultados acerca de los Sistemas Operativos más usados por el Grupo Focal. Sistemas Operativos utilizados durante la prueba Windows XP Windows 7 No Respondieron 121

123 2. Resultados Obtenidos por Errores del Sistema La apreciación por parte del Grupo Focal - Guacarí, sobre los inconvenientes encontrados durante el testeo de la Plataforma Urb@naLab, se podrán observar a continuación: Componentes donde a los usuarios se les presentaron errores durante la prueba Figura 8. Errores en los componentes de amigos, registro sin Facebook, página de inicio y síguenos. 2 1,8 2 1,6 1,4 1,2 0,8 1 0,6 0,4 0, No recibe comentarios en el muro Registro difícil No regresa a Inicio El contenido cambia de lugar Errores encontrados en el Módulo de Perfil durante las pruebas realizadas con el grupo focal. Figura 9. Errores en el Módulo de perfil. Módulo de Perfil 1 2 No se pudo subir la foto Ingresó a un Sitio distinto de Perfil 122

124 Errores presentados en el Chat durante el testeo. Figura 10. Errores en el Componente Chat. Componente de Chat 2 Mensaje no recibido 1 5 No permitió ingresar usuario Dificultades para chatear 3. Evaluación de usabilidad de la plataforma Con respecto a la Evaluación de Usabilidad de la Plataforma, proporcionado por el Grupo de Investigación COMBA I+D (Universidad Santiago de Cali) para la realización de las pruebas sobre la Plataforma Urb@naLab, se obtuvieron resultados correspondientes a cinco temas: Tema 1: Página de Inicio 1. La página de inicio tiene una dirección Web fácil de recordar? (en algunas ocasiones la dirección Web comienza por o va el nombre solo). 2. Con sólo un vistazo a la página de inicio, el usuario que ingresa por primera vez puede entender por dónde comenzar? 3. Todos los elementos de la página de inicio están claramente enfocados en las tareas claves de los usuarios? 4. Existe contenido de utilidad en la página de inicio o a un clic de distancia de la página incial? 5. Las áreas de navegación en la página de inicio sufren de un abuso de formato / diseño? 6. La página de inicio contiene información gráfica con sentido? 7. Toda la información corporativa está bien agrupada en una sola área por aparte? (Ejemplo: "Acerca de"). 123

125 Figura 11. Resultados sobre las opiniones con respecto a la página de inicio de la Plataforma Urb@naLab Sí No No Responde Tema 2: Orientación de Tareas 1. El sitio está libre de información irrelevante, innecesaria y distractora? 2. Puede usted completar rápidamente tareas comunes? 3. El sitio hace que la experiencia del usuario sea más fácil y rápida que si no tuviera la aplicación? 4. Cuando existen múltiples pasos en una tarea, el sitio muestra todos los pasos que deben ser completados y provee una retroalimentación al usuario, indicándole la posición actual en toda la ruta de la tarea? 5. Un usuario típico que visita por primera vez la aplicación, puede llevar a cabo la mayoría de las tareas sin necesidad de asistencia? 6. Cuando usted retorna al Sitio, recuerda cómo llevar a cabo las tareas clave? 7. El Sitio soporta a los usuarios novatos y expertos, brindando niveles de explicación? Ejemplo: en páginas de ayuda y mensajes de error. 124

126 Figura 12. Resultados sobre las opiniones con respecto a la página de inicio de la Plataforma Urb@naLab Sí No No Responde Tema 3: Navegación 1. Existe una manera obvia y conveniente para moverse entre las páginas relacionadas y secciones, es fácil retornar a la página del inicio? 2. La información que más necesita usted, es fácil de navegar en la mayoría de las páginas? 3. Las pestañas de navegación, están localizadas en la parte superior de la página y se ven como versiones "clickeables? 4. Si el sitio abre nuevas ventanas, éstas lo confunden a usted? Ejemplo: pueden ser perfectamente cerradas. 125

127 Figura 13. Resultados sobre las opiniones con respecto a la navegación de la Plataforma Pregunta 1 Pregunta 2 Pregunta 3 Pregunta 4 Sí No No Responde Tema 4: Formularios 1. Las cajas de texto indican el formato de los datos que deben ser introducidos? 2. Puede usted cambiar los valores predeterminados en los campos de los formularios? 3. Los campos en los formularios contienen ayudas, ejemplos o modelos de respuestas para demostrar el dato que se debe introducir? 4. Los formularios son validados cuando la información es enviada? Figura 14. Resultados sobre las opiniones con respecto a los formularios de la Plataforma Sí No 126

128 Pregunta 1 Pregunta 2 Pregunta 3 Pregunta 4 Pregunta 5 Tema 5: Calidad Contenido 1. El Sitio tiene contenido atractivo? 2. Las páginas son rápidas de examinar, con títulos grandes, subtítulos y párrafos cortos? 3. El Sitio evita los títulos con lenguaje difícil de entender? 4. Los títulos y subtítulos son cortos, fáciles, sencillos y descriptivos? 5. Las palabras, frases y conceptos utilizados son familiares para cualquier usuario convencional? Figura 15. Resultados sobre las opiniones con respecto a la calidad contenido de la Plataforma Sí No No Responde F. Conclusiones La evaluación de la Plataforma Urb@nalab fue realizada en dos ámbitos, un primer ámbito de entorno controlado y un segundo ámbito de entorno real. Las pruebas se definieron bajo métricas que permitieran aplicar Pruebas Funcionales, Pruebas de Usabilidad, Revisión de Estructura Interna y Revisión de Diseño, a través de todo el ciclo de desarrollo para obtener Funcionamiento, Funcionalidad y Usabilidad de la Plataforma desarrollada. Las pruebas en entornos controlados fueron ejecutadas con un grupo focal conformado por miembros de la comunidad académica de la Universidad Santiago de Cali (Profesores, estudiantes e 127