SG #51

Biblioteca SG51

sg — Sat, 09 Jul 2016 14:47:54 +0000

Biblioteca SG51

sg Sat, 07/09/2016 - 09:47

Publicado en

SG #51

Biblioteca

Arduino Project Handbook

Mark Geddes. No Starch Press, junio 2016.

El Arduino Project Handbook es una colección de proyectos usando la tableta Arduino. Con una computadora, un microcontrolador Arduino y algunos componentes electrónicos, aprenderás a construir varios proyectos divertidos. El autor, Mark Geddes, originalmente escribió este libro para enseñar electrónica y microcontroladores a su hijo de 10 años sin tener que pasar primero por cientos de páginas de teoría.

Son 25 proyectos y cada uno cuenta con instrucciones detalladas, fotografías, diagramas de circuitos y código completo, de tal manera que hasta los más novatos no tengan ningún problema para arrancar. El libro comienza desde lo más básico, una introducción a Arduino y consejos sobre herramientas y componentes electrónicos. A partir de eso ya puedes escoger si seguir los proyectos en orden o escoger aquellos que más te interesen.

Algunos de los proyectos incluidos son: una estación de monitoreo del clima, un juego de memoria basado en luces de colores, un sistema de alarma por detección de movimiento, un estroboscopio, un show de luces de colores, y una chapa que detecta claves para tocar la puerta , entre otros.

Arduino Project Handbook está disponible en versión impresa y digital. Adicionalmente, en https://www.nostarch.com/arduinohandbook puedes descargar un capítulo con el proyecto del juego de memoria.

Scaling Lean

Ash Maurya. Lean Stack, junio 2016.

Scaling Lean es el libro más reciente de Ash Maurya, uno de nuestros autores y consultores favoritos sobre emprendimiento tecnológico. Scaling Lean brinda una valiosa guía para modelar el camino de tu startup hacia el éxito. Aprenderás cómo obtener métricas esenciales que te permitirán medir la ejecución de tu modelo de negocio, obtener el pulso de tu startup, comunicarte con tus inversionistas y saber cuando es necesario intervenir para corregir el rumbo.

El autor, Ash Maurya, comenta que aunque su libro anterior, Running Lean, plantea un mapa de ruta táctico de cómo llevar una idea a la realidad, se dio cuenta que al aplicarlo en escenarios reales quedaban muchas dudas de implementación. Scaling Lean busca brindar una guía para contestar estas dudas. Entre los aspectos que se enfoca Scaling Lean están: cómo medir o cuantificar un modelo de negocio, cómo balancear el aprendizaje interno del startup y la entrega de resultados a inversionistas, qué es lo que sucede después de lanzar un MVP y cómo mantenerse enfocado en los principales riesgos.

El libro también incluye guías para hacer cosas como:
• Evaluar la viabilidad de un modelo de negocio en unos cuantos minutos.
• Establecer metas progresivas orientadas a crecimientos exponenciales al largo plazo.
• Planear y ejecutar sprints lean de dos semanas para rápidamente obtener, priorizar y probar ideas de negocio.

Si planeas adquirir este libro, te recomendamos hacerlo desde https://leanstack.com/scaling-lean-book ya que obtendrás beneficios adicionales de acceso a contenido y herramientas de soporte.

ARM como Pivote del IoT

sg — Fri, 08 Jul 2016 17:40:36 +0000

ARM como Pivote del IoT

sg Fri, 07/08/2016 - 12:40

Publicado en

SG #51

Programar es un Estilo de Vida

Autor

Gunnar Wolf

A lo largo de los años, fuimos testigos de cómo las arquitecturas rivales de cómputo pasaron de una gran gama de implementaciones luchando por la supremacía durante los 80 y 90 a una aparente monocultura. La primera década del milenio vio sucumbir a poderosas y prometedoras plataformas como Alpha, m680x0 y HPPA-RISC. Sparc y PowerPC redujeron su participación en el mercado a únicamente casos muy especializados. MIPS pasó de ser el último grito en lo relativo a hardware de alto rendimiento a ser una arquitectura para dispositivos de bajo consumo y bajo precio, como la mayor parte de los switches y puntos de acceso inalámbrico disponibles en el mercado.

Consolidación de una arquitectura reinante

Por varios años, parecía que la plataforma x86, definida por Intel como una serie de “parches” sucesivos al procesador 8086 de 1978, reinaría sin rivalidad en prácticamente todos los mercados. Computadoras de escritorio, portátiles, servidores. Hacia 2005, la plataforma x86 se erigía como clarísimo dominante. Y esto no por ser más potente o eficiente que su competencia, sino por tener una muchísima mayor base de usuarios ya instalada, por mantener una gran compatibilidad hacia atrás, y porque prácticamente todo el software de consumo masivo aparecía únicamente para éste.

Es muy sabido que esta compatibilidad hacia atrás no siempre es lo más conveniente técnicamente. En la década de 1980 nació RISC (Reduced Instruction Set Computing, cómputo con un conjunto reducido de instrucciones), primero como concepto teórico y poco más tarde implementado en varias arquitecturas de hardware (algunas de ellas mencionadas en el primer párrafo). Ya en esos años se veía que las principales arquitecturas disponibles tenían conjuntos de instrucciones demasiado complejos (recibiendo la denominación CISC, Complex Instruction Set Computing, cómputo con un conjunto de instrucciones complejo, en contraposición con la nueva tendencia).

Intel mismo intentó en dos ocasiones diseñar una nueva familia de procesadores que reemplazara a x86. La arquitectura RISC i860, lanzada en 1989 y abandonada unos cinco años más tarde, y la Itanium o IA-64, que se ha mantenido viva de manera formal desde su debut en 2001, pero en la práctica y ante el abandono de prácticamente todos los fabricantes y proveedores de software, es una arquitectura cada vez más anecdótica.

ARM: Jaque al rey

Parecería que en este recuento de la gradual homogeneización de las plataformas de cómputo no hay mucho más que decir. Pero en los últimos años, se ha dejado sentir fuertemente un cambio drástico, y desde el segmento bajo del mercado.

La plataforma de hardware ARM no es bajo ningún concepto un nuevo jugador en el mundo del cómputo: su diseño original se produjo durante los años 1983 a 1985, al interior de la empresa Acorn, que buscaba desarrollar un sucesor para el popular CPU de 8 bits 6502 empleado en muchas computadoras de la época y, en particular, en la BBC Micro, plataforma de gran éxito en el Reino Unido. De hecho, ARM se manejó originalmente como acrónimo de “Acorn RISC Machine”, y una vez que la Acorn dejó de ser un hito reconocible en la mente de los usuarios británicos, para 1990 se independizó de la marca padre para denominarse “Advanced RISC Machines”.

Los procesadores ARM son un ejemplo para libro de texto de las diferencias y ventajas de RISC: si bien su conjunto reducido de instrucciones significa que, a una misma velocidad, pueden realizar mucho menos trabajo real que su competencia CISC, el número de transistores requerido para implementarlo resulta decenas de veces menor que el equivalente CISC de su época. Por ejemplo, cuando en 2007 se introdujo el ARM Cortex-A9, de 26 millones de transistores, los CPUs i7 de Intel excedían los 730 millones.

Menos transistores se traduce en muy distintas ventajas, todas ellas importantes para el cambio que hoy estamos observando:

• Fabricar CPUs ARM resulta más barato, dado que pueden usar procesos que requieren menor miniaturización y hay más fabricantes en condiciones de hacerlo (ARM no tiene ninguna fábrica, es dueño únicamente del diseño de los chips).

• La disipación de calor es menor. Un procesador CISC actual requiere de enfriamiento activo, empleando masivos disipadores y ventiladores. La operación normal de un procesador ARM resulta mucho más aceptable para un equipo de perfil delgado, y más aún cuando está diseñado para llevarse en contacto con el cuerpo de su usuario.

• El consumo eléctrico es menor, permitiendo mucho mayor tiempo de operación a baterías. Naturalmente, el tamaño de los chips resultantes es menor. Mientras que un CPU Intel para equipos de escritorio mide unos 4cm. por lado, los procesadores ARM apenas y sobrepasan un centímetro cuadrado.

Los procesadores ARM siempre estuvieron presentes en nuestros dispositivos “menores”, pero dado que nuestra relación con estos nunca fue tan intensa y personal como en los últimos años, rara vez nos resultó claro. Al haber dado el gran salto cualitativo el mercado de los dispositivos móviles, la plataforma ha dado un salto tal que se volvió la primera respuesta al considerar cada vez más casos de uso, incluso ya en algunos casos entrando al segmento tradicionalmente fuerte de x86.

ARM es una arquitectura muy versátil; tienen tres perfiles de CPUs definidos. De más sencillo a más poderoso, “M” (para microcontroladores), “R” (para aplicaciones de tiempo real) y “A” (para aplicación).

Complicaciones de la plataforma

La plataforma x86 tiene, sin embargo, una gran ventaja: la apertura y estandarización de las principales interfaces entre ésta y su sistema operativo. Para bien o para mal, desde la aparición de la IBM PC en 1981, todos los sistemas compatibles cuentan con un BIOS que se adhiere a una interfaz clara y pública; si bien esta ha sido extendida, mejorada y finalmente reemplazada — por UEFI, que a pesar de los puntos negativos que tenga, era una actualización largamente esperada — a lo largo de sus 35 años.

El BIOS funge de intermediario entre el hardware y el sistema operativo en sus primeras etapas (sobre todo en los primeros años de la PC; hoy en día la funcionalidad se limita casi en exclusiva a la inicialización del sistema). Al arrancar la computadora, se encarga de enumerar y realizar pruebas básicas de funcionalidad al hardware del sistema (el POST). Tras este paso, el sistema operativo puede lanzarse con conocimiento básico del hardware con el que operará.

En la arquitectura ARM, el BIOS sencillamente no existe. La razón para esto es que la compañía ARM funciona de forma distinta de Intel. La compañía no vende chips, no posee fábricas, sino que licencia a terceros sus diseños como propiedad intelectual; los chip ARM son en realidad fabricados, entre muchas otras empresas, por AMD, Broadcom, Freescale, Texas Instruments, e incluso el mismo Intel.

En el mundo ARM, es muy común que los chips encapsulen no únicamente al CPU, controlador de memoria, controlador gráfico, y otros componentes esenciales, sino que prácticamente a todo el sistema de cómputo, inclusive la RAM y los controladores de dispositivos. A esta práctica se le conoce como “SoC” (System on a Chip); de hecho, si ven cualquiera de las computadoras basadas en ARM que han surgido en años recientes, uno de los primeros puntos que llama la atención es su relativa simplicidad. Y si acostumbran abrir, en claro ejercicio de un espíritu científico, sus teléfonos o tabletas, notarán precisamente lo mismo.

Las computadoras ARM, pues, no están normalmente concebidas para su expansión. Por sus características físicas, y por su bajo costo, es más bien un enfoque de un sistema para cada tipo de necesidad; desde el punto de vista en pro de la ecología suena nefasto, pero si requieren mayor poder de cómputo, la respuesta es cambiar de computadora. Además, la mayor parte de los fabricantes buscan ubicar sus equipos como “cajas cerradas”. ¡No es de su interés que yo pueda ejecutar mi software favorito en sus teléfonos en vez del “oficial”!

Ahora, dado que la computadora no requiere de la enumeración y prueba que realiza el BIOS, se ha optado por prescindir de este elemento. Es, pues, responsabilidad del sistema operativo saber qué dispositivos tiene y dónde se ubican. En el caso de Linux, el sistema operativo más común para entornos ARM, significa que debe construirse un núcleo ligeramente distinto para cada modelo de computadora. Este conocimiento del entorno se plasma en una estructura conocida como Device Tree (árbol de dispositivos).

Las plataformas Arduino y Raspberry Pi han resultado fundamentales, no por ser únicas o por ser las más económicas, sino por masificar el acceso a esta tecnología llevándolo al mercado educativo, y servir así como base para cientos de productos tangibles.

Adecuar Linux para su funcionamiento en una nueva sub-arquitectura no es una tarea trivial. Hay un fuerte empuje hoy en día para que los desarrolladores de hardware realicen este trabajo de adecuación con mayor colaboración y en consonancia con la comunidad desarrolladora primaria. Tengo plena esperanza en que, conforme se construye el ambiente de desarrollo para el afamado IoT, irá resultando claro a los fabricantes el valor de mantener la apertura ante los usuarios entusiastas.

Bio

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

Special Purpose Languages, parte 3

sg — Fri, 08 Jul 2016 17:33:09 +0000

Special Purpose Languages, parte 3

sg Fri, 07/08/2016 - 12:33

Publicado en

SG #51

Prueba de Software

Autor

Luis Vinicio León Carrillo

En el número anterior definimos lo que es un lenguaje formal de la siguiente manera:

partimos de la definición del concepto de alfabeto como un conjunto finito de caracteres B = { b1 , b2 , …, bm }, y dijimos que B tiene una cardinalidad (cantidad de elementos) igual a m , lo cual escribimos como |B| = m ;
definimos la operación de concatenación ‘·‘ sobre caracteres (lo que nos permite construir b5· b4· b8· b8 ) y sobre conjuntos de caracteres (lo que nos permite construir B · A · C ) ;
definimos la exponenciación de la concatenación Bx sobre un alfabeto B como la aplicación de la concatenación x-1 veces sobre el alfabeto ( B · B · … · B , donde B aparece x veces) ;
definimos la cerradura de Kleene B* como la unión de todas las exponenciaciones sobre el alfabeto B (B* = U∞i=0 Bi ) ;
definimos que un lenguaje formal sobre un alfabeto B es cualquier subconjunto de B* .

De lo anterior se desprende que, dado un código ASCII extendido que llamaremos AE de cualquier cantidad de caracteres, podemos ver al lenguaje Java como el subconjunto de cadenas de cualquier longitud escritas utilizando ese AE que son aceptadas como “correctas” por el compilador de Java. Lo mismo es cierto si sustituimos “Java” por el nombre de cualquier lenguaje de computación.

Ahora bien, en AE* están incluidos no solo todos los lenguajes de programación existentes y por existir, sino también todos los compiladores (escritos y por escribirse) de todos esos lenguajes. De hecho, en AE* se encuentran todas las cadenas de caracteres que podamos escribir en esa extensión del ASCII, incluyendo los programas “incorrectos” en todos los lenguajes.

Contestemos ahora las primeras 2 preguntas que planteamos al final del número anterior, en el cual dijimos que dado un conjunto A que tiene i elementos, la cantidad de subconjuntos que pueden formarse sobre A es igual a 2i .

Dijimos también que B*, la Cerradura de Kleene sobre el alfabeto B, es un conjunto infinito pero contable, porque tiene la misma cardinalidad que el conjunto de los números naturales N. Esto implica en particular que, así como ocurre en el conjunto de los números naturales N, dada una de las cadenas de B*, siempre podemos definir cuál es la que le sigue y listar sus elementos en orden sin saltarnos alguno (en N , dado un número natural y, sabemos que el que le sigue es y+1).

Del penúltimo párrafo se sigue que la cantidad de lenguajes sobre cualquier alfabeto B es igual a 2N … El asunto es que 2N es una cardinalidad estrictamente mayor que la de N (siguiendo el Teorema de Cantor), lo que lo vuelve un conjunto no-contable (aquellos conjuntos en los que, dado un elemento x, no es posible decir cuál elemento es el que sigue, como en el caso de los números reales R : si tenemos el número 0.0004 no podemos decir que el que le sigue es 0.0005; tampoco que es 0.00041; en realidad, entre cualesquiera 2 números reales hay una cantidad infinita de números reales).

Una consecuencia importantísima de lo anterior es que la cantidad de lenguajes (2N) que pueden definirse sobre un alfabeto es estrictamente mayor que la cantidad de cadenas (N) que pueden construirse sobre ese alfabeto, así es que: independientemente del tamaño del alfabeto, siempre tendremos lenguajes sobre ese alfabeto para los que no podemos definir un compilador, esto es, siempre habrá lenguajes que no podremos procesar.

Para nuestro propósito de construir lenguajes propietarios, esto significa que para poder procesarlos, en principio debemos observar algunas restricciones para su diseño. El lado bueno de esto es que, dado que estamos acostumbrados a utilizar lenguajes de programación y sus estructuras obviamente son procesables, podemos incluir estructuras de ese tipo en nuestro lenguaje. El lado malo es precisamente eso mismo: como estamos acostumbrados a ello, probablemente no incluyamos otras estructuras que serian más adecuadas para las actividades que nuestros programadores automatizarán.

El punto no es para subestimarse: las estructuras que tenemos a nuestra disposición en un lenguaje (sea artificial o natural) pueden imponer límites a lo que podemos expresar (sea programar o pensar); como ejemplo tenemos el comentario del reconocido científico computacional C.A.R. Hoare sobre su método de ordenamiento Quick-Sort, después de que tomó un curso de Algol-60 (primer lenguaje en ofrecer la posibilidad de escribir subrutinas recursivas):

“Fue entonces que aprendí por primera vez sobre procedimientos recursivos y vi cómo programar el método de ordenamiento que previamente había tenido tanta dificultad para explicar.”

Para contestar la tercera pregunta necesitaremos elementos que revisaremos más adelante; pero antes, veamos algunos ejemplos.

Ejemplos con “especificaciones algebráicas”

Usando las definiciones arriba mencionadas y tomando como convención que escribiremos:

bibj en lugar de bi· bj (concatenación de caracteres);
bin en lugar de bi· … · bi (concatenación en la que bi aparece n veces);
a en lugar de b1 , b en lugar de b2 , c en lugar de b3 , y d en lugar de b4 (haciendo concreto el alfabeto abstracto
B = { b1 , b2 , …, b4 } ) ;

especifiquemos algunos lenguajes formales:

am bn ci , para m, n, i enteros mayores a cero e independientes entre sí. Este sencillo lenguaje, que llamaremos L1 , especifica todas las cadenas que tienen una o más a’s seguidas por una o más b’s seguidas por una o más c’s.
am bn cn dm , para m, n ≥ 0 . Obviando detalles, este lenguaje que llamaremos L2 (más complejo que L1 ), es una abstracción de los sublenguajes incluidos en prácticamente todos los lenguajes de programación, en los que por ejemplo, los paréntesis y las llaves deben venir por pares (uno de cierre por cada uno de apertura) y estar “emparejados adecuadamente” (por ejemplo, no se acepta “ ( … {… ( … ) … ) … } ” ) ;
am bn cm dn , para m, n ≥ 0 . Obviando detalles, este lenguaje que llamaremos L3 (más complejo que L2 ), es una abstracción de la especificación del mecanismo de paso de parámetros que utilizan muchos lenguajes de programación para exigir que la cantidad de parámetros establecidos en la definición de una subrutina sea la misma que cuando ésta se utiliza.

Gramáticas

Después de esa primera definición de lenguaje en términos de concatenaciones sobre alfabetos, que podríamos llamar algebraica y que es más bien declarativa, tomaremos ahora un enfoque un poco más imperativo utilizando reglas (que pueden verse como una abstracción del concepto de patrones).

Podemos definir lenguajes utilizando gramáticas, las cuales son cuátruplas de la forma

< T, N, S0 , R > donde

T es el conjunto de los símbolos terminales del lenguaje (en adelante “Terminales”), los cuales podemos ver como el alfabeto con cuyos elementos finalmente se construyen las cadenas de caracteres;

N es el conjunto de los símbolos no-terminales del lenguaje (en adelante “no-Terminales”); aquellos símbolos abstractos que deben definirse en términos de Terminales y no-Terminales; nota: debe cumplirse que T ∩ N = {} ;

R es el subconjunto del producto cartesiano
(T ∪ N)* x (T ∪ N)* que define la relación matemática que denota las reglas de reescritura del lenguaje (en adelante “Reglas”);

S0 es el elemento distintivo de los no-Terminales llamado “Símbolo-inicial”, que es con el que inicia el “procesamiento” de R .

Escribiremos las Reglas utilizando el “meta-lenguaje” (llamado así porque es un lenguaje con el cual definimos lenguajes) llamado BNF (Backus-Naur Form). En él, para cada regla se coloca el primer elemento del producto cartesiano, seguido del símbolo “→” seguido del segundo elemento del producto cartesiano.

Ahora bien, cuando tengamos un conjunto de reglas como

α → β1
α → β2
…
α → βn , donde α y todas las βi son elementos de (T ∪ N)* (o sea, elementos de la cerradura de Kleene de la unión de los Terminales y no-Terminales; es decir, combinaciones de uno o Terminales y no-Terminales),

lo escribiremos como

α → β1 | β2 | … | βn

Si alguna βi contiene cero Terminales y cero no-Terminales, la escribiremos como λ (la letra griega lambda), que representará la cadena vacía.

Además, escribiremos los Terminales con minúsculas, los no-Terminales con MAYÚSCULAS, y S0 será el no-Terminal que aparece a la izquierda de “→” en la primer Regla. Con ello R define la gramática por sí sola, porque con las convenciones queda explícito cuáles son los Terminales, los no-Terminales y S0 . Entonces, en adelante podremos definir un lenguaje listando únicamente las reglas de R .

Una jerarquía de lenguajes

Tenemos la siguiente categorización de lenguajes, que se hace considerando la complejidad de la estructura de las reglas en la R particular que los define (por cuestiones de espacio, obviaremos algunos detalles):

Llamaremos gramáticas regulares a aquellas cuyas reglas en R sean de la forma A→ B d | d (o menos compleja); y llamaremos lenguajes regulares (o de Tipo 3, o Lgs3 de manera corta) a aquellos que puedan definirse utilizando gramáticas regulares. Nota: las reglas pueden ser de la forma A→ d B | d , pero no se deben mezclar ambas formas.)
Llamaremos gramáticas libres de contexto a aquellas cuyas reglas en R sean de la forma A→ α (o menos compleja), y lenguajes libres de contexto (o de Tipo 2, o Lgs2) a aquellos que puedan definirse utilizando gramáticas libres de contexto.
Llamaremos gramáticas sensibles al contexto a aquellas cuyas reglas en R sean de la forma β1 A β2 → β1αβ2 (o menos compleja), donde α ≠ λ ; y lenguajes sensibles al contexto (o de Tipo 1, o Lgs1) a aquellos que puedan definirse utilizando gramáticas sensibles al contexto. Decimos que β1 y β2 representan el contexto en el que A se puede transformar en α .Ahora bien, como α ≠ λ , entonces la suma de la cantidad de Terminales y de no-Terminales en α es mayor o igual a uno; a esta cantidad la llamaremos la longitud de α y la denotaremos con |α|. Ahora podemos generar otra definición menos restrictiva (aunque una que no deja ver el atributo de “sensible al contexto”): llamaremos gramáticas sensibles al contexto a aquellas cuyas reglas en R sean de la forma
θ → α (o menos compleja), donde θ ∈ (T ∪ N)* , θ ≠ λ y |θ| ≤ |α| ; y llamaremos lenguajes sensibles al contexto a aquellos que puedan definirse utilizando este tipo de gramáticas
Por último, llamaremos gramáticas estructuradas por frases a aquellas cuyas reglas en R sean de la forma θ → α (o menos compleja), donde θ∈ (T ∪ N)* y θ ≠ λ ; y llamaremos lenguajes estructurados por frases (o Tipo 0, o Lgs0) a aquellos que puedan definirse utilizando gramáticas estructuradas por frases.

Lo anterior define lo que es conocido como la Jerarquía de Chomsky, en la cual ocurre, como se puede observar, que Lgs3 ⊂≠ Lgs2 ⊂≠ Lgs1 ⊂≠ Lgs0 (esto es, los Lgsi son subconjuntos propios de los Lgsi-1). Para el caso particular de Lgs3 ⊂≠ Lgs2 , esto significa que todos los lenguajes regulares (todas las gramáticas regulares) son libres de contexto, pero que hay lenguajes libres de contexto que no son regulares (para los que no existen gramáticas regulares que los definan).

La Jerarquía de Chomsky muestra con claridad un crecimiento significativo en la complejidad de la estructura de las reglas, o dicho de otra manera, una disminución significativa en las restricciones sobre esa estructura. Esto obviamente impacta en la complejidad (incluso en la posibilidad) de procesar todos esos tipos de lenguajes. Retomaremos el tema con más profundidad más adelante.

Referencias

L. León. “Los Special Purpose Languages, parte 1”. Revista Software Guru #48.
http://sg.com.mx/revista/48/los-special-purpose-languages
L. León. “Los Special Purpose Languages, parte 2”. Revista Software Guru #50.
http://sg.com.mx/revista/50/los-special-purpose-languages-2

Bio

Luis Vinicio León Carrillo es Director General y socio fundador de e-Quallity. Antes de fundar e-Quallity fue profesor-investigador en la universidad jesuita ITESO durante varios lustros, que incluyeron una estancia de posgrado en Alemania, durante la cual abordó aspectos relacionados con el Testing y los formal methods and languages.

Los Niveles de Granularidad del Requerimiento Funcional

sg — Fri, 08 Jul 2016 17:27:01 +0000

Los Niveles de Granularidad del Requerimiento Funcional

sg Fri, 07/08/2016 - 12:27

Publicado en

SG #51

Requerimientos

Autor

Como la mayoría de los lectores de SG saben, todo software posee dos dimensiones de requerimientos: funcional y no funcional. Los requerimientos funcionales (RF) describen el comportamiento del software para proporcionar tareas y servicios a sus usuarios; estos tipos de requerimientos están relacionados a lo que el software debe hacer. Los requerimientos no funcionales (RNF) están relacionados al cómo las funcionalidades del software serán entregadas a sus usuarios y pueden incluir aspectos de calidad, técnicos, ambientales y organizacionales.

Teniendo en cuenta un sistema de cajero automático de un banco se podría suponer los siguientes ejemplos para los dos tipos de requerimientos:

RF: Consultar saldo de la cuenta corriente (el qué).
RNF: Toda transacción debe ser completada en un máximo de 30 segundos (el cómo).

Aunque no sea una regla, el RF se acostumbra manifestar de manera explícita en el software, es un comportamiento que se puede determinar claramente en qué parte del software está. El RNF, por lo contrario, se acostumbra manifestar de manera general, se aplica a todo o casi todo el software.

Para la Ingeniería de Requerimientos los dos tipos son igualmente relevantes: ambos deben ser identificados, analizados, especificados, modelados y gestionados. Sin embargo, hay algunas diferencias entre estos dos tipos de requerimientos que valen la pena comentar por separado. Este artículo se enfocará en los RF, con el objetivo de presentar sus niveles de granularidad y su importancia en el trabajo de la Ingeniería de Requerimientos.

Los niveles de granularidad

Continuando con el ejemplo del sistema de cajero automático, las siguientes descripciones podrían estar presentes en su especificación de requerimientos:

Realizar transacciones con la cuenta corriente.
Transferir una cifra de una cuenta corriente para otra cuenta corriente.
Validar la tarjeta y la contraseña del cliente.
Garantizar que la suma de todas las transacciones del cliente en el día no puede ser superior a $5,000.

Aunque estos cuatro ejemplos sean casos válidos de RF, es posible percibir que el nivel de detalle (o granularidad) entre ellos es distinto. Lo más frecuente es que una especificación presente los requerimientos en distintos niveles de granularidad.

El nivel de granularidad es la mayor o menor amplitud de la descripción del comportamiento esperado para el software en una especificación funcional. Esto está relacionado al tipo de objetivo asociado al requerimiento. La Figura 1 ilustra la relación entre estos objetivos y el nivel de granularidad, utilizando una clasificación de tres niveles (agregado, usuario, subfunción) propuesta por Cockburn (2000) para casos de uso y generalizada por los autores para requerimientos funcionales. Esta clasificación no significa que el proceso de la ingeniería de requerimientos deba utilizar una estrategia de desarrollo por descomposición funcional.

Figura 1. Niveles de granularidad.

Nivel de usuario

El requerimiento a nivel de objetivo de usuario es aquel que:

Abarca una única tarea bajo la responsabilidad de un único individuo;
Es realizado en el momento en que el usuario posee todo lo que es necesario para que la tarea sea completada hasta el límite de su responsabilidad en el flujo operativo donde está contenida.

Al final de la tarea el usuario alcanza su propósito, está satisfecho y no hay nada más que necesite hacer. Una vez que el requerimiento fue completado, todo lo que debería de realizarse para tratar un evento externo fue realizado. Esta tarea es casi siempre parte de un proceso de negocio que puede tener un flujo operativo más amplio y por esto puede aún no estar completa. Sin embargo, la perspectiva relevante en este caso no es del proceso de negocio, es de la tarea.

En general, si un trabajo involucra más de un individuo es porque hay más de una tarea presente en el contexto. Hay excepciones como un retiro en la cuenta corriente en la sucursal del banco donde dos individuos participan: la caja del banco que solicita e informa datos para el retiro y el cliente que informa la contraseña.

Esta es la granularidad del ejemplo 2 (“Transferir una cifra de una cuenta corriente para otra cuenta corriente.”). Es una única tarea (seguramente compuesta por varios pasos y reglas), bajo la responsabilidad de un único individuo que al final de todos los pasos está satisfecho con el objetivo alcanzado: una cifra fue transferida a otra cuenta corriente.

Nivel agregado

El requerimiento en este nivel agrega varios requerimientos a nivel de objetivo de usuario en una única especificación de más alto nivel. Tanto más alto sea su nivel, más generales son sus objetivos y para que un objetivo de nivel más alto sea alcanzado, otros objetivos de nivel más bajo deben ser alcanzados primero.

Este tipo de requerimiento está relacionado a objetivos más generales y su amplitud está asociada a objetivos colaborativos o asociados a procesos de negocio de alto nivel. No es relativo a una única tarea, por lo contrario, agrega un conjunto de tareas de uno o más usuarios. Esta es la granularidad del ejemplo 1 (“Realizar transacciones con la cuenta corriente.”).

¿Cuáles son las tareas asociadas a este tipo de requerimiento? Tal vez sean obvias para los lectores de la especificación (los interesados) o tal vez aún no sean conocidas. Sin embargo, es sabido que hay actividades a realizar para levantar (refinar) este requerimiento. Lo que importa es que ya está claro que este requerimiento está dentro del alcance del software a ser desarrollado.

Sin embargo, algunos RF de este tipo poseen patrones que eliminan la necesidad de proporcionar más detalles. Un ejemplo clásico son los formularios CRUD (Create, Read, Update, Delete) para que el usuario pueda mantener datos por medio del software. Es muy común que esto sea expresado como: “El sistema debe mantener productos.”. Hay un conocimiento tácito entre los interesados que el verbo “mantener” agrega las tareas del CRUD. Por lo tanto queda claro a todos los lectores que el software debe permitir al usuario realizar las siguientes tareas: agregar, modificar, eliminar y consultar datos de producto.

Nivel de subfunción

Estos requerimientos son pedazos de requerimientos con objetivo de usuario; están relacionados a un conjunto de pasos o a reglas de una o más tareas de los usuarios.

El requerimiento en nivel de subfunción que representa un conjunto de pasos describe el cambio de datos en los dos sentidos entre el usuario y el software; y entre el software y los requerimientos de almacenamiento. Este es el caso del ejemplo 3 (“Validar la tarjeta y la contraseña del cliente.”). Cada tipo de transacción que utiliza la cuenta corriente (ej.: retiro, transferencia, pago, etc.) exige el mismo conjunto de pasos descrito por el ejemplo 3, que se podría suponer como:

Verificar si la tarjeta es válida.
Verificar si la transacción elegida es compatible con el tipo de tarjeta.
Verificar si la contraseña informada es correcta.
Incrementar el control de errores de contraseña en caso que la contraseña informada sea incorrecta.
Cambiar a cero el control de errores de contraseña en caso que la contraseña informada sea correcta.

Validar la tarjeta y contraseña del cliente no es el objetivo del cliente al utilizar el sistema de cajero automático, sin embargo son pasos necesarios y intermediarios para alcanzar su objetivo: por ejemplo, hacer un retiro.

El requerimiento en el nivel de subfunción que está relacionado a reglas, en general se vincula a las leyes que gobiernan el negocio y describen de manera que complementan los procesos de negocio. También llamadas muchas veces como reglas de negocio. La regla puede describir políticas corporativas, reglamentos gubernamentales o estándares de la industria por los cuales el software debe estar subordinado.

Este es el caso del ejemplo 4 (“Garantizar que la suma de todas las transacciones del cliente en el día no puede ser superior a $5,000.”). Las reglas de negocio muchas veces son compartidas entre varios RF, hasta entre distintos productos de software en la empresa.

Importancia de la granularidad

En una visión simplificada se puede decir que hay dos momentos clave donde una especificación de requerimientos es necesaria:

A. Proporcionar una visión amplia del software (y tal vez aún no profunda).

B. Proporcionar una visión profunda del software (de una parte o del todo).

El caso A es muy común en etapas tempranas de proyectos. El objetivo en este momento es primero obtener una visión amplia del alcance, por ejemplo: para planificar el proyecto, estimar un orden de magnitud de costo o plazo, o hacer un análisis de factibilidad. Un documento de visión es un ejemplo de documento que cumple este propósito. Especificar los RF en el nivel agregado es suficiente y más adecuado a este caso. El costo para obtener información y especificar en un nivel de granularidad más bajo puede significar desperdicio de esfuerzo para detallar lo que no es necesario.

Entonces el documento de requerimientos para el propósito A, tendrá la mayoría de los RF especificados en el nivel agregado. Es posible también que haya especificaciones en el nivel de usuario o subfunción, esto no es un error. A veces puede ser interesante especificar los RF más críticos (no todos o la mayoría) en un nivel más detallado, ya sea para facilitar la comprensión del alcance por el interesado o permitir una estimación con menos incertidumbre.

El principal propósito para especificar requerimientos en niveles agregados es establecer áreas de proceso objeto de informatización y/o automatización para que las necesidades de negocio queden resueltas.

Si el objetivo de la especificación es proporcionar una visión profunda de parte o de todo el software, por ejemplo para iniciar su desarrollo, la existencia de RF en el nivel agregado puede significar que varias decisiones sobre el alcance todavía siguen pendientes. Es decir, hay trabajo de levantamiento que debe ser hecho.

Para el propósito B, el nivel de granularidad más adecuado es del objetivo del usuario pues es el único que proporciona una definición de alcance del software de manera inequívoca; no hay dudas sobre lo que es abarcado. Esto es también el único nivel de descripción de procesos que puede ser estandarizado y consecuentemente es el nivel utilizado por todos los métodos de medición de tamaño funcional adherentes a la norma ISO/IEC 14143.

Consecuentemente, para el propósito B, lo más común es que un documento de requerimientos tenga los RF especificados en su mayoría con el objetivo de usuario. RF en el nivel agregado puede estar presente sólo cuando es el caso de que esté claro a todos los interesados que tareas son abarcadas por este RF.

La definición de un requerimiento en el nivel de subfunción es adecuada cuando el comportamiento especificado es común y compartido por varias otras tareas que el software entrega a los usuarios. Esto hace con que la especificación de requerimientos sea más fácil de modificar en respuesta a cambios, pues disminuye la redundancia de información al evitar describir el mismo conjunto de pasos o reglas más de una vez. También ayuda a alcanzar una especificación más consistente.

Conclusión

Aunque el concepto de los niveles de granularidad del requerimiento funcional sea sencillo, en términos prácticos se percibe que muchos ingenieros de requerimientos no están atentos a esto cuando elaboran las especificaciones. Tener en cuenta los niveles de granularidad ayuda a definir el esfuerzo adecuado para ser dedicado a la elaboración de la especificación y también a alcanzar una especificación de requerimientos de mejor calidad.

El estándar 830 de la IEEE presenta los siguientes criterios para evaluar la calidad de una especificación de requerimientos: correcta, completa, clara (no ambigua), consistente, modificable, priorizada, verificable, trazable.

Siendo el propósito de la especificación proporcionar una visión profunda del alcance, estar atento al nivel de granularidad del RF permite que:

• Se descubra que la especificación puede no estar completa cuando hay RF agregados.

• Se proporcione la comprensión del alcance sin ninguna ambigüedad con respeto a las tareas que el software entregará cuando se enfoca el RF con objetivo de usuario.

• Se genere un documento de requerimientos más fácil de mantener y consecuentemente más consistente al especificar los RF adecuados con objetivo de subfunción.

Referencias

A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000.
COSMIC Measurement Manual: 4.0.1. Common Software Measurement International Consortium, 2015.
IEEE Std. 830–1998: IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.
Function Point Counting Practices Manual. Release 4.3.1. IFPUG, 2010.
C. Vazquez, G. Simões & R. Albert. Análise de Pontos de Função, Medição, Estimativas e Gerenciamento de Projetos de Software. Saraiva, 2013.
C. Vazquez, G. Simões. Engenharia de Requisitos: Software Orientado ao Negócio. Brasport, 2016.

UX También es Pensar en Productos

sg — Fri, 08 Jul 2016 17:18:11 +0000

UX También es Pensar en Productos

sg Fri, 07/08/2016 - 12:18

Publicado en

SG #51

User eXperience

Autor

Misael León

En general cuando pensamos en UX pensamos en hermosas interfaces fáciles de utilizar y amigables con los usuarios. Pero si ahondamos un poco más nos daremos cuenta que el diseño de interacción y la interfaz (UI) son solamente representaciones visibles de features; las cuales a su vez, conforman una pequeña parte de una estrategia de producto con objetivos bien específicos de negocio.

En los siguientes párrafos trataré de hacer un caso para demostrar que cuando hablamos de UX en realidad estamos hablando de productos.

Dado que por más subjetivo que sea su campo de acción, es decir “el diseño de la experiencia”, no significa que los esfuerzos de UX no puedan ser medidos en función de resultados y métricas financieras.

Esto es así porque la estrategia de UX vive dentro de la estrategia general de producto y mercadeo. No puede existir de manera aislada.

Piensa en problemas no en features

Pensemos ahora en ese producto que estamos diseñando, su razón de existir debe ser siempre la resolución de un problema que los usuarios experimentan. Al hacer esto el producto provee valor a las personas y genera ganancias para el negocio. De ahí que UX sea una parte fundamental para el éxito de los proyectos de software, porque facilita a través de la investigación de usuarios ese descubrimiento del producto ideal que debemos poner en el mercado.

A menudo se dice que los usuarios no saben lo que quieren hasta que lo ven, creo que eso es verdad. Pero ello no significa que un producto no exista en función de una necesidad percibida por el usuario.

Integrar actividades de UX dentro de la estrategia de producto minimiza el riesgo de construir algo que la gente no utilizará. Ya sea porque no lo entiende, porque no refleja su estilo de vida, o simplemente porque no resuelve ningún problema real. El tiempo se encarga de depurar el mercado de software de productos intrascendentes.

Un equipo de desarrollo que construye productos sin entender antes el problema siempre producirá soluciones prematuras. Producirá features robustas que no logran enganchar a las personas. La caída de esos productos será inminente. Serán esfuerzos que no rindieron frutos.

Conoce a tu audiencia

Pensar en productos no es pensar en features, es pensar en el problema que estamos resolviendo. Para esto debemos definir quién es nuestra audiencia. Entender profundamente para qué la gente está usando nuestro producto. Saber cómo viven, cómo piensan, comprender su contexto cultural y el entorno en el cual usan nuestro producto.

Definir UX Personas es siempre una buena idea para alinear el entendimiento del equipo. Hacer entrevistas con usuarios, salir a la calle a observar nuestra audiencia, y realizar talleres para generar este conocimiento son las metodologías que más me han funcionado.

La investigación de usuarios no brinda certeza completa pero es el mejor punto de partida. Es una herramienta efectiva para reducir la incertidumbre y elegir un camino a seguir. Nos permite descubrir problemas con potencial de generar negocio y la dimensión real de cómo estos se presentan. Lo que buscamos es conocer nuestra audiencia para no producir numerosas features sin sentido.

Define la Estrategia de Producto

Existe una concepción equivocada y generalizada que nos hace creer que la responsabilidad de la definición del producto recae únicamente en el product manager; pero de ninguna manera es así. Lo ideal es que desarrolladores, diseñadores, mercadólogos también participen. Todos tienen un pedazo del rompecabezas que hay que resolver. El clan unido con un solo objetivo: construir las features ideales para la audiencia correcta.

Una estrategia de producto se construye contestando las siguientes preguntas [1]:

Dimensión orientada a usuarios:

¿Cuál es el problema que tiene que resolver?

¿Cuál es la audiencia para la cual se va a resolver el problema?

Dimensión orientada al trabajo a realizar:

¿Cuál es la visión detrás del trabajo que haremos?

¿Cómo lo construiremos?

Dimensión orientada a resultados:

¿Qué objetivos nos estamos fijando? ¿Cómo mediremos los resultados que lograremos?

¿Qué features incluye esto que construiremos? ¿Qué vamos a hacer para alcanzar nuestros objetivos?

Con este mapa inicial podemos descartar features innecesarias y comenzar a probar hipótesis sobre lo que creemos es lo idóneo para nuestro producto. Al final nos permitirá crear mejores productos guiando cada decisión que tomemos dentro del contexto de la resolución del problema que nuestra audiencia experimenta.

Recordemos que este problema que estamos resolviendo es la razón fundamental por la cual nuestro producto es usado y por el cual nuestro negocio subsiste.

El equipo de producto ideal

Un equipo de producto idealmente está compuesto por un product manager, un UX designer, y un equipo de entre seis y ocho desarrolladores, incluyendo un QA tester. Dependiendo del tamaño del proyecto también puede incluir un visual designer.

He aprendido que la mejor manera en la que un UX designer puede influir en las decisiones de negocio relativas a producto, es trabajar directamente con el product manager en cada paso del proceso. Uno posee las habilidades que el otro carece, juntos completan el cúmulo de información sobre lo que es deseable construir.

Sin embargo son los desarrolladores los únicos que tienen el conocimiento sobre lo que es posible construir en términos del tiempo disponible. La forma más efectiva de generar ideas de producto es exponer a los desarrolladores directamente al problema. Cara a cara con los usuarios. Esto con el fin de propiciar empatía hacia ellos.

Cuando juntamos “lo que se necesita” con lo que “es posible construir” es cuando surgen los productos realmente valiosos.

Cuando hablamos de UX en el fondo hablamos de productos

Adoptar un enfoque de producto es pensar en soluciones a problemas de gente real. Permite que todo el equipo tenga una visión clara sobre lo que se está construyendo. También facilita descartar peticiones de features nuevas cuando no están alineadas a dicha visión.

Todas las actividades de UX van encaminadas en facilitar la interacción del usuario con el producto de software [2]. Si la interacción es exitosa significa que el UX designer participó desde su conceptualización hasta su implementación, validación y subsecuentes iteraciones.

La responsabilidad de un UX designer no es únicamente la de generar ideas visuales. Es la de lograr que todo el equipo se sensibilice con el problema que se está resolviendo en función de los matices de comportamiento humano que implica.

Esa sensibilización al final del día tomará forma de un producto que deberá ser deseable, técnicamente posible y financieramente sustentable. Es por eso que cuando hablamos de UX en el fondo estamos hablando de productos.

Creo firmemente que identificar problemas sociales reales y brindar una solución centrada en las personas, es una forma honesta de dejar el mundo en mejores condiciones de como lo encontramos. Un producto de software a la vez.

Referencias

N. Kellingley. “Product Thinking is Problem Solving.” Interaction Design Foundation. https://www.interaction-design.org/literature/article/product-thinking-is-problem-solving
M. León. “Cómo Iniciar tu Carrera en UX Design”. Software Guru.
http://sg.com.mx/revista/50/como-iniciar-tu-carrera-ux-design

Bio

Misael León (@misaello) es UX Design Researcher en Nearsoft, Inc. una empresa de cultura democrática que desarrolla software y produce clientes felices. Le apasiona difundir las mejores prácticas de UX en comunidades de diseñadores y desarrolladores.

Liberando el Potencial del IoT

sg — Fri, 08 Jul 2016 17:14:00 +0000

Liberando el Potencial del IoT

sg Fri, 07/08/2016 - 12:14

Publicado en

SG #51

En Portada

Autor

José M. Berruecos

Es posible que el internet de las cosas (IoT, por sus siglas en inglés) todavía sea más un deseo que una realidad, rodeada por cierto nivel de escepticismo integrado, pero esto va a cambiar, y las empresas deben estar preparadas. Las principales empresas alemanas de telecomunicaciones, tecnología y fabricación ya formaron la Alianza del Internet de las Cosas (IoTA, por sus siglas en inglés) para adelantarse a la llegada inminente del IoT. El objetivo es asegurarse de que, cuando los dispositivos empiecen a comunicarse entre sí, lo hagan en alemán. Sin embargo, incluso con toda la planificación, se divisa un bloque molesto en el horizonte: la falta de infraestructura adecuada para administrar la enorme cantidad de datos diversificados, el tráfico, el almacenamiento y las demandas de procesamiento asociadas con el gigante de la IoT.

A medida que el IoT se expande, también aumentan la cantidad de cosas que se conectan a Internet, desde termostatos hasta autos, y la necesidad de tener una infraestructura sólida y poder de procesamiento requerido para respaldarla. Así es como se desencadenaron revoluciones en los centros de datos de todo el mundo.

Hervideros de innovación

El hecho de que los controladores de IoT sean cada vez más pequeños y accesibles hace que sea relativamente fácil habilitar la conectividad de la IoT en todo tipo de dispositivos. No obstante, no solo los refrigeradores y las lámparas pasan a estar en línea, sino que IoT se está usando a escala masiva, lo que posibilita una amplia variedad de innovaciones.

Por ejemplo, hay científicos que están colaborando con vinicultores innovadores en el Valle de Napa para modificar las anticuadas técnicas de irrigación por medio de sensores inteligentes incorporados en las vides [1]. Con la simple transmisión inalámbrica de las lecturas de los sensores, pueden analizar los resultados para determinar en nivel de hidratación de la planta, lo que da a los viñedos rezagados un rendimiento óptimo usando menos agua en una época en la que California se encuentra en una sequía catastrófica ampliamente conocida. Los servicios de salud son un sector que aprovechó rápidamente los beneficios proporcionados por la IoT. Una de estas soluciones es el servicio de administración de medicamentos de Philips [2]. Diseñado para personas mayores que a menudo se olvidan de tomar su medicación, el dispositivo le indica al paciente cuando es la hora de tomar las píldoras. Cuando el paciente presiona el botón, se proporcionan vasos llenados previamente con el medicamento. El dispositivo está sincronizado con la línea de teléfono del usuario, por lo tanto, los mensajes se rastrean si la persona no toma una dosis, si es momento de reabastecer esta o si hay una interrupción en la alimentación, que impide el funcionamiento del dispositivo.

El pronóstico de Gartner [3] es que la cantidad de dispositivos IoT aumentará a aproximadamente 25,000 millones de unidades en 2020. En comparación, se espera que la cantidad total de computadoras, tabletas y teléfonos inteligentes en 2020 sea de solo 7,300 millones de unidades. BI Intelligence [4] espera que este año sea un punto de inflexión en el que la cantidad de dispositivos de la IoT supere la cantidad total de computadoras, tabletas y teléfonos inteligentes por primera vez. Para el final de la década, los dispositivos IoT producirán 40,000 exabytes (40 billones de gigabytes) de datos que deben almacenarse y transformarse en inteligencia significativa.

Relación señal/ruido

El índice de adopción de la IoT dependerá mucho de la facilidad de las empresas para evadir la ley alemana Bundesdatenschutzgesetz (BDSG) y desbloquear y usar la información recopilada, con el elemento clave, ya sea de dispositivos dirigidos a empresas o consumidores, con la aplicación y no el sensor. Con los miles de millones de dispositivos conectados a la red proyectados para aparecer en los próximos años a medida que la tendencia de la IoT empiece a triunfar, los operadores de centros de datos deberán invertir para asegurarse de que sus instalaciones tengan la capacidad de datos suficiente para adaptarse a la afluencia de información que generarán las terminales de la IoT.

El problema es que, en general, el big data generado por la explosión de la IoT tiene una relación ruido/señal muy alta con una gran proporción de datos irrelevantes, que provocan una tasa alta de emisión de datos. El resultado será un impacto inmediato en el ancho de banda necesario desde el centro de datos y hacia este, y en el almacenamiento y el poder de procesamiento dentro de este.

Debido a esto, para que el IoT llegue al tipo de crecimiento proyectado por Gartner y otros, las empresas deberán tener una funcionalidad de centro de datos que pueda manejar esta posible afluencia inmensa de datos. Las inversiones en servicios de plataforma de IoT que residan en el centro de datos serán esenciales para cumplir con la promesa de la IoT de conectividad y contexto en cualquier momento, en cualquier lugar y de cualquier forma.

Es más, IDC advierte que es posible que la IoT no pueda proporcionar el potencial prometido sin que se realicen inversiones urgentes para actualizar los centros de datos en su investigación [5] sobre operaciones y exigencias del centro de datos. El grupo de analistas predice que la capacidad del centro de datos consumida por las cargas de trabajo de la IoT aumentará aproximadamente un 750 % entre 2014 y 2019, lo que presionará a las instalaciones desde el punto de vista de redes, almacenamiento y analítica.

Un cambio en los requisitos de infraestructura

Debido al número de dispositivos conectados y a la cantidad de datos generados, las empresas deben concentrarse en los requisitos de sus plataformas de servicio de IoT a nivel del centro de datos, no solo de los servidores individuales o dispositivos de almacenamiento. Y, con la proyección de IDC que dice que más del 90 % de los datos creados por dispositivos IoT estarán alojados en la nube en los próximos cinco años, los centros de datos son los que sentirán la presión.

No obstante, las empresas que se esfuercen por analizar y comprender los datos generados por la gran cantidad de dispositivos conectados a la red en tiempo real podrían llegar a la conclusión de que los antiguos centros de datos tradicionales no están preparados para esto. En lugar de tratar de cubrir las brechas con la compra de infraestructura según componente, veremos empresas conectadas y modernas que pasan a una infraestructura virtual convergente a fin de ofrecer flexibilidad para los grandes cambios futuros en los datos. Esto llevará al surgimiento de centros de datos de hiperescala construidos sobre infraestructuras convergentes e hiperconvergentes para poder adaptarse a las presiones específicas de la era de la IoT.

Cambio de las percepciones de TI

Para permitir que esto suceda, TI debe cambiar su percepción de un centro de costo a un activador de ingresos. Solo con este cambio de mentalidad una organización podrá aprovechar las ventajas de la IoT. Una vez que la tecnología sea central, las empresas podrán lograr los objetivos de integración, velocidad, escalabilidad y resistencia de una organización transformada digitalmente.

Es posible que haya comenzado con un refrigerador conectado a Internet, pero el IoT sin duda se convertirá en el motivador principal de la expansión de TI a centros de datos más grandes en el futuro, lo que hará más rápida la transición a infraestructuras convergentes dirigidas a la nube que tienen la capacidad para escalar y a arquitecturas de plataforma de datos.

Referencias

http://www.wired.com/2012/10/mf-fruition-sciences-winemakers
http://www.managemypills.com/content
http://www.gartner.com/newsroom/id/2905717
https://intelligence.businessinsider.com
http://www.idc.com/getdoc.jsp?containerId=255397

Bio

José Manuel Berruecos es Country Manager de EMC México.

Cinco Maneras en que el IoT Dará Lugar a un Marketing Más Inteligente

sg — Fri, 08 Jul 2016 17:10:11 +0000

Cinco Maneras en que el IoT Dará Lugar a un Marketing Más Inteligente

sg Fri, 07/08/2016 - 12:10

Publicado en

SG #51

En Portada

Autor

Eduardo Lugo

El Internet de las Cosas puede sonar como un “buzz word” más, pero en realidad se trata de una revolución tecnológica que tendrá un impacto en todo lo que hagamos.

El IoT es la interconexión entre las cosas que utilizan tecnología de comunicación inalámbrica (cada una con sus propios identificadores) para conectar objetos, lugares, animales o personas al Internet, lo que permite tanto la transmisión directa como el intercambio óptimo de datos.

En esencia, se refiere a los dispositivos de todos los días que son capaces de intercambiar información automáticamente a través de una red. El IoT también tiene un gran impacto en nuestras vidas cotidianas, ya que cambia la manera en que el tráfico, el clima, la contaminación y el ambiente se monitorean y la forma en que los datos se recopilan.

El IoT ya se encuentra entre nosotros con Nike Fuelband, Google Glass, Fitbit y los iWatch de Apple —todos ejemplos populares de nuestras vidas cada vez más conectadas—.

He aquí 5 maneras en que el IoT mejorará el ROI (retorno de la inversión) del marketing:

1. Intercambio sencillo de datos de ventas

Uno de los activos más valiosos de cualquier empresa son sus datos de ventas. La capacidad de acceder a información sobre cómo, dónde y por qué se están vendiendo sus productos le permitirá dirigir sus esfuerzos de marketing a clientes específicos.

Los dispositivos inteligentes capaces de recopilar esos datos y proporcionarlos en tiempo real, sin la necesidad de que profesionales en TI manejen y monitoreen la interacción, permitirán a las empresas diseñar estrategias de marketing informadas y mejorar el ROI de las ventas futuras.

Más importante aún, sus clientes podrán ofrecer retroalimentación útil al instante. Por lo tanto, si un producto en específico no está cumpliendo las expectativas, podrá enterarse al momento, lo que significa que podrá reducir las pérdidas más pronto que tarde.

2. CRM más inteligente: Análisis del cliente al instante

Cuando se utilice en conjunto con una buena herramienta de administración de relaciones con el cliente (CRM, por sus siglas en inglés), el IoT podrá hacer mucho más que sólo recopilar y organizar los datos del cliente; podrá también analizar de manera eficaz y precisa los datos para brindar resultados accionables sobre su base de consumidores.

Para los comerciantes eso será invaluable, ya que la cadena de mando del comprador es generalmente larga y las decisiones tardan más tiempo en tomarse. Los dispositivos del IoT pueden acelerar ese proceso al ayudarle a conocer dónde se encuentra el cliente en el proceso de compra y, de esa manera, poder aprovechar cada segundo del día para resolver problemas y proporcionar la información correcta que finalmente ayudará a cerrar la venta.

3. Los dispositivos que están muriendo

Uno de los aspectos más prometedores de los productos con tecnología inteligente es su capacidad de realizar su propio mantenimiento y diagnóstico periódicos.

Los automóviles se autodiagnostican desde hace algún tiempo, aunque a través de un método anticuado que emplea señales imprecisas. Gracias al poder del IoT, cada componente es “más inteligente”, de modo que la capacidad de identificar el problema, así como la solución, será mucho más rápida que antes.

En cuanto a los artículos y dispositivos convencionales, por lo general el primer indicio de que algo está mal es cuando el dispositivo repentinamente deja de funcionar. Cuando eso ocurre, no hay mucho que se pueda hacer, además de repararlo o solicitar uno nuevo y esperar a que llegue.

Los dispositivos del IoT podrían eliminar ese tiempo de espera, ya que constantemente monitorean sus propias funciones y, de ser necesario, contactan al soporte técnico. Y en caso de que detecte un problema grande e irreparable, el dispositivo del IoT puede solicitar fácilmente un reemplazo, de modo que cuando deje de funcionar por completo, el nuevo modelo ya habrá llegado y estará listo para utilizarse.

Lo mismo aplica para las actualizaciones. Muchos usuarios posponen la actualización de sus dispositivos por temor a que ésta resulte defectuosa, tome mucho tiempo en instalarse o simplemente que algo salga mal. Por desgracia, dejar de actualizar el software deja los dispositivos vulnerables a ataques de seguridad o a cuestiones problemáticas conocidas. Los dispositivos del IoT omitirían la intervención del usuario y buscarían, descargarían e instalarían las nuevas actualizaciones por sí solos.

4. Redes sociales predecibles

Cuando Facebook y Twitter aparecieron por primera vez hace ya varios años, la mayoría de los comerciantes no estaban del todo convencidos de que valiera la pena incursionar en esos nuevos sitios de “redes sociales”. Hoy sabemos cuán equivocados estaban. En la actualidad, el 74% de los comerciantes de marcas afirman que el tráfico en sus sitios ha aumentado considerablemente después de invertir tan sólo 6 horas a la semana en esfuerzos de marketing para redes sociales

El IoT ya está optimizado para utilizarse en las redes sociales, ya que permite a los dispositivos publicar y compartir de manera automática y preparar el camino para que las nuevas comunidades en línea se centren alrededor de los usuarios de dispositivos específicos.

Los comerciantes que sean capaces de predecir el desarrollo de esas comunidades sociales y enfocar sus esfuerzos en ellas podrán llegar a los clientes potenciales que quizá antes no estaban disponibles. De la misma manera, los dispositivos del IoT, al combinarse con las redes sociales, permitirán a los comerciantes identificar y aprovechar las nuevas tendencias emergentes.

5. Imagine un CTR (proporción de clics) de 100%

Al unificarse, esos factores apuntan hacia un objetivo final: una publicidad más inteligente y más relevante.

A medida que una cantidad cada vez mayor de nuestros dispositivos y objetos antes desconectados se acondicionen con sensores, y gracias al acceso constante al Internet, la cara de la publicidad cambiará tanto para el comerciante como para el consumidor.

Los comerciantes ya no tendrán que depender de carteles publicitarios ni anuncios emergentes que aparecieron en un sitio web que visitaste el martes, pues la mayoría de los dispositivos del IoT no podrán de ninguna manera procesar, mucho menos desplegar, tan primitivas tácticas.

Como resultado, la era del comercial ininterrumpido finalmente morirá en el lado del consumidor. En su lugar surgirá un nuevo mundo donde la publicidad será útil y relevante, donde nunca aparecerá un anuncio que no corresponda al 100% con los intereses, los hábitos y las compras anteriores del usuario.

¿Cómo será posible? Un ejemplo sería un foco que se funde en la casa “inteligente”. El hogar conectado no sólo registraría la necesidad de reemplazar el foco, sino que también proporcionaría al dueño de la casa un cupón digital para un foco nuevo directamente en su smartphone. Aún mejor, registraría y comunicaría el número exacto de horas que el foco se ha utilizado, lo que permitiría al dueño saber que el foco está por concluir su ciclo de vida.

Eso no sólo permitirá al cliente ahorrar tiempo al recibir únicamente anuncios relevantes, sino que los comerciantes ya no tendrán que gastar sumas estratosféricas en publicidad irrelevante.

Los comerciantes necesitarán entender por completo a sus consumidores para poder aprovechar las nuevas oportunidades que surjan, pero aquellos que logren realizar esa transición descubrirán que el IoT les brindará la oportunidad de dejar de ser comerciantes para finalmente convertirse en recursos empresariales valiosos.

Bio

Eduardo Lugo es vicepresidente de Ventas para Latinoamérica de salesforce.com

El Mayor Valor de Negocio del IoT son los Datos

sg — Fri, 08 Jul 2016 17:05:09 +0000

El Mayor Valor de Negocio del IoT son los Datos

sg Fri, 07/08/2016 - 12:05

Publicado en

SG #51

En Portada

Autor

Samuel Dos Reis

Mucho del enfoque al hablar del Internet de las Cosas se centra en “las cosas” mismas, como los wearables, sensores, beacons, y otros equipos conectados a la red. Sin embargo, el mayor valor para las organizaciones proviene de la combinación de datos generados por estos dispositivos con otros datos del cliente u operacionales para descubrir otras ideas y establecer modelos predictivos. Esta es la increíble promesa del IoT, pero sin la capacidad de vincular los datos de las cosas “inteligentes” conectadas con otros datos de negocio, su valor es limitado.

En lugar de proyectos de IoT aislados que no están conectados a la infraestructura corporativa central de datos, hay una oportunidad de usar los datos generados por el IoT para crear valor real de negocio. Las organizaciones pueden combinar datos de los clientes obtenidos de distintos dispositivos con otros datos de los clientes para obtener nuevas perspectivas e identificar nuevas señales sobre el potencial de compra o cambios de comportamiento. Este conocimiento puede llevar a las empresas a un entendimiento más profundo y una mayor capacidad de respuesta a los clientes. Por ejemplo, las tiendas pueden combinar datos obtenidos por beacons dentro de la tienda con el historial de transacciones y almacenar modelos de comportamientos de los clientes para determinar mejores promociones o diversas acciones a tomar, tales como notificar al personal de la tienda que un cliente VIP ha llegado.

También hay enormes oportunidades de poner los datos de IoT a trabajar en modelos predictivos para mejorar horarios de mantenimiento o proporcionar un servicio “justo a tiempo”, antes de que el producto falle. Por ejemplo, muchos dueños de vehículos eléctricos reciben reportes de diagnósticos remotos con información sobre fallas o próximos servicios a necesitar, basados en interpretación de los datos generados por el vehículo.

El reto que muchas organizaciones enfrentan es cómo entender de forma sistemática los datos derivados de “las cosas” y combinarlos con otros datos relevantes de la empresa para crear valor. Los datos del IoT generalmente consisten en archivos de bitácora, a veces mal relacionados, y al parecer no estructurados; de hecho, los datos del IoT tienen estructura, aunque no están en un formato tradicional relacional o estándar. Las archivos de bitácora se estructuran e incluyen puntos de datos de medición que varían de un fabricante a otro, de un modelo a otro, de una versión de software a otra e, incluso de una compañía a otra. Por ejemplo, los terabytes de datos procedentes de un motor de reacción de un jet, difieren por aerolínea, así como por fabricante y modelo. Como otro ejemplo, productos para la agricultura automatizada y maquinaria industrial, todos con ellos con diferentes modelos y variantes, tienen cientos o miles de distintos formatos de archivos de registro procedentes de sus productos usados por clientes alrededor del mundo. Esto introduce una complejidad significativa en cualquier intento de interpretar los datos, darles formato, normalizarlos y combinarlos con otros datos relevantes para su análisis o para sistemas operacionales. Sin estas herramientas que ayuden a interpretar y analizar los datos del IoT, el tiempo y esfuerzo invertido será costoso, prolongado y propenso a errores manuales.

Con el fin de comprender plenamente el valor de combinar los datos del IoT con otros datos de la empresa de manera ágil, las organizaciones deberán aprovechar las modernas herramientas de gestión de datos para acelerar y automatizar los procesos. Utilizando herramientas para clasificar los datos, descubrir su estructura de forma inteligente, para luego extraerlos automáticamente y combinarlos con otros datos relevantes de la empresa de forma continua, hace que los datos del IoT sean más accesibles. Esto crea una infraestructura para una expansión y evolución continua en el uso de los datos del IoT para entender a los clientes y crear modelos predictivos para los sistemas operativos.

Las empresas pioneras infraestructura para IoT están creando soluciones innovadoras que combinen modelos interactivos, visuales de los datos con aprendizaje automatizado, a su vez agilizando la capacidad de obtener valor del negocio a través del IoT. Una vez que el modelo de datos para un dispositivo en particular es entendido, mapeado y preparado, la transformación y la entrega de datos a los sistemas puede ser automatizado para un uso productivo.

En una era en la que vivimos en una mayor conectividad de las cosas, es tiempo de capitalizar toda la explosión de información que resulta de ellas, y poner orden a través de una correcta integración, calidad y limpieza de datos para que las empresas tomen mejores decisiones y generen productos y servicios específicos acordes a cada consumidor.

Bio

Samuel Dos Reis es VP para Latinoamérica de Informatica LLC.

El Salvavidas del IoT en la Evolución Tecnológica

sg — Fri, 08 Jul 2016 17:01:20 +0000

El Salvavidas del IoT en la Evolución Tecnológica

sg Fri, 07/08/2016 - 12:01

Publicado en

SG #51

En Portada

Autor

Esteban Montelongo

Actualmente, cuando hablamos del internet de las cosas ya no se trata de hablar de comunicación entre computadoras, eso solo es parte de redes internas y externas. El internet de las cosas tiene una palabra clave: things, que básicamente describe las “trillones de cosas” que no tienen relación con una computadora como tal, pero que emiten datos e información relevante.

Bajo esta perspectiva, resulta indispensable tomar en cuenta la evolución de la información que ahora es posible obtener vía sensores, provenientes por ejemplo de equipos electrónicos.

En la actualidad, una empresa de retail puede calcular la reposición de sus inventarios, así como distribuir sus productos de acuerdo a un detector ubicado dentro de los refrigeradores de los consumidores. Basta con solo abrir la puerta del refrigerador y sacar un determinado producto, para que esto pueda ser identificado por los sensores como un “faltante” para que así esos datos se envíen de manera inmediata al proveedor, garantizando la venta de dichos productos en tiempo y forma, de acuerdo a los patrones de compra específicos de los consumidores y asegurando, incluso, el envío a la puerta del hogar… ¡Fascinante! ¿No?

Dentro de estas “things”, podemos mencionar a los equipos, máquinas y dispositivos que se utilizan dentro de las diferentes industrias tales como los sistemas de medición de temperatura, irrigación, emisión y/o consumo de combustible, señalización o bien, equipos de salud, tanto de uso personal, como equipos más sofisticados, entre muchos otros.

Sin embargo, para no ahogarse con la gran ola de información, el salvavidas vendrá marcado por los datos que resulten realmente valiosos, filtrados y maniobrados vía herramientas de analítica avanzada así como con arquitecturas que la soporten.

Esta oportunidad de facilitar la información en tiempo y forma así como la flexibilidad para crear modelos de predicción, asociación y clasificación, sin duda alguna está contribuyendo al nuevo éxito de las compañías.

Por ejemplo, hoy en día, el monitoreo de fletes vía sensores ya no solo otorga información sobre el seguimiento del paquete, sino que también puede monitorear las condiciones del transporte a través del trayecto, ¿cuánta humedad había en el contenedor?, ¿el paquete fue abierto o inspeccionado? Con las respuestas a la variedad de preguntas, se tendrá un control preciso de los productos durante el trayecto, con lo que las compañías aseguradoras podrán crear nuevos modelos de aseguramiento y también contar con el detalle de las características del siniestro ocurrido, evaluando el pago de una póliza. Por su parte, el área de logística utilizará esta información para mejorar sus operaciones. Es simple, ahora podemos saber cuándo, dónde y cómo se realizó un determinado evento.

De acuerdo con datos de Gartner, para el año 2020 se calcula que el valor de la economía dentro del IoT sea de 1.9 trillones de dólares, derivada básicamente por las nuevas ofertas dirigidas a un usuario final tales como smart watches, wireless lighting entre otros, así como las orientadas a la operación y automatización de sistemas dentro de una manufacturera, en donde el mayor impacto se verá hasta dentro de algunos años.

La oportunidad para generar nuevas fuentes de ingresos, ventas y reducción de costos, entre otros problemas de negocio, resulta ser sumamente sencilla y simple, incorporando el salvavidas idóneo que sepa sacar provecho de las “cosas” que la evolución de la tecnología nos brinda.

Bio

Esteban Montelongo es Arquitecto de soluciones para analítica avanzada en Teradata.

El Impacto Real del IoT en las Empresas

sg — Fri, 08 Jul 2016 16:55:07 +0000

El Impacto Real del IoT en las Empresas

sg Fri, 07/08/2016 - 11:55

Publicado en

SG #51

En Portada

Autor

Jorge Alvarado

En el Internet de las Cosas, los objetos cotidianos son parte de una red que envía y recibe datos de otras “cosas”. Para los consumidores esto significa capacidades como poder ajustar el termostato de su hogar desde el otro lado del mundo. Pero para las empresas, el puede representar nuevas oportunidades para conectarse con sus clientes y socios, así como reunir, almacenar y analizar grandes volúmenes de datos. La gama de posibilidades que el IoT ofrece va en aumento y ahora las empresas de todo el mundo comienzan a andar los caminos destinados a aprovecharlo. Su impacto, sin duda, revolucionará la manera en que las empresas están haciendo negocio y elevará la productividad y eficiencia, similar a lo que sucedió con la llegada de las computadoras.

En su reporte TechRadar, Forrester revela que 23% de las empresas ya utilizan el IoT, mientras que 29% planean hacerlo en los próximos 12 meses. Aprovechan el IoT para transformar sus modelos de negocio, optimizar la utilización de activos físicos y financieros, y crear nuevas formas de relacionarse con sus clientes. De igual modo, Forrester prevé que el IoT creará grandes volúmenes de datos, por lo que la analítica de IoT se convertirá en una categoría y disciplina especializada. Por su parte, Gartner calcula que para cuando finalice 2016 el gasto en servicios de IoT alcanzará los $235 mil millones de dólares, y que más de la mitad de los nuevos procesos de negocio y sistemas incorporarán algún elemento del IoT para el año 2020.

Mientras los teléfonos móviles, los smart TVs, electrodomésticos y autos inteligentes pueden seguir captando la imaginación de los consumidores, es posible ver que hay mucho que ganar con las implementaciones empresariales. A diferencia de los sensores integrados en los dispositivos de consumo, aquellos integrados en maquinaria, contenedores, trenes, plantas de producción o puntos de venta, por ejemplo, están generando la información para crear aplicaciones en logística, redes inteligentes, servicios públicos, transportación, manufactura y retail.

Pero más allá de los sensores y dispositivos, el valor real del IoT es determinado por los datos y las nuevas aplicaciones que los aprovechan. La inteligencia de estos datos está dando paso a nuevos modelos de negocio y aplicaciones que nunca habían existido antes y que abren la puerta a la transformación digital.

Los alcances del IoT Empresarial

A continuación listo algunos ejemplos de aplicaciones empresariales:

Manufactura inteligente. El servicio o función de una máquina o una parte de ella pueden mejorar antes de que se presente una falla, eliminando así los costosos tiempos de inactividad y eventualidades no previstas.

Cadenas inteligentes de suministro. Proporcionando información en tiempo real de la oferta, demanda y envíos a los clientes. Las entregas pueden ser rastreadas y recuperadas si son extraviadas o robadas.

Infraestructuras inteligentes. Las oficinas inteligentes contribuyen a generar ahorros de energía, mejorar la autosustentabilidad y potenciar la colaboración entre los empleados.

Decisiones en fracción de segundos

¿En qué radica la diferencia entre el IoT de consumo y el empresarial? Los casos de uso de IoT de consumo se crearon sobre una arquitectura en la que el dispositivo se conecta a internet aprovechando la red WiFi del hogar, o puenteando por medio de un teléfono móvil.

En este modelo, el dispositivo transmite todos los datos a un centro de datos en la nube, donde se realiza el análisis y, si se requiere una acción, se envía el mensaje correspondiente al dispositivo para que dispare la acción necesaria. Fundamentalmente, esta arquitectura funciona en este modelo por dos razones: la disponibilidad del ancho de banda y a que no hay que tomar decisiones rápidamente.

En una aplicación de consumo en la que el dispositivo se conecta a la nube por medio del WiFi del hogar, el uso de ancho de banda no tiene un costo adicional para el cliente, ya que típicamente son planes con transferencias de datos ilimitadas. Sin embargo, las conexiones en las empresas tienen más restricciones y cada byte cuenta. De hecho, reducir un solo byte de un mensaje puede ahorrarle a la empresa millones de dólares en costos de transmisión en los casos de uso del IoT industriales. Por lo tanto, se ha vuelto crucial para las arquitecturas de IoT considerar el ancho de banda en sus diseños.

En segundo lugar, para los consumidores típicamente no es crítica la cantidad de tiempo que se necesita para tomar decisiones. En contraste, en un entorno empresarial de misión crítica, las decisiones se miden en fracciones de segundo. Por ejemplo, si el sensor de bajo voltaje de una red eléctrica esperara tres minutos para liberar capacidad adicional cuando el voltaje comienza a disminuir, todas las redes podrían colapsar y perderse miles de millones de dólares en equipo.

De ahí que las empresas deban ser lo más ágiles posible y reaccionar de inmediato a la información que están recabando en tiempo real. Gartner habla del TI Bimodal, en donde las empresas por un lado tienen sistemas de cómputo tradicionales de alto rendimiento (modo 1), y por otro lado aplicaciones escalables y datos en la nube que requieren de agilidad para adaptarse a un mundo cambiante (modo 2). Típicamente el código abierto contribuye con éste último modo, ayudando a las empresas a innovar, ser más productivas y adoptar nuevas tendencias como la nube, la virtualización y el Internet de las Cosas, al tiempo de ahorrar costos y mejorar la seguridad.

Estas consideraciones nos permiten ver que una arquitectura de dos niveles es muy lenta para los datos importantes, y demasiado costosa para los que no lo son. En el plano empresarial surge una arquitectura de tres niveles creada alrededor de una nueva capa media (o el controlador). Estos controladores son lo suficientemente inteligentes para actuar rápidamente, al tiempo de enviar de vuelta únicamente los datos importantes el centro de datos. Este concepto, conocido como de Near Field Processing, permite que las decisiones se tomen más rápidamente y requiere que una menor cantidad de datos viaje hasta el centro de datos. Actuar ágilmente al final reduce los costos de transmisión y el tiempo para tomar decisiones, lo que le permite hacer del Internet de las Cosas una realidad para la empresa.

En el pasado, solo las compañías con más presupuesto podían beneficiarse de reunir datos de los dispositivos distribuidos para tomar mejores decisiones y obtener valor adicional. Hoy, las economías de la arquitectura de IoT: el hardware, la naturaleza ubicua de la conectividad, el big data y las soluciones de software empresarial en todas las capas, acompañan a la experiencia del usuario para ampliar el IoT, y lo hacen posible para que las empresas, no solo los consumidores, se beneficien.

Bio

Jorge Alvarado es Jefe de Arquitectura en Red Hat México.