SG #49

Radar SG49

sg — Wed, 23 Dec 2015 05:53:58 +0000

Radar SG49

sg Tue, 12/22/2015 - 23:53

Publicado en

SG #49

Lo que viene

Spinnaker: Despliegue multi-nube

Netflix continúa publicando como open source algunas de las herramientas y plataformas que ha desarrollado internamente para operar su infraestructura de TI. Caso en cuestión es Spinnaker, una plataforma open source para gestionar la instalación de aplicaciones en la nube. El principal atractivo de Spinnaker es que está diseñado para ser multi-nube, es decir que puede operar con nubes de distintos proveedores, y ser extendido para poder operar con cualquier nube pública o privada. De esta forma, Spinnaker habilita un modelo de instalación agnóstico del proveedor, y facilita la portabilidad. Actualmente Spinnaker soporta la gestión e instalación de aplicaciones en Amazon Web Services, Google Cloud Platform y Pivotal. Próximamente se agregará soporte para Microsoft Azure.

http://spinnaker.io

-----

Apache Kylin: BI sobre Hadoop

La Fundación de Software Apache anunció que el Apache Kylin se graduó de la incubadora y pasó a ser un proyecto de primer nivel. Kylin es un motor distribuido de analítica que provee análisis OLAP multidimensional y una interfaz SQL para Apache Hadoop, soportando conjuntos de datos de gran escala. Kylin permite que los analistas de información y usuarios finales puedan realizar análisis interactivo de información sobre conjuntos de datos masivos. En pocas palabras, Kylin habilita business intelligence sobre Hadoop. Kylin fue originalmente creado por eBay y cedido a Apache en noviembre de 2014 para que gestione su evolución.

http://kylin.apache.org

-----

Android Studio 2: Mucho más rápido

Android Studio 2.0 ya se encuentra disponible como versión previa. Las nuevas capacidades que incorpora se enfocan principalmente en acelerar el flujo de trabajo. Destaca una nueva característica llamada “Instant Run” que básicamente permite hacer “hot swapping” de cambios; es decir que un cambio en el código de una aplicación se refleja inmediatamente (menos de 2 segundos) en un dispositivo físico conectado o un emulador, y se ejecuta sin necesidad de reconstruir e instalar el APK completo. La velocidad del emulador también ha mejorado drásticamente (los reportes preliminares indican mejoras de más de 10x). El nuevo analizador de desempeño de GPU también será útil para encontrar cuellos de botellas en el desempeño gráfico de aplicaciones y optimizarlas para un rendimiento óptimo.

http://android-developers.blogspot.com/2015/11/android-studio-20-preview.htm

----

Microsoft: Nuevas herramientas para desarrollo

En las últimas semanas Microsoft publicó varias herramientas y servicios para desarrolladores. Entre las que más atención generaron están Visual Studio Code (editor de código para Linux, Mac y Win), Visual Studio Team Services (desarrollo colaborativo en la nube) e incluso el proyecto open source Dockercraft (gestión de contenedores Docker desde Minecraft). Otros proyectos o lanzamientos que no generaron tanta atención, pero que nos parecen relevantes son:

Microsoft Graph (https://graph.microsoft.io) - API unificado para acceder a datos y servicios de Microsoft en la nube, como por ejemplo Office 365.
CodePush (http://microsoft.github.io/code-push) - Servicio en la nube para actualizar aplicaciones móviles directamente en el dispositivo móvil del usuario, sin necesidad de pasar por app store. Limitado a apps hechas con Cordova o React Native.
Windows Store for Business - App store administrada por el departamento de TI de una empresa para hacer disponibles las aplicaciones de negocio aprobadas para uso de los empleados y colaboradores.

Algoritmos Inteligentes

sg — Wed, 23 Dec 2015 05:46:09 +0000

Algoritmos Inteligentes

sg Tue, 12/22/2015 - 23:46

Publicado en

SG #49

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

20 años atrás. En 1995 se embarcaron 60 millones de computadoras en todo el mundo. Internet se desarrollaba en paralelo desde fines de los sesenta y su impacto ya era claro. En 1999 salesforce.com se instituyó como una alternativa del cómputo cliente-servidor basado en Internet o “Software-as-a-service”. A fines del 2004 el término “Web 2.0” se usó para enfatizar el contenido creado por usuario y mejoras a la usabilidad e interoperabilidad de la red. Desde ese entonces se especulaba de un Internet que sería primariamente procesado por máquinas.

Hace una década. Fue en agosto 25 del 2006 que Amazon anunció el primer beta del cómputo elástico en Internet. Por primera vez fue posible obtener recursos de cómputo de forma abstracta equivalentes a un procesador Intel Xeon 1.7GHz del 2006, y así nació el cómputo en la nube. Hace una década también nació Hadoop, para el procesamiento de cada vez mayores volúmenes de datos. En mi opinión, el libro “The Big Switch” de Nicholas G. Carr [1], explica con claridad la actual revolución de cómputo en la nube.

Fines del 2015. Desde hace dos años las tabletas y celulares han mantenido en declive su participación contra computadoras personales embarcadas a nivel mundial. La migración a la nube se está acelerando, cada vez son menos los que piensan que nunca abandonaran los centros de datos propios, aún en las industrias más reguladas. Las tecnologías relacionadas a la nube y movilidad —como seguridad, contenedores y analítica— continuarán con gran demanda (leer “50 enterprise startups to bet your careers on in 2016” [2]).

El internet inteligente. Recientemente he descrito en esta columna el Internet de las cosas. Resulta claro que el destino requiere de mejores decisiones tomadas por las máquinas mismas. El verdadero cambio que puedo ver en las propiedades mayores de internet así como en los círculos de emprendimiento es una “fiebre de oro” por el aprendizaje automatizado (machine learning). El último trimestre del 2015 se caracterizó por una variedad de tecnologías de código abiertas para predicción. Pedro Domingos ha expuesto en “The Master Algorithm” [3] cinco distintas “tribus” con aproximaciones distintas a la nueva inteligencia artificial:

Tribu	Orígenes	Algoritmo principal
Simbolistas	Lógica, Filosofía	Deducción inversa
Conexionistas	Neurociencia	Retropropagación
Evolucionarios	Evolución biológica	Programación genética
Bayesianos	Estadísticas	Inferencia probabilística
Análogos	Psicología	Máquinas basadas en un Kernel

Independientemente de que pueda existir un solo algoritmo para que una máquina pueda aprender cualquier cosa, presentando una gran cantidad de “ejemplos”, los fundamentos relacionados y la reciente disponibilidad de la tecnología permite integrarla hasta en las más sencilla aplicación. En décadas pasadas nos hemos hechos dependientes del software, pero en la siguiente etapa dependeremos de un nivel de automatización sin precedente: algoritmos que aprenden y máquinas que se programan a sí mismas, que mejoran gradualmente, que conocen mejor al usuario que otros humanos.

Solo recordemos que la inteligencia de máquina no tiene por qué comportarse como la inteligencia humana.

Referencias

N. Carr. “The Big Switch: Rewiring the world, from Edison to Google”. W. W. Norton & Company, 2008. http://swgu.ru/r0
J. Bort, E. Kim & M. Weinberger. “50 enterprise startups to bet your career on in 2016”. Business Insider, Nov 2015. http://swgu.ru/r1
P. Domingos. “The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World”. Basic Books, 2015. http://swgu.ru/r2
D. Hofstadter. “Gödel, Escher, Bach: An Eternal Golden Braid”. Basic Books, 1979. http://swgu.ru/r3

Bio

Luis Daniel Soto (@luisdans / @luisdanielsoto) trabaja en Amazon Web Services, enfocado en el desarrollo global de negocios para Big Data e Inteligencia de negocios. sotols@amazon.com

Comentarios

I am very enjoyed for this blog

I am very enjoyed for this blog. Its an informative topic. It help me very much to solve some problems. Its opportunity are so fantastic and working style so speedy FOR MORE DETAILS.

Guía para Depuración con Android Wear

sg — Wed, 23 Dec 2015 05:35:10 +0000

Guía para Depuración con Android Wear

sg Tue, 12/22/2015 - 23:35

Publicado en

SG #49

Tutorial

Autor

Intel Software

Depurar (debugging) es un proceso inherente a todo ciclo de desarrollo, y el caso de las aplicaciones de Android Wear no escapa a esa regla. En este artículo mostramos cómo depurar aplicaciones para prendas inteligentes.

Para depurar aplicaciones en prendas inteligentes necesitamos de lo siguiente:

Prenda inteligente (wearable) en cuestión.
Dispositivo móvil Android (teléfono o tableta) que se conecta a la prenda inteligente.
Computadora personal con el Android SDK instalado, incluyendo las “platform-tools”.

Al realizar esta guía utilizamos como referencia un reloj LG G Watch R conectado a un Nexus 4, pero esto se podría hacer con cualquier otra combinación de prendas inteligentes y dispositivos Android modernos.

Activar opciones de desarrollo

Para realizar la depuración, necesitamos activar opciones que están dentro del menú de “Opciones de desarrollo” (Developer options) en la sección de Ajustes (Settings). Si no tienes visible este menú, por favor actívalo tanto en el dispositivo móvil como en el wearable (ver figura 1).

Figura 1. Habilitar opciones de desarrollo.

Para activarlo requieres realizar los siguientes pasos:

Ir a Ajustes.
Entrar a “Acerca del teléfono”
(About phone).
Tocar el siete veces en el Número de compilación (Build number). Después de la séptima vez verás un mensaje indicando que ya eres desarrollador y podrás encontrar el menú de Opciones de desarrollo dentro de la sección de Ajustes.

Conexión directa de wearable a PC

Si el wearable tiene conectividad por USB, esta es la opción más sencilla. Ya que basta con realizar los siguientes pasos en el wearable:

En el wearable, ir a “Ajustes” —> “Opciones de desarrollo” y habilitar “Depuración ADB” (ADB Debugging). Ver figura 2.
Conectar el wearable a la computadora con un cable USB.
En el dispositivo móvil aparecerá una ventana de confirmación para permitir depuración del wearable.
Para verificar la conectividad, desde la terminal de comandos de la computadora puedes teclear el comando “adb devices” y debes ver listado el wearable. Recuerda que el comando adb está en la carpeta platform-tools de tu Android SDK, así que agrega esa carpeta a tu PATH o ejecuta el comando indicando la ruta a la carpeta.

Figura 2. Habilitar depuración en wearable.

Conexión con puente por Bluetooth

Otra opción de conexión es utilizar el dispositivo móvil como puente entre el wearable y la computadora. En este caso, conectamos el wearable con el dispositivo móvil por Bluetooth y luego conectamos el dispositivo móvil a la computadora por USB. Esto requiere que ajustemos la configuración tanto en el wearable como el dispositivo móvil para permitir depuración y que configuremos ADB para que se conecte al wearable.

En el wearable, ir a “Ajustes” —> “Depuración sobre Bluetooth” (Debug over Bluetooth).
En el dispositivo móvil, ir a “Ajustes” —> “Opciones de desarrollo” y habilitar “Depuración de USB” (USB Debugging).
Otra vez en el dispositivo móvil, en la companion app de Android Wear habilitar “Depuración sobre Bluetooth” (Debugging over Bluetooth). En esta sección podemos ver el estatus de conexión hacia el target (wearable) y el host/computadora (ver figura 3).
Conectar el dispositivo móvil a la computadora por USB. Si es la primera vez que conectamos este dispositivo móvil con esta computadora para depuración, aparecerá una ventana pidiendo que autoricemos la depuración desde esta computadora (ver figura 4).
En la computadora personal, escoger un puerto de comunicación libre (en este caso usaremos el 4444) y configurar adb para que se conecte al wearable usando este puerto. Esto se logra escribiendo los siguientes comandos desde la terminal de comandos.
adb forward tcp:4444 localabstract:/adb-hub
adb connect localhost:4444
Posiblemente el dispositivo móvil ahora nos pida también autorización para depurar desde la computadora hacia el wearable (ver figura 5).
Una vez hecho esto, en la companion app de Android Wear desde el dispositivo móvil veremos que el estatus de depuración por Bluetooth mostrará que está conectado (ver figura 6).

Una vez que la conexión es exitosa, si desde la computadora tecleamos “adb devices”, veremos listados dos dispositivos: uno es el dispositivo móvil conectado por USB, y otro que aparecería como “localhost:4444” sería el wearable.

Podemos enviar comandos de depuración al wearable de la siguiente forma:

adb -s localhost:4444 <comando>

o si este es el único dispositivo conectado por TCP/IP o emulador activo, entonces simplemente podemos usar:

adb -e <comando>

Figura 3. Configuración en dispositivo móvil.

Figura 4. Autorizar depuración de dispositivo.

Figura 5. Autorizar depuración de wearable.

Figura 6. Estatus de conexión.

Conclusión

Dado los recursos de cómputo limitados que hay en los wearables, es importante que tengamos perfectamente controlada la actividad de nuestras apps al ejecutarse en wearables. Poder hacer depuración directamente en el wearable nos permite tener este control y nos ayuda a construir apps de mejor calidad. Te recomendamos visitar la Zona de Desarrolladores Intel en:

http://software.intel.com/es-es/android

donde encontrarás artículos y guías para el desarrollo de wearables Android.

Referencias

“Android Wear por ADB”. Intel Software.
https://software.intel.com/es-es/android/articles/android-wear-through-adb

La Paradoja del Software y los Malditos Programadores

sg — Wed, 23 Dec 2015 04:23:18 +0000

La Paradoja del Software y los Malditos Programadores

sg Tue, 12/22/2015 - 22:23

Publicado en

SG #49

Carrera

Autor

David Bonilla

Este artículo fue originalmente publicado en la Bonilista en agosto del 2015 y se encuentra disponible en http://swgu.ru/qu . Fue republicado en SG con permiso del autor.

Hay gente que no acepta que un programador pueda ganarse bien la vida haciendo simplemente su trabajo: programar.

Suele ser gente sin conocimientos técnicos, pero que sí piensan tenerlos porque leen artículos de tecnología “ya digeridos” para consumidores habituales de prensa financiera; o —peor aún— son entrepreneurs que creen que fundar una empresa “de Internet” los convierte, inmediatamente, en gurús tecnológicos.

Es fácil identificarlos porque dicen que es “imposible” encontrar buenos programadores y, cuando les explicas que lo único que tienen que hacer para encontrarlos es salir a buscarlos y pagarles un salario de mercado, se quejan amargamente de que los malditos programadores cobran mucho. Demasiado para poder crear negocios rentables.

Creen que están en la onda porque leen TechCrunch, no dejan de coleccionar contactos en angel.co, en LinkedIn y no se pierden ni un solo guateque estartupero; pero no se están enterando de lo que está pasando y, sobre todo, POR QUÉ.

Hace un par de meses, se publicó The Software Paradox (http://amzn.com/B0118ANTCQ), un libro en el que Stephen O’Grady intenta explicar durante 62 páginas lo que él llama Paradoja del Software o cómo, en un mundo donde el software es cada vez más importante, su valor tiende a ser cero. No es que O’Grady haya descubierto petróleo, pero ha documentado a la perfección la profunda transformación que ha sufrido la industria del software en los últimos 10 años, que le ha llevado a dejar de vender licencias para centrarse en vender servicios.

Pero eso no quiere decir que se gaste menos dinero en software —al contrario— quiere decir que se gasta de otra manera.

Los que se escandalizan por el salario de los malditos programadores deberían recordar la época en la que las empresas adquirían tecnología a golpe de compra de licencias. Antes, era normal que una PYME montara su propio data center, haciendo una inversión importante en servidores y en acondicionar una sala donde colocarlos, mucho antes de poder rentabilizarlos. 99% de esas empresas hoy despliegan sus aplicaciones en máquinas virtuales que escalan según sus necesidades reales.

Antes, era normal pagar cientos de miles de dólares en licencias de uso de un ERP o un CRM que no servían para nada hasta que la empresa gastaba dos o tres veces más en la consultoría necesaria para parametrizarlos y adaptarlos a sus necesidades. 99% de esas soluciones se pueden disfrutar hoy como servicio, pagando una cuota mensual.

En ese contexto, la labor principal del CIO consistía en negociar con los vendedores de soluciones, mientras que el personal de TI se rompía la cabeza averiguando cómo encajar en su proyecto la solución por la que se había pagado un dineral antes de comprobar si realmente solucionaba algo … ¿de verdad alguien echa de menos esto?

Hoy esa misma tecnología se adquiere por una fracción de su antiguo precio, gracias a productos open source y servicios de Software as a Service (SaaS). Y son esos malditos programadores con un salario desorbitado los que lo hacen posible.

El open source y el SaaS han democratizado el acceso a la tecnología y han permitido que los técnicos hoy sean los que tienen el poder —y la responsabilidad— de decisión sobre qué arquitectura se usará en cada proyecto para montar pilotos o MVPs, mucho antes de que estos lleguen al CIO.

Por eso, la industria del software cada vez contrata más evangelistas técnicos y menos vendedores de traje impecable, ahorrando millones de dólares a las empresas en el proceso.

En informática, el centro de gravedad —y de inversión— se ha trasladado del software a los programadores. El software es un activo, pero se paga por un servicio. Si aún no lo has entendido, ya vas tarde.

Los proyectos informáticos hoy son más baratos que nunca. Lo que pasa es que el dinero ya no se mueve en comidas de café, copa y puro, sino en las madrigueras y sótanos donde se solía colocar a los malditos programadores.

Si no quieres aceptarlo, busca otro trabajo con el mismo futuro que tus ideas. Por ejemplo, vender software en cajas. Suerte.

Bio

David Bonilla se dedica a crear cosas y tratar de hacer dinero con ellas, más que nada por medio de Internet. Radica en Madrid, España y es cofundador de Otogami, un servicio de búsqueda y comparación de ofertas de videojuegos. Es autor de la “bonilista”, una lista de correo con artículos para profesionistas de software.

La Fuerza de los Bootcamps

sg — Wed, 23 Dec 2015 04:20:53 +0000

La Fuerza de los Bootcamps

sg Tue, 12/22/2015 - 22:20

Publicado en

SG #49

Carrera

Autor

En los últimos años se ha visto un cambio en el perfil de las personas que trabajan en la industria tecnológica. Del godínez al geek, el sector atrae cada vez menos estudiantes de carreras tradicionales de computación, y cada vez más personas que buscan aprender las habilidades específicas requeridas por el sector, de manera rápida e independiente.

Algunos datos confirman esta tendencia. En Estados Unidos, por ejemplo, las carreras de ciencias de la computación e ingeniería de sistemas han sufrido una caída en el número de egresados. En 2002, 4.5% de los títulos de licenciatura en el país eran en ciencias de la computación. En 2012, ese número bajó 2.2% [1].

Al mismo tiempo, se ha visto un aumento significativo en la popularidad de los coding bootcamps, cursos intensivos de programación, de corta duración, que no requieren conocimiento técnico previo ni un título universitario. El concepto nació en Estados Unidos y el número de egresados creció en 138% en solamente un año, y la tendencia es que siga creciendo de acuerdo a información del Course Report 2015 Bootcamp Market Size Study [2].

¿Cómo se explica este fenómeno? Lo primero es el crecimiento exponencial que está teniendo el sector digital; las empresas buscan talento y no lo encuentran. Las carreras tradicionales no brindan al mercado el número de profesionales que requieren con la misma rapidez con la que crece la industria; tampoco logran adaptarse a los cambios constantes que en cuestión de meses ya no utiliza las mismas herramientas o tecnologías.

Por otro lado, y de cierta manera por las mismas razones, las necesidades de la industria hoy no requieren una formación tradicional. Las empresas buscan personas que sepan programar, independientemente de lo que hayan estudiado en la universidad (o si fueron a la universidad); debido a que es una habilidad técnica que se puede aprender rápido y que se puede perfeccionar con el tiempo de manera autodidacta por medio de recursos en línea.

En Latinoamérica, la situación no es diferente. Actualmente, la demanda insatisfecha de talento en el sector es de 35%. Se estima que para 2025, habrá una demanda de 1.2 millones, y las empresas no encontrarán talento para cubrir 40% de esos puestos de trabajo.

Como resultado, también se ha observado un aumento en la popularidad de los coding bootcamps en la región. Bootcamps como Dev.f, Codeacamp y Laboratoria ya forman a cientos de personas al año. Más de 70% de sus estudiantes salen con un trabajo bien remunerado, contribuyendo con el crecimiento de empresas del sector, y por ende la economía de la región. Esta coyuntura presenta una oportunidad interesante para la región, donde hay 20 millones de jóvenes que no estudian ni trabajan. La existencia de un sector que no requiere educación formal abre puertas para una población por lo general excluida de las oportunidades laborales tradicionales.

En Laboratoria, encontramos el potencial que existía al conectar a estos jóvenes con una industria que no requiere títulos universitarios y que brinda una oportunidad de inserción laboral rápida, y decidimos probar nuestra teoría. Iniciamos en Perú en 2013 con un bootcamp para 15 alumnas, mujeres que no habían tenido acceso a educación superior y vivían en zonas marginadas de Lima se formaron como desarrolladoras web en tan solo 5 meses, y luego empezaron su carrera profesional con trabajo en diversas empresas del sector digital. El éxito de la iniciativa y la demanda creciente de talento permitió la expansión del programa que hoy está también en México y Chile, formando a 130 mujeres y con una red de más de 100 empresas contratistas.

La experiencia de Laboratoria, así como la de los diversos bootcamps en la región, demuestra la fuerza que tiene el sector para brindar oportunidades de educación y laborales que rompen con los paradigmas comunes de lo que significa ser una persona “preparada”, “educada”, con “potencial de crecimiento profesional”.

Para una región sufriendo con la falta de personal calificado los bootcamps nos permiten respirar y arrojar luz sobre una alternativa viable de educación para el trabajo. Hay pocas oportunidades tan empoderadoras, con impactos tan significativos para la economía.

Referencias y estudio adicional

“Coding bootcamps are replacing computer science degrees”. Venturebeat. http://swgu.ru/r4
“2015 Bootcamp Market Size Study”. Course Report. http://swgu.ru/r5

Bio

Gabriela Rocha y Macha Bertrand son co-fundadoras de Laboratoria México. http://laboratoria.mx

Más allá del Software: Implementando servicios para productos de software

sg — Wed, 23 Dec 2015 04:14:40 +0000

Más allá del Software: Implementando servicios para productos de software

sg Tue, 12/22/2015 - 22:14

Publicado en

SG #49

Columna invitada

En ocasiones anteriores hemos conversado sobre la dinámica de generar un modelo de negocio alrededor de un desarrollo software, sus esquemas de financiamiento y los servicios alrededor del mismo a fin de darle sustento; por lo que en esta ocasión nos centraremos en las dinámicas de la ejecución de los servicios que se ofrecerán junto con el producto. Es necesario entender que los servicios también tienen un ciclo de vida y que para asegurar su correcto desarrollo y funcionamiento, es necesario hacer énfasis y mantener el enfoque en los siguientes aspectos que son a la vez un proceso cíclico:

Definición de los procesos

Es básico contar con indicadores de desempeño que ayuden a medir la efectividad de los servicios y determinar un escalamiento en caso de no cumplir los objetivos. Se debe definir de manera puntual todos los roles de los involucrados y actividades con calendarios de tiempos absolutos, naturales y de negocio. Se deberá contar además con herramientas y aplicaciones internas para el registro de las operaciones y la incorporación de reglas de ejecución de acciones para el inicio y término de cada actividad, así como los insumos y entregables que se implican en cada una de ellas.

Ejecución de los servicios

Se debe contar con un orquestador de procesos que controle la ejecución de las actividades y que sirva de motor para el cumplimiento de reglas de negocio y de los flujos definidos para la operación de los servicios. Se debe generar una base de conocimientos institucional, de forma que no se pierda la experiencia adquirida. Es importante resaltar que todo debe basarse en estándares de información, operación e interfaces de comunicación para futuras actualizaciones y ajustes. Además, siempre debe mantenerse vigilado el cumplimiento de los candados de seguridad que se hayan impuesto para el resguardo de la información y por supuesto, la constante vigilancia de los posibles riesgos detectados.

Monitoreo de los servicios

Aun con todo lo anterior, siempre se debe ser un poco psicótico al respecto de la adecuada implementación y ejecución de los servicios para asegurar que se realicen de acuerdo al plan y que se cuenta con un adecuado esquema de mejora continua prestando atención en actividades como: identificar cuellos de botella, analizar el rendimiento de los servicios, asegurar balance entre funciones, realizar simulaciones de procesos basadas en la información de operación, realizar simulaciones de escenarios críticos y ensayos de planes alternativos de acción, detectar desviaciones y mejores prácticas, promover la innovación a través de los procesos, analizar las tendencias basándose en los indicadores de desempeño, crear mejores prácticas.

Por supuesto que todo esto no se centra solo en los procesos y definiciones, sino que también se deberá contar con suficiente personal capacitado para dar respuesta en tiempo y forma a los requerimientos de todo tipo y generar modelos de transferencia de conocimiento eficientes que permitan preparar expertos en plazos cortos, a fin de generar mano de obra y necesidades en el mercado para mantener la operación de los servicios otorgados a clientes de versiones anteriores y/o presentes del producto, pues aun cuando se liberen nuevas versiones, no se debe olvidar que la mayor parte de los clientes no migrarán de manera inmediata.

Conclusión

La finalidad de toda empresa es ganar dinero, pero la realidad empresarial ha rebasado esta concepción estrecha sobre la empresa, ya que así como es indispensable generar valor para los accionistas, también debe considerarse a los empleados, clientes, incluso a la comunidad con la que se convive. Tal concepción empresarial que solo pone el acento en las ganancias corresponde a una visión de corto plazo en donde incluso vive en constante riesgo de desaparecer. Sin embargo toda empresa que desee crecer y permanecer en el tiempo necesita asumir una visión de largo plazo.

Pensar solo en ventas no es suficiente hoy en día, se debe pensar en experiencias. Mientras más poderosa sea la experiencia que entregamos a un cliente, más probable es que nos recomiende a sus amigos, conocidos y familiares como un episodio extraordinario. Recuerda que los “fanáticos” son mucho más valiosos que los clientes.

Bio

Víctor Jesús Hernández Salinas es Coordinador de Vinculación y Trans-ferencia de Productos en INFOTEC, donde colabora desde 2003 en la Gerencia de Desarrollo de Nuevos Productos y Servicios. Fue creador y coordinador del área de Servicios de Producto y su normatividad. Es además coordinador del programa de Certificación en los productos SWB y forma parte de la Red de Mentores en habilidades suaves para cuerpo Gerencial.

Estimación de Software con COSMIC

sg — Wed, 23 Dec 2015 04:08:02 +0000

Estimación de Software con COSMIC

sg Tue, 12/22/2015 - 22:08

Publicado en

SG #49

Gestión de Proyectos

Autor

Carlos Eduardo Vázquez

Hacer una estimación “bottom-up” es inviable cuando no está disponible la estructura de proyecto, y hacer una estimación solamente basada en una analogía es muy subjetivo. Además, no se puede aprender de los errores cometidos. El objetivo de este artículo es introducir el método de medición de COSMIC y presentar una propuesta para derivar unidades de producto a partir de los requerimientos funcionales del usuario en diferentes representaciones.

La problemática de la estimación

Cuando se solicita una medición a un desarrollador para entregar un programa y él provee una estimación de 12 horas, lo más probable es que esté correcto porque se trata de una pieza cuya dificultad o probabilidad de error es pequeña.

Es así que para estimar proyectos de software típicamente se aplica una estrategia bottom-up que consiste en descomponer el proyecto en sus partes constituyentes, estimar cada una de las partes y sumar los resultados para una estimación total.

La falla en esta lógica es que al inicio no se conocen todos los programas y algunas actividades no están en función de esta cantidad, como por ejemplo la ingeniería de requerimientos y el diseño de arquitectura, cuyos productos son los insumos para la programación usada en el ejemplo de apertura. En otras palabras, el nivel de información disponible no permite usar la lógica de la estimación bottom-up como solución para los desafíos de la estimación.

¿Tiene caso estimar?

Ante esta problemática, hay quienes argumentan que este tipo de estimación bottom-up cuando no se conocen los programas requeridos es un esfuerzo inútil, y que es preferible mejor aplicar ese esfuerzo a ejecutar iteraciones de entre 15 y 30 días que nos permitan resolver los aspectos desconocidos, y entonces ya poder “saber” en lugar de simplemente creer.

El problema es que a nivel directivo se requiere tener estimaciones para poder tomar decisiones. La estimación permite tomar decisiones respecto al desarrollo o mejora de sistemas. ¿Tiene caso hacer este proyecto?, ¿su beneficio será mayor que su costo?, ¿cuándo es el momento para hacerlo?, ¿cuál es el 20% de los proyectos que ejecutaremos para atender el 80% de las demandas?

Contar con estimaciones previas también facilita que los equipos sean auto-administrados y que su desempeño sea planeado y monitoreado de acuerdo con las exigencias de transparencia y eficiencia del gobierno corporativo.

Unidad de producto de software

Algunos argumentan que el proceso de software es único y está más allá de cualquier medición. Sin embargo, existen similitudes de éste con la construcción civil en escala industrial. Cada edificio es único, a pesar de que pueda compartir los elementos arquitectónicos comunes en mayor o menor medida. El proceso de entrega de un inmueble involucra desde la concepción de un proyecto arquitectónico, pasando por varios proyectos de ingeniería, construcción y pruebas específicas, hasta la aceptación final por parte del propietario y la garantía por un periodo de transición.

Cuando se construye un edificio, es necesario tener un presupuesto disponible para su construcción. Una información clave en ese momento es el valor del costo por metro cuadrado de construcción. En base a eso podemos tomar varias decisiones: qué tan grande va a ser, cómo vamos a fondear su desarrollo, etc. En esta etapa no lidiamos con el costo detallado de cada componente del edificio. Después de todo, es mucho más costoso (proporcionalmente) construir un baño que una habitación, ya que el baño tiene un costo mayor de mano de obra y materiales. Posteriormente cuando sea necesario hacer la estimación de costo específica del baño, ya contaremos con suficiente información para hacer una estimación bottom-up.

En este punto surge un importante concepto: la productividad. Esta puede ser definida como la razón entre la cantidad de bienes o servicios producidos y las unidades de tiempo o costo para su entrega.

En el caso citado del edificio, la planeación de productividad se hace en dólares por metro cuadrado (USD/m2). Es decir que medimos nuestro producto en términos de metros cuadrados, y observamos el costo generado por cada unidad de producto.

En el caso del desarrollo de software, necesitamos identificar una unidad que nos permita medir el producto durante la planeación. Dicha unidad debe permitir aproximar el tamaño del software a partir de sus requerimientos, y debe ser independiente del desarrollo técnico y decisiones de implementación.

Este tipo de unidad no elimina la necesidad de otras métricas que permitan cuantificar el desempeño técnico de productos y servicios a partir de su implementación, como por ejemplo: análisis de eficiencia del diseño, apoyo a la ingeniería de requerimientos, apoyo a la verificación y validación. Un ejemplo de métricas de este tipo son las que define ISO/IEC 25.000 (SQuaRE).

Considerando las características deseadas para esta unidad de producto, se deben tener como objetivo de medición los requerimientos funcionales del usuario, ya que están específicamente asociados a una tarea o servicio del usuario y describen lo que el software debe hacer independientemente de cómo sea desarrollado.

Contar los requerimientos funcionales parece ser una buena alternativa para representar las unidades de producto del software. Sin embargo, no todos los requerimientos son iguales y se corre el riesgo de no diferenciarlos. Para eso, la ISO/IEC definió un estándar para ese tipo de medición, denominado Medición del Tamaño Funcional, y cuyo método más moderno es supervisado por el Consorcio Internacional de Medición de Software en General o COSMIC.

COSMIC es la segunda generación de métodos de medición de tamaño funcional. Es aplicable a todo tipo de software, compatible con la ingeniería de software moderna, es de dominio público, su documentación no tiene costo, y es reconocido por ISO/IEC.

Proceso COSMIC

El método de medición consiste en un conjunto de modelos, principios, reglas y procedimientos que se aplican para determinar el valor de una magnitud para la funcionalidad entregada por el software. Dicha magnitud de la funcionalidad del software es expresada en puntos de función COSMIC.

A muy grandes rasgos, el proceso consiste en:

Establecer la frontera entre el sistema y los actores con los que interactúa (que pueden ser personas u otros sistemas).
Identificar los procesos funcionales que los actores reciben del sistema.
Para cada proceso funcional, identificar los movimientos de datos que genera. Cada que el usuario provee al sistema un conjunto de datos para realizar un proceso, hay un movimiento de datos. También es un movimiento de datos cuando el sistema provee grupos de datos al usuario, y cuando se acceden o almacenan grupos de datos en almacenamiento. Cada movimiento de datos contribuye con el equivalente a un punto de función COSMIC.

Medición vs aproximación del tamaño

Debemos recordar que en las primeras etapas del proyecto no es factible hacer estimaciones detalladas. El alcance estará definido en términos de macroprocesos de negocio y áreas funcionales. Estos elementos pueden ser contados y comparados con su correlación con el software entregado y medido en puntos de función COSMIC.

En los momentos posteriores en el ciclo de vida, cuando ya existe un alcance definido en términos de cuáles tareas el usuario deben ser parcialmente o totalmente transferidos para el software, es posible identificar procesos y aplicar la misma lógica en la extrapolación de la cantidad de puntos de función COSMIC a partir de la cantidad de procesos.

Al final del proyecto, una vez que se tiene el sistema implementado, se hace una medición (ya no es una estimación) del producto terminado. Esto se hace para:

Evaluar el desempeño mediante la relación entre la cantidad de horas invertidas y la cantidad de puntos función COSMIC medidos.
Revaluar los indicadores de productividad para que pasen a incluir el desempeño del proyecto que acaba de terminar.
Revaluar la cantidad de puntos función COSMIC que corresponden en promedio a los procesos y a los conceptos de negocio conforme al nivel de información disponible en los diferentes puntos que se desea estimar.

Benchmarking

Los resultados reales del proyecto (tamaño, tiempo, esfuerzo y costo) nos sirven para compararlos con nuestra estimación inicial y en base a eso ajustar nuestro proceso de estimación para próximas estimaciones. De manera similar, debemos calcular cuál fue la productividad real (ej. horas hombre por punto de función) y tomarla en cuenta para futuras decisiones.

Con datos históricos de proyectos en la empresa podemos hacer benchmarking para comparar nuestra estimación. Por ejemplo, si estimamos un proyecto para el desarrollo en Java como si tuviera 150 puntos de función COSMIC y un esfuerzo de 1,050 horas hombre esto equivale a una tasa de entrega de 7 horas hombre por punto función (hh/cfp). Si tenemos una base de datos histórica de proyectos podríamos determinar qué tan factible es lograr una productividad de 7 hh/cfp.

Si no contamos con datos internos, podemos apoyarnos en bases de datos de la industria. Por ejemplo, el ISBSG (International Software Benchmarking Standards Group) provee herramientas y bases de datos para la estimación de proyectos de software.

Bio

Carlos Eduardo Vázquez es fundador y responsable de investigación y desarrollo en Fatto Consultoría, empresa de origen brasileño especializada en consultoría para la estimación de proyectos de software. Tiene más de 20 años de experiencia en investigación, consultoría y entrenamiento en estimación con puntos de función. Fue uno de los tres primeros brasileños certificados expertos en puntos de función por el IFPUG en 1996 y uno de los primeros brasileños certificados por COSMIC en 2012. carlos.vazquez@fattocs.com

Site Reliability Engineering

sg — Wed, 23 Dec 2015 03:37:43 +0000

Site Reliability Engineering

sg Tue, 12/22/2015 - 21:37

Publicado en

SG #49

DevOps

Autor

Martín Ferrari

Este artículo es una adaptación y traducción de la serie de notas “Tales from the SRE trenches” que el autor publicó en su blog. Puedes consultar las notas originales en https://blog.tincho.org

Hace poco más de 12 años, en Google se gestó una iniciativa denominada “Site Reliability Engineering (SRE)” —que en español sería Ingeniería de Confiabilidad de Sitios.

Hoy en día, SRE es fundamental para la operación de los servicios en línea de esta empresa, y el concepto se está extendiendo al resto de la industria, tanto así que ya puedes decir que te dedicas a hacer SRE, y las personas —al menos, las adecuadas— te entenderán.

Yo tuve oportunidad de colaborar unos años en Google como parte del equipo de SRE, y actualmente me desempeño como consultor independiente en el rol de SRE. En el siguiente artículo comparto mi perspectiva de en qué consiste este concepto, cuáles son sus beneficios, y algunos tips para incorporarlo en tu forma de trabajo.

¿Por qué debe interesarme SRE?

Recientemente fui invitado a dar una plática sobre SRE en la Asociación Rumana para Mejor Software [1]. Dado que esta es audiencia principalmente dedicada al desarrollo de software y no a la operación o administración de sistemas, posiblemente parezca raro que ellos se interesen en SRE. Es decir, ¿por qué le interesaría a un desarrollador aprender de SRE? o más aún, ¿por qué debería un desarrollador interesarse en facilitar la vida de la gente de operaciones?

El hecho de que el equipo de operaciones soporte adecuadamente tu trabajo como desarrollador, te beneficia. No se trata de abrir la puerta para que los de operaciones te echen la culpa cuando las cosas salgan mal, sino de hacer una alianza; una alianza que hará que tu software opere sin problemas en producción y por lo tanto puedas enfocarte en construir funcionalidad innovadora.

Tal vez tengas la noción de que los desarrolladores solo deben enfocarse en agregar funcionalidad al software para atraer más usuarios, y dejar en manos de operaciones la confiabilidad de este. Pero un servicio poco confiable es difícil que pueda retener usuarios, independientemente de qué tan atractiva sea su funcionalidad. ¿Y qué mejor que tener como aliado a un equipo que tenga “confiabilidad” en su nombre?

¿Qué es la ingeniería de la confiabilidad?

La ingeniería de la confiabilidad es la rama de la ingeniería que se preocupa porque los productos diseñados funcionen como se espera, aun cuando sus componentes no sean confiables por naturaleza. Se enfoca en mejorar la confiabilidad de los componentes, establecer requerimientos mínimos, y hace un uso intensivo de estadística para predecir fallas y entender los problemas.

Ben Treynor es quien inició esta práctica en Google hace poco más de 12 años, y él define SRE de la siguiente forma:

“Fundamentalmente, es lo que sucede cuando le pides a un ingeniero de software que diseñe funcionalidad de operación”.

La primera recomendación al crear un equipo de SRE es contratar solamente a personas que puedan programar. Escribir software es una de las principales actividades de SRE. Esto es porque la visión de SRE consiste en tratar a la operación como un problema de ingeniería de software, es decir que se usa software para resolver problemas tradicionalmente resueltos a mano, implementando pruebas rigurosas, revisiones de código, y tomando decisiones basadas en datos, no en corazonadas.

También implica que SRE puede entender el producto al que está dando soporte y que hay respeto entre los ingenieros de desarrollo y operación.

Posiblemente, algunas de las recomendaciones que hago aquí solo tienen sentido en el contexto de una empresa con las características de Google: varios equipos de desarrollo y operaciones, un crecimiento mayor a la velocidad con la que se puede contratar gente, y un compromiso de la alta dirección para implementar reglas drásticas. Así que mi interés no es pregonar sobre por qué todos deben adoptar SRE, sino extraer algunas de las ideas más útiles que pueden aplicarse en un amplio rango de situaciones.

¿A qué se dedica SRE?

El equipo de SRE se dedica principalmente a mantener tu servicio en línea, realizando las tareas tradicionales de sysadmin como aprovisionamiento de infraestructura, configuración, monitoreo y asignación de recursos de cómputo, etcétera. Utilizan herramientas especializadas para monitorear servicios y obtener alertas en cuanto se detecta un problema. A ellos les toca despertarse a media noche para levantar un sistema caído o corregir una falla.

Pero eso no es todo: la confiabilidad no solo es impactada por nuevos lanzamientos. Puede que de pronto aumente la utilización de un sistema, falle el hardware, haya problemas de conectividad. Al trabajar a gran escala, todo tipo de fallas pueden darse. El objetivo de SRE es que dichas fallas afecten la disponibilidad del sistema lo menos posible. Para ello, SRE trabaja continuamente en 3 grandes estrategias: minimizar el impacto de las fallas, disminuir el tiempo requerido para recuperarse, evitar reincidencias. A continuación entro en más detalle de cada una de estas estrategias.

Minimizar el impacto de fallas

Hay que buscar que una falla no pueda provocar la caída de un servicio entero. Una de las tácticas que SRE utiliza es fragmentar y distribuir un servicio a través de varios “dominios de falla”. Un ejemplo sería distribuir los datos de un sistema a través de varios centros de datos, de manera que si un centro de datos en particular se incendia, solo una fracción de los usuarios se vean afectados. El equipo de SRE dedica gran parte de su tiempo a planear y habilitar sistemas que abarquen distintas regiones geográficas para maximizar redundancia y mantener la latencia de comunicación en niveles razonables.

Recuperarse rapidamente

Comúnmente, la forma más efectiva de reestablecer un sistema que falla es reiniciándolo. Así que otra estrategia es instrumentar los sistemas para que reinicien automáticamente milisegundos después de que se detecta una falla. Si se requiere intervención humana, es crucial que se notifique lo antes posible a las personas adecuadas y que tengan acceso rápido a la información que necesitan para resolver el problema tal como: documentación del ambiente de producción, guías de soporte, reportes de monitoreo, etcétera. Después de todo, es muy probable que a las 2 de la mañana te cueste trabajo recordar en qué país está ubicado cierto segmento de la base de datos, o cuál es la serie de comandos que necesitas para redireccionar el tráfico.

El equipo de SRE dedica bastante tiempo a implementar alertas automatizadas, escribir documentación y guías de soporte, e implementar otros preparativos para recuperación de desastres.

Evitar reincidencias

Cuando un incidente provoca una falla en el sistema, la primera prioridad es restablecer el sistema; pero también es muy importante estudiar la falla, con el objetivo de encontrar la causa raíz y resolverla. Así que otra actividad importante de SRE consiste en redactar reportes de postmortem. Cada incidente debe tener un postmortem, y estos deben usarse con fines de aprendizaje, no de echar culpa.

Prevenir fallas

Por supuesto, otra estrategia más, consiste en evitar que se den fallas en primer lugar. Claro que nadie puede evitar que un disco duro falle, pero hay otros tipos de fallas que se pueden prever. Por ejemplo, un aumento súbito en la carga de uso de un sistema puede tirarlo, por lo que el equipo de SRE debe asegurar que los sistemas sean probados con cargas de trabajo mayores a lo normal. También deben estar preparados para poder escalar rápidamente un servicio (por ejemplo: habilitar más nodos de procesamiento) en caso de que el sistema de monitoreo detecte que se ha alcanzado cierto umbral.

El equipo de SRE puede evitar fallas provocadas por situaciones como que se agote el espacio de almacenamiento o se degraden los componentes físicos. El monitoreo es el elemento clave: captar métricas relevantes y seguir su tendencia a lo largo del tiempo.

Mejorando la relación entre SWE y SRE

La lucha entre el equipo de desarrollo (Software Engineering, SWE) y el de operaciones comienza porque ambos tienen metas distintas. Llega el fin de semana y los desarrolladores quieren liberar una nueva versión a producción, pero los de operaciones quieren tener un fin de semana tranquilo. Cuando las liberaciones son problemáticas, lo que típicamente se hace es agregar burocracia para minimizar los riesgos: revisiones, checklists, ventanas de cambio, etcétera. El resultado es que los desarrolladores continuamente buscan formas de saltarse estos controles, y se generan problemas mayores.

Uno de los principales aspectos de SRE es evitar esto por completo, a través de un cambio en los incentivos para eliminar las presiones entre los equipos de desarrollo y operaciones. A continuación menciono algunas de las estrategias que se aplican en Google para lograrlo:

Tener acuerdos de servicio

Antes de que un servicio pueda ser soportado, se debe determinar el nivel de disponibilidad que debe mantener para que los usuarios y la empresa estén contentos: esto es lo que se conoce como Service Level Agreement (SLA). El SLA define cómo se mide la disponibilidad (por ejemplo: porcentaje de queries completados exitosamente en menos de 50 ms) y cual es el mínimo valor aceptable o SLO (el valor objetivo de nivel de servicio). Esta es una decisión de producto, no técnica. Es un número muy importante para un equipo de SRE y su relación con desarrolladores. No se toma a la ligera, y debe cumplirse de forma rigurosa.

Un objetivo de disponibilidad 100% rara vez es una buena idea, y en la mayoría de los casos es imposible conseguirlo. En empresas como Google, una meta común de disponibilidad en los servicios online es de cinco nueves (99.999%); esto significa que un servicio no puede estar caído más de 5 minutos durante todo un año.

Son muy pocas las cosas que realmente requieren una disponibilidad de 100% (por ejemplo: un marcapasos), y lograrla es muy costoso.

Medir y reportar el desempeño

Una vez que hayas definido el SLA y SLO, es muy importante que estos sean monitoreados y reportados continuamente. Si esperas para el fin del trimestre para producir un reporte manual, el SLA no sirve de nada, ya que no nos sirve enterarnos tan tarde de los problemas.

Este es un aspecto clave de SRE, ya que permite ver el avance de un servicio a lo largo del tiempo, detectando problemas de capacidad antes de que provoquen la caída del sistema, y al mismo tiempo mostrando qué tanto se puede tener el sistema abajo sin romper el SLA. Esto último nos lleva a la siguiente recomendación…

Administrar el presupuesto de falla

Si el SLO es el tiempo mínimo de disponibilidad, entonces al restar 1 - SLO obtenemos la fracción de tiempo que nuestro servicio puede fallar y todavía cumplir el SLA. Esto es lo que llamamos nuestro presupuesto de falla, y debemos aprovecharlo.

En el caso de servicios inestables que acostumbran tener errores, la mayoría de nuestro presupuesto de falla se desperdicia en fallas del sistema, lo cual no nos deja margen para intentar lanzar cambios. Por otro lado, cuando tenemos servicios estables que no usan el presupuesto de falla, tenemos la libertad de apostar parte de ese presupuesto para liberar nueva funcionalidad al usuario con mayor frecuencia.

Una vez que el presupuesto de falla se ha agotado, no se permite hacer nuevos lanzamientos hasta que transcurra suficiente tiempo sin fallas para darnos nuevo saldo.

Al darle visibilidad a todos sobre el comportamiento del presupuesto de falla, se ayuda a reducir conflictos entre los equipos de desarrollo y operaciones. Si el servicio está funcionando adecuadamente, entonces el equipo de operaciones no necesita interferir para oponerse a lanzamientos; se cuenta con evidencia cuantitativa para justificar las decisiones. Esto contribuye a evitar resentimiento y desconfianza entre desarrollo y operaciones. No es que los de operaciones quieran hacerle la vida difícil a los desarrolladores, es que simplemente no tienen presupuesto de falla disponible. Al mismo tiempo, esto provee un incentivo al equipo de desarrollo para evitar malgastar el presupuesto de falla con versiones que contengan errores o estén mal preparadas para liberación.

Dar visibilidad al trabajo de otros

Si el equipo de operaciones es visto por los desarrolladores como un grupo de bomberos cuyo trabajo consiste en apagar incendios 24X7, tienen menos incentivos a hacer buen software. De forma similar, si el equipo de desarrollo no tiene visibilidad a lo que sucede en el ambiente de producción, difícilmente podrán establecer confianza. Por ello es buena práctica que el equipo de desarrollo ocasionalmente haga algo de trabajo de operaciones por ejemplo: atender tickets, gestionar servidores, hacer liberaciones a producción. Lo que resultará en mejor comunicación entre equipos, y un entendimiento común de las prioridades.

Balancear el personal

Un mecanismo que se utiliza en Google es tener un límite de personal unificado entre desarrollo y operaciones. De esta forma, mientras necesites más personas para mantener el servicio en línea, contarás con menos desarrolladores para construir nueva funcionalidad. Combinado con esto, en Google los SRE se pueden mover libremente entre equipos, o incluso moverse a desarrollo. De esta forma, un servicio que es latoso de soportar solo tendrá acceso a los ingenieros menos experimentados.

Limitar la carga operativa

En Google, los SREs no deben dedicar más de la mitad de su tiempo a “trabajo operativo”. El resto de su tiempo deben ocuparlo en tareas de automatización, monitoreo, planeación de crecimiento … y no en continuamente arreglar de forma manual problemas derivados de sistemas mal hechos.

Si se encuentra que un equipo de SRE está dedicando demasiado tiempo a trabajo operativo, esa carga extra se reasigna al equipo de desarrollo. En casos extremos, un servicio puede ser considerado demasiado inestable para mantener, y entonces el equipo de SRE elimina su soporte por completo. Esto implica que el equipo de desarrollo ahora debe realizar todo el trabajo operativo y de soporte.

Otras lecciones aprendidas

Además de los lineamientos que he descrito aquí, hay otras prácticas que creo que serían útiles para cualquier equipo de operaciones e incluso de desarrollo.

Automatiza todo. No es sustentable hacer todo manualmente. No solo es un tema de tiempo ni de dinero, sino de disponibilidad de talento en el mercado laboral.

Involucra a operaciones en el diseño de sistemas. Nadie conoce mejor los retos de un ambiente de producción que el equipo de operaciones. Su retroalimentación te puede ayudar a ver riesgos de escalabilidad, planeación de capacidad, redundancia, y tomar acciones para evitarlos desde el diseño del sistema.

Documenta el diseño. Documentar los detalles de un sistema previo a su construcción es una gran forma de detectar problemas temprano, además es muy útil para comunicar a tu equipo qué es lo que se está construyendo, y convencerlos de que es una gran idea.

Revisa tu código y versiona los cambios. Todo debe estar sujeto a código de versiones: código, scripts de instalación, archivos de configuración. Puede parecer que no valga la pena, pero tener una historia completa de tu ambiente de producción es invaluable. Y al tener control de versiones, entra otra regla: ningún cambio se acepta sino es revisado por un colega. Puede ser frustrante tener que encontrar a un revisor y esperar aprobación por cada cambio, pero una vez que te acostumbres te darás cuenta que los beneficios superan por mucho las inconveniencias.

Antes de modificar, mide. El monitoreo no solo sirve para enviar alertas, sino que es una parte esencial de SRE. Te permite sensar tu disponibilidad, evaluar tendencias, predecir crecimiento, y realizar análisis forense. El monitoreo debe proporcionarte los datos que necesitas para tomar decisiones basadas en hechos. Antes de optimizar o hacer un cambio, encuentra donde está realmente el cuello de botella.

Bio

Martín Ferrari (@TinchoFerrari) ha trabajado en la industria por más de 18 años. Algunas veces como programador, otras como administrador de sistemas, y la mayor parte del tiempo como ambas cosas. Luego de dos años cumpliendo el sueño de trabajar en Google como SRE, decidió dejar la vida de oficinista para volverse un nómada digital. Actualmente realiza trabajos de consultoría para empresas mientras viaja por el mundo. Es también desarrollador del proyecto Debian y activista del Software Libre. Aspira a visitar todos los pubs del mundo. tincho@tincho.org https://tincho.org

Smart Decisions: Un juego para aprender arquitectura y big data

sg — Wed, 23 Dec 2015 03:14:56 +0000

Smart Decisions: Un juego para aprender arquitectura y big data

sg Tue, 12/22/2015 - 21:14

Publicado en

SG #49

Arquitectura

Autor

Humberto Cervantes

En esta ocasión les hablaré de Smart Decisions, un juego que he desarrollado junto con mis colegas Rick Kazman del Software Engineering Institute (SEI) así como Serge Haziyev y Olha Hrytsay de la empresa Softserve. El objetivo del juego es ilustrar la manera en que se realiza el diseño de la arquitectura mediante el método de diseño Attribute Driven Design (ADD). Como parte del juego, se simula el diseño de un sistema de Big Data.

Comenzaremos recordando el método de diseño ADD y después hablaremos acerca de los detalles del juego incluyendo un enlace para descargar los materiales y jugarlo.

Repaso: diseño de arquitectura

La actividad de diseño de la arquitectura (ver SG29) se enfoca en la traducción de drivers, hacia un conjunto de estructuras que conforman la arquitectura. Recordemos que los drivers incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG28).

Attribute Driven Design

La transformación antes mencionada se puede realizar de manera sistemática usando el método de diseño Attribute Driven Design (ADD). ADD es un método iterativo de diseño de arquitecturas de software. El método consta de siete pasos que se muestran en la figura 1.

Figura 1. Pasos del método de diseño ADD.

Las actividades son las siguientes:

El arquitecto se asegura de que tiene una buena comprensión acerca de los drivers que se usan como entradas al proceso de diseño.
Se elige el subconjunto de drivers que serán tratados en la iteración.
El diseño procede mediante el refinamiento de uno o más elementos que son elegidos en este paso. El refinamiento puede involucrar la descomposición de un elemento en subelementos y sus relaciones, o bien puede involucrar diseño adicional de elementos previamente identificados. Al inicio del proceso de diseño de sistemas ‘greenfield’ (desde cero), el único elemento que puede ser elegido es el sistema mismo, que es concebido como un único elemento. En iteraciones subsecuentes, o en el diseño de cambios a un sistema existente, se eligen uno o más elementos previamente definidos.
Este paso involucra la identificación y selección de conceptos de diseño, que describiremos a continuación, que permitirán satisfacer los drivers elegidos para la iteración
Una vez que los conceptos de diseño han sido elegidos, los elementos que se derivan son identificados y conectados. En este paso es donde nuevas estructuras se crean o estructuras existentes se refinan. Adicionalmente, las responsabilidades de los elementos se establecen y las interfaces expuestas por los elementos se definen.
A pesar de que la documentación formal ocurre después del proceso de diseño, cierta información debe registrarse durante el diseño, cuando aún se encuentra fresca en la mente del arquitecto y hay menos probabilidad de que la olvide. En este paso se registra dicha información que incluye bosquejos de las estructuras creadas en el paso previo junto con decisiones de diseño y su justificación (rationale).
En este paso, el arquitecto realiza un análisis de las decisiones de diseño que fueron realizadas durante la iteración y también del proceso de diseño en su conjunto. Como resultado, se toma la decisión de seguir realizando más iteraciones o de parar el diseño y de proceder a la implementación.

Conceptos de diseño

En el paso 4 del método ADD se eligen conceptos de diseño, que son los “bloques de construcción” del diseño de la arquitectura (ver SG46). Estos bloques son soluciones probadas a problemas recurrentes de diseño y pueden ser de naturaleza conceptual o concreta. Los tipos de conceptos de diseño que se consideran incluyen: arquitecturas de referencia, patrones, tácticas, familias tecnológicas y productos o frameworks.

Una de las dificultades que existen al momento de diseñar una arquitectura de software es la selección de conceptos de diseño. Existen cientos de patrones y tecnologías de dónde escoger y, además, la selección es complicada pues frecuentemente no es sencillo entender la influencia que puede tener un concepto de diseño particular sobre los atributos de calidad del sistema. Por ejemplo, cierta tecnología, ¿impacta o favorece el desempeño?

Como se puede apreciar, el diseño de arquitecturas de software no es una tarea sencilla, sin embargo, el uso de un método como ADD permite realizar esta actividad de manera sistemática lo cual aumenta las posibilidades de obtener un mejor resultado.

Smart Decisions

Dada la importancia de diseñar arquitectura siguiendo un método como ADD, decidimos desarrollar un juego cuyo objetivo es ilustrar conceptos importantes asociados con el diseño de arquitectura. Está diseñado para jugarse tanto por estudiantes como por practicantes que no tengan mucha experiencia en el diseño de arquitecturas. Cabe señalar que el juego no busca sustituir a los cursos de diseño de arquitectura, sino más bien, busca ser un complemento a los mismos.

Algunos de los conceptos principales que son ilustrados en el juego son los siguientes:

El diseño arquitectural se desarrolla de manera iterativa y puede realizarse de manera sistemática usando un método como ADD.
El diseño arquitectural comienza con drivers e involucra realizar decisiones de diseño. Algunas de estas decisiones incluyen elegir conceptos de diseño, lo cual generalmente es complicado, sobre todo para los diseñadores que se enfrentan con una “página en blanco” al iniciar el diseño.
Todo concepto de diseño tiene una influencia sobre los drivers y, más específicamente, sobre los atributos de calidad.
Las decisiones de diseño tienen consecuencias: algunas decisiones son mejores (de ahí que el juego se llame “Smart Decisions”) y algunas no lo son tanto. Por otro lado, las decisiones que se hacen en una iteración pueden tener consecuencias en iteraciones posteriores.
Las decisiones de diseño deben ser registradas y analizadas como parte del proceso de diseño.

Smart Decisions requiere un mínimo de dos jugadores y un máximo de seis. Los jugadores pueden ser individuos o grupos de individuos. Adicionalmente, requiere de un facilitador que explique el contexto y la mecánica del juego. El juego se juega en una serie de rondas que representan distintas iteraciones del proceso de diseño de un sistema nuevo (greenfield).

En la primer iteración, el facilitador describe la manera en que los pasos de ADD se llevan a cabo en el juego. Como parte de la explicación inicial, el facilitador presenta también el contexto del juego, es decir, la descripción de los drivers del sistema que se va a diseñar. Actualmente, Smart Decisions cuenta con un contexto de juego de un sistema de Big Data, sin embargo, está diseñado para ser extensible y que en el futuro se puedan agregar contextos de juego relacionados con otros dominios aplicativos.

Para cada iteración, el juego proporciona la siguiente información, que equivale a lo que se obtendría de los pasos 2 y 3 de ADD:

Objetivo de la iteración.
Drivers a considerar.
Elemento a refinar.
Alternativas de conceptos de diseño a considerar.

A continuación, los jugadores deben elegir conceptos de diseño a partir de las alternativas que se les proponen. Esto representa la actividad que se realiza en el paso 4 de ADD y es la parte medular del juego. Los conceptos de diseño se presentan como un conjunto de cartas y cada una de estas cartas contiene información acerca de un concepto de diseño particular (ver figura 2). La información que se presenta en la carta incluye un nombre, un diagrama (si aplica), una descripción y una lista de drivers así como la influencia del concepto de diseño sobre los mismos. La influencia se mide mediante puntos, que están representados como estrellas. Un punto significa que el concepto de diseño no contribuye mucho a satisfacer el driver mientras que tres puntos significa que el concepto de diseño contribuye en gran medida para satisfacer el driver.

Figura 2. Tarjeta de un concepto de diseño relacionado con Big Data.

Una vez que los jugadores han elegido una carta, calculan un total en base a la influencia del concepto de diseño seleccionado sobre los drivers asociados a la iteración. Después de eso, simulan el paso 5 de ADD tirando dos dados. Respecto al paso 6 de ADD, como parte del juego no se realizan bosquejos del diseño, pero sí se documentan las decisiones de diseño, es decir los conceptos de diseño elegidos.

El paso 7 de ADD es guiado por el facilitador quien describe cuáles eran las opciones más apropiadas a elegir como parte de las iteraciones. Dependiendo de lo elegido, los jugadores reciben puntos adicionales o bien son penalizados. Para cada iteración se calcula un puntaje total que combina los puntos de las cartas elegidas, el resultado de tirar los dados y los bonos o penalizaciones resultantes del análisis. Al final del juego, se suman los puntos recibidos en las distintas iteraciones y se calcula un total. El jugador con el total más alto gana.

Una vez que termina el juego, el facilitador promueve una discusión con los participantes con el fin de intercambiar experiencias y opiniones relativas al juego y al proceso de diseño de arquitecturas en general. Esta discusión es un aspecto fundamental dentro de las sesiones de juego.

Conclusión

Smart Decisions es un juego que busca ilustrar el proceso que se sigue para diseñar arquitecturas de software usando ADD. Actualmente, el juego dispone de contenido enfocado al diseño de un sistema de Big Data, pero en el futuro esperamos disponer de otros contextos de juego. Hemos tenido la oportunidad de realizar sesiones de juego con diversas poblaciones que incluyen arquitectos de software, profesores y también con estudiantes(1). A raíz de estas sesiones, hemos recibido retroalimentación muy positiva acerca del juego.

Por último, cabe señalar que el juego está disponible de forma gratuita en http://www.smartdecisionsgame.com

Los invitamos a que lo descarguen, lo jueguen y nos den su opinión al respecto. Adicionalmente, estamos buscando contribuciones de la comunidad para generar otros contenidos en áreas distintas a Big Data.

Referencias

Cervantes, H., Haziyev, S., Hrytsay, O., Kazman, R. “Smart Decisions: An Architecture Design Game”, http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=436542, SATURN Conference 2015.

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. http://humbertocervantes.net

4 Actividades UX Para Disolver Controversias de Desarrollo

sg — Wed, 23 Dec 2015 03:06:03 +0000

4 Actividades UX Para Disolver Controversias de Desarrollo

sg Tue, 12/22/2015 - 21:06

Publicado en

SG #49

User eXperience

Autor

Misael León

Uno de los momentos claves en el trabajo de un UX Designer es presentar sus hallazgos de investigación y comunicar las soluciones propuestas. De su éxito depende que no se generen malos entendidos respecto a cómo debe funcionar el producto de software a desarrollar. Pero, ¿por qué esa habilidad es crucial y cómo afecta al resto del equipo? ¿Cómo podemos unificar esfuerzos y evitar confusiones?

¿Qué está sucediendo?

Comunmente Developers, QA Testers y Product Managers precisan un punto central de discusión del cual se desprendan las tareas individuales. Presumiblemente todos ellos trabajan bajo el mismo objetivo: crear el mejor producto y la experiencia más placentera para el usuario. Es fácil ver que esa pieza central puede ser el prototipo a desarrollar. El prototipo debe convertirse en el punto de partida para alcanzar un acuerdo común. De no hacerlo así se corre el riesgo de crear un monstruo sin pies ni cabeza.

Cuando los desarrolladores no conocen las razones detrás de las decisiones de diseño a menudo son reacios a implementar los cambios y solución planteada. Si el UX Designer falla en comunicar efectivamente su trabajo, enfrentará objeciones como “eso tardará varios meses”, “eso no es posible”. Si este es tu caso hay una manera sencilla de lograr el efecto opuesto.

La solución

Para pasar del “no se puede” al “sí, creo que esto traerá valor” simplemente debemos involucrar a todo el equipo desde el inicio. Desde la generación temprana de prototipos hasta las pruebas de usabilidad. De esta manera entenderán por sí mismos que las decisiones de diseño son soluciones a problemas reales de gente real.

Ver a los usuarios frustrarse con un software pobremente desarrollado y diseñado es la mejor manera de subir a todos al mismo barco. El problema adquiere rostro y es validado por observación propia. Presenciar cómo el producto en el que has trabajado arduamente pierde su valor por una característica mal implementada es un golpe psicológico contundente. Después de presenciarlo el equipo sentirá el impulso de corregirlo de inmediato.

1. Crear el prototipo

Un prototipo efectivo puede variar en sus niveles de fidelidad al producto real. Desde un dibujo hecho a mano, wireframes hechos en software de prototipado rápido, hasta prototipos de alta fidelidad ricos en color e interacciones.

Es altamente recomendado que el prototipo esté fundamentado en investigación previa sobre hábitos y expectativas de los usuarios. Para esto existen varias metodologías de UX que podemos aplicar. Hay que recordar que hacer investigación es salir a la defensa de los usuarios [1].

El nivel de fidelidad de tu prototipo depende de la etapa de desarrollo en la que se encuentre el producto. Aquí una guía rápida:

Nivel de Fidelidad	Cuándo Usarlo	Herramientas	Pruebas de Usabilidad
Paper Prototyping	- Generación preliminar de ideas - Para validar arquitectura de información - Decidir entre alternativas de layout	- Papel y lápiz - Pop App - InVision	Sí
Black & White Wireframes	- Validación temprana - Para resolver dudas sobre interacciones básicas - Descubrir barreras técnicas - Detallar conceptos de arquitectura de información - Definir contenido	- UX Pin - Balsamiq - Axure - Moqups - Sketch - Atomic - Adobe Illustrator / Photoshop - Macaw	Sí
Hi-Fi Prototypes	- Definir estilos - Pruebas de deseabilidad con A/B testing - Para ganar feedback más certero al producto final	- Sketch - InVision - Balsamiq	Sí
Working Demo	- Refinar detalles - Descubrir interacciones nuevas - Entender nuevos hábitos creados por el producto mismo	Para probar: - CrazyEgg - UserZoom - FiveSecondsTests	Sí

Es una buena práctica incluir a todo el equipo desde el primer día en que comiences a prototipar. Así nuestra solución irá creciendo siendo validada desde todas las perspectivas: la de negocios, la técnica y la de los usuarios.

Con prototipo en mano, el equipo ahora está listo para verlo en acción. Someterlo a pruebas tempranas nos permitirá:

detectar errores críticos de conceptualización,
corregir inmediatamente antes de gastar horas de producción,
aprender más sobre el problema a resolver.

Al tener contacto directo con los usuarios notaremos que nuestro entendimiento del problema irá modificándose. Esto es absolutamente normal, se le conoce como la paradoja del problema/solución [2].

2. Reclutar usuarios

Ha llegado el momento esperado. Tienes un prototipo listo y estás ansioso por probarlo. Pero, ¿con quién y cómo?

Algunas recomendaciones para reclutar usuarios:

Definir un perfil deseado en caso que el producto no tenga usuarios activos todavía.
Ofrecer siempre una recompensa por el uso de tiempo que nos concederán.
Brindar opciones de horarios previamente definidos, que ellos elijan.
Hacerles saber que es una invitación abierta sujeta a quien responda primero.
Usualmente de 5 a 8 usuarios por prototipo es suficiente [3].
Pedir ayuda al departamento que ya tiene contacto con ellos, como ventas o soporte.

3. Probar prototipo

Estas son algunas recomendaciones básicas:

Preparar un guión. Hay ciertas consideraciones que los usuarios deben saber antes de iniciar la prueba. Por ejemplo: que hable en voz alta todo lo que piensa, que no recibirá ayuda durante la prueba, que no se le está evaluando a él/ella, que todas las preguntas serán resueltas eventualmente. En http://swgu.ru/qz hay una plantilla que puede ser útil. Es indispensable que el guión puntualice las tareas que el usuario ejecutará. Esta es la parte esencial de las pruebas de usabilidad: observar las maneras en que los usuarios se las arreglan sin ayuda para completar una tarea específica.

Grabar la sesión. Estamos en el entendido que los integrantes del equipo nos acompañarán como observadores durante las sesiones. Sin embargo es buena idea grabar en video la acción, o al menos la acción en pantalla. Esto servirá en el futuro cuando se necesite o alguien más quiera referenciar o recordar ciertos aspectos clave de la interacción.

Sesiones remotas. No descartar la posibilidad de probar el prototipo con usuarios no presenciales. Podemos hacer una videollamada y grabar la acción de la pantalla. Algunas herramientas como InVision nos permiten ver claramente los clics que realiza el usuario.

Aprovecha la oportunidad. Tener a un usuario que no tiene idea de todas las discusiones acaloradas en las juntas de equipo es invaluable. Es nuestra oportunidad de salir de cualquier duda y desechar supuestos. Los usuarios son despiadados y nunca quieren esforzarse de más. Es solo una interfase, ¿por qué habrían de meditar más de lo necesario en encontrar una opción? Simplemente guardemos silencio y observemos la ejecución de la tarea solicitada.

Prepararse para lo inesperado. Ley de Murphy. Todo aquello que pueda salir mal, saldrá mal. Se caerá la red, fallará la herramienta de prototipado, cancelará un usuario, nos daremos cuenta que el prototipo no contempla una parte esencial, etcétera. Todo puede pasar y hay que estar listo. Conservar la calma y ser honesto con lo que está sucediendo. No pasa nada.

4. Analizar resultados

La pregunta del millón es: ¿qué tan detallado debe ser un reporte de usabilidad? La respuesta es dependiendo de a quién va dirigido:

Si es para nuestro equipo, un prototipo anotado, una lista de user stories, y clips de video es suficiente.
Si es para top level executives debemos incluir la metodología utilizada, los descubrimientos, y los errores a corregir. En un formato muy puntual, no más de dos cuartillas.
Si es para nuestro propio registro de documentación, puede ser tan extenso como el tiempo nos lo permita.

En todos los casos anteriores entre más visual sea la información es mejor. Nadie tiene tiempo de leer exhaustivos reportes. Al final es útil ser organizado, llegará el día en que cuestionen las razones detrás de una decisión de producto y es mejor estar preparado.

Ningún reporte de usabilidad es suficiente si solamente se queda en documento. Hay que transformarlo en un prototipo corregido y mejorado con las oportunidades encontradas. El reporte de usabilidad es siempre el inicio de la siguiente iteración.

Conclusiones

El prototipo es la pieza estratégica ideal de discusión del equipo de desarrollo. El prototipo es “tangible” porque es un artefacto concreto con ideas estructuradas. También representa la solución más aproximada en términos técnicos, de limitaciones de negocio, y de deseabilidad por parte de los usuarios, a problemas reales de los cuales se tiene evidencia.

La presencia del equipo de desarrollo como observadores durante las pruebas de usabilidad es una estrategia sabia para sintonizar los esfuerzos de todos hacia un mismo objetivo y agilizar el proceso mismo de desarrollo.

La aprobación de las soluciones de diseño propuestas no solamente depende de la efectividad del UX Designer para comunicarlas, sino también del entendimiento que todo el equipo tenga sobre el problema a resolver.

En Nearsoft tenemos una filosofía central. La mejor manera de hacer software es comenzar lento y avanzar rápido hacia el final [4]. Esto nos evita deshacer, rehacer, borrar y desechar código y esfuerzos.

Referencias

M. León. “A La Defensa De Los Usuarios: Siete Técnicas UX Para Cambiar El Mundo” SG #47. http://swgu.ru/qk
T. Wendt. “Design for Dasein: Understanding the Design of Experiences”. CreateSpace, 2015. http://swgu.ru/qw
J. Nielsen. “How Many Test Users in a Usability Study?” NN Group, 2012.
http://swgu.ru/qx
J. González. “Three Reasons Your Project Is Late and What You Can Do About It”. http://swgu.ru/qy

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. Es colaborador del UX Clinic, una iniciativa dedicada a difundir las mejores prácticas de UX. Es fanático de los libros, el cine, los chocolates. Promotor de la filosofía del asombro.