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
PAG. 14
—
NO.47 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: tenden-
cias de mCommerce, interés de los consumido-
res, gateways de pago, bitcoin, blockchain. Con
este reportaje tendrás una idea mucho más cla-
ra de cómo subirte a esta ola.
 CONTENIDO

INDUSTRIA PRÁCTICAS C COLUMNAS H HUMANOS

I Y EMPRESAS
P DESPUÉS DE TODO

¿Sabemos qué Necesitan los
Emprendedores? 010
HERRAMIENTAS Y
T TECNOLOGÍAS
OpenStack 012
— Mapas de Alta Resolución
WebRatio 013
—
Xamarin.Forms 014
F FUNDAMENTOS
Certificados Digitales 052
Contratación Basada Tendencias en Software 007 Carrera: Guía para certificarte
en Resultados 032 — como Tester 053
— Tejiendo Nuestra Red 008
Seguridad y Frameworks 036 —
— Código Innovare 031
A la Defensa de los Usuarios 038 —
O EN CADA
—
Sobre Nuestra Misión
Progamar es un
modo de vida 048 NÚMERO
como Testers 040
— Noticias y Eventos 005
—
con Drones 042 Radar 006
V VOCES —
Hardware 054
—
Los Bugs del Biblioteca 056
ESTRATEGIA
E DE TI
Testing en México 041
—
Más allá del Software 046
El Presupuesto de TICs 028 —
— Software
Planeación Estratégica 030 Defined Networking 050

EMPRENDIENDO
010
 O EDITORIAL

Renaciendo
cual fénix

La última vez que platicamos por medio de estas líneas era diciem-
bre 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, es-
tuvimos pensando en cómo queremos que sea Software Guru, y qué necesi-
tamos 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 ajustar-
se 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 for-
ma 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, sec-
ciones 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 licen-
ciados 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 O
Noticias

HACKMTY 2

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 pro-
yectos 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 hac-
MOBILE DAY 2015 1 kathons 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 apli-
caciones 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, estra-
tegias 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 3 SXSW INTERACTIVE 4

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 participa-
ción realizando un evento en el Centro de Cultura
Digital con conferencias y exhibición de proyectos.
Adicionalmente se contó con un programa de talle-
res prácticos realizados a lo largo de una semana en
los maker spaces de Hacedores y 330 ohms.
Imagen cortesía de hacedores.com
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 empre-
sas 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
 O RADAR

VISUAL STUDIO CODE 2

Y 2015

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

1 apps iOS y Android para Windows. Sin embargo, las

noticias que más interés generaron entre los desa-
rrolladores fueron las relacionadas con Visual Studio.
MACHINE LEARNING AL ALCANCE DE TODOS
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
En los últimos meses hemos visto gran movimiento dinámico en la oferta de servicios de de Windows, obviamente). Incluye muchas de las
Machine Learning en la nube. IBM fue de los primeros en entrar en este espacio con el ser- capacidades de Visual Studio como IntelliSense,
vicio de Watson Analytics. Microsoft anunció en febrero la disponibilidad oficial de Azure navegación y depuración de código, pero está dise-
Machine Learning (previamente disponible como beta). Un par de meses después Amazon ñado para operarse principalmente por medio del
Web Services comunicó su servicio Amazon Machine Learning. A esta lista hay que agre- teclado (ya que en estas plataformas estamos más
gar otras ofertas de proveedores de nicho como Prediction IO, así como la posibilidad de acostumbrados a teclear comandos que dar clic en
crear tu propio servicio de predicción directamente sobre Apache Spark o sobre una capa iconos u opciones de menú). VS Code es gratuito y
intermedia como Databricks Cloud. ya está disponible para descarga.

Cada uno de estos servicios tiene sus pros y contras. Por ejemplo, el servicio de Amazon Por su parte, Visual Studio 2015 (la versión “tradi-
es bastante sencillo de usar pero es muy limitado en cuanto a sus capacidades. En cambio, cional”) también ya está disponible como Release
Watson Analytics y Azure Machine Learning son mucho más poderosos pero involucran Candidate. Entre sus nuevas capacidades podemos
una mayor curva de aprendizaje. Esperamos próximamente poder preparar un comparativo encontrar mejoras al emulador Android, herramien-
entre estos servicios y compartirlo en estas páginas. tas para Docker, y soporte para Apache Cordova.

ANGULAR 2.0 VS. 1.X 4

JAVA 7 LLEGA AL 3 conocer los planes actualizados...
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 actualizacio-
nes 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 so-
porte comercial o utilizar otra máquina virtual que
mantenga soporte.
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
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 mante-
niendo 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 aho-
ra, 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.

006 SG.47

El Futuro del Software
CAMBIANDO LA FORMA DE VENDER Y MERCADEAR
—
Por Luis Daniel Soto Maldonado
El mercado de “Software empresarial” es enorme, se
estima en $317 billones de dólares anuales y tiene el ma-
yor crecimiento porcentual en inversión en Tecnologías
de Información [1]. La transformación del modelo “tradi-
cional” 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án-
dose. 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 re-
ducir 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 ad-
ministrar. 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 empre-
sarial, utilizarlo por hora y disponer de muchos de los pro-
veedores, en particular todos los de alta calidad que son eva-
luados por analistas como Gartner o Forrester.
En el “AWS Marketplace” es posible rentar un software de CRM
TENDENCIAS EN SOFTWARE C
“IDC anticipa que para el año 2018 el 50% de las cargas
de trabajo de software operarán en la nube pública”.
o uno especializado para administrar Wi-Fi sólo por unas horas,
usarlo en la nube y luego apagarlo permanentemente. Es posi-
ble 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 alre- dans / @luisdanielsoto)
dedor del mundo, a grandes compradores y recibir el pago en trabaja en Amazon Web
Estados Unidos mediante la plataforma de comercio electróni- Services, enfocado en el
co global, hacerse visible a más de un millón de clientes existen- desarrollo global de ne-
tes, eliminar los problemas de la distribución física del software. gocios para Big Data e
¿El fin del canal? Inteligencia de negocios.
Algunas empresas de software han invertido 5-10 años en crear sotols@amazon.com
una muy amplia red de canales. La nueva realidad es distinta: El
internet llega a los usuarios de negocio y estos van a poder ac-
ceder 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 agrega-
do, 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.
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
 C 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
profesora de la UNAM y
su objetivo principal es
generar conocimiento a
través de la creación y
promoción de estándares.
@hannaoktaba
008 SG.47
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 KUALI-
BEH incluido. En la sección 6 del documento se pueden apre-
ciar los reconocimientos para la UNAM y todas las organi-
zaciones y personas que nos han apoyado en esta aventura.
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.
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 organi-
zaciones, 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 expre-
sar 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 es-
pecífico del proyecto y a las necesidades de los involucrados.
Entonces ¿cómo se integró KUALI-BEH a la Esencia? En la en-
trega 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
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 objeti-
vo 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 particula-
res 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 do-
cumentació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 C

“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. Figura 3. Los estados de Method Authoring sub-alfa.

que les parezca más importante, para que em-
piecen a acumular conocimiento explícito com-
partido por la organización. Cuando tengan defi-
nidas 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ác-
ticas, 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
prácticas y métodos hay dos puntos que consi-
dero 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 pro-
pia organización.
2. El método bien formado (léase proceso)
no es un conjunto de prácticas cualquie-
ra, las prácticas tienen que aportar algo
al propósito del método (coherente), ser
suficientes para lograrlo (completo) y no
generar desperdicios en actividades o pro-
ductos innecesarios (consistente).
Conclusión
Este es el primer acercamiento a lo que propo-
ne KUALI-BEH como parte del nuevo estándar
de OMG Esencia. A los interesados les reco-
miendo revisar el Apéndice B para tener mayor
detalle. Con gusto recibo sus comentarios en
@hannaoktaba
—
Referencias
[1] ESSENCE: Kernel and Language for Software Engineer-
ing Methods 1.0. http://www.omg.org/spec/Essence/1.0

SG.COM.MX 009
 I 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 creci-
miento en grandes despachos.
Muchos ensayan esas frases trilladas que son
mitad resignación, mitad refugio. Que así so-
mos, que “puespaquésiyaves”, etc. Otros sim-
plemente se levantan y comienzan otro día de
mucho trabajo, paga insuficiente y pocas pro-
babilidades de éxito. Como ayer, como mañana.
Los emprendedores mexicanos, por necedad o
virtud, llevan años librando batallas que harían
renunciar a Sísifo. Con un sistema financiero au-
sente, 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”.
Como contrapartida, ese medio ácido no impide
que cada tanto escuchemos de grandes opera-
ciones, como la venta de SinDelantal.mx a Just
Eat, por más de 20 millones de dólares según
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
TechCrunch (tcrn.ch/1FS7Y1O), o la adquisición
de Aventones por BlaBlaCar.
Por supuesto que estamos lejos de las va-
luaciones “billonarias” de los Uber, Alibaba y
Facebook del mundo, pero que eso no nos opa-
que la perspectiva: tenemos un nivel más que
saludable de energía emprendedora que debe-
mos encauzar y favorecer para establecer éxi-
tos, repetirlos, exportarlos e inspirar a nuevas
generaciones a seguir este camino.
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.
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 factura-
ción logre cubrir los gastos?
Tenemos un grupo de emprendimientos que
pasan por más de una incubadora en sus ini-
cios, en una suerte de respirador artificial mien-
tras reúnen fuerzas para dar el salto a la reali-
dad. 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 cre-
cimiento 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 adminis-
tración profesional para sus activos. Una vez
dado ese paso, y más allá de alguna cuestión
sentimental sobre la empresa familiar, las inver-
siones se evalúan según su mérito propio y pro-
yectos atractivos pueden ser buen destino de
capitales que en otra época irían directo a bie-
nes 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 ig-
norá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 hacer-
le la vida fácil, porque pocas veces tanto futuro
depende de tan módica locura.
 T INFRAESTRUCTURA
Figura 1.
Arquitectura
de OpenStack
Todo como Servicio
con OpenStack
—
Por Miguel Ángel Barajas
Sin duda el cómputo en la nube está cambian-
do la forma en la que consumimos recursos de
cómputo. Nos estamos acostumbrando a consu-
mir 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ási-
camente rentamos una máquina virtual conec-
tada a la red y pagamos por el uso de proce-
samiento, 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, almacenamien-
to 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ís-
ticas 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
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
grandes conceptos: cómputo, almacenamiento
y red, que a su vez son soportados por varios
servicios compartidos.
Al momento de editar este artículo, está por libe-
rarse 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 servi-
cios (Ceilometer).
• Aprovisionamiento de clusters Map-
Reduce 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).
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 inte-
ractúan entre sí.
Aunque a primer vista se ve complicada, en
realidad no lo es tanto si nos abstraemos al ni-
vel de los distintos servicios (compute, stora-
ge, network, etc). Los programas mantienen su
información en una base de datos compartida.
La comunicación entre programas se realiza tí-
picamente por medio de APIs y es “stateless”.
La comunicación directa con el hardware o soft-
ware a controlar se hace mediante agentes y/o
plug-ins específicos del fabricante.
Distribuciones de OpenStack
OpenStack sufre del mismo “problema” que
GNU/Linux en cuanto a que la configura-
ción, empaquetado e instalación manual es
un compleja. Por ello, al igual que GNU/Linux
Openstack se distribuye de una manera em-
paquetada. Es así que los “sospechosos co-
munes” son los que han creado distribuciones
los cuales dan soporte y mantenimiento así
como compatibilidad con sus propias distribu-
ciones 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 automatiza-
do 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 aque-
llas 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.

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 necesi-
dades 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 organi-
zaciones 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.
¿Cómo funciona WebRatio?
WebRatio es una plataforma visual. El desarrollador diseña el modelo con-
ceptual 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 funcio-
namiento 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.
Ágil y segura, basada en estándares
WebRatio Platform se basa únicamente en estándares sin utilizar lengua-
jes 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 genera-
do con total libertad de manipularlo.
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.
CONTENIDO PATROCINADO
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 de-
finir 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
WebRatio permite no solo crear sistemas para responder a necesidades exis-
tentes, sino también construir soluciones innovadoras que ofrezcan nuevas po-
sibilidades. 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
WebRatio: la empresa
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.
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
 T 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 ter-
ceros. Para Windows Phone o Windows Store, si
somos desarrolladores de .NET no se nos com-
plica en lo absoluto, es muy parecido a lo que ya
sabemos desarrollar, sólo que con diferentes es-
tá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 utili-
zando Xamarin Studio. Adicionalmente se anun-
ció 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 ex-
plotar mejor los recursos de las diferentes pla-
taformas, 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 apli-
caciones para Android e iOS, por lo que si ha-
bía duda de qué tan fuerte está Xamarin en el
mercado, con los recientes anuncios por parte
de ambas compañías vemos una seria consoli-
dación en el mundo de desarrollo de aplicacio-
nes multiplataforma y se despeja la interrogante.
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, et-
cé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 plata-
formas, por lo que minimizamos tiempos de de-
sarrollo. Por ejemplo, tradicionalmente tenemos
que desarrollar la aplicación en Java para Android
y en Objective-C para iOS la misma funcionali-
dad, lo cual es tedioso y repetitivo, con Xamarin
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
podemos reutilizar el código en un 75-85% según
fuentes oficiales. Esto no quiere decir que no ten-
gamos 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 es-
tuvié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 posteriormen-
te publicar. Otro punto importante es que para
Android por ejemplo, si tenemos algunos com-
ponentes 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#.
Por ejemplo para Android, al construir el pro-
yecto nos generará el archivo .APK, el cual po-
dremos ejecutar en un emulador, en un disposi-
tivo o incluso en la tienda de google realizando
el proceso tradicional.
La figura 2 ilustra la arquitectura típica de una
aplicación Xamarin.
Figura 1. Arquitectura de aplicación Xamarin.
Lo que muestra la figura 1 es que tenemos un
proyecto o librería compartida que contiene
los componentes de las capas de negocio, ser-
vicios y datos. Por otro lado, tenemos distin-
tas aplicaciones para cada tipo de cliente, que
utilizan las librerías y componentes nativos de
la User Interface de cada plataforma. Las apli-
caciones cliente acceden al código compartido
para interactuar con las capas de negocio, ser-
vicios 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, dependien-
do del caso. Esto permite aprovechar los ele-
mentos 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 de-
finir interfaces de usuario para distintas pla-
taformas desde una misma base de código.
Xamarin.Forms está orientado a construir
aplicaciones con interfaces de usuario senci-
llas, 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 compo-
nentes 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
A continuación mostraremos cómo se construye
una aplicación con Xamarin.Forms. Por ahora solo

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, escribi-
mos “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 pro-
yectos SG.Android y SG.iOS vamos a escribir lo
requerido por cada plaforma. La figura 2 mues-
tra la estructura generada.
Figura 2. Estructura del proyecto.
En el proyecto SG tendremos el programa App.
cs cuyo código base se muestra en el listado 1.
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 necesa-
rios para que todo esto funcione.
Listado 1. App.cs
Listado 2. MainActivity.css
Listado 3. AppDelegate.cs
Si quisiéramos hacer una forma de captura, por
ejemplo un login con usuario/contraseña, inclui-
ríamos un código similar al del listado 4 en nues-
tro 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 for-
ma tanto en iOS como en Android. Nótese que
en cada caso se aplica automáticamente el estilo
default de la plataforma correspondiente.
Inyección de dependencia
Incluso en el proyecto Portable podemos espe-
cificar un comportamiento diferente para cada
TUTORIAL T
plataforma utilizando la directriz #ifdef. Por
ejemplo, un bloque con #ifdef __ANDROID__
solo se ejecutará en plataforma Android.
Listado 4. Forma de login.
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.
Listado 5. Consultar plataforma.
Una tercera forma es utilizar inyección de de-
pendencias. 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 nues-
tro caso), utilizando DependencyService de
Xamarin para instanciar las implementaciones
SG.COM.MX 015
 T TUTORIAL
o si se requiere algo mucho más robusto po-
demos utilizar Unity , TinyIOC, Autofac entre
otras que se pueden obtener desde Nuget.
Las principales clases candidatas a ser imple-
mentadas por medio de inyección de dependen-
cias 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, pre-
ferencias, creación y acceso a una base de datos
de SQLite, preferencias de la aplicación en el dis-
positivo, personalizar un control como un botón,
un grid, procesamiento de una imagen, etcétera.
DependencyService es el medio por el cual po-
demos resolver las interfaces cuya implementa-
ción se encuentra en cada plataforma. Al utilizar:
[assembly:Dependency(typeof( Clase))]
estamos indicando a .Net que esa clase podrá re-
solverse mediante DependencyService tomando
la implementación en la plataforma en ejecución.
A continuación mostraré un ejemplo para reali-
zar 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 6. Definición de interfaz.
Lo siguiente es codificar la implementación
puntual de esta funcionalidad en cada plata-
forma. El listado 7 contiene la implementación
para Android, y el listado 8 para iOS.
016 SG.47
Listado 7. Implementación para Android
Listado 8. Implementación para iOS
Teniendo estas implementaciones, basta con po-
ner desde nuestro código portable algo como:
var language = DependencyService.Get<ILocale>().
GetCurrent();
Personalización de controles
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 vere-
mos un ejemplo donde personalizamos un con-
trol para cada plataforma.
En nuestro proyecto portable definimos un
CustomEntry de la siguiente forma:
public class CustomEntry: Entry { }
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 di-
ferencias irreconciliables entre
plataformas por la forma en que
procesan sus datos y la arquitec-
tura, por lo que es necesario que
en funcionalidades como estas
desarrollemos el código específi-
co para la plataforma.
Estilos
Podemos definir estilos que de-
terminen 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 pla-
taforma así que sólo se fija una vez en nuestro
proyecto portable.
Entonces cuando creamos un objeto Label, pode-
mos 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 aplicacio-
nes 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 comporta-
miento 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 domici-
lio, 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 parti-
cipantes indicaron ya estar comprando despen-
sa vía internet para entrega a domicilio, y 55%
indicó estar interesados en hacerlo próxima-
mente. 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 consu-
midores 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] ge-
nerado a partir de los resultados de la encuesta,
muestra cómo los consumidores utilizan la tec-
nologí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
Figura 1. Supermercado virtual en Seúl.
ya están activas en línea, y por lo tanto no es re-
presentativo 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
tienen capacidad de compra. Estos consumido-
res 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?
En México, aunque son todavía pocas las empre-
sas 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 espe-
cialidad, 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 pro-
ductores 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 ma-
zapanes de alga spirulina). Mi Alacena es otro
nuevo startup, que busca permitirte comprar
productos y alimentos que no hay en tu ciudad y

020 SG.47

Figura 2. Hábitos de compra en internet por generación.
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 ha-
ciendo 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) segui-
rán predominando, al menos en un futuro cer-
cano. Además del beneficio obvio que ofrecen
de poder obtener un producto inmediatamente
y sin costos de envío, hay experiencias senso-
riales 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 par-
ticipantes en el estudio de Nielsen previamente
mencionado, consideraron que ir al supermer-
cado es una experiencia grata.
Así que las tiendas de autoservicio deben bus-
car cómo aprovechar la tecnología para asegu-
rarse de que la experiencia del consumidor sea
grata, eficiente y asegure su retención.
Pedro Galván es cofundador y director editorial de SG Software Guru.
Figura 3. Uso e intención de digitalizar experiencia en tienda.
Imagina un supermercado en el que al momen-
to 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 as-
pecto de la transformación digital del autoservi-
cio. 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 den-
tro y fuera de las tiendas, y los consumidores
crecientemente utilizan tecnología para simpli-
ficar 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 auto-
servicio tienen mucho camino que recorrer para
cubrir aspectos básicos de habilitación digital
tales como cupones móviles, apps para listas
EN PORTADA P
de compra, y Wi-Fi. Actualmente, sólo un pe-
queño porcentaje de consumidores en el mun-
do 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 simi-
lar, con un 15% de uso actual y un 64% de in-
tenció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 in-
teré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 don-
de estas capacidades están más instaladas y
los consumidores tienen mayor disposición a
utilizarlas. En Latinoamérica, aunque el uso ac-
tual es bajo, hay bastante entusiasmo por ha-
cerlo 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
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 bre-
ve análisis de los gateways disponibles en nues-
tra 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 relativa-
mente altas (4% + $4 pesos por cargos a tarje-
tas de crédito) además de que ofrece las meno-
res 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 canti-
dad de medios de pago como tarjetas de crédito
y débito Visa y Mastercard nacionales e inter-
nacionales, American Express, pago en tiendas
Oxxo, y transferencia bancaria por SPEI. Las co-
misiones 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ísti-
cas, comisiones y hasta librerías son muy simi-
lares a las de Conekta. Podríamos decir que son
como gemelos pero nacidos de distintas ma-
dres. 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 len-
guajes que soporta, además de que su docu-
mentación técnica está muy bien organizada.
http://www.openpay.mx
022 SG.47
Compropago. Solamente soporta pago por me-
dio 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 tam-
bié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 protoco-
lo Ripple, el cual está diseñado especialmente
para la interacción entre instituciones financie-
ras. 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 comer-
cio electrónico). Mercado Pago tiene presencia
en varios países de nuestra región. Las comisio-
nes 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 in-
ternacional, 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 pro-
veen un lector de tarjeta tales como iZettle, Clip,
o Pago Facil, porque a pesar de que algunos ofre-
cen APIs que se pueden usar como gateway, en
realidad están más enfocados a usarse como so-
lució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 sur-
gido 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 lo-
cales que están haciendo un excelente trabajo.
Esperamos que esto comience a rendir frutos
pronto, mejorando el comercio digital en nues-
tra región e impactando positivamente las eco-
nomías de nuestros países.
Agradezco a Eugenio Perea y Fernando Ramos
por la información provista para el desarrollo de
este artículo.

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 consoli-
darse 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 apli-
caciones que han sido habilitadas
con la capacidad de hacer “com-
pra-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 me-
diante sistemas de banca móvil.
Desafortunadamente la cantidad
de teléfonos inteligentes conec-
tados a internet, así como la pe-
netració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 financie-
ros en México.
Otra limitante son los montos de
transacción, debido a los altos
costos en el uso de estos servi-
cios, 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.
Pero hay una nueva tecnología
que podría cambiar esta realidad
en el futuro cercano, BlockChain
y Bitcoin permiten hacer estas
Joel Cano es Director de Operaciones en meXBT, empresa especializada en negocios con criptomonedas.
mismas transacciones de una ma-
nera completamente digital, elimi-
nando intermediarios y para tran-
sacciones 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úbli-
co, la mensualidad de un auto o in-
cluso el auto completo con la misma
forma de moneda.
La billetera funciona en el teléfo-
no inteligente y conectada a un
Exchange puede hacer transac-
ciones 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 direc-
ció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 posi-
ble 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 .
Tambien se pueden enviar los
bitcoins a un cajero que tenga la
opción de dinero móvil y sin necesi-
dad de una cuenta bancaria retirar
Figura 1. Inversión en bitcoin.
efectivo con una solución llamada
sendbitcoin.mx mediante el envio
de una cuenta instantánea a teléfo-
no celular y con un código de segu-
ridad de cuatro caracteres realizar
la operación de manera segura.
Otras tecnologías que ya están
disponibles son por ejemplo “SIM-
cards” que habilitan un telefóno
celular tradicional o inteligente
como una billetera con bitsim.co;
y si se están desarrollando apli-
caciones móviles para teléfonos
inteligentes y se desea integrar-
les opciones de pago seguras, se
puede lograr mediante bitcoin en
rivetz.com
Estas son solo algunas de las posi-
bilidades de conectar los móviles
con bitcoin y el blockchain. La ver-
dadera movilidad en el comercio
ahora es una realidad.
La inversión de capital empren-
dedor 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 poten-
cial que los inversionistas ven hoy
EN PORTADA P
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).
En México meXBT está impulsan-
do 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 perso-
nas que necesitan mover dólares
americanos a pesos mexicanos.
También está impulsando solucio-
nes que puedan convertir los pagos
entre empresas pequeñas y media-
nas al extranjero para que más fá-
cilmente puedan integrarse en las
cadenas productivas globales y que
los pagos para la importación y ex-
portació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.
El futuro de los pagos y transferen-
cias de dinero y valores mediante
estas nuevas tecnologías está ape-
nas empezando.
SG.COM.MX 023
 EL BLOCKCHAIN
Y SUS APLICACIONES
Por Pedro Galván
Hoy en día, una conversación sobre tenden-
cias 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 susten-
ta 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 ciuda-
dana. El artículo “Block chain 2.0: The renais-
sance of money” publicado por Wired en enero
de este año lo plantea así [2]:
“Bitcoin, altcoin, dodgecoin … ¿a quién le im-
portan? 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 li-
bro mayor de contabilidad (ledger).
Blockchain es administrado por la red de no-
dos del sistema bitcoin. Dichos nodos están
continuamente difundiendo transacciones
del tipo: el emisor X envía Y bitcoins al recep-
tor 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 mi-
nutos 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 en-
cuentra cada día se mantiene constante.
El algoritmo blockchain fue inventado específi-
camente para el sistema Bitcoin, pero se puede
aplicar en cualquier otro caso donde se requiera
establecer un consenso distribuido en presen-
cia 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 blo-
que inicial (génesis) hasta el bloque más recien-
te. 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 nue-
vo 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 subse-
cuentes 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 compu-
tacionalmente 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 efecti-
va 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 cier-
to activo. Esto es lo que se conoce como monedas
coloreadas (colored coins), y es un mecanismo que
permite utilizar el blockchain para almacenar y ges-
tionar 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 colo-
rear monedas que representen acciones y repar-
tirlas 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 colo-
rear monedas, es decir crear activos digitales
sobre la red bitcoin. No me sorprendería que al-
gú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 block-
chain es el de contratos inteligentes. Esto consiste
en crear programas que pueden manejar dinero
automáticamente. Al crear un contrato se defi-
nen ciertas condiciones o criterios que se deben
cumplir, y las acciones (transacciones) que se

disparan cuando se cumplen los criterios. Cuando
se realiza una transacción entre dos partes, el pro-
grama 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 adminis-
tren contratos, criptomonedas u otros activos.
Otro proyecto que busca establecer una pla-
taforma para aplicaciones descentralizadas es
Ethereum [5], el cual involucra una nueva crip-
tomoneda, 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 propie-
dad intelectual.
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 re-
gistran sus obras en un sistema de registro de
propiedad intelectual distribuido que es públi-
camente 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.
El fundador de ascribe comentó recientemen-
te en un artículo publicado en Forbes [7] que
un acercamiento similar también sería muy útil
EN PORTADA P
para gestionar los derechos de otras obras ar-
tísticas, como la música o las películas, permi-
tiendo 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 moni-
torear por medio del blockchain las formas en
las que la disquera explota tus obras (ventas, li-
cencias, 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 automa-
tizado (machine learning), en el que las computa-
doras pueden actuar sin necesidad de ser progra-
madas 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 cade-
na alternativa del blockchain, la wiki de Bitcoin [8]
tiene buena información al respecto.
Nota sobre nomenclatura. La documentación origi-
nal 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.
—
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.
[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-prepare-
growth-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 com-
merce está cobrando relevancia, y las empre-
sas que lo ignoren perderán una gran oportu-
nidad de negocio.

Aquellas empresas que quieran aprovechar

esta oportunidad, deben hacerse las siguien-
tes 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 per-
sonas, 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, marke-
ting 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 digi-
tal que considere un amplio crecimiento en el
comercio móvil.
A continuación comparto con usted cinco re-
comendaciones 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óvi-
les? ¿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 com-
portamiento de tus clientes móviles con la lle-
gada de servicios como Apple Pay?
3. Adapte sus procesos de comercio móvil de
acuerdo al comportamiento del cliente. No in-
tentar obligar al cliente a cambiar sus hábitos y
forma de usar su dispositivo móvil para poder in-
teractuar 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ísti-
cas y ofertas que les ahorren tiempo y dinero.
Por ejemplo, si su empresa tiene una app para
compras online donde el cliente tiene la op-
ción de pasar a una tienda a recoger su pedi-
do, entonces aproveche la app para facilitar y
agilizar el proceso de recolección. Otro ejem-
plo 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 caracte-
rísticas creativas y visualmente atractivas,
como por ejemplo poder compartir fotos de
productos. Sin embargo, las tácticas que ge-
neran mayor uso son aquellas que también
proveen información o acciones útiles para
los usuarios, como por ejemplo poder cono-
cer la disponibilidad de cierto producto en
una tienda cercana.
El comercio móvil impactará la forma en que in-
teractuamos con nuestros clientes y representa
una gran oportunidad para crecer nuestro nego-
cio. ¿Cómo se está preparando su organización
para el crecimiento en el comercio móvil?

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

026 SG.47
 EN PORTADA P

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 dimensio-
nar la diversidad y complejidad de este todavía naciente ecosistema.
La primer figura, creada por Trinity Ventures, es un mapa de los principa-
les jugadores en el ecosistema de mCommerce, agrupados por categoría.
La segunda figura, creada por Pymnts.com es un mapa del metro que re-
presenta los distintos conceptos que sustentan la cartera digital, agrupa-
dos como rutas. Este mapa fue hecho en 2013 y le hace falta una actua-
lizació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
 E 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 cuanti-
ficación de cómo las TIC contribuyen a obte-
ner 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 presupues-
tales, no están familiarizadas con la compleji-
dad real de utilizar la tecnología. Así que usual-
mente 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 informa-
ción y comunicaciones?, pues que es muy fácil
cuantificar cuánto se gasta en ellas, pero es di-
fícil cuantificar la contribución desde un punto
de vista financiero.
A continuación ahondo en los principales facto-
res que inciden en esta situación:
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
Baja madurez de procesos
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 ope-
rativos y financieros.
Se diluye el beneficio
Se deja de cuantificar como un beneficio el im-
pacto 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 du-
rante 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 rea-
lizar 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 contem-
plar 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 mante-
nimiento esperado, sino que además, es posible
que el sistema deba de sobrevivir a la obsoles-
cencia del hardware y software de plataforma.
Complejidad de integración
Las soluciones tecnológicas empresariales típi-
camente 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 imposi-
bles de prever.
Los costos ocultos
Usualmente se privilegia el resultado inmedia-
to 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 agrega-
do externo.
Debido a que el mantenimiento típicamente
es urgente, circunscrito a requisitos especí-
ficos, muchas veces etiquetados como “tem-
porales”, 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 re-
diseñ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 acos-
tumbran 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 tec-
nologías que están casi extintas.

Justificar el presupuesto
de tecnología
Aunque al justificar el gasto en tecnología de-
bemos 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 si-
guientes 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 siste-
ma 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, apli-
cando 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 utiliza-
ron para implementar el sistema original.
La tabla 1 refleja el ejercicio de planeación a 8
años con los supuestos anteriores.
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 du-
ros para que todas las partes interesadas: CEO,
COO, CFO, CIO y demás, puedan tener una vi-
sión compartida.
Autoevaluación
Hagamos ahora un ejercicio de autoevaluación
contestando el siguiente cuestionario y suman-
do los puntos que obtenemos en cada respuesta.
1. ¿En su organización se planea el presupues-
to de TICs?
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 pre-
supuesto (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
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 planea-
ción de TI, se trabaja de forma reactiva.
Conclusiones
• Entre mayor es el aprovechamiento de las
TICs, mayor es el gasto que se deberá desti-
nar a ellas.
• Es útil compartir el costo total de propiedad pre-
visto, para tener bases útiles para entenderse con
ESTRATEGIA DE TI E
las demás partes interesadas en el aspecto finan-
ciero, 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 fundamen-
tal 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 re-
quiere hacer X desembolsos. Pero más impor-
tante, 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 requie-
re de una inversión significativa. Si solamente
justificamos decisiones de TI en base a ahorros,
nuestra organización perderá oportunidades im-
portantes 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 organiza-
ciones 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 únicamen-
te 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
 E 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 momen-
to 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 pro-
ceso 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 organiza-
ciones tenemos un entendimiento distorsiona-
do tanto de lo que es planeación como de lo
que es estratégico, y en algunas ocasiones sor-
prendentemente hasta de lo que son las TIC.
¿Realmente hacemos
planeación tecnológica?
Como mexicanos tenemos un reto cultural-
mente hablando, pues no somos precisamente
proclives a planear, justificando en muchas oca-
siones 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 ela-
boradas 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 pro-
ceso formal de levantamiento de requerimientos
que estén debidamente justificados en cuanto a
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
beneficios cualitativos y cuantitativos en térmi-
nos de negocio. Incluso tratándose de proyec-
tos regulatorios, tendríamos que ser capaces
de justificarlos en función de evitar las multas
o sanciones económicas o evitar daño reputa-
cional a la compañía. Planear también implica
ser capaces de tener identificados los recursos
requeridos en aspectos de infraestructura, licen-
ciamiento, 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 respon-
sables 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 dis-
creción del solicitante, máxime cuando el so-
licitante está del lado del negocio. Estratégico
no sólo es aquello que requiere grandes can-
tidades de recursos o que provenga de la alta
dirección. Estratégico debe ser aquello de alto
impacto —en función del negocio— y con-
secuentemente 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 pla-
neación estratégica no debe realizarse en ais-
lamiento. 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 co-
munican 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 mone-
da, 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 no-
sotros 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 pro-
yectos tecnológicos de alto impacto y largo pla-
zo que hagan correspondencia con las respecti-
vas iniciativas estratégicas de negocio.
Llevar a cabo un ejercicio de planeación estra-
té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 iniciati-
vas 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 pre-
sentado, 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 or-
ganizació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.
 CÓDIGO INNOVARE C

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 di-
gital 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 estra-
tégico para cualquier empresa y por lo tanto deben ser pla-
neados 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 so-
cial. Por tanto cuando se plantea una estrategia de marketing
que incluye redes sociales, se dará un paso hacia la planifi-
cación promocional multicanal, que además permitirá reali-
zar 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 re-
des 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 conside-
rar 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 Gabriela Campos Torres
se acaba convirtiendo en basura para los usuarios. es Community Manager
• Falta de escucha y de personalización, sin proporcionar de SemanticWebBuilder
a los clientes potenciales la información que quieren y en la Gerencia de
buscan. Desarrollo de Nuevos
• No fomentar las relaciones con la comunidad, sin man- Productos y Servicios de
tener ningún tipo de conversación con ellos, sin respon- INFOTEC. Es Licenciada
der a sus comentarios o sin darles las gracias por sus en Ciencias de la
aportaciones. Comunicación por el Tec
• No desarrollar un plan de crisis, alineado con el plan gene- de Monterrey. Cuenta
ral de crisis de la empresa. con amplia experiencia
• No analizar qué están haciendo las empresas de la compe- en la ejecución de pro-
tencia en redes sociales. yectos relacionados con
• No monitorear y escuchar lo que se dice de la marca y del la adopción de implan-
sector al que pertenece. taciones tecnológicas y
• No actualizar la estrategia de redes sociales, de acuerdo a cambios culturales.
las necesidades existentes.
Conclusión
En definitiva, las redes sociales se han convertido en un me-
dio muy útil para la redefinición y crecimiento de negocios
siempre y cuando se tome en cuenta la inversión y los resul-
tados que se obtendrán. Y en este sentido los dispositivos
móviles son cada vez más importantes entre los consumi-
dores, 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 elemen-
tos 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 desa-
rrollo 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 subje-
tiva para la generación de métricas e indicadores especia-
lizados de cualquier industria. Este conjunto de atribucio-
nes 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 indus-
tria TIC en México.

SG.COM.MX 031
 P 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 afec-
tado 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 soft-
ware, 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 can-
tidad de trabajo que requiere, el perfil y la cantidad de profesionales mo-
vilizados 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 eco-
nó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 es-
tablecido 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 incremen-
to 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 clien-
te 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 remunera-
ció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 res-
ponsabilidades de cada empresa y exigir la garantía. El cliente paga
por un servicio y también por cualquier mantenimiento posterior co-
rrectivo 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 defi-
nidos 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á difi-
cultades 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 insufi-
ciente y la calidad del producto se vea seriamente afectada o incluso el
proyecto no se pueda completar.

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 ori-
ginal, ya que dependiendo en qué fased el proyecto esté, no hay compe-
tencia, 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 traba-
jo, 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 for-
mas 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 de-
berí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 res-
ponsabilidad del cliente, impacta este modelo de contrato.
SOURCING P
“Un modelo de contratación óptimo sería la
remuneración de acuerdo con las unidades de
resultado del servicio realizado”.
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 pro-
veedor, ya que existe un riesgo de lesiones si hay retraso en las unida-
des 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 recono-
cida 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, we-
bservices, puntos de función, entre otros. Pero no todas estas unidades
cumplen con los criterios para ser reconocidos por el cliente y el provee-
dor de forma consistente.
Al analizar las unidades de carácter más técnico, no se tiene en cuenta la vi-
sibilidad 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 tie-
nen 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
 P 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.
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 ex-
presado 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 es-
timado (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 implemen-
tados. 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 esta-
blecer 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
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 con-
trato, 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.
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 clien-
te ejerce el control efectivo y la gestión de contratación. El perfil de los profe-
sionales 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 realiza-
do. Este modelo utiliza como base el precio medio (o promedio de produc-
tividad) para la derivación del costo. Dado que hay una buena definición
de los parámetros de precios, estas variaciones entre los proyectos tien-
den 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

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 funcio-
nalidades 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 ingre-
sos. 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.
Como también hay interés por parte del proveedor para entregar un ser-
vicio 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 embar-
go, 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, aun-
que 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.
Dificultades comunes
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
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, esti-
mació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.
SOURCING P
“Para los contratos basados en los puntos
de función, el fraude es fácilmente detectado
por la auditoría”.
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 cos-
tos de otras organizaciones, sin la calibración necesaria de sus paráme-
tros 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 res-
cindir el contrato.
Una dificultad más está relacionada con las mediciones, que deben cen-
trarse exclusivamente en las necesidades del negocio. Para aquellos que
están involucrados en la implementación, es común que haya una dificul-
tad en la abstracción de la implementación y esto se refleja en una medi-
ción a menudo incorrecta (y por lo general, más grande).
Conclusión
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 entre-
gados 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
[5] NESMA. http://nesma.org
[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
SG.COM.MX 035
 P 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 ex-
perto 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 pue-
de 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 importan-
te para las organizaciones. Sin embargo, pocos arquitectos abordan este
atributo de calidad de manera estratégica. Los arquitectos y desarrolla-
dores frecuentemente ponen un énfasis mayor en satisfacer los reque- Figura 1. Categorización de tácticas de seguridad.
rimientos 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 as-
pectos 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 ini-
cial 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 des-
critos 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 enfo-
que de no adopción.
• Sistema 2. Un portal web desarrollado usando HTML y JSP. En un prin-
cipio 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”.
• Sistema 3. Una aplicación interna programada en Java por una empre-
sa 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 he-
rramienta genera un reporte de resultados indicando la cantidad de vul-
nerabilidades identificadas, agrupadas por severidad. El análisis se enfocó
únicamente en los aspectos de software, por lo que se deshabilitó hard-
ware 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 en-
trevistas 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 distin-
tos 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.

036 SG.47

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 ex-
ternos. Podemos observar una relación entre el esfuerzo que estimaron
los arquitectos para satisfacer aspectos de seguridad y el número de tác-
ticas 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 vulne-
rabilidades 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 im-
plementó la mayor cantidad de tácticas.
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 reco-
mendació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 satis-
facer 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 fra-
meworks, y la necesidad de mantener actualizados los frameworks para
estar al día respecto a las nuevas amenazas que aparecen con el tiempo.
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.
ARQUITECTURA P
“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”.
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 sis-
tema, conviene tomar el catálogo de tácticas mostrado en la figura 1 a
manera de checklist para asegurarnos que estamos cubriendo las distin-
tas 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 primor-
dial como parte del diseño de la arquitectura. El considerar la seguri-
dad desde el principio y usar frameworks para soportarla puede dar
excelentes resultados.
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 con-
tactarme 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 segu-
ridad (en constante evolución).
—
Referencias
[1] Bass, Clements y Kazman, “Software Architecture in Practice”, 3a Edición, Addison-
Wesley Professional, 2012.
SG.COM.MX 037
 P UX
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 in-
mediata. Dedicamos poco tiempo a entender lo que necesitamos para
lograr nuestros objetivos. La lógica nos dice que si actuamos rápido ob-
tendremos 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ís-
ticas 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 con-
tradicció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-traba-
jo se puede evitar si entendemos lo que los usuarios realmente necesitan,
si apreciamos cómo piensan y viven. Actuando de esta manera podre-
mos 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 mar-
co 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 usua-
rios. 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 com-
portamiento, 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 bus-
can 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 de-
signer, sino de todos los involucrados en el ciclo de desarrollo del produc-
to. 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 inmensa-
mente 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 sie-
te 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 princi-
pios 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 inte-
ractú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 pue-
dan 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ón-
de invertir tus recursos. Kano también permite determinar cuáles son
esas features claves que lograrán diferenciar tu producto de la compe-
tencia. 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 herra-
mienta de investigación muy poderosa para sintetizar y modelar comple-
jos 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 opor-
tunidad 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 herra-
mientas, 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 co-
laborativas. Este enfoque considera que las personas son los verdaderos
expertos ya que poseen un conocimiento más amplio de sus propios esti-
los 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 par-
ticulares. 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.
Cambiando el mundo desde el escritorio
Los UX Designers y la industria de desarrollo de software en general tie-
nen 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.
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.
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.
UX P
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 investiga-
ció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 usua-
rios 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.
http://www.nngroup.com/articles/ux-without-user-research
[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
[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
SG.COM.MX 039
 P 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 apor-
te 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, perfor-
mance, 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é mo-
mento del proyecto / ciclo de vida del producto, con qué restricciones y
recursos, con qué objetivos.
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 encon-
tramos en algunos proyectos y una posible fuente de malentendidos o
conflictos entre los integrantes de un equipo de proyecto.
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
—
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 tene-
mos 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 (pue-
den 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 co-
municació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 cali-
dad, 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.
—
Referencias
[1] J. Bach. “Question: Tester’s Freedom of Thought”.
http://www.satisfice.com/blog/archives/61

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 com-
partió un interesante artículo sobre las retrospectivas y ten-
dencias 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 for-
mularnos 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.
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 creci-
miento se vuelve fundamental que los que estamos involu-
crados seamos evangelistas y no sólo creyentes. El reto ya no
es poder aterrizar al testing, es ser autocríticos y perfeccio-
nar lo que ahora realizamos para lograr mejores resultados.
Sobre todo, sabiendo que nuestro país ha dado pasos impor-
tantes 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 co-
rregir 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 per-
cepción de que para dedicarse al testing no se requieren co-
nocimientos y aptitudes específicas y por lo tanto cualquie-
ra 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
VOCES V
técnicas rudimentarias que están poco dispuestos a dejar, Carlos González cuen-
mientras que los integrantes jóvenes tienen una forma- ta con experiencia en la
ción poco robusta (consecuencia de lo que comento en implementación de pro-
el punto anterior). Básicamente, el grueso de nuestros cesos y metodologías de
testers aprendió a trabajar en base a sentido común y sus prueba, certificado por el
necesidades específicas, es decir que solamente cuentan ISTQB y conferencista en
con una formación empírica. Entre otras cosas, esto pro- SGCE 2014. Creador de la
voca discrepancia en la forma de trabajar entre distintos iniciativa Latin American
testers. Un ejemplo de ello es la gran diferencia que suele Software Testing (http://
existir al diseñar casos de prueba, lo que provoca proble- testingla.com) la cual
mas de entendimiento; genera retrabajo, falsas estimacio- busca establecer crite-
nes, y retrasos en la ejecución. rios sólidos para el de-
sarrollo y madurez del
Matando a la hormiga, no al hormiguero testing en Latinoamérica.
Los perfiles formados en testing “a prueba y error”, la rea- Actualmente se desem-
lización de tareas rutinarias y una cultura de corregir en peña como Tester en
lugar de prevenir repercuten en nuestros procesos actuales MTP México.
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 preven-
ción de defectos.
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 tes-
ting, 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 in-
geniero de pruebas o a todo un equipo, y cómo van a sopor-
tar 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, de-
finan requerimientos, etc.?
• ¿Qué aspectos probaremos y qué prioridad daremos a cada
uno? ¿funcionalidad?, ¿desempeño?, ¿seguridad?
SG.COM.MX 041
 P 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 dro-

nes, 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 digita-
les. Tradicionalmente, estos mapas se han generado utilizando avionetas,
globos aeroestáticos, y satélites. Sin embargo, hoy en día es perfectamen-
te factible hacer esto con drones, con un costo mucho menor que las op-
ciones anteriores.

Componentes de un dron
Antes de entrar en detalle, es importante dar a conocer cómo está cons-
truido 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 (posicio-
namiento, 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 au-
tónomos a través de coordenadas geo-referenciadas vía GPS. Las imáge-
nes 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 utili-
zando 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 mues-
tra en el recuadro.
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 in-
terrupció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 di-
señ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.

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 mo-
delo 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.
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 mi-
nutos por cada carga), la zona de vuelo que consta de un perímetro aproxi-
mado 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.

042 SG.47
 MAKER ZONE P

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. Figura 3. Monitoreo de captura de datos en vivo.

Los recuadros morados de la figura 2 muestran el nivel de traslape espera-

do 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 procesa-
miento para ser generados. En estas aplicaciones, 80% se considera un
buen porcentaje de traslape en las imágenes.
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 or-
tomapa 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 re-
lació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 tridimen-

sional 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-refe-
renciada 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 condicio-
nes 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 procesa-
miento en el que analizó cada pixel de cada una de las imágenes captu-
radas en el cual encuentra similitudes y continuidades; con ello, la apli-
cació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
 P MAKER ZONE
Figura 5. Nivel de traslape de imágenes.
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 captura-
das. 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.
De manera general, el porcentaje de traslape obtenido fue lo suficientemen-
te 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 he-
rramienta el modelo tridimensional, el cual, añade volumen a los obje-
tos de la ortoimagen. Este modelo puede ser exportado y utilizado en
cualquier otra herramienta para manipulación de imágenes tridimen-
sionales. 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.
Conclusiones
Al tener una imagen geo-referenciada y un modelo tridimensional a esca-
la, es posible utilizar estos modelos para diferentes propósitos. Por ejem-
plo, en la construcción y arquitectura, estas imágenes pueden ser impor-
tadas 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
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
Figura 6. Ortoimagen final.
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].
Por otro lado, para tener una mayor precisión en la generación de un mo-
delo tridimensional y en una ortoimagen, es importante recalcar la im-
portancia 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 mo-
delos 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 nue-
vos negocios en estos momentos.
—
Referencias
[1] Orto-imagen del parque.
https://mangomap.com/maps/34662/Mapa-Parque-Navojoa
[2] Modelo tridimensional del parque. http://goo.gl/3oCgta
[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

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 reco-
mendaron un artículo del blog de Santiago L. Valderrama [1] donde co-
menta 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?
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”.
Concuerdo con Santiago, y justamente es el espíritu de esta nueva sec-
ción en SG.
Para poder evaluar si alguien sabe programar o no, Santiago plantea un
reto con 5 problemas, indicando que un verdadero “ingeniero de soft-
ware” debería ser capaz de resolverlos en 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.
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.
4. Escribe una función, que dada una lista de enteros no negativos, los or-
ganice 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.
ALGORITMIA P
—
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 ejem-
plo: 1+2+34-5+67-8+9=100. Entonces, escribe un programa que encuen-
tre 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.
En las referencias de este artículo encontrarás enlaces a ejemplos de solu-
ció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 consul-
tes la solución hasta que hayas terminado o te hayas rendido.
En futuras entregas de esta sección encontrarás artículos donde revisare-
mos problemas de programación y estrategias para resolverlos.
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
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.
—
Referencias
[1] S. Valderrama. “Five Programming problems every Software Engineer should be able
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
 V 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 de
Productos en INFOTEC.
Desde 2003 colabo-
ra en INFOTEC en el
equipo de Desarrollo
de Nuevos Productos y
Servicios. Fue creador y
Coordinador del área de
servicios a producto y su
normatividad. Es además
coordinador del progra-
ma 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 servi-
cios 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 pla-
zos y tasas de interés considerables, por lo que muchas per-
sonas 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 cabe-
za 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 financiamien-
to 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 proyec-
to, es el modelo de negocio que decidas adoptar. En lo per-
sonal 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
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 cons-
tantes 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 segmen-
tar mercados puede ser una buena opción.
• Disponer canales de comunicación directa y bidireccio-
nal 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 respal-
dar al mismo, y es importante considerar que aunque no se libe-
ren todos al mismo tiempo o en la magnitud deseada al momen-
to del lanzamiento, sí deben incluirse los más representativos y
en consecuencia, se deberá contar con el suficiente personal ca-
pacitado 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 clien-
te y que por tanto, el entender debidamente las actividades
que éste realiza, así como su experiencia con nuestro pro-
ducto (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.

046 SG.47
 C 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 en-
cuentro con más abstracciones. ¡Me siento perdido! ¿Dónde quedó la simple realidad del cómputo que teníamos antes?

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
Gunnar Wolf es a profundidad podía un niño de los ochenta conocer a una
administrador de sis- magnífica Commodore 64, e incluso cuánto puede haber
temas para el Instituto aprendido con una PC. Recuerdo largas horas de leer docu-
de Investigaciones mentación, modificar binarios a mano con un editor hexade-
Económicas de la cimal para cambiar las cadenas que presentaban al usuario,
UNAM y desarrollador buscando comprender todo lo que veía —simplemente, por-
en el proyecto Debian que era posible hacerlo.
GNU/Linux.
http://gwolf.org Con el tiempo, el mundo ha ido cambiando. Y yo también.
Al volverme un miembro útil a la sociedad, como les ha-
brá pasado a ustedes también, fui eligiendo mi nicho eco-
ló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 precisamen-
te 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 apli-
caciones 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 ob-
jetos. Configuración por convención. Muchas muy buenas
prácticas de desarrollo, y un marco de desarrollo con opinio-
nes 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 desen-
cantos. 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 com-
patibles hacia atrás, y buena parte de mi código histórico iba
emitiendo advertencias por usos desaconsejados — O rom-
pié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 relativa-
mente simple. Un sistema que ya está en producción no re-
quiere ser actualizado. El programador puede congelar el sis-
tema base y las gemas (bibliotecas) que emplea, y convivir

048 SG.47

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 coheren-
te 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 libre-
mente: el temido DevOps, criatura que encarna lo más obscu-
ro tanto de desarrolladores como de administradores.
Y ojo, me centro en este aspecto porque mi Dr. Jekyll es ad-
ministrador 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 nive-
les 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 emocio-
nó: 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 siste-
ma 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 plantea-
mientos de origen que siempre hago a mis alumnos: no es-
pero que de mi clase salgan autores de sistemas operativos;
sería un gran orgullo que así fuera, pero no es lo que la ma-
teria persigue. Una de las principales razones para estudiar
esta materia es que, si no se comprenden los fundamentos
PROGRAMAR ES UN MODO DE VIDA C
“Los frameworks no únicamente son cómodos,
sino que son necesarios para la realidad del desarrollo
de software hoy en día”.
de lo que estamos haciendo, nuestros programas van a re-
sultar 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 impor-
tancia 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 pro-
vecho 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 titula-
do 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 des-
prenden 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 tan-
tos 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 impro-
bable 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
 V VOCES
Software Defined Networking
—
Por Carlos Perea
Carlos Perea es ¿Cuál es el resultado de que el hardware ceda el control
Vicepresidente de los procesos a los componentes que se encuentran en ni-
de Ventas para veles superiores de sofisticación?, ¿cómo puede el software
Latinoamérica de tomar un papel más estratégico en la redes sin comprometer
Extreme Networks 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 nue-
vo 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 empre-
sas 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 de-
manda en innovación y síntesis en los procesos, como a la de pro-
veer 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 algu-
nos 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 in-
formá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 infraestruc-
tura con una inversión de tiempo y recursos mínimos.
Sin embargo, a pesar de que SDN es capaz de resolver la ma-
yoría de los problemas que plantean las redes actuales en su
complejidad, el reto más grande que encaran hoy las empre-
sas consiste en tener un acercamiento realista a esta arquitec-
tura 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, au-
tomatizá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án-
dares abiertos que no atan a los clientes a un solo fabricante.
2. Un esquema ágil en el cual es posible que la red se modifi-
que 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 mis-
mo 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án-
dares 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 resulta-
do es simple: una plataforma sin las limitaciones que común-
mente se encuentran en otros modelos SDN en el mercado,
muchos de ellos, no son aplicables y obligan a las organizacio-
nes a atarse a un mismo fabricante.
Implementar una arquitectura de SDN de código abierto, per-
mite 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.
 F FUNDAMENTOS
Certificados Digitales
—
Por Héctor Uriel Pérez Rojas
Seguramente en alguna ocasión has escu-
chado acerca de los certificados digitales, por
ejemplo al navegar en internet, o al autentificar-
te dentro del portal del SAT para realizar dife-
rentes 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 cripto-
grafía, existen dos tipos de algoritmos populares
para cifrar información: simétricos y asimétricos.
En los algoritmos simétricos se utiliza una mis-
ma 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/des-
cifrar 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 remiten-
tes que requieran enviar un mensaje cifrado al
destinatario, mismo que sólo podrá ser desci-
frado a través de la llave privada del destinata-
rio. Dicha clave, debe ser únicamente conoci-
da 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 cuen-
ten con su llave pública, puedan descifrar el
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
Fig. 1. Funcionamiento
de PKI.
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 certi-
ficados digitales, comparémoslos con los certi-
ficados que se obtienen al concluir algún curso
o entrenamiento. Dichos certificados, gene-
ralmente 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 certifi-
cados 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 institu-
ción, entre otros datos opcionales.
Validación de un certificado digital
Se puede tener la certeza de que un certificado
digital permanece íntegro, a través de la hue-
lla 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 digi-
tal no haya sido alterado o dañado, dando como
resultado una comprobación de identidad.
Infraestructura de Llave Pública (PKI)
Los certificados digitales más conocidos, se basan
en el estándar denominado X.509, y que se en-
cuentra 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
framework, consiste en un conjunto de hardware,
software, gente, procesos y políticas que juntos,
permiten crear, administrar, distribuir, usar, alma-
cenar y revocar certificados digitales.
La figura 1 ilustra el funcionamiento de dicha
infraestructura. El proceso para obtener un cer-
tificado 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 va-
lidaría que la persona física o moral sea realmente
quien acude a solicitar su par de llaves.
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 in-
formació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 cer-
tificados 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.
Conclusión
Continuamente compartimos información sen-
sible a través de internet apoyándonos en cer-
tificados digitales. Es importante que entenda-
mos cómo funcionan y el papel que juegan en
los esquemas de seguridad.

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 susten-
tante 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 in-
tención de este artículo es desglosar los diver-
sos temas que se requieren para poder presen-
tar 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 plan-
tean reglas y un proceso general para la aplica-
ció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 co-
nocer los ciclos de vida de desarrollo del soft-
ware, ya que son una parte importante de la
certificación. Una vez que se comprenden los
ciclos de vida, se estudian los niveles de prue-
bas dentro del ciclo de vida y que incluyen las
etapas de pruebas. Se revisan los diferentes ti-
pos de prueba que existen y se entiende cómo
aplicarlos dentro del software.
Pruebas estáticas. Se revisan los pasos reque-
ridos para realizar un conjunto de pruebas. Lo
que significa que se definen las etapas y las
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 empresa-
riales y administradores de proyectos tecnológicos.
condiciones para dar por buenas cada una de
ellas. Adicionalmente se revisan las responsa-
bilidades de todo aquel involucrado en el pro-
ceso 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 inclu-
yen 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 des-
criben 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 com-
plejas 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 or-
ganizaciones 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 es-
pecialización de las pruebas de software.
CARRERA H
Para apoyar a la organización a formar un
equipo de pruebas con parámetros de conoci-
miento homogéneo es recomendable que sus
equipos lo formalicen a través de la certifica-
ció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 ob-
tención de productos de software con calidad
y con menos fallas, porque así como es impor-
tante 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 co-
nocimiento de los conceptos de las pruebas de
software; y es necesario para poder presentar
los siguientes. El nivel avanzado maneja el co-
nocimiento necesario para la administración
de equipos de pruebas y de pruebas técnicas
avanzadas; el nivel experto provee el conoci-
miento para la mejora de pruebas, automati-
zació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 aproba-
ción. Si todo es exitoso, el certificado llega por
correo al domicilio.
http://www.istqb.org
SG.COM.MX 053
 O 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 den-
tro 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 im-
permeables. 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) 4

3 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 bate-
rí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.
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 tie-
nen 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 com-
pleta 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”.

054 SG.47
 5

RELOJ FIBONACCI
http://swgu.ru/px

Como buen lector de SG, seguramente te gus-

tan las cosas que tengan estilo, requieran usar
el cerebro y sean “hackeables”. Es por ello que
te presentamos el reloj Fibonacci. Es un re-
loj 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, tene-
mos dos cuadros pequeños, cada uno represen-
tando 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 calcu-
lar 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 en-
cuentra 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 lis-
ta de partes para tú ensamblarlo, hasta la ver-
sión lista para usarse. El reloj utiliza un micro-
controlador 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.
 O BIBLIOTECA

TEACH YOUR KIDS TO CODE: A PARENT 1

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 enfo-
cada 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 programa-

ció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áti-
cas 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 2

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 organi-
zaciones 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 moder-
no 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á desti-
nado 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