SG #52

Contenedores: Un poco de historia

sg — Wed, 12 Oct 2016 08:19:44 +0000

Contenedores: Un poco de historia

sg Wed, 10/12/2016 - 03:19

Publicado en

SG #52

Programar es un Estilo de Vida

Autor

Gunnar Wolf

Recuerdo la primera vez que tuve contacto con la virtualización. En 2005, en un congreso, participé en un breve taller en el que nos presentaron esta (entonces) característica tan única de las arquitecturas IBM de gama alta: los servidores s390.

¡Parecía magia! Varios sistemas operativos corriendo a velocidad nativa, compartiendo armónicamente una misma computadora. Un hipervisor gestionando y mostrando estadísticas de uso en tiempo real. Claro, a esas alturas yo ya conocía el mecanismo que empleaba VMWare para virtualizar sobre la arquitectura PC desde fines de los noventa, pero la diferencia en el rendimiento y la confiabilidad era muy notoria. Por esos años, relativamente muy poca gente consideraba la oferta de VMWare para entornos de producción.

Un año más tarde, el panorama cambió radicalmente. Tanto Intel como AMD comenzaron a incorporar extensiones de virtualización en sus procesadores de arquitectura x86 —las instrucciones y niveles de protección necesarios para permitir este mágico aislamiento que hasta entonces estaba reservado a los sistemas de muy alto costo. Si bien la virtualización apareció primero en la gama alta de estas compañías, hoy en día (diez años más tarde) prácticamente todos sus procesadores las incluyen. Y sí, cambiaron fuertemente la forma de trabajo en los centros de datos, las ofertas de servicio de los proveedores de infraestructura— y permitieron el nacimiento del, permítanme esta redundante cacofonía, nebuloso término de "la nube".

Por un par de años, hubo un claro surgimiento de la “virtualización basada en hardware”. Proveedores de servicio de todo tamaño comenzaron a ofrecer “servidores privados virtuales” a precios que antes nunca hubiéramos esperado. Los administradores de sistemas de todo el mundo comenzamos a cambiar nuestra mecánica de trabajo, “particionando” el trabajo que realizaban nuestros grandes servidores monolíticos en cargas especializadas, a ser repartidas en cuantos servidores virtuales fuera necesario. No tardaron en aparecer numerosas tecnologías base, libres y propietarias.

De virtualización a paravirtualización

Quedaba aún mucho por mejorar, sin embargo, si bien la ejecución de código dentro de las máquinas virtuales ocurría ya a velocidad nativa, había inocultables capas de emulación que era necesario cruzar. ¿A qué me refiero? Una máquina virtual aparenta ser una computadora completa, al lanzar una, vemos cómo una interfaz comparable con el BIOS lanza al gestor de arranque, el sistema operativo se inicializa… la máquina virtual cree tener las tarjetas de red, unidades de disco y demás periféricos que le indiquemos (que normalmente corresponden con modelos simples y antiguos). El manejo del video es particularmente curioso; lo más común es que se presente como una tarjeta de video tonta, sin aceleración 3D, que interfacea mediante un framebuffer. Todos estos dispositivos tienen que ser emulados, y toda emulación tiene su costo.

Hoy en día, prácticamente la totalidad de herramientas de virtualización ofrece más bien un híbrido, entrando al terreno de la paravirtualización. ¿Qué es? Es cuando el engaño no es completo, cuando el hardware virtual ofrecido al sistema operativo ya no pretende ser una computadora completa, sino que el sistema operativo huésped “sabe” que está siendo virtualizado y coopera en la tarea. Esta cooperación estiba en que, en vez de buscar controlar a su hardware como si fuera real, lo toma como un buffer glorificado y envía, más bien, solicitudes al anfitrión (host) para cumplir lo que los programas requieren. Una diferencia aparentemente sutil, pero que —sobre todo en los casos de cargas de trabajo orientadas a la entrada y salida, como las bases de datos y el manejo de red— típicamente llevan a una diferencia de rendimiento de diez veces tanto.

Virtualización y paravirtualización brindan grandísimas ventajas a los administradores, y una en la que insistiré en este punto es que el “engaño” es a nivel sistema entero, cada computadora virtual puede ejecutar un sistema operativo distinto completo. Esto es particularmente útil al hablar de proveedores de servicio en la nube, pues cada cliente tendrá la flexibilidad absoluta de correr en su computadora el software que desee. Sin embargo, hacia adentro de las organizaciones, sigue siendo subóptimo.

Raíces, jaulas, contenedores

Como siempre, la respuesta a una nueva necesidad viene del pasado, con nuevas maneras de emplear lo ya conocido, de refinamientos técnicos que mejoran la implementación de la idea —y en este caso, de la mano de bastante mercadotecnia que llevó a mucha gente a ver hacia el lugar obvio.

Los contenedores pueden definirse como virtualización a nivel sistema operativo. Los usuarios de máquinas virtuales ya no serán engañados con lo que parece ser una computadora completa, sino que únicamente con algo que dice ser un sistema operativo dedicado a ellos. Y, siendo el sistema operativo el principal encargado de agrupar al hardware en clases, gestionar su manipulación de bajo nivel, y proveer abstracciones uniformes para los programas que corren en espacio de usuario… la diferencia es enorme.

Pero vamos por partes, ¿cómo se originaron los contenedores?, ¿cuáles son las ideas primigenias?

En 1982, Bill Joy, uno de los arquitectos del Unix de BSD y fundador de Sun Microsystems, creó la llamada al sistema chroot() para auxiliarse en el desarrollo de Unix. Dado que desarrollaba en la misma computadora donde hacía sus pruebas, quería poder mantener aislado su entorno de desarrollo y construcción del entorno de pruebas. La manera más sencilla (y, además, elegante) de hacerlo es por medio de esta llamada, se invoca con un argumento, y a partir del momento en que un proceso la llama con el nombre de un directorio y hasta el final de su ejecución, el sistema operativo le dará a dicho proceso una vista parcial del sistema, limitada al directorio que le es indicado. Esto es, tras un chroot('/home/gwolf/test'), si el proceso en cuestión da un cd /, el sistema operativo lo llevará a /home/gwolf/test.

En los manuales de sistema es común encontrar advertencias de seguridad — chroot() no está pensado para proveer aislamiento, únicamente conveniencia — Hay varias maneras por medio de las cuales un proceso puede escapar de esta jaula, además de que su funcionamiento se limita a restringir la vista del sistema de archivos, sin proteger otros aspectos del sistema como las interfaces de red, la lista de procesos, o el acceso a dispositivos.

El primer sistema operativo en ofrecer lo que hoy conocemos como contenedores (bajo el nombre de jails) fue la versión 4 de FreeBSD, liberada en el año 2000. Poco después, esta funcionalidad apareció en Solaris, Linux e incluso para Windows; en los dos últimos casos, esto fue inicialmente mediante productos de terceros (Parallels Virtuozzo Containers para Windows, Vserver y OpenVZ para Linux, OpenVZ siendo una rama libre de Virtuozzo). Varios años después de la introducción de esta funcionalidad por medio de terceros, tanto en el caso de Linux (con lxc desde 2009) como recientemente en el de Windows (desde 2015) han sido incorporados a la plataforma base del sistema operativo.

La virtualización a nivel sistema operativo implica que los contenedores engañarán a los procesos huéspedes presentándoles una vista limitada en los siguientes aspectos:

Tablas de procesos
Señales y comunicación entre procesos (IPC)
Interfaces de red
Dispositivos de hardware
Límites en el consumo de recursos (espacio en disco, memoria, o ciclos de CPU)
Información del sistema, como el nombre del equipo o la hora actual

Esto permite a los árboles de procesos que habitan dentro de un contenedor tener una vista de sistema completo, viéndose obligados a respetar las asignaciones de recursos de los demás contenedores. Uno de los principales atractivos para los administradores de sistemas es que un contenedor cuyos servicios no están siendo activamente utilizados permanece efectivamente dormido, con un nivel de consumo de recursos verdaderamente mínimo — A diferencia de la virtualización de sistema entero, en este caso el sistema operativo conoce directamente todos los eventos a que están esperando cada uno de los procesos, y mientras dicho evento no ocurra, los contenedores no pasarán de ser una estructura en memoria.

A últimos años, los contenedores se han ido popularizando ya no únicamente como una herramienta para que el administrador de sistemas particione lógicamente la carga de trabajo de servidores o provea infraestructura de cómputo con acceso privilegiado a distintos usuarios manteniendo garantías de seguridad, sino también como mecanismo de distribución de software, instalado y preconfigurado —la implementación más conocida es el proyecto docker. En lo particular, como administrador de sistemas de vieja guardia y formado en la escuela tradicionalista, le veo importantes carencias a su planteamiento… pero sin duda ha logrado una importante penetración de mercado.

Como sea, la tecnología de contenedores es una genial herramienta con la que contamos hoy, que ha cambiado de raíz la manera en que se despliegan los servicios. Invito a todos los lectores que no se hayan aún adentrado a comprenderla y utilizarla, a no dudar en hacerlo.

Bio

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

Designing Software Architectures: A Practical Approach

sg — Wed, 12 Oct 2016 08:14:37 +0000

Designing Software Architectures: A Practical Approach

sg Wed, 10/12/2016 - 03:14

Publicado en

SG #52

Arquitectura

Autor

Humberto Cervantes

En esta ocasión tengo el gusto de compartir con ustedes la noticia de la reciente publicación del libro que escribí junto con mi colega Rick Kazman quien es investigador en el Software Engineering Institute (SEI). Nuestro libro lleva por título “Designing Software Architectures - A Practical Approach” (Diseñando Arquitecturas de Software - Un Enfoque Práctico) y fue publicado por la editorial Addison Wesley en la colección “SEI Series in Software Engineering”.

Nuestro libro se enfoca en el método de Diseño Guiado por Atributos (Attribute-Driven Design), o ADD; un método de diseño de arquitecturas originalmente creado por el Software Engineering Institute y del cual hablé en la columna “Diseño de la Arquitectura”, en SG 29. A pesar de que ADD ha existido por más de una década, se ha escrito relativamente poco al respecto y es difícil encontrar ejemplos de cómo llevarlo a cabo. Esta falta de información ha complicado su adopción y enseñanza. Además, la información que se ha publicado acerca de ADD tiende a ser un tanto abstracta y puede ser difícil conectarla con los conceptos, prácticas y tecnologías que los arquitectos usan en sus actividades cotidianas.

Rick y yo hemos guiado a arquitectos de software durante años en la realización del proceso de diseño y, al mismo tiempo, hemos estado aprendiendo de ellos; por ejemplo, que en la práctica los arquitectos consideran la tecnología de forma temprana en el proceso de diseño y esto es algo que no era parte de la versión original de ADD. Por tal razón, el método original parecía “desconectado” de la realidad para la gente de la industria. En este libro presentamos una versión revisada de ADD en la cual hemos tratado de reducir la brecha entre la teoría y la práctica.

Durante varios años, hemos estado también enseñando arquitectura de software y la manera en que se realiza el diseño de la misma. Nos hemos dado cuenta que a la gente que no tiene experiencia le es muy difícil diseñar arquitecturas. Este entendimiento nos empujó a crear una “hoja de ruta” que creemos será útil para guiar en la realización del proceso de diseño. También creamos un juego que es útil para enseñar acerca del diseño de arquitecturas, y que se puede considerar como un complemento al libro (ver “Smart Decisions: Un juego para aprender Arquitectura y Big Data” en SG 49).

Nuestro libro está dirigido a cualquier persona que esté interesada en el diseño de arquitecturas de software. Creemos que será particularmente útil para los practicantes que deben realizar esta tarea, pero que actualmente la realizan de forma ad hoc. Los practicantes con experiencia que ya realizan el diseño siguiendo un método establecido también encontrarán nuevas ideas, por ejemplo, cómo dar seguimiento al proceso de diseño usando un tablero Kanban o cómo analizar el diseño usando cuestionarios basados en tácticas. Por último, la gente que está familiarizada con otros métodos del Software Engineering Institute encontrarán información acerca de la manera de combinar ADD con métodos tales como el taller de atributos de calidad QAW, el método de análisis de compromisos arquitectónicos ATAM (ver SG 31) y el método de análisis de costos beneficios CBAM.

Este libro también será útil para estudiantes y profesores de programas de ciencias de la computación o de ingeniería de software. Creemos que los casos de estudio que describimos ayudarán a entender a través de ejemplos la manera de realizar el proceso de diseño más fácilmente. Como dijo Einstein: “El ejemplo no es otra manera de enseñar, es la única manera de enseñar”.

Esperamos que nuestro libro permita entender que el diseño puede realizarse siguiendo un método y que el hacerlo de esta manera es de gran ayuda para producir mejores sistemas de software.

Su estructura es de la siguiente manera siguiente:

En el capítulo 1 presentamos una introducción breve del concepto de arquitectura de software y del método ADD.
En el capítulo 2 discutimos acerca del diseño de arquitecturas de manera más detallada, junto con las entradas principales al proceso de diseño a las cuales llamamos los drivers de la arquitectura. Además, hablamos de los conceptos de diseño que son ‘bloques de construcción’ a partir de los cuales se construye la arquitectura y que permiten satisfacer estos drivers usando soluciones probadas.
El capítulo 3 presenta el método ADD de forma detallada. Presentamos cada uno de los pasos del método junto con varias técnicas que pueden ser usadas para llevar a cabo estos pasos de manera adecuada.
El capítulo 4 presenta un primer caso de estudio que ilustra el desarrollo de un sistema “desde cero”. Para este caso de estudio, hemos hecho un esfuerzo por mostrar la manera en que la mayoría de los conceptos descritos en el capítulo 3 son usados en el proceso de diseño, así que este caso de estudio tiene una naturaleza más “académica” (aunque se deriva de un sistema del mundo real).
El capítulo 5 presenta un segundo caso de estudio que escribimos junto con arquitectos de software expertos en big data y, por ello, tiene muchos más detalles técnicos que el anterior. Este caso de estudio describe los detalles finos de cómo usar ADD en el diseño de un sistema de big data que involucra diversas tecnologías. Este ejemplo ilustra también lo que consideramos un diseño en un dominio “novedoso”, a diferencia del dominio más tradicional usado en el capítulo 4.
El capítulo 6 es un caso de estudio más corto que describe el uso a ADD para realizar la extensión de un sistema legado, lo cual es una situación común en la práctica. Este ejemplo demuestra que el diseño arquitectural no es algo que se realice una sola vez, al inicio del desarrollo del sistema, sino que más bien es una actividad que puede ser realizada en distintos momentos del proceso de desarrollo.
El capítulo 7 presenta otros métodos de diseño. En nuestra revisión de ADD, adoptamos ideas de otros autores que también han investigado el proceso de diseño y aquí resumimos brevemente sus enfoques como un homenaje a sus propuestas y como una comparativa de ADD a estos métodos.
El capítulo 8 discute acerca del tema del análisis de forma detallada. Aún si el tema principal de este libro es el diseño, el análisis se realiza naturalmente como parte del mismo, así que aquí describimos técnicas de análisis que pueden ser usadas durante el proceso de diseño o después de que una parte del diseño ha sido completada. En particular, describimos el uso de cuestionarios basados en tácticas, los cuales son útiles para entender de forma simple y rápida las decisiones que se realizan durante el proceso de diseño.
El capítulo 9 describe la manera en que el proceso de diseño embona a nivel organizacional. Por ejemplo, es posible realizar cierta cantidad de diseño en los momentos más tempranos del ciclo de vida con el fin de realizar la estimación del proyecto (ver “Arquitectura y Preventa” en SG 46). Mostramos también cómo ADD puede ser usado con distintos enfoques de desarrollo, como por ejemplo, con las metodologías ágiles o con métodos más establecidos como el Team Software Process (TSP).
El capítulo 10 concluye el libro.

Incluímos también dos apéndices. El A presenta un “catálogo de conceptos de diseño” que, como su nombre indica, es un catálogo de distintos tipos de conceptos de diseño que pueden ser usados para un dominio aplicativo particular (ver “Conceptos de Diseño: Patrones, Tácticas y Frameworks” en SG 38). Este catálogo presenta conceptos de diseño que recopilamos de distintas fuentes y refleja la manera en que los arquitectos con experiencia trabajan en el mundo real. En este caso, el catálogo contiene una muestra de conceptos de diseño usados en el caso de estudio presentado en el capítulo 4. El apéndice B provee un conjunto de cuestionarios basados en tácticas para los siete atributos de calidad más comunes, así como un cuestionario adicional para DevOps.

Conclusión

Debo decir que me llena de orgullo el haber escrito un libro para la prestigiosa colección editorial del Software Engineering Institute que, además, es el nuevo material de referencia para el curso “Software Architecture Design and Analysis” que se imparte en el SEI. Espero que sea de mucha utilidad para la comunidad de desarrollo en México y en el resto del mundo.

Quiero aprovechar para agradecer a Pedro Galván y su equipo por la oportunidad que me han dado a lo largo de estos años de escribir esta columna de arquitectura de software. Como se puede apreciar en las distintas referencias que hice a números pasados de la revista, muchos de los temas desarrollados de forma detallada en el libro han sido presentados de forma resumida a lo largo de los años en esta columna.

Para terminar, incluyo una liga en donde se puede adquirir el libro: https://goo.gl/Wd01TL

Bio

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

La Capacitación como Agente de la Transformación

sg — Wed, 12 Oct 2016 08:09:00 +0000

La Capacitación como Agente de la Transformación

sg Wed, 10/12/2016 - 03:09

Publicado en

SG #52

Carrera

Autor

Omar Sánchez

La capacitación práctica y teórica en Tecnologías de Información es de vital importancia, y necesaria a fin de ampliar el desempeño de las actividades de los profesionales del sector, debido a que las organizaciones son cada vez más dependientes de ellas para soportar y mejorar los procesos de negocio que demandan cumplir las necesidades de los clientes y de la propia organización. Esto requiere de una estrategia y transformación bien definida para la mejora del software que las empresas necesitan, por lo que cabe preguntarnos ¿qué valor o aporte le estamos dando al cliente, colaboradores o accionistas, con el uso de este tipo de tecnologías?

Actualmente la capacitación en TI para los profesionales dedicados a la gestión contribuye al desarrollo profesional, y por tanto al económico de las empresas que prestan interés al tema, ya que los servicios de TI conforman la base del modelo de negocio en su totalidad para cualquier tipo de empresa, por ello, las compañías deben encontrar mecanismos que transmitan información relacionada con las actividades de su organización brindando a sus colaboradores conocimientos, habilidades y actitudes que se pretenden para lograr a través de las mejores prácticas en gestión de servicios de TI, un desempeño óptimo.

Lamentablemente muchas organizaciones consideran que la formación profesional de TI es un gasto innecesario, sin darse cuenta que es todo lo contrario, ya que puede ofrecer resultados positivos así como una optimización en la calidad de la infraestructura en el software que maneja la propia organización; es decir, es una inversión que trae beneficios al colaborador, a la organización y, lo más importante, al cliente o usuario final.

Dentro de la industria de TI existen organismos que centran su importancia en el desarrollo de mejores prácticas ITIL (Information Technology Infrastructure Library, por sus siglas en inglés), que se basa en una colección de documentos públicos, fundamentados en procesos y en un marco de optimización en la industria, permitiendo la Gestión de Servicios de TI con calidad y a un costo adecuado, por supuesto que para ello es importante una capacitación en ITIL enfocada a los profesionales involucrados con todos aquellos procesos que se necesitan ejecutar dentro de las organizaciones para la administración y operación de la infraestructura de TI, de tal forma que logre una excelente provisión de servicios a los clientes bajo un esquema de costos congruentes con las estrategias del negocio.

La biblioteca de ITIL se ha convertido en el estándar mundial de capacitación y actualización para la gestión de servicios Informáticos que genera una sinergia entre personas, procesos y tecnología. Tal es el caso de ITSMF (Information Technology Service Management Forum), que anualmente realiza un congreso en la Ciudad de México, sobre dichos temas.

Algunos de los beneficios de una capacitación ITIL para una adecuada gestión del servicio en las tecnologías de información son: maximiza la calidad del servicio apoyando al negocio de forma expresa, ofrece una visión clara de la capacidad del área TI, aumenta la satisfacción en el trabajo mediante una mayor comprensión de las expectativas y capacidades del servicio, minimiza el ciclo de cambios y mejora los resultados de los procesos y proyectos TI, incrementa la rentabilidad del negocio.

Las TI aportan de manera más que sustancial los elementos para lograr las metas y objetivos, cuantitativos como cualitativos, de cualquier tipo de organización o industria, por ello es imposible lograr una gestión exitosa de negocio sin el manejo apropiado de dichas tecnologías. En las organizaciones no solo deben existir mecanismos alineados a los objetivos tácticos como estratégicos, sino también para el resguardo de los activos informáticos, pero sobre todo en capacitación, para saber cómo hacerlo con base a las mejores prácticas normas, guías y estándares.

Bio

Omar Sánchez es un consultor especializado en Gestión de Servicios de TI. Actualmente dirige la empresa O2 Systems y es Presidente de ITSMF México, además de ser profesor de asignatura en la Universidad Iberoamericana en el área de Gobierno de TI.

Asegurando la Calidad de la Experiencia de Usuario

sg — Wed, 12 Oct 2016 08:03:33 +0000

Asegurando la Calidad de la Experiencia de Usuario

sg Wed, 10/12/2016 - 03:03

Publicado en

SG #52

Calidad

Autor

Roselyn Piñango

Según el ISTQB (International Software Testing Qualifications Board), uno de los objetivos de las pruebas, es satisfacer compromisos aplicando la validación de los requisitos de usuario respecto al sistema que está siendo objeto de la prueba. Igualmente este estándar define las pruebas de sistema como aquellas que se realizan desde la perspectiva del usuario y predomina como protagonista el equipo de QA para ejecutarlas [1]. Por otro lado, uno de los atributos no funcionales de la calidad según la norma ISO9126 es la usabilidad que consiste en la capacidad que tiene un software de ser amigable, atractivo y útil al usuario final. Ahora bien, el dinamismo tecnológico ha permitido que usuarios no expertos interactúen con la tecnología como parte de su día a día haciéndolos más exigentes. La validación de requisitos, pruebas de sistema y la usabilidad ya no son suficientes, es necesario que las pruebas incluyan en su alcance la experiencia de usuario (UX).

La experiencia de usuario es el conjunto de factores y elementos relativos a la interacción del usuario con dispositivos o software tecnológico cuyo resultado es la generación de una percepción positiva o negativa de dicho servicio, producto o dispositivo. Ésta depende no solo de los factores relativos al diseño sino además de aspectos relativos a las emociones, sentimientos, confiabilidad y transmisión de la marca (2). El diseño de la experiencia del usuario se define como el proceso de aumentar la satisfacción y lealtad del cliente mediante mejoras en la usabilidad, facilidad de uso y el placer de la interacción entre el cliente y el producto.

El diseño de experiencia de usuario se preocupa por un número mayor de variables que el diseño de interfaz de usuario y no necesariamente están relacionadas con el aspecto visual, por ejemplo: la presentación de los productos, redacción de contenidos, la velocidad de carga, entre otros factores. Algunos de los principios de este tipo de diseño son el color, eficiencia, error humano, estética, íconos, jerarquía visual, legibilidad, mapeo natural y visibilidad, entre otros. Definitivamente esto compromete aún más a los especialistas en ingeniería de requisitos y en sí, al proceso de interacción con los usuarios de manera que el equipo de desarrollo y pruebas pueda conocer las pautas, funcionalidades y expectativas que debe cumplir el sistema.

En el ámbito de las pruebas, esto significa que no será suficiente la base de pruebas que utiliza un equipo de QA (listado de funcionalidades) sino es necesario comprender claramente cuál es la motivación del sistema, qué beneficios traerá, qué se busca con su construcción y qué se espera de él. Para ello es necesario que las pruebas de calidad de la experiencia de usuario cuenten con la participación del usuario, pero no significa que estas pruebas deban realizarse al final del ciclo de vida de desarrollo, al contrario, debe ser una de las primeras exploraciones (por ejemplo por medio de prototipos) a realizar dentro del enfoque de pruebas definido respetando el principio “pruebas tempranas” de ISTQB. Pudiera ser un nuevo nivel de pruebas híbrido probador/usuario.

De de las pruebas más conocidas en este ámbito son las A/B que consisten en dos escenarios controlados que se envían/cargan de forma aleatoria a los usuarios (normalmente una muestra de ellos) con el objetivo de medir la efectividad de un diseño de interfaz y/o contenido en específico. Otro tipo de prueba utilizada es la llamada think aloud (piensa en voz alta) en donde se le solicita al usuario que utilice el sistema, narrando sus pensamientos y percepciones del mismo mientras navega por las funcionalidades del sistema. Lo importante es que se contemple desde QA que las pruebas del diseño de experiencia de usuario no es tarea única del profesional de QA, se trata de un trabajo conjunto con el usuario, y aunque algunos autores califican estas pruebas como “costosas”, sin duda no es equivalente a desarrollar un sistema que no sea utilizado cuando esté en producción.

Conclusión

La tecnología avanza y los usuarios son cada día más exigentes con los sistemas que reciben para su rutina laboral o vida diaria, lo cual significa un reto adicional para los profesionales de QA, en donde el objetivo de satisfacer compromisos lo obliga a ser un tecnólogo multidisciplinario que debe garantizar la mejor experiencia de usuario posible, funcionalidad (y otros atributos de la calidad) bajo la arquitectura idónea para el contexto donde se ejecutará el sistema, convirtiéndolo en un profesional integral.

Referencias:

“Foundation Level Syllabus”. ISTQB, 2011. http://swgu.ru/rt

Bio

Roselyn C. Piñango Díaz es Ingeniero en Computación con especialización en Sistemas de Información. Gerente de QA Factory en Global R, Venezuela. Cuenta con 10 años de experiencia en desarrollo y pruebas de software; y certificaciones: OCE SQL, OCA PL/SQL Developer, CTFL ISTQB, ASE HP ALM v11, CAA SAPB1.

Special Purpose Languages, parte 4

sg — Wed, 12 Oct 2016 07:59:18 +0000

Special Purpose Languages, parte 4

sg Wed, 10/12/2016 - 02:59

Publicado en

SG #52

Prueba de Software

Autor

Luis Vinicio León Carrillo

En el número anterior mostramos la Jerarquía de lenguajes de Chomsky, que se construye considerando la complejidad de la estructura de las reglas del conjunto R que define cada tipo de lenguaje. Partamos ahora no de las gramáticas, sino de los lenguajes, y apliquemos unas extensiones: llamamos…

Lenguajes Regulares(o de Tipo 3, o de manera corta Lgs3) a aquellos que pueden definirse utilizando Gramáticas Regulares, cuyasreglas son de la forma A→ B d | d (o menos compleja).

(Nota: las reglas podrían ser de la forma A→ d B | d , pero no se pueden mezclar ambas formas en una misma gramática.)

Lenguajes Libres de Contexto (o Tipo 2, o Lgs2) a aquellos que pueden definirse utilizando Gramáticas Libres de Contexto, cuyasreglas son de la forma A→ α (o menos compleja).

Dentro de estos lenguajes existen varias divisiones. Una de las más relevantes es la que diferencia entre los lenguajes determinísticos y los no-determinísticos; un ejemplo de estos últimos es an bn ∪ an b2n , que como podrán intuir, para procesarlo es necesario que el compilador asociado realice backtracking.

Lenguajes Sensibles al Contexto (o Tipo 1, o Lgs1) a aquellos que pueden definirse utilizando Gramáticas Sensibles al Contexto, cuyasreglas ó son de la forma a) β1Aβ2→β1αβ2 (o menos compleja), donde α≠λ ; ó b) θ→α (o menos compleja), donde |θ| ≤ |α| .
Lenguajes Estructurados por Frases (o Recursivamente Enumerables,o Tipo 0, o Lgs0) a aquellos que pueden definirse utilizando Gramáticas Estructuradas por Frases, cuyas reglas son de la forma θ→ α (o menos compleja), donde θ≠λ.

Dentro de estos Lgs0 se encuentra la importantísima clase los Lenguajes Decidibles (o Recursivos,o Lgsdec), que son aquellos para los que es posible construir programas (por ejemplo compiladores) que siempre terminan y anuncian si la cadena sí es elemento del lenguaje o si no lo es (aunque para ello consuman cantidades considerables de tiempo y memoria). Las reglas con las que se definen tienen la misma forma que los Lgs0.

Podemos ver a los Lgs0 como lenguajes semi-decidibles: los programas que los procesan (por ejemplo compiladores) pueden determinar cuando las cadenas sí son elementos del lenguaje, pero cuando no es así continúan su procesamiento indefinidamente.

Lenguajes Generales (o Lgsgral) a aquellos que incluyen a todos los anteriores y a los que no son susceptibles de ser definidos con reglas.

En esta jerarquía ocurre (obviando algunas precisiones) que Lgs3⊂≠ Lgs2⊂≠ Lgs1⊂≠ Lgsdec⊂≠ Lgs0 ⊂≠ Lgsgrals.

Esto enuncia con mayor exactitud lo que mencionamos sobre la cantidad de programas (|N|) y de lenguajes (|2N|): de todo el universo de lenguajes Lgsgrals, solamente para los Lgsdecpodemos escribir procesadores que determinan cuando las cadenas sí forman parte del lenguaje y también cuando no es así.

Ejemplos de especificaciones usando gramáticas

Especifiquemos ahora con gramáticas los lenguajes que definimos “algebraicamente” en el número anterior:

L1 : am bn cidk , para m, n, i, k ≥ 0 e independientes entre sí:

E → λ | a E | b | b F | c | c G | d | d H

F → b | b F | c | c G | d | d H

G → c | c G | d | d H

H → d | d H

Como pueden observar, se trata de una Gramática Regular.

Escribamos lo que se denomina una derivación para a2 b3 c1 d0 :

E → a E → aa E → aa F → aab F → aabb F → aabbb F → aabbb G → aabbbc G → aabbbc H → aabbbc λ → aabbbc

Este tipo de gramáticas son equivalentes a las conocidas expresiones regulares, y como veremos en seguida, son suficientes para especificar los “scanners” de los compiladores, los cuales se encargan del análisis lexicográfico.

L2 : am bi ci dm , para m, i ≥ 0 que aparecen por pares y están “anidadas”:

E → a E d | F

F → b F c | λ

Este es un ejemplo “clásico” de una Gramática Libre de Contexto.

He aquí una derivación para a2 b3 c3 d2 :

E → a E d → aa E dd → aa F dd → aab F cdd → aabb F ccdd → aabbb F cccdd → aabbb λ cccdd

→ aabbbcccdd

(Si hacemos a = ( , b = { , c = } , y d = ) tenemos el caso concreto que mencionamos en la revista anterior.)

Este tipo de gramáticas son equivalentes a los conocidos grafos de sintaxis, y son suficientes para especificar los parsers de los compiladores, los cuales se encargan del análisis sintáctico.

L3 : am bi cm di , para m, i ≥ 0 , que aparecen por pares pero no están anidadas:

S → V | λ
V → a V Y | a c | X
X → b X Z | b Z
Z Y → Z T1 , Z T1 → Y T1 , Y T1 → Y Z /* Reglas que abreviaremos como Z Y → Y Z */
b Y → b c
c Y → c c
c Z → c d
d Z → d d
b Z → b d

Excepto por el λ en la primera regla, que es indispensable porque el lenguaje genera λ, y que es aceptable porque solo la genera el Símbolo-inicial, la anterior es una Gramática Sensible al Contexto: en las 3 primeras reglas no hay contexto (β1= λ y β2= λ, volviéndolas Libres de Contexto); en las restantes ocurre que β1= λ o que β2= λ .

He aquí una derivación para a3 b2 c3 d2 :

S → V → a V Y → a a V Y Y → a a a V Y Y Y

→ a a a X Y Y Y → a a a b X Z Y Y Y → a a a b b Z Z Y Y Y

→ a a a b b Z Y Z Y Y → a a a b b Y Z Z Y Y → a a a b b Y Z Y Z Y → a a a b b Y Y Z Z Y

→ a a a b b Y Y Z Y Z → a a a b b Y Y Y Z Z → a a a b b c Y Y Z Z → a a a b b c c Y Z Z

→ a a a b b c c c Z Z → a a a b b c c c d Z → a a a b b c c c d d

Con este tipo de gramáticas se podrían especificar (al menos buena parte de) los Sistemas de Tipos de los lenguajes de programación, los cuales definen sus aspectos semánticos (de significado, como los del paso de parámetros que mencionamos, o la equivalencia de tipos). Sin embargo, dado que el procesamiento de estas gramáticas es más complejo y costoso en tiempo que el de las Libres de Contexto, y que la mayoría de los constructos de los lenguajes de computación son de este último tipo, los aspectos semánticos también se suelen abordar apoyándose en gramáticas Libres de Contexto y en una Tabla de Identificadores (en la cual suele almacenarse, entre otras cosas, su nombre, clase (si es variable, procedimiento, función, etc.), tipo (v.gr. integer, string, 〈char, real〉→ boolean), y dirección).

Lenguajes y Compiladores

Obviando algunas precisiones, un compilador suele tener una estructura como la siguiente:

Grosso modo, su funcionamiento es como sigue:

Cada vez que el scanner (Analizador Léxico) es llamado, reanuda su lectura de caracteres del Código Fuente escrito en el Lenguaje1; se salta caracteres irrelevantes (como una secuencia de comentarios, blancos, y/o saltos de línea) y luego concatena los que sí son relevantes hasta completar una cadena que tenga significado por sí misma (por ejemplo “{“, “main” y “contador” en el lenguaje C); en seguida detecta si la cadena es una palabra reservada (como “main”), un símbolo (como “{“,) o un identificador (como “contador”), en cuyo caso lo busca en la Tabla de Identificadores y si no lo encuentra lo da de alta; finalmente, regresa esta información a la subrutina que lo llamó, usualmente el parser.

El parser (Analizador Sintáctico) suele ser el componente central del procesamiento de un compilador. Manda llamar al scanner, el cual le regresa la cadena que acaba de completar y la información que mencionamos arriba. Con esos datos, el parser busca seguir alguna de las reglas gramaticales del lenguaje; en caso de no encontrar alguna envía un mensaje de error. En su procesamiento va utilizando y actualizando la Tabla de Identificadores (por ejemplo, escribiendo si el Identificador es el nombre de una subrutina o de una variable, así como su tipo), va construyendo el Árbol Sintáctico del programa en cuestión (ver un ejemplo en seguida), y va ejecutando instrucciones que tiene “embebidas”, tanto del Analizador Semántico que revisa cuestiones relacionadas principalmente con tipos de datos (para lo cual se apoya en la Tabla de Identificadores), como del Generador de Código (el cual también se apoya en esa Tabla) para ir construyendo el Código Objeto con instrucciones en el Lenguaje2.

El árbol sintáctico para la cadena a2 b3 c3 d2 del lenguaje L2, descrito arriba, se muestra en la siguiente figura. En ella se puede observar que se parte de S0 y se van generando ramificaciones sustituyendo no-Terminales mediante la aplicación de alguna regla de la gramática; las hojas del árbol acaban siendo Terminales o λ.

Compiladores y Arquitectura

La investigación en Arquitectura de Software ha estado motivada principalmente porque los sistemas han venido creciendo en tamaño y complejidad, haciendo que el tema de mayor preocupación no sean ya tanto los algoritmos y las estructuras de datos, sino la interacción entre los constituyentes del sistema.

Esta investigación puede verse como una continuación natural del desarrollo de mecanismos de abstracción en los lenguajes de programación, los cuales buscan facilitar el desarrollo de sistemas:

Los primeros programas de software fueron escritos en lenguaje máquina. La inserción de una nueva instrucción podía requerir tener que revisar manualmente el programa completo, lo cual motivó el desarrollo de Ensambladores Simbólicos, que hacían actualización automática de referencias y permitían utilizar nemónicos en lugar de códigos de operación de instrucciones. Los posteriores procesadores de macros fueron más allá y permitieron que un solo símbolo fuera sustituido por una secuencia de instrucciones.
Después se detectaron patrones de ejecución comunes, como la evaluación de expresiones aritmético-algebraicas, el llamado a subrutinas, así como las instrucciones de alternación (como el “if”) y de repetición (como el “while”).

Luego se detectaron también patrones en el uso de datos, que condujeron al desarrollo de Sistema de Tipos que incluían tipos básicos y constructores de tipos.

Después vino la introducción de módulos, que permitió “aislar” subrutinas y tipos de datos para impedir su modificación, y proveer interfaces de los mismos solamente para su uso a (el resto de) los programadores.
Hoy se trabaja en la formalización de Patrones Arquitectónicos para poder procesarlos con lenguajes formales, facilitando la construcción de la arquitectura los sistemas.

Es común que la arquitectura de un producto de software se defina formalmente como un grafo dirigido definido por: a) un conjunto (finito) de nodos, que son los componentes del producto (subrutinas, datos, etc.); b) un conjunto (finito) de conectores entre los nodos (interacciones como llamadas, accesos a datos, etc.); y (eventualmente) c) un conjunto de restricciones e invariantes sobre los grafos (v.gr. la ausencia de ciclos).

En la literatura especializada se han documentado varios patrones arquitectónicos. Dos de ellos son:

Pipelines: en ellos los componentes son programas que llamamos filters y que se ejecutan secuencialmente, y los conectores, que llamamos pipes, son los flujos de datos entre ellos.

Inicialmente (en los 70’s), la arquitectura de un compilador se veía como un pipeline:

Repositories: uno de los tipos más importantes de repository son los blackboards, en los cuales hay una(s) estructura(s) de datos central(es) a la(s) que se conectan los componentes, la(s) cual(es) dirige(n) la ejecución de los mismos.

La arquitectura de los compiladores se ha venido sofisticando y hoy en día tiene más bien una estructura de blackboard como la que mostramos al inicio de la sección anterior.

Los compiladores pueden ser un muy buen ejemplo al abordar el tema de los patrones arquitectónicos:

facilitan el estudio de la necesidad y aplicabilidad de patrones a la luz de la complejidad y sofisticación el producto en cuestión a lo largo del tiempo (como hemos intentado hacerlo aquí, si bien superficialmente);
cuando se construyen compiladores se aprovechan los avances en el procesamiento de lenguajes formales para generar automáticamente el blackboard y utilizar meta-lenguajes especializados (como como las Expresiones Regulares, la notación BNF, y los Grafos de Sintaxis) con los cuales se especifica la instancia del compilador específico, así como para aplicar el método de análisis sintáctico que resulte más conveniente.

Podremos abundar sobre este tema en números posteriores.

Bio

Luis Vinicio León Carrillo es Director General y co-fundador de e-Quallity. Fue profesor-investigador en la universidad ITESO. Realizó estudios de posgrado en Alemania, durante los cuales abordó temas relacionados con la prueba de software y los métodos y lenguajes formales.

Cómo Aumentar la Lealtad de tus Usuarios en Aplicaciones Móviles

sg — Wed, 12 Oct 2016 07:53:44 +0000

Cómo Aumentar la Lealtad de tus Usuarios en Aplicaciones Móviles

sg Wed, 10/12/2016 - 02:53

Publicado en

SG #52

User eXperience

Autor

Misael León

Hablemos de cuando los usuarios abandonan nuestra aplicación y no vuelven más. Ese duro momento que nos duele tanto a los equipos de productos. Si está sucediendo con tu app no te sientas solo; es de hecho un suceso promedio en la industria de software y es tan alto que es impresionante.

Los datos duros dicen: la media de las aplicaciones en el mercado pierde 77% de sus usuarios después de 3 días de haberla instalado. Dentro de 90 días sube a 95% [1]. El terror encarnado. Pero, ¿qué hacer al respecto? A continuación veamos las causas más comunes y algunas soluciones para ponerle fin a la pesadilla.

Causas comunes de abandono

Hay distintas razones para que un usuario abandone una aplicación. Exploremos una de las más recurrentes, cuando creamos una barrera inicial justo después de haberla instalado.

1. Un proceso de onboarding confuso

Onboarding es la actividad de educar a los usuarios respecto a cómo funciona nuestra aplicación o tal vez sobre los beneficios de utilizarla. Son una serie de pantallas informativas colocadas al inicio de la interacción.

Usualmente nuestra intención de educar es genuina. Sin embargo, es común abusar de este recurso y presentar mucha información en una sola pantalla, o ceder a la tentación de hablar de todas las funcionalidades que nuestro producto es capaz de hacer. Esto ocasiona que nuestros usuarios terminen sintiéndose abrumados y confundidos. Recuerda que lo que ellos quieren es experimentar tu aplicación de inmediato, usar el juguete nuevo. Déjalos descubrirla por sí mismos.

Solución. Realiza entrevistas con algunos de tus usuarios (entre 8 y 10 será suficiente) para entender cómo tu producto encaja en su estilo de vida. De esto aprenderás a identificar qué los motiva y qué los frustra. También podrás conocer sus hábitos personales y de consumo. De esta manera podrías seleccionar el tipo de onboardingprocess adecuado. A continuación describo los tipos de onboarding más comunes:

Orientado a beneficios: es cuando describimos en esas pantallas iniciales la transformación que el usuario experimentará si utiliza nuestra aplicación. Tal vez será más feliz, más saludable, más conectado con sus amigos, más organizado. Quizás ganará acceso a millones de canciones o recomendaciones de recetas. Estos son beneficios subjetivos. Recomiendo no ir más allá de 4 o 5 pantallas.
Orientado a funciones: aquí es cuando describimos lo que la aplicación hace propiamente. Tal vez permitirá crear listas de reproducción inteligentes, compartir información en redes sociales u obtener recomendaciones de expertos. Estos son beneficios objetivos que tu producto brindará. Recuerda que el usuario ya está convencido de utilizarla, dado que ya la ha instalado. Así que ten máximo 3 o 4 pantallas y úsalas para sorprenderlos con algo inesperado.
Orientado a funcionalidades específicas: cuando tu producto funciona de manera diferente al estándar del mercado o cuando es algo radicalmente nuevo, lo ideal es indicar dónde están ciertas funcionalidades y explicar cómo usarlas. Es decir, en dónde los usuarios podrán crear listas de reproducción, cómo podrán exportar información o cómo sacar mayor provecho de alguna búsqueda tal vez. Es ideal utilizar entre 3 a 4 pantallas. Dejemos que las personas gocen de su deseo innato de descubrir lo nuevo por sí mismas.

No existe una solución única que sea adapte para todas las aplicaciones. Puedes considerar incluso no utilizar ningún tipo de onboarding en absoluto. Una interfaz intuitiva debería ser capaz de explicarse a sí misma.

2. Llenar un perfil muy largo

¡Hurra! Tenemos un usuario nuevo, pidámosle todos los datos posibles para conocerlo mejor. Errrrr. Esta es una práctica nociva. Pedirle mucha información a un usuario cuando recién llega es como si entraras a una tienda y te pidieran llenar una encuesta para identificarte. Piensa, ¿realmente necesitas el número teléfonico de inmediato?

Pedir a los usuarios que llenen un perfil muy largo antes que experimenten tu aplicación los hará sentirse atrapados. De nuevo, los ponemos muy lejos del juguete nuevo.

Solución. Lo más sencillo es pedirles hacer login mediante servicios conocidos como Google o Facebook. De no ser posible puedes definir un perfil modelo de tus usuarios. En UX le llamamos Persona [2]. La información base la puedes obtener a través de entrevistas, analizando tus analíticos o realizando encuestas. De esta manera podrás tener una visión aproximada de quiénes son ellos exactamente. Entendiendo sus hábitos y estilo de vida, puedes determinar qué información te es relevante y cuáles datos están dispuestos a proporcionar. La diversidad moderna hace del uso de perfiles una necesidad. Por ejemplo, no podemos tratar de igual manera a una mamá que a un millennial, ambos tienen una visión del mundo muy diferente.

3. Limitaciones en las versiones

Imagina que vas a comprar una carro nuevo, de inmediato sientes la adrenalina que experimentarás al manejarlo y mueres por hacer una prueba de manejo. Pero por alguna razón desconocida la agencia solamente te deja encender el carro, pero no manejarlo. ¡Imposible! Esto nunca sucede. Y sin embargo constantemente vemos esta situación en las aplicaciones móviles.

Cuando bloqueamos funcionalidades de nuestro producto, no estamos dejando a los usuarios “probar” la mercancía antes de comprarla. Solamente causamos frustración cuando ponemos a los usuarios en la situación de comprar una versión completa sin antes dejarlos evaluarla.

Soy creyente fiel de los trial versions, por tanto dejar a las personas utilizar una versión completa para sentirse seducidos por las bondades de tu aplicación, hará que suban tus cifras de conversión. Después de todo, nos medimos la ropa antes de comprarla, probamos una muestra de galletas antes de decidirnos por una caja. Nuestro comportamiento en el mundo real no es tan diferente al mundo digital.

Solución. Realiza A/B testing [3] para determinar qué incluir en tu trial. Por ejemplo, puedes liberar una versión lite con cierto número de funcionalidades, digamos 4 de 10, y mides el nivel de conversión de compra de la versión completa. Posteriormente, liberas otra versión con 7 de 10 funcionalidades y mides si la conversión mejoró.

4. Configuraciones iniciales complicadas

Creemos saberlo todo. Es por eso que a menudo no leemos los manuales de lo que compramos. Esto es excepcionalmente cierto para los productos digitales. Poner a los usuarios a llenar configuraciones complicadas y robustas antes de dejarlos experimentar tu aplicación es como ponerlos a leer un manual. Lo que termina ahuyentando a cualquiera.

Si tu producto realmente necesita cierto tipo de configuraciones iniciales por parte de tus usuarios, piensa primero cuáles de esas pueden ser predefinidas o cuáles pueden ser completadas en una ocasión posterior.

Solución. Realiza pruebas de usabilidad para determinar en qué parte del proceso de configuración tus usuarios se confunden y abruman. Si pruebas la configuración inicial con 5 personas [4] podrás descubrir los problemas más críticos de usabilidad de tu aplicación. Los datos que obtendrás serán útiles para determinar esos momentos bajos que tu usuario experimenta al ir llegando a tu aplicación. De esta manera podrás determinar más fácilmente qué configuraciones predeterminar, cuáles posponer y cuáles otras deben ser redefinidas para hacerlas más sencillas.

El largo camino del abandono a la lealtad

Sin duda, el éxito del producto con los usuarios está determinado desde el día uno de uso. Esto no es tan fácil como parece, requiere de una medición esmerada sobre lo que funciona y lo que no funciona. Es por eso que realizar investigación de usuarios es necesario para entender por qué la gente termina abandonando nuestra aplicación.

Las aplicaciones que hoy en día son exitosas, lo son porque han logrado convertirse en parte indispensable de la vida de las personas; piensa en Facebook o Snapchat.

Con tantas opciones, la competencia entre apps es intensa. Liberar tu aplicación al mercado no es garantía de éxito, ya que es una entre miles. El aprendizaje continuo es lo que hará fuerte a tu equipo de producto. ¿Ya estás listo para salir a investigar?

Referencias

A. Chen. “New data shows losing 80% of mobile users is normal, and why the best apps do better.” http://swgu.ru/rj
S. Carter and J. Christ. “Avoiding Bullshit Personas”. Presentación: http://swgu.ru/rk Audio: http://swgu.ru/rl
J. Cardello. “Define Stronger A/B Test Variations Through UX Research.” Nielsen Norman Group. http://swgu.ru/rm
J. Nielsen. “Why You Only Need to Test with 5 Users.” Norman Nielsen. http://swgu.ru/rn

Bio

Misael León (@misaello) es un UX Designer que trabaja en Nearsoft investigando usuarios, desarrollando ideas de productos y diseñando prototipos. Su misión es la de crear herramientas intuitivas para que otros puedan realizar su trabajo. Le apasiona difundir las mejores prácticas de UX en comunidades de diseñadores y desarrolladores.

El Desarrollo de Baja Codificación ya no es Opcional

sg — Wed, 12 Oct 2016 07:41:16 +0000

El Desarrollo de Baja Codificación ya no es Opcional

sg Wed, 10/12/2016 - 02:41

Publicado en

SG #52

Estrategia de TI

Autor

Aad van Schetsen

El desarrollo de aplicaciones con baja codificación (low-code development) no es nada nuevo. En muchos sentidos, es simplemente una rama de la tendencia 4GL de las décadas los 80 y 90. Pero el mundo de la tecnología ha cambiado y hoy en día, la baja codificación se ha vuelto más relevante que nunca.

De acuerdo con Forrester, el mercado mundial para el desarrollo con baja codificación eclipsará los 10 mil millones de dólares en 2019. Eso tiene sentido, ya que las fortalezas de dicha estrategia —iteraciones rápidas, colaboración simple, y fácil mantenimiento a largo plazo— se complementan perfectamente con las necesidades de las empresas que requieren llevar de manera eficiente aplicaciones móviles comerciales, de escritorio, de nube y arquitecturas cliente-servidor.

En pocas palabras, si tienes que competir en la creciente industria del software, es necesario el desarrollo con baja codificación. A continuación comparto cinco razones de por qué hacerlo:

Colaboración casi en tiempo real entre las áreas de Negocio y TI

Las aplicaciones son hechas por desarrolladores, no necesariamente para desarrolladores. No importa qué tan elegante sea la interfaz de usuario, o qué tan intuitiva sea la experiencia de usuario, una aplicación que no concuerda con los objetivos de negocio es, en cierto nivel, un fracaso.

Afortunadamente, aquí es donde el desarrollo con baja codificación brilla en particular. Debido a que la cantidad de codificación manual de bajo nivel se reduce drásticamente, el desarrollo avanza muy rápido. Lo que le lleva a un desarrollador días o semanas programar manualmente, puede en muchos casos realizarse en horas con herramientas de baja codificación. Como resultado, los stakeholders pueden ver su visión tomar forma rápidamente, dejando tiempo para ajustes rápidos. Los desarrolladores y los usuarios de negocios disfrutan de una colaboración en tiempo casi real y del intercambio de ideas, en lugar de la metodología tradicional iterativa de “prueba y error”.

Adicionalmente, en el desarrollo de baja codificación basada en modelos, la aplicación es derivada directamente de las reglas del negocio. El comportamiento de la aplicación no está impulsada solo por el código sino por la misma lógica del negocio. En tal escenario, los requerimientos del negocio y la aplicación están íntimamente ligados; la aplicación debe ajustarse a igualar las reglas de negocio más exigentes, ya que están inextricablemente "construidas al mismo tiempo".

Aumento del enfoque del desarrollador hacia la funcionalidad

Las empresas contratan trabajadores expertos con altos conocimientos esperando que sean eso —expertos en su área. Cuando se trabaja en una plataforma de desarrollo con baja codificación, los programadores pasan menos tiempo “escribiendo” genérico y más tiempo creando objetos que representan la funcionalidad de muchas líneas de código. Esto aumenta considerablemente la productividad potencial de cada desarrollador, se consiguen resultados más rápido y se mejora la utilización de sus habilidades únicas.

Despliegue transparente, independiente de plataforma

En un proyecto de baja codificación, los desarrolladores trabajan en la definición de modelos y se centran en la interfaz y experiencia de usuario, en lugar de preocuparse acerca de cómo se implementará la aplicación a través de diferentes arquitecturas. El despliegue de una aplicación con baja codificación es completamente transparente; no importa el paradigma o plataforma que se utilice —nube, servidor, web, móvil, cualquiera que sea— todos los datos se extraen de localidades específicas en el modelo, con la configuración necesaria y con muy poca codificación adicional.

Los desarrolladores pueden concentrarse en hacer una genial aplicación dentro del contexto de los requisitos de negocio y no tener que preocuparse por el entorno de implementación, ya que muchas de las tareas de bajo nivel que participan en el despliegue de una aplicación orientada a objetos son eliminadas.

Adecuada para el uso a largo plazo

La velocidad y facilidad con la que una aplicación de baja codificación puede ser modificada no termina en el despliegue. Puesto que tales aplicaciones siguen siendo muy fáciles de mantener —ya que los ajustes del modelo afectan a muchos elementos individuales— es especialmente adecuado para el uso a largo plazo. Añadir soporte para una nueva tecnología o plataforma es simple, y los requisitos de negocio cambiantes se pueden resolver eficientemente de manera extraordinaria.

Una sola base de código con menor margen de error

En el desarrollo tradicional de aplicaciones, es común ver una disminución gradual en la calidad y facilidad de uso. La primera iteración se ve muy bien, pero luego hay ajustes y cambios en las necesidades de los usuarios. Pasa otra iteración y sucede lo mismo. Conforme se acerca la fecha de entrega, la aplicación comienza a parecer un muégano, adiciones tardías que se aplican a las prisas, y con distintos criterios de calidad. Esto se ve agravado por el hecho de que muchos cambios de última hora afectan componentes centrales de la aplicación, creando una situación donde las funciones más importantes tienen la menor calidad.

En contraste, en el desarrollo con baja codificación, los desarrolladores trabajan en una simple línea base de código limpio. Las modificaciones se realizan una vez, y se extienden a lo largo del desarrollo de la aplicación, debido a que el proceso general es más sencillo. Los usuarios de negocio pueden proporcionar retroalimentación temprana durante el proceso, multiplicando el beneficio. La modificación de los requisitos y especificaciones se pueden abordar de forma cuidadosa y metódica, en lugar de manera previa o posterior al lanzamiento.

Conclusión

Mediante la eliminación de código de bajo nivel que se programa de manera manual, se aumenta el tiempo que los desarrolladores dedican a tareas de alto valor. El desarrollo con baja codificación permite a los equipos producir rápidamente aplicaciones que se alinean estrechamente con los objetivos de negocio. El despliegue —sin importar la plataforma— es simple y consistente, y las aplicaciones conservan un alto nivel de calidad pensando a futuro. No es la respuesta a todos los retos de programación —siempre habrá un lugar para Java, .NET y otros frameworks orientados— pero el desarrollo con baja codificación está encontrando cada vez más su lugar dentro de los equipos de desarrollo modernos.

Bio

Aad van Schetsen es CEO de la empresa Uniface. Cuenta con tres décadas de experiencia en la industria, con un liderazgo demostrado y profundo conocimiento en negocios empresariales, administración general, software y TI.

Prerrequisitos para una Implementación Exitosa de la Entrega Continua

sg — Wed, 12 Oct 2016 07:31:41 +0000

Prerrequisitos para una Implementación Exitosa de la Entrega Continua

sg Wed, 10/12/2016 - 02:31

Publicado en

SG #52

DevOps

Autor

Cyrille Le Clerc

La entrega continua está ganando rápidamente la atención de las organizaciones, ya que ayuda a satisfacer la demanda creciente para entregar software de manera ágil. Con su énfasis en mantener el software en un estado “listo para despliegue” en todo momento, es una evolución natural de las prácticas de integración continua y desarrollo ágil de software. Sin embargo, los retos culturales y operacionales para lograrlo son mucho más grandes que dichas prácticas. Para la mayoría de las organizaciones, la entrega continua requiere la adaptación y extensión de los procesos existentes de liberación de software. Los roles, relaciones y responsabilidades de la gente en toda la organización también pueden ser impactados; por otra parte, las herramientas utilizadas para entregar, actualizar y mantener el software deben apoyar la automatización y colaboración en forma apropiada, con el propósito de minimizar demoras en el despliegue de nuevos servicios y proporcionar ciclos de retroalimentación rápida en toda la empresa.

Las organizaciones que están buscando hacer la transición a la entrega continua deben considerar los siguientes siete prerrequisitos. Son pasos prácticos que les permitirán ejecutar en forma exitosa los cambios culturales y operacionales dentro del marco legal y funcional en el cual operan.

Los equipos de desarrollo, QA y operaciones deben tener metas compartidas y comunicarse

Mientras que la integración continua limita el alcance del equipo de desarrollo, la entrega continua incluye las fases de prueba del equipo de aseguramiento de calidad (QA) y los despliegues a producción manejados por el equipo de operaciones. Esto es un cambio de paradigma importante, y para tener éxito evolucionando una práctica de integración continua a entrega continua, es crítico que los equipos de desarrollo, QA y operaciones tengan un modelo de gobernanza (governance) compartido. La colaboración y la comunicación son componentes vitales del desarrollo exitoso de software hoy en día, y en un ambiente de entrega continua tienen que tomar el centro del escenario.

La integración continua debe funcionar antes de moverse a la entrega continua

La entrega continua es una extensión de la integración continua, su prerrequisito es tener la integración continua implementada y funcionando, incluyendo control de versiones, y construcción automatizada (automated builds) con pruebas unitarias y pruebas automatizadas.

Automatiza y haz versiones de todo

La entrega continua involucra la repetición continua de muchas tareas tales como hacer builds, desplegar aplicaciones y configuraciones, restaurar ambientes y bases de datos. Todas estas tareas se deben automatizar con herramientas y scripts, y todo se debe mantener bajo control de versiones para poder auditarlo y reproducirlo.

Compartir las herramientas y procedimientos entre equipos es crítico

La entrega continua apunta a validar los procedimientos de implementación y automatización utilizados en el ambiente de producción; para hacerlo exitosamente, estos procedimientos y automatizaciones deben ser utilizados tan temprano como sea posible de forma tal que, sean ampliamente probados cuando se usen para implementar software a el ambiente de producción. En la mayoría de los casos, las mismas herramientas pueden utilizarse en todos los ambientes (pruebas, preproducción y producción).

Los scripts de automatización deben manejarse en repositorios compartidos de código fuente de tal forma que cada equipo —desarrollo, QA y operaciones— pueda mejorar las herramientas y los procedimientos. Mecanismos como pull-requests pueden ayudar al gobierno de estos scripts y herramientas.

La aplicación tiene que ser amigable en su despliegue para hacer que las implementaciones no generen eventos disruptivos

Las aplicaciones deben simplificar sus procedimientos de instalación y marcha atrás (rollback) para minimizar conflictos. Un paso importante para lograrlo es reducir el número de componentes y de parámetros de configuración. La facilidad de dar marcha atrás, brinda la posibilidad de que en caso de que haya algún problema con una instalación se pueda rápidamente deshacer y regresar el sistema a su estado anterior. La capacidad de activar capacidades de forma independiente (feature toggle) permite desacoplar la instalación de binarios de la activación de capacidades, de esta manera si hay un problema al activar una capacidad, simplemente se desactiva en lugar de tener que reinstalar los binarios anteriores. Una marcha atrás entonces puede ser simplemente la desactivación de la misma , gracias a una tecla de conmutación.

Se debe poner especial atención a cualquier cambio en el esquema de las bases de datos, ya que se pueden volver mucho más complejas las implementaciones y los retrocesos. El patrón de diseño sin esquema de las bases de datos NoSQL trae mucha flexibilidad, pasando la responsabilidad del esquema desde la base de datos, al código. Este concepto también puede ser aplicado a bases de datos relacionales.

La infraestructura debe apuntalar el proyecto para potenciar a la gente y equipos

Las infraestructuras deben proporcionar todo el equipamiento (GUIs, APIs y SDKs) y documentación requeridos para empoderar al equipo de desarrollo y QA, y hacerlos autónomos en su trabajo. Estas tareas incluyen:

Poder implementar la versión de su elección de la aplicación.
Gestionar los parámetros de configuración (ver, modificar, exportar, importar).
Gestionar bases de datos (crear snapshots y restaurar a partir de estos).
Dar acceso a las bitácoras (logs) de la aplicación.

Las plataformas de nube pública, principalmente en modelos de Plataforma como Servicio (PaaS), son ejemplos de plataformas amigables con los proyectos.

Las versiones de aplicaciones deben estar listas para ser enviadas a producción

Una de las metas más importantes de la entrega continua es permitir que el dueño de producto pueda desplegar en producción cualquier versión de la aplicación que pase exitosamente el conducto (pipeline) de entrega continua, en lugar de solo poder liberar las versiones mayores que resultan al final de una iteración.

Alcanzar este objetivo requiere cambios importantes en la forma en que son diseñadas las aplicaciones, por ejemplo: las características que aún no han sido validadas por el equipo de QA se deben poder ocultar a los usuarios finales sin que la base de código se modifique. Dichas características deben estar en ramas (branches) de código distintas a la rama maestra, e incorporarse a la rama maestra hasta que hayan sido validadas por QA y aceptadas para su uso en producción. Otra posibilidad es usar feature toggling que consiste en poder activar o desactivar una funcionalidad desde alguna consola de administración.

Las herramientas de construcción deben evolucionar del concepto de versiones semánticas (SemVer) hacia un flujo continuo de versiones. En el caso de subversion, es sencillo ya que automáticamente provee un número de versión ordenado. En el caso de Git, dado que su árbol de versiones no es lineal, es un poco más complicado y requiere acuerdos en cuanto a cómo se va a organizar el árbol de versiones y la nomenclatura que se le dará.

Conclusión

La entrega continua no solo se trata de un conjunto de herramientas. También debe tomar en cuenta a las personas y la cultura organizacional. La tecnología, la gente y el proceso necesitan estar alineados para hacer que la entrega continua sea exitosa; y un enfoque colaborativo es fundamental para su éxito. Implementar estas mejores prácticas puede permitir a las organizaciones cosechar las recompensas de un enfoque automatizado más fluido al desarrollo de software, y uno que también proporciona agilidad de negocios.

Bio

Cyrille Le Clerc es Director of Product Management en la empresa CloudBees. Previamente Cyrille fue CTO de Xebia. Fue uno de los primeros proponentes del modelo ágil de desarrollo “You Build It, You Run It” , que ha puesto en marcha con una gran variedad de clientes.

Arquitectura Lambda: Combinando lo mejor de dos mundos

sg — Wed, 12 Oct 2016 07:27:06 +0000

Arquitectura Lambda: Combinando lo mejor de dos mundos

sg Wed, 10/12/2016 - 02:27

Publicado en

SG #52

Arquitectura

Autor

Benjamín Vera-Tudela

A alto nivel hay dos tipos de procesamiento de datos: el primero es el procesamiento de datos en modo batch, el segundo es en modo stream o tiempo (semi)-real. Elaborando un poco más sobre esta diferencia, el procesamiento batch es aquel que nos permite procesar volúmenes de datos en tiempos espaciados (ej. cada 15 minutos, cada 3 horas, o diario). Mientras que el modo stream es aquel que nos permite procesar datos casi al instante en que estos son producidos (ej. cada 100 milisegundos o cada segundo).

Para entender por qué esta diferencia es importante, podemos utilizar ejemplos de la vida real que la hacen más evidente. Por ejemplo, si una empresa quiere entender al final de cada trimestre cuál fue la tendencia de venta de un producto, para tomar decisiones, es necesario almacenar datos sobre las transacciones de venta del producto a lo largo del mismo periodo para luego realizar el procesamiento. Si el volumen de datos es alto, este procesamiento podría tomar varios minutos o incluso horas, y en este caso en particular es probable que quienes tomen decisiones estén dispuestos a esperar ese tiempo para poder hacerlo.

Sin embargo en otros casos, la espera para tomar decisiones puede ser costosa, y por lo tanto se necesita hacerlo de manera casi inmediata. Por ejemplo, si se desea bloquear el uso de una tarjeta de crédito que aparenta ser fraudulenta, no podemos esperar varios minutos ya que el daño realizado por ese tipo de transacciones puede ser elevado. En estos casos es mejor tomar decisiones casi al instante en que la información de una posible transacción fraudulenta esté disponible.

Cuando los volúmenes de datos en cualquiera de estos casos son muy altos —es decir, cuando afrontamos temas de big data como es el caso hoy para muchas empresas operando en la era digital, y como lo será en los próximos años con el internet de las cosas— la complejidad y el costo de implementar sistemas de información que nos permitan manejar ambos tipos de procesamiento también incrementa. Es ahí en donde nace el concepto de la Arquitectura Lambda.

En una arquitectura lambda la idea es implementar sistemas de información que combinan ambas modalidades de procesamiento de datos: batch y stream. Esto nos da lo mejor de dos mundos, ya que el modo batch nos brinda un alcance completo y confiable mientras que el modo stream nos da los datos en línea para decisiones instantáneas.

Figura 1. Arquitectura Lambda.

La figura 1 muestra un modelo de cómo funciona la arquitectura lambda. Los datos que entran al sistema se despachan tanto a la capa batch como a la capa de velocidad (speed). La capa batch escribe los datos al master data set y prepara las vistas batch, pasándolas a la capa de servidor. Esta última se encarga de indexar las vistas batch de manera que pueda responder a búsquedas con muy baja latencia. El problema es que el proceso de escribir datos y luego indexarlos es lento, por lo que éstos no están disponibles de forma instantánea; es aquí donde entra en acción el rol de la capa de velocidad; que se dedica a exponer solamente los datos más recientes, sin preocuparse por escribirlos a un registro permanente. El resultado de cualquier búsqueda puede conjuntar datos provenientes tanto de vistas de la capa batch como de la capa de velocidad.

Tecnologías involucradas

En cada una de las capas de esta arquitectura se utilizan tecnologías especializadas para cada propósito. Aunque es posible utilizar distintas opciones, una opción popular es utilizar Apache Sqoop + HDFS + Hive para capturar, almacenar y procesar datos en forma batch, y Apache Kafka + HBase + Spark para capturar, almacenar y procesar datos en forma stream. Existen proveedores —como Cloudera, donde yo colaboro— que ofrecen productos que integran estas herramientas y permiten fácilmente incorporar arquitecturas lambda.

Referencias:

http://lambda-architecture.net

Bio

Benjamin Vera-Tudela es Senior Big Data Architect en Cloudera, compañía líder en el desarrollo y comercialización de tecnologías abiertas para big data.

Un Vistazo a la Arquitectura Serverless

sg — Wed, 12 Oct 2016 07:22:21 +0000

Un Vistazo a la Arquitectura Serverless

sg Wed, 10/12/2016 - 02:22

Publicado en

SG #52

Arquitectura

Autor

Pedro Galván

Uno de los temas que hemos explorado durante los últimos meses en los distintos canales de Software Guru, es el de arquitectura serverless (sin servidor). Ya en el primer episodio del vlog Devotion lo comentamos de forma casual, y luego en el congreso SG Next tanto Verónica López como Obie Fernández nos platicaron al respecto con mayor detalle. Así que ahora es mi turno de compartir mi perspectiva sobre este modelo arquitectónico.

Lo primero que hay que aclarar es que, a pesar de lo que diga su nombre, en las arquitecturas serverless sí hay servidores. Y de hecho no es uno, sino muchos. La diferencia respecto a las aplicaciones tradicionales es que no hay un servidor maestro que controle el flujo de la aplicación, sino que los servidores simplemente hospedan servicios que atienden peticiones de forma atómica y no están conscientes del flujo de la aplicación, ya que éste se controla del lado del cliente. Dichos servicios pueden haber sido implementados por nosotros (en el caso de comportamiento específico a nuestra aplicación) o también podemos usar servicios proporcionados por terceros para resolver aspectos comunes tales como, autenticación de usuarios, almacenamiento, mensajería. Por último, los desarrolladores no tienen ninguna visibilidad a los servidores que hospedan los servicios, ya que estos son administrados por terceros. Así que los desarrolladores se pueden dedicar exclusivamente a implementar la funcionalidad de la aplicación sin tener que preocuparse por administrar servidores.

La figura 1 (es la misma que aparece en la cabecera de este artículo) brinda un panorama de este concepto.

Figura 1. Arquitectura serverless. Fuente: http://martinfowler.com [1]

Las aplicaciones serverless típicamente hacen uso extensivo de servicios terceros para cumplir tareas que no son centrales o específicas a la aplicación. Una aplicación puede utilizar una familia de servicios terceros de un mismo proveedor (ej. Firebase) o usar servicios de proveedor distintos, por ejemplo una aplicación podría usar Auth0 para la autenticación de usuarios, Azure Media Services para entregar video por streaming, y OneSignal para push notifications.

Una de las principales responsabilidades de una aplicación tradicional centrada en el servidor es controlar el ciclo de petición-respuesta. Los controladores en el servidor procesan las entradas, invocan el comportamiento correspondiente y construyen una respuesta dinámica usando un motor de plantillas (template engine). En contraste, en una aplicación serverless, donde el comportamiento se ensambla a partir de servicios, el control del flujo se hace del lado del cliente y el contenido se genera de forma dinámica en el cliente. Por ejemplo, las aplicaciones móviles, IoT e incluso las de smart TV utilizan frameworks de interfaz de usuario para generar contenido dinámico a partir de información obtenida por medio de llamadas a APIs remotas.

En las aplicaciones centradas en el servidor, la aplicación está compuesta por procesos que están continuamente activos y atendiendo peticiones. En contraste, en las aplicaciones serverless el ciclo de vida de los programas es mucho más corto, tendiendo a ser un solo ciclo petición/respuesta en HTTP. El programa se activa cuando recibe una petición, la procesa y en cuanto termina se apaga. Este tipo de programas típicamente están hospedados en un entorno como Amazon Lambda, Azure Function o Google Cloud Functions, que se encarga de gestionar el ciclo de vida y escalabilidad del programa. Este tipo de estructura se conoce como “Funciones como Servicio” (FaaS).

Ventajas y desventajas

Cualquier decisión de diseño arquitectónico involucra ventajas y desventajas.

Uno de los principales beneficios de la estrategia serverless es el ahorro en costo. En sistemas que tienen patrones de tráfico con picos repentinos, tener un servidor con grandes recursos continuamente disponible es costoso; en cambio, en el modelo FaaS se cobra por petición atendida. Otro componente de costo que te ahorras con serverless es el del personal y del esfuerzo requerido para administrar el servidor.

En cuanto a las desventajas, la primera sería la complejidad que se agrega al estructurar las aplicaciones de esta forma. También puede haber un impacto en el desempeño de la aplicación debido a la carga y latencia introducida al estar continuamente invocando servicios que no están inmediatamente disponibles.

Este artículo apenas ha sido un panorama general sobre serverless. Si te interesa conocer más al respecto, te recomiendo leer el artículo “Serverless Architectures” [2] de Mike Roberts.

Referencias:

B. Janakiranam. “Serverless”. http://swgu.ru/rs
M. Roberts. “Serverless Architectures”. http://swgu.ru/rr

Bio

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