SG Software Guru #45 by Revista Software Guru

Gestión de procesos Pag. 38

DevOps Pag. 40

Pagos Móviles Pag. 42

No.

TUTORIAL

Desarrolla con Kinect v2

ESPECIAL

CONOCIMIENTO EN PRÁCTICA www.sg.com.mx

LA ERA DE LAS

APIS

TESTING

TENDENCIAS Y PRÁCTICAS

www.sg.com.mx |

Software Guru

CONOCIMIENTO EN PRÁCTICA

.CONTENIDO

Agosto - Octubre 2014 | www.sg.com.mx

Pág.

26 En Portada Tendencias en Testing

Cuando se quiere mejorar la calidad del producto final de software, mejorar la rentabilidad de producción del mismo y reducir los costos en mantenimiento es inevitable no hacer una estrategia de testing. Esta disciplina ha evolucionado, ya no es solo una fase o una serie de prácticas opcionales. En esta sección encontrarás contenidos que te servirán si estás trabajando en una estrategia de fortalecimiento de testing para tus proyectos.

.CONTENIDO

Especial APIs 18 Las APIs son engranes muy importantes en el mundo del software y por ello es vital comprender su funcionamiento. Estos engranes están siendo referenciados como el futuro de muchos negocios en línea. Conoce más de este tema en esta sección especial que tenemos para ti.

Emprendiendo ¿Por qué todos en tu Startup deberían contestar Correos de Soporte? 11 Por Celeste North

Pág.

Prácticas Calidad

Por Ana Vazquez

Gestión 38

Reseña

Por Pilar Barrio, Rodrigo Guzmán y Raúl Martínez

SGCE 2014 06

Lo que viene 12 Docker 17

Columnas

Tutorial Desarrolla apps con Kinect SDK v2 14

Por Hanna Oktaba

Por Laura Frías Carrillo

Mejora continua

Personas

Por Pedro Solares

Por Luis Cuellar

Carrera 48 Tendencias en Software Por Luis Daniel Soto

Tecno-lógico

Tecnología

Por Mauricio Angulo

Diagnóstico Físico Utilizando Google Glass y Machine Learning

Columnas invitadas: DevOps ¿Qué es? 40

Por Jair A. Serrano, Lainy C. Regalado, Victor F. Villa,

y Germán H. Alférez

Por Ismael Villegas

Análisis de la Situación Actual de los Pagos Móviles, desde la Perspectiva de un Usuario de la Banca

En Cada Número 42

Por Sergio Bolaños

Implantando Big Data 44 Por Victor Pichardo

Editorial 04 Noticias 05 SG Perfiles 52 Gadgets 54 Biblioteca 56

www.sg.com.mx |

Tejiendo nuestra red 08

Software Guru

Herramientas y Novedades

.EDITORIAL Bienvenida

“Nuevos modelos de negocio, nuevas formas de interactuar con los clientes y consumidores”.

. Transformación digital

a incorporación de nuevos procesos, razonamientos y tecnologías que hacen más eficientes a los negocios es parte de las oportunidades que está trayendo la transformación digital. Durante las pasadas ediciones hemos ya hablado sobre elementos de la transformación digital, en esta edición encontrarás un elemento más: Las API’s. Empresas de diferentes industrias están contribuyendo en el crecimiento del mercado de las API’s debido a que ofrecen ventajas competitivas muy importantes. Si se establecen estrategias de API’s y se llevan a cabo correctamente favorecen en la creación de nuevos modelos de negocio, nuevas formas de interactuar con los clientes y consumidores. Como tema principal encontrarás las tendencias del testing, que responden a los retos que están dictando la movilidad, el cloud y la profesionalización de las funciones que los roles dedicados al testing han logrado gracias a la necesidad de este rol en nuestra industria. Al preparar esta edición, tuvimos la motivación de nuestro pasado congreso, el 8vo de la era de SG. El estar cerca de nuestros lectores, colaboradores y seguidores de esa manera, nos da mucha energía para continuar contribuyendo a seguir cambiando la cara del desarrollo de software en nuestra región.

››Equipo Editorial SOFTWARE GURU

DIRECTORIO SG Dirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Vanessa Amaya / Arte y Diseño Oscar Sámano / Suscripciones Patricia Moreno Consejo Editorial Jorge Valdés - PMI / Luis Cuéllar - Softtek / Luis D. Soto - Microsoft / Hanna Oktaba - UNAM / Emilio Osorio - Sistemas Humanos / Luis Vinicio León - e-Quallity / Gloria Quintanilla

Colaboradores

Ana Vazquez, Angel G. Terrera, Berenice Ruiz Eguino, Celeste North, Francisco Jiménez Hernández, Germán H. Alférez, Gunnar Wolf, Gustavo Alzate Sandoval, Humberto Cervantes, Ismael Villegas, Jair A. Serrano, Javier Garzás, Jorge Alberto Jiménez Sandoval, Lainy C. Regalado, Laura Frías Carrillo, Ma. Ángeles Morales, Masa K Maeda, Mauricio Angulo, Noemí Navarro, Pedro Solares, Pilar Barrio, Raúl Martínez, Rodrigo Guzmán, Sergio Bolaños, Victor F. Villa y Victor Pichardo

Ventas Claudia Perea / Ventas y Delivery Yoloxochitl Juárez / Marketing y Alianzas Fernando Hernández / SGCampus Vanessa Amaya y Ariel García Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., San Francisco 238 Altos. Col. Del Valle. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 2.5 México. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: En trámite. ISSN: 1870-0888. Registro Postal: PP15-5106. Distribuido por Sepomex.

.NOTICIAS

.Mobile Camp México 2014

El pasado 15 de agosto, más de 200 entusiastas del desarrollo móvil de México se reunieron en las instalaciones de Microsoft para hablar del estado que la movilidad guarda en nuestro país, así como también abordar panoramas técnicos de gran interés como la programación de iOS con Swift, Android con NDK, Realidad aumentada con Vuforia y Windows 8.

.EMC Forum

Con visitantes de distintas ciudades como León, Puebla, Hermosillo, Toluca, Guadalajara, Cancún así como ponentes de EEUU y de España, se llevó a cabo el #JdayMX14 en la Ciudad de México. Dicho evento fue organizado por el Grupo de Usuarios Joomla Ciudad de México. Destacó que incluso ofrecieron charlas usuarios de Drupal y Wordpress, por lo que fue un excelente punto de reunión para que todos los interesados en los sistemas de gestión de contenido (CMS) compartieran conocimiento e hicieran nuevos nexos profesionales.

.Barcamp Cancún 2014 .Agile Open México

El 9 de agosto se llevó a cabo el Agile Open México en las instalaciones del Instituto Tecnológico Autónomo de México. Este evento tuvo un formato de conferencia o reunión abierta, donde la agenda fue generada de manera dinámica entre todos los asistentes. Grandes mentes se unieron haciendo un círculo de sillas para hacer sesiones de trabajo muy interesantes. Este evento fue organizado por Logical Bricks Solutions, Scrum México, ITAM, Segunda Mano y Kleer.

El 31 de Julio, en Cancún, se llevó a cabo el evento Barcamp organizada por la comunidad GDG Cancún con el objetivo de aprender, compartir experiencias e innovaciones relacionadas con las tecnologías de Google. Durante el evento se presentaron conferencias relacionadas a temas como derechos de autor del desarrollador, IOT con Arduino, economías colaborativas, nube personal, social media, e interfaces reactivas, entre otros.

Para mayor información, noticias al día y actualizaciones de la industria visita: www.sg.com.mx

Software Guru

.Joomla Day

www.sg.com.mx |

Con el objetivo de invitar a redefinir TI, el pasado 7 de agosto EMC llevó a cabo el “EMC Forum 2014” en las instalaciones de Centro Banamex a donde acudieron ejecutivos de áreas de TI interesados en definir sus empresas por software. Patricia Florissi, Vicepresidente y CTO de EMC Americas, con un gran entusiasmo hizo ver a los asistentes la gran transformación de la que estamos siendo parte a través de la llegada e interacción del Internet de las cosas, las redes sociales, la movilidad, el cómputo en la nube y el Big Data; y para adoptar dicha transformación de forma correcta debemos cubrir cada una de las anteriores dimensiones.

.RESEÑA

CIE TO N NDO H U J ISTORIA

SGCE 2014

¡Te esperamos en nuestro próximo congreso!

www.sg.com.mx |

l 25 y 26 de junio se realizó la edición 2014 de SG Conference & Expo, en el marco de cual celebramos el 10mo aniversario de Software Guru. Durante dos días, los participantes presenciaron conferencias y talleres relacionados a tendencias y mejores prácticas para construir software. Destacó la participación de conferencistas nuevos y conocidos para la audiencia de SG tales como Philippe Kruchten, Crista Lopes, Álvaro Videla, Emilio Osorio, Gunnar Wolf, Norberto Ortigoza y Víctor González, entre otros. Nuestra mejor forma de celebrar fue continuar haciendo lo que en una década nos ha distinguido: motivar a una gran comunidad de desarrolladores de software a aprender cómo construir software grandioso y destacarse en nuestra industria a través de conocimientos con enfoque práctico, neutralidad y diversidad. Durante el cocktail del evento, aprovechamos para celebrar con los asistentes los 10 años de existencia de Software Guru, y contamos con la presencia de colaboradores y empresas que han crecido junto con SG en ésta década. Agradecemos a los patrocinadores que participaron en este congreso tan especial: ABIZTAR, Activ, CA Technologies, DSIndigo, e-Quallity, Infotec, Ingressio, KIO Networks, Mexico First, MicroFocus, Oracle, Qualtop, SEAN y Spingere. Damos las gracias también a las comunidades y asociaciones que apoyaron en la difusión de este evento: AMITI, Adictivox, Código Ambar, Csoft Monterrey, Ideadores, Java México y WebAdictos.

Software Guru

.COLUMNA Tejiendo Nuestra Red

De Chile y de Manteca ESSENCE 1.0 con KUALI-BEH

En mayo de 2014 fue publicado por OMG el nuevo estándar ESSENCE 1.0, cuyo anexo B contiene una extensión del núcleo de ESSENCE llamada KUALI-BEH, desarrollada orgullosamente en México. Ya es el segundo estándar intenacional, después de ISO/IEC 29110, dónde pusimos nuestro granito de arena apoyados, entre otros, por Software Guru. El documento de ESSENCE 1.0 está disponible en para su descarga [1] en versión Beta2, que espera en la fila de estándares para la última “manita de gato” de los editores técnicos de OMG, pero ya no cambiará su contenido. Les debo un artículo sobre ESSENCE y su uso en la vida diaria de los proyectos de software, que puede ser de mucha utilidad. Mientras tanto pueden buscar el libro The Essence of Software Engineering, Applying the SEMAT Kernel, de Ivar Jacobson y sus colegas.

Imagen 1. Sydney, Australia

actualizados, se pondrán a la revisión por los países miembros como un nuevo perfil de 29110 llamado Organizational Management. Además, nos comprometimos a trabajar en los llamados grupos de estudio para atacar el problema de estándar de servicios de TI para las VSEs y la interpretación con métodos ágiles del Basic profile para software. Como ven esto no tiene fin. La verdad necesitamos más manos de obra calificada para abarcar todos los temas que están surgiendo.

Reunión plenaria de ISO/IEC JTC1 SC7 en Sydney, Australia Los trabajos sobre el estándar ISO/IEC 29110 no terminan. En la reunión plenaria en la bonita ciudad de Sydney (Ver Imagen 1) tuvimos la oportunidad de percatarnos de como la idea, que surgió en México hace12 años con MoProSoft, de enfocar el modelo de procesos a pequeñas empresas, adquiere mucha importancia internacional.

›› “Necesitamos más manos de obra calificada para abarcar todos los temas que están surgiendo”.

Evento SG

29110 Basic.

Por un lado, se nos sumaron al WG24, que trabaja el estándar 29110, los nuevos representantes de la India, Corea del Sur y Sud África. Fuimos el grupo más numeroso de todos los grupos de trabajo de SC7. Preguntando a Gargi Keeni, la consultora de nada menos que TCS (Tata Consultancy Services), porqué tanto interés en VSEs (Very Small Entities), me contestó lo siguiente: aunque TCS es una empresa grande, la mayoría de los proyectos se hacen por equipos pequeños, por eso queremos entender la propuesta que han hecho para VSEs. Por otro lado Japón ha publicado una guía para facilitar la adopción de ISO/IEC 29110 Basic profile a sus empresas (Ver ImaLa Dra. Hanna Oktaba es profegen 2). Ni hablar de Brasil que tiene un programa muy sora de la UNAM y su objetivo prinagresivo de adopción de ese estándar con el apoyo de cipal es generar fondos gubernamentales y de Microsoft. Su modelo de conocimiento a través de la creaevaluaciones está basado en las auditorías tipo ISO 9000 ción y promoción de estándares. con un reconocimiento internacional. hanna.oktaba@ Como Delegación Mexicana logramos que los procesos ciencias.unam.mx de MoProSoft de la capa de Gerencia y de la Alta Dirección, 08

No puedo terminar esta columna sin agradecer nuevamente a SG por permitirme disfrutar SG Confernce&Expo en junio pasado. Me reencontré con algunos colegas y exalumnos, aprendí cosas nuevas como el manifiesto del artesano de software y me decepcioné del SWIFT como “nuevo” lenguaje de programación, que no es otra cosa que una mezcla de conceptos conocidos desde Simula-67 y Smalltalk 80. Pero lo más importante para mí fue notar la competencia y el entusiasmo de los expositores, la excelente organización del evento y una sensación de comunidad unida gracias a la gran labor de Mara y Pedro, los fundadores de SG.

Imagen 2. Publicación de la guía ISO/IEC

Muchas felicidades por los 10 años y que sigan muchos más. >> Por Hanna Oktaba

Referencias [1] Documento de ESSENCE 1.0 http://www.omg.org/spec/ Essence/Current

www.sg.com.mx |

Software Guru

.COLUMNA Mejora Continua

Modelos de Calidad

l artículo anterior en SG44 dialogábamos sobre productos y servicios, sobre cómo cada día los servicios se están volviendo los verdaderos diferenciadores de una propuesta de valor, conjuntando la ingeniería de software con la ingeniería de servicios. Dentro de este nuevo mundo, ¿qué rol juegan los modelos de calidad? ¿Por qué dichos modelos se han vuelto los principales medidores de un buen servicio? Muchas veces escucho tanto a desarrolladores de software como a los mismos clientes cuestionar exactamente ¿qué me da un modelo de calidad?, ¿por qué es tan importante que la empresa con la que trabajo esté acreditada en algún modelo? ¿Cuál es el mejor modelo? ¿Que lo hace tan bueno? La realidad es que, desde mi punto de vista, y con riesgo a que ya no me inviten a los brindis de navidad, todos los modelos de calidad, bien implementados, generan valor; el secreto está en implementar estos modelos correctamente. Yendo más lejos, con algunas salvedades la mayoría de los modelos tienen mucho más similitudes que diferencias. Algunos modelos son más genéricos y otros más específicos, algunos modelos son descriptivos lo cual los hace más fáciles de implementar y de auditar, otros son más normativos, lo cual los hace más flexibles y susceptibles a interpretación. Cada modelo de calidad tiene sus ventajas y desventajas, algunas de ellas dirigidas al cliente, otras dirigidas al implantador y otras tantas dirigidas a ambos. Al final de cuentas, los objetivos principales de cualquier modelo de calidad se enfocan a asegurar un servicio estable, eficiente, de calidad y mejorable a través del tiempo. Esto normalmente lo logran a través de los siguientes principios: 1) El servicio se debe de basar en procesos repetibles. Todos los modelos de calidad buscan definir un proceso estándar, este proceso puede ser previamente definido dentro del mismo modelo o el modelo puede simplemente generar las reglas para crearlo. Este proceso debe de incluir la mayor cantidad de planeación en cuanto al futuro, buscando democratizar el conocimiento sobre cómo se resuelve un problema específico, para volver escalable la resolución de problemas y establecer bases para poder aprender realmente de nuestros errores y validar los supuesto que hacemos en cada proyecto

Luis R. Cuellar es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Software Engineer y Six Sigma Black Belt. @lcuellar

2) Planeación, estimación y seguimiento. Todos los modelos de calidad piden algún tipo de planeación: el ciclo de vida puede ser iterativo o en cascada; puede ser un servicio basado en requerimientos en dónde sólo planeamos como atacar cada requerimiento o por entregables en donde tengo que planear cada fase y cada entregable; la planeación puede abarcar desde una plantación de los entregarles, hasta una planeación de cómo integrar nuevos miembros al equipo de trabajo. En el todo de la solución, la estimación realmente es poco importante es una lista de supuestos que hago en base a estadísticas pasadas, la parte realmente crítica es el segui-

›› “cualquier modelo, bien implementado, genera valor”. miento del proyecto, el cual se asegura a través de continuamente verificar los supuestos, calcular riesgos y resolver issues asegurándose que la ejecución se asemeje a lo estimado y que asimilemos nuevas variables que se requieren contemplar en el futuro. 3) Todo modelo de calidad establece métricas específicas para tanto la calidad del producto, como el logro de los objetivos del servicio. Algunos modelos de calidad definen procesos específicos de cómo se debe definir estas métricas y otros definen las métricas básicas que se deben utilizar. El primer objetivo de las métricas es correctivo para ajustar la planeación y sus supuestos. El segundo objetivo es establecer un modelo de aprendizaje con el que se puede aprender a mediano largo plazo cómo mejorar el servicio a través de análisis estadísticos y modelos de simulación. 4) Los modelos de calidad no definen cómo generar una solución. Esta labor es muy dependiente de las características específicas de servicio. La ingeniería de software se preocupa por asegurar que resolvamos correctamente el problema correcto. Lo único que algunos modelos de calidad trabajan son procesos para asegurar que se resolvieron todas las necesidades acordadas con el cliente. Eso se lleva a cabo mediante algún tipo de seguimiento a los requerimientos, mientras pasan a través de diferentes fases de la preparación del producto tratando de dejar una liga clara de cómo los requerimientos iniciales concluyeron con los resultados finales. 5) Algunos modelos de calidad cubren elementos considerados de apoyo a la operación. ¿cómo es la estrategia y ejecución de entrenamiento continuo?, ¿la administración del conocimiento?, ¿la sustentabilidad del negocio y su aportación a la sociedad? El alcance de algunos modelos es más amplio. Por ejemplo, algunos cubren elementos de seguridad de información, conceptos legales o laborales que afectan al proyecto, dando diferentes énfasis a cada elemento dependiendo del enfoque y el tipo de servicios que busca apoyar. Estas reglas aplican a la mayoría de los modelos de calidad, y son la base para establecer una estructura de software orientada al servicio, la mayoría de las empresas que están certificadas en algún modelo de calidad pueden dar respuesta a estas inquietudes. Estos modelos son la pauta para asegurar que el servicio que estamos dando es de calidad, consistente a través del tiempo y que se revisa continuamente para buscar hacer el servicio cada vez mejor. Los modelos de calidad son la base para establecer un modelo de servicio de software.

>> Por Luis Cuellar

.EMPRESAS

Emprendiendo

“Si el usuario tuvo un problema con la aplicación por un bug

¿Qué le decimos?”.

¿Por qué Todos en tu Startup Deberían Contestar Correos de Soporte?

Organiza a tu equipo

Aunque no todos tengan la habilidad de contestar y resolver los problemas, una buena práctica es tener un sistema para monitorear los mensajes y el seguimiento que se le da a los mismos. Esto puede ser algo tan sencillo como utilizar etiquetas de Gmail y contar con un correo grupal al que se copian los mensajes al momento de contestar (para que todos sepan que el tema se está atendiendo) o tan complicado como utilizar un sistema más avanzado de seguimiento de correos de soporte como Zendesk o Support Bee. Una vez que definan cuál será el procedimiento para recibir y contestar los correos, lo mejor es generar un documento que contenga

información sobre cómo contestar por cada tipo de casos. Este documento irá creciendo y cambiando a la vez que lo hace tu startup pero será el referente para que personas nuevas sepan cómo actuar y para tener un procedimiento claro que evite que las decisiones de cómo proceder a ciertos casos estén en manos de la persona que contesta. Este documento puede contener por ejemplo los criterios para reembolsos ¿En qué casos se hace un reembolso parcial o total? ¿Cómo se debe contestar al cliente si no es posible reembolsarle? Si el usuario tuvo un problema con la aplicación por un bug ¿Qué le decimos? Sobra decir que este documento deberá ser actualizado constantemente de acuerdo a los problemas nuevos que se presenten o cambios en el funcionamiento de tu plataforma.

Identifica los puntos de frustración más comunes

Tú conoces tu plataforma de arriba para abajo, conoces perfectamente a donde te lleva (o debería llevarte) cada click y la ves todos los días a toda hora. Las primeras veces que lees sobre la frustración de tus usuarios es fácil pensar que no le entienden o que no son tu tipo de cliente y que por lo tanto el problema son ellos. Este es un gravísimo error. Si un futuro cliente no entiende cómo funciona lo que le estás vendiendo, no podrá jamás ver el valor que estás tratando de darles pero entenderlo no es responsabilidad de ellos. Piensa en todas las veces que has sentido frustración por una forma de registro que no funciona bien o una página en la que no encuentras el botón que necesitas. Además, un cliente que se enoja con tu servicio y en lugar de descartarlo por completo, decide enviarte un mensaje, puede ser un futuro fiel usuario. El paso de uno a otro puede recaer casi enteramente a que alguien le conteste en tiempo y forma además de solucionar su problema. Aprovecha la oportunidad de entender mejor a tus clientes y de mejorar las áreas de tu producto o servicio que están alejando a tus clientes, ellos serán más honestos que tus amigos sobre las cosas que hay que cambiar en tu plataforma o aplicación. .BIO

Celeste North es Country Manager de MUBI México, plataforma de Video on Demand de cine de arte, clásico y de culto. Activa participante del ecosistema de startups en México, anteriormente fue fundadora de NuFlick y participó en Mexican.VC y Startup Chile. Encuentrala en Twitter como @celestenorth

www.sg.com.mx |

ntre la gran cantidad de cosas que tienes que hacer cuando estás en un startup, especialmente al principio cuando el equipo es muy pequeño, es contestar a todos esos valiosos clientes que experimentan frustración, confusión y enojo con tu producto o servicio. Sin embargo, al inicio nunca está muy bien definido quién se encarga de hacerlo. Si le toca a la persona técnica porque es un problema con la plataforma o si le toca al de negocios porque es un problema de que no se entendió el producto/servicio, etcétera. En mi camino por distintos proyectos he notado que siempre se busca un responsable que se encargue de ello mientras el resto del equipo se encarga de sus distintas áreas. Y cuando una persona nueva entra al equipo, nunca le toca colaborar contestando correos de soporte. Hacer esto es desperdiciar una enorme oportunidad de aprendizaje; nada te hará entender mejor cuáles son las áreas de tu producto o servicio que se tienen que mejorar si no escuchas lo que tus clientes tienen que decir. Se nos olvida que una mala experiencia con nuestra plataforma o aplicación puede generar no solo malos momentos a nuestros clientes, sino toda una serie de malas recomendaciones al grado de que ya nadie quiera intentar usar tu servicio porque todos le han dicho que no funciona. Esto se puede prevenir si entendemos mejor cuáles son los puntos donde estamos fallando y las áreas de mayor frustración para nuestros usuarios.

Software Guru

›› Por Celeste North

.HERRAMIENTAS Y TECNOLOGÍAS Lo Que Viene

Yeoman es una herramienta para generar esqueletos de nuevas aplicaciones y acelerar así su desarrollo. La novedad de Yeoman es que es extensible y cualquiera puede colaborar con nuevos tipos de generadores. Actualmente hay generadores para una gran de tecnologías, incluyendo algunas de las más populares como: • Angular, Backbone, Cordova, Node y Ember. • El workflow de Yeoman está compuesto por tres tipos de herramientas: • La herramienta para generación de esqueletos (se llama “yo”). • Un sistema de construcción (build automation) como Grunt. • Un gestor de paquetes como npm o Bower. http://yeoman.io

Realm: Base de datos móvil

Realm es una base de datos para aplicaciones móviles. Se define a sí misma como un reemplazo para Core Data y SQLite. Realm tiene un API simple de usar, ofrece un desempeño rápido y puede soportar estructuras de datos complejas. Incorpora capacidades como lazy loading y multithreading. Realm actualmente está disponible para iOS y OSX. Se espera que pronto también liberen la versión para Android. http://realm.io

Appium es una herramienta para automatización de pruebas de aplicaciones móviles. Es open source, cross platform y se puede utilizar para probar tanto apps móviles nativas como web e híbridas. Con appium puedes probar apps para iOS, Android y FirefoxOS. Appium viene a ser algo así como una versión de Selenium para apps móviles. De hecho, utiliza WebDriver, el protocolo de Selenium. Una de las ventajas de Appium respecto a otras herramientas para testing de apps, es que no requiere recompilar la app, ya que recurre al framework de automatización de UI de cada plataforma (UIAutomation en iOS y UIAutomator en Android). Otra ventaja es que puedes escribir tus pruebas en cualquiera de los lenguajes soportados por WebDriver como Python, Java, PHP, C# o Ruby, entre otros. http://appium.io

Apache Spark: Cómputo de alto desempeño

Yeoman: Scaffolding de apps

Appium: Mobile app testing

Hace tiempo que no mencionamos en esta sección ningún proyecto de la fundación Apache. Posiblemente su proyecto “estrella” (y no lo decimos solo por el logo) actualmente es Spark. Spark es un motor para procesamiento de datos distribuido de alta velocidad. Spark se basa en el sistema de archivos de Hadoop (HDFS), pero no está atado al paradigma MapReduce, y de hecho promete un desempeño entre 10 y 100 veces más rápido que MapReduce. Spark provee primitivas para cómputo en-memoria en cluster, lo cual lo hace buen candidato para procesar algoritmos de aprendizaje automático (machine learning). http://spark.apache.org

.COLUMNA

Tendencias

en software

Productos en Permanente Mejora

Del juego al negocio

La aplicación de los conceptos de “aprendizaje de máquina” que he descrito aplica no solo a entretenimiento, sino a la realidad de casi cualquier negocio: 13

Para las grandes empresas, optimizar un proceso en un 0.001% significará generar millones incrementales de venta o ahorros. Dichos modelos no son triviales, requieren de alto poder de cómputo y semanas de experimentar con modelos. Un sistema en producción se puede implantar también en semanas o meses y va a requerir correcciones continuas. Esta capacidad es ahora viable, pero aún es una combinación de “arte” y ciencia que requiere, no de un individuo, sino de un equipo que combine conocimientos de programación, manipulación y modelado de datos, estadística, conocimiento de negocios y por supuesto de visualización y comunicación efectiva. Para darse una idea de las formas en que los diferentes equipos resuelven problemas similares a los descritos los invito a que visiten http://kaggle.com En un reciente concurso público por crear un modelo para predecir el valor de reventa de autos, decenas de equipos de “científicos de datos” utilizaron todo tipo de parámetros y algoritmos para identificar autos que generarían mayores utilidades. El ganador produjo el mejor “modelo de elevación” en predicciones; su modelo se basaba en tan solo un elemento de información: si el color del vehículo era no estándar, era altamente probable que los dueños lo cuidaran y mantuvieran mucho mejor, reduciendo el riesgo de adquirir autos seminuevos defectuosos. Si contara con instrumentación similar a la descrita, conocería mejor a mis lectores, sus intereses, el futuro del consumo y aplicación de mis artículos. Mientras llegamos me conformo de saber que nuestro entorno se preparará a anticipar nuestros actos. Luis Daniel Soto Maldonado Habilitemos la era de la inteligencia (@luisdans) labora en la división de prescriptiva y productos que se adaptan en negocio de servidores y herramiencada instante. tas de Microsoft Corp.

>> Por Luis Daniel Soto Maldonado

Software Guru

• Pronóstico. ¿Qué clientes van a dejar de pagar un crédito? ¿Cuántos bienes se van a vender? ¿Cuánto voy a vender? ¿Cuál será la temperatura en un edificio dentro de 2 horas? • Detección de anomalías. Predecir cuándo el acceso a un servidor por cierto rol se sale de la norma o cuando el comportamiento de la granja de servidores cambia. Fraudes con pago de tarjeta de crédito, fugas de información, etcétera. • Optimización. ¿Cuál es la mejor forma de efectuar cientos de envíos? Optimizar la inversión de mercadotecnia digital con el precio de subasta de cientos de palabras clave para la mayor conversión. Predecir los ingresos con monedas internacionales de diversos mercados.

www.sg.com.mx |

unque todavía se debate cuándo apareció el primer juego electrónico, la era de las “maquinitas” operadas con moneda inició en 1972. A lo largo de cuatro décadas hemos vivido una permanente era de innovación. Durante este mismo periodo, hemos planeado el futuro de los videojuegos utilizando técnicas de limitado alcance; literalmente, hemos diseñado con los ojos cerrados. Las cosas están cambiando. Por ejemplo, hoy es posible predecir en tan solo 3 días el riesgo de que el cliente de un nuevo videojuego en línea abandone el servicio. Identificar a los jugadores que pueden dejar de jugar permite tomar acciones para prevenir el abandono. Mantener a los clientes activos en el sistema significa mayores ingresos y utilidades. Significa también menos copias vendidas en el mercado de productos usados. Por ejemplo, el videojuego Halo recolecta información estadística de las sesiones de juego. Los datos adquiridos contienen detalle de la interacción, desempeño y aspectos sociales de los jugadores. De estos datos se producen 150 “características” que describen el comportamiento y experiencia del usuario. Ejemplos de estos son: segundos jugados, puntos acumulados, número de juegos con otras personas, número de juegos con un mismo amigo, etcétera. Con base en el uso de estas grandes cantidades de información, el aprendizaje de máquina es capaz de “descubrir el secreto” detrás de posible uso del sistema, con una muy alta probabilidad. Si el usuario no abandonó la experiencia, los siguientes 7 días crearán un perfil más detallado y será posible conocerlo mejor y en más facetas. Además de conocer con 90% de certeza lo que sucederá, el análisis de máquina permite identificar errores en el juego, cambios de comportamiento (cheats), dificultad de los niveles y preferencias de diversos tipos. En el pasado, cambiar un juego llevaría posiblemente meses o años, hoy es posible cambiar el juego en cuestión de horas, crear nuevas áreas en base a preferencias efímeras. De hecho, el motor de gamification que Microsoft utiliza es totalmente independiente al código del juego; éste puede ser editado en tiempo real sin ningún programador. El juego emite “eventos” como un gol o un zombi eliminado. Un conjunto de eventos puede “desbloquear” reconocimientos, de hecho éstas se podrán asociar a zonas geográficas, husos horarios, etcétera. Con lo anterior un analista es capaz de crear nuevos retos y colocarlos a escala global en minutos. En resumen, la era de operar “sin” instrumentos terminó. En el futuro tendremos mucho más sistemas de observación, de captar el comportamiento real y con ello tendremos el poder de actuar antes de que los eventos sucedan y de adaptar los productos como nunca antes.

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

DESARROLLA APPS CON

KINECT SDK V2 ›› Por Laura Frías Carrillo

uando se popularizaron las computadoras personales hace cerca de 30 años, el teclado y el ratón se convirtieron en objetos cotidianos para poder trabajar con procesadores de texto, hojas de cálculo y juegos de escritorio. Con la aparición de dispositivos touch como smartphones, tabletas y computadoras el uso de esta tecnología se volvió más natural e intuitiva, sólo basta observar cómo niños y adultos son capaces de utilizarlos sin esfuerzo. Las interfaces naturales de usuario están cambiando la manera en que interactuamos con los dispositivos de cómputo. Las interfaces naturales de usuario (natural user interfaces, NUI) son aquellas que permiten interactuar con un sistema o aplicación sin necesidad de utilizar dispositivos intermedios —como serían un ratón, teclado, lápiz óptico o touchpad. Es decir que interactuamos con el dispositivo de la misma manera que lo hacemos con otros humanos —mediante la voz y movimientos corporales.

Kinect: Innovando las NUI

Kinect ha sido parte de esta revolución, y está innovando en el uso de las NUI no solo para el entretenimiento sino en todo tipo de ámbitos. Desde su primera versión, Kinect cuenta con las siguientes características: • Una cámara que puede ver en 3D gracias a los sensores de profundidad que recolectan la información de los rayos infrarrojos. • Una videocámara tradicional RGB. • Un arreglo de 4 micrófonos ubicados en la parte inferior para detectar la dirección de donde provienen los sonidos y reconocimiento de voz. • Un sistema que reconoce si una persona está enfrente del sensor y la posición de su cuerpo a través de la creación de un esqueleto virtual. Kinect ha logrado mejoras en diferentes áreas como medicina, educación y sistemas de rehabilitación. Por ejemplo, los médicos pueden interactuar con radiografías mediante gestos dentro de los quirófanos (ver figura 2). También se han desarrollado terapias con el sensor para ayudar a niños a desarrollar sus capacidades motrices y de lenguaje.

Mejoras en la versión 2

Con la salida de la consola Xbox One, Microsoft liberó en julio de 2014 las nuevas herramientas de desarrollo para la versión 2 del sensor Kinect, lo que mejoró sustancialmente sus capacidades de reconocimiento. Entre las mejoras destacan: • Un campo de visión más amplio, tanto horizontal como vertical, se eliminó la necesidad de tener un motor para el ajuste de altura, ya que se modificó la tecnología de infrarrojos. 14

Figura 1. Kinect en la medicina.

• La fidelidad en los datos de profundidad se incrementó al triple. También mejoró el rango de profundidad que se puede cubrir, desde 50 cm hasta 8 metros. • La cámara de color ahora es full HD y funciona a 30 cuadros por segundo. • Ahora se cuenta con 25 uniones en el esqueleto y soporta simultáneamente el seguimiento de hasta seis personas, con correcciones especialmente en las uniones de la cadera, hombros y columna vertebral. Ver Figura 3. • Se agregó un reconocimiento especial del pulgar para saber si la mano está cerrada o abierta.

Cómo desarrollar apps con Kinect

El SDK 2.0 para el Kinect ya se encuentra disponible de forma gratuita para que puedas aprender a construir apps que aprovechen esta tecnología. Actualmente el SDK se encuentra en una versión de “preview” que todavía no permite publicar las apps en el Windows Store, pero se espera que antes de que termine el año se libere la versión final del SDK que permitirá publicar al Windows Store. Para desarrollar aplicaciones con Kinect v2, además de contar con el sensor Kinect requieres una computadora con las siguientes características de hardware y software: • Procesador dual-core de 3.1 Ghz o más • 4 GB de RAM o más • Tarjeta gráfica con soporte para DirectX 11 • Puerto USB 3.0 • Sistema Operativo Windows 8/8.1 • Visual Studio 2012/2013 • .NET Framework 4.5 • SDK Kinect para Windows V2 (disponible para descarga en http://bit.ly/SDKKinect)

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

Figura 2. Arquitectura de Kinect para Windows.

La figura 2 muestra la arquitectura de APIs del Kinect v2. El sensor Kinect compone la capa de más bajo nivel, pues es el hardware que contiene los sensores y cámaras. La capa siguiente son los controladores que permiten digitalizar los datos de los sensores que posibilitan su programación. El runtime funciona como conexión entre la información que proporciona el hardware de Kinect y las diferentes APIs. Con esto es posible soportar una gran gama de lenguajes de programación en donde sólo necesitamos interactuar con esta capa. En el nivel más alto se construyen las APIs, por lo que se logra tener una para cada tipo de desarrollo: apps desktop nativas o con .NET, o apps para Windows Store utilizando WinRT y lenguajes de programación como C#, Visual Basic, JavaScript y C++ con XAML.

Figura 4. Referencia de Kinect a nuestro proyecto.

El último cambio que debemos hacer a la configuración de nuestro proyecto es habilitar las capacidades de la aplicación. Abrimos el archivo Package.appxmanifiest y en la pestaña Capabilities seleccionamos Microphone y Webcam.

Figura 5. Habilitar capacidades de micrófono y webcam.

Ahora comenzaremos a programar la aplicación. Abrimos el archivo MainPage.xaml para agregar una imagen dentro del Grid donde se mostrará la información de la cámara infrarroja. <grid background=”{ThemeResource ApplicationPageBackgroundThemeBrush}”> <image name=”image” width=”512” height=”424”></image> </grid>

En el MainPage.xaml.cs definimos las bibliotecas que usaremos para el manejo de la imagen y los datos de Kinect. using Windows.UI.Xaml.Media.Imaging; using WindowsPreview.Kinect;

Figura 3. Plataforma de compilación.

Ahora necesitamos agregar la referencia de Kinect a nuestro proyecto. Hacemos clic derecho sobre la carpeta de References y enseguida Add Reference. Dentro de la ventana que abre, seleccionamos en Windows 8.1 la opción de Extensions y elegimos KinectPreview. Kinect. Ver Figura 4. 15

A continuación se declaran los objetos que utilizaremos: un objeto KinectSensor para comunicarnos con el Kinect; InfraredFrameReader y un arreglo de ushorts para leer los datos del infrarrojo y guardarlos respectivamente; un arreglo de bytes para almacenar el color de cada pixel de la imagen que pondremos en un objeto WriteableBitmap. KinectSensor sensor; InfraredFrameReader irReader; ushort[] irData; byte[] irDataConverted; WriteableBitmap irBitmap;

www.sg.com.mx |

Lo primero es crear un proyecto en Visual Studio. Se elige la plantilla en blanco de Windows Store App y le asignamos un nombre. Una vez que se ha generado el proyecto, en el explorador de soluciones hacemos clic derecho en la solución que acabamos de crear y seleccionamos Properties. En la ventana que se abre, elegimos Configuration Properties y cambiamos la plataforma de compilación a x86. Ver Figura 3.

Software Guru

Desarrolla tu primera aplicación con Kinect utilizando C# y Visual Studio

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

Dentro del constructor, agregamos un método al evento Loaded de la clase.

if (irFrame != null) { irFrame.CopyFrameDataToArray(irData); for (int i = 0; i < irData.Length; i++) { byte intensity = (byte)(irData[i] >> 8); irDataConverted[i * 4] = intensity; irDataConverted[i * 4 + 1] = intensity; irDataConverted[i * 4 + 2] = intensity; irDataConverted[i * 4 + 3] = 255;//alfa } irDataConverted.CopyTo(irBitmap.PixelBuffer); irBitmap.Invalidate(); }

public MainPage() { ... this.Loaded += MainPage_Loaded; }

En el método MainPage_Loaded creamos una nueva instancia del sensor, una instancia para el lector de infrarrojo y un objeto FrameDescription que nos permita saber la longitud en pixeles de la información infrarroja. Con este dato, inicializamos el arreglo de ushorts y el arreglo de bytes multiplicándolo por cuatro para almacenar la información en formato RGBA. Para la inicialización del mapa de bits usamos el ancho y el alto de la imagen que se captura con la cámara infrarroja. Ligamos la fuente de la imagen del xaml con nuestro mapa de bits para poder actualizarla con los datos del sensor. Se abre la instancia del sensor Kinect para usarse, y por último hacemos el vínculo del método al evento FrameArrived que se ejecutará cada vez que un cuadro de la imagen sea recibido.

} }

Estamos listos para ejecutar la aplicación en la máquina local y ver nuestra aplicación. La app mostrará en pantalla el flujo de datos que el sensor infrarrojo del Kinect está obteniendo, tal como se muestra en la figura 6.

void MainPage_Loaded(object sender, RoutedEventArgs e) { sensor = KinectSensor.GetDefault(); irReader = sensor.InfraredFrameSource.OpenReader(); FrameDescription fd = sensor.InfraredFrameSource.FrameDescription; irData = new ushort[fd.LengthInPixels]; irDataConverted = new byte[fd.LengthInPixels*4]; irBitmap = new WriteableBitmap(fd.Width, fd.Height); image.Source = irBitmap; sensor.Open(); irReader.FrameArrived +=irReader_FrameArrived; }

Dentro del nuevo método obtenemos el cuadro de la imagen del infrarrojo mediante el parámetro args utilizando FrameReference. AcquireFrame(). Verificamos si el InfraredFrame es distinto de nulo; si lo es, copiamos su información al arreglo de ushorts irData, iteramos sobre el arreglo y por cada dato realizamos un corrimiento de bits para obtener el byte más significativo. Con esto asignamos una intensidad que permitirá realizar una imagen a escala de grises dentro del arreglo irDataConverted, dejando el canal alfa en 255 para tener una imagen opaca. Finalmente, copiamos el arreglo de bytes resultante al PixelBuffer de irBitmap e invalidamos la información forzando la aplicación a redibujar la imagen en nuestra app. void irReader_FrameArrived(InfraredFrameReader sender, InfraredFrameArrivedEventArgs args) { using (InfraredFrame irFrame = args.FrameReference.AcquireFrame()) {

Figura 6. App ejecutándose.

El proyecto completo de Visual Studio con este ejemplo y contenido extra se encuentra disponible para descarga en http://swgu.ru/tutorial-kinect

Referencias [1] Channel 9: Programming Kinect for Windows V2 http://channel9.msdn.com/Series/Programming-Kinect-for-Windows-v2 [1] MSDN: Kinect for Windows SDK http://msdn.microsoft.com/en-us/library/dn772637.aspx

.BIO Laura Frias Carrillo (@lauriutz) es Technical Evangelist en el equipo de Divulgación Tecnológica en Microsoft México. Se especializa en el desarrollo de apps para Windows Phone, Windows 8 y Kinect para Windows. Laura es orgullosa egresada de la Facultad de Ciencias, UNAM. http://blogs.msdn.com/b/laurafrias

.HERRAMIENTAS Y TECNOLOGÍAS Novedades

CONOCIENDO DOCKER ›› Por Borja Burgos

Docker es, en esencia, un intento exitoso por estandarizar la tecnología de contenedores de Linux de la que hemos gozado en los últimos años. Para explicar lo que es un contenedor de software, el equipo de marketing de Docker acostumbra usar la analogía de un contenedor de mercancías. Pero dado el perfil de la audiencia de SG, tal vez resulte más familiar para todos nosotros pensar en otra analogía: la máquina virtual. Si pensamos que el sistema operativo que se ejecuta dentro de una máquina virtual está siendo “engañado” para que piense que corre en su propio hardware, entonces la analogía resulta sencilla. Una aplicación o proceso que corre dentro de un contenedor también está siendo “engañado” para pensar que corre dentro de su propio sistema operativo. Al igual que con las máquinas virtuales, donde

contenedor, dejamos de preocuparnos por versiones y configuraciones de librerías, sistemas operativos, servidores de aplicaciones, etcétera. Se podría decir que desplegar una aplicación con Docker es análogo a instalar una aplicación móvil en un celular corriendo Android o iOS. La instalación es trivial para el usuario. Una vez desplegado el contenedor, las aplicaciones exponen servicios e interfaces al sistema operativo y a otras aplicaciones que deseen hacer uso de ellas. Las aplicaciones que corren dentro de un contenedor quedan a su vez aisladas del sistema operativo donde corren.

Un ecosistema en crecimiento

Además de las herramientas y la tecnología “open source” que facilitan a desarrolladores y administradores el empaquetar y desplegar sus propias aplicaciones, Docker, Inc. también ha lanzado un servicio online llamado Docker Hub (http://hub.docker.com). Éste se está convirtiendo en un repositorio público de aplicaciones open source. Al día de hoy cuenta con más de cien mil imágenes públicas. Por ejemplo, en Docker Hub encontraremos imágenes de aplicaciones populares como bases de datos MySQL, PostgreSQL, MongoDB, ... o aplicaciones CMS (Content Management System) como Wordpress, Drupal o Joomla. Es gracias a este repositorio de imágenes públicas que instalar una aplicación open source en nuestro servidor es tan sencillo como instalar una aplicación en nuestros celulares. Sin lugar a dudas, el elevado número de beneficios y las casi inapreciables desventajas de utilizar contenedores para nuestras aplicaciones harán que esta tecnología se convierta en el estándar a la hora de empaquetar y desplegar nuestras aplicaciones en la nube. Conoce más sobre Docker en https://www.docker.com

.BIO Borja Burgos (@borja_burgos) es un emprendedor, ingeniero y hacker que disfruta diseñar y construir soluciones para problemas nuevos y existentes. Actualmente es CEO de Tutum, empresa proveedora de servicios de hosting para contenedores Docker. https://www.tutum.co

Software Guru

Contenedores: un concepto simple

el hardware que el sistema operativo “ve” no tiene por qué ser el mismo que el hardware que existe en la realidad, un contenedor puede “ver” un sistema operativo distinto al del sistema operativo donde se está ejecutando. Cabe destacar que, pese que existen similitudes entre ambos, un contenedor resuelve cuellos de botella de software, mientras que una máquina virtual resuelve cuellos de botella de hardware. Ambos son complementarios, y no excluyentes. ¿Y qué tipo de problemas resuelven los contenedores? Seguro que todos en algún momento de nuestras carreras nos hemos topado con el problema de una aplicación que corre satisfactoriamente en un servidor (virtualizado o no), pero se comporta erráticamente en otro. O el código de un desarrollador, que funciona en su computadora, pero luego falla cuando lo mandamos al entorno de “staging” o producción. Esto se debe a que dos copias exactas de una misma aplicación se comportan de manera distinta en dos entornos con configuraciones distintas. La falta de una dependencia, como una librería, o que exista pero con una versión distinta, o que una variable de entorno sea distinta, o incluso que la versión del sistema operativo varíe puede ocasionar que nuestra aplicación deje de funcionar correctamente. Docker resuelve este problema de manera elegante, con Docker empaquetar aplicaciones en contenedores autosuficientes es una tarea sencilla. Una vez que tenemos la aplicación en un contenedor, desplegarla es una operación rápida y ligera, independientemente del tipo de servidor, del sistema operativo (sólo Linux, eso sí), o del proveedor de infraestructura que utilicemos. Y porque la aplicación, configuración y todas sus dependencias están “contenidas” en el

www.sg.com.mx |

ocker, hoy en boca de todos, nació en Marzo de 2013 como un proyecto “open source” de dotCloud, startup que por aquel entonces era un proveedor de PaaS al estilo de Heroku. En tan solo 18 meses Docker se ha convertido en uno de los proyectos más populares en GitHub. El proyecto ha sido tan exitoso, que dotCloud mismo pasó a llamarse Docker, Inc. y en Junio de 2013 organizaron la primera conferencia DockerCon en San Francisco con el apoyo de compañías como Google, RedHat o Rackspace. Pese a todo esto, todavía existe mucha confusión acerca de qué exactamente es Docker, qué aporta sobre tecnologías existentes, la razón de su éxito, y lo más importante, por qué lo necesitamos y cómo va a cambiar nuestra manera de desarrollar, construir, probar y desplegar nuestras aplicaciones de software.

Por Gustavo Alzate Sandoval CADA VEZ MÁS VEMOS COMO LA TENDENCIA A EXPONER APIS (APPLICATION PROGRAMMING INTERFACE) AUMENTA EN TODO TIPO DE ORGANIZACIONES. HOY EN DÍA EL USO E IMPLEMENTACIÓN DE APIS REPRESENTA UN NUEVO CANAL DE PRODUCTO PARA LLEGAR A MUCHAS PERSONAS, YA QUE LOS APIS FACILITAN EL APROVECHAMIENTO DE DATOS O SERVICIOS EXISTENTES. EN BASE A ESTO SURGE UNA BUENA PREGUNTA: ¿SÓLO YO USO Y EXPONGO MI INFORMACIÓN O DEBERÍA PERMITIR QUE TERCEROS EXTERNOS PUEDAN USARLA? UN EJEMPLO CLARO DE ESTO PUEDEN SER GRANDES COMPAÑÍAS COMO FACEBOOK Y TWITTER, QUIENES REPORTAN UN ALTO USO DIARIO DE SUS APIS EXPUESTAS, Y QUE SIN LUGAR A DUDA SE CONVIERTEN EN GRAN PARTE DE SU TOTAL DIFUSIÓN Y USO. Y NO ES PARA MENOS EN UNA ERA EN LA CUAL ABUNDAN GRAN CANTIDAD DE DISPOSITIVOS QUE REQUIEREN CONSUMIR UN API DE UNA FORMA SENCILLA.

.ESPECIAL

Y es entonces en la era actual, dónde es tan importante pensar en construir un API que exponga mi información, y pensar luego: “he ahí el poder de habilitar a la comunidad para que exponga tu información y no solo seas tú quien lo haga”. Y más allá de convertirse en un valor agregado, tener un API se convierte en una necesidad, ya que si el mercado cambia y nuestros clientes cambian, nosotros debemos hacer lo mismo. Así que si tienes dudas sobre si necesitas un Api o no, te invito a que te respondas las siguientes preguntas: •¿Sus clientes o socios le han preguntado por un API? •¿Necesita usted crear una aplicación móvil en diversas plataformas? •¿Necesita usted mayor flexibilidad para exponer su contenido? •¿Tiene usted datos que pueden ser expuestos? •¿Su competencia directa usa un API? •¿Quiere usted escalar la integración e interacción con sus socios y clientes? Son preguntas sencillas que pueden definir si se necesita de un API o no. En mi opinión en la mayoría de los casos obtendremos un sí como respuesta.

Y a pesar de ver ahora la necesidad de exponer un API e iniciar con la construcción de la misma, no es tarea fácil plantear una estrategia que ayude a que esta API tenga éxito. Hay que considerar distintos actores y puntos de vista que pueden intervenir en este proceso: el dueño del producto a nivel negocio, el equipo de desarrollado que lo construye apoyándose en tecnologías como REST, el usuario que lo utiliza para generar nuevos productos y servicios, y el equipo que soporta la infraestructura de cómputo desde donde se ofrece el API que debe asegurarse de poder soportar la carga de uso requerida, así como picos de uso, sincronización y respaldo de datos, etcétera.

REST, facilitando el uso y consumo de APIs De acuerdo con programmableweb.com (un sitio con noticias y contenidos relacionados con las APIs), el 70% de las APIs en la actualidad usan estilo de arquitectura REST (Representational State Transfer). El papel que juega REST en la era de las APIs es fundamental, ya que en la actualidad la mayoría de APIs están basadas en esta filosofía, y por lo tanto se ha convertido en el estándar de facto (una de las alternativas es SOAP, que es mucho menos utilizado). El estilo de arquitectura REST se basa en los siguientes principios: • Facilidad de uso. • Consumo desde múltiples dispositivos. • APIs ligeras y sencillas. Y esto ha vuelto mucho más fácil la tarea de crear cada vez mejores APIs para exponer al público, tanto para los propietarios de las APIs como para los desarrolladores que las implementan, ya que siempre se busca garantizar las características mencionadas anteriormente en un API para lograr su éxito y adecuado uso. Las tecnologías web mutan y cambian para suplir necesidades a los variables usuarios y tendencias, la era actual de la web está basada en el uso de las Apis, es una realidad y un presente, ¿solo tu administras y compartes tu información?, o ¿muchas personas más pueden hacerlo?

Referencias [1] D. Jacobson, G. Brail, D. Woods. APIs: a strategy guide. O’Reilly Media. [2] R. Scoble.”Why if you miss Siri you’ll miss the future of the web”. [3] “Representational State Transfer”. Wikipedia.

Figura 1. APIs: Nuevo canal de producto.

.BIO Gustavo Alzate Sandoval trabaja en Visión Travel como Líder de Proyecto. Su especialidad es el desarrollo de software. Es conferencista, entrenador y consultor. Pertenece a la comunidad Avanet y es Microsoft Community Specialist. gustavoalzatesandoval@gmail.com @ElTavoDev http://www.eltavo.net

Software Guru

• Web 1994: “Dame un dominio y una página”. • Web 2000: “Haz mis páginas interactivas y con usuarios”. • Web 2010: “Elimina las páginas y conecta a las personas por medio de APIs”.

“Las organizaciones líderes ven a sus APIs como una herramienta estratégica de negocio”.

www.sg.com.mx |

No solo se trata a de crear un API que exponga mi información, esto va mucho más allá. Entre otras cosas hay que definir: a qué tipo de público va dirigida, que consideraciones debo tener para diseñarla, qué consideraciones de disponibilidad debo tener y también cómo voy a promocionarla. Las organizaciones líderes ven a sus APIs como una herramienta estratégica de negocio. Y no es para menos, si según cifras de Twitter y Facebook indican que el consumo de sus APIs expuestas da cada vez más tráfico, posicionamiento e ingreso a sus marcas. Es por esto que podemos decir que nos encontramos en el inicio de una nueva era en el Internet: “La era de las APIs”. A decir verdad podemos demarcar tres importantes eras en torno a la web, como dice uno de los más famosos bloggers del mundo Robert Scoble en uno de sus artículos [2]:

CARACTERÍSTICAS Y MODO DE USO Por Francisco Jiménez Hernández y Jorge Alberto Jiménez Sandoval COMO TODOS SABEMOS, LAS REDES SOCIALES CRECEN DÍA A DÍA Y POSEEN INFORMACIÓN TANTO PERSONAL, COMO DE OPINIONES DE LOS USUARIOS QUE LAS UTILIZAN. Con el fin de conocer dicha información para fines específicos y de promocionar marcas y servicios, actualmente muchas aplicaciones están siendo diseñadas de tal forma que tengan la capacidad de establecer una conexión con el API (Application Programming Interface) de dichas redes. Para establecer dicha conexión, se debe seguir un proceso de autenticación y autorización de permisos mediante la implementación del protocolo oAuth (Open Authentication). Este protocolo permite que un usuario conceda acceso a un tercero (proveedor de servicio o aplicación) para que acceda a sus datos, sin tener que proporcionarle su usuario y contraseña. En dicho proceso y al momento en que el usuario concede permisos a la aplicación, la red social proporciona un “token” que deberá ser guardado por dicha aplicación para poder realizar peticiones en nombre del usuario, tales como leer información personal, intereses, contactos o publicar nueva información. La interacción entre las redes sociales y la aplicación es realizada mediante peticiones enviadas sobre el protocolo HTTPS. Dependiendo de la acción que se desee realizar pueden usarse peticiones de tipo GET, POST, PUT o DELETE. Todas las peticiones, independientemente si son para leer, escribir, editar o eliminar información, deben de incluir el “token” de acceso por medio del cual se valida la petición y se acepta o se rechaza de acuerdo a los permisos otorgados por el usuario. Es recomendable que el “token” de acceso sea enviado dentro del encabezado de las peticiones, sin embargo, también puede ser enviado como parámetro en la URL, ya que es protegido por el mismo protocolo HTTPS. En seguida mencionaremos a modo personal y de acuerdo a nuestra experiencia, algunas características que hemos notado acerca de la API de Twitter, Facebook, YouTube e Instagram.

Twitter Twitter es una de las redes sociales que por su naturaleza no hay muchas rescricciones de privacidad, es decir, la gran mayoría de usuarios tiene público su perfil y por lo tanto también sus tuits. Por esta razón, Twitter permite el acceso a toda esta información a través de su API. Las restricciones con las que se encuentran los desarrolladores es que existen límites de peticiones en un periodo de tiempo, es decir, existen intervalos de 15 minutos en donde se puede hacer un número máximo de peticiones. Cabe mencionar que estos límites son por usuario, no por aplicación, de esta forma cada usuario es controlado de forma independiente. Dependiendo del tipo de recurso que sea solicitado, existen dos tipos de restricciones principales:

15 peticiones cada 15 minutos y 180 peticiones cada 15 minutos. Adicionalmente, no se permite recuperar información histórica, es decir, si se ejecuta una búsqueda sólo es posible obtener información generada 7 días atrás como máximo. En caso de exceder el número máximo de peticiones en un periodo de tiempo, se obtiene un código de respuesta en donde se provee información acerca del recurso restringido temporalmente y el tiempo de espera para que el recurso se encuentre nuevamente disponible. Otra particularidad de Twitter, es que cuenta con streaming, lo que permite obtener información en tiempo real sin restringir el número de peticiones por un periodo de tiempo. La versión actual del API de Twitter es la 1.1.

Facebook En el caso de Facebook, por todas las restricciones de privacidad que protegen la información del usuario, no es posible acceder a datos protegidos a menos que ambos usuarios tengan una relación de ‘amistad’ en la red social. En caso contrario sólo puede obtenerse acceso sin restricción al nombre y al género de los usuarios. Sin embargo, si un usuario da consentimiento explícito a que un tercero acceda a su información de perfil, correo electrónico, gustos, intereses, amigos, eventos, datos de amigos, entre otros más; entonces la aplicación prácticamente no tendrá restricciones para ese usuario en particular. El acceso a los mensajes públicos en Facebook es mediante su Open Graph que soporta también peticiones utilizando el Facebook Query Language. Facebook no tiene documentado el número máximo de peticiones en un periodo de tiempo o si las restricciones son por usuario, aplicación, dirección IP o la combinación de estos, sin embargo, si continuamente se envían peticiones hacia un recurso específico, con el tiempo se aprecia que se empieza a obtener menos información acerca del mismo. Facebook cuenta con actualizaciones en tiempo real, con esto es posible subscribirse a ciertos recursos, como el muro de un usuario, y recibir notificaciones si hay cambios. Esta funcionalidad evita estar haciendo peticiones de forma periódica. Actualmente el Open Graph se encuentra en la versión 2.0 y de acuerdo a la documentación oficial de la misma, ya no será posible acceder a los mensajes públicos que actualmente están disponibles en su versión 1.0.

YouTube En el caso de YouTube el acceso a los datos por medio de su API es muy similar a Twitter dado que los videos están disponibles públicamente. .BIO

Francisco Jiménez Hernandez es desarrollador Sr. en INFOTEC desde hace 3 años. Ha trabajado como desarrollador en la Gerencia de Nuevos Productos y Servicios, dando mantenimiento a la herramienta Open Source de SemanticWebBuilder. Actualmente sus funciones como Coordinador de Desarrollo involucran la definición de funcionalidades de un nuevo producto de la familia SemanticWebBuilder denominado SWB Social.

.ESPECIAL

“una

Instagram Instagram cuenta con una API con mayores limitantes desde el punto de vista de interacción, dado que a diferencia de las redes sociales descritas anteriormente, con Instagram no es posible subir contenido, esta acción solamente es permitida mediante su aplicación oficial. De forma adicional, se tiene una restricción de 5 mil peticiones por hora por “token” de acceso. El API de Instagram solamente permite realizar búsquedas sobre mensajes que contengan etiquetas que existan en la red social. Este tipo de búsqueda se realiza sobre los mismos mensajes y sobre sus comentarios.

Comparación Una de las redes sociales con más flexibilidad para obtener información es Twitter, dado que la información es en su mayoría pública y su API proporciona facilidades para ejecutar sin restricciones un gran

Experiencia y uso específico En INFOTEC hemos estado desarrollando un nuevo producto al que denominamos SWB Social, el cual se conecta a las redes sociales mediante las técnicas aquí descritas. También es posible conectarse y explotar la información de más redes sociales en un tiempo relativamente rápido. SWB Social escucha y entiende opiniones acerca de una organización, sus productos y servicios e inclusive de su competencia, identificando en la información sentimientos, influencia, geolocalización e idioma, entre mucha más información relevante que ayuda a tomar decisiones para mejorar los productos y servicios de una organización. SWB Social es una herramienta que INFOTEC está liberando como open source, tal como lo ha venido haciendo con otros productos, como apoyo a las organizaciones e industria de TI en México. Conoce más en http://www.semanticwebbuilder.org.mx/SWBSocial .BIO

Jorge Alberto Jiménez Sandoval es consultor Sr. en INFOTEC con 15 años de experiencia en arquitectura y desarrollo de productos de software, basados muchos de ellos en Web Semántica, mediante modelado ontológico de datos. Arquitecto y desarrollador líder de SWB Social.

www.sg.com.mx |

Las restricciones de acceso no son medidas por intervalos cortos de tiempo donde se permite un número máximo de peticiones, sino que es controlado por día. YouTube asigna diariamente un número de ’Unidades’ para cada aplicación (no es por usuario) y cada operación que se realiza tiene un costo de esas unidades, por ejemplo, subir un video representa el uso de mil 600 unidades que son restadas del total disponible del día. Ahora bien, cuando se requiere realizar una búsqueda de videos, YouTube tiene una restricción que permite recuperar un máximo de 500 videos por búsqueda y no tiene una restricción de temporalidad, es decir, pueden recuperarse videos que fueron subidos recientemente o de meses atrás. Si la búsqueda devuelve más de 500 videos, YouTube sugiere que se utilicen otros criterios de búsqueda para refinar los resultados y de esta forma obtener la información deseada. YouTube hace uso principalmente de XML para compartir sus datos y para enviar respuestas o mensajes de error, sólo algunos recursos pueden ser configurados para que la respuesta sea devuelta en formato JSON. La versión actual del API de YouTube es la 3.0.

número de acciones, por ejemplo, marcar un “tuit” como favorito o retuitearlo, seguir o dejar de seguir a un usuario, ver los mensajes de cualquier usuario que no tenga privado su perfil, entre otros más. Adicionalmente su “streaming API” es una ventaja sobre las demás redes sociales dado que provee información en tiempo real sin tener que subscribirse a un recurso como lo hace Facebook. En el caso de Facebook existe mucha más información alrededor de los usuarios, como sus gustos, intereses, edad, escolaridad, y aunque toda esta información no es pública, es usada para el envío de publicidad dirigida hacia públicos muy específicos mediante su API de anuncios. Una desventaja de Facebook es que su búsqueda no ofrece la posibilidad de utilizar operadores lógicos para realizar búsquedas, a diferencia de Twitter que soporta: OR, AND, NOT y búsqueda en cuentas específicas. El API de YouTube cumple bien sus funciones, sin embargo, tiene limitantes muy restrictivas dado que sólo pueden recuperarse como máximo 500 videos en una búsqueda y los operadores lógicos que proporciona (AND y OR) no funcionan de forma óptima en todos los casos. De forma adicional, a diferencia de las redes sociales anteriores, es necesario renovar su “token” de acceso de forma periódica. Por último, la red social cuya API tiene más restricciones a nuestro parecer es Instagram, dado que no es posible publicar nuevo contenido o realizar comentarios sobre los mensajes existentes, básicamente sólo es posible leer información. Las búsquedas no contemplan el uso de operadores lógicos, y el término de búsqueda tiene que ser necesariamente una etiqueta válida existente en dicha red para que se obtengan resultados exitosos.

Software Guru

de las redes sociales con más flexibilidad para obtener información es twitter”.

Por Gunnar Wolf EL PASADO MES DE JULIO TUVE NUEVAMENTE LA OPORTUNIDAD DE PARTICIPAR EN EL CONGRESO ANUAL QUE ORGANIZA SG, PRESENTANDO LA CONFERENCIA DESARROLLO DE SOFTWARE Y CRIPTOGRAFÍA [1]. ME DOY CUENTA QUE, SI BIEN SU RELEVANCIA RESULTA CLARA Y HAY INTERÉS EN LA COMUNIDAD DE DESARROLLADORES POR COMPRENDERLO, EL TEMA DE LA CRIPTOGRAFÍA ES VISTO POR MUCHOS COMO UN TEMA CASI MÁGICO O MÍSTICO: HAY UNOS POCOS EXPERTOS, PERO ESTÁ FUERA DEL ALCANCE PARA EL COMÚN DE NOSOTROS, LOS SIMPLES DESARROLLADORES QUE CARECEMOS DE UN SÓLIDO CONOCIMIENTO MATEMÁTICO DE FONDO. Y sí, no puedo negarlo: El uso correcto de la criptografía requiere de darse una pequeña zambullida en un mar de conceptos nuevos. Sin embargo, me da gusto ver que estamos cada vez más conscientes de la importancia de proteger los datos de nuestras aplicaciones, tanto como sea posible, por criptografía fuerte. Aquí aparece la primer tensión que abordo: ¿Cómo responder a las necesidades de seguridad de información sin tener un sólido conocimiento matemático en cuestiones de criptografía? Afortunadamente, en ese punto es donde aparece el hilo conductor con el tema de la presente edición de SG: La era de las APIs: Hay varias bibliotecas criptográficas ampliamente disponibles, implementando los diferentes algoritmos y modos de operación. Y no es necesario implementar los protocolos criptográficos, sino únicamente llamar a las funciones indicadas de la biblioteca de nuestra elección. Y, claro, el hablar de estas principales implementaciones también da pie a abordar del impacto de los no pocos ni triviales problemas que han aquejado a este campo en los últimos meses. Y sí, aunque probablemente muchos asocien en principio al término API con las interfaces presentadas por servicios en la nube como las redes sociales, en realidad toda biblioteca que empleemos para el desarrollo (incluyendo las bibliotecas estándar, parte de la definición de nuestro lenguaje) expone una interfaz de programación de aplicaciones. Claro está, estamos viviendo en la era de las APIs — Desde hace más de 60 años.

Criptografía: ¿Para qué? La criptografía nos brinda distintas herramientas para proteger nuestra información — Y si partimos de que la información es el activo más valioso de todos nuestros sistemas, resulta obvio que la criptografía es uno de nuestros mayores aliados. Si bien la criptografía es casi tan vieja como la escritura misma, apenas fue abordada como una disciplina científica matemática a 22

partir de mediados del siglo XX. El objetivo esencial de la criptografía es brindar confidencialidad a a información valiosa. Sin embargo, hoy en día la confidencialidad representa sólo una de las propiedades de la información que la criptografía nos permite asegurar. La segunda propiedad que protege la criptografía es la integridad: Partiendo de un texto origen arbitrariamente largo, las llamadas funciones digestoras calculan su hash, una cadena de longitud fija con la propiedad fundamental de ser muy dificil encontrar otro texto que genere la misma salida. Esta definición de integridad posiblemente deje a más de uno insatisfecho. Y sí, por sí sola no sirve para garantizar gran cosa… pero la tercer propiedad hará clara su utilidad. Hasta mediados de 1970, todos los esquemas de criptografía dependían de una llave única: el equivalente a una contraseña que permitía tanto convertir un texto claro en una representación ininteligible como manipular a dicha representación para obtener de vuelta al texto claro. Entre el breve lapso comprendido 1976 y 1980, el mundo de la criptografía cambió por completo: nació la criptografía de llave pública, con los principales protocolos que siguen siendo utilizados al día de hoy. Esencialmente, en vez de manejar una sola llave, se descubrieron varias funciones matemáticas que permiten llaves compuestas de dos mitades: una privada, que cada individuo debe custodiar celosamente, y una pública, que puede ser ampliamente distribuida. Estas dos llaves actúan como inversas: lo que se cifra con una sólo puede descifrarse con la otra. Este hecho, que parecería una mera curiosidad, permitió la creación de mecanismos para proteger las tercera propiedad de la información: la autenticación. Si un mensaje cifrado por mi llave privada puede ser descifrado por cualquiera que conozca mi llave pública, y existen directorios de llaves públicas, este mensaje sólo puede haber sido generado por mí. Ya con estos antecedentes, ¿qué es la cadena que aparece en todas las facturas electrónicas y ocasionalmente incluso en los correos electrónicos?

.ESPECIAL

Al hablar de la integridad, mencioné que debía ser muy difícil encontrar dos textos que produzcan el mismo resultado. A pesar de que el término puede no inspirar mucha confianza, sin embargo, debe leerse no como algo que intuitivamente (y sin ser especialista) me parezca difícil, sino definido desde la teoría de la complejidad computacional: computacionalmente difícil significa que es sumamente resistente a ser atacada por búsqueda exhaustiva (o lo que es lo mismo, por fuerza bruta); idealmente, la complejidad crece de forma exponencial con el espacio de búsqueda. Por ejemplo: un algoritmo de cifrado simétrico ampliamente utilizado como el AES puede operar con llaves de 128 a 256 bits. Esto significa que, con una llave de 128 bits, el espacio de búsqueda es de 2128 (del orden de 1038) posibilidades. Si tuviéramos poder de cómputo suficiente para intentar decodificar un billón de llaves por segundo, una búsqueda exhaustiva tomaría sólo 719 millones de veces la edad del universo. En contraste (e ilustrando el crecimiento exponencial), una llave de 64 bits tomaría sólo 213 días. Los algoritmos que se han desarrollado, es cierto, no son perfectos. Por ejemplo, Alex Biryukov y Dmitry Khovratovich presentaron en 2009 un artículo [2] detallando un tipo de análisis permitiendo reducir dramáticamente (a sólo unas decenas de veces la edad del universo según nuestro cálculo) el espacio de búsqueda. La búsqueda de debilidades en algoritmos criptográficos es un campo vibrante de investigación matemática, con muchos talentosos académicos buscando cómo ganarle un bit más, un pasito más. De encontrarse alguna debilidad, aparecerá sin duda publicada en las más importantes revistas académicas del ramo.

Bibliotecas criptográficas Pero, dado que nuestro campo es el desarrollo de sistemas y no la criptografía desde un punto de partida matemático, recordemos que hay una gran regularidad entre los parámetros que requieren los diferentes algoritmos. Si empleamos una biblioteca de funciones criptográficas, como la muy conocida OpenSSL, y un algoritmo ampliamente utilizado es descubierto como vulnerable, hacer el cambio para emplear otro algoritmo resultará casi trivial. Por otro lado, me permito citar la máxima de Adi Shamir, uno de los padres de la criptografía moderna:

OpenSSL es la biblioteca criptográfica por excelencia, y su principal fuerza es también su principal desgracia: es una biblioteca con 20 años de historia, y profundamente multiplataforma. Vamos, su herencia multiplataforma ha mantenido el soporte para arquitecturas que desde hace años son consideradas obsoletas, como VMS u OS/2. Además, el estilo del código es de muy difícil comprensión —los desarrolladores justifican esto puesto que, siendo la criptografía tan demandante de recursos de cómputo, se vieron orillados a tomar decisiones motivados más por el rendimiento que por la claridad. Como sea, el fallo conocido como Heartbleed expuso lo inadecuadas que dichas prácticas son hoy en día. Sin embargo, y analizando el fenómeno desde la perspectiva de un promotor del software libre, la respuesta de la comunidad ha sido de lo más interesante: por un lado, la Linux Foundation (a través de su Core Infrastructure Initiative) está fondeando una auditoría del código de OpenSSL. Y por otro lado, surgieron dos proyectos derivados de OpenSSL, buscando corregir sus defectos de formas más radicales, aunque signifique romper la compatibilidad a nivel API: LibReSSL [5], del equipo de sistema operativo OpenBSD, y BoringSSL [6], de Google. ¿Por qué BoringSSL? En palabras de Shawn Wilden: Los componentes fundamentales de seguridad deberían ser muy aburridos. No son el lugar para innovar y experimentar, (ni) para el código que demuestra el virtuosismo del autor. Son donde quieres implementaciones simples, directas y aburridas de los algoritmos y protocolos. Cuando se habla de seguridad, lo aburrido es bueno. Que Heartbleed fue un fallo nefasto nadie lo pone en duda. Sin embargo, ante estos fallos siempre es interesante ver la reacción de las comunidades de desarrolladores. Al igual que cuando otros fallos severos, Heartbleed ha llevado a los desarrolladores (al menos dentro de las comunidades de software libre, cuyo código y cuyas discusiones son claramente visibles desde fuera) a iniciar auditorías y replantearse prácticas que seguramente redundarán en el avance global de la calidad del software.

Referencias [1] http://gwolf.org/desarrollo_y_criptografia [2] http://eprint.iacr.org/2009/317

La criptografía normalmente es evadida, no penetrada. Decenas de productos han implementado soluciones criptográficas (generalmente basadas en el firmado) en los últimos años, sólo para encontrar que su mecanismo fue roto al muy poco tiempo de salir al mercado [3]. Todos estos ejemplos derivan de un uso incorrecto de la criptografía: Para hacer un jailbreak, el atacante burla la llamada a la función criptográfica, aprovechando un error de programación para secuestrar el flujo antes de

[3] La excelente presentación Crypto won’t save you either, disponible en http://regmedia.co.uk/2014/05/16/0955_peter_gutmann.pdf, presenta más de 20 casos. [4] ¿No supiste acerca de la vulnerabilidad de seguridad más publicitada por lo menos en este lustro? http://heartbleed.com [5] http://www.libressl.org [6] https://www.imperialviolet.org/2014/06/20/boringssl.html

.BIO Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. http://gwolf.org

Software Guru

Pero… ¿Se puede confiar en la criptografía?

que se lleve a cabo la validación. Y antes de cerrar esta columna: mencioné a la popular biblioteca OpenSSL. A más de uno de ustedes debe haberle sonado una alarma: ¿En serio está recomendando OpenSSL? ¿Después de Heartbleed?[4] Sí, sí lo recomiendo. Vamos paso por paso.

www.sg.com.mx |

Tomando un texto origen, se obtiene su hash, y se firma con la llave privada del emisor. ¡Listo! Una firma electrónica con un tamaño constante, estableciendo una relación no repudiable entre un documento y su emisor. Partiendo de distintas formas de emplear estas tres propiedades pueden derivarse otros varios patrones de validación de documentos; este es sólo el más común y sencillo de muchos de los patrones de uso de criptografía.

Por Humberto Cervantes EN ESTA OCASIÓN HABLARÉ DE UN TEMA RELACIONADO CON LAS INTERFACES DE PROGRAMACIÓN DE APLICACIONES (API) Y CON LAS PRUEBAS QUE JUEGA UN PAPEL FUNDAMENTAL DENTRO DE LA ARQUITECTURA: LAS INTERFACES. LAS INTERFACES SON LOS PUNTOS DE CONTACTO QUE ESTABLECEN UN CONTRATO QUE PERMITE EL INTERCAMBIO DE INFORMACIÓN ENTRE ELEMENTOS QUE FORMAN PARTE DE LA ARQUITECTURA DE UN SISTEMA DE SOFTWARE. ESTOS ELEMENTOS PUEDEN SER LÓGICOS (EJ. MÓDULOS), DINÁMICOS (EJ. OBJETOS) O FÍSICOS (EJ. NODOS DE HARDWARE). RECORDEMOS QUE LA ARQUITECTURA ESTÁ FORMADA POR ESTRUCTURAS COMPUESTAS POR ELEMENTOS CONECTADOS ENTRE SÍ (VER SG27), Y ES EN LOS PUNTOS DE CONEXIÓN DONDE SE ENCUENTRAN LAS INTERFACES. Durante el diseño de la arquitectura (ver SG29), el arquitecto considera un subconjunto de requerimientos que se denominan drivers para crear las estructuras que conforman a la arquitectura del sistema. Estos requerimientos incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG28). Al diseñar la arquitectura, el arquitecto identifica elementos que permiten satisfacer los drivers, junto con las interfaces de estos elementos. La identificación y definición de las interfaces se hace, generalmente, mediante un análisis dinámico de la interacción entre los elementos con el fin de soportar un requerimiento particular. La figura 1 muestra un ejemplo de esto.

mientras que almacena() forma parte de la interfaz del componente Persistencia. Cabe señalar que en general una interfaz tiene varios métodos, a diferencia de este ejemplo simple. El arquitecto no identifica todos los elementos y sus interfaces, solo lo hace para aquellos que soportan los drivers. Sin embargo, estas decisiones establecen un marco de referencia que permite a los desarrolladores identificar los elementos e interfaces para requerimientos que no son drivers. Considerando el ejemplo previo, se deberían identificar componentes para soportar los demás casos de uso así como sus interfaces.

Permiten realizar la integración del sistema

Figura 1. Estructuración lógica para soportar el caso de uso CU-1 (llave: UML)

El caso de uso CU-1, que es primario, forma parte de los drivers mientras que los demás casos de uso no. Al momento de diseñar la arquitectura, el arquitecto identifica elementos (en este caso capas y componentes) que permiten soportar el driver. Una vez identificados los elementos, se establecen los mensajes que deben intercambiar instancias de los elementos para soportar el driver. En el ejemplo, el componente ServicioCU1 tiene un método procesa() que recibe dos parámetros p1 y p2 y regresa un valor de retorno retA mientras que el componente Persistencia tiene un método almacena() que recibe un parámetro p3 y regresa un valor de retorno retB. En este caso, el método procesa() forma parte de la interfaz del componente ServicioCU1 24

En general un sistema es desarrollado de forma paralela por un equipo de desarrolladores que se encargan de construir partes individuales que posteriormente serán conectadas. Si el contrato entre las partes está bien definido desde el principio, se reducen los problemas relacionados con la integración. Retomando el ejemplo de la figura 1, supongamos que los componentes ServicioCU1 y Persistencia son desarrollados por distintas personas. Si previo al desarrollo de estos componentes se estableció que el componente Persistencia tiene una interfaz con un método retB almacena(p3), el desarrollador de ServicioCU1 tiene claro cómo interactuar con el componente Persistencia y la integración normalmente se hace sin dificultades. De lo contrario, es posible que la integración se retrase por correcciones necesarias para permitir que los componentes puedan interactuar.

Especificaciones para el diseño detallados de los módulos La interfaz de un componente sirve también como especificación para realizar su diseño detallado y construcción. Consideremos el ejemplo anterior en el cual la interfaz del componente ServicioCU1 tiene un método retA procesa(p1,p2). El desarrollador puede diseñar y codificar el componente de diversas formas, siempre y cuando su diseño e implementación satisfagan el contrato establecido por la interfaz que, en este caso, es que el componente provea el método procesa().

.ESPECIAL

“la

interfaz de un elemento se debe diseñar de forma cuidadosa para no exponer detalles de implementación”.

Conexión con sistemas externos Es cada vez más común que los sistemas de software no sean entidades que trabajan de forma individual. En la actualidad, un sistema de software frecuentemente hace uso de funcionalidades provistas por otros sistemas, o bien proporciona funcionalidades para que sean usadas por otro sistema. Para permitir la interacción entre sistemas, es necesario establecer interfaces que establezcan un contrato sobre la manera en que se intercambia la información. Es común hoy en día que esas interfaces se describan usando un lenguaje tal como WSDL (Web Services Description Language), si la comunicación entre sistemas se realiza mediante servicios web.

Interfaz de Programación de Aplicaciones (API) Las interfaces de programación de aplicaciones (API) generalmente están relacionadas con librerías o frameworks (ver SG38). En lenguajes de desarrollo orientado a objetos tales como Java, existe una API asociada con el lenguaje que proporciona una gran cantidad de clases para propósitos diversos, como pueden ser el manejo de estructuras de datos. En este caso, el API se usa creando instancias de las clases que son parte del API, o bien, heredando y extendiendo a las mismas.

Alta cohesión y bajo acoplamiento. Este es el principio fundamental del diseño de interfaces. La alta cohesión se refiere a que cada componente haga una sola cosa, mientras que el bajo acoplamiento busca que al modificar un elemento el cambio no se propague hacia otros elementos. El bajo acoplamiento se logra encapsulando detalles de implementación. Esto significa que la interfaz de un elemento no debe exponer detalles internos del mismo, tales como las estructuras de datos en las cuales se almacena el estado, ya que estos detalles deben poder cambiarse sin necesidad de que esto afecte a los clientes de la interfaz. Por lo anterior, la interfaz de un elemento se debe diseñar de forma cuidadosa para no exponer detalles de implementación, ya que el tener interfaces no garantiza el bajo acoplamiento. Programación defensiva. Cuando una interfaz es expuesta para que sea usada por un sistema externo o para que se construya un programa haciendo uso de ella, es necesario tomar precauciones adicionales en relación con los valores de entrada de los métodos de la interfaz. Lo anterior es parte de lo que se conoce como “programación defensiva” e implica, entre otras cosas, validar todas las entradas y considerar posibles situaciones inesperadas. En las interfaces internas, es posible relajar un poco este aspecto si se tiene seguridad de que no se recibirán valores que podrían causar problemas. Aspectos de calidad de servicio. En algunos casos, además de la “firma” de la interfaz que está compuesta por elementos sintácticos (nombre de métodos, tipo de parámetros y valores de retorno), es necesario especificar como parte de la interfaz aspectos relacionados con la calidad de servicio. Un ejemplo de ello sería que la ejecución de un método tiene que completarse en un tiempo establecido.

Conclusión Las interfaces tanto internas como externas juegan un papel fundamental en el desarrollo de un sistema de software. La definición de las interfaces está intrínsecamente relacionada con el diseño de la arquitectura, y una definición deficiente de las interfaces tiene muchas repercusiones negativas en el desarrollo del sistema. El no definir las interfaces de forma oportuna impacta negativamente en la integración del proyecto y en la realización de pruebas del mismo, lo cual tiene repercusiones en el tiempo de desarrollo y la calidad del sistema. Por todo lo anterior, es necesario poner especial cuidado de identificar y definir correctamente las interfaces entre los elementos del sistema.

.BIO El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Además de realizar docencia e investigación dentro de la academia en temas relacionados con arquitectura de software, realiza consultoría y tiene experiencia en la implantación de métodos de arquitectura dentro de la industria. Ha recibido diversos cursos de especialización en el tema de arquitectura de software en el SEI, y está certificado como ATAM Evaluator y Software Architecture Professional por parte del mismo. www.humbertocervantes.net

Software Guru

Al desarrollar un sistema es necesario probar sus partes de forma individual, esto es lo que se conoce como prueba unitaria. La manera típica de hacerlo es probando el elemento a través de su interfaz, pues se asume que si un componente satisface el contrato que establece la interfaz entonces funciona correctamente. Retomando el ejemplo de la figura 1, si se quiere probar el componente Persistencia , habría que invocar el método almacena() y corroborar si el valor de retorno ret2 es lo que se espera en base al valor del parámetro p3. Por otro lado, las interfaces permiten realizar prueba unitaria de elementos que dependen de otros al soportar la sustitución de elementos de los que se depende. Por ejemplo, si se quiere probar el componente ServicioCU1 del ejemplo anterior, no es necesario que se disponga del componente Persistencia. Basta con crear una implementación de la interfaz que debe implementar el componente Persistencia y que regrese los valores esperados. Esto es lo que se conoce como un “mock” (sustituto). Cabe señalar que para lograr esto es necesario hacer uso de alguna primitiva del lenguaje que permita especificar interfaces de forma independiente de su implementación. Finalmente, las pruebas de integración, como su nombre lo indica, se enfocan en probar que los elementos se conectan de forma adecuada y para ello juegan un papel fundamental las interfaces y su correcta definición.

A continuación se describen algunos aspectos de importancia que se deben considerar en relación con las interfaces.

www.sg.com.mx |

Pruebas unitarias y de integración

TENDENCIAS EN TESTING

ASEGURAMIENTO ÁGIL DE

CALIDAD —

Por Dr. Masa K Maeda

“TDD ES FANTÁSTICO PERO HAY AÚN MÁS”.

Pruebas funcionales Ejemplos Pruebas de historias Prototipos Simulaciones

Pruebas de escenarios de exporación Pruebas de usabilidad Pruebas de aceptación de usuario Alfa/Beta

Pruebas unitarias Pruebas de componentes

Manuales

Pruebas de desempeño y carga Pruebas de seguridad Pruebas de capacidades (“ility”)

Herramientas

Automatizadas

Perspectiva tecnológica

TDD Para ello hacemos uso de Desarrollo Basado en Pruebas unitarias (TDD del inglés Test-Driven Development). En breve, se trata de generar y codificar las pruebas de lo que se va a implementar primero; ejecutar el código de prueba para asegurar que falle porque el código a probar no se ha implementado; e implementar el código que pase esas pruebas. Si esto se hace bien y completo entonces ese último código es la característica indicada en la especificación con la ventaja de que jamás tuvo errores. Adicionalmente las pruebas automatizadas son la documentación (más completa y actual). Conforme ésta práctica se lleva a cabo es indispensable factorizar el código que se está generando. TDD es fantástico pero hay aún más. Desarrollo Basado en Pruebas de Aceptación (ATDD del inglés Acceptance Test-Driven Development) en el cual las pruebas son de aceptación en lugar de unitarias. Las pruebas de aceptación son creadas por el equipo técnico y sus líderes técnicos. La ventaja radica en que el énfasis está en el comportamiento esperado del código en lugar de tan solo en la validez del código.

BDD Figura 1. Cuadrante de Pruebas Ágil.

El primer cuadrante tiene que ver con probar aspectos que ayudan al equipo de desarrollo desde la perspectiva tecnológica. Utilizando herramientas se verifica la calidad mediante pruebas unitarias y de componentes. Esto es para asegurar que la funcionalidad del código y las interfaces de los módulos es adecuada. El segundo cuadrante se enfoca también en probar aspectos que soporten el desarrollo, pero desde la perspectiva de negocio. En ese cuadrante se llevan a cabo pruebas funcionales para validar lo que se está construyendo respecto a las expectativas del usuario. Esto involucra pruebas tanto automatizadas como manuales. El tercer cuadrante es para pruebas que evalúan el producto o servicio desde el punto de vista del negocio. Este es el único cuadrante en el que es aceptable sólo hacer pruebas manuales y es para aspectos de exploración, uso, aceptación y Alfa/Beta (éste último es para determinar cuál de más de una opción de funcionalidad es mejor y es determinada por los usuarios mismos).

Otro paso adelante es el Desarrollo Basado en Comportamiento (BDD del inglés Behavior-Driven Development) en el cual el énfasis es en verificar que el código hace lo que el negocio necesita en lugar de verificar si la implementación funciona. En éste tipo de pruebas se generan escenarios en adición a historias de usuario. Como pueden ver las actividades de Aseguramiento de Calidad y de Pruebas son distintas y requieren de mayor nivel de excelencia técnica de lo que en muchas industrias se considera. Es posible que algunos lectores piensen que las actividades que menciono incrementarán costos y retrasarán el tiempo de entrega. No es así. En realidad los costos y tiempos mejorarán porque más tiempo es dedicado típicamente en proyectos a la detección y resolución de defectos de lo que toma evitarlos como les he mostrado aquí. Aún muchos de los defectos que no son detectados de la manera tradicional son encontrados tarde, cuando el servicio ya está en producción o fue entregado al cliente, haciéndolo mucho más costoso. Les invito a que eleven el nivel de madurez de sus organizaciones y actividades de calidad.

.BIO El Dr. Masa K Maeda es el CEO de Valueinnova en Silicon Valley USA, Consultor Senior del Cutter Consortium, Maestro en la Universidad de Berkeley, Miembro del Comité de Dirección del Agile Testing Alliance, coautor del libro España Lean Startup Nation y autor del libro Serious LeAP que será publicado en Septiembre de éste año.

Software Guru

Perspectiva negocio

Evalúan el producto

Soportan el desarrollo

Automatizadas y manuales

El último cuadrante se enfoca en pruebas para evaluar el producto desde la perspectiva de tecnología. Las pruebas en este cuadrante se llevan a cabo de manera enteramente automatizada. Ejemplos de pruebas son seguridad y carga. Tomando un paso hacia adelante, el aseguramiento de la calidad de software no debe ser una actividad reactiva. Es decir que en lugar de enfocarnos en probar código para encontrar defectos o para verificar que defectos no existan, mejor llevemos a cabo actividades para evitar que los defectos existan.

www.sg.com.mx |

oy reconocido en la industria primordialmente por mi actividad en el ámbito de Lean, Kanban y Agile. Algo menos sabido es que también soy miembro del Comité de Dirección del Agile Testing Alliance y que en 3 de las 5 empresas en Silicon Valley que fui miembro del equipo fundador yo cree las organizaciones de aseguramiento de calidad. Así que a compartiré a continuación algunos aspectos relevantes de pruebas estilo ágil. La mayoría de las actividades de pruebas de software desafortunadamente se enfocan en hacer pruebas funcionales manuales lo cual es deficiente pues el alcance y valor agregado de ese tipo de prueba es muy limitado, resultando en productos y servicios de baja calidad. Un punto de partida para mejorar la calidad de las actividades de prueba es considerar el Cuadrante de Pruebas Ágil, el cual nos muestra el tipo de pruebas a efectuar dependiendo de los factores considerados además de recomendar qué hacer de manera manual y qué hacer de manera automatizada. Ver Figura 1.

TENDENCIAS EN TESTING

TENDENCIAS EN TESTING…

HACIA EL “CLOUD” Y EL “CROWD” —

Por Javier Garzás, Ma. Ángeles Morales y Noemí Navarro

l testing es tan antiguo como el software, pero en los últimos años ha evolucionado hasta tal punto que las pruebas se han convertido en algo estratégico y clave. Esto es consecuencia de los actuales ciclos de vida que buscan cada vez la entrega de desarrollos lo más rápido posible para acortar el llamado “time to market”. En esta línea, según estudios realizados [1], en 2013 el 23% de los presupuestos de TI se destinaron al testing, ya que las empresas cada vez son más conscientes de que el testing ayuda a reducir costes, a ser más productivos a la hora de lanzar soluciones y a conseguir beneficios económicos. Con tanta demanda y criticidad, la evolución en técnicas, tecnología y estrategias de testing no ha parado de evolucionar. En este artículo les comentaremos dos de esas evoluciones, dos nuevas tendencias que vienen de la mano del popular “cloud”, pero esta vez aplicado al testing, y que “amenazan” con revolucionar el ya llamado testing “clásico”: el Cloud Testing y el Crowd Testing.

Cloud Testing… ¿qué es? “Cloud Testing”, como su propio nombre indica surgió de la unión entre el software testing y el “Cloud Computing”. El cloud ya cambió la manera de usar el software, pasando de las licencias tradicionales al pago por uso. La tecnología de cómputo en la nube permite ofrecer servicios de computación bajo demanda a través de Internet, ofreciendo un sistema informático como servicio, acceder a servicios disponibles “en la nube”. Sus principales capas de servicios son la infraestructura como servicio (IaaS), plataforma como servicio (PaaS) y software como un servicio (SaaS). En esta línea, el cloud testing permite las pruebas bajo demanda y el pago por uso. En la actualidad podemos encontrar con que hay cada vez más empresas que ofrecen estos servicios de cloud testing ofreciendo distintos tipos de pruebas. Siendo esta una de las áreas más emergentes del testing, ya que ofrece un nuevo enfoque para preparar de forma rápida, flexible y escalable un entorno de pruebas. La nube agrega nuevas dimensiones a los modelos convencionales de testing. En lugar de comprar e instalar las herramientas y entornos de prueba, de formar a nuestro personal en las mismas,

preocuparnos de actualizar las herramientas, hoy existe la posibilidad de encontrar servicios de cloud testing para casi todo, como por ejemplo pruebas de rendimiento, de carga, de seguridad, para dispositivos móviles, etcétera. El principal beneficio del testing en la nube es que reduce costes de instalar, de mantener, de formar en cómo instalar y configurar, etc. Otros beneficios son la flexibilidad de adquirir un entorno de pruebas según sea necesario. No obstante, a pesar de estos beneficios hay otros costos que son menos obvios y más difíciles de evaluar: el cloud testing requiere conocimientos técnicos especiales para generar casos de prueba y scripts, y el manejo de la seguridad también podría acarrear costes adicionales [4]. Veamos los pros y contras con más detalle.

El Cloud Testing vs testing tradicional La realización de las pruebas que conlleva el cloud testing presenta algunas diferencias con respecto a las pruebas tradicionales de software. Respecto al tiempo de configuración del ambiente de pruebas, en el testing en la nube se tardan minutos mientras que en el testing tradicional la duración es mayor. Las pruebas de testing tradicional se realizan en un ambiente controlado, antes de que el producto sea puesto en producción, mientras que las de testing en la nube se realizan en un ambiente “público”, bajo demanda, propiedad de proveedores externos. Finalmente, los temas económicos; en el testing tradicional el costo va ligado a la infraestructura, a la instalación y al software (licencias), sin embargo en el testing en la nube el costo está basado en el uso. Obviamente, no todo es bonito en el cloud testing ni todo está resuelto. A continuación presentamos una lista de las principales ventajas y desventajas. VENTAJAS • Probar de manera más económica: comprando la cantidad justa de servidores, así como diferentes SSOO y entornos de prueba. • Mejoras en el rendimiento y en la escalabilidad.

“LA NUBE AGREGA NUEVAS DIMENSIONES A LOS MODELOS CONVENCIONALES DE TESTING”. • Probar más rápido: las empresas dedican menos tiempo a la adquisición y montaje de la infraestructura para las pruebas. • Resultados más realistas: se trabaja con diferentes entornos operativos. • Mayor disponibilidad de herramientas de prueba y soporte de aplicaciones complejas: permite a las organizaciones llevar a cabo estudios de viabilidad técnica e identificar los mejores entornos de pruebas.

funcionalidad y en la facilidad de uso de la aplicación. El crowd testing es muy útil, económico y, sin duda, ofrece una representación fiel de todos los dispositivos y clases de usuarios [3]. Al igual que hemos presentado una tabla comparativa con las ventajas y desventajas que conlleva aplicar cloud testing, realizamos otra tabla que se refiere a la aplicación de crowd testing [4].

DESVENTAJAS • Regulación y la legislación teniendo que trabajar con proveedores que estarán en otros países. • La confidencialidad. • Integrar los recursos de la nube pública con los centros de datos internos de los clientes.

VENTAJAS • Interacción con muchos usuarios. Entornos diversos que incluyen muchas combinaciones posibles. • Los testers no están relacionados con el desarrollo del producto, por lo que su opinión es totalmente imparcial. • Aplicaciones que están dirigidas a ser lanzadas en regiones geográficas se pueden probar de manera muy eficaz. • En ocasiones la empresa sólo paga por los errores reportados. DESVENTAJAS • La gestión de las pruebas de crowdsourcing pueden ser una tarea difícil. • Confidencialidad ya que el software estará a disposición de un gran número de personas antes de ser finalmente liberado en el mercado.

Concluyendo y mirando al futuro Una vez hecha la reflexión anterior y pensando en un futuro, podemos concluir que el testing seguirá en evolución, yendo cada vez a más, aprovechando las tendencias de las propias TI, haciendo uso de nuevas técnicas para ahorrar recursos, para que los sistemas software sean más fiables y de mejor calidad gracias al testing y para que se pueda probar cada vez más rápido y de manera más económica. Todo ello en línea con los tiempos que vivimos, que requieren de ciclos de mercado más cortos y por ello… de más y mejor testing.

Referencias [1] Capgemini (2013). http://www.es.capgemini.com/noticias/la-transformacion-digital-eleva-al-23-la-inversion-para-asegurar-la-calidad-del-software-en

Crowd Testing vs testing tradicional Estos dos métodos se complementan entre sí, para entregar un producto software de alta calidad a los clientes. Aun así hay cosas que un equipo de crowd testing puede hacer y cosas que sólo un equipo de testing tradicional puede hacer. Los equipos de testing tradicional se centran en el producto, cambios en ellos y en la presentación de informes de errores, mientras que los equipos de crowd testing se centran normalmente en los problemas de

[2] Garzás, J. (2012). Testing en cloud: Qué es, pros, contras y 10 proveedores que ya lo ofrecen. http://www.javiergarzas.com/2012/07/testing-en-cloud.html [3] Iglesias, A. (2012). Crowd testing: El poder de las masas utilizado para mejorar apps. http://www.computerworld.es/archive/crowd-testing-el-poderde-las-masas-utilizado-para-mejorar-apps [4] Riungu-Kalliosaari, L., Lappeenranta Univ. of Technol., Lappeenranta, Finland, Taipale, O. & Smolander, K. (2012). Testing in the cloud: Exploring the practice. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6051416

.BIO Javier Garzás. Su primer proyecto ágil fue en 2001. Hasta la fecha, ha trabajado para más de 80 empresas en gestión e ingeniería software. Es Doctor, Ingeniero en Informática y Posdoctorado en la Carnegie Mellon. Ahora, profesor de la Universidad Rey Juan Carlos y colabora con 233gradosdeTI.com Desde 2006 escribo un blog sobre tecnología, ya con más de 1000 post: javiergarzas.com. Ma. Ángeles Morales Muñoz actualmente colabora en el grupo Kybele-Universidad Rey Juan Carlos en el estudio e implantación de metodologías ágiles en general y Scrum en particular, modelos de procesos y DevOps, apasionada por la gestión de equipos e interesada en la calidad del software. https://www. linkedin.com/in/mamoralesmc Noemí Navarro Sánchez, colabora en Kybele Consulting S.L especializada en proyectos relacionados con la implantación de metodologías ágiles, Scrum y calidad del software para importantes organizaciones. Apasionada por la adaptación de herramientas de gestión a entornos ágiles. https://www.linkedin.com/in/nnsanchez92

Software Guru

La externalización de los servicios de Testing y QA es un modelo emergente entre las empresas que quieren mejorar su calidad. Y de ahí la otra tendencia que nombrábamos al principio del artículo: el “Crowd Testing” o “Crowdsource Testing”. El “Crowdsourcing”, también conocido como “tercerización masiva” o “subcontratación voluntaria”, consiste en externalizar tareas que, tradicionalmente, realizaban los empleados o proveedores, a un grupo numeroso de personas o una comunidad vía internet que voluntariamente deciden probar una aplicación. Uno de los objetivos del “crowd testing” es reducir los costos y conseguir grandes volúmenes de testers por todo el mundo, lo que permite probar el software en muchísimos entornos y plataformas… y por mucha gente. Además consigue reducir el costo-tiempo de salida al mercado y de flexibilidad. El crowd testing ha entrado en muchas compañías innovadoras para convertirse en una parte de su proceso de testing estándar, creando su propia comunidad de crowd testing, o contratando empresas que proporcionan la plataforma para el testing y una comunidad de testers que voluntariamente se han registrado para probarlo y que suelen ser pagados por bug encontrado.

www.sg.com.mx |

Crowd Testing… ¿qué es?

TENDENCIAS EN TESTING

LENGUAJES DE DOMINIO ESPECÍFICO PARA EL DESARROLLO DE

PRUEBAS AUTOMATIZADAS Por Ernesto Herrera

a diferencia entre un producto bueno y uno excelente es la calidad; a medida que una aplicación crece, es mayor el esfuerzo que debemos invertir para validar la funcionalidad. Las pruebas automatizadas nos ahorran tiempo y dinero, estas pueden ser repetidas una y otra vez durante todo el ciclo del desarrollo para asegurar la calidad del producto. Cada vez que exista un cambio, arreglo o nuevos elementos, seremos capaces de validar la funcionalidad completa, rápida y consistentemente. Nuestros casos de prueba deben poder ser ejecutados con diversos conjuntos de datos en diversos entornos, sin que esto represente un esfuerzo adicional para darles mantenimiento a medida que el proyecto crece. Las pruebas automatizadas son por sí mismas aplicaciones cuyo objetivo es validar la funcionalidad del software, por lo cual es necesario que apliquemos el mismo enfoque que el usado para crear el producto. Para demostrar cómo es que podemos diseñar pruebas altamente efectivas, haremos uso de un lenguaje específico para pruebas junto con el patrón PageObject. Los ejemplos que muestro a continuación están enfocados a la validación de aplicaciones web, sin embargo, estos mismos principios pueden ser utilizados en pruebas para aplicaciones de escritorio o móviles.

El patrón PageObject Este patrón de diseño nos permite mapear los elementos de la página en un objeto al igual que las acciones que podemos realizar dentro de la misma: agregar usuarios, actualizar descripciones de productos, etc. En esencia este modelo es una forma especializada del patrón Façade, lo que en términos simples significa que reemplazamos una API poco descriptiva por una que es más fácil de entender. Veamos el siguiente ejemplo para ilustrar este concepto, el código está escrito en Java usando Selenium: WebElement formDiv = driver.findElement(By.className(“form-group”)); assertEquals(formDiv.findElement(By.xpath(“//input[3]”)).getText(),”Guitar”);

En este fragmento de código, el API está orientado hacia los elementos HTML; ahora veamos el mismo ejemplo haciendo uso del patrón antes descrito: assertEquals(WishList.Description, “Guitar”);

Como podemos observar tenemos un objeto que modela nuestra página de WishList la cual cuenta con la descripción del producto como propiedad, aquí es más claro qué es lo que estamos validando, más importante aún, nuestro modelo nos permite abstraer la implementación específica. En el primer ejemplo, si se agrega un campo más a la aplicación, la descripción no se encontraría en el tercer input y actualizar nuestra prueba implicaría cambiar todas las partes donde aparece “// input[3]”, pero al hacer uso de un modelo solo requerimos modificar el selector en un solo lugar, lo cual facilita dar mantenimiento a nuestras pruebas. En un escenario ideal en el cual tanto las pruebas como la aplicación comparten un mismo diccionario de selectores, al momento de que el desarrollador modifique el mismo selector, las pruebas quedarían

automáticamente actualizadas; sin embargo, esto requiere una estrecha colaboración entre el equipo de calidad y los desarrolladores. Pero aun cuando no contemos con este elemento común entre aplicación y pruebas, podemos ver las ventajas que nos ofrece este patrón: • El modelo representa las pantallas de la aplicación web como una serie de objetos y encapsula las características representadas por una página. • Nos permite generar pruebas inteligibles y robustas. • Reduce la duplicidad del código en las pruebas. • Simplifica el mantenimiento a largo plazo. Este patrón de diseño nos permite crear un lenguaje específico para el desarrollo de pruebas automatizadas. Citando a Martin Fowler: “Creo que la parte más difícil de los proyectos de software, la fuente más común de fracaso del proyecto, es la comunicación con los clientes y usuarios de ese software. Al proporcionar un lenguaje claro y preciso para hacer frente a los dominios, un DSL puede ayudar a mejorar esta comunicación. “ En este caso, nuestro dominio son las pruebas, hasta ahora solo hemos creado el modelo de una página, podemos usar este mismo principio para sacar mayor provecho y definir como tal un DSL (Domain Specific Language), el siguiente ejemplo presenta una prueba que hace uso del mismo: I Login TestCase.UserName TestCase.Password And Create TestCase.NewProduct And Save

La prueba cumple con todos los requisitos que hemos planteado, ahora nos daremos a la tarea de descomponerla para ver cómo es que logramos llegar a este punto. Para este ejemplo en particular estamos usando F#, FluentAutomation y distintos modelos, uno para la página y otro para los datos.

FluentAutomation Este framework puede ser usado con Selenium WebDriver o WatiN, lo que nos permite realizar pruebas con distintos navegadores y dispositivos. Hemos seleccionado esta herramienta por su flexibilidad y porque ya incluye en su API la habilidad para implementar fácilmente el patrón PageObject. En este artículo no vamos a profundizar en todas las características de este framework, para lo cual recomiendo al lector revisar la documentación del mismo. Continuando con nuestro ejemplo, presentamos el modelo de la página escrito en C#: public class SalesLoginPage : PageObject { public SalesLoginPage(FluentTest test) : base(test) { Url = string.Format(“{0}/{1}”, TestCase.Environment, “/sales/login”); At = () =>; I.Expect.Exists(SalesLoginElements.UserNameInput); I.Expect.Exists(SalesLoginElements.PasswordInput); }

3 1

“LA PARTE MÁS DIFÍCIL DE LOS PROYECTOS DE SOFTWARE, LA FUENTE MÁS COMÚN DE FRACASO DEL PROYECTO, ES LA COMUNICACIÓN CON LOS CLIENTES Y USUARIOS”.

public SalesHomePage login(string userName, string password) { I.Enter(userName).In(SalesLoginElements.UserNameInput); I.Enter(password).In(SalesLoginElements.PasswordInput); I.Click(SalesLoginElements.LoginButton); return Switch<SalesHomePage>(); } }

nos permite escribir pruebas a modo de especificaciones. Tal como algunas herramientas para BDD (behavior-driven development), estas pruebas son legibles para más personas, además de los desarrolladores e ingenieros de calidad. Te invitamos a descargar el proyecto completo en nuestra página en GitHub donde encontrarás el ejemplo completo: https://github.com/ScioMx/SG.DSL.

Analicemos un poco este código antes de avanzar. Primero vamos a hablar del objeto TestCase, el cual es estático sin embargo los valores de sus propiedades los leemos desde nuestra fuente de datos. Para este ejemplo usamos un archivo XML, pero podría usarse otra fuente distinta (base de datos, JSON, CSV, etcétera), esto nos permite ejecutar las pruebas en diferentes entornos (local, instancia de pruebas, preproducción) o distintos usuarios. El objeto SalesLoginElements es un recurso (Archivo *.resx) en el cual mantenemos la lista de selectores, tal como hemos mencionado anteriormente. Esta lista nos permite facilitar el mantenimiento de las pruebas cuando hay cambios en la página, e incluso puede ser compartida con la aplicación web. SalesLoginPage y SalesHomePage son modelos que heredan de PageObject. Aquí hemos utilizado la convención de nombrar las acciones que podemos realizar en la página con minúsculas, esto lo podemos ver en la prueba original y solo es una nomenclatura para diferenciar estas acciones de las funciones propias del DSL (I, And, etcétera).

Conclusión

Referencias [1] Martin Fowler: PageObject. http://martinfowler.com/ bliki/PageObject.html [2] Martin Fowler: DSL. http://martinfowler.com/bliki/ DomainSpecificLanguage.html [3] Fluent Automation. http://fluent.stirno.com/docs [4] BDDfy your browser testing with FluentAutomation. http://blog.chatekar.com/bddfy-your-browser-automation-with-fluentautomation [5] Martin Fowler: FluentInterface. http://martinfowler. com/bliki/FluentInterface.html

Escribiendo pruebas en F# Ahora que ya tenemos nuestros modelos, diccionarios y fuentes de datos, sólo nos resta escribir las suites de pruebas. Para lograr esto optamos por un lenguaje funcional, ya que nos permite escribir código expresivo que podemos ejecutar de manera interactiva; F# provee la sintaxis que

[6] Selenium Project. http://code.google.com/p/selenium/wiki/PageObjects [7] Herramientas: a.https://github.com/elight/coulda b.http://jasmine.github.io/ c.http://pyparsing.wikispaces.com/ d.http://camel.apache.org/ e.http://www.parrot.org/

.BIO Ernesto Herrera es un líder técnico especializado en proyectos web y Java. Siempre está interesado en aprender nuevas tecnologías y tendencias para desarrollar software. Su meta es continuar desarrollando sus habilidades para convertirse en Arquitecto Senior de software.

www.sg.com.mx |

Es muy importante mencionar que aún cuando usemos otros lenguajes, frameworks o herramientas distintos a los de los ejemplos presentados en este artículo, es posible lograr el mismo resultado haciendo uso de los conceptos clave. Para ello me gustaría mencionar algunos frameworks/herramientas que nos permiten definir DSLs: Coulda (Ruby), Jasmine (JS), PyParsing (Python), Apache Camel (Java), o inclusive Parrot.

Software Guru

Como ya hemos visto en los ejemplos, el crear pruebas automatizadas que sirvan como herramienta para el control de calidad, utilizando el patrón PageObject y un lenguaje específico para pruebas, es una tarea sencilla.

TENDENCIAS EN TESTING

PROBANDO APIS —

Por S. Berenice Ruiz Eguino

omo bien sabemos, las pruebas de software se han convertido en una etapa imperdonable dentro del ciclo del desarrollo de software, ya sea que se trate de software de aplicación o software de sistemas. La estrategia, el enfoque, y herramientas para realizar las pruebas pueden variar cuando se trata de probar APIs. Sin embargo hay algunas técnicas que pueden igualmente ser aplicables al llevar a cabo un proyecto de testing que implique contar con una GUI (Graphic User Interface) o cuando no se cuenta con ella, sino sólo con una serie de funciones, métodos, procedimientos que requieren ser llamados. Y justo para adentrarnos un poco más en este tema, vale la pena considerar algunos conceptos esenciales, sólo para asegurar que estemos dentro de un mismo contexto. Partamos de que una API (Application Programming Interface) o Interfaz de Programación de Aplicaciones, es una colección de funciones, procedimientos o métodos que están disponibles para ser ejecutados por otras aplicaciones de software; su fin principal es ofrecer acceso a ciertos servicios y proveer de cierta capacidad de comunicación entre componentes de software. Facilitan la vida a los desarrolladores ya que pueden beneficiarse de la funcionalidad de una API, evitando así el tener que volver a programar dicha funcionalidad desde cero. Se utilizan de forma muy común en las llamadas bibliotecas. Ejemplos: • Microsoft Win32 API • OpenGL • OpenCL • CORBA • Microsoft Framework .NET • Google Web API’s • API de Twitter • API de Facebook • API REST

API Testing Entendamos éste como el proceso de someter metódicamente a evaluación, las llamadas o ejecuciones de dichos métodos, procedimientos o funciones a través de aplicaciones de software externas que ejercitarían diversas técnicas para simular el uso de dichas APIs con diversas y creativas variantes en los parámetros de las mismas, así como configurando pre-condiciones especiales en el ambiente, interactuando con bases de datos, dispositivos, archivos, etcétera, a fin de evidenciar errores. Al igual que ocurre en un proyecto de testing para evaluar cualquier otro tipo de software, se requieren las típicas fases de: Iniciación -> Planeación -> Ejecución y Control -> Cierre Entendiendo que, dentro de dichas etapas del proyecto, igualmente requeriríamos llevar a cabo algunas de las actividades básicas, como: • Análisis: entendimiento de funcionalidad y comportamiento esperado, conocer estructura y parámetros, valor de retorno esperado. • Diseño y aplicación de técnicas de pruebas: clases de partición de equivalencias, valores al límite, condición negativa, prueba funcional básica-camino feliz, etcétera. • Identificación de dependencias y características de interoperabilidad. • Diseño de pruebas: elaboración de scripts/casos de prueba –comúnmente a través de lenguajes de scripting, aunque también se pueden efectuar pruebas manuales. • Preparación de ambiente. • Preparación de datos de prueba: identificación de parámetros de entrada y valores esperados de retorno. • Ejecución de pruebas. • Reporte, administración y seguimiento de incidencias/defectos. • Obtención y análisis de métricas.

En el primero de los casos, podríamos considerar: • Configuraciones de base de datos. • Creación de scripts automatizados para las pruebas. • Creación de queries si se pretende a través de ellas realizar consultas o modificar datos. • Arrancar el servidor. En el segundo de los casos, podría requerirse: • Preparación de diversas combinaciones de parámetros para las llamadas a funciones. • Creación de ciertos objetos, previo a las llamadas a la API. • Crear las condiciones iniciales bajo las cuales se pretende realizar las diversas formas de llamadas a las APIs (de forma directa, mediante algún evento o en respuesta a alguna excepción).

Técnicas para probar APIs Se ponen a consideración las siguientes técnicas, de entre las cuales incluso existen algunas que pueden ser también empleadas en el testing convencional, ya sea incluso manual o automatizado. En el testing de APIs, particularmente se pueden considerar como base para el diseño de los scripts/caso de prueba, las siguientes: 1) Selección de parámetros y valores de retorno. Consiste en ejercitar las llamadas a funciones/métodos de la API aplicando una creativa selección de parámetros y generación de valores de retorno que evalúen éstas mediante la variación no sólo de los valores empleados sino en las formas de llamarlos (con vacíos, null, uno, dos o más parámetros, diversos tipos de parámetros distintos al tipo esperado), la secuencia en las llamadas también puede ejercitarse. 2) Condición negativa. Se recomienda validar los mecanismos para el manejo de errores y excepciones, ejercitando con diversos casos posibles que puedan evidenciar ya sea una incorrecta o ausente validación. La API debiera seguir funcionando ante una inesperada o incorrecta forma de llamada, por ejemplo: ante una lectura incorrecta de un archivo o corrupción de éste, intento de lectura de un archivo no abierto previamente, intento de uso de un dispositivo inaccesible, valores de entrada incorrectos en alguna llamada, o nombres de funciones, procedimientos, métodos inexistentes.

Por ejemplo, considerando un parámetro de entrada cuyo valor debe ser un entero entre 10 y 50, se recomendaría probar la función con los siguientes parámetros: Func(10-1); Func(10); Func(10+1); Func(0); Func(30); Func(50-1); Func(50); Func(50+1) 4) Clases de partición de equivalencias. Como ya lo explicaba en un artículo de la edición 41 de SG [1], esta técnica de pruebas de caja negra permite establecer una relación entre los elementos de un conjunto de valores que comparten cierta característica o propiedad que los representa. Esto permite reagrupar dichos elementos en clases de equivalencia válidas y clases inválidas (grupos de elementos similares) cuyos valores revelarían el mismo error si todos fueran empleados en varias pruebas. La ejemplaridad de dichos valores de entrada permite limitar la cantidad de datos a usar en las pruebas. 5) Prueba Funcional Básica (happy path). Consiste en probar el flujo básico, en este caso, considerando llamadas a funciones de la API cuyo resultado genere los resultados esperados ejecutando cada función o método también en la secuencia “normal”. Ejemplo: Inicializar(); Configurar (20,1,1); CargarDatos(); 6) Modificación de recursos accedidos por la API. Se sugiere evaluar las llamadas a la API que impliquen modificar ciertos recursos, como: modificación de registros, eliminar ciertos procesos, insertar, actualizar, remover datos de una base de datos, etc. Y una vez que se efectúen dichas tareas, asegurarse que efectivamente sean realizadas como se esperaba. Recordemos que una de las características importantes de la calidad externa del software que pretende probarse en las API’s es la interoperabilidad, es decir, “la habilidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada”[2]. Teniendo esos requisitos de interoperabilidad en mente, así como el resto del comportamiento funcional de la API y el software que hará uso de ellas, se deberá planear la adecuada cobertura para obtener las métricas objetivo del proyecto.

Referencias

3) Valores al límite. Se requiere ejercitar la API realizando llamadas a funciones donde se evalúe que éstas funcionan adecuadamente ante parámetros de entrada que contemplan valores no sólo en los límites

[1] B. Ruiz. “Preparación y Gestión de Datos de Prueba” SG Software Guru #41. http://sg.com.mx/revista/41/preparacion-y-gestion-datos-prueba [2] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary.

.BIO Sandra Berenice Ruiz Eguino es Directora de Operaciones de e-Quallity. Ha participado como Consultora Senior en proyectos de mejora de organizaciones de Prueba de Software; cuenta con certificación internacional en Pruebas por el ASTQB. A lo largo de su trayectoria profesional ha actuado también como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos nacionales e internacionales, analista y desarrolladora. Ha sido profesora de la Universidad Autónoma de Guadalajara (UAG), donde realizó sus estudios de Maestría en Ciencias Computacionales.

Software Guru

Probar una API es diferente en ciertos aspectos, dado que para empezar, muy rara vez pudiera llegar a ocurrir que se tenga una GUI. Pro esto no significa que no haya que preparar algún ambiente de pruebas. Como ya lo decíamos, son importantes tanto 1) la preparación de los artefactos y ambiente donde correrán las pruebas, así como 2) la configuración propiamente de la aplicación.

máximo y mínimo permitidos, sino además, al menos en: (N-1); 0; N; (N+1). Se sugiere un mayor rigor cuando el caso lo amerite, considerando los siguientes posibles escenarios: (LInf-1); LInf; (LInf+1); 0; N; (LSup-1); LSup; (LSup+1) donde LInf es el límite inferior y LSup el límite superior.

www.sg.com.mx |

Preparación de ambiente para probar APIs

TENDENCIAS EN TESTING

CASUÍSTICA CANDIDATA PARA

AUTOMATIZAR PRUEBAS —

Por Angel G. Terrera

ay dos enfoques a tener en cuenta aquí en relación con el área de software testing que se hará cargo de la selección de casos de prueba candidatos: a) Aquella que no ha iniciado aún proyectos para automatizar sus pruebas. b) Aquella que ha puesto en marcha proyectos de automatización y se encuentra con la intención de transitar el camino de la mejora continua.

Entiéndase por esto, a qué tan madura se encuentra el área para encarar la tarea de seleccionar la casuística candidata (es decir, los casos de prueba candidatos) para automatizar. Para las áreas del tipo (a) se les abre todo un abanico de posibilidades que deben conocer (o deberían conocer) de antemano cómo tratarlas, más que por la relación costo-beneficio. Entre ellas: • Identificar y reconocer los casos de prueba candidatos a partir de ciertos criterios definidos. • Registrarlos en una herramienta para su posterior seguimiento, control y actualización. • Gestionar la ejecución de los scripts generados, sobre la base de los escenarios candidatos seleccionados, o integrarlos con otra herramienta que los ejecute, al margen de tener muy bien planificado el proyecto en sí mismo. Para las áreas del tipo (b) se les abre otro abanico de posibilidades porque deben reconocer de los procesos que se encuentren automatizados, aquellos escenarios de prueba que por su característica y/o resultado, deben comenzar a “separarse” como mejores candidatos para ir mejorando la performance de las corridas, de manera progresiva. A continuación enumero algunos factores que deberían considerarse a la hora de seleccionar candidatos para automatizar, dependiendo del tipo de escenario que se tenga que someter a prueba. 1. Herramienta de Automatización: la herramienta debe poder soportar la o las tecnologías sobre la que está construida la aplicación. 2. Disponibilidad de tiempo para las pruebas: el automatizar desde cero nos puede costar hacer el script hasta el doble de tiempo de las pruebas manuales. 3. Frecuencia de uso de la aplicación: Se valora si se usará constantemente, si se usará esporádicamente, o solo se usará una vez, esto para saber si conviene o no, dedicarle el tiempo para automatizar. 4. Complejidad de la aplicación: dependiendo de ésta habrá que evaluar si probar ciertos casos candidatos, ya que el esfuerzo inicial es elevado. 5. Estabilidad y variabilidad de la versión: Si se cuenta con una versión estable de cambios, es candidata a ser automatizada, sin dejar de considerar su variabilidad. 6. 100% automatización: dependerá de cuánta intervención humana tenga el escenario a probar. 7. Flujo principal: Identificar/Reconocer/Evaluar aquellos escenarios que se hayan definido como principales y sus respectivas condiciones de

prioridad (críticas, importantes, urgentes) que se alinean a las reglas de negocio principales. 8. Evitar automatizar todo: es el error más común intentar automatizar todos los casos de prueba, ya que los scripts de automatización deberían ser un apoyo a las pruebas manuales y no el reemplazo de ellas. 9. Evaluar combinación 3 y 7: Aquellos casos de prueba vinculados con el core de la aplicación y que se pueden construir al principio del proyecto, para luego utilizarlos (adaptación mediante) en el resto del desarrollo y vida del software. 10. Costo de la automatización asociado al caso de prueba: evaluar su complejidad para decidir si se continúa con el proceso de automatizar o bien, se lo deja para ejecutarlo manualmente. 11. Proyecto de antenimiento: identificar historial de incidentes como fuente de información. 12. Pensar en el público: ¿Quién va a leer y a utilizar los casos de prueba seleccionados? 13. Tipos de Pruebas: considerar algunos escenarios propios de ciertos tipos de prueba (por ejemplo UAT, Regresión, Smoke). 14. ROI: el retorno de la inversión (ROI) para el negocio que tenga cada uno de los scripts, propio de cada empresa. 15. Número de pasos y verificaciones: la complejidad la da el número de pasos (acciones) y puntos de verificación (resultados esperados) que tenga cada uno de ellos. Ahora bien, mucho tendrá que ver el tipo de proyecto en el que participemos, ya que el tratamiento a seguir no es el mismo para proyectos tradicionales (en cascada) que ágiles. No está de más aclarar que la generación manual de casos de prueba es una tarea que se torna más compleja y costosa, a medida que el sistema a probar aumenta en complejidad y tamaño, y por ese motivo es tan importante hoy en día, más que nada por el time-to-market a cumplir, utilizar técnicas que permitan generar la automatización de los casos de prueba seleccionados previamente como mejores candidatos. Algunas posturas relacionadas a la hora de evaluar los mejores candidatos, enuncian: • Escenarios que no pueden fallar bajo ningún concepto. • Funcionalidades que si faltasen tendrían un impacto negativo en el cliente. • La selección comienza con aquellos casos que cubren las funcionalidades principales. • Casos con complejidad media de negocio, es decir, que no sea muy costoso automatizarlo. Sin lugar a dudas, a partir de este contenido podremos profundizar en el próximo artículo acerca de situaciones un poco más concretas y “bajando a terreno”, como se suele decir habitualmente. Nota del autor: El contenido de este artículo fue extraído de partes de comentarios dejados por los miembros del grupo TESTING & QA en LinkedIn, a partir de debates generados. .BIO

Angel G. Terrera es Fundador de TestingBaires.com, webSite dedicado a la difusión de la actividad del Software Testing. Angel es ISTQB Certified Tester. webmaster@testingbaires.com www.testingbaires.com @testingbaires

www.sg.com.mx |

Software Guru

.PRÁCTICAS Calidad

El Futuro es Hoy ›› Por Ana Vázquez

MOPROSOFT Y LA ISO/IEC 29110 VISTAS DESDE EL EXTRANJERO

a semana pasada me di cuenta que el futuro que habíamos visualizado para MoProSoft llegó. Por un lado un consultor de procesos de software canadiense me dijo que estaba trabajando con sus clientes para implantar la ISO/IEC 29110, “por fin una norma que avala todo lo que le digo a mis clientes” externó. Por otro lado, vi que Brasil lanzó un paquete de formatos para la adopción de la norma en Portugués, Inglés y Español, lo que para mí es un claro indicador de que ya se subieron a la norma internacional, pues algunos lo dudábamos debido a que tienen una norma nacional bastante consolidada . Mi júbilo aumentó cuando tratando de explicar a mi colega canadiense sobre la situación de los procesos de software en México encontré que en el 2013 México reporto 58 evaluaciones CMMI ocupando con esto el 4º lugar a nivel mundial. También encontré que hay más de 300 evaluaciones en MoProSoft y que ya hay 5 empresas evaluadas en la ISO/IEC 29110. El asombro del canadiense era evidente, después de hablar un poco sobre precios me dijo “no sabía, voy a mandar a desarrollar mi software allá”, en ese momento pensé “lo estamos logrando”. Estaba en este tenor cuando leí la columna de mi querida Dra. Oktaba, con quien he tenido la fortuna de trabajar en forma intermitente desde finales de los 90. Ella estaba muy lejos de compartir la euforia en la que yo estaba inmersa, fue entonces cuando decidí, contrario a mi costumbre, sentarme a escribir estas líneas para compartir la visión que teníamos en el 2006 cuando presentamos MoProSoft ante ISO/IEC y como hoy desde el extranjero la veo convertida en una realidad.

Un poco de historia

La primera visionaria fue Gloria Quintanilla quien, cuando se enteró del esfuerzo que se estaba haciendo en ISO/IEC buscó la oportunidad de hablar sobre MoProSoft al Dr. Claude Laporte, una de las personas que está liderando el esfuerzo. Él a su vez invitó a 36

México a unirse al grupo. En aquel entonces, Gloria en su calidad de presidenta de la (lamentablemente extinta) AMCIS gestionó la participación de México ante el grupo de ISO/IEC. Cuando todo estaba listo un contratiempo personal no le permitió asistir, y fue así como Jorge Palacios y una servidora haciendo milagros con el presupuesto que teníamos e invirtiendo de nuestras propios ahorros nos lanzamos a la aventura de hacer que la norma internacional se pareciera lo más posible a la norma mexicana, que fue el objetivo que nos fijamos en el órgano de normalización nacional. Cualquier otro resultado a largo plazo hubiese sido desastroso para las empresas que ya habían invertido en MoProSoft, pues habría otro estándar internacional con el mismo objetivo y dirigido al mismo sector, al que las empresas que quisieran un distintivo internacional tendrían que migrar. Como buenos mexicanos, muchos se quejaron amargamente de que Jorge y yo hubiésemos asistido a la reunión en lugar de alguien mejor calificado y estoy de acuerdo, habían muchos colegas mejor calificados que nosotros para ir. Sin embargo creo que pocos nos hubieran ganado en entusiasmo y seguridad al llevar un producto de clase mundial, elementos que logramos transmitir en la presentación, logrando que nuestra norma fuera elegida como base para los trabajos del grupo, sobre otras que se habían analizado provenientes de diversas partes del mundo, logrando con ello un objetivo que nadie se atrevió a proponer, por parecer más bien un sueño guajiro. Gracias a ello hoy, mientras otros países están conociendo, adoptando y preparando los entes de normatividad para comenzar a hacer las evaluaciones, en las listas del NYCE ya hay 5 empresas evaluadas, y más de 300 evaluaciones en MoProSoft que incluye casi en su totalidad la norma ISO/IEC 29110. Es hoy cuando estas empresas mexicanas pueden salir a buscar oportunidades con una referencia internacional de calidad, es hoy cuando tienen esa ventaja competitiva y me da un gusto enor-

.PRÁCTICAS Calidad

¿Qué estamos haciendo el equipo México por la ISO/IEC 29110? El ente relacionado directamente con la norma es la CANIETI en su calidad de comité espejo del grupo ISO/IEC JTC1, ahora es clave que la delegación mexicana, encabezada por Claudia González, siga contando con el apoyo necesario para seguir participando en las reuniones internacionales, para que los futuros perfiles de la ISO/IEC 29110 también sean hermanos gemelos de MoProSoft. Hice una búsqueda rápida en internet en inglés sobre la norma, encontré información proveniente de Canadá, EEUU, Irlanda, Brasil, Perú, y Finlandia un país bastante lejano y diferente al nuestro. De México encontré un trabajo de la UNAM y un webinar de SG, ¡necesitamos más! si no queremos que Brasil nos “coma el mandado”, pues en esa misma búsqueda vi que son ellos quienes están capacitando evaluadores en Irlanda.

Irlanda fue uno de los países a los que la Secretaría de Economía pidió ayuda para comenzar a delinear la estrategia del programa PROSOFT, recuerdo claramente a un Irlandés, que con la amabilidad que los caracteriza, nos dijo que en su país para mejorar la industria de software habían trabajado en mejorar sus procesos. Paradójicamente después de unos años ellos mismos están adoptando la norma que generó México para seguir su recomendación, este hecho nos debe dar una perspectiva adecuada del avance que hemos logrado. Como consultor de procesos de software, desde Canadá les digo que contrario a lo que se podría pensar, el conocimiento tengo sobre MoProSoft e ISO/ IEC 29110 es más exportable que el que tengo en CMMI pues de este modelo, a pesar de ser muy reconocido, hay muy pocas iniciativas de implantación, debido a que es muy caro para el entorno de este país. Para concluir me gustaría ver los números de otra forma, alrededor de 300 empresas que ostentan una evaluación de procesos de software muy cercana a la norma internacional, con la posibilidad de utilizar dicha certificación para generar confianza en clientes y socios tanto en México como en el extranjero, así como una infraestructura funcionando para que las empresas que así lo deseen tenga los medios para obtener la certificación. Adicionalmente las empresas evaluadas tiene la posibilidad de integrarse para competir con empresas más grandes por proyectos que estarían fuera de sus capacidades, ya que MoProSoft facilita la integración a nivel operativo, porque tiene la virtud de ir más allá de una la lista de requerimientos. El futuro es hoy y hay que aprovecharlo. .BIO Ana Vázquez actualmente estudia la maestría en Calidad en la Universidad de Concordia en Canadá, y es representante de Praxis en el área de Quebec. Fue pionera en la adopción del PMBoK, revisora reconocida de su versión 2000, ha implantado ISO 9000 y CMMI. Colaboró en la adopción de MoProSoft como norma nacional, y se desempeñó como jefa de la delegación en las reuniones del comité ISO/IEC JTC1.

www.sg.com.mx |

me ver que algunas lo están haciendo, ya que en marzo pasado al menos una de ellas que vino a Montreal en busca de negocios con su evaluación MoProSoft bajo el brazo. Por una coincidencia providencial, sé de primera mano que esta semana va a ser contactada por una empresa canadiense que le va a proponer un negocio. Esta PYME mexicana se ganó esta oportunidad seguramente gracias a muchos años de trabajo arduo, a su certificación pero sobre todo a su osadía de haber venido a buscar negocios al primer mundo sin complejos. Ya sé lo que están pensando “China y la India tienen más evaluaciones”, y lo que al respecto yo les diría que la ventaja de estos países no está en sus evaluaciones de calidad si no en algunos aspectos de su cultura, misma que tuve oportunidad de conocer de cerca cuando un equipo de Indios me admitió en su equipo de trabajo en una de mis clases de maestría. La primera junta fue para persuadirme sobre las ventajas de trabajar realmente como un equipo, fue entonces cuando aprendí que en su lengua materna (una de tantas de aquel país) cuando se habla de trabajo y de gente 1 más 1 no es 2 si no 11.

Software Guru

Necesitamos más, si no queremos que Brasil nos “coma el mandado”.

.PRÁCTICAS Gestión

Acercando el Producto de Software al Negocio ›› Pilar Barrio, Rodrigo Guzmán y Raúl Martínez

ste trabajo resume los pasos seguidos por una empresa en un ambiente híper competitivo como es el comercio electrónico y las decisiones técnicas y organizacionales que tomaron para mejorar su desempeño. Se analizan éstas luego para extraer conclusiones aplicables a cualquier empresa.

cumplidas. Los indicadores de éxito estaban referidos a un producto con baja tasa de errores. Ver Figura 1

El escenario previo Arquitectura técnica

Originalmente la plataforma de e-commerce fue monolítica y cerrada. Su base de datos y su código estaban centralizados. El diseño de esta arquitectura fue pensado para generar ventajas competitivas, pero con altos costos en pérdida de flexibilidad y riesgos ante cambios.

Impacto de las fallas En este esquema monolítico, centralizado y cerrado, un defecto producto de un error en el desarrollo, tenía una alta probabilidad de impacto cruzado en distintas partes de la aplicación con su consecuencia directa e importante en el negocio. El riesgo asociado a un defecto latente era muy alto y los efectos no deseados sobre el negocio podían ser significativos. El foco estaba puesto en corregir los defectos.

Procesos de desarrollo Los procesos se diseñaron bajo la premisa de evitar errores resultando en ciclos de desarrollo y pruebas extensos, difíciles de escalar y con un “time-tomarket” poco acorde a la industria de e-commerce. Los ciclos de desarrollo-liberación eran extensos, con semanas/meses en pruebas, frecuencia de liberación – “release”- quincenal y en ocasiones mensual.

Figura 1. Escenario visto como una pirámide.

El nuevo escenario Arquitectura técnica

Se produjo un cambio radical cuando la plataforma dejó de ser un sitio web para convertirse en una plataforma abierta de e-commerce. Se rediseñó la arquitectura para abrir la plataforma y descentralizar tanto la base de datos como el código fuente, permitiendo distribuir la aplicación en distintos departamentos de la organización.

Impacto de las fallas La nueva arquitectura eliminó fricciones y dependencias funcionales y técnicas existentes entre los módulos en el modelo monolítico. El riesgo se distribuyó y esto obró como factor de cambio en la organización y en el negocio.

defectos, sino de lograr un producto con la calidad suficiente para no afectar los indicadores del negocio. El impacto de los defectos en el producto no es ya la fricción principal en el negocio: Esto permite manifestarse al resto de las variables que afectan al negocio y que antes no formaban parte explícita de la definición interna de la calidad del producto. Los nuevos indicadores e incentivos definidos requieren un comentario adicional. Ya no es suficiente evitar errores en el producto, o asegurar el funcionamiento y la disponibilidad de la plataforma; se trata de dar a los usuarios lo que necesitan y como lo necesiten, satisfaciendo sus expectativas y logrando una experiencia que diferencie a la empresa de la competencia. Hay espacio para equivocaciones, pero existen mecanismos sensibles de alertas y procesos de cambios y corrección muy agilizados. Para monitorear el comportamiento de las nuevas variables se consideraron varios niveles de indicadores, como muestra la pirámide de la Figura 2. Este escenario puede visualizarse completando la pirámide de la Figura 1 con otros dos niveles: producto útil para el usuario y, si esto se cumple, producto exitoso para el negocio. Los indicadores de éxito se relacionan en la base con la baja tasa de errores, y hacia el vértice, se definen en relación a los KPI’s que interesan al negocio, no olvidando además la satisfacción de los clientes. Nivel 1 (base) - Escalabilidad Nivel 2 (base) - Funcionamiento Core Nivel 3 (base) - Usabilidad Nivel 4 (medio) - Customer Satisfaction Nivel 5 (vértice) - Rentabilidad Nivel 6 (vértice) - Competitividad

Organización Se generó una dinámica organizacional poco tolerante a los defectos, con incentivos alineados a evitar y prevenir cualquier tipo y magnitud de defecto. Equivocarse no era bien visto, por lo tanto la capacidad de innovar e iterar tendió a reducirse. El concepto de calidad de producto era elemental y estaba definido en términos de cantidad de defectos. Las métricas y objetivos a lograr se diseñaron bajo ese concepto y se enfocaban en medir y controlar cantidad de fallas en producción. Este escenario puede visualizarse como a base de una pirámide. En él, el esfuerzo estaba puesto en un producto sin defectos y con el resto de las características

Procesos de desarrollo Se establecieron procesos ágiles de desarrollo y prueba permitiendo aumentar la frecuencia de pruebas, cantidad y paralelismo de los cambios, mejorando la velocidad de implementación y corrección de defectos. Se pasó de tener una única implementación quincenal a tener casos de más de ochenta pasajes a producción en un mismo día.

Organización La nueva perspectiva introdujo un cambio radical en la dinámica organizacional, enfocando y alineando a los equipos de trabajo con la mejora continua y el cambio constante, no tratando de prevenir todos los

Figura 2. Pirámide completa

.PRÁCTICAS Gestión

Los siguientes aparecen como interesados principales: La Empresa, que requiere un producto ágil y ampliable, competitivo en funcionalidad, con costos aceptables de desarrollo y operativos, medido mediante indicadores que relacionen el comportamiento del producto y el del negocio.

y planificación de nueva funcionalidad o cambio, hasta su puesta en Producción y posterior evolución. Se disolvió el QA centralizado reasignando sus integrantes a los nuevos equipos. Se implementó la función de Business Assurance, que controla el producto en operación y analiza el impacto de su comportamiento en el negocio mediante indicadores.

Para satisfacer al universo de interesados, la Empresa encaró cambios radicales en la arquitectura del producto, los procesos de negocio y técnicos, y la organización que los soporta.

Analicemos los cambios

Próximos pasos

El cambio tuvo como finalidad que ésta no fuera una traba para cumplir las expectativas de la Dirección y grupos responsables del producto en cuanto a agilidad en los cambios y clara responsabilidad de los intervinientes. Los visitantes/usuarios observan un comportamiento estable y similar en el producto, o mejorado en algunas funciones. El costo de lograr este comportamiento es menor, algo no visible al visitante, pero sí a la Organización.

Continuar la detección de interesados, además de los visitantes y comerciantes, ampliando a otros con expectativas sobre el producto: comunidad de desarrollo externa, auditores, seguridad informática, etc. Entendiendo la influencia y comunicación con cada uno.

El Grupo de Desarrollo que requiere un producto construido de modo tal que les permita satisfacer el Time-tomarket, mantenible, posible de ser probado y auditable.

Arquitectura

Procesos de desarrollo El proceso convencional de desarrollo y mantenimiento, adecuado para un producto monolítico y altamente acoplado, se cambió por prácticas ágiles.

KPIs del negocio Continuar midiendo “features” del producto por los resultados sobre el negocio. Las medidas deben ser accionables, y se debe poder relacionar el KPI del negocio con el producto, para intervenir si es necesario.

Indicadores El producto y organización originales, no mostraban cómo los indicadores técnicos se relacionaban con los del negocio (ver Figura 1). No existía una relación directa entre las acciones a tomar en el producto para corregir o potenciar situaciones de negocio. Los distintos niveles de indicadores (ver Figura 2), permiten ahora detectar la calidad en uso del producto para los interesados y efectuar mediciones que delimitan sobre qué parte del producto accionar si fuera necesario. Estos indicadores accionables, en forma indirecta, establecen si se cumplen los objetivos de negocio dependientes del producto, posibilitando dar incentivos a los responsables de las distintas partes de la plataforma de la Empresa en función al cumplimiento de dichos objetivos.

El Visitante/usuario, que requiere un producto confiable y maduro, completo en funcionalidad, sencillo de utilizar, seguro y de buena performance.

luar la calidad ofrecida. El software será visto entonces como homogéneo, ya sea el producto base o sus extensiones. Aquí resultan aplicables los modelos establecidos en la industria de calidad de sistemas y de productos de software.

KPIs del producto Desarrollar nuevos KPIs que midan la calidad técnica del producto, para pronosticar su calidad final. Como se mencionó anteriormente, aquí aplican los modelos de calidad de software y las métricas que proponen.

Mejora continua Compenetrar al personal técnico del producto cada vez más en el negocio, ya que el negocio se basa en el producto, completando así un ciclo para mejorar la calidad del producto haciéndolo más competitivo y exitoso.

Conclusiones

Interesados

Se mostró cómo esta Empresa: • Colocó en el centro al cliente y al producto y no a la tecnología. • Relacionó el negocio con el producto de software y el éxito en el negocio con la calidad de dicho producto. • Cambió su organización y modelos de trabajo para adecuarlos a los tiempos y necesidades que demandaba su mercado. • Dio, intuitivamente, los pasos necesarios para considerar todo el contexto en el que el producto de software estaba inserto y reaccionó ante ese contexto. • Los próximos pasos propuestos intentan hacer más visibles y analizables estas decisiones consolidando aún más la calidad del producto que se está logrando.

Detección y priorización de expectativas Realizar encuestas o consultas instantáneas a los visitantes/compradores y comerciantes para entender sus expectativas. Utilizar herramientas como el Modelo Kano y los Mapas de Empatía para detectar y priorizar requerimientos y expectativas.

Modelo de calidad y evangelización Organización La organización original evolucionó en paralelo con los nuevos procesos, para satisfacer expectativas de time-to-market, responsabilidades, costo de cambios, e indicadores de comportamiento producto / negocio. Se formaron equipos pequeños, descentralizados y multifuncionales responsables desde la definición

Formalizar en la medida necesaria y posible, el conocimiento tácito de calidad para la Organización y transmitirlo a los equipos propios, a terceros y a otros interesados mediante reuniones y eventos. Ejemplo, al desarrollador que amplía el producto de la Empresa mediante APIs, la formalización le permitirá comprender la calidad esperada, y a la Empresa, eva-

Si bien este análisis es de un caso en particular, permite extraer conclusiones aplicables a otras organizaciones que quieran lograr una mayor y mejor relación entre sus productos de software y el negocio en el que se aplican.

.BIO Pilar Barrio la Iglesia fue docente universitaria en distintas materias relacionadas con la tecnología informática. Socia fundadora de RMyA S.R.L., especializada en consultoría sobre aseguramiento de calidad y testing. pbarrio@rmya.com.ar Rodrigo Guzmán es Gerente Senior de Desarrollo de Producto en MercadoLibre empresa líder de comercio electrónico. Responsable de varios proyectos de desarrollo de producto, principalmente la verticalización de la plataforma para las principales categorías. Lic. en Admón de Empresas, postgrado en Calidad y Gestión y Certified Scrum Master. rodrigo.guzman@mercadolibre.com Raúl Martínez se especializa en Gestión de Proyectos de TI y calidad de productos de software. Docente de la Facultad de Ingeniería (UBA). Socio fundador de RMyA SRL interesado en mejora de procesos, gestión de proyectos, gestión de la calidad. rmartinez@rmya.com.ar

Software Guru

Tratando de interpretar las decisiones más importantes tomadas surge: Interesados y sus expectativas.

www.sg.com.mx |

Análisis del caso

.COLUMNA DevOps

DevOps ¿Qué es? P

ara las metodologías de desarrollo de software la meta final será siempre entregar un producto funcional al usuario. Esto comprende un conjunto de pasos que abarca desde la conceptualización de la aplicación hasta su instalación y mantenimiento. Con una visión cerrada y limitada del manejo de la aplicación, el equipo de desarrollo trabaja incansablemente para encontrar la manera óptima de poder entregar en tiempo y forma el resultado de su trabajo. Al sólo preocuparse de construir y liberar, el equipo de desarrollo entra en una constante fricción con el área de sistemas encargada de implementar esta nueva aplicación: Infraestructura (Operaciones). A fin de cuentas, el equipo de Infraestructura es el último manipulador de un sistema de software previo a su liberación a ambiente de Producción. Historias de terror se cuentan de ese paso del ambiente de Desarrollo a Producción: conflictos, desvelos, fines de semana, marchas de la muerte. Esto genera un esfuerzo mal enfocado donde por un lado el área de Desarrollo busca demostrar que la construcción del producto fue correcta para poder alcanzar su liberación, mientras que el área de Infraestructura se dedica a demostrar que aunque por fuera la manzana es roja, en su interior guarda un conjunto de problemas al intentar ser instalado. Conflicto seguro entre las áreas de Desarrollo e Infraestructura. Acuñado por Patrick Debois [1] en 2009 para un evento tecnológico de nombre DevOpsDays en Bélgica, el término DevOps no tiene una definición formal. Esto genera un conjunto de definiciones que enriquecen el alcance y características del concepto. DevOps no es un software, no es un título/puesto, no es un estándar. No formalizado de manera escrita, el movimiento DevOps es generado de practicante a practicante, a partir del conjunto de experiencias reales que se comparten por medio de una comunidad que colabora de forma descentralizada y abierta. Basta revisar el hashtag #Devops en Twitter para verificar la constante participación y flujo de ideas al respecto. Con la interacción de los conceptos de Ágil, Kanban, Integración Continua y Cloud Computing el movimiento reúne al área de Desarrollo e Infraestructura en una visión global en el ciclo de vida de la aplicación para la entrega de valor al negocio. Ver Figura 1.

Uso de Ágil y otras metodologías de software

Las metodologías ágiles se destacan por la continua entrega de pequeños pedazos de código funcional a un ritmo y velocidad. Entregas que solo abarcan el ciclo de vida de software y al área de Desarrollo, dejando de fuera todo aquello que conlleva la administración de la configuración y la preparación de los componentes para su liberación a Producción. El ritmo generado por las metodologías ágiles como Scrum y Kanban empuja componentes al área de Pruebas e Integración para que al finalizar de manera exitosa, se entregue a Infraestructura de manera continua y rápida para su instalación, siendo un problema cuando Pruebas o Infraestructura tienen la costumbre de liberar en ventanas de tiempo ya definidas y controladas. Esto genera presión entre todas las áreas involucradas, no todos fueron preparados para trabajar ágilmente y ahora el exceso de entregables rompe con las rutinas prestablecidas de trabajo. En el caso de peticiones continuas para la resolución de nuevas funcionalidades o incidentes en el código con un flujo de trabajo limitado se implementa Kanban. Kanban que utiliza la teoría de restricciones sobre el trabajo en progreso (WIP), este da las herramientas para que no importando el área involucrada el trabajo sea atendido ágilmente y se vea como un todo y no silos de funcionalidad en sistemas.

Amplia disponibilidad de Virtualización en la nube

Si las liberaciones continuas alteran la operación en el área de Infraestructura, la administración, prueba y configuración en el ambiente de Producción del nuevo producto se vuelve algo complejo, ya que los tiempos de implementación y los respectivos ambientes de trabajo, deben de cumplir con los requisitos del producto para su funcionamiento (ej. El ambiente de Desarrollo nunca es igual al de Producción). La complejidad de esto se resuelve con la virtualización de ambientes, que pueden crearse y atenderse de una manera tan rápida que vaya a la par de las entregas del área de desarrollo. Además de utilizar máquinas virtuales, también se está popularizando la utilización de contenedores, 40

.COLUMNA DevOps

›› “Se debe revisar la composición de los procesos del área de tecnología para poder mapear el valor generado y eliminar el desperdicio existente entre tareas”.

como Docker. Si se trabaja con un nuevo desarrollo, se debe de preparar todos los elementos relacionados de ambiente al mismo tiempo, pruebas, control de versiones, etc. Esto permitirá involucrar al área de Infraestructura desde el inicio del proceso de desarrollo y estará lista para avanzar con el proyecto. A esta respuesta a la metodología ágil de desarrollo se le llama Infraestructura Ágil. La administración de la configuración es un tema importante para la administración de los ambientes virtuales, así como la administración de la infraestructura como código bajo esquemas como SaaS y APIs que permiten el manejo de la infraestructura en la nube. Esto disminuye el impacto de la entrega continua generada por las metodologías ágiles. Figura 1. Esquema DevOps.

toda la línea de liberación, para poder implementar la mejora continua. Las entregas se realizarán de manera más rápida al negocio, generando el valor esperado. La innovación estará presente al momento de generar la colaboración entre áreas. Toda esta mejora en proceso y administración se ve apoyada por la automatización del software para realizar las tareas, desde los sistemas de administración de la configuración, pasando por los sistemas de pruebas automáticas, hasta la generación automatizada de ambientes virtuales para la puesta en marcha de los productos tecnológicos. Estos elementos técnicos ya existían el mercado, ahora con DevOps se les da relevancia y apoyan para que el flujo de trabajo sea continuo en el proceso de liberación de productos. Todo esto implica un cambio cultural, una reestructuración de la relación entre Desarrollo e Infraestructura para buscar el bien común del negocio y generar valor al cliente. ¿Complicado? Solo el tiempo lo dirá, la madurez de las áreas y la organización debe permitir ejecutar este nuevo enfoque sin problema. Esos raspones que existen entre Desarrollo e Infraestructura pueden sanar si se implementa una filosofía de métodos ágiles y nos empeñamos en alcanzar la colaboración y comunicación que los distinguen.

>> Por Ismael Villegas

Referencias [1] Barton Geroge, DevOpsDays Austin: Patrick Debois Recuperado de https://www.youtube.com/watch?v=xL3iW-F3Gqw y CityTV.nl, T-DOSE 2010, Dev/Ops to DevOps, Patrick Debois and Kris Buytaert Recuperado de https://www.youtube.com/watch?v=ty6iHN4EilY

Software Guru

Con ambos escenarios en la mesa, se forma el movimiento DevOps que remueve las barreras entre Infraestructura y Desarrollo para generar valor al cliente. Con un esfuerzo combinado se busca generar la inercia suficiente para responder ante el cambio continuo del negocio. Generar una entrega continua exige un manejo ágil en el desarrollo de software y la infraestructura, flujos continuos de trabajo bajo tiempos definidos. Se debe revisar la composición de los procesos del área de tecnología para poder mapear el valor generado y eliminar el desperdicio existente entre tareas. Conviene implementar una política de cero tolerancias a errores y si estos se presentan, tener la capacidad de detener el flujo de trabajo tanto en Desarrollo como en Infraestructura para verificar la situación. Para alcanzar la mejora continua se debe de resolver desde el principio cualquier error que se presente. Los silos que se generan entre las áreas que promueven la liberación de la aplicación a producción deben de desaparecer, la integración entre las áreas de Desarrollo e Infraestructura debe ser completa en el sentido de responsabilidad sobre los componentes que se generan. Los problemas son compartidos, se tiene que superar la visión cerrada que cada área tiene sobre las responsabilidades que desempeña. Trabajando con la filosofía de que el área de Tecnología es un gran sistema que trabaja en conjunto para generar valor al cliente esto facilita el compromiso de las áreas involucradas. Los problemas al liberar a Producción no son problemas individuales de las áreas sino son problemas de negocio que restan la generación del valor al cliente. Se tiene que enfocar el esfuerzo en hacer con calidad los productos tecnológicos, de forma integral (Desarrollo-Infraestructura) y no sólo generar productos por generarlos. La generación del producto debe someterse a métricas que evalúen

Ismael Villegas, PMP, CSM, CTFL es docente a nivel Maestría y Licenciatura, consultor de sistemas en el manejo de desarrollos de software y administración de proyectos tecnológicos en el ramo de instituciones financieras por 17 años. Ha participado en proyectos globales de desarrollo e implementación de software con entidades en Brasil y Estados Unidos, actualmente revisando temas de implementación de arquitectura empresarial en instituciones financieras.

www.sg.com.mx |

Incremento en las entregas a producción

.COLUMNA Pagos Móviles

Análisis de la Situación Actual de los Pagos Móviles,

desde la Perspectiva de un Usuario de la Banca

s un hecho que los pagos móviles son el presente y el futuro, lo que no está claro es la velocidad de adopción por los consumidores y las diferentes variantes que tendrán estos. El futuro del dinero y del comercio está ligado a romper las barreras y ampliar el acceso a cada vez más personas, derivando en la verdadera inclusión financiera, que no es más que la incorporación de toda la población en operaciones financieras (bancarias y no bancarias), sin importar su nivel de ingresos o su ubicación geográfica, a un precio que resulte factible y con una usabilidad que considere la diversidad de nivel educativo. Un factor importante en la adopción de las plataformas móviles, pueden ser las mujeres, que en los últimos 10 años, han eliminado la brecha digital de genero en México, pues tenían una participación del 46% en el uso de computadoras o teléfonos inteligentes, y que en el último año tienen ya el 50% de participación [1]. Adicional a esto, las mujeres son el cliente principal de muchas entidades financieras (principalmente SOFIPO´s y SOFOMes), especializadas en los créditos grupales y ligados con actividades productivas o comerciales, con lo cual toda estrategia enfocada en las mujeres, puede significar la detonación del uso de los pagos móviles, además de auxiliar en el desarrollo de la economía. El uso de los pagos móviles en aquellas poblaciones con mayor dificultad de acceso a los servicios financieros tradicionales, representa una disminución de la pobreza, pues es un hecho que son esas poblaciones las que tienen las tarifas y comisiones más altas, ya que no se tiene competencia alguna y el jugador que opera en esa plaza aprovecha dicha situación. La incorporación de los pagos móviles puede erradicar por completo estos monopolios, sin embargo será necesario la interacción de los diversos actores y la generación de alianzas entre los mismos, para que la oferta de servicios y productos que puede ofrecer una plataforma móvil tenga la misma o mayor amplitud de opciones y beneficios que puede ofrecer la banca tradicional, pues de no hacerlo, lograr el objetivo llevará más tiempo y en algunos casos será una labor imposible.

Dichas alianzas no deben descartar a la misma banca, pues en muchos casos sus modelos actuales se fundamentan en la tecnología que tienen hoy dentro de las instituciones.

Soluciones y plataformas

Hasta el momento la mayoría de las soluciones de pagos móviles se han centrado en el envío de dinero o remesas nacionales, recargas de tiempo aire, pagos de servicios y en algunos casos pagos de préstamos. Solo una solución ya ofrece la contratación de micro-seguros y micro-pagos, aunque este servicio puede considerarse como parte de la siguiente versión de las plataformas móviles. Lo mismo sucede para el micro ahorro y los micro créditos, que pueden derivar en la popularización del uso de este tipo de tecnologías, además de tener servicios disponibles que hoy solo tienen los usuarios de la banca por Internet, (La Banca por Internet sólo es utilizada por cerca de 4.5 Millones de personas en México, según el estudio de la AMIPCI sobre el uso de la banca [2]), pero la adopción de los pagos móviles, no solo debe representar una disminución en los costos de transacción para los usuarios, es esencial que derive en un mayor control . También el uso de las plataformas móviles tiene un gran potencial en el comercio electrónico, que aún no tiene el despegue que se espera en México, pues solo el 20% de la población que utiliza Internet realiza transacciones de compra, contra un 19% que realiza transacciones con la banca [3] . En el caso de las transacciones de comercio electrónico, la mayoría de las operaciones que no se realizan con el pago de tarjeta, consideran dentro de su proceso de compra, actividades manuales (como impresión y envío de comprobantes al comercio). Las plataformas de pagos móviles, pueden revolucionar todo el sector de minoristas o pequeños comercios, que hoy frente a las grandes cadenas están perdiendo terreno cada año e incluso desapareciendo. Con los desarrollos de las plataformas como Pademobile o Gestopago, estas “tiendas de la esquina” han podido acceder a ofrecer servicios que de otra manera sería impensable por sus altos costos. El poder ofrecer 42

.COLUMNA Pagos Móviles

›› “La Banca por Internet sólo es utilizada por cerca de 4.5 Millones de personas en México”.

Seguridad

La seguridad no solo debe proteger al consumidor, también tiene que hacerlo con los que están del otro lado de la mesa y que no son un gran almacén comer-

Conclusión

Es en la seguridad donde hay una gran oportunidad para los desarrolladores, pues es una realidad que a la par de los avances tecnológicos que se anuncian de forma diaria, y que pueden sorprender a la mayoría de la población, también va creciendo la tecnología “negativa”, aquella que busca quebrantar los protocolos de las plataformas actuales. De ahí el que en muchos de los foros de tecnología la parte de seguridad sea el foco principal, y por eso plataformas como Pademobile cada día incorporan nuevos esquemas con la Autenticación de Identidad al momento de registrar una tarjeta a su dispositivo móvil.

>> Por Sergio Bolaños

Referencias [1] CIU (The Competitive Inteligent Unit) ¿Brecha Digital de Género? ¡Ya no! Marzo 2014. [2] AMIPCI (Asociación Mexicana de Internet) Estudio Banca por Internet en México 2011 [3] AMIPCI (Asociación Mexicana de Internet) Estudio sobre los hábitos de los Usuarios de Internet en México 2014. [4] CIU (The Competitive Inteligent Unit) ¿Quién va ganando la carrera en el Mercado Mexicano de Smartphones?

Sergio Bolaños quien es responsable de la oficina en México de Pademobile, cuenta con más de 20 años de experiencia, en el sistema financiero mexicano, principalmente en el desarrollo de productos y en áreas operativas. Participando en bancos como Citibank, Financiera Rural y Bansefi, así como en la creación de diversas Sofoles y Sofomes, fue parte del Programa para la Regulación de las Sociedades Financieras Populares. Egresado de la Universidad Iberoamericana en Sistemas Computacionales e Informática Administrativa. sergio.bolanos@ pademobile. com.mx @sbolanoss

Software Guru

cial o una institución financiera o una de las mayores tiendas en línea; sino a los emprendedores que tienen un pequeño comercio en Internet o la tienda de la esquina o el taller de una población. Todos estos comercios que deberán incorporarse a la aceptación de los pagos móviles tienen que tener la certidumbre de que la aceptación de este tipo de pagos no deriva en un riesgo que pueda comprometer la continuidad de su negocio, que es el caso que hoy presentan la aceptación de pagos con tarjetas bancarias. De ahí la razón del por que no se ha logrado la penetración en este tipo de negocios. Además las plataformas móviles deben considerar la realidad y la situación actual de los usuarios que se busca incorporar, pues el nivel educativo es muy básico o incluso nulo en muchos de los casos, con lo cual no se puede pretender que para garantizar el nivel de seguridad, se deba cumplir con complicados procesos que los usuarios deban aprender.

www.sg.com.mx |

programas de lealtad a sus clientes, para lo cual estos negocios tendrán que vencer paradigmas y comenzar a generar bloques por colonia o población, puede significar hacer frente a la competencia que hoy enfrentan. Para la adopción y uso de algunos de estos productos, no se requiere de ningún desarrollo, y en algunos casos con tener solo un aparato celular con acceso a servicios de SMS se pueden comenzar a utilizar estos servicios, aunque también es cierto que la cantidad y la accesibilidad a los productos y servicios aumentará conforme se tenga un Smartphone o una tableta en dichos comercios. Es importante recordar que en México y los países de América Latina, el 91% de las operaciones de consumo, se siguen realizando en efectivo, y la velocidad de sustitución del efectivo por tarjeta es solo del 1% anual. Sin embargo, la velocidad de crecimiento de Smartphones en México se efectúa de una forma acelerada, pasando de una penetración de casi el 9% en 2010, a una proyección de terminar el 2015 con 68% de las líneas asociadas a un Smartphone [4], lo que demuestra que la innovación en los pagos móviles no puede focalizarse en el segmento bancarizado, pero si debe aprovechar las facilidades que otorga el uso de un Smartphone, permitiendo a los usuarios efectuar transacciones móviles de una manera más sencilla y cada vez con mayor seguridad. Es este último punto, el que ninguna solución o plataforma de pagos móviles puede olvidar, pues es una realidad que una gran barrera de entrada para la adopción de las plataformas móviles, es la desconfianza de la gente; desconfianza por diversos casos de fraudes que han existido en el pasado, que si bien no derivan de un tema tecnológico, el fraude se percibe como tal, aunando al desconocimiento y desinformación de informática por parte de la mayoría de la población, con lo cual cualquier mínimo incidente que genere un daño económico en los consumidores, procedente de alguna ventana de error en las plataformas de pagos móviles, puede significar años de retraso en su adopción.

.COLUMNA Big Data

Implantando Big Data

LECCIONES APRENDIDAS

unque fue la industria financiera quien primero quiso involucrarse con Big Data, en este momento todo el mundo habla de Big Data y la buena noticia es que ya los conocimientos sobre esta importante tendencia han madurado en aquellos que consideran incluirla en sus iniciativas. Debido a la madurez antes mencionada y a que el número de proyectos de Big Data va creciendo, ya podemos identificar lecciones aprendidas tanto para México como para Latinoamérica. A continuación comparto las que considero más relevantes.

Lección 1: El hecho de que Big Data sea una tendencia, no quiere decir que toda empresa lo requiera.

Se debe de entender bien lo que implica Big Data para que realmente aporte valor. No se trata de implantar para entender, no se trata de hacer una inversión a ciegas y debido a esto sugiero que los casos de uso tengan antes de hacer la estrategia. Antes de iniciar un proyecto de Big Data es importante saber cómo se va a hacer porque el reto es implementar.

Lección 2: La adopción de software libre es un factor de adopción más ágil de Big Data.

Todos los que hablamos de Big Data sabemos que está relacionado con software libre y este es un factor cultural en el que varios países ya están más avanzados, como Brasil. Los países que entienden lo que el software libre puede hacer por ellos y que han eliminado de su cultura los paradigmas de que en el software libre no se tiene soporte y que han visto el enorme apoyo y soporte que pueden obtener son aquellos que ahora están más adelantados en la adopción de Big Data. Aparte de Brasil también, en mi opinión, Chile, México, Colombia y Argentina han aumentado el interés y número de proyectos implantados. En los últimos meses he visto que México en particular ha levantado en este aspecto, aunque no estoy seguro si es por moda o si es porque realmente ya estamos entendiendo lo que Big Data puede hacer. Victor Pichardo es un ejecutivo altamente reconocido en la industria de TI en América Latina con 21 años de experiencia en varios puestos de nivel Senior en compañías de software empresarial. Desde 2005 ha sido Vicepresidente para Latinoamérica de Excelerate Systems, compañía de soluciones de TI enfocada en las operaciones de TI, Infraestructura, Big Data, BYOD, Cloud Computing y Seguridad. http://www.exceleratesystems.com

Lección 3: Definir bien los alcances.

Si dejas crecer un proyecto de Big Data sin control, se puede convertir en un monstruo de siete cabezas que no te va a servir, porque no verás resultados que avalen la elección. El alcance y objetivos deben de

estar definidos por las áreas de Tecnología, las áreas de Negocio y las áreas de Marketing. En mi experiencia, si la iniciativa se inicia solamente en el área de Tecnología fracasa. Involucrar a las 3 áreas antes mencionadas es definitivamente un factor de éxito.

Lección 4: La Ciencia de Datos es la pieza angular de Big Data.

Otro factor de éxito importante es tener una estrategia clara de analítica de datos en la cual se entienda su universo y se entienda lo que el negocio necesita. Lamentablemente, solamente el 10% de las empresas tienen una estrategia clara de analítica de datos y desafortunadamente esto se debe a nuestra cultura, tenemos que cambiar nuestra forma de pensar. La administración de datos está cambiando y la nueva era en la gestión de datos nos exige cambios de fondo, entre ellos el definir nuevos roles y nuevos grupos de trabajo que estén orientados al nuevo trato que requieren los datos ahora.

Lección 5: Big Data complementa Data Warehouse, no lo sustituye.

Hay datos que el Data Warehouse no va a poder procesar o digerir. Por ejemplo, si una empresa ocupa su Data Warehouse para procesar todos los logs de seguridad que genera, pensemos ¿cuánto cuesta un terabyte en Data Ware House? Con un cluster de 5 nodos de Hadoop se podrían procesar vario años de logs.

Conclusiones

Las áreas que más se benefician con la implantación de proyectos de Big Data son las áreas de negocio. Empresas que tienen reportes de ventas generados en veinticuatro horas podrían estar contentas y funcionando, pero con Big Data pueden tener la misma información en dos minutos, tomar decisiones ágilmente y tener una reacción inmediata que impacte positivamente en sus negocios y ante esa agilidad, las empresas ya dicen “necesito esa información en dos minutos, no en veinticuatro horas”. Es importante continuar aclarando conceptos a nivel Directivo para que entiendan Big Data y apoyen su implantación pero en realidad, quienes se benefician más son todos(as) aquellos(as) que están en nivel Gerencial porque están en la batalla, son los que son medidos para dar resultados. No olvides: Solo conociendo Big Data y preparándose adecuadamente para su implantación asegura un ROI.

www.sg.com.mx |

Software Guru

.COLUMNA Tecnológico

Desarrollando Experiencias Digitales D

esarrollar nuevas tecnologías nunca había sido tan sencillo -o tan rentable- como lo es actualmente. Con millones de usuarios de computadoras personales, dispositivos móviles, televisores inteligentes conectados por medio de una red global con capacidades de procesamiento y almacenamiento virtualmente infinitas el acceso a dispositivos digitales ya no es privilegio de unos cuantos, sino un fenómeno global que está cambiando la manera en que las personas trabajan, interactúan y se comunican. Este proceso de “consumerización” de la tecnología ha logrado que esta se haya colocado en los hogares de las personas, más allá de la percepción de que las tecnologías de información son solo herramientas de trabajo y productividad. La evolución de internet hace que ésta comience a rebasar las barreras del navegador web y por lo mismo, la limitante de dónde y cuándo estamos conectados.

La expectativa del usuario

Mauricio Angulo (@mauricioangulo) es programador desde 1989 divulgador, ávido escritor y emprendedor. Actualmente es CEO y fundador de Tesseract Space donde realiza funciones de asesor y consultor de innovación tecnológica, mercadotecnia digital y experiencia de usuario.

La creación tecnológica para ser exitosa actualmente debe ser un proceso centrado en el usuario, y es necesario entender el contexto en el que esos usuarios usan la tecnología así como los problemas que deben resolver mientras la usan. A diferencia de otras “generaciones” tecnológicas, la mayoría de los usuarios actuales carecen de entrenamiento formal en el uso de la tecnología, sino que aprenden a usarla por prueba y error. El escritor británico Arthur C. Clarke mencionó en algún momento que “toda tecnología lo suficientemente avanzada es indistinguible de la magia” y para los usuarios finales la expectativa actual de la tecnología es justo esa: que funcione bien, de manera natural

y todo el tiempo, sin que realmente les interese cómo es que la tecnología funciona internamente. Entre más interacción tienen los usuarios finales con la tecnología más sofisticados se vuelven y su expectativa sobre el funcionamiento de la misma se hace más exigente. Para el usuario final los fundamentos de seguridad, usabilidad, rendimiento e interoperabilidad son transparentes y los da por sentado como responsabilidad del desarrollador, fabricante o quien sea que se encuentre detrás de la creación de los dispositivos, sitios o apps que usa. Cuando esta expectativa del usuario -a veces poco realista- no se cumple adecuadamente, es normal que ese usuario, desencantado, comience a buscar opciones que se ajusten a su idea sobre cómo debería de funcionar la tecnología. Vale la pena recordar que desde la perspectiva de la disciplina de experiencia de usuario (UX) ni la expectativa ni el mal uso de la tecnología es culpa del usuario; es responsabilidad de los creadores de esas tecnologías crear modelos de interacción que sean intuitivos y consistentes al tiempo que resuelven las necesidades de los usuarios para los que fueron creados.

Más allá de las tres pantallas

En la última década los usuarios han vivido bajo el paradigma de “tres pantallas y una nube”, una manera simple para describir cómo las personas gestionan su información e interactúan con otros por medio de la tecnología. Esas tres pantallas -la PC, el móvil y la TVestán ligadas por medio de servicios que viven en internet para sincronizar datos e información de manera transparente, pero en la próxima década el número de dispositivos a través de los cuales los usuarios estarán 46

El mundo conectado

La promesa del internet de las cosas va más allá de las relaciones simples de cliente/servidor para envío y recepción de datos por medio la red, así como escenarios predecibles como el de una persona en una oficina frente a una PC. En un mundo conectado el número de escenarios y situaciones en que puede encontrarse un usuario será increíblemente variable y en muchas ocasiones se encontrará en situaciones en que la conexión a internet sea intermitente o nula por periodos extendidos de tiempo, y deberemos de tomar en cuenta más que nunca las capacidades limitadas de procesamiento, memoria y batería de los dispositivos que utilizarán los usuarios en su experiencia digital.

Al hablar de “internet de las cosas” comenzaremos a hablar también de “intranets de las cosas”, pequeños espacios personales privados donde diferentes dispositivos vinculados a un solo usuario -o a unos pocos- podrán interactuar entre ellos para compartir información, configuraciones y repartir cargas de trabajo. Los usuarios, en general, son integradores de tecnología en el sentido de que su ecosistema personal está compuesto de equipo, software y servicios que vienen de distintos fabricantes y espera que estos se entiendan de manera natural desde el principio. Las interfaces de programación -las APIs- serán el cimiento clave para esta integración de dispositivos, de la misma manera que durante el periodo de la web 2.0 las APIs permitieron la integración de un ecosistema diverso de sitios y aplicaciones que antes vivía aislado y duplicado hasta la saciedad en perjuicio del usuario quien tenía que tener servicios duplicados para integrar sus necesidades de cómputo. En los próximos años, el desarrollo de cualquier tecnología tendrá implícita la capacidad de poder extender su funcionalidad a otras plataformas para integrarse en los micro-sistemas personales que los usuarios comenzarán a integrar a su alrededor por medio de dispositivos personales que vivirán en todas partes. La búsqueda de experiencias digitales consistentes para nuestros usuarios nos ayudará a encontrar también una visión más amplia sobre la manera en que la tecnología pueda hablar consigo misma.

>> Por Mauricio Angulo S.

www.sg.com.mx |

conectados generando y compartiendo información aumentará dramáticamente. Esta nueva época en la que la web rebasa las fronteras de los navegadores está ya sobre nosotros en forma de lo que muchos llaman “El Internet de las cosas” (Internet of Things) en la que prácticamente cualquier dispositivo alrededor nuestro estará conectado a internet enviando y recibiendo datos. El reto que tenemos los que hacemos tecnología es integrar un ecosistema tan diverso para crear experiencias que sean consistentes para los usuarios en todos sus dispositivos y en todas partes. Posiblemente el cambio más fuerte es que el usuario ya no tendrá que ir a buscar o consultar la información, sino que la información deberá buscar al usuario y ofrecerle de todo el acervo que hay en internet solo aquella que es útil y relevante para él en el contexto que se encuentre.

Software Guru

›› “Ni la expectativa ni el mal uso de la tecnología es culpa del usuario”.

.PERSONAS Carrera

Competencias, Conocimientos, Habilidades y Actitudes QUE REQUIEREN LOS PROFESIONISTAS DEDICADOS AL SOFTWARE ›› Por Pedro Solares Soto

as brechas entre “academia” e “industria” en relación a la carrera de TI y en particular para profesionistas de software no tienen por qué seguir siendo grandes y mucho menos tiene que continuar desatendida. Es importante que todo estudiante por egresar, todo recién egresado y todo profesionista puede ayudar a acortar dicha brecha y orientarse hacia lo que las empresas necesitan para ser más productivas y obtener mejores resultados en una industria tan competida como la nuestra. Para atender las necesidades que las empresas tienen en relación con el software, requieren contar con personal calificado con las competencias, conocimientos, habilidades y actitudes correctas. Estas necesidades son: • Tener personal capacitado en el desarrollo e integración de software que atienda a sus propios requerimientos. • Ocupar con personas competentes nuevos puestos que comparten funciones de distintas áreas relacionadas con el software, como el de arquitecto en software. • Contar con personal que tenga una visión sistémica de los procesos de las TI, que les permitan comprender los procesos que se realizan en diferentes actividades, tales como programar, desarrollar, integrar y modelar. • Tener personal capacitado para desarrollar sistemas en la nube con información en línea y disponibilidad continua. “El concepto de competencia surge de la necesidad de valorar no sólo el conjunto de los conocimientos apropiados (saber) y las habilidades y destrezas (saber hacer) desarrolladas por una persona, sino de apreciar su capacidad de emplearlas para responder a situaciones, resolver problemas y desenvolverse en el mundo” [1] Cuando se cubren las competencias correctas, las empresas pueden incrementar su productividad. Es muy importante que los profesionistas desarrollen sus capacidades para integrarse en mejores condiciones a la planta productiva y mejorar así su nivel de vida. Por ejemplo, en cuestión de conocimientos [2], contar con aquellos relacionados a: Sistemas operativos y tecnología. • Tecnologías emergentes. • Técnicas de calidad de software. • Técnicas de arquitectura de software. • Tratamiento de la información (bases de datos, análisis de información para generar valor). • Redes y comunicaciones.

• Seguridad e integridad de la información. • Bases sobre lógica de programación. • Organización, política y cultura empresarial. • Prácticas empresariales. • Gerencia de proyectos • Inglés (lectura y redacción) En cuestión de habilidades [3] contar con aquellas relacionadas a: • Diseño y desarrollo de aplicaciones y técnicas de calidad de software. • Aplicación de estándares y certificaciones en programación, redes y bases de datos. • Diseño de técnicas de Arquitectura de software. • Integración de sistemas. • Modificación de las aplicaciones de tecnologías de la información. • Uso de tecnologías, aplicaciones y prácticas para la colección, integración, análisis, selección y presentación de la información. • Diseño de estructuras de programación. • Negociación y toma de decisiones. • Resolución de conflictos. • Planear, administrar y priorizar trabajo. • Trabajo en equipo • Orientación al cliente • Orientación a resultados Es un hecho que la actitud tiene un impacto directo en el rendimiento laboral, la actitud de un profesionista se relaciona con su desempeño. Las actitudes [4] que todo profesionista de software debería de procurar son: • Liderazgo • Creatividad • Innovación • Iniciativa • Ética • Colaboración • Tolerancia • Respeto • Servicio • Disciplina Las anteriores listas de conocimientos, habilidades y actitudes mencionadas son las señaladas en programas como PROSOFT, IMPULSA, CONOCER [5] y el Programa Académico De Técnico Superior Universitario en Software de la Universidad Iberoamericana. 48

La productividad no es una cuestión que solo deba preocupar a las empresas, es un aspecto que debe nacer desde los profesionistas ya que, siendo la esencia de nuestra industria y los motores principales, deben de procurar estar alineados a lo que las empresas necesitan, alineados a las tendencias más demandadas y estar conscientes de que su buen desempeño no solo beneficia a sus proyectos, su buen desempeño los hará cosechar muchos éxitos profesionales que les beneficiarán a su vida personal.

Software Guru

Para puestos relacionados al desarrollo de software: • Desarrollar componentes de software para la elaboración de aplicaciones de cómputo. • Desarrollar sistemas web mediante lenguajes de programación. • Programar estructuras de software. • Programar aplicaciones de software para resolver problemas de la organización. • Desarrollar aplicaciones de cómputo innovadoras de acuerdo con diversos estándares internacionales. • Implementar y administrar sistemas de información, mediante técnicas avanzadas de desarrollo de software para mejorar los procesos de las organizaciones. • Administrar la estructura de bases de datos para asegurar su funcionamiento, seguridad e integridad. • Gestionar los protocolos y los procesos de comunicación, uso y ubicación de los dispositivos de red de acuerdo con los tipos de conectividad, direccionamiento y topologías de las aplicaciones.

• Instalar diversas plataformas de sistemas operativos.

Referencias [1] Definiciones - Competencias Laborales. http:// www.competenciaslaborales.cl/definiciones. htm#competencia [2] Conocimientos del programa Técnico Superior Universitario (TSU) en Software de la Universidad Iberoamericana Ciudad de México. [3] Habilidades del programa Técnico Superior Universitario (TSU) en Software de la Universidad

Para puestos relacionados con el Soporte técnico: • Realizar el mantenimiento preventivo y correctivo a equipo de cómputo y periféricos. • Gestionar los recursos de los equipos de cómputo.

Iberoamericana Ciudad de México. [4] Actitudes del programa Técnico Superior Universitario (TSU) en Software. [5] Estrategia para el fortalecimiento del capital humano del sector, con base en las competencias de las personas. Sector Tecnologías de Información. http:// www.conocer.gob.mx/pdfs/documentos/software.pdf

.BIO Morales Mtro. Pedro F. Solares Soto es Coordinador del programa Técnico Superior Universitario (TSU) en Software y Coordinador de la Maestría en Administración del Servicio de TI en la Universidad Iberoamericana Ciudad de México pedro.solares@ibero.mx

www.sg.com.mx |

Cuando un profesionista procura cultivar los conocimientos, habilidades y actitudes mencionadas en el presente artículo es capaz de realizar eficientemente las funciones más solicitadas por la industria:

.TECNOLOGÍA

Diagnóstico Físico Utilizando Google Glass y Machine Learning ›› Por Jair A. Serrano, Lainy C. Regalado, Victor F. Villa, y Germán H. Alférez

uestro ritmo de vida ha ido en aumento. Es por esto que en ocasiones no nos percatamos de algunos factores que pudieran repercutir negativamente en nuestra salud. De hecho, México se ha convertido en el país con el mayor índice de obesidad a nivel mundial. Según la Organización de las Naciones Unidas para la Alimentación y la Agricultura, una tercera parte de los adultos mexicanos es obesa. El problema radica en la alimentación con un alto contenido calórico y de bajo costo, aunado a un estilo de vida sedentario [1]. Creemos que estos graves problemas requieren soluciones urgentes. Es por esto que en lugar de reaccionar a la enfermedad con un tratamiento que puede ser costoso y doloroso, lo ideal es prevenir proactivamente la enfermedad. Soluciones preventivas pueden ayudar a las personas a tomar decisiones a tiempo antes de enfermar. Por lo anterior, creemos conveniente contar con herramientas que puedan ayudarnos a tomar decisiones proactivamente y así prevenir enfermedades. Estas herramientas pueden tomar la forma de “wearables” (dispositivos electrónicos que son llevados por alguien debajo de, con o sobre la ropa). La ventaja de esta aproximación es que podemos obtener retroalimentación de nuestro estado físico en tiempo real y a diario. Por ejemplo, uno de los productos más recientes de Google es Google Glass. Aunque estas gafas tienen un procesador muy potente y una gran cantidad de memoria, Google Glass no cuenta con las capacidades inherentes suficientes para realizar diagnósticos físicos. Es por esto, que creemos que se le debe inyectar una capa de inteligencia artificial a los wearables, tales como Google Glass, para resolver esta situación. Nuestra contribución es una solución para el diagnostico físico utilizando Google Glass y Machine Learning. Machine Learning (Aprendizaje Automático) es una rama de la Inteligencia Artificial que tiene como objetivo primordial desarrollar métodos y técnicas que permitan que una computadora sea capaz de aprender. Esto se realiza observando comportamientos y posteriormente analizando los datos obtenidos con el fin de aprender de las situaciones y tomar decisiones acertadas [2]. En nuestra aproximación, Google Glass captura la información acerca de los kilómetros caminados durante el día.

Esta información es recopilada en una base de datos remota. En la mañana, nuestra aproximación envía recomendaciones al usuario acerca de las calorías a quemar durante el día gracias a un análisis de los datos usando Machine Learning. En la noche nuestra aproximación envía recomendaciones al usuario de acuerdo a las calorías que se han quemado durante el día.

Necesidad de diagnósticos físicos

María tiene 47 años. Su estilo de vida es sedentario. Su trabajo requiere que ella se encuentre ocho horas sentada. Cuando termina sus horas laborales ella se dirige a casa. No obstante, María no realiza actividades físicas. Si María continua con este estilo de vida poco saludable, ella corre el riesgo de que en el futuro pueda llegar a ser obesa. María fue una de las primeras personas en adquirir Google Glass. Este dispositivo es capaz de recopilar información por medio de GPS. La información que se captura por GPS podría servir para conocer las distancias que ella recorre y en cuánto tiempo lo hace. Con esta información, sería posible averiguar las calorías que quema. En la siguiente sección presentamos nuestra aproximación para que Google Glass le entregue a personas como María información de diagnostico físico.

Diagnóstico Físico Mediante Google Glass y Machine Learning

La Figura 1 describe nuestra solución para realizar diagnósticos físicos mediante Google Glass y Machine Learning. A continuación se describe cada uno de los pasos de nuestra solución: 1. Capturar los Kilómetros Caminados: En este paso, Google Glass captura la información de los kilómetros que el usuario camina durante el día. Esta información es enviada a una base de datos en un servidor remoto. Esta base de datos contiene tres atributos: el numero del día registrado (este es un valor entero secuencial); el número de kilómetros caminados durante el día; y las calorías quemadas durante el día. El valor de las calorías se calcula mediante los kilómetros caminados. 2. Analizar y Tomar Decisiones: Mediante Machine Learning 50

.TECNOLOGÍA

“creemos conveniente contar con herramientas que puedan

Conclusiones y Trabajo Futuro

En este artículo se presentó una aproximación basada en Google Glass y Machine Learning que procesa información especifica del usuario para la elaboración de un diagnóstico físico oportuno y proactivo. Creemos que nuevas tecnologías, tales como las presentadas en este artículo, pueden ser de gran ayuda para mejorar nuestra salud.

[1] CNN. (2013). México es el país más obeso del mundo, según la ONU. 11 de Julio, de CNN. Recuperado de: http://cnnespanol.cnn.com/2013/07/11/mexico-es-el-paismas-obeso-del-mundo-segun-la-onu/ [2] Mitchell, T. (1997). Machine Learning, Pittsburgh: McGraw Hill. [3] Sayad, S. (2011). Real Time Data Mining. Self-Help Publishers [4] Iglesia Adventista del Séptimo Día. (2013). ¿Qué es Quiero Vivir Sano?. 15 de Mayo. Recuperado de: http://quierovivirsano.org/que-es-qvs/

.BIO Jair A. Serrano, Lainy C. Regalado, Victor F. Villa, y Germán H. Alférez pertenecen a la Facultad de Ingeniería y Tecnología de la Universidad de Montemorelos. jair.alberto.sm@gmail.com, lainy.regalado@gmail.com, felipe.villa@bleext.com, harveyalferez@um.edu.mx

www.sg.com.mx |

se analiza la información almacenada en la base de datos utilizando el algoritmo ZeroR. Este algoritmo permite construir una tabla de frecuencia con los datos almacenados y de la cual se obtiene el valor mas frecuente [3]. El análisis realizado con Machine Learning se realiza automáticamente en las primeras horas de la mañana. En este proceso, se analizan todos los datos en la base de datos que se han recopilado en los días anteriores. El resultado de este proceso es el número de calorías a quemar durante Figura 1. Diagnóstico de estado físico mediante Google Glass y Machine Learning. el día. En el ejemplo, el algoritmo ZeroR encontró que en base a los datos recopilados en los 22 días previos, Como trabajo futuro, utilizaremos la cámara de Google Glass para se diagnostica que el usuario debe quemar 232.45 calorías durante el día. hacer un reconocimiento de los alimentos ingeridos. Mediante Machine Learning y técnicas de reconocimiento de imágenes, se analizará esa 3. Presentar el Diagnóstico Físico: Al finalizar el día, nuestra aproxima- información con el fin de llevar un conteo de las calorías ingeridas por ción compara el valor de calorías a quemar que se ha diagnosticado en el usuario. En base a esto, se darán diagnósticos físicos más exactos para la mañana, mediante Machine Learning, con el valor real de las calorías llevar un control de perdida de peso. Además, se aplicará nuestra soluque se quemaron durante el día. Gracias a esta información, el sistema ción en el programa “Quiero Vivir Sano” [4]. “Quiero Vivir Sano” es una le envía el diagnóstico físico al usuario. Por ejemplo, si el usuario ha metodología que fomenta hábitos y conductas saludables, con el fin de quemado menos calorías que las sugeridas, Google Glass presenta un prevenir y desacelerar las enfermedades crónicas no transmisibles. mensaje de advertencia al usuario. En la Figura 1, se puede observar este caso en donde se presenta el siguiente mensaje: “Cuida tu salud. Hoy quemaste 159 calorías. Debiste haber quemado 232.45 calorías”. Referencias

Software Guru

ayudarnos a tomar decisiones proactivamente y así prevenir enfermedades”.

.SG TALENTO Perfiles

LUIS FERNANDO CÁZARES

MARU MUNGUÍA

ALEJANDRO ARMENTA

http://sgtalento.com/perfil/a/cazaresluis

http://sgtalento.com/perfil/c/12936

http://sgtalento.com/perfil/c/12932

Luis es desarrollador web especializado en sistemas

Maru es fundadora y CEO de 2MundosConectados

Alejandro es cofundador de Intelectech, una startup dedi-

administrativos y gestión de procesos operativos,

- 2MC, una empresa de diseño y desarrollo web, con

cada al desarrollo de software y prestación de servicios en

experiencia en sistemas de registro e inscripciones,

una trayectoria probada de más de 18 años. Sus es-

tecnologías de la información, así mismo colabora con otras

reservaciones en línea. Tiene 18 años laborando en

pecialidades son: El Liderazgo de equipos, la gestión

empresas como consultor de TI y como apoyo en las fases

Turismo & Convenciones, 12 años de experiencia

de proyectos, la gestión de proyectos Software as a

estratégicas de negocio. Actualmente se encuentra partici-

como programador y diseñador Web. Sus especialida-

Service, Desarrollo de Productos, la usabilidad, cloud

pando en programas de emprendimiento desarrollando

des son: Administración de servidores Web, office365

computing y el modelo CMMI.

proyectos que contribuyen a la innovación tecnológica.

¿Qué es lo que más me gusta de lo hago?

¿Qué es lo que más me gusta de lo que hago?

¡La gente! Yo siempre he creído que uno no trabaja

Me es grato saber que las tecnologías de la información es-

¿Qué es lo que más me gusta de lo que hago?

con empresas, sino con personas que las representan.

tán presentes en muchos sectores empresariales, lo que da

Diseñar y desarrollar soluciones que permitan al

Me encanta conocer quién está detrás de los proyec-

pie a aprender acerca de nuevos giros, y sobre todo, tener

usuario final ser eficaz y más productivo, proporcio-

tos, los resultados, los éxitos.

la satisfacción de aportar valor a los negocios a través de las

Desarrollo en PHP, HTML, CSS, jQuery, Ajax, MySQL, bootstrap, wordpress.

nar a mis clientes un valor agregado operativa y admi-

soluciones en las que participo. Disfruto proponer ideas,

nistrativamente. Me emociona analizar el problema y

¿Quiénes son mis modelos a seguir?

proponer la solución adecuada.

Definitivamente Steve Jobs, con él confirme que SI

liderar proyectos e inyectar motivación al equipo de trabajo.

se puede cambiar al mundo. Robert Kiyosaki, por ser

¿Quiénes son mis modelos a seguir?

otra persona que piensa diferente y por su claridad y

No tengo un modelo a seguir, pero reconozco ampliamente la

Realmente no tengo un modelo a seguir, solo aplico

enfoque respecto al valor del dinero. Chris Gardner

labor de emprendimiento de Mark Zuckerberg y Steve Jobs,

uno de los consejos más importantes que me dio mi

por su espíritu de lucha y compromiso; de él me llevo

ingeniaron y crearon cosas geniales que fascinaron al mundo

padre: capacitate, se honesto, tolerante y humilde.

el apegarse al plan A. Nunca al B así como su espíritu

entero, hicieron de eso un gran negocio y son un gran referente

de lucha y su claridad hacia el compromiso.

de éxito para esta generación. En un ámbito local, admiro a varios colegas, tengo el placer de conocer y haber trabajado con

Mi consejo para mis colegas En la actualidad la competencia en nuestra profesión es

Mi consejo para mis colegas

muy aguerrida, por favor demos el valor justo a nuestro

Definan su proyecto de vida y apeguense a él. De-

personas excepcionales y sumamente talentosas.

trabajo, conocimiento y picardía par crear tecnología.

diquen el tiempo necesario a descubrir aquello que

Mi consejo para mis colegas

les apasiona; el dinero es sólo el resultado de hacer

Ser un profesionista exitoso no tiene que ser frustran-

justo eso. Los sueños son la forma de visualizar rea-

te y aburrido, diviértete haciendo lo que elegiste hacer,

lidades. Creo firmemente que el talento mueve al ca-

pero si te equivocas en algo, relájate, tómalo como una

pital. Rendirse NO es opción, aprender a desarrollar

lección y aprende de ella. Si eres bueno en lo que haces,

tolerancia a las fallas, errores y fracasos; el camino al

creativo e inquieto... ¡Felicidades! probablemente posees

éxito, está lleno de estos momentos. ¡Cree en ti!

el potencial para hacer cosas diferentes a lo que el resto de la gente hace, solo descúbrelo y explótalo.

Te invitamos a compartir tu perfil en http://sgtalento.com

www.sg.com.mx |

Software Guru

.TECNOLOGÍA Gadgets

Noke

Candado bluetooth

Withings Home

Monitor inteligente y multifuncional

Withings Home es una cámara diseñada para monitorear tu hogar. Incluye una cámara HD de 5 megapixeles con ángulo amplio de 135 grados y visión nocturna. También tiene sensores para monitorear la calidad del aire, temperatura y humedad. Su conectividad es por WiFi y Bluetooth, y también tiene micrófonos y bocinas de alta definición por lo que puedes escuchar y hablar a través de ella. Cuando la Home detecta eventos de movimiento o sonido, automáticamente toma fotografías y video de 5 segundos y los sube a Internet donde quedan almacenados un par de días; esto puede ser útil tanto por seguridad como simplemente para capturar momentos cotidianos y generar un video-diario. La Home es compatible con IFTTT lo cual te permite programar tus propias reacciones a eventos que detecte. http://swgu.ru/sg45-home

Tú, yo, nosotros, ellos … todos hemos perdido la llave o combinación de un candado que por lo tanto queda inservible. La empresa Fuz designs busca cambiar esto con su candado Noke (pronunciado “nouki”, como “sin llave” en inglés). Noke es un candado que se conecta con tu smartphone via Bluetooth y te permite abrirlo cuando detecta a éste. Por medio de una app puedes configurar el comportamiento de tu Noke, e incluso darle acceso a otras personas de forma temporal o permanente. También puedes crear una combinación manual (por medio de un patrón de cliqs al candado), así que podrás abrir tu Noke aún si te quedas sin batería. El Noke pasó por Kickstarter y fue fondeado con más del 500% de la meta original. Estará disponible a partir de febrero 2015. http://swgu.ru/sg45-noke

Dell Venue 8 7000

Tablet Android con cámara 3D

Apenas se empezaron a anunciar las tablets que llegarán para esta temporada navideña, pero hasta ahora la Dell Venue 8 7000 (sí, sabemos que el nombre es terrible) es la que más nos emociona. La mayoría de la información liberada hasta el momento hace énfasis en lo delgada que es. Y sí, es muy delgada, pero eso no es lo que nos llama la atención. Para nosotros, el hito importante es que es la primera tablet que incluye la tecnología Intel RealSense (un sensor de profundidad 3D). Así es, imagínate una tablet con un sensor similar al del Kinect. Por ahora, el uso de la cámara 3D se está enfocando en aplicaciones fotográficas (al incluir metadatos de distancia, profundidad y volumen, se puede hacer todo tipo de procesamiento de imagenes). Sin embargo, poco a poco iremos viendo nuevas apps que aprovechen esta tecnología de formas que no tenemos contempladas. http://swgu.ru/sg45-venue8

Intel Edison

Construye tu IoT

Durante su foro para desarrolladores, Intel anunció la disponibilidad comercial de su plataforma “Edison” diseñada para habilitar wearables y dispositivos de tipo Internet of Things. Edison es una computadora muy pequeña (del tamaño de una estampilla postal) con las siguientes capacidades: SoC Intel Atom de 22 nm con CPU dual-core a 500 Mhz y MCU de 32 bits a 100 MHz, 1 GB de RAM y 4 GB de almacenamiento no volátil, conectividad por WiFi y Bluetooth de baja energía. El desarrollo es compatible con Arduino, y en inicio soporta programación en C/C++ pero en el futuro próximo brindará soporte para Python, Node.js, RTOS y programación visual. http://swgu.ru/sg45-edison 54

Directorio Abiztar 4F http://www.abiztar.com.mx/

e-Quallity 01 www.e-quallity.net

Excelerate 47 http://www.exceleratesystems.com/

IDC 35 http://www.idclatin.com/

Mexico First 31 www.mexico-first.org

Pronatura 3F http://www.pronatura.org.mx/

SG Campus 09 www.sgcampus.com.mx

Software Guru

SG Virtual 2F http://sg.com.mx/sgvirtual

Testing IT 45

www.sg.com.mx |

www.testingit.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TI SG se distribuye de manera impresa en la República Mexicana, y de manera digital llega a más de 25mil lectores de habla hispana. El anuncio en la revista digital cuenta con hiperliga directa a tu sitio web, lo que te dará la oportunidad de acercarte a nuevos clientes. “Es una gran oportunidad participar con Software Guru, pues comprobamos que es un medio efectivo.” -Novalys Latinoamérica Contáctanos en el (55)

5239.5502 o en publicidad@sg.com.mx

.BIBLIOTECA

El Libro Negro del Programador

CÓMO CONSEGUIR UNA CARRERA DE ÉXITO DESARROLLANDO SOFTWARE Y CÓMO EVITAR LOS ERRORES HABITUALES

Rafael Gómez Blanes a través de este libro nos muestra todas aquellas circunstancias que rodean el desarrollo de software y que determinan su éxito o fracaso. En cada capítulo se habla de los hábitos de trabajo que un desarrollador profesional debe incorporar para que pueda avanzar en su trabajo generando un código limpio y de calidad, incluso en el primer capítulo se explica cómo la deuda de no desarrollar de ese modo es demasiado alta. Este libro es importante ya que ingenuamente se cree que el éxito de un proyecto software consiste básicamente en entregar lo acordado a tiempo; nada más lejos de la realidad. Rafael nos explica que hay factores que indican en qué medida el proyecto ha sido un éxito o no: dichos factores saltan a la luz tiempo después de haber entregado el proyecto. Este libro trae el mensaje de que como desarrolladores, debemos tener claro que una de las mejores fuentes de conocimiento es el trabajo de los demás.

Desarrollo de aplicaciones para Android MANUAL IMPRESCINDIBLE

Quien quiera sumarse a gran número de desarrolladores que están subiéndose a la tendencia móvil, este libro les ayudará a aprender fácilmente a realizar programas para el sistema operativo Android, comenzando desde cero y llegando a realizar sus propias aplicaciones. En este libro se muestra el desarrollo de diferentes proyectos para todo tipo de dispositivos, desde los nuevos wearables hasta los más grandes, pasando como es lógico por los smartphones y tablets, siempre con el objetivo de crear código versátil y reutilizable. En esta edición se han tenido en cuenta las diversas versiones de Android disponibles actualmente en el mercado, descubriendo al lector cómo utilizar el paquete de compatibilidad. Si te interesa realizar aplicaciones que hagan uso del GPS o la cámara, crear animaciones, gestionar la información mediante bases de datos, crear aplicaciones para tablets reutilizando código de aplicaciones para otros dispositivos, usar fragmentos, o incluso crear sus propios estilos, fondos animados o widgets este libro es para ti.

Fundamentos de Pruebas de Software

CLAVES BÁSICAS PARA APROBAR EL EXAMEN DE “PROBADOR CERTIFICADO” (CERTIFIED TESTED) CONFORME AL ESTÁNDAR ISTBQ

Las pruebas de software consisten en un proceso crítico para asegurar que el software sea entregado al cliente libre de defectos y debería ser tratado como tal por lo que este libro proporciona a los Ingenieros de Pruebas y Jefes de Pruebas el fundamento, los procesos, las herramientas y habilidades esenciales que ellos necesitan para posicionarse en un camino hacia el verdadero profesionalismo en pruebas. Cubre también las principales técnicas de diseño de pruebas por medio de la clase y los ejercicios. Este libro proporciona una guía de auto-estudio para pasar el examen Probador Certificado ISTBQ Nivel Básico (ISTQB Certified Tester Foudation Level) que incluye los 6 capítulos, un glosario de los términos más importantes, ejercicios prácticos y sus soluciones por cada capítulo junto con dos exámenes de simulación y con más de 200 preguntas de muestra que abarcan cada objetivo del aprendizaje del Programa de Estudios.