SG Software Guru #47 by Revista Software Guru

PLANEACIÓN ESTRATÉGICA DE TI PAG. 30

—

CONTRATACIÓN BASADA EN RESULTADOS

PAG. 32

—

USER EXPERIENCE DESIGN PAG. 38

—

TUTORIAL

APPS MÓVILES CON

XAMARIN.FORMS

NO.47

PAG. 14

—

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

MAKER ZONE

GENERACIÓN DE MAPAS CON DRONES PAG. 42

COMERCIO DIGITAL TENDENCIAS Y TECNOLOGÍAS

NO.47

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

EN PORTADA

COMERCIO DIGITAL 020

Abordamos tanto aspectos estratégicos como detalles técnicos del comercio digital: tendencias de mCommerce, interés de los consumidores, gateways de pago, bitcoin, blockchain. Con este reportaje tendrás una idea mucho más clara de cómo subirte a esta ola.

CONTENIDO

INDUSTRIA Y EMPRESAS

¿Sabemos qué Necesitan los Emprendedores? 010

HERRAMIENTAS Y TECNOLOGÍAS

OpenStack 012 — WebRatio 013 — Xamarin.Forms 014

ESTRATEGIA DE TI

EMPRENDIENDO

052

El Presupuesto de TICs — Planeación Estratégica

028 030

COLUMNAS

Tendencias en Software 007 — Tejiendo Nuestra Red 008 — Código Innovare 031 — Progamar es un modo de vida 048

FUNDAMENTOS

Certificados Digitales

010

Contratación Basada en Resultados 032 — Seguridad y Frameworks 036 — A la Defensa de los Usuarios 038 — Sobre Nuestra Misión como Testers 040 — Mapas de Alta Resolución con Drones 042

E F

PRÁCTICAS

VOCES

Los Bugs del Testing en México 041 — Más allá del Software 046 — Software Defined Networking 050

HUMANOS DESPUÉS DE TODO

Carrera: Guía para certificarte como Tester 053

EN CADA NÚMERO

Noticias y Eventos 005 — Radar 006 — Hardware 054 — Biblioteca 056

EDITORIAL

Renaciendo cual fénix La última vez que platicamos por medio de estas líneas era diciembre de 2014. Cinco meses después, te presentamos este nuevo número de SG. Lo sabemos, es mucho tiempo y te pedimos una disculpa. ¿Qué estuvimos haciendo durante todo ese tiempo? Pues más que nada, estuvimos pensando en cómo queremos que sea Software Guru, y qué necesitamos hacer para que eso suceda. Como sabes, SG nació hace poco más de 10 años. Durante este tiempo, tanto la industria de medios como la de TI han sufrido grandes cambios tanto a nivel global como local. Es así que SG también necesita cambiar para ajustarse a las nuevas características de la industria y satisfacer las necesidades de nuestra audiencia.

Es por ello que tomamos un tiempo para hacer varios ajustes en SG de forma que podamos seguir realizando por muchos años más nuestra misión: informar, inspirar y vincular a los profesionistas y organizaciones de TI en Latinoamérica para impulsarlos a ser de clase mundial. En esta edición de SG notarás algunos cambios: nuevos colaboradores, secciones y temas, además de un ligero rediseño. Continuaremos con los ajustes a lo largo del año, pero prometemos ya no hacerte esperar tanto. Agradecemos tu paciencia y lealtad. Lo mejor está por venir. Equipo Editorial Software Guru

DIRECTORIO SG Dirección Editorial Pedro Galván | Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Susana Tamayo | Arte y Diseño Oscar Sámano | Suscripciones María de Jesús Montiel Consejo Editorial Luis Daniel Soto | Gunnar Wolf | Luis Vinicio León | Hanna Oktaba Ariel Jatuff | Emilio Osorio | Gloria Quintanilla | Jorge Valdés COLABORADORES Andrés Bianciotto, Celeste North, Miguel Ángel Barajas, Alder López, Arturo Téllez, Héctor Santillán, Gabriela Campos, Guilherme Siqueira Simoes, Humberto Cervantes, Misael León, Pilar Barrio, Carlos González, Quauhtli Martínez, Víctor Hernández, Carlos Perea, Héctor Uriel Pérez, Ismael Villegas, Armando Márquez

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.

004

NOTICIAS

Noticias HACKMTY

MOBILE DAY 2015

El hackathon estudiantil HackMty se llevó a cabo el 21 y 22 de marzo en el campus Monterrey del Tecnológico de Monterrey. 300 estudiantes se organizaron en equipos y trabajaron en sus proyectos a lo largo del fin de semana. Los proyectos ganadores fueron Roady (app para gamification de puntualidad), ID Scanner (lector de datos en identificaciones para alimentar formas) y Rocket (clustering para procesamiento distribuido usando smartphones). El evento fue organizado por Major Leage Hacking, que se especializa en organizar hackathons estudiantiles y que a lo largo del año estará realizando otros eventos en el país.

Software Guru organizó la edición 2015 del Mobile Day (enfocado en el desarrollo de aplicaciones móviles empresariales) el pasado 19 de marzo en Ciudad de México. Este es su segundo año y contó con más de 300 asistentes interesados en construir mejores apps. A lo largo del día, los participantes aprendieron sobre mejores prácticas de UX design, estrategias de testing para lidiar con la gran variedad de dispositivos, criterios para desarrollar apps nativas o híbridas, low-code mobile platforms, gamification, y la plataforma Twitter Fabric, entre otros temas. Agradecemos a los participantes y nos vemos en 2016.

GLOBAL ARDUINO DAY

El pasado 28 de marzo se celebró el Global Arduino Day con eventos en distintas ciudades del mundo. América Latina tuvo una participación nutrida con la realización de más de 70 eventos. Tan solo en Brasil se realizaron más de 30, y en México 9. Ciudad de México fue una de las sedes con mayor participación realizando un evento en el Centro de Cultura Digital con conferencias y exhibición de proyectos. Adicionalmente se contó con un programa de talleres prácticos realizados a lo largo de una semana en los maker spaces de Hacedores y 330 ohms. Imagen cortesía de hacedores.com

SXSW INTERACTIVE

Un año más, y otra edición del SXSW Interactive. El festival más importante de medios interactivos se realizó del 13 al 17 de marzo en Austin, Texas reuniendo a más de 30 mil participantes. México tuvo participación a través del panel “Navigating the Entrepreneurial Ecosystem in Mexico”, así como un pabellón en la expo con la presencia de varias empresas nacionales (entre ellas SG). En cuanto a las novedades y tendencias, previo al evento el tema que se esperaba que dominara las conversaciones era el de Internet de las Cosas, apareciendo en al menos 70 sesiones (de un total de mil 250 sesiones que se realizan a lo largo del festival). Y efectivamente IoT fue un tema importante, pero lo que en realidad dominó las conversaciones en SXSW 2015 fue Meerkat, la app para hacer live streaming que había sido lanzada apenas un par de semanas antes, y durante SXSW captó cerca de 100 mil usuarios nuevos. Así que la noticia es que SXSW todavía puede funcionar como detonador de apps y startups.

SG.COM.MX

005

RADAR

VISUAL STUDIO CODE Y 2015

1 MACHINE LEARNING AL ALCANCE DE TODOS

Durante la conferencia Microsoft Build se liberaron o dieron a conocer una gran cantidad de proyectos, como por ejemplo Vorlon.js para depurar código Javascript de forma remota, o la posibilidad de portar apps iOS y Android para Windows. Sin embargo, las noticias que más interés generaron entre los desarrolladores fueron las relacionadas con Visual Studio.

En los últimos meses hemos visto gran movimiento dinámico en la oferta de servicios de Machine Learning en la nube. IBM fue de los primeros en entrar en este espacio con el servicio de Watson Analytics. Microsoft anunció en febrero la disponibilidad oficial de Azure Machine Learning (previamente disponible como beta). Un par de meses después Amazon Web Services comunicó su servicio Amazon Machine Learning. A esta lista hay que agregar otras ofertas de proveedores de nicho como Prediction IO, así como la posibilidad de crear tu propio servicio de predicción directamente sobre Apache Spark o sobre una capa intermedia como Databricks Cloud.

La principal noticia en este sentido es Visual Studio Code, el primer editor de código creado por Microsoft que funciona en Mac y Linux (además de Windows, obviamente). Incluye muchas de las capacidades de Visual Studio como IntelliSense, navegación y depuración de código, pero está diseñado para operarse principalmente por medio del teclado (ya que en estas plataformas estamos más acostumbrados a teclear comandos que dar clic en iconos u opciones de menú). VS Code es gratuito y ya está disponible para descarga.

Cada uno de estos servicios tiene sus pros y contras. Por ejemplo, el servicio de Amazon es bastante sencillo de usar pero es muy limitado en cuanto a sus capacidades. En cambio, Watson Analytics y Azure Machine Learning son mucho más poderosos pero involucran una mayor curva de aprendizaje. Esperamos próximamente poder preparar un comparativo entre estos servicios y compartirlo en estas páginas.

Por su parte, Visual Studio 2015 (la versión “tradicional”) también ya está disponible como Release Candidate. Entre sus nuevas capacidades podemos encontrar mejoras al emulador Android, herramientas para Docker, y soporte para Apache Cordova.

ANGULAR 2.0 VS. 1.X

JAVA 7 LLEGA AL FINAL DE LA LÍNEA

En esta ocasión no les hablamos de algo que viene, sino de algo que se va. En abril de 2015 Oracle cesó la disponibilidad pública de parches y actualizaciones para Java 7 incitando a los usuarios a migrar a Java 8 o comprar un plan comercial de soporte de largo plazo para seguir recibiendo actualizaciones y parches para la máquina virtual de Java 7. Entonces, si tienes aplicaciones en producción que utilizan la JVM de Oracle para Java 7, ve revisando cuál va a ser tu estrategia ya sea para migrarla, comprar soporte comercial o utilizar otra máquina virtual que mantenga soporte.

006

SG.47

AngularJS es un framework Javascript para el desarrollo de apps web creado por Google que ha cobrado gran popularidad. En octubre de 2014 el equipo de Angular anunció planes para lanzar una versión 2.0 con grandes mejoras, pero que no sería retrocompatible con la rama 1.x. Como era de esperarse, la mayoría de los desarrolladores pusieron el grito en el cielo. Así que durante su conferencia, Angular (ng-conf) en marzo de este año, se dieron a conocer los planes actualizados... La rama 1.x se mantendrá, y estará hospedada en http://angularjs.org mientras que Angular 2.0, actualmente en versión alfa, será hospedado en http://angular.io. El plan es monitorear el tráfico a ambos sitios, así como la actividad en los repositorios de GitHub, para conocer el nivel de interés en cada rama y determinar hasta cuándo seguir manteniendo la rama 1.x, así como investigar posibles estrategias de migración de 1.x a 2. Angular 2.0 está principalmente enfocado al desarrollo de aplicaciones móviles, incorpora un mecanismo mejorado de dependency injection que soporta child injectors, aprovecha las capacidades de los navegadores más modernos y el código es más esbelto y con mejor desempeño que el de la rama 1.x. Así que a futuro, es mejor opción que 1.x. En resumen, si tienes aplicaciones hechas con Angular 1.x, puedes estar tranquilo por ahora, pero mantente al tanto de recomendaciones para posibles estrategias de migración a 2.0. Por otro lado, si apenas estás entrándole a Angular, vale la pena que mejor enfoques tus esfuerzos a Angular 2.0.

TENDENCIAS EN SOFTWARE

El Futuro del Software CAMBIANDO LA FORMA DE VENDER Y MERCADEAR — Por Luis Daniel Soto Maldonado

“IDC anticipa que para el año 2018 el 50% de las cargas de trabajo de software operarán en la nube pública”.

El mercado de “Software empresarial” es enorme, se estima en $317 billones de dólares anuales y tiene el mayor crecimiento porcentual en inversión en Tecnologías de Información [1]. La transformación del modelo “tradicional” al software como servicio (SaaS) ha cambiado los requerimientos, el modelo de negocio y la forma en que la casa de software empaquetado vende y se mercadea. No obstante, el cambio al SaaS ha sido mucho más lento que lo anticipado. La infraestructura como servicio abrió las puertas al software tradicional para operar en la nube, y en los meses más recientes dicha migración continúa acelerándose. Aún así, la nube pública, incluyendo a Google, Amazon y Microsoft tiene menos del 15% de la base instalada total de servidores a nivel mundial. IDC anticipa que para el año 2018 el 50% de las cargas de trabajo de software operarán en la nube pública [2]. ¿Cómo es esto posible?

Mercados de software empresarial Enfoquémonos en el software tradicional. Hoy el adquirir software empresarial no es simple: El “licenciamiento” es complejo, requiere de contratos y acuerdos legales con muchos proveedores. Agregar o reducir servicios sólo puede suceder en ciertos periodos y de forma limitada. Establecer una relación comercial y formas de pago con muchos vendedores es laborioso y difícil de administrar. En algunas ocasiones el software especializado no tiene distribuidores locales. Amazon es uno de los jugadores tratando de resolver estos problemas, con un nuevo modelo de menor fricción. Imagina que de la misma forma que se compran productos en el web o contenidos digitales sea posible adquirir software empresarial, utilizarlo por hora y disponer de muchos de los proveedores, en particular todos los de alta calidad que son evaluados por analistas como Gartner o Forrester. En el “AWS Marketplace” es posible rentar un software de CRM

o uno especializado para administrar Wi-Fi sólo por unas horas, usarlo en la nube y luego apagarlo permanentemente. Es posible adquirir un servidor de análisis de datos por mes, ya que la mayoría de proyectos tienen duraciones menores a tres meses y no justifican la compra anual ni “mantenimiento” del mismo. Este marketplace cuenta ya con más de 2 mil productos, con la ventaja para el cliente de que hay un único punto de contacto y atención, y una cuenta de servicios consolidada. Se facilita la evaluación de software como nunca antes. Luis Daniel Soto (@luis-

Para los vendedores también hay ventajas clave: vender alrededor del mundo, a grandes compradores y recibir el pago en Estados Unidos mediante la plataforma de comercio electrónico global, hacerse visible a más de un millón de clientes existentes, eliminar los problemas de la distribución física del software.

dans / @luisdanielsoto)

¿El fin del canal?

Inteligencia de negocios.

Algunas empresas de software han invertido 5-10 años en crear una muy amplia red de canales. La nueva realidad es distinta: El internet llega a los usuarios de negocio y estos van a poder acceder el software empresarial de la misma forma que funciona cualquier “app store” y en muchas ocasiones con nulo o muy poco soporte del departamento de sistemas. Los canales van a tener que enfocarse 100 por ciento en servicios de valor agregado, el licenciamiento del producto gradualmente desaparecerá, ya que el software será cada vez más un “producto básico”. La magia del software continuará, pero las reglas van a cambiar.

sotols@amazon.com

trabaja en Amazon Web Services, enfocado en el desarrollo global de negocios para Big Data e

Desde febrero de este año, estoy dedicado a la nueva misión de simplificar el acceso al software.

— Referencias [1] “Gartner Says Worldwide IT Spending on Pace to Grow 2.4 Percent in 2015”. http://swgu.ru/ps [2] “IDC: Worldwide Cloud Server 2014–2018 Forecast”. http://swgu.ru/pt

SG.COM.MX

007

TEJIENDO NUESTRA RED

KUALI- BEH como extensión de las alfas de ESENCIA (ESSENCE) PARA LOS QUE QUIEREN HACER EXPLÍCITAS SUS BUENAS PRÁCTICAS — Por Hanna Oktaba

La Dra. Hanna Oktaba es

En la columna anterior les platiqué sobre el concepto de las alfas de Esencia y su posible uso. Mientras se publicaba la revista, me enteré de que en noviembre del año pasado el estándar ESSENCE de OMG superó la prueba como beta 2 y, finalmente, fue publicado en su versión 1.0 [1] con KUALIBEH incluido. En la sección 6 del documento se pueden apreciar los reconocimientos para la UNAM y todas las organizaciones y personas que nos han apoyado en esta aventura.

profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares.

La historia de cómo se gestaba KUALI-BEH y como se “casó” con ESSENCE la pueden encontrar en mis columnas de los años entre 2012 y 2014. En esta ocasión les explicaré cual es el resultado final de la integración de KUALI-BEH a la Esencia.

@hannaoktaba

KUALI-BEH (buen camino) es una propuesta de conceptos comunes para los proyectos de desarrollo de software, que permiten expresar los métodos y prácticas de las organizaciones, así como su ejecución durante los proyectos. Se compone de dos vistas (Ver figura 1): estática y operacional. La vista estática permite a los ingenieros de software expresar sus formas de trabajar como métodos compuestos por prácticas, los cuales se resguardan como infraestructura del conocimiento de la organización. La vista operacional se relaciona con la realización dinámica de proyectos. Proporciona a los equipos los mecanismos para ejecutar los métodos adaptando sus prácticas al contexto específico del proyecto y a las necesidades de los involucrados. Entonces ¿cómo se integró KUALI-BEH a la Esencia? En la entrega anterior de esta columna en SG 46 expliqué qué son los alfas, el concepto básico de la propuesta de Ivar Jacobson y sus colegas. En particular, el área del Esfuerzo/Proyecto tiene tres alfas: Equipo (Team), Forma de Trabajar (Way of Working) y Trabajo (Work). Al analizar estas alfas nos dimos cuenta de que la vista estática de KUALI-BEH tiene que ver con la definición de

008

SG.47

la forma de trabajar y la vista operacional con el trabajo mismo. A raíz de esta observación, los colaboradores de Jacobson nos propusieron incorporar KUALI-BEH como extensión de los alfas de Way of Working y Work, lo que quedó documentado como Apéndice B (normativo) del estándar. En esta ocasión les quiero presentar cómo la vista estática de KUALI-BEH quedó expresada como sub-alfas de Way of Working llamadas Autoría de Práctica (Practice Authoring) y Autoría de Método (Method Authoring).

Autoría de práctica Es una guía definida de trabajo, con un objetivo específico, que asesora en la manera de producir un resultado a partir de una entrada. La guía proporciona un conjunto sistemático y repetitivo de actividades enfocadas en el logro del objetivo de la práctica y del resultado. Se definen los criterios de terminación, asociados al resultado, para determinar si fue logrado el objetivo. Se requieren competencias particulares para realizar las actividades de la guía, opcionalmente apoyadas por el uso de herramientas. Se pueden asociar las medidas seleccionadas para evaluar el desempeño y el logro de los objetivos de la práctica. Las medidas se estiman y se recogen las mediciones durante la ejecución de la práctica. La Autoría de Práctica proporciona un marco para que los practicantes definan sus diferentes formas de trabajar. La documentación de la especificación [1], en su anexo B dedicado a KUALI-BEH contiene una plantilla para definir prácticas. La figura 2 muestra los estados por los que pasa la autoría de práctica: Identificada, Expresada, Acordada, En Uso, En Optimización y Consolidada. Su uso es recomendado para las organizaciones que no tienen documentadas las formas de trabajar. Sobre todo, se sugiere que las pequeñas organizaciones intenten ponerse de acuerdo y expresar sus formas de trabajar tácitas, empezando por lo

TEJIENDO NUESTRA RED

“La Autoría de Práctica proporciona un marco para que los practicantes definan sus diferentes formas de trabajar”. Figura 1. Vista estática y operacional de KUALI-BEH.

Figura 2. Los estados de Practice Authoring sub-alfa.

que les parezca más importante, para que empiecen a acumular conocimiento explícito compartido por la organización. Cuando tengan definidas varias prácticas interrelacionadas pueden componerlas en un método.

Autoría de método Un método es una articulación de un conjunto coherente, consistente y completo de las prácticas, con un propósito específico, con el fin de cumplir con las necesidades de los involucrados en condiciones específicas. La sub-alfa de Autoría de Método pasa por los siguientes estados: Identificado, Integrado, Bien Formado, En Uso, En Optimización y Consolidado, que se ilustran en la figura 3. En nuestra propuesta para la autoría de las

Figura 3. Los estados de Method Authoring sub-alfa.

prácticas y métodos hay dos puntos que considero son novedosos: 1. Proponemos definición de prácticas y métodos (antes llamados procesos) de manera de “abajo hacia arriba” (bottom – up), a partir de las formas tácitas de trabajar, que cada organización tiene. Es decir, primero las prácticas individuales y luego su composición en métodos. Que luego se pueden ir mejorando en función de los acuerdos y necesidades de la propia organización.

suficientes para lograrlo (completo) y no generar desperdicios en actividades o productos innecesarios (consistente).

Conclusión Este es el primer acercamiento a lo que propone KUALI-BEH como parte del nuevo estándar de OMG Esencia. A los interesados les recomiendo revisar el Apéndice B para tener mayor detalle. Con gusto recibo sus comentarios en @hannaoktaba

— 2. El método bien formado (léase proceso) no es un conjunto de prácticas cualquiera, las prácticas tienen que aportar algo al propósito del método (coherente), ser

Referencias [1] ESSENCE: Kernel and Language for Software Engineering Methods 1.0. http://www.omg.org/spec/Essence/1.0

SG.COM.MX

009

EMPRENDIENDO

¿Sabemos qué Necesitan los Emprendedores? — Por Andrés Bianciotto

Nota del editor: Este artículo fue originalmente escrito en enero 2015 y por lo tanto se enfoca en “el inicio de año”. Por cuestiones ajenas al autor el artículo se está publicando en mayo, pero se mantiene igual de relevante.

Mientras estás leyendo esta nota, el precio del petróleo nos juega una mala pasada, anuncian otro recorte en Pemex y quizás el tercer recorte federal. Te preguntas ¿en qué mes fue el “Mexican Moment”? y ¿por qué parece tan lejano? Aún se escucha el eco de los grandes anuncios sobre reformas y todavía nos agobia el vacío que dejan miles de líneas borradas en archivos de Excel, como un pequeño hipo en la pantalla, mientras se ajustan las previsiones de crecimiento en grandes despachos.

TechCrunch (tcrn.ch/1FS7Y1O), o la adquisición de Aventones por BlaBlaCar.

Muchos ensayan esas frases trilladas que son mitad resignación, mitad refugio. Que así somos, que “puespaquésiyaves”, etc. Otros simplemente se levantan y comienzan otro día de mucho trabajo, paga insuficiente y pocas probabilidades de éxito. Como ayer, como mañana.

Hoy la “capa” de incubadoras y aceleradoras en México está bien poblada, aunque nunca sobran. Y cualquier proyecto que facture unos cuantos millones por año y tenga un camino claro de crecimiento puede conseguir capital mexicano o extranjero sin mucho peregrinar.

Los emprendedores mexicanos, por necedad o virtud, llevan años librando batallas que harían renunciar a Sísifo. Con un sistema financiero ausente, capital “de riesgo” conservador hasta el paroxismo, educación de otro siglo, burocracia Kafkiana y ni empecemos a hablar de las políticas federales “pro-emprendimiento”, estos Quijotes me hacen parafrasear aquella declaración de Jurassic Park: “entrepreneurship finds a way”.

Hay un vacío entre esos dos pasos, que es el desafío actual: una vez que se monta la startup y se valida el producto durante unos 6 meses de incubación, ¿quién pone 150 mil - 200 mil dólares para financiar el primer año “serio” de operación de la empresa, hasta que la facturación logre cubrir los gastos?

Como contrapartida, ese medio ácido no impide que cada tanto escuchemos de grandes operaciones, como la venta de SinDelantal.mx a Just Eat, por más de 20 millones de dólares según

Por supuesto que estamos lejos de las valuaciones “billonarias” de los Uber, Alibaba y Facebook del mundo, pero que eso no nos opaque la perspectiva: tenemos un nivel más que saludable de energía emprendedora que debemos encauzar y favorecer para establecer éxitos, repetirlos, exportarlos e inspirar a nuevas generaciones a seguir este camino.

Tenemos un grupo de emprendimientos que pasan por más de una incubadora en sus inicios, en una suerte de respirador artificial mientras reúnen fuerzas para dar el salto a la realidad. No sólo están absorbiendo recursos que se utilizarían mejor generando nuevas empresas,

sino que —aunque es mejor que la muerte— tampoco están en el sustrato correcto para la etapa de vida de la empresa, retrasando su crecimiento por falta de opciones. Un candidato más que saludable para tomar una posición fuerte en ese segmento es el mar de family offices que floreció en México a partir de la diáspora de empresarios medianos que salieron del país y establecieron una administración profesional para sus activos. Una vez dado ese paso, y más allá de alguna cuestión sentimental sobre la empresa familiar, las inversiones se evalúan según su mérito propio y proyectos atractivos pueden ser buen destino de capitales que en otra época irían directo a bienes raíces (y algunos aún lo hacen por defecto). Ya tuvimos muchos “años de”, ya vivimos el año del emprendimiento, el de las incubadoras, el de los eventos, el de las apps. Ya conocemos las estadísticas que indican que son las PyMEs y emprendimientos quienes emplean al grueso de la población activa. Ya descubrimos que ignorándolos no desaparecen. Comencemos a mirar seriamente a la materia prima que alimenta y se desdobla en todo lo otro: el loco solitario que un día se pone de pie y dice: “voy a mover esa piedra”. Es hora de que le preguntemos qué necesita. Es tiempo de hacerle la vida fácil, porque pocas veces tanto futuro depende de tan módica locura.

Andrés Bianciotto (@andresb) fundó Next.LA, un servicio de hosting especializado en medios digitales y dirige Founder Institute en México, una incubadora de startups con presencia en más de 100 ciudades del mundo. andres@next.la

010

SG.47

INFRAESTRUCTURA

Figura 1. Arquitectura de OpenStack

Todo como Servicio con OpenStack — Por Miguel Ángel Barajas

Sin duda el cómputo en la nube está cambiando la forma en la que consumimos recursos de cómputo. Nos estamos acostumbrando a consumir todo “como servicio”. Una de las formas más básicas de consumir recursos como servicio es el denominado Infrastructure as a Service (IaaS) donde básicamente rentamos una máquina virtual conectada a la red y pagamos por el uso de procesamiento, almacenamiento y transferencia de datos. Empresas como Amazon, Microsoft, HP e IBM ofrecen este servicio. Sin embargo, también existen productos y proyectos para que las empresas puedan crear su propia nube. Dentro de estos proyectos, el que más destaca es OpenStack, una plataforma para construir nubes altamente escalables. Openstack (http://openstack.org) es un sistema operativo de cómputo en la nube que controla grupos de recursos de cómputo, almacenamiento y redes. Se administra por medio de un panel de control (dashboard) y permite que los mismos usuarios puedan aprovisionar recursos a través de una interfaz web. OpenStack es software libre (licencia Apache 2.0) y se construye de forma abierta y colaborativa. Es muy rico en características y altamente configurable, por lo que permite crear soluciones para todo tipo de nubes. Puede controlar múltiples hipervisores y manejadores de virtualización, además de ser compatible con una gran variedad de hardware y software, lo cual nos ayuda a mitigar casos de “vendor lock-in”.

Proyectos de OpenStack OpenStack está organizado en torno a 3

grandes conceptos: cómputo, almacenamiento y red, que a su vez son soportados por varios servicios compartidos.

información en una base de datos compartida. La comunicación entre programas se realiza típicamente por medio de APIs y es “stateless”.

Al momento de editar este artículo, está por liberarse la versión Kilo de OpenStack (abril 2015), que incluye los siguientes proyectos: • Gestión de recursos de cómputo (Nova). • Almacenamiento de objetos (Swift). • Almacenamiento de bloques (Cinder). • Manejo de imágenes (Glance). • Aprovisionamiento de base de datos como servicio (Trove). • Manejo de redes y direcciones IP (Neutron). • Gestión de identidad y SSO (Keystone). • Panel de control (Horizon). • Orquestación de servicios (Heat). • Telemetría para monitorear el uso de servicios (Ceilometer). • Aprovisionamiento de clusters MapReduce para Hadoop y Spark (Sahara). • Aprovisionamiento en “bare metal” (Ironic). • Mensajería entre aplicaciones (Zaqar). • Sistema de archivos compartido (Manila). • DNS como servicio (Designate). • Gestión de llaves secretas (Barbican).

La comunicación directa con el hardware o software a controlar se hace mediante agentes y/o plug-ins específicos del fabricante.

Arquitectura La figura 1 muestra un diagrama con un ejemplo de arquitectura común de OpenStack, donde se muestran los principales servicios y cómo interactúan entre sí. Aunque a primer vista se ve complicada, en realidad no lo es tanto si nos abstraemos al nivel de los distintos servicios (compute, storage, network, etc). Los programas mantienen su

Distribuciones de OpenStack OpenStack sufre del mismo “problema” que GNU/Linux en cuanto a que la configuración, empaquetado e instalación manual es un compleja. Por ello, al igual que GNU/Linux Openstack se distribuye de una manera empaquetada. Es así que los “sospechosos comunes” son los que han creado distribuciones los cuales dan soporte y mantenimiento así como compatibilidad con sus propias distribuciones de GNU/Linux, una lista no extensiva de estas distribuciones de OpenStack son: RDO de RedHat, SUSE Cloud de SUSE, Ubuntu OpenStack, Mirantis. También está Devstack, que es un “shellscript” que nos permite hacer un despliegue automatizado de OpenStack en una sola máquina virtual para propósitos de pruebas. Es una excelente forma de jugar un poco con la plataforma y entender un poco más como funciona OpenStack.

Conclusión OpenStack es una excelente opción para aquellas empresas que desean establecer su propia infraestructura de cómputo como servicio. Al ser una plataforma abierta, ayuda a las empresas a evitar el evitar el vendor lock-in, reducir costos y tener mayor control sobre su futuro tecnológico.

Miguel Ángel Barajas (@gnuowned) es un Arquitecto Senior de Soluciones especializado en cómputo en la nube. Actualmente colabora con Cisco Systems atendiendo clientes en la región de Latinoamérica.

012

SG.47

CONTENIDO PATROCINADO

WebRatio Platform DESTÁCATE EN LA ERA DE LOS NEGOCIOS DIGITALES

WebRatio es una plataforma para desarrollar aplicaciones móviles y web innovadoras sin escribir ni una sola línea de código.

Singularidad y velocidad La revolución digital que vivimos permite a las empresas ofrecer productos y servicios únicos, revolucionando el mercado y respondiendo a las necesidades de los clientes de forma fácil y rápida. Para satisfacer las exigencias de los mercados dinámicos que demandan velocidad y agilidad, las organizaciones de TI deben ver más allá de los métodos de desarrollo tradicional. WebRatio ha creado la herramienta de desarrollo ágil: WebRatio Platform, la cual ayuda a los CIOs y desarrolladores a entregar siempre a tiempo sus proyectos. Es una plataforma integrada en Eclipse que permite desarrollar aplicaciones móviles y web de forma visual ahorrando hasta el 80% de los tiempos y los costos en comparación con métodos tradicionales.

Figura 1. WebRatio trabaja en base a estándares y evitas lock-in.

Para las aplicaciones móviles se utiliza la arquitectura abierta de Apache Cordova (PhoneGap), junto con Ionic, AngularJS y SQLite para poder definir la aplicación solo una vez y luego liberarla ya sea para Android o iOS. La figura 1 muestra este proceso a grandes rasgos.

Aplicaciones para todas las necesidades ¿Cómo funciona WebRatio? WebRatio es una plataforma visual. El desarrollador diseña el modelo conceptual de la aplicación sea para la definición del front-end, back-end y la integración con otros sistemas. Una vez definido el modelo, WebRatio Platform genera automáticamente todo el código necesario para el funcionamiento de la aplicación. Los usuarios de WebRatio pueden personalizar en cualquier momento las reglas de generación y los componentes de sus proyectos utilizando lenguajes a ellos familiares. WebRatio Platform es simple: cada experto tiene una vista dedicada para sus actividades y la plataforma se ocupa de la integración de las distintas partes del proyecto.

WebRatio permite no solo crear sistemas para responder a necesidades existentes, sino también construir soluciones innovadoras que ofrezcan nuevas posibilidades. Un ejemplo es el proyecto evenTometers (www.eventometers.com) realizado en conjunto con Fluxedo y Eurotech; es una solución tipo IoT (Internet of Things) para poner a disposición de las empresas sistemas inteligentes que puedan facilitar la recolección, análisis y difusión de datos durante eventos. WebRatio está disponible en tres ediciones: • Community edition (gratuita) para crear aplicaciones sencillas de uso personal. • Professional edition para freelancers y pequeños negocios. • Enterprise edition para empresas grandes y aplicaciones. Más información en www.webratio.com

Ágil y segura, basada en estándares

WebRatio: la empresa

WebRatio Platform se basa únicamente en estándares sin utilizar lenguajes que aten a los desarrolladores y las empresas al uso de la plataforma (no vendor lock-in). El desarrollador podrá tener acceso al código generado con total libertad de manipularlo.

WebRatio es una empresa Italiana que opera en Norteamérica, América Latina y Europa. Desde el 2001 WebRatio ofrece sus plataformas de desarrollo para la creación de aplicaciones empresariales móviles y web. En 2013, Gartner nombró a WebRatio como «Cool Vendor». WebRatio es creador original del Interaction Flow Modeling Language (IFML), actualmente estándar de la OMG.

Junto a los estándares UML y BPMN, WebRatio Platform soporta IFML (Lenguaje de Modelado de los Flujos de Interacción), una nueva notación para la definición de la UX de la aplicación y que además es un estándar de industria gestionado por el Object Management Group (OMG). El código generado por las aplicaciones web es 100% Java. El front-end de las aplicaciones se vuelve responsivo y dinámico gracias al uso de HTML5, CSS3 y Javascript. Para el back-end se utiliza Java, Spring y Hibernate, también se integra con todas las bases de datos, sistemas gerenciales y otros que ya existan en la empresa.

WebRatio cuenta con una red internacional de partners. En México, las empresas que ya están ofreciendo productos y servicios WebRatio son: Genoco, Innovatedu, 4 Tools Power Systems e IDT Mexicana de Servicios.

Contáctanos Estados Unidos: +1 612 638 2762 Latinoamérica (Ecuador): +593 7 4103 792 Estaremos presentes en SG CONFERENCE & EXPO 2015, ¡ven a conocernos!

SG.COM.MX

013

TUTORIAL

Desarrollo Cross-Platform con Xamarin.Forms — Por Alder López

Xamarin es una plataforma para desarrollar aplicaciones para plataformas iOS, Android, Windows Phone, Windows Store y Mac usando el lenguaje de programación C#. Cabe aclarar que en este artículo sólo trataremos el desarrollo de Android e iOS por ser las plataformas de terceros. Para Windows Phone o Windows Store, si somos desarrolladores de .NET no se nos complica en lo absoluto, es muy parecido a lo que ya sabemos desarrollar, sólo que con diferentes estándares de desarrollo de la UI (User Interface). Es importante mencionar que Xamarin dispone de una versión para estudiantes, con la que se puede compilar y probar las aplicaciones utilizando Xamarin Studio. Adicionalmente se anunció hace algunos meses la firma de colaboración entre Xamarin y Microsoft, que además de tener un equipo de trabajo dedicado a optimizar y explotar mejor los recursos de las diferentes plataformas, se tendrá disponible desde la versión Visual Studio Community 2015 la Free Xamarin Starter Edition for Visual Studio Users, es decir, podremos compilar, ejecutar y probar las aplicaciones para Android e iOS, por lo que si había duda de qué tan fuerte está Xamarin en el mercado, con los recientes anuncios por parte de ambas compañías vemos una seria consolidación en el mundo de desarrollo de aplicaciones multiplataforma y se despeja la interrogante.

podemos reutilizar el código en un 75-85% según fuentes oficiales. Esto no quiere decir que no tengamos que saber detalles de cada plataforma, de hecho lo mejor es conocer al menos conceptos básicos del manejo de recursos, configuraciones, etcétera, ya que al final el proceso es como si estuviéramos desarrollando una aplicación nativa respectivamente, pues se genera una .APK para Android y un .IPA para iOS; y se le debe dar el tratamiento normal a cada una para probar en dispositivos o emuladores para posteriormente publicar. Otro punto importante es que para Android por ejemplo, si tenemos algunos componentes en java podemos utilizarlo por medio de lo que llamamos Java Integration, para hacer un Java Bindings Library (una clase wrapper del tipo en java) para hacer referencia desde C# hacia los archivos .jar; así como también un Java Native Interface (JNI) que permite realizar llamadas a código java corriendo en la JVM (Java Virtual Machine) desde aplicaciones no escritas en java, por lo cual Xamarin.Android utiliza JNI para crear sus bindings en el codigo C#.

Xamarin nos da la posibilidad de tener una base de código compartido que contiene entidades de negocio, lógica de negocio, acceso a servicios, etcétera, y simplemente tener código distinto para los detalles de interfaz de usuario para la capa de cliente en cada plataforma. Básicamente es como desarrollar al mismo tiempo para todas las plataformas, por lo que minimizamos tiempos de desarrollo. Por ejemplo, tradicionalmente tenemos que desarrollar la aplicación en Java para Android y en Objective-C para iOS la misma funcionalidad, lo cual es tedioso y repetitivo, con Xamarin

La figura 2 ilustra la arquitectura típica de una aplicación Xamarin.

Por ejemplo para Android, al construir el proyecto nos generará el archivo .APK, el cual podremos ejecutar en un emulador, en un dispositivo o incluso en la tienda de google realizando el proceso tradicional.

Lo que muestra la figura 1 es que tenemos un proyecto o librería compartida que contiene los componentes de las capas de negocio, servicios y datos. Por otro lado, tenemos distintas aplicaciones para cada tipo de cliente, que utilizan las librerías y componentes nativos de la User Interface de cada plataforma. Las aplicaciones cliente acceden al código compartido para interactuar con las capas de negocio, servicios y datos. Para desarrollar las aplicaciones nativas para cada plataforma, Xamarin ofrece dos estrategias: • La primera es crear aplicaciones específicas para cada plataforma por ejemplo utilizando Xamarin.iOS y Xamarin.Android, dependiendo del caso. Esto permite aprovechar los elementos de UI específicos de cada plataforma y construir así interfaces de usuario avanzadas y personalizadas para cada una. • La segunda estrategia es Xamarin.Forms. Una serie de componentes que permite definir interfaces de usuario para distintas plataformas desde una misma base de código. Xamarin.Forms está orientado a construir aplicaciones con interfaces de usuario sencillas, donde es más importante la capacidad de compartir código que el brindar interfaces de usuario avanzadas y personalizadas para cada plataforma, sin embargo, existe la posibilidad de hacer la personalización de los componentes a cada plataforma heredando nuestro componente básico de Xamarin.Forms a uno que se implementara en el proyecto de iOS y Android , y ahi podemos usar instrucciones típicas (equivalentes en .NET) de Objective-C y Java respectivamente.

Primera aplicación Xamarin.Forms Figura 1. Arquitectura de aplicación Xamarin.

A continuación mostraremos cómo se construye una aplicación con Xamarin.Forms. Por ahora solo

Alder López es ingeniero de software e investigador en la empresa Advanced Technology Research. Se especializa en el desarrollo de aplicaciones móviles. https://mx.linkedin.com/in/alder1sismty

014

SG.47

TUTORIAL

plataforma utilizando la directriz #ifdef. Por ejemplo, un bloque con #ifdef __ANDROID__ solo se ejecutará en plataforma Android.

crearemos para iOS y Android como se mencionó antes. Haremos esto en Visual Studio. 1. Visual Studio –> Nuevo Proyecto. 2. Seleccionamos aplicación en blanco de tipo Xamarin.Forms.Portable. 3. En el nombre de la solución, escribimos “SG”. Enseguida tenemos 3 proyectos: El primero es SG, un proyecto portable en el que vamos a escribir el código común. En los proyectos SG.Android y SG.iOS vamos a escribir lo requerido por cada plaforma. La figura 2 muestra la estructura generada.

Listado 1. App.cs Listado 4. Forma de login.

Listado 2. MainActivity.css

Figura 3. Ejemplo de pantallas de login.

Una segunda forma de lograrlo sería utilizar la clase Device y TargetPlatform, como se muestra en el listado 5.

Figura 2. Estructura del proyecto.

Listado 3. AppDelegate.cs

En el proyecto SG tendremos el programa App. cs cuyo código base se muestra en el listado 1.

Si quisiéramos hacer una forma de captura, por ejemplo un login con usuario/contraseña, incluiríamos un código similar al del listado 4 en nuestro proyecto portable, sin necesidad de tener que mover un dedo sobre el código de iOS y Android. La figura 3 muestra cómo se despliega esta forma tanto en iOS como en Android. Nótese que en cada caso se aplica automáticamente el estilo default de la plataforma correspondiente.

El listado 2 muestra el el código del MainActivity.cs en el proyecto de Android, y el listado 3 muestra AppDelegate.cs para el proyecto iOS. Notemos que en los proyectos SG.Droid y SG.iOS se tiene la instrucción: Xamarin.Forms.Forms.Init(this, bundle); Este código inicializa los componentes necesarios para que todo esto funcione.

Inyección de dependencia Incluso en el proyecto Portable podemos especificar un comportamiento diferente para cada

Listado 5. Consultar plataforma.

Una tercera forma es utilizar inyección de dependencias. La forma de lograr esto es que en el proyecto portable definimos las interfaces de nuestras clases, y éstas se implementarán en cada plataforma (iOS y Android para nuestro caso), utilizando DependencyService de Xamarin para instanciar las implementaciones

SG.COM.MX

015

TUTORIAL

o si se requiere algo mucho más robusto podemos utilizar Unity , TinyIOC, Autofac entre otras que se pueden obtener desde Nuget. Las principales clases candidatas a ser implementadas por medio de inyección de dependencias son las que utilizarán recursos propiamente de la plataforma como: acceder a la ruta de la aplicación en el dispositivo móvil para almacenar un archivo, acceso a los recursos de redes, preferencias, creación y acceso a una base de datos de SQLite, preferencias de la aplicación en el dispositivo, personalizar un control como un botón, un grid, procesamiento de una imagen, etcétera.

public class CustomEntry: Entry { }

Listado 7. Implementación para Android

Posteriormente, implementamos la personalización de dicho control en Android e iOS. El listado 9 tiene la personalización para Android, y el 10 para iOS. Analizando el código, podemos darnos cuenta que existen diferencias irreconciliables entre plataformas por la forma en que procesan sus datos y la arquitectura, por lo que es necesario que en funcionalidades como estas desarrollemos el código específico para la plataforma.

DependencyService es el medio por el cual podemos resolver las interfaces cuya implementación se encuentra en cada plataforma. Al utilizar:

Estilos [assembly:Dependency(typeof( Clase))] estamos indicando a .Net que esa clase podrá resolverse mediante DependencyService tomando la implementación en la plataforma en ejecución. A continuación mostraré un ejemplo para realizar la funcionalidad de localización de recursos para soportar multilenguaje. Primero, en el proyecto portable declaramos un interfaz llamado ILocalizeService. El listado 6 muestra el código.

Listado 8. Implementación para iOS

Teniendo estas implementaciones, basta con poner desde nuestro código portable algo como: var language = DependencyService.Get<ILocale>(). GetCurrent();

Podemos definir estilos que determinen los aspectos visuales de nuestra interfaz de usuario tales como colores, tipografías, tamaños, etcétera; de tal manera que no estemos redefiniendo dichos estilos en cada pantalla. Para lo cual creamos una clase donde definimos los estilos y de ahí los vamos colocando según se requiera. El listado 11 muestra el código de un programa AppStyles.cs que define un estilo para objetos Label. Este código es independiente de la plataforma así que sólo se fija una vez en nuestro proyecto portable.

Personalización de controles

Listado 6. Definición de interfaz.

Lo siguiente es codificar la implementación puntual de esta funcionalidad en cada plataforma. El listado 7 contiene la implementación para Android, y el listado 8 para iOS.

016

SG.47

Otro tema muy importante en Xamarin.Form es que es posible personalizar los controles UI específicos para cada plataforma utilizando Custom Renderers. Esto se realiza mediante la directriz ExportRenderer. A continuación veremos un ejemplo donde personalizamos un control para cada plataforma. En nuestro proyecto portable definimos un CustomEntry de la siguiente forma:

Entonces cuando creamos un objeto Label, podemos establecer su estilo de la siguiente forma: var nameLabel = new Label () { Text = “Name”, Style = AppStyles.LabelStyle };

Listado 9. CustomEntryRenderer en Android.

Listado 10. CustomEntryRenderer en iOS.

Listado 11. Definición de estilos.

Conclusión En este artículo hemos visto cómo por medio de Xamarin.Forms podemos construir aplicaciones móviles que reutilicen elementos de código común para generar aplicaciones nativas para cada plataforma, y también hemos visto algunas formas en que podemos ajustar el comportamiento y estilo de cada plataforma. El código generado durante este tutorial está disponible como un repositorio en: https://github.com/pacificIT/SG.Xamarin

COMERCIO DIGITAL HACE MÁS DE 15 AÑOS QUE SE REALIZA COMERCIO POR MEDIO DE INTERNET, ASÍ QUE DISTA DE SER UNA NOVEDAD. SIN EMBARGO, DESPUÉS DE MÁS DE DÉCADA Y MEDIA DE EVOLUCIÓN, HAY ALGO EN EL ÁMBITO DEL COMERCIO DIGITAL QUE LE ESTÁ DANDO UN NUEVO AUGE. MÁS AÚN, POR PRIMERA VEZ EN LATINOAMÉRICA LO ESTAMOS ATESTIGUANDO COMO ALGO VIABLE Y DISPONIBLE LOCALMENTE. LA MAYOR PENETRACIÓN DE CONECTIVIDAD DE BANDA ANCHA, LA DISPONIBILIDAD DE MECANISMOS DE PAGO DIGITAL —INCLUSO NUEVOS TIPOS DE MONEDA DIGITALMENTE NATIVAS— Y LA LLEGADA DE LOS MILLENIALS A LA FUERZA LABORAL (Y POR LO TANTO CON CAPACIDAD DE ADQUISICIÓN) SON ALGUNOS DE LOS FACTORES QUE ESTÁN IMPULSANDO ESTA NUEVA OLA DE COMERCIO DIGITAL. A TRAVÉS DE LAS SIGUIENTES PÁGINAS ANALIZAMOS ESTOS FACTORES CON MIRAS A PODER EXPLOTAR AL MÁXIMO SUS POSIBILIDADES. COMENCEMOS (Y COMERCIEMOS)...

018

SG.47

SG.COM.MX

019

EL SUPERMERCADO DIGITAL Por Pedro Galván

Parte 1. El Lechero Digital Probablemente si hoy le explicaras a tus hijos que en tu infancia había un señor que andaba de casa en casa vendiendo leche, les costaría trabajo imaginarlo. El mundo actual parece estar muy lejos de ese modelo de venta. Sin embargo, en todo el mundo se está viendo un resurgimiento del modelo de entrega a domicilio, pero con la novedad de que está habilitado por tecnología. Los consumidores no sólo están pidiendo por teléfono; cada vez más lo están haciendo desde web o desde apps móviles. En un estudio realizado recientemente por The Nielsen Company, una cuarta parte de los participantes indicaron ya estar comprando despensa vía internet para entrega a domicilio, y 55% indicó estar interesados en hacerlo próximamente. En resumen, el lechero ha vuelto pero ahora es digital.

Cada vez más, los comercios están introduciendo modelos de e-commerce que facilitan a los consumidores a comprar en línea los productos que les interesan. Por ejemplo, en 2011, Tesco (Homeplus) introdujo el primer supermercado virtual en una estación del metro de Seúl en Corea del Sur (ver figura 1). El supermercado consistía en letreros (pósters) en la pared con imágenes de productos que el usuario seleccionaba con una app y al hacer “check-out” se enviaban ese mismo día a su casa. De esta manera, los usuarios aprovechaban su tiempo mientras esperaban a que llegara el metro.

Los compradores están puestos The Nielsen Company recientemente realizó una encuesta en la que participaron más de 30 mil personas en 60 países para entender el impacto que la tecnología digital tendrá en el escenario de grocery shopping (“comprar la despensa”) del futuro. El reporte “The Future of Grocery” [1] generado a partir de los resultados de la encuesta, muestra cómo los consumidores utilizan la tecnología para comprar y ofrece ideas de cómo los comercios pueden aprovechar esta oportunidad para mejorar la experiencia de sus clientes. Dado que la encuesta se realizó por medio de internet, sólo refleja el comportamiento de personas que

020

SG.47

tienen capacidad de compra. Estos consumidores tienen un gran entusiasmo por la tecnología y para ellos comprar vía internet es natural. Por ejemplo, 30% de los millenials (edades de 21 a 34 años) y 28% de la generación Z (15 a 20 años) ya hacen algunas compras de despensa por internet. La figura 1 muestra mayor detalle.

¿Qué está pasando localmente? Figura 1. Supermercado virtual en Seúl.

ya están activas en línea, y por lo tanto no es representativo de la población en general. Aun así, el estudio sin duda nos permite ver hacia donde van las cosas. 13% de los participantes indicaron realizar compras en alguna tienda virtual con entrega a domicilio, y un 12% indicó que realizan órdenes por internet y pasan a recoger su pedido. Más del 50% están interesados en utilizar estas opciones en el futuro. El crecimiento de las ventas en línea se debe en gran parte a que los jóvenes que crecieron con la tecnología digital están alcanzando la madurez y

En México, aunque son todavía pocas las empresas que venden artículos de despensa en línea con entrega a domicilio, sí las hay y se espera que la oferta aumente considerablemente durante los próximos años. Por un lado están las grandes tiendas de supermercados como Superama que lo ofrecen desde hace varios años, pero también han surgido startups para productos de especialidad, o difíciles de conseguir. Un ejemplo es My Coffee Box, un servicio de suscripción online que te envía cada mes a domicilio una dotación de café gourmet sembrado por pequeños productores nacionales. Otro caso es el de Good Express, una tienda en línea de comida saludable (por si no sabes en dónde conseguir esos mazapanes de alga spirulina). Mi Alacena es otro nuevo startup, que busca permitirte comprar productos y alimentos que no hay en tu ciudad y

EN PORTADA

Figura 2. Hábitos de compra en internet por generación. Figura 3. Uso e intención de digitalizar experiencia en tienda.

recibirlos en tu domicilio (conforme escribo esto se me antojan unos tamales de elote de la Chata de Culiacán). Si conoces otros casos que quieras compartir de empresas locales que están haciendo e-commerce en nuestra región, por favor coméntalos en la versión online de este artículo en http://swgu.ru/q3

Parte 2. Mejorando la Experiencia en Tiendas Físicas La primera parte de este artículo se enfoca en la compra de productos con entrega a domicilio. Es decir, en cómo la tecnología puede ayudar al consumidor a evitar las tiendas físicas. Pero las tiendas físicas (brick and mortar) seguirán predominando, al menos en un futuro cercano. Además del beneficio obvio que ofrecen de poder obtener un producto inmediatamente y sin costos de envío, hay experiencias sensoriales que son prácticamente imposibles de replicar en línea, como por ejemplo el olor de pan recién horneado. De hecho, 61% de los participantes en el estudio de Nielsen previamente mencionado, consideraron que ir al supermercado es una experiencia grata. Así que las tiendas de autoservicio deben buscar cómo aprovechar la tecnología para asegurarse de que la experiencia del consumidor sea grata, eficiente y asegure su retención.

Imagina un supermercado en el que al momento de entrar recibes recomendaciones y ofertas personalizadas, donde de antemano puedas saber en qué pasillo y estante está el producto que buscas, donde puedas saber cuándo y en donde se cosechó una fruta, donde no tengas que hacer cola y ni siquiera tengas que sacar tu cartera para pagar. Suena futurista, pero si lo piensas, la tecnología para hacerlo ya existe. Posiblemente sea un caso de “el futuro ya está aquí, pero no está distribuido uniformemente”. Pero la compra vía internet es solamente un aspecto de la transformación digital del autoservicio. Una estrategia digital completa para retail incluye interacción en todos los puntos de la experiencia de compra, desde localizar tiendas, hacer listas, checar precios, investigar productos, pagar, y compartir tu experiencia de compra o uso de un producto con otros (ej. en redes sociales). Todos estos puntos de interacción se dan dentro y fuera de las tiendas, y los consumidores crecientemente utilizan tecnología para simplificar y mejorar el proceso. Insertar estrategias digitales a la experiencia de compra en tiendas físicas todavía es algo novedoso y experimental. Las tiendas de autoservicio tienen mucho camino que recorrer para cubrir aspectos básicos de habilitación digital tales como cupones móviles, apps para listas

de compra, y Wi-Fi. Actualmente, sólo un pequeño porcentaje de consumidores en el mundo está utilizando tales capacidades, pero hay un alto interés por hacerlo. Por ejemplo, un 18% reporta utilizar cupones digitales actualmente pero un 65% planea hacerlo próximamente. El caso de las listas de compra en el móvil es similar, con un 15% de uso actual y un 64% de intención futura. 14% indicó utilizar una app de la tienda o de su programa de lealtad para recibir información y ofertas, y un 63% planea usarlas cuando estén disponibles para la tienda de su preferencia. 12% reporta utilizar el Wi-Fi de la tienda para recibir ofertas, y un 11% escanea códigos QR para acceder a mayor información. La figura 3 refleja los porcentajes de uso e interés en las distintas regiones del mundo, para distintas posibilidades que complementen la experiencia digital en una tienda física. Como podemos ver, la región de Asia Pacífico es donde estas capacidades están más instaladas y los consumidores tienen mayor disposición a utilizarlas. En Latinoamérica, aunque el uso actual es bajo, hay bastante entusiasmo por hacerlo en el futuro. Todas las estadísticas y gráficas presentadas en este artículo se obtuvieron del estudio “The Future of Grocery”, publicado por The Nielsen Company en abril de 2015. Para obtener una copia del reporte, visita http://swgu.ru/py

Pedro Galván es cofundador y director editorial de SG Software Guru.

SG.COM.MX

021

GATEWAYS DE PAGO EN LATAM Por Pedro Galván

Si estás desarrollando un sitio web o app desde el cual quieres que tus usuarios puedan pagar por un producto o servicio, seguramente requerirás utilizar un gateway de pago. Este tipo de servicios se encargan de operar el cargo a tarjetas de crédito y otros medios (ej. gestionar pagos por medio de tiendas de autoservicio). Sin embargo, ante la variedad de gateways de pago que han surgido en los últimos años en nuestra región, la pregunta es: ¿cuál elegir? A continuación comparto un listado con un breve análisis de los gateways disponibles en nuestra región que considero más relevantes. PayPal. Es el más conocido y utilizado a nivel mundial. Y México no es la excepción, a pesar de que las comisiones que cobra son relativamente altas (4% + $4 pesos por cargos a tarjetas de crédito) además de que ofrece las menores posibilidades de personalización ya que en nuestra región sólo soporta el nivel de servicio PayPal Payments Standard. http://paypal.com Conekta. El retador local. Soporta una gran cantidad de medios de pago como tarjetas de crédito y débito Visa y Mastercard nacionales e internacionales, American Express, pago en tiendas Oxxo, y transferencia bancaria por SPEI. Las comisiones que cobra están en el nivel bajo (para Latinoamérica): no hay costo de instalación, y se cobra una comisión de 2.9% + $2.5 pesos por cada operación con tarjeta Visa o Mastercard; 3.5% + $2.5 en Oxxo y 4.5% + $2.5 con American Express. Expone un API REST, y ofrece scripts de integración client-side en javascript, iOS y Android. Del lado del servidor ofrece librerías para Ruby, Python, PHP, y Java. https://www.conekta.io OpenPay. Otro retador local. Las características, comisiones y hasta librerías son muy similares a las de Conekta. Podríamos decir que son como gemelos pero nacidos de distintas madres. Una de las diferencias es que en el caso de tiendas de autoservicio, OpenPay no utiliza Oxxo sino otras tiendas como 7 Eleven, Extra, Farmacias Benavides, entre otras. Aunque no tuvimos oportunidad de probar sus librerías de integración, en papel parece ser el ganador de esa categoría por la amplia variedad de lenguajes que soporta, además de que su documentación técnica está muy bien organizada. http://www.openpay.mx

022

SG.47

Compropago. Solamente soporta pago por medio de tiendas de autoservicio. Sin embargo, la comisión que cobra es la menor para este tipo de pago (2.9% + $3) y soporta una amplia red de tiendas que no solo incluye a los sospechosos comunes como Oxxo, 7 Eleven y Extra, sino también a tiendas Soriana, Chedraui, Elektra, Coppel, entre otras. https://www.compropago.com Astropay. Gateway originario del Reino Unido y enfocado en atender países en desarrollo. En el caso de Latinoamérica, soporta transacciones en Argentina, Brasil, Chile, Colombia, México, Perú y Uruguay. Uno de sus distintivos es que su solución tecnológica se basa en el protocolo Ripple, el cual está diseñado especialmente para la interacción entre instituciones financieras. Además del servicio de gateway, Astropay tiene un servicio de tarjeta (Astropay card) que es como una cuenta donde acarreas saldo y con la cual puedes pagar en sitios web que soporten Astropay. https://merchant.astropay.com PayU. Es lo que antes se conocía como DineroMail, y es una de las empresas pioneras en soportar pagos en tiendas de autoservicio en nuestra región. Las comisiones que cobra están en el mismo rango que Conekta y OpenPay. Entre sus fortalezas está la amplia presencia que tiene a nivel Latinoamérica, soportando transacciones en Argentina, Brasil, Colombia, Chile, México, Panamá y Perú; con una amplia red de tiendas de autoservicio en cada país. http://www.payu.com Mercado Pago. Es el gateway de pago creado por la empresa Mercado Libre. (No está de más

decir que Mercado Libre es un titán del comercio electrónico). Mercado Pago tiene presencia en varios países de nuestra región. Las comisiones son un poco mayores que las del segmento bajo, cobrando 3.79% + $4.00 en el caso de México. https://www.mercadopago.com Stripe. Es un gateway importante a nivel internacional, sin embargo para Latinoamérica por el momento sólo tiene un beta privado en México que únicamente acepta pagos en pesos mexicanos. https://stripe.com Opté por no mencionar a los servicios que proveen un lector de tarjeta tales como iZettle, Clip, o Pago Facil, porque a pesar de que algunos ofrecen APIs que se pueden usar como gateway, en realidad están más enfocados a usarse como solución integrada para agregar a tu aplicación. Sí es posible hacerlo, pero no es en lo que destacan.

Conclusión La gran cantidad de proveedores que han surgido en este espacio en los últimos años es prueba del interés que hay por resolver el reto de los pagos digitales en nuestra región. Nos sorprendió gratamente ver a competidores locales que están haciendo un excelente trabajo. Esperamos que esto comience a rendir frutos pronto, mejorando el comercio digital en nuestra región e impactando positivamente las economías de nuestros países. Agradezco a Eugenio Perea y Fernando Ramos por la información provista para el desarrollo de este artículo.

EN PORTADA

M-COMMERCE USANDO BITCOIN Por Joel Cano

La migración hacia la economía móvil será una de las tendencias tecnológicas que veremos consolidarse en 2015. Los servicios como el comercio móvil, la banca móvil y los servicios de billeteras para Bitcoin han hecho que el número de usuarios de teléfonos móviles que realizan transacciones y compran bienes y servicios se incremente de manera rápida. Las transacciones bancarias, los pagos de servicios, las compras de productos y servicios se realizan cada vez más usando dispositivos móviles; y éstos a través de aplicaciones que han sido habilitadas con la capacidad de hacer “compra-en” mismas que se conectan a las cuentas de débito o crédito de los usuarios vía sistemas de pago les permiten hoy comprar libros, solicitar taxis o hacer pagos mediante sistemas de banca móvil.

mismas transacciones de una manera completamente digital, eliminando intermediarios y para transacciones de cualquier monto. Adopción Bitcoin • 8.5 millones de billeteras. • 88 mil comercios. • 180 miles de millones USD de ingresos. • 374 cajeros automáticos. • 3.4 miles de millones USD de capitalización. • 14 millones de bitcoins en circulación. Por ejemplo un usuario puede tener una billetera digital que le permitiría pagar el monto del transporte público, la mensualidad de un auto o incluso el auto completo con la misma forma de moneda.

Otra limitante son los montos de transacción, debido a los altos costos en el uso de estos servicios, y a la posibilidad de rechazo en la adopción por parte de los usuarios, hacen difícil justificar a muchos negocios la posibilidad de ofrecer estos servicios.

La billetera funciona en el teléfono inteligente y conectada a un Exchange puede hacer transacciones de prácticamente cualquier monto de manera sencilla. Sólo se descarga la aplicación de billetera como BlockChain Wallet o Hive por ejemplo, se solicita la dirección pública de la billetera o punto de venta donde se realizará el pago de la compra y listo. Si se necesita comprar o cambiar los Bitcoins que se han recibido, simplemente se crea una cuenta en un Exchange como meXBT y desde ahí es posible comprar o cambiar Bitcoins por pesos o dólares. La cuenta en el Exchange se puede cargar en efectivo o mediante transferencias electrónicas a través de 160 mil tiendas de conveniencia .

Pero hay una nueva tecnología que podría cambiar esta realidad en el futuro cercano, BlockChain y Bitcoin permiten hacer estas

Tambien se pueden enviar los bitcoins a un cajero que tenga la opción de dinero móvil y sin necesidad de una cuenta bancaria retirar

Desafortunadamente la cantidad de teléfonos inteligentes conectados a internet, así como la penetración del dinero electrónico mediante tarjetas de débito y crédito es limitada. Se estima que existe una penetración de no más de 40% de los servicios financieros en México.

Figura 1. Inversión en bitcoin.

efectivo con una solución llamada sendbitcoin.mx mediante el envio de una cuenta instantánea a teléfono celular y con un código de seguridad de cuatro caracteres realizar la operación de manera segura.

en este tipo de tecnología que promete cambiar la manera en como manejamos el dinero y los valores al igual que sucedió con la información antes y después de internet (ver figura 1).

Otras tecnologías que ya están disponibles son por ejemplo “SIMcards” que habilitan un telefóno celular tradicional o inteligente como una billetera con bitsim.co; y si se están desarrollando aplicaciones móviles para teléfonos inteligentes y se desea integrarles opciones de pago seguras, se puede lograr mediante bitcoin en rivetz.com

En México meXBT está impulsando soluciones como sendbitcoin. mx que permite que las remesas entre Estados Unidos y México puedan tener un costo y velocidad más conveniente para las personas que necesitan mover dólares americanos a pesos mexicanos. También está impulsando soluciones que puedan convertir los pagos entre empresas pequeñas y medianas al extranjero para que más fácilmente puedan integrarse en las cadenas productivas globales y que los pagos para la importación y exportación de productos y servicios desde México a cualquier parte del mundo sean a través de un simple clic en nuestras computadoras o teléfonos celulares.

Estas son solo algunas de las posibilidades de conectar los móviles con bitcoin y el blockchain. La verdadera movilidad en el comercio ahora es una realidad. La inversión de capital emprendedor en el primer trimestre de 2015 en este nuevo ecosistema es prácticamente igual a la que se realizó en internet en 1995. Esto es sin duda, indicativo del potencial que los inversionistas ven hoy

El futuro de los pagos y transferencias de dinero y valores mediante estas nuevas tecnologías está apenas empezando.

Joel Cano es Director de Operaciones en meXBT, empresa especializada en negocios con criptomonedas.

SG.COM.MX

023

EL BLOCKCHAIN Y SUS APLICACIONES Por Pedro Galván

Hoy en día, una conversación sobre tendencias en comercio que no hable sobre bitcoin, sin duda quedaría incompleta. Ya en este reportaje hablamos sobre bitcoins y la expectativa que hay alrededor de la criptomoneda, pero ahora quisiera platicar sobre la tecnología que sustenta al bitcoin, es decir el block chain.* Conforme escribo este artículo, Nasdaq ha anunciado que comenzará a experimentar con usar blockchain para registrar transacciones [1]. Pero las aplicaciones de éste no se reducen al ámbito financiero. Por ejemplo, la plataforma DemocracyOS está considerando aprovechar esta tecnología para registrar votación ciudadana. El artículo “Block chain 2.0: The renaissance of money” publicado por Wired en enero de este año lo plantea así [2]: “Bitcoin, altcoin, dodgecoin … ¿a quién le importan? Lo único que importa es el block chain”. Así que hay que asegurarnos de entender qué es, cómo funciona y cómo se podría aplicar en otros campos.

Fundamentos El aspecto central sobre el que se basa el diseño del sistema bitcoin es que no hay una autoridad central. Ante esto, se requiere un mecanismo para determinar quién es dueño de qué monedas. Dicho mecanismo debe ser distribuido (repartido entre una red de nodos) y resistente a ataques que quieran alterar su integridad. Este es el rol que juega blockchain. Es una bitácora donde se registran todas las transacciones de bitcoins que se comparte por todos los nodos que participan en la red bitcoin. En otras palabras, el blockchain es una bitácora transaccional distribuida, y en el caso del bitcoin viene a ser el equivalente a su libro mayor de contabilidad (ledger). Blockchain es administrado por la red de nodos del sistema bitcoin. Dichos nodos están continuamente difundiendo transacciones del tipo: el emisor X envía Y bitcoins al receptor Z. Los nodos validan las transacciones, las agregan a su copia del libro de contabilidad, y difunden estas nuevas transacciones a otros nodos. Cada nodo de red tiene su propia copia

024

SG.47

del blockchain. Aproximadamente cada 10 minutos se crea un nuevo bloque que contiene un grupo de transacciones aceptadas, se agrega el bloque a la cadena, y se envía al resto de los nodos. El proceso de calcular los bloques para irlos agregando a la cadena es lo que se conoce como hacer minería. Es un proceso diseñado para ser computacionalmente intensivo, de tal manera que el número de bloques que se encuentra cada día se mantiene constante. El algoritmo blockchain fue inventado específicamente para el sistema Bitcoin, pero se puede aplicar en cualquier otro caso donde se requiera establecer un consenso distribuido en presencia de actores maliciosos o no confiables.

Garantizando la integridad Como su nombre lo indica, el blockchain es una cadena de bloques. La cadena va desde el bloque inicial (génesis) hasta el bloque más reciente. Es así que una copia completa del blockchain contiene todas las transacciones realizadas en un sistema a lo largo de su historia. A partir de esta información, es posible determinar el valor que corresponde a cada dirección del sistema en cualquier punto de la historia. Para implementar este encadenamiento, cada nuevo bloque contiene un hash del bloque previo. Esto garantiza un orden cronológico, ya que un bloque nuevo requiere conocer el bloque anterior para poder determinar su hash. Una vez que un bloque es parte de la cadena, todos los bloques subsecuentes tienen rastro de ese bloque, por lo que si quisiéramos alterar un bloque, cambiaría su hash y por lo tanto habría que regenerar todos los bloques subsecuentes, lo cual lo hace impráctico computacionalmente y por lo tanto es un mecanismo de protección para evitar alteración de datos. Podremos tener nuestras opiniones sobre el bitcoin y su viabilidad, pero es un hecho que la tecnología blockchain funciona y es efectiva para su propósito. Un blockchain se puede utilizar para firmar digitalmente cualquier tipo de información sensible, sin necesidad de una autoridad central. Esto por ejemplo se puede aplicar en la gestión de contratos, depósitos de garantía, autenticación, etcétera.

Monedas de colores Imaginemos que a nuestros bitcoins les agregamos notas para indicar que en realidad representan cierto activo. Esto es lo que se conoce como monedas coloreadas (colored coins), y es un mecanismo que permite utilizar el blockchain para almacenar y gestionar la propiedad de activos que no son bitcoins. Por ejemplo, podríamos manejar el capital social de una empresa en el blockchain por medio de colorear monedas que representen acciones y repartirlas entre los accionistas. Las acciones entonces se podrían negociar inmediatamente y sin costos de transacción. También podemos representar bienes inmobiliarios como monedas coloreadas. Entonces, puedes poner tu casa en un bitcoin, y transferir la propiedad de tu casa por medio de una simple transacción en la red de bitcoin. Coloredcoins.com [4] es un servicio para colorear monedas, es decir crear activos digitales sobre la red bitcoin. No me sorprendería que algún romántico(a) ya haya puesto su corazón en un bitcoin y lo haya transferido a su amado(a).

Contratos inteligentes y dinero programable Uno de los campos de aplicación para el blockchain es el de contratos inteligentes. Esto consiste en crear programas que pueden manejar dinero automáticamente. Al crear un contrato se definen ciertas condiciones o criterios que se deben cumplir, y las acciones (transacciones) que se

EN PORTADA

para gestionar los derechos de otras obras artísticas, como la música o las películas, permitiendo rastrear su uso y por lo tanto compensar adecuadamente a los dueños de los derechos. Por ejemplo, si eres un artista puedes asignarle los derechos a tu obra a una disquera y monitorear por medio del blockchain las formas en las que la disquera explota tus obras (ventas, licencias, streaming, etcétera). Esto minimizaría la controversia y costos de transacción sobre el pago de regalías. Pero más allá de eso, facilitaría que los artistas pudieran compartir, gestionar y monitorear directamente el uso de sus obras.

Conclusión Nos dirijimos a un mundo de aprendizaje automatizado (machine learning), en el que las computadoras pueden actuar sin necesidad de ser programadas explícitamente. Dicho mundo requiere de la capacidad de asignar recursos de forma rápida y eficiente, sistemas capaces de auto-organizarse y realizar las transacciones. El blockchain parece ser la clave para lograrlo. Si te interesa ir a mayor profundidad técnica sobre cómo crear una cadena alternativa del blockchain, la wiki de Bitcoin [8] tiene buena información al respecto.

disparan cuando se cumplen los criterios. Cuando se realiza una transacción entre dos partes, el programa verifica que el producto/servicio se haya satisfecho, y solamente si el criterio se cumple entonces la cantidad de dinero se transmite a la cuenta del proveedor. De esta forma, se obtiene un servicio de depósito de garantía en tiempo real con un costo de operación cercano a cero. Si te interesan los contratos inteligentes, te recomiendo que eches un vistazo al proyecto Codius [4]. Es una plataforma open source para hospedar programas inteligentes que administren contratos, criptomonedas u otros activos. Otro proyecto que busca establecer una plataforma para aplicaciones descentralizadas es Ethereum [5], el cual involucra una nueva criptomoneda, un lenguaje de programación y un nuevo navegador diseñado para este protocolo.

Gestión de propiedad intelectual Otra aplicación interesante del blockchain es para compartir y gestionar el uso de propiedad intelectual.

Nota sobre nomenclatura. La documentación original del bitcoin utiliza el término “block chain” (dos palabras) para referirse a este mecanismo, ya que a fin de cuentas es eso, una cadena de bloques. Sin embargo, conforme su popularidad y aplicaciones han aumentado, es común referirse a éste como un sustantivo y unir las dos palabras para crear un anglicismo (“el blockchain”). Es por ello que en la mayoría de este artículo he utilizado esta forma, una sola palabra integrada como anglicismo.

— Por ejemplo, Ascribe [6] es un servicio que utiliza el blockchain de bitcoin para permitir a artistas, galerías y coleccionistas registrar, transferir y archivar arte digital. Los artistas registran sus obras en un sistema de registro de propiedad intelectual distribuido que es públicamente accesible. Las obras son almacenadas en la nube y acreditadas al artista. Cada versión de la obra recibe un identificador criptográfico único que es inseparable de la versión original.

Referencias [1] “Nasdaq bets on bitcoin’s Blockchain as the future of finance”. The Guardian. http://swgu.ru/p[2] “Block chain 2.0: The renaissance of money”. Wired. http://swgu.ru/p[3] Colored coins. http://coloredcoins.org [4] Codius. https://codius.org [5] Ethereum. http://ethereum.org [6] ascribe. https://www.ascribe.io [7] “The Bitcoin Blockchain Just Might Save The Music Industry...If Only We Could Understand It”. Forbes.

El fundador de ascribe comentó recientemente en un artículo publicado en Forbes [7] que un acercamiento similar también sería muy útil

[8] http://swgu.ru/pz [9] Alternative chain. https://en.bitcoin.it/wiiki/Alternative_chain

SG.COM.MX

025

5 FORMAS DE PREPARARSE PARA EL COMERCIO MÓVIL Por Jennifer Polk

Este artículo es una versión traducida y editada por Software Guru del original “5 Ways to Prepare for Mobile Commerce” publicado en el blog de Gartner for Marketing Leaders y disponible en http:// blogs.gartner.com/jennifer-polk/5-ways-preparegrowth-mobile-commerce

Gartner estima que para el año 2017, más de la mitad del comercio digital en Estados Unidos se realizará por medio de dispositivos móviles. Sin duda, cada país tiene su propio ritmo, pero es un hecho que el mobile commerce está cobrando relevancia, y las empresas que lo ignoren perderán una gran oportunidad de negocio. Aquellas empresas que quieran aprovechar esta oportunidad, deben hacerse las siguientes preguntas: • ¿Qué rol juega la interacción en dispositivos móviles en la decisión de compra de nuestros clientes? • ¿Qué cambios requiere nuestra estrategia de comercio digital para no sólo soportar mobile commerce sino aprovecharlo al máximo? • ¿Qué inversiones requerimos hacer en personas, procesos y tecnología para mobile commerce? Responder estas preguntas no es trivial. Las áreas de marketing y TI no podrán contestarlas por sí solas tampoco. Los líderes de TI, marketing y comercio digital requieren colaborar para construir una estrategia, establecer objetivos, elegir y habilitar tecnología (tanto en front-end como back-end) y preparar a la organización para ejecutar una estrategia de comercio digital que considere un amplio crecimiento en el comercio móvil. A continuación comparto con usted cinco recomendaciones para empresas que buscan prepararse para el crecimiento del mobile commerce:

1. Analice el comportamiento móvil de sus clientes. ¿Cómo utilizan sus dispositivos móviles? ¿Cómo varía el uso dependiendo de si usa un smartphone o una tablet? ¿Qué rol tienen las aplicaciones móviles y sitios web optimizados para móvil en la interacción que tienen con tu empresa o marca? 2. Manténgase al pendiente de factores que puedan disparar cambios de comportamiento. Por ejemplo, ¿cómo se podría afectar el comportamiento de tus clientes móviles con la llegada de servicios como Apple Pay? 3. Adapte sus procesos de comercio móvil de acuerdo al comportamiento del cliente. No intentar obligar al cliente a cambiar sus hábitos y forma de usar su dispositivo móvil para poder interactuar con su marca o comprar sus productos. El cliente preferirá comprarle a alguien más, que cambiar sus hábitos. 4. Busque oportunidades para agregar valor a sus clientes móviles por medio de características y ofertas que les ahorren tiempo y dinero. Por ejemplo, si su empresa tiene una app para

Jennifer Polk es Directora de Investigación en Gartner, especializada en comercio digital.

026

SG.47

compras online donde el cliente tiene la opción de pasar a una tienda a recoger su pedido, entonces aproveche la app para facilitar y agilizar el proceso de recolección. Otro ejemplo es que si va a estar publicando ofertas, permita que el consumidor pueda guardarlas en su cartera digital para que le sea más fácil recordarlas y aplicarlas. 5. Innove por medio de la creatividad y la utilidad. La innovación en el comercio móvil tiende a venir de aplicaciones con características creativas y visualmente atractivas, como por ejemplo poder compartir fotos de productos. Sin embargo, las tácticas que generan mayor uso son aquellas que también proveen información o acciones útiles para los usuarios, como por ejemplo poder conocer la disponibilidad de cierto producto en una tienda cercana. El comercio móvil impactará la forma en que interactuamos con nuestros clientes y representa una gran oportunidad para crecer nuestro negocio. ¿Cómo se está preparando su organización para el crecimiento en el comercio móvil?

EN PORTADA

M-COMMERCE EN IMÁGENES Para cerrar este reportaje sobre tendencias en comercio móvil, les compartimos un par de infografías interesantes que ayudan a dimensionar la diversidad y complejidad de este todavía naciente ecosistema. La primer figura, creada por Trinity Ventures, es un mapa de los principales jugadores en el ecosistema de mCommerce, agrupados por categoría.

La segunda figura, creada por Pymnts.com es un mapa del metro que representa los distintos conceptos que sustentan la cartera digital, agrupados como rutas. Este mapa fue hecho en 2013 y le hace falta una actualización (por ejemplo, no hace mención de las criptomonedas), pero sin duda ayuda a visualizar los distintos conceptos, servicios y tecnologías que se conjuntan para soportar la visión de la cartera digital.

Figura 1. m-Commerce market map. Trinity Ventures.

Figura 2. Digital wallet subway map. Pymnts.com

SG.COM.MX

027

ESTRATEGIA DE TI

El Presupuesto de TICs INDICIOS, ARGUMENTOS Y EXPECTATIVAS — Por Héctor Santillán

El presupuesto destinado a las tecnologías de la información y comunicaciones (TICs), es principalmente el resultado del esfuerzo personal del CIO. Me explico: La problemática básica radica en que típicamente las TICs son un medio, no una finalidad. Así que la trazabilidad y cuantificación de cómo las TIC contribuyen a obtener resultados y generar valor, ya sea público o económico, no es evidente en la mayoría de los casos. Por otro lado, las áreas financieras y presupuestales, no están familiarizadas con la complejidad real de utilizar la tecnología. Así que usualmente califican más como un costo o gasto, que como un activo en el que conviene invertir en su creación y sobre todo en su mantenimiento. Uno de los principios básicos de cualquier área financiera es mantener los costos bajos, pero la pregunta clave es: ¿cómo sabemos que un monto cualquiera, es un costo bajo?; La respuesta la da la racionalidad y justificación de la inversión. Solo que la racionalidad y la justificación pueden ser muy subjetivas, por eso es bueno justificar con números, pues son objetivos. ¿Qué ocurre con las tecnologías de la información y comunicaciones?, pues que es muy fácil cuantificar cuánto se gasta en ellas, pero es difícil cuantificar la contribución desde un punto de vista financiero. A continuación ahondo en los principales factores que inciden en esta situación:

Baja madurez de procesos

Complejidad de integración

Sólo es factible recopilar métricas en procesos definidos, a los que la organización se apega, y que están instrumentados con indicadores operativos y financieros.

Las soluciones tecnológicas empresariales típicamente involucran integrar una gran variedad de plataformas, herramientas y servicios de distintos proveedores, lo cual acarrea riesgos. Por más que dichas plataforma y herramientas pregonen ser abiertas y basadas en estándares, la realidad es que siempre ocurrirán problemas de integración, lo que generará costos imposibles de prever.

Se diluye el beneficio Se deja de cuantificar como un beneficio el impacto de una solución tecnológica a partir del segundo año, a veces antes. Por ejemplo, si una nueva solución ahorra X cantidad de dinero durante su primer año, en los años subsecuentes se deja de cuantificar este beneficio, así que se diluye. Entonces, unos años más tarde cuando se solicita presupuesto para actualizarla o realizar un mantenimiento mayor, es más difícil de obtener el apoyo de la alta dirección.

Costos de operación La dificultad para comprender el costo total de propiedad, en particular los relacionados con la provisión de servicios y activos tecnológicos que habilitan o soportan funciones de negocio. Se invirtieron 10 millones para desarrollar un nuevo sistema. Pero, luego entra a la etapa de mantenimiento, en donde se debe de contemplar no sólo las adecuaciones que solicite el área de negocio, sino las que se requieran por la obsolescencia de la plataforma tecnológica. Se acostumbra decir que el costo de realizar un cambio, es del doble en comparación de haberlo desarrollado por primera vez. Así que hay que estimar no sólo la cantidad de mantenimiento esperado, sino que además, es posible que el sistema deba de sobrevivir a la obsolescencia del hardware y software de plataforma.

Los costos ocultos Usualmente se privilegia el resultado inmediato o en el corto plazo, sacrificando o aplazando los costos y esfuerzo que implica el integrarlo al núcleo de la solución, y no como un agregado externo. Debido a que el mantenimiento típicamente es urgente, circunscrito a requisitos específicos, muchas veces etiquetados como “temporales”, no se acostumbra considerar que muchas veces conviene hacer un rediseño de la aplicación, con todo el esfuerzo que ello implica. Conforme se evade el trabajo de rediseño, los ajustes o parches que se realizan hacen que el mantenimiento posterior sea cada vez más complicado.

La obsolescencia tecnológica Desgraciadamente las áreas financieras acostumbran no entender este tema en su amplitud. El problema no es que acabe la vida útil de un producto y se compre algo más actual. Ocurre que se reinventa, se replantea todo y se vuelve casi imposible tratar de prolongar la vida a tecnologías que están casi extintas.

Héctor Santillán (@hectorsantillan) se desempeña como consultor en gobernabilidad de TICs, formulación de soluciones de negocio y marketing digital.

028

SG.47

ESTRATEGIA DE TI

Justificar el presupuesto de tecnología Aunque al justificar el gasto en tecnología debemos considerar los ahorros que vamos a generar, debemos estar conscientes que esto posiblemente no sea suficiente y concientizar a las áreas financieras de que así como aumenta la plantilla de una organización, su activo fijo, sus ventas, requerimos estar aumentando los sistemas y el presupuesto asignado a éstos. Hagamos un ejercicio de planeación. Imaginemos una organización donde cada año se construye una solución tecnológica nueva para resolver una necesidad de negocio distinta. Conforme se desarrollan las nuevas soluciones, hay que dar mantenimiento a los sistemas en producción que implementamos anteriormente. Para efectos ilustrativos, establezcamos los siguientes supuestos. 1. El desarrollo de cada nuevo sistema implica 6 mil horas hombre al año, o sea 3 personas de tiempo completo aproximadamente. 2. Se estima que el mantenimiento a un sistema en producción, es alrededor del 10% del tamaño del sistema, así que el esfuerzo de mantenimiento es de 1,200 horas al año, aplicando la regla de 2 horas de mantenimiento por 1 de desarrollo. 3. El sistema tiene una vida útil de 6 años, por la razón que quieran. Es así que al término de este periodo, habrá que realizar un esfuerzo específico para reemplazar o modernizar dicho sistema. Asumamos que esto requiere invertir las mismas 6 mil horas hombre que se utilizaron para implementar el sistema original. La tabla 1 refleja el ejercicio de planeación a 8 años con los supuestos anteriores.

Tabla 1. Planeación de presupuesto.

Si -> 5 puntos No -> 0 puntos. 2. ¿Tienen cuantificados los beneficios que año tras año aportan las TICs? Si -> 5 puntos No -> 0 puntos. 3. ¿Cómo se determina el presupuesto de TI respecto al año anterior? a) Similar al año pasado más la inflación -> 2 puntos. b) Se incrementó por nuevos proyectos -> 3 puntos. c) Se evalúa y considera cada renglón del presupuesto (zero-based) -> 5 puntos. 4. ¿Hay una trazabilidad entre los servicios y activos digitales versus las funciones y áreas de negocio? Totalmente -> 5 puntos. Parcialmente -> 3 puntos. No -> 0 puntos. 5. ¿Con que herramienta se elabora el presupuesto? a) Sistema para Gobierno de TIC -> 5 puntos b) Hoja de cálculo -> 2 puntos

Este tipo de ejercicios pueden ayudarnos a justificar el presupuesto requerido para poder satisfacer las metas de negocio desde el ámbito tecnológico. Necesitamos suficientes datos duros para que todas las partes interesadas: CEO, COO, CFO, CIO y demás, puedan tener una visión compartida.

Resultados: • 20 puntos o más: Una organización ejemplar, queremos aprender de ti. • 9 a 18 puntos. El presupuesto es subjetivo, y seguramente resultado de la argumentación y negociación. • 8 puntos o menos: Prácticamente no hay planeación de TI, se trabaja de forma reactiva.

Autoevaluación

Conclusiones

Hagamos ahora un ejercicio de autoevaluación contestando el siguiente cuestionario y sumando los puntos que obtenemos en cada respuesta. 1. ¿En su organización se planea el presupuesto de TICs?

• Entre mayor es el aprovechamiento de las TICs, mayor es el gasto que se deberá destinar a ellas. • Es útil compartir el costo total de propiedad previsto, para tener bases útiles para entenderse con

las demás partes interesadas en el aspecto financiero, sobre todo, en años subsecuentes. • La trazabilidad de los activos y servicios TICs, versus las funciones, soporte y habilitación de los procesos de la organización, es fundamental para tener indicios o datos para lograr una estimación de la contribución de las TICs a la generación de valor. • Es necesario evangelizar a las demás áreas involucradas, respecto a cómo y por qué se requiere hacer X desembolsos. Pero más importante, es necesario crear una cultura relativa a buenas prácticas de inversión en TICs, con una visión a largo plazo. • Para comenzar a obtener resultados, se requiere de una inversión significativa. Si solamente justificamos decisiones de TI en base a ahorros, nuestra organización perderá oportunidades importantes de innovación por medio de TI. Con el advenimiento del cómputo basado en la nube, el acceso a internet desde móviles y en el camino, las ventajas y beneficios potenciales, la nueva lógica financiera que esto implica, hace que el tema de la planeación presupuestal sea un elemento clave que permitirá a las organizaciones obtener grandes beneficios. El verdadero reto para el CEO, es contar con un CIO, que tenga la visión de cómo aprovechar la tecnología, con la capacidad de compartirla y convencer al resto de la organización, cuando en la práctica, tiene pocos datos duros, y más indicios y percepciones. La creación del presupuesto no es únicamente un ejercicio de planeación estratégica o financiera, sino de liderazgo, cabildeo, visión de negocio, con futurología y por supuesto, ¡trabajo en equipo!

SG.COM.MX

029

ESTRATEGIA DE TI

Planeación Estratégica de TIC ¿REALIDAD O FICCIÓN? — Por Arturo Téllez

Ahora que estamos en el segundo trimestre del año, probablemente tengamos una buena cantidad de iniciativas y proyectos de TI en curso, todos ellos obviamente apegados al presupuesto y al plan estratégico de TI, que a su vez está alineado a los planes de negocio pues fueron conjuntamente elaborados entre octubre y noviembre del año pasado. Nada más lejos de la realidad… Para este momento del año, algunas iniciativas de TI seguramente surgieron como resultado de atender un tema regulatorio, alguna petición urgente del negocio o apagar un fuego. Pocas veces se observa un proceso formal de planeación. Mucho menos con un sentido estratégico ya sea de TI o de negocio. Para comprender por qué sucede así, debemos estar conscientes que dentro de las organizaciones tenemos un entendimiento distorsionado tanto de lo que es planeación como de lo que es estratégico, y en algunas ocasiones sorprendentemente hasta de lo que son las TIC.

¿Realmente hacemos planeación tecnológica? Como mexicanos tenemos un reto culturalmente hablando, pues no somos precisamente proclives a planear, justificando en muchas ocasiones que el área de TI es un área de servicio — lo cual es cada vez menos cierto— y debemos sólo responder a lo que el negocio requiera en el momento que lo requiera. Luego entonces, nos encontramos con listas de buenos deseos elaboradas con solicitudes de pasillo por parte de las gerencias o de la dirección general. La planeación de TI implica llevar a cabo un proceso formal de levantamiento de requerimientos que estén debidamente justificados en cuanto a

beneficios cualitativos y cuantitativos en términos de negocio. Incluso tratándose de proyectos regulatorios, tendríamos que ser capaces de justificarlos en función de evitar las multas o sanciones económicas o evitar daño reputacional a la compañía. Planear también implica ser capaces de tener identificados los recursos requeridos en aspectos de infraestructura, licenciamiento, software, habilidades e información, los tiempos en que tendría que llevarse a cabo y lo más importante, quiénes serán los responsables de ejecutar dichos proyectos, así como el patrocinador no solamente financiero.

¿Es válido hablar de estrategia tecnológica? Por otro lado, es una tentación cotidiana en las empresas, darle la connotación de estratégico a todo lo que consideramos importante a discreción del solicitante, máxime cuando el solicitante está del lado del negocio. Estratégico no sólo es aquello que requiere grandes cantidades de recursos o que provenga de la alta dirección. Estratégico debe ser aquello de alto impacto —en función del negocio— y consecuentemente de largo plazo. Si estos dos componentes no están presentes a la par, no podemos decir que es estratégico. Algo indispensable es que el ejercicio de planeación estratégica no debe realizarse en aislamiento. Muchas empresas aíslan —con el afán de crear un clima favorable de “análisis y reflexión”— a su cuadro directivo para elaborar el plan estratégico de negocios y a su regreso (generalmente de lugares paradisiácos) le comunican dicho plan al responsable de TI para que con base en él, elabore el plan estratégico de tecnología. En el lado contrario de la moneda, algunos CIOs elaboran a ciegas su propio

“plan estratégico” de TI, adivinando qué puede ser relevante para el negocio. El inconveniente que esto acarrea es que estamos colocando una restricción importante al negocio, definiendo nosotros solos la arquitectura e infraestructura, sin fundamento alguno de negocio.

¿Por dónde empezar? De esta forma, la planeación estratégica de TI consiste en construir la visión del futuro de la organización, con base en las iniciativas y proyectos tecnológicos de alto impacto y largo plazo que hagan correspondencia con las respectivas iniciativas estratégicas de negocio. Llevar a cabo un ejercicio de planeación estratégica de tecnología en conjunto con las áreas de negocio, ofrece consistencia, minimiza el fracaso de los proyectos y asegura la entrega de valor al negocio. Es decir, alinea la visión tecnológica con la visión que tiene y persigue el negocio, y garantiza que todas las iniciativas y proyectos por realizar tienen un sustento razonable y no son capricho de uno o algunos, sin poner en riesgo la consecución de las metas organizacionales. Una vez estructurado el plan, deberá ser presentado, revisado, aprobado y priorizado por la dirección general o comité si fuese el caso, y finalmente comunicado para que se tenga certeza de la utilización de los recursos, en los tiempos programados y saber en qué momento tendrá lugar cada proyecto. Tomando esto en consideración cualquier organización, ya sea pública o privada, pequeña o grande, familiar o con gobierno corporativo, puede hacer realidad un Plan Estratégico de TI que soporte lo que el negocio requiere.

Arturo Téllez Mejía actualmente funge como Gerente de Seguridad y Redes para Quálitas Compañía de Seguros. Es egresado de la Licenciatura en Informática de la UPICCSA-IPN y maestro en Tecnologías de Información y Administración por el Instituto Tecnológico Autónomo de México (ITAM). Es catedrático a nivel posgrado en el ITAM y la UVM. www.arturotellezmejia.com

030

SG.47

CÓDIGO INNOVARE

Alineando la Estrategia de Marketing a Redes Sociales OPTIMIZACIÓN Y DEFINICIÓN DE OBJETIVOS SON PIEZAS FUNDAMENTALES — Por Gabriela Campos

Para los responsables del departamento de marketing, la optimización del retorno de inversión en comunicación digital y medios sociales es crítica. Hoy en día, el mercado es dinámico y todo cambia en un minuto.

Cambios en los medios sociales Los medios sociales han pasado de ser un elemento estratégico para cualquier empresa y por lo tanto deben ser planeados de la misma forma. En toda organización debe existir una estrategia de redes sociales y un plan general para poder cumplir con los objetivos. Medir el impacto ayuda a clarificar en qué porcentaje se ha incrementado el valor de la marca gracias a la actividad social. Por tanto cuando se plantea una estrategia de marketing que incluye redes sociales, se dará un paso hacia la planificación promocional multicanal, que además permitirá realizar una segmentación mucho más delimitada por intereses, edades, estudios, etcétera. La aspiración principal de las empresas es asegurarse de que sus redes sociales no sólo funcionen a nivel local, sino en todos los mercados en los que tienen presencia. El objetivo es usar los medios sociales para mejorar la percepción de la marca.

Errores en la estrategia de redes sociales Lo importante no es estar, sino saber estar. Aquí algunos errores comunes que debemos evitar: • Carecer de una estrategia. • No alinear la estrategia de redes sociales con la estrategia y la visión de la empresa. • No integrar marketing online y offline, que constituyen las dos caras de una misma moneda. • No ofrecer una experiencia de marca. Olvidar la identidad, la filosofía y la razón de ser de la empresa. • No involucrar a todos los departamentos en la definición de la estrategia de redes sociales. • No informar a todos los empleados de la estrategia de redes sociales. • No tener una presencia activa en las redes sociales en las que la empresa está presente. • No invertir lo suficiente para tener personal con el perfil apropiado para encargarse de la gestión de redes sociales. • Creer que todas las redes sociales son iguales, sin considerar las particularidades y usos de cada una de ellas, así como el potencial diferente que ofrecen.

• Usar las redes sociales como un mero canal publicitario, que se acaba convirtiendo en basura para los usuarios. • Falta de escucha y de personalización, sin proporcionar a los clientes potenciales la información que quieren y buscan. • No fomentar las relaciones con la comunidad, sin mantener ningún tipo de conversación con ellos, sin responder a sus comentarios o sin darles las gracias por sus aportaciones. • No desarrollar un plan de crisis, alineado con el plan general de crisis de la empresa. • No analizar qué están haciendo las empresas de la competencia en redes sociales. • No monitorear y escuchar lo que se dice de la marca y del sector al que pertenece. • No actualizar la estrategia de redes sociales, de acuerdo a las necesidades existentes.

Gabriela Campos Torres es Community Manager de SemanticWebBuilder en

Gerencia

Desarrollo de Nuevos Productos y Servicios de INFOTEC. Es Licenciada en

Ciencias

Comunicación por el Tec de Monterrey. Cuenta con amplia experiencia en la ejecución de proyectos relacionados con la adopción de implantaciones tecnológicas y cambios culturales.

Conclusión En definitiva, las redes sociales se han convertido en un medio muy útil para la redefinición y crecimiento de negocios siempre y cuando se tome en cuenta la inversión y los resultados que se obtendrán. Y en este sentido los dispositivos móviles son cada vez más importantes entre los consumidores, pues se han convertido en una parte fundamental del día a día de los usuarios y por tanto las organizaciones están invirtiendo cada vez más en su estrategia móvil. INFOTEC desarrolló una herramienta en esquema de Open Source que tiene como propósito principal obtener elementos de análisis que proporcionen datos de utilidad para la toma estratégica de decisiones en cuestión del social media. De esta manera, INFOTEC incursiona en la investigación y desarrollo tecnológico de herramientas de software en el mercado internacional. La investigación y los prototipos realizados para el desarrollo del SWB Social pueden ser retomados y extendidos para aplicarse en diversos ámbitos a nivel nacional, como puede ser la obtención de información estadística subjetiva para la generación de métricas e indicadores especializados de cualquier industria. Este conjunto de atribuciones se realiza bajo el esquema de código libre y ya se está trabajando en la versión para dispositivos móviles con la intención de seguir aportando al crecimiento de la industria TIC en México.

SG.COM.MX

031

SOURCING

Contratación

de Software Basada en

Resultados —

Por Guilherme Siqueira Simões

El sector de Tecnologías de la Información se ha visto muy afectado por el movimiento de externalización de las empresas. Gran parte del desarrollo y mantenimiento de los sistemas ya no se hace más internamente. Sin embargo, esta medida trajo efectos secundarios inesperados (y no deseados) para muchas organizaciones que han adoptado esta iniciativa. Uno de los problemas se refiere a las prácticas de contratación de estos servicios de terceros. En las secciones siguientes se comentan las formas más comunes de la contratación de servicios de desarrollo de software.

La contratación por hora-hombre En esta forma de contratación, también conocida como body shopping, el cliente contrata a profesionales para la asignación en el desarrollo de software, generalmente en conjunto con su propio equipo, algunas veces con varios proveedores de mano de obra, y utiliza su infraestructura logística interna. La remuneración del proveedor se calcula basándose en el nivel de cualificación y experiencia de los profesionales en las horas trabajadas y otros gastos posibles. En este tipo de contrato, la remuneración del proveedor está orientada a los procesos “internos” de la producción de software. El precio final de un proyecto se determina a partir de consideraciones tales como: la cantidad de trabajo que requiere, el perfil y la cantidad de profesionales movilizados para su aplicación, y la complejidad de la gestión. El control de precios está en manos del proveedor, que en teoría, tiene más experiencia en estos aspectos técnicos del proyecto que el cliente, cuya actividad económica tiende a ser diferente al desarrollo o mantenimiento de software. Este modelo es fácil de administrar y proporciona una gran flexibilidad tanto para el cliente y como para el proveedor. Una vez que se hayan establecido las relaciones comerciales, el cliente es capaz de ser más ágil en el cumplimiento de los picos de demanda del servicio. En el caso de que exista cambio de las necesidades, no es necesario renegociar el contrato con el proveedor. Sin embargo, aumentar el alcance provoca un incremento del trabajo (horas), así como del costo del proyecto. Es justo que haya remuneración al proveedor por este esfuerzo adicional, ya que la gestión del alcance es responsabilidad directa del cliente.

032

SG.47

El aspecto más crítico de este tipo de contratación, es que el cliente es responsable por la gestión del equipo de servicio, incluyendo la productividad del proveedor. Esto requiere un nivel de competencia que puede no estar disponible internamente. Además, la remuneración del proveedor no está vinculada a los resultados producidos, sólo al número de horas realizado. No hay incentivo para que el proveedor mantenga o aumente los niveles de productividad y calidad, lo que debería ser parte de su responsabilidad. El incentivo es negativo: en cuanto más esfuerzo se demande por parte del proveedor, mayor será la remuneración. Y esta es la antítesis de la productividad. Otro obstáculo está relacionado con las garantías de servicio. Si la asignación implica más de una empresa, es muy difícil aislar las responsabilidades de cada empresa y exigir la garantía. El cliente paga por un servicio y también por cualquier mantenimiento posterior correctivo asociado a éste.

Contratar a un precio fijo Este tipo de contratación, también conocido como fixed price, favorece el enfoque de proyecto con un comienzo y un final bien definidos (y por supuesto, del alcance). Además, este modelo requiere un mayor nivel de organización del cliente y del proveedor. Si los requisitos están mejor definidos hay menos posibilidades de fricción entre las partes. Sin embargo, es probable que el proveedor no tenga mucha información, no domine el problema o no dedique tiempo para un análisis detallado de los requisitos para la preparación de su propuesta de negocio. Como resultado, habrá un subdimensionamiento o sobredimensionamiento del presupuesto presentado. Cuando la competencia es intensa, es probable que el primer caso se produzca. Ambos casos son indeseables. En el primero, el proveedor tendrá dificultades para atender al cliente. Si los requisitos no están bien definidos, es probable que se cree un callejón sin salida y una nueva negociación comercial tendrá que ser considerada. Aunque los requisitos hayan sido bien definidos, el presupuesto por el proveedor puede haber sido insuficiente y la calidad del producto se vea seriamente afectada o incluso el proyecto no se pueda completar.

SOURCING

“Un modelo de contratación óptimo sería la remuneración de acuerdo con las unidades de resultado del servicio realizado”.

En este modelo hay una transferencia del riesgo del cliente al proveedor, y surgen los cuestionamientos con respecto al riesgo del alcance (¿los cambios serán alojados sin coste adicional?) y de la productividad (¿cuál es el nivel de control sobre los vectores que afectan el trabajo?). El precio propuesto por los proveedores debe tener en cuenta estos riesgos. El uso de este enfoque se complica cuando se asume que los requisitos no cambiarán (o habrá poco cambio) después del inicio del proyecto. El entorno de una organización se es dinámico, los requisitos también lo son. En cuanto más larga sea la duración del proyecto, es más probable que hayan cambios en los requisitos. Aparte es difícil de estimar cómo estos cambios afectan el presupuesto original del proveedor. De acuerdo con C. Jones [7] más de 2% de los requisitos cambian mensualmente después de la fase de requisitos. En este caso, es probable que sea necesaria una renegociación. Si esto ocurre, el cliente no tendrá la misma condición original, ya que dependiendo en qué fased el proyecto esté, no hay competencia, ni una unidad para comparar el precio originalmente acordado con los precios cobrados de acuerdo a las nuevas características solicitadas. En este modelo de contratación, el control sobre la cantidad a pagar lo tiene el proveedor. Es muy común que la formación de precios se efectúe en términos de la estructura de descomposición del proyecto de trabajo, la cantidad de las horas y el perfil de profesionales asignados a esa actividad. Esto también ocurre con la contratación por hora-hombre, el control está bajo quienes poseen los conocimientos técnicos de ingeniería de software y la aplicación de sus disciplinas.

Un modelo alternativo de contratación Con el tiempo, algunas organizaciones comenzaron a experimentar con formas alternativas de contratación de servicios de software que promovían una mejor distribución de los riesgos y resultados. En el modelo hora-hombre, la productividad del trabajo es un problema de gestión del cliente, cuando debería ser preocupación del proveedor. La administración del alcance también es responsabilidad del cliente, ya que el proveedor no tiene control sobre los requisitos. En el modelo de precio fijo, la productividad es responsabilidad del proveedor, lo que es justo, ya que este es responsable del proceso de trabajo. Sin embargo, cualquier cambio o incertidumbre de los requisitos, que es responsabilidad del cliente, impacta este modelo de contrato.

Por lo tanto, un modelo de contratación óptimo sería la remuneración de acuerdo con las unidades de resultado del servicio realizado. Esto promueve el balance de riesgos y responsabilidades entre cliente y proveedor. En este caso, la productividad es responsabilidad del proveedor, ya que existe un riesgo de lesiones si hay retraso en las unidades de producción. Además, en el caso de que exista un aumento en el alcance, se debe construir más unidades para el servicio y el proveedor es remunerado por ello. El gran desafío de este enfoque es encontrar una unidad que sea reconocida de manera inequívoca, uniforme y consistente tanto para el cliente como para el proveedor. Ejemplos de unidades podrían ser: pantallas, informes, tablas, casos de uso, líneas de código, stored procedures, webservices, puntos de función, entre otros. Pero no todas estas unidades cumplen con los criterios para ser reconocidos por el cliente y el proveedor de forma consistente. Al analizar las unidades de carácter más técnico, no se tiene en cuenta la visibilidad de estas por parte del cliente. La relación (si existe) entre las líneas de código, por ejemplo, y algo de valor tangible al cliente es muy débil. El cliente no siempre tiene toda la experiencia para atribuir valor a un servicio que involucró a escribir un cierto número de líneas de código. A menudo, una de las razones para la externalización es precisamente la búsqueda de un proveedor con más conocimientos especializados en un tema, que no es de interés para el cliente y no le generará interés de tener dominio. Por otra parte, al analizar algunas unidades menos técnicas, tales como pantallas, tablas, informes, casos de uso o los puntos de función, estos tienen unidades que son fácilmente reconocidas y comprendidas por ambas partes. La cuestión ahora es encontrar una definición consistente para esta unidad. En el caso de las pantallas, tablas, informes y casos de uso, no hay definición normalizada. A pesar de que hay buenas prácticas, y hacen uso del sentido común para definir lo que debería ser o no un caso de uso o una pantalla, estas unidades no son suficientes para utilizarse como una unidad de medida de contratos. En un extremo el cliente puede manejar el servicio de todo el sistema si se especializa en solo un caso de uso para minimizar el costo; en caso contrario, el proveedor puede dividir la especificación del sistema en casos de uso para aumentar su remuneración.

SG.COM.MX

033

SOURCING

El tamaño funcional puede ser considerado una unidad viable de medida en los contratos, precisamente porque son una medida de carácter no técnico, con una definición estándar, y consistente. Por otra parte, la contratación de los servicios basado en los resultados entregados, permite al cliente tener más control sobre los costos.

en costos, como en el precio unitario es definido (o debería ser definido) según la productividad esperada para el contrato. Al igual que las características de los servicios que se exigen en el contrato, el modelo puede ser refinado (y por lo general esto se hace) con el uso de diferentes indicadores de la tasa de entrega (H/PF) o el precio de la unidad ($/PF), calibrado para especificidades de cada tipo de servicio.

La medición funcional del software La medición funcional mide el software mediante la cuantificación de sus tareas y servicios, es decir, las características que el software proporciona al usuario. En resumen, mide los requisitos funcionales del software. La idea es que la medición funcional sea: • Lo suficientemente simple para reducir al mínimo el costo adicional del proceso de medición. • Una medida consistente entre los diversos proyectos y organizaciones. El resultado de la medición es llamado tamaño funcional y a menudo expresado en una unidad llamada punto de función (PF). Hay cinco métodos de medición funcional estándares: IFPUG (ISO/IEC 20926), NESMA (ISO / IEC 24570), Mark II (ISO / IEC 20968), COSMIC (ISO/IEC 19761) y FISMA (ISO/ IEC 29881).

Modelo de costos Un modelo para la prestación de servicios de software basado en el tamaño funcional puede ser representado por las fórmulas siguientes, que en la práctica son similares. Esfuerzo = Tamaño x Tasa de entrega (1) En esta primera fórmula, el esfuerzo del proyecto que se ejecutará es estimado (en horas) teniendo en cuenta el tamaño (en puntos de función) y una tasa de entrega pre-definida (horas por puntos de función). Esta tasa es definida, de acuerdo con el proveedor y un estudio de productividad del cliente basado en una muestra histórica de proyectos ya implementados. El costo del proyecto se deriva simplemente de la multiplicación del esfuerzo calculado por un valor de horas acordado entre el cliente y el proveedor. Costo = Tamaño x Precio por Unidad (2) En esta segunda fórmula el costo del proyecto se calcula directamente con el tamaño funcional multiplicado por el precio unitario de éste. Para establecer el precio que se ofrece, los proveedores deben tener en cuenta todo el proceso de trabajo definido por el cliente en el Request for Proposal. Ambas fórmulas son equivalentes, ya que el esfuerzo se puede convertir

034

SG.47

Para organizaciones grandes, los procesos de contratación son a menudo largos y costosos. Por lo tanto, el modelo descrito anteriormente se aplica generalmente no en un proyecto individual, sino a un volumen de puntos de función predefinidos para ser utilizados en varios proyectos durante un período por lo general de doce o más meses. Este volumen se determina normalmente basado en los proyectos previstos por el área de sistemas en la planificación estratégica. A medida que el tamaño funcional se realice con base a la vista externa del usuario, en contraste con una vista interna de la ingeniería de software, el cliente ejerce el control efectivo y la gestión de contratación. El perfil de los profesionales movilizados o la cantidad de horas trabajadas dejan de ser factores definitivos para el análisis. Se trata de un modelo en el que el tamaño funcional no cumple el papel de la estimación de esfuerzo o costo, sino de prescribir la cantidad que se pagará independientemente de su costo o esfuerzo real. Al igual que los contratos de precio fijo, este modelo tiene riesgos. Sin embargo, con una mejor distribución. Las consideraciones acerca de la complejidad del trabajo en sus diversas dimensiones (excepto alcance de las funciones solicitadas y entregadas al usuario), y el perfil y la cantidad de profesionales asignados serán consideradas cuando se defina el precio por unidad ($/PF) o la tasa de entrega (H/PF). El precio unitario, junto al tamaño funcional, prescribe la forma en la que el proveedor será recompensado por cada servicio prestado. En un análisis específico de cada proyecto entregado, la recompensa (o esfuerzo) aumenta o disminuye en comparación con lo realmente realizado. Este modelo utiliza como base el precio medio (o promedio de productividad) para la derivación del costo. Dado que hay una buena definición de los parámetros de precios, estas variaciones entre los proyectos tienden a anularse entre sí cuando se considera el conjunto de proyectos en un horizonte de tiempo más largo (por ejemplo, un año).

Beneficios del modelo propuesto Una de las razones para usar el modelo propuesto es que el vocabulario de la medición funcional utiliza la terminología y define elementos de análisis que son independientes de la tecnología utilizada para desarrollar el software. El proceso de medición sólo tiene en cuenta la perspectiva de

SOURCING

“Para los contratos basados en los puntos de función, el fraude es fácilmente detectado por la auditoría”.

negocio como se entiende y es válida para el cliente. La eliminación de estos tecnicismos facilita la comprensión entre las partes y es un motor importante para la comunicación entre cliente y proveedor. Otra de las ventajas de este método, especialmente para el sector público, es que contratos remunerados por el tamaño funcional permiten auditoría externa de todos los pagos hechos. Algo que no puede ser hecho en un contrato por hora-hombre. Verificar horas trabajadas después del pago es muy difícil. Para los contratos basados en los puntos de función, el fraude es fácilmente detectado por la auditoría. A medida que la medición funcional refleje funcionalidades entregadas por los proyectos, no hay manera de que sean falsificados.

Service Level Agreements (SLAs) En este modelo hay interés directo de los proveedores para maximizar el flujo de las demandas entregadas, ya que implica un aumento de los ingresos. Para el cliente esto también es beneficioso, ya que proporciona más capacidad de respuesta a las necesidades de software de la organización.

gran impacto para promover este cambio. La contratación por el tamaño funcional consiste en trabajar enfocado en proyectos, lo que implica una buena planificación y evaluación del alcance. Sin embargo, la falta de planificación, documentación y visibilidad de los resultados producidos es común en contratos por hora-hombre. Otro punto en el que se debe tener cuidado es no copiar modelos de costos de otras organizaciones, sin la calibración necesaria de sus parámetros con datos históricos propios. Cuando se utilizan parámetros de otras organizaciones (o precio unitario), los costos de la contratación pueden elevarse o los proveedores serán oprimidos hasta llegar al punto de rescindir el contrato. Una dificultad más está relacionada con las mediciones, que deben centrarse exclusivamente en las necesidades del negocio. Para aquellos que están involucrados en la implementación, es común que haya una dificultad en la abstracción de la implementación y esto se refleja en una medición a menudo incorrecta (y por lo general, más grande).

Conclusión Como también hay interés por parte del proveedor para entregar un servicio de calidad, ya que las correcciones implican repetición del trabajo, sin los ingresos asociados, el costo impacta a la rentabilidad del contrato. Pronto podremos ver una convergencia de intereses en ambos lados para una rápida entrega y una mejor calidad del servicio entregado. Sin embargo, no se puede prescindir de los Acuerdos de Nivel de Servicio (Service Level Agreements), específicamente en plazo y calidad. Cuando hay un retraso en la entrega del servicio, incluso si el cliente tiene la previsibilidad del saldo a pagar, este retraso puede resultar en pérdida de oportunidades para el negocio. Lo mismo se aplica a los defectos, aunque no hay costo adicional para las correcciones, esto puede afectar la fecha de entrega de una solución o incluso provocar un daño muy grande al negocio si la manifestación del defecto ocurre después del despliegue del software. Por lo tanto, es una buena práctica, el uso de SLA’s en los contratos basados en la medición funcional.

El modelo de contratación de servicio de software por resultados ha sido madurado principalmente en Brasil y Corea del Sur durante los últimos quince años. En varios casos fueron percibidos mejora de productividad, mejora de la calidad de la documentación de requisitos y resultados entregados con nivel de satisfacción más alto.

— Referencias [1] Vazquez, C. E.; Simões, G. S; Albert, R. M., “Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software”. 13ª ed., São Paulo-Brasil: Editora Érica, 2013. [2] International Function Point User Group. http://ifpug.org [3] United Kingdom Software Metrics Association. http://uksma.co.uk [4] Common Software Measurement International Consortium (COSMIC). http://cosmicon.com

Dificultades comunes

[5] NESMA. http://nesma.org

Una dificultad para la adopción del modelo de contrato basado en el tamaño funcional es la poca madurez en proyectos en muchas organizaciones. Para aquellos que están en un modelo basado en hora-hombre, existe un

[6] Finnish Software Measurement Association (FISMA) http://fisma.fi [7] C. Jones. “Conflict and Litigation Between Software Clients and Developers”, Software Productivity Research, Versión 10 . abr. 2001

Guilherme Siquiera Simões es socio y director de FATTO Consultoría y Sistemas, donde actúa como consultor e instructor en servicios de consultoría y capacitación de medición, estimación y requisitos de proyectos de software. Es autor del libro “Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software”, el más vendido en Brasil sobre este tema.

SG.COM.MX

035

ARQUITECTURA

Seguridad y uso de

Frameworks —

Por Humberto Cervantes, Rick Kazman y Jungwoo Ryoo

En esta ocasión resumiré un trabajo que presenté en la conferencia SATURN 2014 de arquitectura de software junto con mis colegas Rick Kazman y Jungwoo Ryoo. Rick Kazman es investigador del Software Engineering Institute y académico en la Universidad de Hawaii. Jungwoo Ryoo es investigador de la Universidad del estado de Pensilvania y experto en temas de seguridad. Cabe señalar que la conferencia SATURN, organizada por el SEI, está enfocada a los practicantes y que este trabajo fue muy bien recibido por dicha comunidad, por lo que considero que puede ser de interés para los lectores de esta sección.

Enfoque arquitectónico hacia la seguridad La seguridad del software es una preocupación cada vez más importante para las organizaciones. Sin embargo, pocos arquitectos abordan este atributo de calidad de manera estratégica. Los arquitectos y desarrolladores frecuentemente ponen un énfasis mayor en satisfacer los requerimientos funcionales, y la seguridad usualmente es aplicada como un “parche” durante o después de que la aplicación ha sido desarrollada. Desarrollar código enfocado a la seguridad es una tarea compleja y, por ello, frecuentemente se recurre a la adopción y uso de frameworks que se enfocan en atender distintas áreas de la seguridad como pueden ser el control de acceso, el cifrado y la validación de entradas entre otras. Podemos identificar tres enfoques relativos a la adopción de frameworks como parte del diseño de la arquitectura para resolver la seguridad: • No adopción: La seguridad no es considerada dentro del diseño de la arquitectura y solamente se codifican soluciones ad-hoc para tratar aspectos de seguridad. • Adopción parcial: Se introducen frameworks de seguridad después del diseño inicial de la arquitectura. • Adopción completa: La seguridad es considerada dentro del diseño inicial de la arquitectura y parte de las decisiones del diseño incluyen el uso de frameworks enfocados a la seguridad.

Caso de estudio Con el fin de comprender las consecuencias de los tres enfoques descritos anteriormente, realizamos un estudio sobre tres distintos sistemas empresariales accesibles vía web: • Sistema 1. Un sistema de administración de registros médicos de fuente abierta llamado OpenEMR [1]. Desarrollado en PHP y representa el enfoque de no adopción. • Sistema 2. Un portal web desarrollado usando HTML y JSP. En un principio utilizaba un enfoque de no adopción y posteriormente se decidió agregar una solución comercial para mitigar riesgos de seguridad en el código, aplicando así un enfoque de adopción parcial. Nos referiremos a éste como “Sistema 2 Antes” y “Sistema 2 después”.

036

SG.47

Figura 1. Categorización de tácticas de seguridad.

• Sistema 3. Una aplicación interna programada en Java por una empresa mexicana. Este sistema representa el enfoque de adopción completa. Utiliza Spring security [2] como framework primario de seguridad pero también utiliza el framework ZK [3] en la capa de presentación, que también brinda protección de ataques comunes en esta capa. Estos sistemas fueron analizados utilizando la herramienta IBM AppScan que analiza alrededor de 33 tipos distintos de vulnerabilidades tales como inyección de SQL, negación de servicio o indexado de directorios. La herramienta genera un reporte de resultados indicando la cantidad de vulnerabilidades identificadas, agrupadas por severidad. El análisis se enfocó únicamente en los aspectos de software, por lo que se deshabilitó hardware de seguridad tal como firewalls. Adicionalmente se realizó una entrevista a los arquitectos de los distintos sistemas para entender los enfoques de seguridad que siguieron. Estas entrevistas se basaron en la lista de 17 tácticas de seguridad que se muestra en la figura 1. Para cada una de las tácticas se le preguntó al arquitecto si la había considerado y, en caso afirmativo, qué medidas había tomado al respecto.

Resultados La tabla 1 presenta un resumen del resultado del análisis sobre los distintos sistemas. Como se puede observar de la tabla, los enfoques de adopción parcial y completa tienen los mejores resultados ya que ninguno de estos sistemas exhibió vulnerabilidades de severidad alta. En el caso del sistema 2, llama la atención que al introducir un framework de seguridad se eliminaron por completo las vulnerabilidades de severidad alta, y las medianas se recortaron a la mitad.

ARQUITECTURA

“La seguridad es un aspecto de gran importancia en la mayoría de las aplicaciones. Se le debe dar una consideración primordial como parte del diseño de la arquitectura”.

Tabla 1. Resultado del análisis de seguridad.

Por otro lado podemos apreciar que, a excepción del sistema 3, en los demás casos una parte de las tácticas fueron implementadas mediante programación ad-hoc, y no usando frameworks u otros mecanismos externos. Podemos observar una relación entre el esfuerzo que estimaron los arquitectos para satisfacer aspectos de seguridad y el número de tácticas implementadas de manera ad-hoc. Como era de esperarse, el enfoque de adopción completa resultó ser el mejor ya que el sistema en que se usó, es decir el sistema 3, no tuvo vulnerabilidades de severidad alta, y el esfuerzo que el arquitecto estimó haber dedicado a atender aspectos de seguridad fue bajo en comparación con los demás sistemas, además de que este fue el sistema en el cual se implementó la mayor cantidad de tácticas.

Es conveniente, además, atender la seguridad usando una combinación de software y hardware como, por ejemplo, cortafuegos. Una recomendación adicional es que al diseñar la arquitectura de un sistema, conviene tomar el catálogo de tácticas mostrado en la figura 1 a manera de checklist para asegurarnos que estamos cubriendo las distintas tácticas de seguridad.

Conclusión La seguridad es un aspecto de gran importancia en la mayoría de las aplicaciones y es por ello que se le debe dar una consideración primordial como parte del diseño de la arquitectura. El considerar la seguridad desde el principio y usar frameworks para soportarla puede dar excelentes resultados.

Consideraciones La muestra de sistemas que se usó para este estudio es muy pequeña y esto impide llegar a conclusiones definitivas. Sin embargo, y a pesar del tamaño de la muestra, los resultados obtenidos permiten emitir la recomendación siguiente: la seguridad es un atributo de calidad que no se debe dejar “para después” y es conveniente elegir frameworks como parte de las decisiones de diseño de la arquitectura. El uso de frameworks tiene sentido pues quien desarrolla una aplicación para un dominio particular generalmente no es un especialista en temas de seguridad. Por otro lado, intentar desarrollar código ad-hoc para satisfacer aspectos de seguridad consume recursos valiosos del proyecto que podrían más bien estar enfocados en resolver la problemática de negocio. Las únicas dificultades asociadas con el uso de frameworks para manejar la seguridad son las posibles curvas de aprendizaje asociada con los frameworks, y la necesidad de mantener actualizados los frameworks para estar al día respecto a las nuevas amenazas que aparecen con el tiempo.

Aprovecho este espacio para comentarles que estamos buscando más casos de estudio por lo cual si están interesados en que alguna de sus aplicaciones empresariales forme parte de este estudio no duden en contactarme en hcm@xanum.uam.mx. Los resultados del análisis y los datos de su organización serán confidenciales. En http://goo.gl/cZUIi5 pueden encontrar un video de la presentación de este trabajo realizada en SATURN 2014. En http://goo.gl/plbwrJ pueden encontrar una lista de frameworks de seguridad (en constante evolución).

— Referencias [1] Bass, Clements y Kazman, “Software Architecture in Practice”, 3a Edición, AddisonWesley Professional, 2012.

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa y consultor independiente especializado en arquitectura de software. Está certificado como ATAM Evaluator y Software Architecture Professional por parte del Software Engineering Institute.

SG.COM.MX

037

A La Defensa De Los Usuarios SIETE TÉCNICAS UX PARA CAMBIAR EL MUNDO — Por Misael León

Algo nos sucedió en el camino. Siempre vamos de prisa buscando resultados rápidos. La cultura moderna es aquella de la gratificación inmediata. Dedicamos poco tiempo a entender lo que necesitamos para lograr nuestros objetivos. La lógica nos dice que si actuamos rápido obtendremos resultados rápidos. Este apresurado tren de pensamiento se ha generalizado a tal grado que incluso ha contagiado hasta el proceso de desarrollar y crear productos de software. ¡Genial! Pero, los resultados casi nunca son óptimos porque son… pues, apresurados. Diseñadores y desarrolladores por igual hemos vivido las consecuencias de un proyecto no planeado adecuadamente, o aún peor, un proyecto basado en meras intuiciones sobre los que usuarios desean y necesitan. Todos los involucrados opinan sobre lo que el producto debe hacer y qué características debe contener. Nos enamoramos de la idea y comenzamos a trabajar. No tenemos tiempo de investigar. Rápido, rápido, rápido. Una verdadera receta para el desastre. Sin embargo nosotros no somos los usuarios y nuestras suposiciones como expertos son solamente eso, suposiciones educadas. Es una contradicción tan obvia que a menudo la pasamos por alto, queremos ser proveedor y cliente al mismo tiempo. Es casi como trabajar con los ojos cerrados. Factores como la falta de retención de usuarios nos abren los ojos y nos obligan a corregir, deshacer y rehacer. ¡Y vaya que el re-trabajo es costoso en nuestra industria!

Suponer vs entender Afortunadamente no todo es caos y desesperación, este tipo de re-trabajo se puede evitar si entendemos lo que los usuarios realmente necesitan, si apreciamos cómo piensan y viven. Actuando de esta manera podremos sentir verdadera empatía por ellos, y como consecuencia resolver de manera efectiva los problemas que enfrentan diariamente a través de la tecnología que desarrollemos. Destinar tiempo para realizar investigación de usuario utilizando un marco metodológico, nos provee un punto de referencia más realista. Nos permite ejecutar de una manera más certera esa idea genial que tenemos, pero esta vez, acorde al modelo mental y estilo de vida de nuestros usuarios. La investigación de usuarios es el fundamento principal del diseño de experiencia del usuario (UX Design). Como bien dice Hoa Loranger: “UX sin User Research no es UX” [1]. Sin conocer para quiénes estamos diseñando, y sus particularidades de comportamiento, no podremos llegar a una solución efectiva. La investigación disuelve la contradicción. La investigación de usuario se puede incluir en el desarrollo de productos de software en cualquier ambiente, incluyendo Agile. UX Research no es enemigo de Agile. Incluso son compatibles ya que ambos enfoques buscan prototipar, descartar y/o validar ideas. La variedad y formato de los

038

SG.47

métodos de diseño es muy flexible, haciendo la adopción de UX Research en un ambiente Agile bastante factible. Incorporar prácticas de UX no es solamente responsabilidad del UX designer, sino de todos los involucrados en el ciclo de desarrollo del producto. Todos los involucrados deben reconocer que el usuario es el centro de nuestro trabajo, es la única manera de asegurar que nuestro producto se incorporará fácilmente a la vida de las personas. No olvidemos que diseñamos para humanos, y vaya que los humanos somos seres inmensamente complejos. Suena como chiste, pero lo olvidamos muy a menudo. Suponer comportamientos es cómodo, pero es altamente riesgoso desde una perspectiva de negocios.

Comienza hoy: siete metodologías UX El objetivo del UX Design es producir una experiencia memorable y positiva en los usuarios. UX Design no es una ciencia exacta, es resultado de una serie de técnicas que ayudan a identificar e influir en la percepción que las personas tienen sobre un producto o servicio. A continuación presento siete técnicas populares de UX que permiten explorar los modelos mentales de tu audiencia, descubrir oportunidades, y generar ideas efectivas: Evaluación Heurística. Esta es una manera poco costosa de evaluar la usabilidad de una interfaz. Es realizada por un grupo de expertos en User Experience, quienes analizan la interfaz de acuerdo a una serie de principios de usabilidad, como prevención de errores, uso de lenguaje común, retroalimentación usuario-sistema, minimizar la carga de memoria, etcétera. El objetivo es limpiar la interfaz de errores obvios de usabilidad y realizar las correcciones pertinentes. Rapid Contextual Design. Con este método puedes observar usuarios en su propio ambiente. El objetivo es entender cómo las personas interactúan con tu producto en un contexto real. Haciendo las anotaciones necesarias puedes tener una idea más clara del problema a resolver. Para generar ideas de diseño las observaciones se interpretan mediante el uso de herramientas de análisis tales como diagramas de afinidad. De esta manera compruebas si tu producto está acorde al comportamiento de tus usuarios [2]. Rapid Paper Prototyping + Usability Testing. Existen requisitos mínimos que un producto de software debe contemplar para que los usuarios puedan completar la tarea que tienen en mente. Si deseas aprender sobre el desempeño real de tu producto necesitas realizar pruebas de usabilidad regularmente. Puedes probar tus ideas tan pronto como tengas el primer boceto en papel. Esta es una manera eficaz para: 1. Descubrir qué tan difícil es para tus usuarios aprender a usar tu producto. 2. Conocer qué obstáculos enfrentan al momento de completar tareas. 3. Identificar problemas de usabilidad a un bajo costo y a tiempo. 4. Evitar desperdiciar recursos de desarrollo o diseño en features que no funcionarán.

Kano Analysis. Es una metodología cuantitativa que permite descubrir cuáles características tienen el mayor grado de satisfacción entre tus usuarios. Es un tipo especial de encuesta que te ayuda a determinar dónde invertir tus recursos. Kano también permite determinar cuáles son esas features claves que lograrán diferenciar tu producto de la competencia. Al ser un método cuantitativo, brinda un sustento estadístico para apoyar la toma de decisiones. Business Origami. Si tu producto es parte de un sistema complicado, deja que los usuarios lo simplifiquen para ti. Business Origami es una herramienta de investigación muy poderosa para sintetizar y modelar complejos sistemas de interacción entre usuario-producto-ambiente. Se trata de un taller donde los usuarios hablan de su experiencia con un producto o servicio desde su perspectiva única. Si a las personas les brindas la oportunidad de contar su propia historia, ¡lo harán sin duda! Sobre todo si les provees de objetos tangibles (tokens) con los cuales puedan narrar sus experiencias. De esta manera podrás visualizar todo el viaje que realizan para lograr un objetivo y cómo tu producto entra en esa historia. Es una manera efectiva de identificar problemas y convertirlos en oportunidades. Scenario Swimlanes. Para que una experiencia resulte positiva para tus usuarios se requiere la interacción de muchas piezas. Esta técnica ilustra precisamente cómo todas las piezas de un sistema interactúan entre sí. Los diferentes roles involucrados en cada parte del flujo de la experiencia (touch points) son mostrados por niveles. Desde la reacción subjetiva del usuario, los procesos de negocio, los protocolos de atención, las herramientas, la tecnología de información, hasta los atributos del sistema. Generative Research. Bajo este enfoque “generativo” invitas a usuarios (ya sea reales o potenciales) a participar en una serie de actividades colaborativas. Este enfoque considera que las personas son los verdaderos expertos ya que poseen un conocimiento más amplio de sus propios estilos de vida. Los participantes crean algo, ya sea un collage, un prototipo o un artefacto. Al proporcionarles objetos tangibles para jugar e interactuar es más probable que expresen sus sentimientos y puntos de vista particulares. El objetivo es generar un entendimiento más amplio sobre el problema a resolver. Este tipo de talleres son una manera efectiva para entender y sentir empatía por tus usuarios. La figura 1 muestra un ejemplo de un taller de generative research.

Figura 1. Taller de generative research.

UX Research: entender para impactar Aun cuando el campo de UX Design ha ganado popularidad, las malas prácticas siguen plagando nuestros proyectos. Alguien debe romper el ciclo y tú puedes ser el inicio de este cambio de mentalidad. La investigación de usuarios te ayudará durante el confuso proceso de descubrir qué es lo que las personas quieren y necesitan. Escucha y observa a tus usuarios con verdadera empatía. Ellos tienen las respuestas que buscas. Nunca olvides que la gente utilizará el producto de software en el cual trabajas. Tu idea, tu diseño y tu código resolverán problemas de personas reales, en el mundo real. Comienza a sentir curiosidad por saber quiénes son, cómo viven y cómo tu trabajo impactará sus vidas. Te aseguro que sentirás una gratificación duradera al ver que tu esfuerzo tiene un impacto positivo en este mundo que va de prisa. En la sección de referencias he dejado enlaces a videos donde se habla con mayor detalle de cada una de las técnicas mencionadas. Estos videos forman parte de los contenidos de una iniciativa en la cual colaboro: The UX Clinic, ahí mostramos los resultados de casos de estudio sobre UX Design. Te invito a que nos visites en http://theuxclinic.com

— Referencias [1] H. Loranger. “UX Without Research Is Not UX”. Nielsen Norman Group.

Cambiando el mundo desde el escritorio

http://www.nngroup.com/articles/ux-without-user-research

Los UX Designers y la industria de desarrollo de software en general tienen la oportunidad de crear productos que impacten de manera positiva la vida de las personas. En nuestras manos está la posibilidad de mejorar la condición humana a través de la empatía y la creación de herramientas para resolver problemas.

[2] Heuristic Evaluation. http://theuxclinic.com/casestudies/13-heuristic-evaluation-salescaddy [3] Rapid Contextual Design http://theuxclinic.com/casestudies/2-contextual-design-daisy-wheel [4] Rapid Paper Prototyping. http://theuxclinic.com/casestudies/3-rapid-paper-prototyping-spork

Si aceptas esta misión recuerda nunca estancarte en una suposición. Mejor sal del edificio y ponla a prueba. Al tiempo, sal y ponla a prueba de nuevo. Si no lo haces las reglas del juego pueden cambiar sin que te des cuenta. El diseño y el desarrollo de software son procesos dinámicos, no son entregables que se realizan una vez para luego quedar olvidados y estáticos.

[5] Kano Analysis. http://theuxclinic.com/casestudies/4-kano-analysis-bidaway [6] Business Origami. http://theuxclinic.com/casestudies/5-business-origami-crowdswell [7] Scenario Swimlanes. http://theuxclinic.com/casestudies/6-scenario-swimlanes-olset [8] Generative Research. http://theuxclinic.com/casestudies/7-generative-research-sureify

Misael León (@misaello) es UX Design Researcher en Nearsoft, Inc. una empresa de cultura democrática que desarrolla software y produce clientes felices. Es colaborador del UX Clinic, una iniciativa dedicada a difundir las mejores prácticas de UX. Es fanático de los libros, el cine, los chocolates. Promotor de la filosofía del asombro.

SG.COM.MX

039

TESTING

Sobre

Nuestra Misión como Testers —

Por Pilar Barrio

Seguramente lo primero que nos han transmitido o se nos ocurre es que nuestra misión es encontrar defectos y/o lograr entregar aplicaciones libres de defectos. Pero esto es sólo una pequeña parte y es una visión muy acotada del aporte de valor que nuestro trabajo puede brindar a una organización si es bien entendido y encarado (y recordemos que no existen aplicaciones libres de defectos, a lo sumo, si hacemos bien nuestro trabajo, estarán libres de los defectos importantes y relevantes para los interesados). Por otra parte, fuera de considerar únicamente lo que nosotros pensamos que es testear, debemos tener en cuenta qué esperan de nuestro servicio o actividad quienes nos contratan o convocan, qué expectativas tienen: • ¿Por qué una organización cree que es valioso tener un área de testing o contratar ese servicio en un proyecto? • ¿Qué espera obtener como retorno de su inversión en el área o el servicio? - Mejor calidad en sus productos, - Clientes o usuarios satisfechos, - Software “cero defectos”, -… - Todas las respuestas anteriores… • ¿Qué espera que hagamos? - Prueba durante el ciclo de vida de desarrollo de un producto, - Prueba de homologación de un producto adquirido, - Pruebas de atributos de calidad específicos, seguridad, performance, otros, -… - Todas o algunas de las respuestas anteriores… Difícilmente podemos cumplir los objetivos de quienes nos convocan o contratan, sean clientes internos o externos a nuestra organización, si no identificamos claramente nuestra misión: Qué tipo de testing tenemos que ejecutar, en qué contexto, en qué momento del proyecto / ciclo de vida del producto, con qué restricciones y recursos, con qué objetivos.

El “no pensé que iban a probar a este nivel de detalle” o “no pensé que iban a probar esto” o frases similares, son objeciones que típicamente aparecen cuando algunos miembros del equipo de proyecto no entienden por qué estamos ahí, pero también reflejan que los primeros que tenemos que tener clara nuestra misión somos nosotros, para aplicar nuestras mejores técnicas, prácticas, herramientas, imaginación, conocimientos, ética, para lograr cumplir esa misión. El testing es un servicio. Dada esa definición, para poder brindarlo “con calidad” (o sea cumpliendo las expectativas del cliente) necesitamos: • Entender expectativas y objetivos del cliente y otros interesados (pueden ser diferentes). • Cuestionar y evaluar el producto. • Focalizar los riesgos, entender y gestionar los cambios que afecten al servicio (en el proyecto, el producto, el contexto). • Investigar, explorar, brindar y facilitar la retroalimentación. • Confirmar, comunicar. • Proveer información relevante para la toma de decisiones, a distintos niveles de interesados. • Aprender, seguir capacitándonos. Así ayudaremos a completar el proyecto entregando un producto útil y exitoso para todas las partes. Para lograrlo es fundamental una buena comunicación y relación con todos los interesados por parte del equipo de proyecto, así como lo es entender el beneficio que brindará al negocio. La buena comunicación ayudará a lograr que los interesados transmitan mejor sus expectativas y necesidades, se involucren más en el día a día del servicio y reciban finalmente un producto que perciban como de calidad, sin tantos tropiezos. En relación a estos puntos, habría seguramente mucho más que decir y cada uno puede tener su propia visión. A quienes les interese reflexionar más sobre este tema, les recomiendo la discusión “Question: Tester’s Freedom of Thought” [1] en el blog de James Bach, que aunque es de 2006, sigue siendo muy valiosa.

En otras palabras, si no entendemos para qué nos llaman, no podremos cumplir las expectativas. Las expectativas y las percepciones del cliente y otros interesados podrían entonces diferir mucho, con lo que podrían concluir que hacer testing no aporta valor, o que nuestros servicios no aportan valor. — Y esto es a mi criterio uno de los orígenes de la “resistencia” que encontramos en algunos proyectos y una posible fuente de malentendidos o conflictos entre los integrantes de un equipo de proyecto.

Referencias [1] J. Bach. “Question: Tester’s Freedom of Thought”. http://www.satisfice.com/blog/archives/61

Pilar Barrio la Iglesia es socia fundadora de RMyA S.R.L., especializada en consultoría sobre aseguramiento de calidad y testing. pbarrio@rmya.com.ar

040

SG.47

VOCES

Los Bugs del Testing en México MADUREZ EN TIEMPOS DE PRUEBAS — Por Carlos González

En números anteriores de SG, Sandra Berenice Ruíz compartió un interesante artículo sobre las retrospectivas y tendencias sobre testing y nos hacía la invitación a dar pasos firmes hacia los nuevos retos que ya se están presentando en la industria. Sin embargo, nuestro día a día nos hace formularnos la pregunta: ¿realmente estamos impulsando un testing de calidad? No se trata solamente de hacer presencia, certificar gente o abrirnos camino. Se trata, incluso, de ser ejemplo a otras áreas en la empresa de que nuestro trabajo es de calidad, y que genera un verdadero valor.

técnicas rudimentarias que están poco dispuestos a dejar, mientras que los integrantes jóvenes tienen una formación poco robusta (consecuencia de lo que comento en el punto anterior). Básicamente, el grueso de nuestros testers aprendió a trabajar en base a sentido común y sus necesidades específicas, es decir que solamente cuentan con una formación empírica. Entre otras cosas, esto provoca discrepancia en la forma de trabajar entre distintos testers. Un ejemplo de ello es la gran diferencia que suele existir al diseñar casos de prueba, lo que provoca problemas de entendimiento; genera retrabajo, falsas estimaciones, y retrasos en la ejecución.

Carlos González cuenta con experiencia en la implementación de procesos y metodologías de prueba, certificado por el ISTQB y conferencista en SGCE 2014. Creador de la iniciativa Latin American Software Testing (http:// testingla.com)

cual

busca establecer criterios sólidos para el desarrollo y madurez del

México ha hecho un muy buen esfuerzo al ser el segundo país en Latinoamérica con mayor número de certificados por el ISTQB en el nivel de fundamentos, lo que nos deja ver el crecimiento y especialización de nuestra área. En este crecimiento se vuelve fundamental que los que estamos involucrados seamos evangelistas y no sólo creyentes. El reto ya no es poder aterrizar al testing, es ser autocríticos y perfeccionar lo que ahora realizamos para lograr mejores resultados. Sobre todo, sabiendo que nuestro país ha dado pasos importantes en materia de competitividad TI en el mundo. Es con este afán que expongo a continuación cuatro rasgos negativos que en general he detectado en organizaciones de software en nuestro país y que considero que debemos corregir para poder mejorar el nivel e impacto del testing.

No se reconoce la especialización del perfil de tester Desafortunadamente, en México todavía predomina la percepción de que para dedicarse al testing no se requieren conocimientos y aptitudes específicas y por lo tanto cualquiera puede dedicarse a el testing. Muestra de ello es que se siguen solicitando testers sin conocimientos en estándares, mejores prácticas, aptitudes específicas, e incluso sin tener una formación en TI. Esto es señal de una baja madurez de esta práctica en nuestra región.

Formación empírica Al trabajar con distintos equipos de testing a través de los años, con frecuencia me he encontrado con que los profesionistas con mayor experiencia siguen procesos y

Matando a la hormiga, no al hormiguero

testing en Latinoamérica.

Los perfiles formados en testing “a prueba y error”, la realización de tareas rutinarias y una cultura de corregir en lugar de prevenir repercuten en nuestros procesos actuales de calidad. Seguimos con la idea de que el testing consiste principalmente en detectar defectos de software, creando así una mentalidad de que la detección de defectos es el fin, cuando en realidad sólo es el medio para llegar a la prevención de defectos.

Actualmente se desempeña como Tester en MTP México.

Organizaciones y procesos no diseñados para testing En organizaciones poco maduras, los procesos y estructura no tienen considerados a los equipos y actividades de testing, por lo que se terminan incorporando “con calzador” y con resultados de poco impacto. Toda organización debe preguntarse qué es lo que se pretende al incorporar a un ingeniero de pruebas o a todo un equipo, y cómo van a soportar los esfuerzos de dicho equipo. Algunas de las preguntas que pueden surgir como resultado de este ejercicio son: • ¿Mi proceso de desarrollo tiene la flexibilidad para integrar un equipo de pruebas? • ¿Cuánto presupuesto vamos a disponer para herramientas de testing? • ¿Qué actividades harán los testers? ¿Aporta calidad que los testers también modifiquen código, realicen análisis, definan requerimientos, etc.? • ¿Qué aspectos probaremos y qué prioridad daremos a cada uno? ¿funcionalidad?, ¿desempeño?, ¿seguridad?

SG.COM.MX

041

MAKER ZONE

Generación de

Mapas de Alta Resolución con Drones —

Por Quauhtli Martínez

El campo de los vehículos aéreos no tripulados, conocidos como drones, ha cobrado gran interés en los últimos años. Una aplicación común de los drones es la Ortofotografía, es decir la generación de mapas digitales. Tradicionalmente, estos mapas se han generado utilizando avionetas, globos aeroestáticos, y satélites. Sin embargo, hoy en día es perfectamente factible hacer esto con drones, con un costo mucho menor que las opciones anteriores.

Componentes de un dron Antes de entrar en detalle, es importante dar a conocer cómo está construido un dron comercial. A grandes rasgos, consta de los siguientes componentes: • Motores. • Carcaza (frame). • Hélices (propellers). • Distribuidores de corriente eléctrica (Power Board). • Controladores de velocidad (Electronic Speed Controls). • Radio transmisores/receptores por radiofrecuencia. • Controlador de vuelo (Flight Controller) con puertos de entrada y salida para conectar los diferentes dispositivos. • Baterías y sus respectivos cargadores. Adicionalmente, existe una gran cantidad de componentes y opciones para tareas específicas, tales como sensores de diversos tipos (posicionamiento, temperatura, presión, etcétera), cámaras, pinzas electromecánicas, sistemas de telemetría, por mencionar algunos.

Caso de estudio En el presente caso de estudio se utilizó un dron tipo “cuadricóptero”, con un controlador de vuelo (“Pixhawk”) con capacidad de ejecutar vuelos autónomos a través de coordenadas geo-referenciadas vía GPS. Las imágenes se capturaron con una cámara Canon S100 modificada (vía software) que guarda la latitud, longitud y altura del punto geográfico donde fue tomada cada fotografía. La cámara se instaló en el cuadricóptero utilizando un soporte especial diseñado e impreso a la medida mediante una impresora 3D. La figura 1 muestra el dron utilizado, el objeto azul en la parte inferior del dron es el montaje con la cámara, cuyo detalle se muestra en el recuadro. El área de vuelo corresponde a un parque público en construcción en la ciudad de Navojoa, Sonora. El procedimiento utilizado para la obtención de la ortoimagen y del modelo tridimensional del parque en construcción contó con cinco etapas: 1. Inspección física del espacio a volar. 2. Planeación y diseño de vuelo y parámetros de fotografía.

042

SG.47

Figura 1. Dron con montaje de cámara.

3. Ejecución del vuelo y captura de imágenes aérea. 4. Procesamiento de imágenes y validación de la calidad. 5. Generación del modelo tridimensional y análisis.

Inspección física del espacio a volar En la primera etapa se realizó la inspección física del espacio a volar con el objetivo de identificar elementos físicos que pudieran causar una interrupción no deseada al vuelo del dron, por ejemplo, árboles muy altos, antenas, fuentes de electromagnetismo, edificios, etcétera. Con esta inspección fue posible detectar una antena cuya altura llegaba hasta los 30 metros de altura, parámetro que se utilizó como base para programar posteriormente el vuelo del dron a una altura de 40 metros para estar siempre por encima de la antena.

Planeación y diseño de vuelo Una vez realizada la inspección física, se llevó a cabo la planeación y el diseño del vuelo, así como la configuración de los parámetros de fotografía, los cuales son adaptados a las distintas condiciones del plan de vuelo, por ejemplo: la superficie a cubrir (que afecta a la rapidez con la que se deben tomar las fotografías), la velocidad de vuelo, la luz del día del vuelo (que afecta a los parámetros del obturador de la cámara), entre otros. Para esta fase, se utilizó una aplicación compatible con el controlador de vuelo del dron, esta aplicación se conoce como “Mission Planner”, es de código abierto y está disponible para la comunidad interesada. Dadas las restricciones del tiempo de vuelo por batería del dron (10-15 a quince minutos por cada carga), la zona de vuelo que consta de un perímetro aproximado de 313 metros x 190 metros se dividió en dos partes para poder hacer un intercambio de baterías una vez terminada la primera parte del vuelo.

MAKER ZONE

Para ambas secciones, se programó un vuelo autónomo a 40 metros de altura. La velocidad se ajustó a 5 metros por segundo y se utilizó un intervalómetro en la cámara (vía un script enviado a la cámara a través del Canon Hack Development Kit) para que las imágenes se capturaran cada 3 segundos. En otros casos, es posible capturar las imágenes cada determinada distancia, en vez de un intervalómetro, para ello se utilizan cables especiales “disparadores” conectados al controlador de vuelo y a la cámara. Con estos parámetros, se buscaba obtener, en un vuelo por sección de no más de 10 minutos con un 80% de traslape en las imágenes capturadas, lo cual es un parámetro de suma importancia para producir una imagen final de calidad. Los recuadros morados de la figura 2 muestran el nivel de traslape esperado en las imágenes capturadas. La intensidad del color morado refleja qué tanto traslape se espera en cada cuadro. Los cuadros con mayor traslape generan una imagen de mayor calidad, aunque necesitan mayor procesamiento para ser generados. En estas aplicaciones, 80% se considera un buen porcentaje de traslape en las imágenes.

Figura 3. Monitoreo de captura de datos en vivo.

Procesamiento de imágenes Una vez capturadas las imágenes, se utilizó la aplicación Agisoft PhotoScan Pro para realizar el procesamiento, verificar la calidad de las imágenes adquiridas (a través de un reporte de traslape), generar el ortomapa final, así como el modelo tridimensional y la exportación de un archivo KML para alimentar a Google Earth. Las imágenes individuales contaban con una resolución de 1200 x 1600 pixeles. La herramienta utilizada para el procesamiento de las imágenes reportó una resolución de 2.5 cm por pixel. Para el cálculo exacto de la relación de centímetros por pixel, existen técnicas formales más avanzadas, sin embargo, quedaron fuera del alcance de este caso de estudio. El primer paso para la generación de la ortoimagen y del modelo tridimensional es la importación de las imágenes al software de procesamiento. Una vez hecho, se puede observar sobre el mapa los puntos geográficos donde fueron tomadas cada una de las fotografías tal y como se muestra en la figura 4.

Figura 2. Nivel de traslape esperado.

Ejecución del vuelo Una vez construidos los planes de vuelo, estos fueron enviados al UAV a través del Mission Planner que comunicamos con el dron mediante un módulo de telemetría via USB que utiliza el protocolo MavLink. En estos planes de vuelo, entre otras cosas, se encontraba la trayectoria geo-referenciada de cada punto por el cual el dron debía volar. Una vez que el plan se envió al dron, se ejecutó el vuelo de manera autónoma, con el intervalómetro de la cámara accionado para tomar las imágenes cada 3 segundos. Esto significaba que, una vez despegado, el dron alcanzó cada punto geo-posicionado sin necesidad de ser controlado por el piloto a través de un control remoto con radio-frecuencia, Se utilizó el Mission Planner para supervisar en tiempo real las condiciones del UAV durante el vuelo, así como para validar la trayectoria que seguía, entre otros datos. En la figura 3 se muestra un ejemplo de cómo se obtiene la información en vivo del dron en un vuelo autónomo.

Figura 4. Puntos donde se tomaron las fotografías.

A partir de estas fotografías, la aplicación realizó un intenso procesamiento en el que analizó cada pixel de cada una de las imágenes capturadas en el cual encuentra similitudes y continuidades; con ello, la aplicación, crea un mosaico en el que queden unidas todas las fotografías en una única imagen, manteniendo la coherencia y la resolución en la imagen final (ortoimagen).

SG.COM.MX

043

MAKER ZONE

Figura 5. Nivel de traslape de imágenes.

Figura 6. Ortoimagen final.

Para verificar la calidad de la imagen final, además de revisar ocularmente la ortoimagen generada, es posible verificar vía la herramienta el traslape de imágenes (el cual se buscó que fuera de un 80%). En la figura 5 se puede observar el nivel de traslape obtenido con las imágenes capturadas. Las áreas rojas muestran los puntos donde sólo se utilizó una imagen; y las áreas azules oscuro, más de 9 imágenes. Al tomar una muestra de cada una de las zonas se pude observar el porqué de las variaciones en el traslape: en la parte coloreada con verde intenso, se observa que el dron capturó más imágenes que en la parte de color amarillo.

conservación de sitios arqueológicos, de hecho, ya hay empresas que se dedican exclusivamente a ofrecer servicios para la arqueología utilizando drones y fotografía aérea geo-referenciada [3].

De manera general, el porcentaje de traslape obtenido fue lo suficientemente bueno para generar una ortoimagen coherente y con calidad suficiente para realizar este estudio. Para trabajos que requieren una mayor calidad, este porcentaje de traslape probablemente no hubiese sido suficiente.

Generación de modelo tridimensional y análisis Una vez construida la ortoimagen, se generó a través de la misma herramienta el modelo tridimensional, el cual, añade volumen a los objetos de la ortoimagen. Este modelo puede ser exportado y utilizado en cualquier otra herramienta para manipulación de imágenes tridimensionales. En este caso, se utilizó el servicio en la nube Sketchfab para que el modelo pudiera ser consultado vía web a través del siguiente sitio web http://goo.gl/3oCgta.

Por otro lado, para tener una mayor precisión en la generación de un modelo tridimensional y en una ortoimagen, es importante recalcar la importancia de la fase de captura de imágenes. En el caso estudiado en este artículo, el modelo tridimensional generado no fue lo suficientemente rico como para ser utilizado en una aplicación profesional, debido a que no hubo suficientes imágenes para generar los volúmenes de los objetos contenidos en la imagen con una mayor precisión, para ello es necesario fotografiar el sitio a diferentes alturas y perspectivas. Finalmente, el uso de drones para la construcción de ortoimágenes y modelos tridimensionales a escala, ya es algo al alcance de cualquier usuario que pueda adquirir equipo como los que se utilizaron en este estudio (2 mil dólares aproximadamente, incluyendo la cámara), siendo esto algo muy novedoso, con múltiples aplicaciones y con el potencial para generar nuevos negocios en estos momentos. — Referencias [1] Orto-imagen del parque. https://mangomap.com/maps/34662/Mapa-Parque-Navojoa

Conclusiones

[2] Modelo tridimensional del parque. http://goo.gl/3oCgta

Al tener una imagen geo-referenciada y un modelo tridimensional a escala, es posible utilizar estos modelos para diferentes propósitos. Por ejemplo, en la construcción y arquitectura, estas imágenes pueden ser importadas en aplicaciones tipo CAD o GIS para realizar diferentes mediciones como superficies, distancias y volúmenes, además de la posibilidad de inspeccionar visualmente el avance de la obra y detectar anomalías que, a simple vista, no podrían ser detectadas debido a la perspectiva a nivel de suelo que comúnmente se tiene. Otro ejemplo de caso de uso, sería en la

[3] Aerial Digital Archeology & Preservation. http://dronearchaeology.com [4] Mission Planner. http://planner.ardupilot.com [5] Agisoft PhotoScan. http://www.agisoft.com [6] Protocolo MavLink. http://qgroundcontrol.org/mavlink/start [7] Controlador de vuelo PixHawk. https://pixhawk.org/ [8] Canon Hack Development Kit. http://chdk.wikia.com/wiki/CHDK [9] KAP UAV Exposure Control Script. http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_Script

Quauhtli Martínez (@quauhtlimtzz) es director en SOA Software Factory y cofundador de Droneware, empresa especializada en la creación de soluciones usando drones. http://droneware.mx

044

SG.47

ALGORITMIA

Cinco Problemas

para Menos de 1 Hora —

Por Pedro Galván

Como parte de la revisión editorial que estamos haciendo en Software Guru, hemos decidido abrir una nueva sección dedicada a algoritmia y programación. Conforme buscaba contenido para esta sección, me recomendaron un artículo del blog de Santiago L. Valderrama [1] donde comenta que le sorprende que una gran cantidad de personas que hoy en día aplican para posiciones de ingeniero de software, en realidad no saben programar. En sus palabras: “Imagino que es aceptable aplicar para una posición de desarrollador web si sólo sabes JQuery, pero ¿desde cuándo “ingeniero de software” significa que basta con saber HTML, Javascript y CSS?

5. Usando los números del 1 al 9 en orden consecutivo, podemos realizar 3 operaciones entre cada dígito: suma, resta o concatenación, para que el resultado de las operaciones conjuntas de como resultado 100. Por ejemplo: 1+2+34-5+67-8+9=100. Entonces, escribe un programa que encuentre todas las posibilidades de realizar esto. Los primeros 3 problemas son muy sencillos, el cuarto tiene un poco de jiribilla y el quinto sí es más complicado. Personalmente, creo que quien pueda resolver el quinto problema en menos de 1 hora, merece “puntos extra”, pero no descartaría a quienes no puedan hacerlo.

Espero que quienes aplican a mi vacante de ingeniero de software, puedan realmente programar. Es decir, que reciban un problema y programen una solución utilizando cualquier lenguaje de programación que quieran”.

En las referencias de este artículo encontrarás enlaces a ejemplos de solución que Santiago sugiere para los problema 4 y 5. Antes de consultarlas, te invito a que intentes resolver los problemas por tí mismo y solo consultes la solución hasta que hayas terminado o te hayas rendido.

Concuerdo con Santiago, y justamente es el espíritu de esta nueva sección en SG.

En futuras entregas de esta sección encontrarás artículos donde revisaremos problemas de programación y estrategias para resolverlos.

Para poder evaluar si alguien sabe programar o no, Santiago plantea un reto con 5 problemas, indicando que un verdadero “ingeniero de software” debería ser capaz de resolverlos en 1 hora.

Te invito a que compartas tus soluciones como comentarios en la versión online de este artículo, publicada en http://sg.com.mx/revista/47/ cinco-problemas-para-menos-1-hora

Comparto a continuación los problemas que plantea Santiago, y los invito a que los resuelvan utilizando el lenguaje de programación de su preferencia.

Spoiler alert: En el caso del problema 4 verifica que tu solución sea capaz de soportar el escenario en el que recibe una lista como [5, 50, 56]. El resultado correcto en este caso no es 56505 sino 56550. Así que vas a tener que hacer algo más que una simple comparación de strings.

1. Escribe 3 funciones que calculen la suma de los números en una lista. En la primer función utiliza un ciclo for, en la segunda un while, y en la tercera recursividad. 2. Escribe una función que combine dos listas alternando los elementos de cada una. Por ejemplo, si tenemos las listas [a, b, c] y [1, 2, 3] la función debería regresar [a, 1, b, 2, c, 3]. 3. Escribe una función que calcule la lista de los primeros 100 números Fibonacci. Por definición, los primeros números de la secuencia son 0 y 1, y cada número subsecuente es la suma de los dos anteriores.

— Referencias [1] S. Valderrama. “Five Programming problems every Software Engineer should be able

4. Escribe una función, que dada una lista de enteros no negativos, los organice de manera que forman el número más grande posible. Por ejemplo, dada la lista [ 50, 2, 1, 9] el resultado sería 95021.

to solve in less than 1 hour”. http://swgu.ru/pu [2] S. Valderrama. “Solution to problem 4”. http://swgu.ru/pv [3] S. Valderrama. “Solution to problem 5”. http://swgu.ru/pw

SG.COM.MX

045

VOCES

Más Allá del Software PARTE 2. FINANCIAMIENTO Y MODELO DE NEGOCIO — Por Víctor Hernández

Victor Jesús Hernández Salinas es Coordinador de

Servicios

Productos en INFOTEC. Desde

2003

colabo-

ra en INFOTEC en el equipo

Desarrollo

de Nuevos Productos y Servicios. Fue creador y Coordinador del área de servicios a producto y su normatividad. Es además coordinador del programa de certificaciones para SWB.

En el artículo anterior “Cuestionamientos y servicios”, tratamos las consideraciones para lanzarse a la aventura de desarrollar un producto (desarrollo software más los servicios que lo respaldan), y ahora continuaremos con algunos otros puntos que se deben considerar para el financiamiento y el desarrollo del modelo de negocio. Comencemos con la parte del financiamiento, pues es aquí donde la mayoría de las grandes ideas terminan. Por supuesto, conoces los métodos de financiamiento tradicionales con plazos y tasas de interés considerables, por lo que muchas personas y empresas optan por no entrar en ellos y si lo hacen es con mucha cautela. Sin embargo, en México existen distintos programas federales o estatales (Según INADEM más de 100) destinados al apoyo de la innovación y desarrollo tecnológico por medio de subsidios, créditos, asesorías, capacitaciones o becas, los cuales (lamentablemente) no reciben la difusión adecuada. Estos programas, podrían ser un buen mecanismo de financiar tu proyecto, pues aunque deben cumplir diversos requisitos y en algunos casos contar con la colaboración de instituciones educativas o de investigación, el concursar por dichos recursos puede ser una excelente opción para buscar fuentes, no sólo de financiamiento, sino de recursos técnicos que quizás no podrías disponer de manera regular. Tan solo algunas de las dependencias que ofrecen este tipo de programas son: INADEM, CONACYT (en colaboración con distintas entidades), PROSOFT, MexicoFIRST, o dependencias estatales equivalentes. Sugiero entonces, acercarse a la cabeza del sector del área de aplicación de tu producto e investigar sobre dichos programas, así como las fechas de publicación y registro a los mismos (pero no te quedes en recepción, ve directo a las áreas de comunicación o de programas sociales). Ahora bien, supongamos que ya se resolvió el financiamiento y estás listo para arremangarte la camisa y comenzar a trabajar. Uno de los primeros requisitos a resolver tanto para la parte financiera, como para la sustentabilidad del proyecto, es el modelo de negocio que decidas adoptar. En lo personal me gusta pensar que un modelo válido y funcional es el propuesto por la “Teoría de Restricciones” donde sostiene que deben cumplirse tres condiciones básicas: 1. Asegurar la satisfacción presente y futura de los clientes. 2. Asegurar la satisfacción y estabilidad presente y futura de los trabajadores y colaboradores. 3. Asegurar la satisfacción presente y futura de los inversionistas. El postulado es, que si tu modelo de negocio no cumple con alguna de estas condiciones en cualquier momento, es una

046

SG.47

opción que deberá desecharse y pasar a la siguiente. Puede sonar complicado de lograr considerando que las condiciones de mercado, tecnológicas, legales, entre otras; no son constantes y cambian frecuentemente. Lo que hoy funciona, puede no hacerlo mañana. Pero lo importante es asegurar que todas las acciones a realizar antes, durante y después del desarrollo, contribuyan a lograr las condiciones mencionadas. Algunas sugerencias de condiciones del modelo de negocio que propongo deben incluir: • Desarrollar poniéndose en los zapatos del cliente (cómo nos gustaría que nos sirviera el producto si nosotros lo tuviéramos que comprar). • Planear la trayectoria completa de satisfacción del cliente (expectativas vs experiencias). Desde el “coqueteo” con el cliente, hasta que nos compra y cómo nos recomendará con sus amigos. • Al pensar en el precio, debemos recordar que valor y costo no son lo mismo, y que el mismo producto tendrá percepciones de valor distintas para cada cliente, por lo que diferenciar y segmentar mercados puede ser una buena opción. • Disponer canales de comunicación directa y bidireccional con los clientes, permite crear comunidades, mejora la atención y el servicio al cliente y principalmente, fomenta la creación de “fans” de la marca, que al final se convertirán en evangelistas, que son aún más valiosos que los clientes, pues ayudarán a vender el producto por convicción y gusto (y gratis). Otro aspecto a considerar al planear el modelo de negocio para el producto implica el tipo de servicios que se ofrecerán para respaldar al mismo, y es importante considerar que aunque no se liberen todos al mismo tiempo o en la magnitud deseada al momento del lanzamiento, sí deben incluirse los más representativos y en consecuencia, se deberá contar con el suficiente personal capacitado y recursos técnicos y financieros necesarios para poder otorgarlos debidamente. Debe haber también, una proyección de tiempo de cuándo y cómo se lanzarán los servicios adicionales que apoyen al posicionamiento del producto.

Conclusión Recuerda que las marcas no son razón suficiente de compra mientras no estén respaldadas por un valor real para el cliente y que por tanto, el entender debidamente las actividades que éste realiza, así como su experiencia con nuestro producto (software y servicios) debe ser la guía para determinar muchas de las características básicas a incluir en el modelo de negocio. Sin olvidar, que el producto debe enfocarse en resolver las necesidades no sólo del cliente directo, sino del cliente del cliente.

PROGRAMAR ES UN MODO DE VIDA

Los Detalles de Implementación en la Era de las Abstracciones UNA CHARLA ENTRE YO JEKYLL Y YO HIDE — Por Gunnar Wolf

– Me llamo Gunnar, y soy programador. – ¡Hola, Gunnar! – Tengo que contarles hoy respecto a mi abuso de las abstracciones y de la automatización. Por aprovechar las facilidades de un framework completo y poderoso, me he ido olvidando de las interacciones reales. Me engolosiné con un ORM que me presenta los datos como objetos, y me olvido de la realidad de su representación entidad-referencial. Mis métodos son todos cortitos y asumo que el ciclo de atención a solicitudes es corto, olvidando que dejo referencias en memoria. Hago llamadas a procedimientos remotos en proveedores SaaS y no considero que pueden fallar. – Pero ahora estás consciente de ello. ¡Has dado el Primer Paso! ¡Ese es el camino para ser un programador! – Sí, pero… ¿Por dónde comienzo? Hay tantas abstracciones, tanto por reaprender. A todos lados a donde volteo a buscar, me encuentro con más abstracciones. ¡Me siento perdido! ¿Dónde quedó la simple realidad del cómputo que teníamos antes?

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador en el proyecto Debian

Sí, no hay ni cómo esconderlo. Tiene ya varias décadas que me apasionó comprender lo que pasa dentro de una computadora, cómo opera su aparente magia. Y cuando aprendí, cuando muchos de nosotros aprendimos, incluso un niño de diez años podía comprender cómo operaban ciertos procesos, si bien tal vez no a nivel electrónico, sí a partir de una visión muy cercana. Piensen, por ejemplo, en qué tan a profundidad podía un niño de los ochenta conocer a una magnífica Commodore 64, e incluso cuánto puede haber aprendido con una PC. Recuerdo largas horas de leer documentación, modificar binarios a mano con un editor hexadecimal para cambiar las cadenas que presentaban al usuario, buscando comprender todo lo que veía —simplemente, porque era posible hacerlo.

GNU/Linux. http://gwolf.org

048

SG.47

Con el tiempo, el mundo ha ido cambiando. Y yo también. Al volverme un miembro útil a la sociedad, como les habrá pasado a ustedes también, fui eligiendo mi nicho ecológico: desarrollo de aplicaciones web y administración de sistemas. Primero, exprimiendo los detallitos que me ofrecía cada pedacito del protocolo… Aunque recuerdo muy bien una discusión con un colega: yo era bastante reacio a emplear frameworks de desarrollo precisamente porque, al automatizar las tareas repetitivas, esconden del programador su funcionamiento real, y dificultan tener verdadero control de lo que hacen, pero él me mostró las ventajas que conllevan.

Pero bueno, acortando la historia … de desarrollar mis aplicaciones completas con el lenguaje Perl, cabalgando a pelo sobre el API de Apache, me subí al tren de Ruby on Rails. Y disfruté muchísimo de las posibilidades que me brindó esta experiencia: una programación más limpia, orientada a objetos. Configuración por convención. Muchas muy buenas prácticas de desarrollo, y un marco de desarrollo con opiniones propias que me marcó cómo estructurar mi desarrollo. Y sí, las aplicaciones resultantes eran comprensiblemente más rápidas de desarrollar, y al tener el comportamiento base resuelto, me topé con muchos menos errores lógicos en las capas más bajas. Pero la vida sobre un framework también trae sus desencantos. En mi caso, me topé con los primeros al encontrar la cantidad de código que había que reescribir cuando Rails pasó de su versión 1 a 2, de 2 a 3. Como es de esperarse, los cambios que introducen las versiones mayores no son compatibles hacia atrás, y buena parte de mi código histórico iba emitiendo advertencias por usos desaconsejados — O rompiéndose por completo. Y entre más sistemas desarrollaba, menos tiempo tenía para mantenerlos a todos al día. La respuesta de la comunidad Rails a mis cuitas es relativamente simple. Un sistema que ya está en producción no requiere ser actualizado. El programador puede congelar el sistema base y las gemas (bibliotecas) que emplea, y convivir

PROGRAMAR ES UN MODO DE VIDA

“Los frameworks no únicamente son cómodos, sino que son necesarios para la realidad del desarrollo de software hoy en día”.

fácilmente en el mismo sistema con otras aplicaciones Rails — Incluso si estas usan otras versiones de prácticamente todo en el sistema. En ese momento, comenzó una lucha interior, entre mi Dr. Jekyll, un administrador de sistemas que prepara las cosas y, con la cabeza fría, mantiene una visión consistente y coherente del conjunto, y mi Mr. Hyde, un programador que quiere vivir al límite probando las últimas versiones del último grito de la moda, cambiando de arquitectura subyacente, abandonando a FCGI por Mongrel, a Mongrel por Thin, a Thin por Passenger, incorporando a Rack… Y claro, encarnando a esa aberración de la que hablaremos en otra ocasión que hoy deambula libremente: el temido DevOps, criatura que encarna lo más obscuro tanto de desarrolladores como de administradores. Y ojo, me centro en este aspecto porque mi Dr. Jekyll es administrador de sistemas. Pueden imaginar lo que diría uno con formación de DBA al ver el caos resultante del ORM: ¿Cómo se crea mi esquema de datos? ¿Dónde están las verificaciones de integridad? ¿Cómo se generan las consultas para cada una de las operaciones que el buen ActiveRecord realiza? En fin, podemos recordar esa máxima de la ciencia de la computación, que he visto atribuída tanto a David Wheeler como a Butler Lampson: Todos los problemas en la ciencia de la computación pueden resolverse con un nivel adicional de indirección — a excepción del de tener demasiados niveles de indirección. Mientras esa pelea ocurría en mi yo desarrollador, muchos otros importantes cambios se presentaron en mi vida. Uno de ellos, me convertí en profesor en la Facultad de Ingeniería de la UNAM. Imparto una materia que siempre me emocionó: Sistemas Operativos. He disfrutado muchísimo con la preparación del material y con el dictado de las clases. En esta materia estudiamos las funciones básicas de todo sistema operativo — Comunicación entre procesos, multiplexión de recursos, organización de sistemas de archivos, gestión de memoria, etc. Conforme estudio y repito mi material, y conforme comento al respecto con mis colegas, vuelvo a uno de los planteamientos de origen que siempre hago a mis alumnos: no espero que de mi clase salgan autores de sistemas operativos; sería un gran orgullo que así fuera, pero no es lo que la materia persigue. Una de las principales razones para estudiar esta materia es que, si no se comprenden los fundamentos

de lo que estamos haciendo, nuestros programas van a resultar de muy baja calidad. Si nos olvidamos que a fin de cuentas todo nuestro código se traduce a instrucciones de muy bajo nivel, si nos olvidamos de cuidar la eficiencia de los cachés y de reducir accesos a disco, si no tenemos en cuenta el costo de cada llamada al sistema, si no consideramos la necesaria sincronización en problemas que enfrentan concurrencia… Vamos a terminar creando código lento y frágil. Vamos a terminar siendo malos desarrolladores. Entonces bien, el motivo de esta columna no es llamar a que abandonemos las herramientas que facilitan nuestra tarea. Los frameworks no únicamente son cómodos, sino que son necesarios para la realidad del desarrollo de software hoy en día. Pero debemos mantener en mente, siempre, la importancia de comprender qué pasa. Si hay un comportamiento dado que parece mágico, ese es el punto donde debemos revisar el código fuente del framework y averiguar cómo está haciéndolo. Porque sólo de esa forma podremos sacar el provecho correcto del sistema — y escribir mejor código, que a fin de cuentas, por eso nos hacemos llamar profesionales. Entonces, vestidos de investigadores privados y lupa en mano, ¡vamos a investigar implementaciones! ¡Disfruten el viaje!

Si alguno de ustedes se siente identificado con este disfrute histórico, no puedo dejar de invitarlos a una de las lecturas que más he disfrutado en los últimos meses. Un libro titulado sencillamente «10 PRINT CHR$(205.5+RND(1)); : GOTO 10», y que pueden descargar gratuitamente de http://10print. org. Este libro aborda muy distintos aspectos que se desprenden de la línea de BASIC que lleva por título; un análisis técnico, social, cultural, incluso artístico de esa era que a tantos nos atrapó convirtió en lo que hoy somos. Como segunda nota recomendación literaria, el libro «Lauren Ipsum: A story about computer science and other improbable things» de Carlos Bueno (http://laurenipsum.org). Aprender los fundamentos del cómputo siendo aún niño definió mi vida. Este libro presenta, a través de un cuento inspirado en Alicia en el país de las maravillas, conceptos fundamentales de la ciencia de la computación: Problemas clásicos, estructuras de datos, conceptos fundamentales, presentados con el cuento de una niña perdida en el bosque de los árboles rojo-negros, buscando volver a casa.

SG.COM.MX

049

VOCES

Software Defined Networking — Por Carlos Perea

Carlos Perea es Vicepresidente de Ventas para Latinoamérica de Extreme Networks

¿Cuál es el resultado de que el hardware ceda el control de los procesos a los componentes que se encuentran en niveles superiores de sofisticación?, ¿cómo puede el software tomar un papel más estratégico en la redes sin comprometer la seguridad e integridad de la misma? El Software Defined everything (SDx) se divide en varias ramas clave para entender a dónde va este concepto: Software Defined Storage, Software Defined Infrastrucure hasta el Software Defined Security y por supuesto, Software Defined Networks. Hablamos de una evolución tecnológica natural frente a un nuevo paradigma en la industria: capacidad de adaptabilidad de la infraestructura de red que genere valor al negocio, democratice el uso de la red y se tenga una administración descentralizada pero con una gran seguridad y estándares abiertos que no aten a los CIOs a un fabricante, tal y como había venido dándose. Debemos ser capaces de resolver los complejos retos a los que las empresas y organizaciones se están enfrentando y hacer de sus redes un activo estratégico de su negocio, no un gasto. Desde la concepción y nacimiento de las redes informáticas, su evolución ha estado marcada tanto por la respuesta a una demanda en innovación y síntesis en los procesos, como a la de proveer una multiplicidad de prestaciones y valores a los procesos de negocio. Dada la complejidad pero alcance que han ido sumando generación tras generación, las redes informáticas forman parte de la funcionalidad crítica de casi cualquier industria de todos los sectores productivos existentes. El surgimiento de tendencias tecnológicas como la virtualización y la migración a ambientes virtuales, Cloud Computing, patrones de tráfico en la red, BYOD y Wi-Fi de alta densidad para un número cada vez más sólo de dispositivos dentro y fuera de las organizaciones, son solo algunos indicadores de que el paradigma de las redes informáticas tal cual lo conocemos hoy, necesita un cambio. Para satisfacer este cambio de paradigma en las redes informáticas, han surgido diferentes propuestas, entre las que destacan las Redes Definidas por Software, o SDN. SDN es el resultado de más de seis años de trabajo de investigación, y en este tiempo se ha consolidado como una arquitectura lo suficientemente flexible y funcional como para permitir a los administradores de red gestionar y monitorear la infraestructura con una inversión de tiempo y recursos mínimos. Sin embargo, a pesar de que SDN es capaz de resolver la mayoría de los problemas que plantean las redes actuales en su complejidad, el reto más grande que encaran hoy las empresas consiste en tener un acercamiento realista a esta arquitectura de forma rentable, sin tener que renovar totalmente su infraestructura y obteniendo un mayor control posible sobre

050

SG.47

la multiplicidad de funciones que exigen las nuevas redes, automatizándolas tanto como sea posible. ¿Por qué los CIOs se sienten tan atraídos por el SDN?, se debe a que esta arquitectura ofrece tres aspectos fundamentales que agregan valor a la red y la convierte en un activo estratégico para la red: 1. Una administración mejorada que permita que las redes de las organizaciones evolucionen a la par de los nuevos modelos intensivos de cómputo, tráfico y densidad; en adición a estándares abiertos que no atan a los clientes a un solo fabricante. 2. Un esquema ágil en el cual es posible que la red se modifique de manera automática para cumplir con las exigencias de los cambios, ya que las redes basadas en SDN son por mucho, más flexibles que las administradas de forma tradicional. 3. Una disminución sustancial en los costos operativos. Automatizar funciones de la red permite esta disminución al mismo tiempo que mejora y aumenta la productividad del área de TI.

SDN con estándares abiertos Desplegar una nueva aplicación SDN en una red existente, regularmente es una tarea algo compleja. Las soluciones de SDN con estándares abiertos permiten a los clientes contar con estos servicios sin importar quien los provea. Un ejemplo es el ecosistema abierto que Extreme Networks propone, al no sólo estar probado en diferentes condiciones, sino que abre la puerta a nuevas aplicaciones que estén siendo desarrolladas con estándares OpenDaylight. Una plataforma de SDN debe ser simple, rápida e inteligente; que pueda integrarse fácilmente a diferentes equipos y software de otros fabricantes y no debe intentar amarrar al cliente con estándares cerrados que con el tiempo, serán caros y poco escalables. Plataformas basadas en estos conceptos, buscan hacer más ágil la compatibilidad en infraestructuras multi-fabricante con estándares OpenFlow standard y otras API abiertas. El resultado es simple: una plataforma sin las limitaciones que comúnmente se encuentran en otros modelos SDN en el mercado, muchos de ellos, no son aplicables y obligan a las organizaciones a atarse a un mismo fabricante. Implementar una arquitectura de SDN de código abierto, permite a cada cliente evolucionar su red conforme a sus propias necesidades de seguridad, al ritmo que la complejidad y el tamaño de la organización lo permitan y desde luego, siendo congruentes y realistas con los presupuestos asignados.

FUNDAMENTOS

Fig. 1. Funcionamiento de PKI.

Certificados Digitales — Por Héctor Uriel Pérez Rojas

Seguramente en alguna ocasión has escuchado acerca de los certificados digitales, por ejemplo al navegar en internet, o al autentificarte dentro del portal del SAT para realizar diferentes movimientos. En este artículo veremos qué son y cómo funcionan a grandes rasgos.

Antecedentes Hoy en día, como parte de la rama de la criptografía, existen dos tipos de algoritmos populares para cifrar información: simétricos y asimétricos. En los algoritmos simétricos se utiliza una misma llave para cifrar y descifrar mensajes (por ejemplo cuando se comprime un fichero con una contraseña en WinRAR). Esto quiere decir que tanto emisor como receptor, deben tener la misma llave (contraseña) para cifrar/descifrar los mensajes. El riesgo en este tipo de cifrado reside en el hecho de que ambas partes deben compartirse la clave a través de algún canal de comunicación, siendo éste la mayoría de las veces inseguro. En cambio, en los algoritmos asimétricos cada uno de los participantes cuenta con una llave pública y una llave privada. La llave pública puede ser compartida con aquellos remitentes que requieran enviar un mensaje cifrado al destinatario, mismo que sólo podrá ser descifrado a través de la llave privada del destinatario. Dicha clave, debe ser únicamente conocida por el propietario. Si por otra parte, el propietario de las llaves desea publicar un mensaje, deberá cifrarlo con su clave privada, para que aquellos que cuenten con su llave pública, puedan descifrar el

mensaje enviado. Este es el principio en el cual se basa la firma electrónica.

Certificados digitales Para entender de una forma práctica los certificados digitales, comparémoslos con los certificados que se obtienen al concluir algún curso o entrenamiento. Dichos certificados, generalmente constan de un emisor (la institución que emite el certificado), la persona a quien se le reconoce, un sello, y en ocasiones, una fecha de expiración. Lo mismo ocurre con los certificados digitales, los cuales contienen los datos de quién ha emitido el certificado, los datos de la persona a quien validan para hacer uso del certificado, una fecha de expiración, la llave pública del propietario del certificado, una huella digital equivalente al sello oficial de la institución, entre otros datos opcionales.

framework, consiste en un conjunto de hardware, software, gente, procesos y políticas que juntos, permiten crear, administrar, distribuir, usar, almacenar y revocar certificados digitales. La figura 1 ilustra el funcionamiento de dicha infraestructura. El proceso para obtener un certificado digital, inicia con una petición hacia la Autoridad Registradora (RA), que es la encargada de recibir todas las solicitudes. De igual forma, se ocupa de validar la información real de la entidad. Si se tomara como ejemplo el caso del SAT, se validaría que la persona física o moral sea realmente quien acude a solicitar su par de llaves.

Se puede tener la certeza de que un certificado digital permanece íntegro, a través de la huella digital. Esta se obtiene generando un valor hash tomando como base el propio certificado digital. Posteriormente, se aplica otra función matemática que usa la llave privada del emisor para generar la huella digital. Esto ayudará a que se pueda comprobar que el certificado digital no haya sido alterado o dañado, dando como resultado una comprobación de identidad.

Una vez que se ha validado que el solicitante es confiable, se procede a enviar la información de éste a la Autoridad Certificadora (CA), la cual generará un nuevo certificado digital con la información del solicitante, así como información sobre el uso del certificado, periodo de validez, la huella digital, entre otros. Otro componente clave es la Autoridad Validadora (VA), también conocida como OSCP (Online Certificate Status Protocol), un servidor cuyo principal objetivo es mantener una base de datos con todos los certificados emitidos por la CA, con su respectivo estatus (válido, revocado o desconocido). Esto le permitirá a un tercero validar el estatus de un certificado digital, y con esto determinar si debe aceptarlo o no.

Infraestructura de Llave Pública (PKI)

Conclusión

Los certificados digitales más conocidos, se basan en el estándar denominado X.509, y que se encuentra en la versión 3. El estándar X.509, es parte de un framework denominado Infraestructura de Llave Pública (PKI por sus siglas en inglés). Dicho

Continuamente compartimos información sensible a través de internet apoyándonos en certificados digitales. Es importante que entendamos cómo funcionan y el papel que juegan en los esquemas de seguridad.

Validación de un certificado digital

Héctor Uriel Pérez Rojas es maestro en Ciencias de la Computación con especialidad en Ingeniería de Software por parte del CENIDET. Es socio fundador de Grupo Empresarial Multidisciplinario IASEC. www.iasec.com.mx

052

SG.47

CARRERA

Guía para Certificarte como Tester por el ISTQB — Por Ismael Villegas y Armando Márquez Espinoza

Dentro de las certificaciones que se manejan en el mercado para desarrollo de software, se encuentra la del área de pruebas o testing con el ISTQB (International Software Testing Qualifications Board). Esta certificación permite validar que el sustentante tiene los conocimientos necesarios para calificar como Tester de Software y cubrir todos los posibles ángulos sobre los escenarios que el software debe considerar para darlo como completo y con la funcionalidad correcta. La intención de este artículo es desglosar los diversos temas que se requieren para poder presentar el examen de certificación para ser tester. Fundamentos de pruebas. En esta sección se introduce a la persona a los conceptos básicos de pruebas de software, los cuales consideran la importancia de las pruebas y el cómo éstas permiten generar software con calidad. Se plantean reglas y un proceso general para la aplicación de las pruebas. Se hace hincapié en el código de ética que el tester debe de cubrir tanto con sus clientes como en su equipo de trabajo, para el buen desempeño de sus funciones. Ciclos de vida. Como tester es importante conocer los ciclos de vida de desarrollo del software, ya que son una parte importante de la certificación. Una vez que se comprenden los ciclos de vida, se estudian los niveles de pruebas dentro del ciclo de vida y que incluyen las etapas de pruebas. Se revisan los diferentes tipos de prueba que existen y se entiende cómo aplicarlos dentro del software. Pruebas estáticas. Se revisan los pasos requeridos para realizar un conjunto de pruebas. Lo que significa que se definen las etapas y las

condiciones para dar por buenas cada una de ellas. Adicionalmente se revisan las responsabilidades de todo aquel involucrado en el proceso de pruebas. Técnicas de diseño de pruebas. Se revisa el proceso de pruebas y se delimita el alcance de las pruebas que se van a realizar. Éstas incluyen tanto pruebas basadas en especificación (caja negra) como basadas en estructura (caja blanca). Dependiendo el escenario se aprende a seleccionar el tipo de prueba a utilizar. Administración de pruebas. En esta sección se revisan temas con respecto a la organización de pruebas, desde las estrategias a utilizar, pasando por la planeación y estimación de las pruebas a aplicar. La administración básica con un control y monitoreo de incidentes se cubre también en este apartado. La administración de la configuración es un tema recurrente para controlar las pruebas y todos los artefactos generados en ellas. Herramientas de soporte para pruebas. Se describen las herramientas de pruebas automáticas y el uso que se les da a éstas. La automatización y seguimiento de los resultados para pruebas complejas o de volumen son algunos de los ejemplos que se realizan en este apartado.

Conclusión El área de pruebas durante los últimos años ha cobrado interés e importancia dentro de las organizaciones de tecnología, por ello es vital que el Tester busque la formalización de su labor con una certificación que avale su capacidad y conocimiento. Esta certificación es vigente en cualquier parte del mundo y permite crear un plan de carrera con la profesionalización y especialización de las pruebas de software.

Para apoyar a la organización a formar un equipo de pruebas con parámetros de conocimiento homogéneo es recomendable que sus equipos lo formalicen a través de la certificación. El equipo de pruebas crecerá y generará más valor para el área de tecnología, lo cual será importante para mostrar a la comunidad que la profesión de tester es clave para la obtención de productos de software con calidad y con menos fallas, porque así como es importante generar el código para una aplicación, es más importante revisar que ésta haga lo que se supone. Se recomienda la revisión del ISTQB Syllabus y el Glosario como parte de un autoestudio para homologar términos. El nivel Foundation que es el básico de los tres que se ofrecen, no mide la habilidad sino el conocimiento de los conceptos de las pruebas de software; y es necesario para poder presentar los siguientes. El nivel avanzado maneja el conocimiento necesario para la administración de equipos de pruebas y de pruebas técnicas avanzadas; el nivel experto provee el conocimiento para la mejora de pruebas, automatización y seguridad. El examen es electrónico y se realiza en un centro autorizado para su aplicación. No se permite el acceso con materiales al examen y el desarrollo del examen es monitoreado para garantizar la correcta aplicación del mismo. Consta de 40 preguntas de opción múltiple con un requerido de 70 por ciento de aprobación. Si todo es exitoso, el certificado llega por correo al domicilio. http://www.istqb.org

Ismael Villegas Ochoa PMP, CSM, CTFL; y Armando Márquez Espinoza, ambos son Maestros en Tecnologías de la Información con más de 20 años de experiencia en el área de Desarrollo de Sistemas en el sector financiero. Cuentan con amplia experiencia en la administración y desarrollo de proyectos de software. Actualmente desempeñan roles de arquitectos empresariales y administradores de proyectos tecnológicos.

SG.COM.MX

053

HARDWARE

2 1

AUDÍFONOS HYPERX CLOUD II

MOCHILAS SOLARES LUMOS

http://kingston.com/latam/hyperx

http://iwearlumos.com

Lumos es una empresa con raíces mexicanas que diseña y produce wearables enfocados a la conservación de la energía. Entre sus productos están las mochilas Thrillseeker y Unplug, que cuentan con páneles solares. Cuando la mochila está expuesta al sol, los paneles con capacidad de 3W generan electricidad que se almacena en una batería dentro de la mochila con capacidad de 4,000 mAh. Con esto puedes cargar o dar energía a tus electrónicos. Las mochilas están diseñadas principalmente para las necesidades de personas que se transportan en bicicleta, por lo que cuentan con reflectores y son impermeables. Pero aunque la bicicleta no sea lo tuyo, bien puedes aprovechar tu mochila Lumos para cargar tus gadgets mientras caminas y cuidas el planeta. La Unplug tiene un compartimento para laptops de hasta 15 pulgadas. La Thrillseeker es más pequeña y diseñada para quienes andan más ligeros.

Visto en @geek_mx La nueva generación de los audífonos Cloud de HyperX viene acompañada de control de audio con retro-iluminación LED y surround sound virtual 7.1 basado en hardware (no necesita controladores) con audio independiente y control de volumen del micrófono. Diseñados específicamente para gaming, los jugadores pueden cambiar fácilmente el surround sound virtual 7.1 con solo pulsar un botón para emular siete altavoces posicionales y mejorar la experiencia de juego. Están disponibles en colores rojo, metálico y la limitada edición color rosa (próximamente).

LENOVO THINKPAD X1 CARBON (2015)

http://lenovo.com/mx

STAR WARS MIMOPOWERTUBE http://mimoco.com

Visto en @geek_mx Manteniéndonos en la línea de baterías recargables, te presentamos los MimoPowerTube de Mimoco, basados en los personajes –y armas– del universo Star Wars. Los MimoPowerTube integran una batería recargable de 2600mAh que se puede cargar en tan solo unas 4 horas. Además de la batería, cada MimoPowerTube incluye una funda para guardar y cables para conexión USB, Apple Lightning y de 30 pin.

054

SG.47

Desde su primer generación lanzada hace poco más de 2 años, la Thinkpad X1 Carbon se ha ganado un lugar especial entre los usuarios que buscan una laptop con un alto nivel de portabilidad, poder y resistencia. Lenovo recientemente dio a conocer la tercera generación de la X1 Carbon, y definitivamente podemos decir que mantiene el estándar al que nos tienen acostumbrados con este modelo. Pesa 1.3 kg y tiene un grosor de menos de 18 mm. La configuración más económica viene con pantalla Full HD (no táctil), procesador Intel Core i5-5200U y disco duro de estado sólido de 128 GB, mientras que la configuración más completa tiene pantalla táctil WQHD+ (2,560 x 1,440), procesador i7-5600U y disco de estado sólido de 512 GB con tecnología PCIe que es hasta 80% más rápido que los discos SATA. El cuerpo de la X1 es de fibra de carbono de grado satelital (más fuerte que el utilizado en aviones) y está diseñada para soportar condiciones extremas de temperatura, humedad, polvo y golpes, así como el ocasional “se me cayó el café sobre el teclado”.

RELOJ FIBONACCI http://swgu.ru/px

Como buen lector de SG, seguramente te gustan las cosas que tengan estilo, requieran usar el cerebro y sean “hackeables”. Es por ello que te presentamos el reloj Fibonacci. Es un reloj de mesa que representa la hora por medio de cuadros organizados de acuerdo a la serie Fibonacci que se prenden de distintos colores para indicar horas y minutos. Recordaremos que los primeros números de la serie son 0, 1, 1, 2, 3, 5. Mapeando esto al diseño del reloj, tenemos dos cuadros pequeños, cada uno representando el valor 1, un siguiente cuadro cuyo lado mide el doble de los pequeños y por lo tanto representa el valor de 2, otro cuadro con valor de 3, y un último cuadro que vale 5. Para calcular la hora, sumas los cuadros rojos y azules, y para determinar los minutos sumas los cuadros verdes y azules y multiplicas por 5 (sí, este diseño sólo permite representar una fidelidad de 5 minutos). El reloj Fibonacci actualmente se encuentra como proyecto en Kickstarter y ha sido todo un éxito, rebasando por mucho su meta original. Se puede pedir en distintas ediciones: desde la DIY donde recibes el puro circuito y lista de partes para tú ensamblarlo, hasta la versión lista para usarse. El reloj utiliza un microcontrolador Atmega328 con Arduino y tiene un conector FTDI que permite reprogramarlo sin necesidad de quitarlo. El autor publicará como GPL los esquemas del circuito así como código fuente una vez que haya terminado los envíos. Este comic fue originalmente publicado en http://www.commitstrip.com/en/2015/04/29/what-is-not-said-in-coder-job-descriptions-you-still-need-to-master Fue traducido al español y compartido por Software Guru con el permiso del autor.

BIBLIOTECA

TEACH YOUR KIDS TO CODE: A PARENT FRIENDLY GUIDE TO PYTHON PROGRAMMING

Bryson Payne. No Starch Press, 2015.

Teach Your Kids to Code es el libro más reciente de No Starch Press, la editorial enfocada en libros técnicos para niños (y niñas, por supuesto). A diferencia de otros libros diseñados para autoestudio, Teach Your Kids to Code está pensado para leerse y usarse en colaboración entre un adulto y uno o más niños. El libro está lleno de ejemplos visuales y coloridos que ayudan a mantener la atención de los jóvenes programadores. Utiliza como referencia el lenguaje de programación Python, que es una buena elección como primer lenguaje. El espectro de temas abordados va desde la instalación del ambiente de programación hasta cómo crear un juego con gráficas animadas. Obviamente, en el inter se cubren temas como variables, funciones, ciclos, condiciones, operaciones matemáticas e interacción con el usuario. Teach Your Kids to Code parece ser el libro perfecto para sentarte este verano con tu hijo(a) y convivir un rato mientras aprende a programar. Consúltalo en http://swgu.ru/q1

LEAN ENTERPRISE: HOW HIGH PERFORMANCE ORGANIZATIONS INNOVATE AT SCALE

Por Jezz Humble, Joanne Molesky, y Barry O’Reilly. O’Reilly Media, 2014.

¿Qué tan bien responde tu organización a los cambios en las condiciones del mercado, las necesidades de tus clientes o tecnologías emergentes conforme desarrolla soluciones de software? Esta guía práctica presenta principios y patrones orientados a llevar a una organización entera a ser ágil. A través de casos de estudio se muestra cómo es que organizaciones exitosas han rediseñado todas sus áreas y procesos, desde finanzas hasta cultura organizacional y arquitectura de sistemas para poder mejorar su agilidad y desempeño. Lean Enterprise es el libro más reciente de la “Lean Series” curada por Eric Ries y que incluye obras como “Running Lean” de Ash Maurya y “Lean UX” de Jeff Gothelf. Expertos en la materia tienen muy buenos comentarios sobre esta obra. Por ejemplo, Mary Poppendieck comenta que “es un compendio de el mejor pensamiento moderno sobre cómo construir productos y servicios intensivos en software” y Gene Kim agrega que es “la versión moderna de ‘Rengineering The Corporation’ ... está destinado a ser la obra de autoridad sobre cómo las organizaciones planean, organizan e implementan su trabajo en la era digital.” Con ese tipo de porras, vale la pena agregar a Lean Enterprise a la lista de libros para leer próximamente. Consúltalo en http://swgu.ru/q2

056

SG.47