SG Software Guru #46 by Revista Software Guru

SG SOFTWARE GURU

Modelado de negocio con BPMN Pag. 32

Clean Coding Pag. 34

Arquitectura y Preventa Pag. 38

No.

TUTORIAL

Programación Orientada a Aspectos

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

No.46 | Noviembre 2014 - Enero 2015

ESTUDIO DE SALARIOS 2014

TALENTO CÓMO ENCONTRAR, ATRAER Y RETENER

www.sg.com.mx |

Software Guru

CONOCIMIENTO EN PRÁCTICA

.CONTENIDO

Noviembre 2014 - Enero 2015 | www.sg.com.mx

Pág.

24 En Portada ¿Cómo Encontrar, Atraer y Retener Talento?

En esta ocasión publicamos artículos con recomendaciones y perspectivas sobre qué pueden hacer las empresas para lograr encontrar, atraer y retener talento en esta industria donde el capital humano es clave.

.CONTENIDO

Especial Estudio de Salarios SG 2014

Durante noviembre de 2014 realizamos una edición más de la ya tradicional Encuesta de Salarios de SG. Conoce los resultados de este año.

Pág.

16 Reportaje Parquesoft

Emprendiendo Consejos para un Buen Pitch 08

Herramientas y Novedades

Columnas Tejiendo nuestra red

Por Celeste North

Lo que viene

Tutorial: AOP con Ptolemy

Prácticas BPMN

Por Luis Daniel Soto

Por Enoc Cruz Nájera y Germán H. Alférez

Código Innovare

Calidad

Por Armando Peralta Díaz

Por Victor Luna y Fernando Arana

Programar es un Modo de Vida

Ingeniería de Software

Por Gunnar Wolf

Por Abel García Nájera

Columnas invitadas: ¿Por qué Documentar el Código?

Por José Sánchez

Carta a la Tía Margarita

Arquitectura

Por Humberto Cervantes

Por Marco A. Dorantes

Tecnología

Cuando el Big Data y el Internet de las Cosas Colisionan 48

Por Miguel Ángel Barajas

Infraestructura

Por Manuel del Pino

Más Allá del Software

Por Víctor Hernández

En Cada Número Editorial

Noticias

Gadgets

Biblioteca

¿Cómo Sobrevivir a un Proyecto en Gobierno? 50 Por Héctor Santillán

Cómo Aprovechar la Arquitectura Empresarial en la Administración de Proyectos de TIC Por Oscar Gutiérrez Rodríguez

www.sg.com.mx |

Tendencias en Software

Software Guru

Por Hanna Oktaba

.EDITORIAL Bienvenida

“Si a una empresa le interesa más tu título que tu github, huye”. @pedrogk

. Personas por encima de procesos

ace diez años que comenzamos Software Guru, y desde entonces hemos estado preocupados y ocupados en contribuir a que en nuestra región haya más profesionistas de software, mejor preparados, y trabajando en mejores empresas. Parte crucial de este esfuerzo es conocer cuál es la compensación que reciben estos profesionistas, y qué factores son los que más la impactan. Pero lograr atraer y retener al mejor talento va más allá del dinero. Es por ello que en esta edición de SG enfocada al talento, hemos incluido artículos para platicar sobre dónde está el talento, cómo involucramos a más mujeres en TI, o cómo puedes hacer a tu empresa más atractiva hacia desarrolladores. Aprovechamos este espacio para desearles unas felices fiestas y cierre de año (cruzamos los dedos para que esos proyectos que tienen que salir antes de fin de año sí salgan sin problemas). Esperamos que también tengan un excelente inicio de 2015, en el cual nos seguiremos viendo. Tenemos ya planeados varios eventos (Mobile Day, SG Virtual, SG Conferencia y Expo, entre otros) e iniciativas. Los invitamos a consultar la información en los anuncios de estas páginas.

››Equipo Editorial SOFTWARE GURU

DIRECTORIO SG Dirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial 360° Contenidos on Demand / Arte y Diseño Oscar Sámano / Suscripciones Patricia Moreno Consejo Editorial Jorge Valdés - PMI / Luis Cuéllar - Softtek / Luis D. Soto - Microsoft / Hanna Oktaba - UNAM / Emilio Osorio - Sistemas Humanos / Luis Vinicio León - e-Quallity / Gloria Quintanilla

Colaboradores

Guadalupe Trujillo, Ulises Juárez, Beatriz A. Olivares, Ignacio López, Celia Romero , Celeste North, Erick Camacho, Raquel Hernández, Fabiola Calderón, Jeduan Cornejo, Enoc Cruz Nájera, Germán H. Alférez, Víctor Luna, Fernando Arana, Abel García, Humberto Cervantes, José Sánchez, Marco A. Dorantes, Armando Peralta, Gunnar Wolf, Manuel del Pino, Víctor Hernández, Héctor Santillán, Óscar Gutiérrez, Miguel Ángel Barajas, Mariel García, Alejandro Vizio.

Dirección Comercial Claudia Perea / Atención a clientes Yoloxochitl Juárez / Marketing y Alianzas Fernando Hernández SGCampus Ariel García / Proyectos Especiales Vanessa Amaya Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., San Francisco 238 Altos. Col. Del Valle. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 4.0 Internacional. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: En trámite. ISSN: 1870-0888. Registro Postal: PP15-5106. Distribuido por Sepomex.

.NOTICIAS

.Prosoftware recibe certificación de organización internacional de clústeres

El Clúster de Tecnologías de Información de la Ciudad de México (Prosoftware) recibió la certificación Bronce, otorgada por la European Cluster Excellence Iniciative, una iniciativa que reconoce la excelencia en los procesos de gestión de los clústeres en el mundo. Para Prosoftware, esta certificación es de vital importancia ya que no solo reconoce la calidad de la industria de la región, sino que va de la mano con el compromiso del clúster de otorgar el apoyo necesario para que las TI crezcan y generen mayor competitividad en el sector, señaló Óscar Rivera Rodríguez, Presidente de Prosoftware. Víctor Gutiérrez Martínez, Presidente Nacional de CANIETI, señaló que este reconocimiento contribuirá para posicionar a México como un país innovador, de alta tecnología y líder en el mercado global de las tecnologías de la información.

.Gira Intel Android

De septiembre a noviembre de este año, Software Guru ha estado realizando la gira #IntelAndroid a través de Latinoamérica visitando ciudades como Bogotá, Buenos Aires, Cancún, Guadalajara, Monterrey, Aguascalientes y Ciudad de México. Esta gira es auspiciada por Intel Software y a través de ella se capacita a desarrolladores de aplicaciones móviles para enseñarles a optimizar sus apps para que funcionen de manera óptima en dispositivos x86. Para SG ha sido un gran placer recorrer estas ciudades e interactuar con personas con muchas ganas de aprender. Mantente al tanto de a donde irá la gira Intel Android próximamente en http://giraintelandroid.com

.JSConf Argentina

Buenos Aires fue controlada por Javascript durante un día, ya que el JSConf se realizó en esta ciudad el pasado 29 de noviembre. Aunque el evento solamente duró un día, fue bastante nutrido ya que fueron 12 horas con charlas de gran nivel a cargo de 18 distintos conferencistas provenientes de siete distintos países. Los más de 600 desarrolladores que participaron llenaron la capacidad del auditorio Buenos Aires y quedaron muy satisfechos. Las conferencias magistrales estuvieron a cargo de Andreas Gal (CTO actual de Mozilla) y Brendan Eich (ex CTO de Mozilla). Empresas como Wordpress, Google y Auth0 fueron los principales patrocinadores del congreso y demostraron su interés por conectar con desarrolladores en esta región. Habrá que estar al pendiente el año próximo para ver si podemos darnos una escapada a Buenos Aires para el JSConf Ar 2015.

.Rackspace abre oficina en México

Rackspace anunció la apertura de una nueva oficina ubicada en la Ciudad de México, siendo ésta su primera locación en América Latina. La empresa, líder en lo que denomina “nube administrada”, ha estado presente en la región desde hace más de diez años ofreciendo hospedaje administrado y su “soporte fanático” desde sus oficinas centrales en San Antonio, Texas. De acuerdo con ejecutivos de la empresa, Rackspace cuenta con más de 3 mil clientes en la región y la mayoría de ellos están en México, por lo que era natural abrir una oficina en este país para poder estar más cerca de sus clientes y atenderlos mejor, además de ver un gran potencial de crecimiento en esta región.

Para mayor información, noticias al día y actualizaciones de la industria visita: www.sg.com.mx

www.sg.com.mx |

El pasado 25 de noviembre en el marco del Foro AMITI, la organización IMPULSA-TI presentó el Sistema de Capital Humano (SICAPH - TI). IMPULSA-TI es el programa que atiende la brecha entre la formación académica y la fase laboral de talento, que con el objetivo de conocer y administrar dicho talento en México, ha desarrollado el SICAPH, sistema que identifica los perfiles y localiza físicamente a los profesionistas que las instituciones generan. Con el objetivo de cerrar dicha brecha, el sistema permite realizar un mapeo entre los diferentes perfiles que provee la academia y los perfiles que demanda la industria, todo alineado al Modelo Paracurricular desarrollado igualmente por IMPULSA-TI. Para conocer más sobre el modelo y el SICAPH visita: http://www.impulsati.org

Software Guru

.IMPULSA-TI presenta el SICAPH-TI

.COLUMNA Tejiendo Nuestra Red

ESENCIA

Y SU USO PARA REFORZAR LA GESTIÓN DE LOS PROYECTOS DE SOFTWARE

n el número anterior les prometí hablar de cómo usar ESSENCE (lo voy a traducir como Esencia, que suena muy bonito) en la vida diaria de los proyectos de software. El concepto básico de la Esencia es algo llamado ‘alfa’. Su uso puede reforzar tanto la gestión tradicional de proyectos (PMBoK) como la ágil. ¿Qué es un alfa? Como lo explican Ivar Jacobson y sus allegados, es una cosa con la cual se tiene que trabajar, o en otras palabras, puntos que hay que tener muy presentes en todo momento durante un proyecto (endeavor) de desarrollo de software. Los alfas captan los conceptos clave recogidos de la experiencia de los últimos casi 50 años de la Ingeniería de Software.

“Las listas de verificación de

Esencia sintetizan la

experiencia práctica de la ingeniería de software.”

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares. hanna.oktaba@ ciencias.unam.mx

No por nada, la propuesta está liderada por Ivar Jacobson, uno de los gurús más viejitos pero de estos que siguen “coleando”. Los alfas permiten dar seguimiento, evaluar el progreso y la salud de cualquier proyecto de ingeniería de software y proporcionan una base común para la definición de los métodos y prácticas de ingeniería de software. Esencia identifica siete alfas las cuales se ubican en tres áreas de interés: cliente, solución y esfuerzo (equivalente a un proyecto). Esto se ilustra en la figura 1: • Área del Cliente. Contiene los alfas de oportunidad (opportunity) e interesados (stakeholders). • Área de la Solución. Contiene los alfas de requerimientos (requirements) y sistema de software (software system). • Área del Esfuerzo/Proyecto. Esta área considera los elementos para realizar el proyecto tales como equipo (team), forma de trabajar (way of working) y trabajo (work). En el área del cliente, la oportunidad representa todo lo que le da el valor al que va a invertir en el sistema. Los interesados son principalmente los que necesitan y pagan por el sistema de software, así como los que lo usarán y mantendrán. En el área de solución no requiere mayor explicación. Lo que sí vale la pena notar es que el diseño no está explícito, sino que está “perdido (diluido) en el espacio”. En mi opinión creo que fue una concesión a los agilistas (por favor que éstos no se me ofendan). El área de esfuerzo afortunadamente contempla a las personas (equipo), sin ellas todo lo demás es imposible ☺ (disculpen el uso exagerado de las ☺ pero últimamente ando en la onda de las UX). El alfa de la forma de trabajar es, ni más ni menos, el proceso que se va a seguir (favor de no decírselo a nadie, menos a su gestor de procesos ☺).

En resumen, el alfa de Trabajo representa la chamba del Equipo que aplica la Forma de Trabajar para implementar el Sistema de Software, que cumpla con los Requerimientos acordados por los Interesados, con el cual se logra la Oportunidad. Esta es la esencia de los alfas de la Esencia. Pero el meollo del asunto está en que cada alfa pasa por una serie de estados secuenciales. Dichos estados reflejan la evolución deseada de los temas de los alfas desde el inicio hasta la final de un proyecto. Por ejemplo, un Equipo pasa por los estados: Sembrado, Formado, Ejecutando, Colaborando y Suspendido (este último es cuando ya el equipo dejó de trabajar en el proyecto). Y ¿cómo saber en qué estado se encuentra un alfa? Para ésto se han definido las listas de verificación (checklists) que ayudan a analizar si cumplimos los criterios para colocar un alfa en cierto estado. Estas listas de verificación de los estados de los alfas son, en mi opinión, la síntesis más importante hasta la fecha de la experiencia práctica de la Ingeniería de Software. Otra característica interesante, es que son independientes a las metodologías; no dependen de las técnicas ni procesos particulares. Para ejemplificar, les presento la lista de verificación para constatar si el alfa del Equipo está en el estado Sembrado: • La misión del equipo ha sido definida en términos de las oportunidades y resultados. • Se conocen limitaciones al funcionamiento del equipo. • Se conocen los mecanismos para hacer crecer al equipo. • Está definida la composición del equipo. • Están definidas las restricciones sobre dónde y cómo se llevará a cabo el trabajo. • Están descritas las responsabilidades del equipo. • El nivel de compromiso del equipo es claro. • Se identificaron competencias requeridas.

.COLUMNA Tejiendo Nuestra Red

• El tamaño del equipo está determinado. • Reglas de gobierno están definida. • Se seleccionó el modelo de liderazgo.

La práctica de reflexión

Objetivo: Analizar la salud del proyecto de software usando alfas para proponer las acciones que ayuden a continuar el proyecto con éxito. Entradas: Se reúne todo el equipo, se eligen los alfas con las se quiere trabajar (pueden ser todas o las que son importantes para el momento del avanze del proyecto), se ponen en la mesa las tarjetas impresas con los nombres de los alfas, nombres de los estados y las listas de verificación de cada estado (ver ejemplo en la fig. 2). Existen las opciones electrónicas para revisar los estados de las tarjetas en web - essence.sv.cmu.edu y la aplicación State Explorer para iPhon. Guía de actividades 1. Para cada alfa elegido, cada miembro del equipo revisa en su cabeza las listas de verificación de los estados y decide el estado alcanzado según él. 2. Todos los miembros del equipo compar07

ten su decisión con los demás argumentando con base en las listas de verificación. 3. En el caso de discrepancia de las opiniones, se discuten hasta lograr el consenso los elementos de las listas de verificación en los que no coinciden. En este paso se ejercita la idea de la democracia- todos tienen derecho de opinar, y de no perder el foco- sólo se discuten cumplimientos de los puntos de las listas de verificación y no los clásicos de echar la culpa unos a otros. 4. El equipo analiza cuáles de los objetivos de la lista de verificación del estado siguiente quiere alcanzar y qué acciones deben de tomarse para lograrlos. Criterios de verificación: Todos los miembros del equipo están conformes con la evaluación de los estados alcanzados y de las acciones a tomar para avanzar a los siguientes estados. Mediciones: Tiempo dedicado a la reunión de reflexión (horas/hombre). Resultado: • Lista de acciones para incluir en el plan de trabajo inmediato. • Todos los miembros del equipo conocen el estado actual del proyecto (o un aspecto representado por un alfa) y están de acuerdo en lo que hay que hacer para avanzar con éxito en el proyecto.

A los administradores de proyectos o Scrum Masters que no se han convencido con mi explicación, les recomiendo que primero hagan este ejercicio solitos. Con quienes he visto que lo han intentado, les ha caído el veinte luego, luego (para los lectores de otros países “caer el veinte” significa entender y convencerse). La ventaja de esta propuesta es que con pocos elementos (alfas, sus estados y listas de verificación para alcanzar los estados) tenemos resumida la sabiduría práctica de 50 años de la Ingeniería de Software lista para usarse. Qué la disfruten ☺. Para experimentar con Esencia es suficiente leer la sección 8 del documento gratuito [1]. Para los que necesitan más explicación pueden buscar el libro The Essence of Software Engineering, Applying the SEMAT Kernel, de Ivar Jacobson y sus colegas [2] o comunicarse con Jorge López de Nueva Librería (jorge.lopez@nuevalibreria.com. ar) para conseguir la traducción al español. No se pierdan el siguiente capítulo de la aplicación de Esencia

>> Por Hanna Oktaba

Referencias [1] ESSENCE - Kernel and Language for Software Engineering Methods 1.0 - Beta 2 http://www.omg.org/spec/Essence/1.0/Beta2/ [2] Ivar Jacobson and all. The Essence of Software Engineering: Applying the SEMAT Kernel, AddisonWesley, 2013.

Software Guru

Nombre: Reunión de Reflexión con Alfas de Esencia (Id ReflexAlfas).

Fig 1. Alfas por áreas de interés y sus relaciones [1].

www.sg.com.mx |

Pero me van a preguntar: ¿cómo podrían usarse los alfas, sus estados y las listas de verificación para reforzar la gestión de proyectos? La propuesta más simple es agregar las reuniones de reflexión, que se apoyen en los alfas, para complementar a las reuniones de seguimiento o reuniones diarias de Scrum. La práctica de reflexión es la siguiente, descrita como lo propone Kuali-Beh (apéndice B de Esencia [1])

.REPORTAJE

ParqueSoft Por Pedro Galván

arquesoft es una red de parques tecnológicos que hospeda a microempresas de tecnología y servicios relacionados. Inició operaciones hace 14 años en Cali, Colombia y actualmente la red ParqueSoft opera en 14 ciudades de Colombia, reuniendo a más de 200 empresas que integran a más de 1,000 personas. Hace cerca de 9 años que me enteré de la existencia de ParqueSoft, y desde entonces he tenido un gran interés por este ecosistema. Este verano tuve oportunidad de viajar a Cali, así que aproveché para visitarlos y conocer más.

Entendiendo a ParqueSoft

Sé que hoy en día abundan los parques tecnológicos, espacios de coworking, incubadoras y aceleradoras de startups, así que Parquesoft podría parecer simplemente “uno más”. Sin embargo, tiene un enfoque distinto que a mi parecer lo hace único. Tal vez la mejor forma de entender a ParqueSoft es pensar en una familia: hay una cabeza de familia, y muchos hermanos(as); todos nacen del mismo vientre (aunque también se aceptan adoptivos) pero cada uno tiene su propia identidad, habilidades y objetivos; comparten el mismo hogar, pero cada uno se gana la vida a su manera; hay hermanos mayores que ya salieron de casa pero siguen siendo parte de la familia, y hay otros que aunque ya podrían vivir por su lado les gusta seguir en casa. En este caso, la cabeza de la familia es la Fundación ParqueSoft, presidida por Orlando Rincón (a quien probablemente recuerden como conferencista en eventos anteriores de SG). La fundación administra los parques y provee servicios horizontales a las empresas: infraestructura, administración, aspectos legales, etcétera. La mayoría de las empresas nacen dentro del mismo ParqueSoft. Es decir, ParqueSoft no se dedica a buscar empresas ya formadas, sino que busca a personas con

talento e iniciativa, y una vez en ParqueSoft se juntan entre ellas para formar empresas. Esto es clave, porque hace que todas las empresas tengan un alto sentido de pertenencia a ParqueSoft.

3 en 1: incubadora, cluster e integradora

La mayoría de los clusters de TI que he conocido están formados por empresas con ofertas muy similares, que compiten entre sí y no tienen mucha oportunidad de colaboración. En ParqueSoft no es así, ya que muchas de las empresas nacen a raíz de lo que ven que está haciendo falta en la oferta de otras empresas de ParqueSoft. Entonces, en ParqueSoft encuentras tanto startups como empresas de desarrollo a la medida, y otras que ofrecen servicios de soporte (por ejemplo servicios legales, de marketing, fuerza de venta, aseguramiento de calidad, integración de hardware, multimedios y hasta estación de radio). El hecho de que las empresas de ParqueSoft tengan un origen común pero ofertas complementarias facilita que participen en proyectos conjuntos. Es aquí donde entra la cara de ParqueSoft como integradora de empresas. Es decir, a pesar de que cada empresa opera por su lado y tiene sus propios clientes, hay proyectos de gran escala donde la Fundación ParqueSoft opera como un “prime” o integrador, que reparte y coordina el trabajo de las distintas empresas que participan en el proyecto.

ParqueSoft en otros países

Como se podrán dar cuenta, no tengo más que elogios para ParqueSoft. Me parece un caso muy interesante y exitoso; la verdad es que me da envidia que en México no tengamos algo así. La buena noticia es que ParqueSoft está buscando internacionalizarse, y no duden que pronto encontremos ParqueSoft en otros países de nuestra región.

www.sg.com.mx |

Software Guru

.HERRAMIENTAS Y TECNOLOGÍAS Lo Que Viene

JetBrains liberó la versión 14 de su popular IDE IntelliJ IDEA. Entre las novedades de esta versión, posiblemente la más interesante es que incorpora un decompilador de código Java que permite ver la estructura del código de librerías a partir de su clase compilada (sin que tengamos el código fuente). Otro frente con mejoras significativas es la depuración de código, tal como la capacidad de mostrar el valor de variables en el mismo editor, así como la evaluación de expresiones lambda. Otra capacidad útil es la posibilidad de seleccionar un objeto y visualizar todos los objetos (incluyendo arreglos, colecciones, referencias indirectas, etcétera) que hacen referencia a dicho objeto. IntelliJ IDEA 14 incorpora todas las capacidades de Android Studio Beta, incluyendo soporte para Android Wear y Android TV, por lo que puede ser una muy buena opción para desarrollar Android apps. https://www.jetbrains.com/idea

Se viene la batalla por el hosting administrado

Rackspace está estrenando oficinas en México, Softlayer anunció un data center en México, Kio Networks lanzó su oferta Koolfit de cómputo administrado desde la nube, y parece que por fín el gobierno federal se está convenciendo de poner sus datos en el data center de Infotec en Aguascalientes. En otras palabras, parece ser que las empresas en México por fín se están abriendo al hosting administrado y cómputo en nube privada (o al menos eso esperan los proveedores). Sin duda, como consumidores de estos servicios nos veremos beneficiados de esta competencia. Y si te dedicas a administrar infraestructura de cómputo en una empresa, te recomendamos ir poniendo tus barbas a remojar (y aprender OpenStack).

Meteor es una plataforma open source para construir aplicaciones web y móviles en JavaScript. Está diseñado principalmente para ofrecer UIs que se actualizan en tiempo real, por lo que es ideal para aplicaciones que muestran información o colaboración multi-usuario en tiempo real. En Meteor, el default es tiempo real por lo que todas las capas, desde la base de datos hasta los templates, se actualizan por sí solas de forma automática cuando es necesario. Después de poco más de dos años de desarrollo, Meteor liberó su versión 1.0. Entre las novedades de esta versión están mejoras en el soporte para aplicaciones móviles, tanto en iOS como Android. También se mejoró el manejo de paquetes con dependencias a librerías binarias para distintas arquitecturas de procesador. http://meteor.com

AWS Lambda

IntelliJ Idea 14

Meteor 1.0

AWS Lambda es un servicio de cómputo que ejecuta tu código en respuesta a eventos y automáticamente maneja los recursos de cómputo para tí. Con AWS Lambda puedes crear nuevos servicios en el back-end sin preocuparte por gestionar la infraestructura de cómputo que atenderá dichos servicios. Por medio de AWS Lambda puedes disparar automáticamente la ejecución de tu servicio cuando alguien realiza cierta actividad en tu app o sitio web. AWS Lambda ejecuta tu código solo cuando se requiere, y pagas solamente por las peticiones atendidas y el tiempo de cómputo requerido para ejecutar tu código. La cobranza se realiza en incrementos de 100 milisegundos de cómputo, así que realmente solo pagas lo que usas. Entre los escenarios donde se visualiza que un servicio como Lambda puede ser útil están: procesamiento disparado por eventos (ej. comprimir un archivo cuando este se sube a un servidor), procesamiento de tareas batch calendarizadas, y servicios back-end para responder a eventos generados por sensores conectados a la red (Internet of Things). http://aws.amazon.com/lambda

.COLUMNA

Tendencias

en software

El Hogar Inteligente

iOS y Android que controlan luces, cortinas o variedad de equipos se han hecho presentes. Equipos de audio multi-zona y termostatos digitales son apenas el principio del “hogar inteligente”. Hoy, la mayoría de la gente que conozco no necesariamente ha cambiado las configuraciones por omisión de sus ruteadores y ni siquiera instalado software para restringir el acceso de internet a menores. Tenemos PCs viejas tratando de acceder servicios web que han dejado de existir. Pocos son los que han invertido en los focos de $60 dólares que se pueden controlar desde una app (requieren no solo de wifi sino de BLE). La perspectiva del “hogar inteligente” en orquestar accesorios inteligentes, robots, nuestro reloj y la cafetera, los sensores de líquidos y gas es maravillosa. Puedo asegurar que realmente nos encontramos en una etapa muy temprana de la visión. No solo por el aspecto tecnológico y de normas, posiblemente por nuestra capacidad de ser inquilinos de enjambres tecnológicos muy variados. Las normas en definición hoy están en competencia, no terminadas y son de bajo nivel. Pensar en esa alfombra con sensores que nos dirá cuántas veces hemos pisado cada centímetro cuadrado abre cientos de áreas de oportunidad y nuevas preguntas de la eficiencia de nuestros hogares. Los casos de uso no están totalmente definidos, determinar lo que puede salir mal y como radicalmente pensar las relaciones con los individuos es una tarea en proceso. Soy entusiasta del tema y en mis siguientes columnas describiré los escenarios del “internet de coLuis Daniel Soto Maldonado sas” en nuestro hogar… no sin antes poner en (@luisdans) se dedica a asesorar perspectiva la complejidad de la problemática empresas en estrategia tecnolóy nuestra realidad existente. gica y gestión de productos.

>> Por Luis Daniel Soto Maldonado

www.sg.com.mx |

a vida digital nunca ha sido simple, especialmente en el hogar. Las primeras computadoras y el software mismo eran de muy alto costo. La guerra de formatos y protección contra copiado ha dificultado conservar en su más alta calidad el contenido y reproducirlo sin fricción. Durante muchos años me dedique a digitalizar mis CDs y DVDs cuando el almacenamiento era aún costoso - mantener los “metadatos” en orden continúa siendo un reto. La década pasada fue relativamente fácil con el “teatro en casa”: una sola PC conectada a un monitor de buenas dimensiones. Una sola cámara digital y un proceso de transferencia manual de datos. Consolidar el servicio de cable nunca ha sido sencillo, aún hoy las consolas de videojuegos no lo ofrecen. En mi caso y por distintas razones termine con películas adquiridas en Xbox Live, Amazon Video, Vudu, Sony Unlimited, Apple iTunes y Android Play. Aun soy usuario del DVR y probé Netflix pero finalmente opté por usar Redbox. Hoy tengo una solución para ver mis películas y escuchar mi música favorita en cualquier dispositivo y lugar con una combinación de PC, nube y dispositivos electrónicos personales. Hoy en día esa PC de “teatro en casa” evolucionó en un servidor multimedia utilizando Plex. No anticipo que los múltiples servicios de video converjan pronto, por lo que apuesto a mantener mi propia colección de favoritos en formatos abiertos y también acceder servicios de consumo ilimitado para música (Pandora), revistas digitales (Next issue), libros (Kindle subscription) y cualquiera de los que ya mencioné de video. Hoy ha sido ya difícil tener que adquirir cables y conectores específicos para diversos sistemas de reproducción de medios digitales y pantallas, configuraciones específicas para obtener el 7.1 de audio o los formatos que nunca fueron exitosos como super audio digital (aunque en mi auto continúo escuchándolo). Los controles remotos programables y las aplicaciones para

Software Guru

Llegará Hasta el 2020

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

APLICACIÓN DE ASPECTOS Y DISEÑO POR CONTRATO CON

PTOLEMY

›› Por Guadalupe I. Trujillo, Ulises Juárez, Beatriz A. Olivares, Ignacio López, Celia Romero - Instituto Tecnológico de Orizaba

as principales ventajas que ofrece la Programación Orientada a Aspectos son: separación de asuntos (componentes y aspectos), facilidad para razonar conceptos, alto nivel de reutilización y mejor mantenimiento del software. Actualmente, existen varios Lenguajes Orientados a Aspectos entre los que destacan: AspectJ, CaesarJ, ECaesarJ, EOS, y Ptolemy. Cada uno proporciona mecanismos que contribuyen al desarrollo o mantenimiento del software dependiendo de lo que se desee realizar. El Diseño por Contrato es una técnica muy conocida para el diseño de software de calidad. Los beneficios más importantes del DbC son: facilitad de pruebas unitarias, manejo de excepciones de manera eficiente y construcción de componentes robustos. Las principales herramientas que implementan el DbC en Java son: jContractor, Jass, Modern Jass, Contract4j, JML y Ptolemy. Sin embargo, no se reporta alguna guía para el desarrollo de software con Ptolemy. El propósito de este artículo es ofrecer una guía básica de cómo aplicar conceptos orientados a aspectos en Ptolemy utilizando ptolemy-1.2.0-beta6.

Diseño por Contrato (DbC)

El DbC es una técnica diseñada por Bertrand Meyer y característica central de su lenguaje de programación Eiffel [1]. El DbC se utiliza con cualquier lenguaje de programación, para validar que el software cumpla con su especificación (contrato). El contrato establece condiciones de uso e implementación denominadas aseveraciones que clientes y proveedores de un componente deben cumplir. En el DbC se utilizan tres tipos de aseveraciones [1]: • Precondición: restricciones bajo las cuales una rutina funcionará correctamente. • Postcondición: describe el efecto de la rutina. • Invariante de clase: restricciones que deben satisfacerse por cada objeto tras la ejecución de los métodos y constructores.

Ptolemy

Ptolemy es un lenguaje de programación cuyo objetivo es mejorar la habilidad de separar asuntos conceptuales [2]. Además, ofrece el soporte para el manejo de eventos e introduce el concepto de contrato translúcido [3]. A diferencia de AspectJ y CaesarJ solventa dificultades como: • Cuantificación: referenciar los lugares en el código donde un evento es identificado sin tener que nombrar a las clases que disparan el evento. 12

• Inconsciencia: liberar al programador de las especificaciones puntuales donde una sentencia o conjunto de sentencias del programa tendrá efecto. • Fragilidad en los cortes: dependencia léxica y acoplamiento entre aspectos y código base.

Instalación. El compilador de Ptolemy se puede obtener en http://ptolemy.cs.iastate.edu/download. Requiere tener instalado un Java Runtime Environment (JRE) 1.6 o superior. Recomendaciones. El archivo bat localizado en \pyc\bin requiere de los siguientes ajustes para utilizar el compilador de Ptolemy: • Completar la sintaxis al asignar un valor a la variable de entorno PYC_HOME. El valor debe situarse entre %. • Corregir la ruta del archivo javac.jar, localizado dentro del subdirectorio \bootstrap\lib\javac.jar. Compilación. Para compilar y ejecutar programas, es necesario configurar las variables de entorno del sistema Path y PYC_HOME. Ptolemy es compatible con Java; es decir, un programa válido en Java es válido en Ptolemy. La compilación se efectúa como se muestra a continuación: pyc NombreClase.java Tras ejecutar el comando pyc, se generarán los archivos .class. Si existen errores sintácticos en el código fuente, el compilador informa de ello.

Ejecución. La ejecución de un programa en Ptolemy se realiza de la misma manera que se ejecuta un programa Java, es decir: java [nombre de clase con main()] Contrato translúcido. Un contrato translúcido para un tipo de evento es un algoritmo abstracto que describe el comportamiento de los aspectos que se aplican a una interfaz orientada a aspectos [2]. Para verificar el cumplimiento de un contrato translúcido es necesario habilitar las aseveraciones en tiempo de ejecución como se muestra a continuación: java -ea [nombre de clase con main()]

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

Orientación a aspectos

El siguiente listado de código presenta un breve ejemplo de cómo aplicar los conceptos orientados a aspectos en Ptolemy anteriormente mencionados. void event IntEvento { int x,y; // Contrato translúcido. Iniciamos con precondición. requires x < 25 && y < 120 assumes { next.invoke(); establishes next.x() == old(next.x()); } ensures x < 25 // Cerramos con postcondición. }

void metodo() { // activación del aspecto announce IntEvento(20,119) { System.out.println(“Hola!! cumplo el contrato translúcido”); } // activación que no cumple contrato announce IntEvento(200,12) { System.out.println(“No cumplo el contrato translúcido”); } } public static void main(String[]args) { new Entero().metodo(); } } Listado 1. https://gist.github.com/pedrogk/6550a1f8e08c7fbbff5f

Conclusión

Como se puede apreciar, Ptolemy ofrece una forma útil para desarrollar software correcto, es decir que la funcionalidad cumpla con su especificación mediante la aplicación de contratos translúcidos cuyo enfoque combina el Diseño por Contrato y la Programación Orientada a Aspectos. Las ventajas más destacadas de Ptolemy son: • Eliminación de fragilidad de los cortes. • Cuantificación inconsciente. • Mejora la modularidad de los asuntos de corte, preservando la encapsulación del código orientado a objetos. • Control de avisos. • Razonamiento modular.

Referencias [1] M. Bertrand. Object Oriented Software Construction. Prentice Hall, 2002.

public class Entero { Entero() { // Registra el evento en la lista de los objetos activos. register(this); }

[2] H. Rajan, G. T. Leavens et al. “Ptolemy Programming Language”. http://ptolemy. cs.iastate.edu [3] H. Rajan, G. T. Leavens et al. “Modularizing Crosscutting Concerns with Ptolemy”. http://swgu.ru/pb [4] M. Bagherzadeh, H. Rajan, et al. “Translucid Contracts for Modular Reasoning about Aspect-oriented Programs”. http://swgu.ru/pc

public void aviso(IntEvento next) throws Throwable { next.invoke(); 13

[5] M. Bagherzadeh. “Enabling Expressive Aspect Oriented Modular Reasoning by Translucid Contracts”. http://swgu.ru/pd

Software Guru

Aplicando lo aprendido

} when IntEvento do aviso;

www.sg.com.mx |

A continuación se describen los conceptos de aspectos desde la perspectiva del lenguaje Ptolemy. • Evento: Un punto de unión es un evento identificable en la ejecución de un programa. La declaración de un evento (línea 1 de Figura 1) en Ptolemy consta de 3 elementos [2]: nombre, lista de variables de contexto y tipo de retorno. • Método controlador del evento (Aviso): A diferencia de AspectJ, Ptolemy no tiene una sintaxis especial para los aspectos o avisos. En su lugar, reemplaza todos los eventos en un conjunto específico con llamadas al método controlador. • Cuantificación: Ptolemy asocia un método de clase a un conjunto de eventos identificados por un tipo de evento mediante las palabras reservadas when y do. Ptolemy cuantifica de manera inconsciente, al no depender del patrón de firmas como lo hace AspectJ, garantizando que el sistema reaccione a los eventos registrados [5]. • Variables de contexto: La exposición de contexto permite conocer cuáles son los argumentos del corte. A diferencia de AspectJ, Ptolemy no provee primitivas como target, this y args para exponer contexto, en cambio permite definir n variables disponibles para los manejadores de eventos. • Activación dinámica de aspectos: se realiza mediante palabra reservada announce, la cual puede ocurrir dentro de un método o constructor.

// Refinamiento contrato translúcido refining establishes next.x() == old(next.x()) { System.out.println(“Valor x: “+ next.x() + “\nValor y:”+next.y()); }

.EMPRESAS Emprendiendo

CONSEJOS PARA UN

BUEN PITCH ›› Por Celeste North

a vida del emprendedor es muy parecida a la de un agente de ventas en el sentido de que siempre estás (o deberías estar) invitando a la gente a probar tu producto o servicio. Siempre estás vendiendo. Ya sea tu visión, el producto en sí o el equipo que hará que todo sea posible. De ahí que sea importante siempre estar preparado para hacer un buen pitch. Un pitch es un discurso de venta. Puede venir en varios formatos, por ejemplo el elevator pitch se refiere a poder presentar tu negocio en un par de minutos; muy distinto a un pitch con inversionistas donde seguro además tienes espacio para enfocarte en detalles. De ahí, que lo primero que tenemos que hacer es pensar en el público al cuál vamos a estar pitcheando.

de la empresa será capaz de aprovechar la oportunidad de negocio. Concursos para emprendedores. En este tipo de eventos un buen pitch puede marcar la diferencia entre obtener atención sobre tu empresa o pasar desapercibido. Independientemente de que estemos de acuerdo o no sobre la relevancia de estos eventos en el ecosistema, la realidad es que como emprendedor siempre quieres ser memorable y que esto impacte en tu empresa. Aquí el objetivo es sorprender, dar información contundente y compartir tu visión de manera contagiosa.

Consideraciones

que puedas continuar. Apréndete tu pitch de memoria, imagina que le estás contando a un amigo. Es mejor ser un poco más informal y mantener la atención del público en todo momento a congelarte porque no recuerdas qué más ibas a contar. Tú eres parte del pitch. Así como pones empeño en tener una presentación increíble, ten en cuenta que al final lo que la gente recuerda es a tí. Investiga un poco sobre tu audiencia y trata de manejar un tono adecuado para ellos, por ejemplo con inversionistas serás más formal que con estudiantes o con posibles clientes. Busca una manera de enganchar con ellos, de que te sientas cercano. Elimina cualquier posible causa de estrés, desde procurar conocer el lugar donde harás el pitch, hasta usar ropa con la que te sientas seguro.

Ajusta tu pitch de acuerdo al objetivo

Lo que nadie te dice cuando te preparas un pitch es la importancia de tener cualquier detalle técnico bajo control. Algunas consideraciones que debes tener en cuenta.

Evangelizar sobre tu producto o servicio. Se refiere a presentaciones con público en general, posibles clientes o proveedores. Como tu principal objetivo es enamorarlos, enfócate en la solución, en los puntos fuertes de tu producto/servicio y los beneficios que ellos obtienen usándolo, comprándolo o trabajando contigo.

Una buena presentación también es práctica. ¿Cuántas veces no te ha tocado ver presentar a alguien que le fallaron las animaciones, el video o las tipografías en sus diapositivas? No quieres ser esa persona. Seguramente quieres poner ese video padrísimo que explica todo sobre tu startup, también es muy posible que el audio falle y sea una experiencia horrible cuando estés presentando. Como recomendación, olvídate de videos, animaciones y efectos, mantén lo más sencilla posible tu presentación. El objetivo es tener un apoyo visual que refuerce lo que estás diciendo, te recuerde las ideas que quieres transmitir y mantengan la atención de la gente. [Pro tip: exporta tu presentación a PDF para que no tengas que preocuparte por formatos ni tipografías].

Una buena presentación cuenta una buena historia. Contar historias es la forma más antigua de transmitir ideas de manera convincente. Con tu presentación lo que estás haciendo es justo eso: contar la historia de lo que se puede convertir/lograr con tu visión y tu equipo. Así como las historias tienen una estructura, piensa en el recorrido que llevará tu presentación, este puede cambiar de acuerdo a como tu decidas que funciona mejor. Una estructura recomendable sigue estos puntos: problema, solución (tu producto/servicio), características principales de tu solución, mercado (tamaño, particularidades), tracción (o cualquier número que hable de lo bien que vas), equipo (personas) y una invitación; esta invitación debe ser contundente, piensa en una frase que sea memorable y que transmita tu objetivo.

Tu presentación no es tu pitch. La ley de Murphy establece que cuando algo puede salir mal, seguramente saldrá mal. La máquina donde van tus diapositivas podría fallar, y eso no debería ser impedimento para

LA PREPARACIÓN ES TODO. Practica, ensaya, memoriza, rediseña todo lo necesario para que te sientas de lo más natural cuando empieces a contar la historia de tu startup. Y bueno, recuerda rockear, fuerte.

Hay varios objetivos por los cuáles uno hace un pitch, al momento que tenemos claridad en qué buscamos obtener de nuestra presentación, será más fácil decidir en qué puntos debemos enfocarnos. Veamos los principales objetivos para hacer un pitch:

Levantar capital para tu empresa. Si el objetivo principal es obtener inversión para tu empresa, además de hablar de las bondades de tu producto será importante que te enfoques en el tamaño del mercado. Si ya tienes algunos números, como porcentaje de conversión de prospecto a cliente o crecimiento por ciertos lapsos de tiempo (tracción), este es el momento para mostrarlos. Adicionalmente, enfócate en cómo el equipo detrás

.BIO Celeste North (@celestenorth) es Country Manager de MUBI México, plataforma de Video on Demand de cine de arte, clásico y de culto. Activa participante del ecosistema de startups en México, anteriormente fue fundadora de NuFlick y participó en Mexican.VC y Startup Chile.

www.sg.com.mx |

Software Guru

.ESTUDIO DE SALARIOS SG 2014

Estudio de Salarios

SG 2014

DURANTE NOVIEMBRE DE 2014 REALIZAMOS UNA EDICIÓN MÁS DE LA YA TRADICIONAL ENCUESTA DE SALARIOS DE SG. COMPARTIMOS AQUÍ LOS PRINCIPALES RESULTADOS. VALE LA PENA MENCIONAR QUE ESTE AÑO TAMBIÉN ESTAMOS PUBLICANDO LOS DATOS PARA QUE PUEDAS ACCEDERLOS Y GENERAR TUS PROPIAS ESTADÍSTICAS. AL FINAL DE ESTE ARTÍCULO ENCONTRARÁS INFORMACIÓN PARA HACERLO.

PG. 17

CONSIDERACIONES PARA INTERPRETAR LAS CIFRAS Las cifras y estadísticas que mostraremos en este artículo se generaron en base a una muestra de 1,550 respuestas obtenidas durante noviembre de 2014 en una encuesta abierta realizada por medio de internet. Los datos mostrados reflejan en su mayoría la situación en México, dado que 95% de los participantes en la encuesta indicaron radicar en el país. Todos los datos se refieren a salario bruto mensual, expresado en pesos mexicanos. A diferencia de otros años, donde nos guiamos principalmente por la media aritmética (promedio), para este año hemos decidido guiarnos por la mediana, ya que así las estadísticas no son tan afectadas por aquellos salarios que distan mucho del promedio. También estamos incluyendo información de la desviación estándar para que puedas tener en cuenta la dispersión de los datos en cada caso.

ACTIVIDADES Y ROLES Aunque la encuesta de salarios es contestada por personal que labora en la industria de software, sabemos que hay muchos roles distintos en esta industria, y el salario entre ellos varía de forma considerable. Así que antes que nada comencemos desglosando los salarios de acuerdo al principal rol que desempeñan las personas. Esto se muestra en la tabla 2.

Tabla 2. Salario por rol.

Cada participante podía escoger un máximo de tres roles, es por eso que la suma de las muestras es mayor al número de participantes (1,550). Como es de esperarse, los roles de dirección y venta son los que perciben los salarios más altos, mientras que quienes se dedican al soporte técnico perciben los salarios más bajos. Los roles con mayor participación son los de programación, análisis de requerimientos, project management y arquitectura. Vale la pena aclarar que el rol de arquitectura considera también a quienes hacen diseño lógico de programas o componentes individuales, solo que no le llamamos “diseñador” para que no se confunda con diseño gráfico ni UX.

Tabla 1. Estadísticas descriptivas del salario.

www.sg.com.mx |

Es así que de acuerdo a los datos recopilados este año, el salario medio de un profesionista de software en nuestra región es de $26,000 pesos brutos mensuales (para los aferrados que de todos modos quieran conocer el promedio, éste es de $30,986.98). La tabla 1 muestra los principales datos estadísticos para el salario. El cuartil 1 indica la marca de 25%. Es decir, que 25% de las personas gana abajo de $16,000 pesos. El Q2 es 50%, es decir la mediana, y el Q3 es 75%. Así que según estos datos 75% de los profesionistas de software en México gana menos de $38,750 pesos de salario bruto mensual. Comparando estos datos con los de 2013, donde obtuvimos una mediana de $22,000 y media de $26,310, podemos entonces deducir que los salarios de los profesionistas de software en México aumentaron alrededor de un 15% durante 2014. Además del salario bruto mensual, los participantes también indican si reciben una compensación extra tal como bonos de desempeño, aguinaldo u otras prestaciones económicas. En este caso, la mediana reportada es de $20,000 pesos anuales de compensaciones extra y el promedio es de $51,000 pesos. Esta disparidad nos hace ver que mientras un gran número de personas reciben a fin de año su aguinaldo de una quincena, hay quienes reciben bonos y paquetes de compensación por varios cientos de miles de pesos. Sin duda, el salario mensual no lo es todo.

Software Guru

A LOS NÚMEROS

.ESTUDIO DE SALARIOS SG 2014

Tabla 3. Salario por entidad federativa (México).

GEOGRAFÍA La tabla 3 muestra el desglose de acuerdo al estado de la República Mexicana donde radican los participantes. Solo se muestran aquellos estados de donde obtuvimos 15 o más respuestas. Desde la edición número uno del presente estudio, el Distrito Federal y Nuevo León se pelean la posición del primer lugar. En años anteriores nos había extrañado que Jalisco no quedara más arriba (en 2013 apareció en sexto lugar), pero esta ocasión ya aparece en terce- Tabla 4. Tipo de empresa. ro cercano. Sinaloa, al igual que en 2013 aparece como el estado con salarios más bajos para profesionistas de software. Nos extraña un poco ya que se han abierto centros de desarrollo de software en los últimos años en esta región, y al parecer los salarios no se han visto favorecidos con ello.

TIPO DE EMPRESA Y ESQUEMA La tabla 4 muestra la descomposición de los participantes de acuerdo al tipo de organización en la que laboran. Al igual que hace un año, las startups son las que reportan los mejores salarios brutos. Tal parece que esta es una particularidad en nuestra región, donde los empleados

de startups sen enfocan más en el salario que en tener participación de la propiedad. En el caso de empresas de outsourcing vs. áreas usuarias, las primeras tienen una mediana más alta, pero las segundas tienen un promedio mayor. Suponemos que es porque en las áreas usuarias típicamente hay más niveles jerárquicos que en las empresas de outsourcing, las cuales buscan tener estructuras más horizontales. Por otro lado, la tabla 5 muestra los esquemas de compensación más populares entre los participantes. Aunque la mayoría (66%) continúa en un esquema de nómina, el esquema mixto o híbrido (una parte en nómina y otra en honorarios) cada vez es más utilizado.

PG. 19

Tabla 5. Compensación mensual por esquema.

¿CÓMO VAMOS CON LA IGUALDAD DE GÉNERO? La tabla 6 muestra un desglose de salario en base al género. Aunque los números siguen reflejando una alta proporción de hombres y una diferencia significativa en salario (las mujeres perciben 22% menos), la buena nota es que estos números son mejores que los obtenidos en años anteriores, donde típicamente teníamos una relación de 84/16 y una diferencia de salario de 30%. Habrá que poner atención en este dato para el próximo año y ver si continúa la tendencia.

Tabla 7. Salario por lenguaje.

Sabemos que entre la información que genera mayor interés (y morbo) de este estudio cada año es la descomposición de salarios de acuerdo a las tecnologías utilizadas. La tabla 7 presenta la lista de salarios de acuerdo a lenguajes de programación. Aunque la encuesta tenía muchas otras opciones de lenguajes (Lua, Swift, Scala, etc.) solo dejamos los que tuvieron más de 15 respuestas. Es importante notar que únicamente las personas que indicaron “programación” entre sus actividades actuales tuvieron la opción de escoger lenguajes. Esto evita que personas que programaban hace muchos años y hoy en día son gerentes o directivos con altos salarios, afecten las estadísticas. Otra aclaración pertinente es que sabemos que Node no es un lenguaje de programación (en realidad es javascript), pero consideramos adecuado ponerlo por separado. Tal como sucedió en 2013, Objective C se mantiene como el lenguaje mejor pagado, derivado de la alta demanda que hay de desarrollo móvil, y la escasez de personas que dominen este lenguaje. Apple lanzó Swift este año (que de hecho era opción en la encuesta pero muy pocos participantes lo marcaron), así que veremos que pasa para 2015. Otro aspecto interesante de esta tabla es que la desviación estándar refleja qué tan “hipster” es cada lenguaje. Mientras que lenguajes principalmente usados en apps departamentales como VB, Delphi o C# tienen baja desviación, lenguajes como Objective C, Node, Ruby y Python tienen desviaciones estándar altas. La tabla 8 lista las plataformas para las que los participantes han desarrollado o mantenido aplicaciones durante el último par de años.

Tabla 8. Salario por plataforma.

La tabla 9 lista algunas de las certificaciones más populares en nuestra industria, y los salarios correspondientes. Como podemos ver, las certificaciones relacionadas con cuestiones más “cerca del negocio” son mejor pagadas que las certificaciones técnicas.

www.sg.com.mx |

HABILIDADES Y CONOCIMIENTOS

Llama la atención que en los primeros lugares tenemos a dos plataformas que son polos opuestos. Por un lado tenemos al mainframe, ícono del cómputo centralizado de alto desempeño; sabemos que se paga bien porque son sistemas de misión crítica en sectores como financiero, telecomunicaciones, retail y gobierno. En contraste, tenemos la plataforma de Internet de las Cosas (IoT), altamente novedosa y optimizada para dispositivos con bajo poder de cómputo. También es curioso ver que web, que era la plataforma “novedosa” hace 15 años, hoy es la más común y con los salarios menores. Otro dato interesante que arroja esta tabla que hay más trabajo para Android, aunque iOS es mejor pagado.

Software Guru

Tabla 6. Salario por género.

.ESTUDIO DE SALARIOS SG 2014

Tabla 11. Salario por nivel de inglés.

Tabla 9. Salario por certificación.

Estos datos nos dan oportunidad de hacer una estimación a grandes rasgos del valor económico de una certificación. La tabla 9 nos dice que participaron 172 programadores Java certificados con un salario medio de $31,000. De la tabla 7 obtenemos 321 programadores Java (certificados y no certificados) con un salario medio de $25,000. En base al tamaño de las muestras, podríamos estimar que el salario medio de un programador Java no certificado ronda los 20 mil pesos, lo cual indica una diferencia de alrededor de 10 mil pesos contra un programador Java certificado. Otro factor ampliamente debatido es qué tanto impacto tienen los estudios universitarios en el salario. La tabla 10 nos da un poco de luz sobre este tema.

Tabla 10. Salario por nivel de estudios.

Tal parece que lo más rentable es realizar estudios de posgrado (ej. diplomados) y maestrías. Adicionalmente, tal parece que la industria en México no aprecia (o no tiene necesidad) de personas con estudios de doctorado. Otro dato interesante es que al parecer quienes cuentan con estudios técnicos perciben mayores ingresos que los universitarios sin titular.

PG. 21

Para terminar, revisemos la tabla 11 que nos muestra el desglose de acuerdo al nivel de inglés. Ya sabemos que en nuestra industria este es un factor con gran impacto en el desarrollo profesional, así que no es sorpresa ver que el nivel de inglés tiene una clara correspondencia con mejores salarios. En todo caso lo que habría que estudiar es si a través de los años estamos mejorando el nivel de inglés de nuestros profesionistas. Los resultados de 2013 arrojaron que 21.3% de los participantes tenía un nivel de principante y 21.4% avanzado. Así que parecería que poco a poco estamos mejorando en este aspecto.

SATISFACCIÓN La buena noticia es que a pesar de nuestras quejas, parece ser que la mayoría de los profesionistas de software está contento con su trabajo actual. La tabla 12 muestra este índice.

Tabla 12. Satisfacción con empleo actual.

www.sg.com.mx |

Software Guru

Por otro lado, la tabla 13 nos muestra cuales serían las principales razones por las que los participantes cambiarían de empleo.

Tabla 13. Razones para cambiar de empleo.

CONCLUSIÓN Y ACCESO A DATOS Agradecemos a todas las empresas y personas que nos ayudaron con sus respuestas, así como a los organismos que nos apoyaron en la difusión; especialmente IJALTI, CSoft, AMITI, CANIETI y Prosoftware. Más aún, agradecemos a Softtek, Mexico FIRST, Kelly Services México y Dawcons, quienes patrocinaron la realización de la encuesta. Los datos con los que se generó el presente estudio están disponibles para consulta. Puedes accederlos a través de los siguientes enlaces. Cuestionario utilizado: http://swgu.ru/salarios2014-estructura Datos en Fusion Tables: http://swgu.ru/salarios2014-datos Video explicativo de cómo interactuar con Fusion Tables: http://swgu.ru/salarios2014-video

.ESTUDIO DE SALARIOS SG 2014

MEJORES EMPRESAS

para trabajar

AL IGUAL QUE EN LA EDICIÓN ANTERIOR DEL ESTUDIO DE SALARIOS SG, HEMOS APROVECHADO ESTA OPORTUNIDAD PARA DETECTAR CUÁLES SON LAS EMPRESAS CUYOS EMPLEADOS SE SIENTEN MÁS SATISFECHOS. EN OTRAS PALABRAS, CUÁLES SON LAS MEJORES EMPRESAS PARA TRABAJAR EN TI EN NUESTRA REGIÓN.

METODOLOGÍA Los participantes en la encuesta tuvieron la opción de indicar el nombre y url (para identificarla más fácilmente) de la empresa donde laboran, y llenaron una matriz donde indicaron su nivel de satisfacción con la empresa donde actualmente laboran. La satisfacción considera los siguientes rubros: • El trabajo que realizo provee un reto intelectual que me ayuda a crecer profesionalmente. • Trabajo con gente muy capaz y eso contribuye a mi aprendizaje. • La empresa ofrece facilidades para tomar capacitación/entrenamiento. • La empresa ofrece facilidades para participar en eventos de la industria. • Sé hacia donde voy con esta empresa, confío en que puedo crecer mucho en ella. • Mi trabajo me ayuda a vincularme con personas fuera de mi empresa. • Cuento con el equipo y herramientas (hardware y software) adecuado para realizar mi trabajo. • La empresa tiene finanzas estables y paga puntualmente. • Me agrada mi estación e inmobiliario de trabajo (oficina, escritorio, silla, etcétera). • Estoy satisfecho(a) con la ubicación donde se encuentra la empresa/oficina. • Me gustan las opciones que tengo para comer. • Estoy satisfecho(a) con el horario de trabajo (o flexibilidad de horario) • Me siento valorado(a) por mis superiores. • Laborar en esta empresa me facilita estar saludable. La calificación en cada uno de estos factores se promedió para generar una calificación global por cada participante. A su vez, las calificaciones globales de los distintos participantes de una empresa se promediaron

para obtener el puntaje de la empresa. Solamente tomamos en cuenta a empresas de donde obtuvimos un mínimo de 5 participantes distintos.

GANADORES Presentamos entonces la lista de las 20 mejores empresas para trabajar de acuerdo a los participantes en la encuesta de salarios SG 2014.

La lista está ordenada de acuerdo a la calificación obtenida (es decir que la empresa en 1er lugar tuvo la mejor evaluación por parte de sus empleados).

Felicitamos a estas empresas y nos quitamos el sombrero ante ellas. A varias las conocemos de cerca, y sabemos que trabajan mucho en brindar las mejores condiciones posibles a sus colaboradores. Reconocemos especialmente a aquellas empresas que repiten de la lista de ganadores del 2013. Estas son: Crowd Interactive, Oracle, Globant, InnovaWeb, Scio Consulting, Tiempo Development, HP, IDS Comercial, BBVA Bancomer y Softtek. Dado que la gran mayoría de los participantes en la encuesta radican en México, casi todas las empresas listadas son de México o se refieren a su subsidiaria en México. Al igual que en 2013, la excepción es Globant, que aunque ha aumentado su presencia en México, la mayoría de los participantes que la evaluaron para esta encuesta indicaron radicar en Argentina y Colombia. Recalcamos que dada la metodología utilizada, esta no es una lista exhaustiva de empresas de la industria. Es decir, el hecho de que una empresa no aparezca en la lista no necesariamente es porque no haya sido bien calificada, sino que también puede ser porque no hubo suficientes respuestas de parte de empleados de esta empresa, como para ser considerada. Invitamos a todas las empresas que quieran aparecer en este ranking el próximo año a que se ocupen en mejorar la satisfacción de sus empleados y en noviembre de 2015 se aseguren de invitarlos a que contesten el estudio de salarios de SG.

PG. 23

AGRADECIMIENTOS http://www.kellyservices.com.mx

http://www.softtek.com

http://www.dawcons.com

Los resultados obtenidos en la encuesta de SG son muy consistentes con los obtenidos en los monitoreos de MexicoFIRST. En cuanto a los niveles de sueldo por certificación podemos notar que hay muchísimos cambios respecto al año pasado, lo que demuestra el dinamismo de la industria y el interés por Administración de Proyectos y Arquitectura Empresarial que nos han expresado las empresas que piensan obtener certificaciones de clase mundial. MexicoFIRST está igualmente apoyando para el mejoramiento del idioma inglés, ya que no solo es necesario para apuntalar la posición de México como destino preferido para Offshoring sino que adicionalmente beneficia a las personas al habilitarlas para mejorar sus niveles de percepciones.

Pudimos observar que 2014 fue un año difícil para la industria de TI, pues se mostró un freno en las inversiones como efecto a la Reforma al Sector de Telecomunicaciones. Kelly Services, líder mundial que ofrece Soluciones Integrales en Recursos Humanos, reconoce la importancia de la industria de TI en México. Nuestra experiencia y servicio nos permite desarrollar al talento ideal en las empresas con el fin de optimizar a la industria. Es nuestro compromiso contar con los mejores especialistas en la búsqueda del talento para acercarlo a las mejores compañías, con el objetivo de traer mayor eficiencia y productividad en sus procesos, para que, tanto para las empresas como el talento mexicano se desarrolle con éxito. En Kelly Services estamos seguros que este año 2015 será de gran crecimiento y proyección para esta industria, ya que, se están vislumbrando inversiones que permitirán la modernización de infraestructura, siendo uno de los impulsores de la industria de TI en México el desarrollo del cómputo en la nube, donde se espera un crecimiento acumulado en cinco años aproximado de 52%.

Hoy somos testigos de la evolución de las empresas hacia el mundo digital: sus procesos, sus productos, sus servicios se encuentran basados cada vez más en algún software; lo mismo sucede con el contacto a clientes a través de medios digitales, de tal manera que la tecnología se está convirtiendo en la empresa misma. Ante este escenario, el valor de las personas que crean y ayudan a evolucionar las TI ha ido en ascenso. En Softtek estamos conscientes de esto, trabajamos para impulsar a nuestros colaboradores, acelerar su desarrollo y prepararlos para acompañar a nuestros clientes en esta etapa de transformación.

En Dawcons sabemos que para poder dar lo mejor a nuestros clientes, debemos basar nuestra estrategia en la formación humana y tecnológica de cada una de las personas que colaboran con nosotros. Es por eso que en Dawcons, además de contar con un equipo directivo con más de 20 años de experiencia en las Tecnologías de la Información, buscamos rodearnos de personas expertas en su área que aspiren a la mejora continua, proporcionándoles un plan de desarrollo profesional en la empresa. Si estás en busca de una oportunidad laboral y te apasiona el desarrollo tecnológico, envíanos tu información para que te desenvuelvas y crezcas junto a Dawcons.

Juan A. Saldívar Director de Promoción de Capital Humano, MexicoFIRST

Monserrat Mendoza Marketing Coordinator, Kelly Services Mexico

Gilberto Romero Director de Marketing México, Softtek

Jorge Valadez Director Comercial y de Marketing, Dawcons

www.sg.com.mx |

http://www.mexico-first.org

Software Guru

AGRADECEMOS EL PATROCINIO DE LAS SIGUIENTES EMPRESAS QUE CONTRIBUYERON A HACER POSIBLE EL ESTUDIO DE SALARIOS SG 2014.

.PORTADA

¿DÓNDE ESTÁ EL

TALENTO? POR ERICK CAMACHO

Nota del editor: El presente artículo fue originalmente publicado por Erick en su blog y lo hemos retomado con su permiso para publicarlo en esta edición de SG.

EN CUALQUIER CHARLA CON PERSONAS DEL MEDIO DE TI, TARDE O TEMPRANO SALDRÁ EL TEMA DE LO COMPLICADO QUE ES ENCONTRAR “RECURSOS COMPETENTES” EN EL ÁREA DE DESARROLLO. EN OTRAS PALABRAS, ES DIFÍCIL ENCONTRAR PROGRAMADORES BUENOS, LO QUE NO QUIERE DECIR QUE NO EXISTAN. EN MÉXICO EL TALENTO NO ESCASEA. HAY MUY BUENOS PROGRAMADORES Y, A DIFERENCIA DE OTRAS PROFESIONES, NO SOLEMOS BUSCAR SALIR AL EXTRANJERO. ASÍ QUE EN TEORÍA HAY UNA BUENA BASE CON CUAL TRABAJAR. ¿Pero dónde están esas perlas? Pues primero empezaré por decir donde no están: buscando trabajo. Seamos sinceros, los buenos programadores están, pues, programando. Dado que hay mucha demanda, seguro están ganando buen dinero y/o en un empleo que les satisface. Así que aquí va la primera mala noticia para los reclutadores: no van a leer tu anuncio en la bolsa de empleo. De hecho, si han aprendido como yo, a la mala, ni por curiosidad mirarán las ofertas de esas bolsas.

No importa cuantos anuncios con un “Urge” pongan, de esa forma no lograrán atraerlos. No importa cuantos mails pidiendo CVs envíen, tampoco lo lograrán. Esas técnicas de spam sirven para conseguir otro tipo de profesionistas pero a los programadores no les atraen. Si no están buscando trabajo, no les importa que a ti te urja un desarrollador, o que necesites que llenen un CV con el formato de tu empresa para facilitarte el trabajo. Así que de entrada, hay que esforzarse más para conseguir a un buen programador.

.BIO Erick Camacho es CTO en Nubleer Media. Cuenta con amplia experiencia en la arquitectura de aplicaciones JEE así como el desarrollo de aplicaciones nativas para iOS. Erick es Maestro en Tecnologías de la Información con especialidad en Ingeniería de Software por la Universitat Politècnica de Catalunya.

¿Dónde sí están? Los buenos programadores están … con otros programadores. A continuación doy algunos ejemplos.

que aportar algo y dejar ver que te interesa el talento para que te hagan caso. Software Guru también tiene iniciativas similares.

EN REUNIONES DE PROGRAMADORES

EN PROYECTOS OPEN SOURCE

Las reuniones de programadores reúnen a gente con intereses similares para hablar de temas en torno a la programación. Una constante que he observado en reuniones en varias partes del mundo es que la gente que suele asistir a ellas son de muy buen nivel. Esto resulta obvio, cuando te das cuenta que estás hablando de gente que trabaja al menos 8 horas diarias programando y aún así se reúne después del trabajo o en fines de semana para hablar sobre cómo programar. Así que debe de encantarle lo que hace (otra opción es que lo dejó la novia y no tenía nada que hacer) y si te encanta lo que haces, sueles volverte bueno en ello. Así que asiste a estas reuniones, pero sin tu playera de reclutador. Asiste como participante, habla con ellos, conócelos. Nosotros desconfiamos de quien llega a ofrecer empleo sin más. Hay varias estrategias que funcionan, como por ejemplo patrocinar las cervezas o llevar libros para rifar. Eso derribará la primer barrera y podrás hablar sobre lo que necesitas. Es más, si puedes llevar a programadores de tu empresa a exponer cosas técnicas, mucho mejor. De esta forma estás demostrando que en tu empresa valoran el talento y fomentan que su personal se vincule con otros colegas.

Muy parecido al caso anterior pero aún más extremo. Cuando un programador colabora a un proyecto open source, no sólo es su opinión o conocimiento el que se pone a prueba, es su posesión más valiosa: su código. Está exponiendo el producto de su talento, de una forma tal que no caben ni comentarios, ni poses. Así que aquellos que colaboran con estos proyectos, por el simple hecho de hacerlo, han mejorado su nivel de programación. Estos proyectos open source son una gran ventana al pool de talento. Así que una buena opción es mirar en los sitios de repositorios de código como github y bitbucket que han indexado todos esos proyectos y te dan acceso a los datos agregados de los mismos. ¿Cómo contactas a programadores en estos proyectos? La opción más viable es que si necesitas gente que conozca de cierta tecnología, digamos una librería, pues contacta a los responsables de esa librería. La mayoría de los colaboradores open source lo hacen por necesidad (está usando ese proyecto) o por gusto. Así que si les ofreces un trabajo donde parte del trabajo será seguir manteniendo y creciendo su proyecto open source, lo ven con buenos ojos. Alguien les pagará por algo que están haciendo de a gratis.

EN FOROS DE PROGRAMACIÓN ¿Conoces javamexico, javahispano, stackoverflow, programming reddit, etc? Estos sitios están llenos de buenos programadores ayudando y colaborando entre sí. Las comunidades juegan un importante rol en la vida de un programador, quienes las mantienen con sus contribuciones en forma de artículos, respuestas a preguntas de foros, son gente de buen nivel. ¿Por qué? Porque lo que escribas ahí estará bajo el escrutinio de miles de programadores. Así que o tiene sentido lo que pones o te comen vivo a la primera tontería que digas, este miedo a la humillación pública resulta un importante filtro de talento en estas comunidades. Estos lugares sirven para detectar a gente buena, pero no tanto para hablar con ellos. No hay nada peor que un anuncio de “URGE desarrollador .NET” en un foro de programación, es ponerte la soga al cuello. En javaHispano en cambio, hemos colaborado con empresas a llegar a los programadores de la comunidad de forma más amigable. Por ejemplo, haciendo concursos de programación (la JavaCup) donde se dan premios en efectivo patrocinados por empresas que quieren contactar al talento habitual en esa comunidad. Así que va la misma lección: tienes

ENCERRADOS EN EL PISO MÁS ESCONDIDO DE LAS GRANDES EMPRESAS

No todos los buenos programadores asisten a las reuniones, ni van a congresos, ni colaboran con proyectos open source. Muchos están muy ocupados sacando la nueva versión del sistema core de un Banco o programando la última versión de un sistema CAD 3D para una empresa extranjera. Estos son los más difíciles de detectar porque no salen al sol muchas veces. Para estos casos, lo más fácil es asumir que detrás de todo buen sistema hay programadores buenos e intentar detectarlos. Siempre que veo algo bien hecho, desde un sitio de un banco estable y funcional, hasta un producto de mesa de regalos en una tienda departamental que funciona bien; asumo que hay un buen programar detrás. Pregunta por ellos, ¿quién creó el menú para cambiar de sección en el módulo de edición impresa en la aplicación de iPhone del periódico Reforma? ¿Quién diseñó el sistema de SPEI que procesa millones de transacciones al día? A esos son a los que quiero conocer. Así que no pongas anuncios en bolsas de empleo, no pongas un anuncio en un foro con la palabra URGE (así en mayúsculas). A los buenos programadores no les importa eso. Dedícate a detectarlos, a hablar con ellos. Una vez hecho esto, no todo está servido. Falta convencerlos de que dejen a su actual empresa, falta corroborar que estos programadores puedan desempeñar un buen papel en tu equipo, falta ver si realmente tendrán el nivel necesario. Lo que estoy tratando de decir es que si quieres encontrar al talento, te tiene que importar el talento. No les faltes al respeto con spam enviando un formulario para que te lo llenen, o con llamadas al celular para pedirle su sueldo actual (los dos casos me ha pasado). Primero tienes que participar en su mundo y demostrar que te interesa, de esa forma te aceptarán una charla sobre un posible empleo.

Software Guru

PATROCINAR UN CONGRESO ES MUY BIEN VISTO POR LOS PROGRAMADORES.

Caso similar al arriba citado, pero con una gran diferencia. Los congresos cuestan, ya sea simplemente la entrada, ya sea faltar unos días al trabajo o desplazarte hasta ellos. En países como México, las empresas no le pagan eso a los empleados; así que normalmente verás que los programadores de su propia bolsa se pagan todo el show y hasta pierden días de vacaciones para asistir. Si tienes presencia en un congreso como patrocinador, esto es muy bien visto por los programadores. Nos damos cuenta que tienes un interés por este tipo de eventos y que a lo mejor no amenazas con despedir a tus empleados si asisten a ellos (lo que en países latinos ya es ganancia).

www.sg.com.mx |

EN CONGRESOS

.PORTADA

INCLUYAMOS A LAS

MUJERES POR RAQUEL HERNÁNDEZ

DURANTE LOS 10 AÑOS QUE LLEVO TRABAJANDO COMO INGENIERO DE SOFTWARE EN MÉXICO Y ESTADOS UNIDOS, UN COMÚN DENOMINADOR EN LOS PROYECTOS EN QUE HE PARTICIPADO ES QUE SOY LA ÚNICA MUJER EN EL EQUIPO DE DESARROLLO. MUCHAS EMPRESAS NO SE DAN CUENTA DE LO IMPORTANTE QUE ES TENER UN EQUIPO DE TRABAJO INCLUYENTE, ESPECIALMENTE CUANDO SE ESTÁN CREANDO PRODUCTOS QUE SERÁN UTILIZADOS POR UNA GRAN DIVERSIDAD DE PERSONAS. LAS EMPRESAS DEBEN BUSCAR QUE SU EQUIPO REFLEJE LAS DISTINTAS FORMAS DE PENSAR DE SUS CONSUMIDORES, SOBRE TODO SE DEBE CREAR UN AMBIENTE LABORAL DONDE TODAS LAS IDEAS SE ESCUCHEN, VALOREN Y SE TOMEN EN CONSIDERACIÓN. TENER MUJERES EN EL EQUIPO DE TRABAJO, NO ES SOLO NECESARIO POR EQUIDAD DE GÉNERO, SINO QUE ES FUNDAMENTAL CUANDO SE DESEAN GENERAR LAS MEJORES IDEAS Y QUE SE REFLEJEN EN LA CALIDAD DE LOS PRODUCTOS QUE LAS EMPRESAS PRODUCEN. 26

.BIO Raquel Hernández es co-fundadora y Co-CTO de Glimpse, una aplicación móvil de citas que conecta usuarios de Instagram. Es Licenciada en Matemáticas Aplicadas y Computación por la UNAM. Desde 2007 radica en Nueva York, donde ha tenido un rol integral en el desarrollo de diferentes startups y empresas de gran escala.

Software Guru

cionar este problema. Lo mejor es empezar lo más temprano posible, algunas empresas no se preocupan de la equidad de género hasta que ya es demasiado tarde. Es mucho más difícil que una mujer se una a un equipo de 20 hombres que a un equipo de menos de 10 personas. Otro de los grandes errores de muchas empresas es que cuando crean sus ofertas de trabajo, incluyen palabras como “rockstar”, “ninja”, “jedi”, etc., que son términos muy comunes en la cultura geek, pero que son términos que excluyen totalmente a las mujeres. El uso de estos términos puede implicar que se tiene la expectativa de un nivel de experiencia muy alta. Hay un gran número de programadoras muy talentosas, que no se sienten con la confianza necesaria en sus habilidades, aunque tengan la capacidad requerida. Y el solo uso de esta terminología está causando que tal vez una excelente candidata desista. Otro error común es incluir prestaciones que son totalmente orientadas para atraer talento masculino, como pueden ser “full bar”, “cerveza y pizza todas las noches”, “mesa de billar”, etc. Este tipo de incentivos hacen parecer a la empresa como si tuviera una cultura de “club de Toby”. Empresas como Google que se caracterizan por ofrecer los más ridículos incentivos a sus empleados, además de “full bar”, también ofrecen “servicio de guardería”, “gimnasio”, “masajes”, “yoga”, entre otros; prestaciones mucho más atractivas para cualquier género. Es muy recomendable que cuando se inicie el proceso de reclutamiento, alguna mujer del equipo participe en las entrevistas. Es intimidante ser entrevistada sólo por hombres, y más si se tiene que entrevistar con un grupo grande de personas. El tener diversidad en el primer contacto con los candidatos y candidatas, muestra a la empresa diversa e incluyente, y los aspirantes tienden a relajarse y mostrarse más seguros de sí mismos. A pesar de la gran disparidad, es un gran momento para las mujeres de trabajar en el mundo de la tecnología porque está evolucionando constantemente, haciéndolo mucho más interesante y divertido. Un gran beneficio de trabajar en este rubro es que puedes aplicar tus conocimientos en industrias que te apasionen. Por ejemplo si tu gran pasión es la moda, música, cine, bienes raíces, salud, entre muchas otras industrias, hay un gran campo laboral en todas ellas. Otra de las grandes ventajas de trabajar en empresas tecnológicas es que hay una gran oportunidad de crecimiento laboral, compañías que empiezan desde cero el día de hoy, el día de mañana se pueden transformar en grandes empresas. La alta demanda de programadores también ha beneficiado para que los salarios se hayan disparado; en la actualidad desarrolladores de aplicaciones móviles pueden ganar más de lo que ganaba un CEO de una empresa hace 10 años, por ejemplo. Y la demanda laboral seguirá creciendo en el futuro inmediato. El departamento de trabajo de Estados Unidos calcula que para el año 2020 habrá más de 1.4 millones de trabajos relacionados con el campo de tecnologías de la información, pero al paso que vamos, solo se podrán cubrir un 30% de estos puestos con universitarios estadounidenses. Lo que abre la puerta a talento de muchos países, incluyendo México.

www.sg.com.mx |

Desafortunadamente, encontrar este balance de género no es una tarea nada sencilla, porque es muy difícil encontrar talento femenino. El mundo de la tecnología puede ser un ambiente hostil para las mujeres por cuestiones culturales, machismo y sobre todo porque es un terreno totalmente dominado por hombres. Esto causa que muchas mujeres se sientan inseguras ya que para poder sobresalir se tiene que esforzar aún más, y muchas veces por la misma condición de ser mujer no se valora su trabajo o sus conocimientos como se hace con un hombre. De ahí que la mayoría de las mujeres en esta industria sufran del “síndrome del impostor”, que les provoca tener expectativas demasiado altas respecto a ellas mismas y baja autoestima. Se ha comprobado que las mujeres ganan menos que los hombres en esta industria, solo por el simple hecho de que fallan al negociar por la falta de confianza en sí mismas. También las mujeres suelen ser bastante cautelosas cuando se trata de cambiar de empleo —especialmente si se han tenido malas experiencias en el proceso de reclutamiento— y un buen número toma mucho tiempo para decidirse a cambiar de empleo y buscar mejores oportunidades. El problema con el proceso de reclutamiento, es que varias de las entrevistas técnicas están diseñadas para probar de una forma muy rápida qué tan “inteligente” es el candidato o candidata. Este tipo de entrevistas, casi siempre hacen fallar a las mujeres. El no poder programar un algoritmo que nunca se utiliza en la vida profesional en 15 minutos sin consultar en Internet, no significa que el candidato no es apto para el puesto. La inclusión de las mujeres se está convirtiendo en un tema muy importante y cada vez vemos más iniciativas que buscan tener una fuerza laboral diversificada. Algunas empresas están verdaderamente preocupadas por la falta de mujeres en sus equipos de desarrollo. Etsy es un gran ejemplo, ellos se han dado a la tarea de contratar diversidad, particularmente diversidad de género. 80% de los usuarios de Etsy son mujeres, lo que demuestra que la inclusión debe ser una prioridad, además, una de las iniciativas que lanzaron es un programa de becas para mujeres ingenieras. Este programa fue muy exitoso para ellos y lograron incrementar 500% el número de mujeres ingenieras en su equipo. Google también ha realizado esfuerzos en el tema de inclusión y ha creado una gran iniciativa llamada “Made with Code” que trata de reducir la disparidad de género, esta iniciativa destinará 50 millones de dólares a incrementar el número de mujeres programadoras en los próximos tres años. Google confía en que ésta iniciativa ayudará a que más adolescentes y mujeres jóvenes se interesen por el campo de la programación y desarrollo de tecnologías. También las mujeres desarrolladoras se han organizado en grupos y se apoyan mutuamente. Un ejemplo es DevChix, un grupo super diverso de mujeres programadoras de todos los niveles de experiencia, en donde se puede hablar libremente de todo tipo de temas técnicos, se ofrecen tutorías y cuentan con bolsa de trabajo. En México ya también se están formando grupos como estos, un ejemplo es @CodificadasMx. Muchas empresas que están interesadas en contratar mujeres desarrolladoras no tienen éxito, y a veces se preguntan cómo pueden solu-

.PORTADA

EL CÓMPUTO CON ROSTRO FEMENINO POR FABIOLA CALDERÓN

LA COMPUTACIÓN QUE SE HACE HOY EN DÍA DISTA MUCHO DE LA MANERA EN QUE SE HACÍA EN LA DÉCADA DE LOS 90, CUANDO REALICÉ MIS ESTUDIOS UNIVERSITARIOS EN ESTE CAMPO. LA ESTRUCTURA ORGANIZACIONAL DE LAS EMPRESAS Y DE LOS EQUIPOS DE TRABAJO HA IDO EVOLUCIONANDO CONFORME A LA NECESIDAD DE MEJORAR LOS PROCESOS COMPUTACIONALES. Pero lo que no ha cambiado es la ausencia de las mujeres en dicho campo del conocimiento. Quisiera enfocar este artículo en reflexionar sobre qué podemos hacer para acercar a las mujeres a las carreras profesionales relacionadas al cómputo. Cuando fui profesora de bachillerato en la preparatoria No. 6 “Antonio Caso” de la UNAM, tuve a mi alcance la oportunidad de conocer los intereses de las adolescentes. A muchas de ellas les motivaba ser económicamente independientes, tener una carrera profesional exitosa, contar con una vida personal satisfactoria y ser estables. La materia que impartía entonces era Opción Técnica en Computación; tenía una duración de dos años y los alumnos del quinto grado la cursaban de manera opcional, egresando del bachillerato con un extra que les abría la puerta laboral, les permitía recabar información valiosa en cuanto a su vocación profesional y, si decidían ingresar a alguna licenciatura en el ramo del cómputo, se integraban a ella con conocimientos sólidos en el tema. Más de una de las alumnas egresadas de la Opción Técnica en Computación decidía estudiar alguna de las carreras alusivas que la UNAM ofrece, pues en su paso por la materia, descubría el gusto por la computación o detectaba habilidades para estudiar una carrera de ese tipo. La labor educativa de la opción técnica se respaldaba con la realización de diversas actividades organizadas por los profesores que formábamos parte de la planta docente; como los concursos de programación que eran espacios donde tanto hombres como mujeres ponían a prueba los conocimientos adquiridos hasta el momento, además representaba la oportunidad de interactuar con jóvenes cuyos intereses eran similares. Por lo regular, las adolescentes se mostraban entusiastas y comprometidas al participar en las actividades relacionadas a los concursos de programación, poniendo el esfuerzo y tiempo necesarios para hacer un buen papel. Entonces, si existe el talento en las mujeres para ejercer la computación, ¿por qué no hay un mayor número de ellas incursionando en este campo? ¿Qué les puede brindar el ejercicio de esta profesión? Además de independencia económica: • La oportunidad de trabajar en casi cualquier sector laboral en el país y en el extranjero. • La conquista de diversos retos profesionales, cuya velocidad y sentido quedan pautados por el ritmo en el avance y el crecimiento de la tecnología. • Empleos bien remunerados. • Calidad de vida y cumplimiento de metas personales al alcance de sus bolsillos.

Siendo testigo de la labor vocacional que ejercía la Opción Técnica en Computación, considero indispensable llevar a cabo acciones cuyo objetivo sea proponerle a la mujeres ingresar al mundo de la computación y despertar en ellas el interés por esta emocionante actividad. Tales acciones podrían ser: • Aprovechar diversos foros para brindar conferencias dirigidas a las adolescentes y, en general, a las mujeres interesadas en la tecnología y en la computación. • Invitar a mujeres exitosas en el tema para que hablen o escriban sobre su decisión de estudiar y ejercer alguna carrera en cómputo, de tal forma que sus historias muestren que la computación es un camino lleno de retos y satisfacciones y que puede representar una forma de vida accesible a cualquier mujer. • Aprovechar espacios como ferias de libros, ferias sobre tecnología, hackatones, encuentros, ciclos de conferencias y exposiciones fotográficas en las diversas escuelas secundarias y bachilleratos. • Diseñar cursos de programación enfocados a este sector de la sociedad. • Trabajar en conjunto con el gobierno local de cada entidad y con el gobierno federal para diseñar acciones y programas que beneficien al mayor número de niñas, adolescentes y mujeres en general que pudieran encontrar en la computación el desarrollo y el aprovechamiento de sus habilidades y talentos. ¿Qué pasaría si, así como hay campañas de alfabetización hubiera también campañas para la enseñanza del cómputo? Estoy segura que más de una mujer respondería al llamado. Cada acción debe realizarse bajo la perspectiva de sensibilizar a la sociedad sobre el papel que la mujer debe interpretar hoy en día en la sociedad, para percibirse como un agente de cambio, como parte fundamental en el desarrollo económico del país y del mundo. De acuerdo a los Objetivos de Desarrollo del Milenio que conforman el Proyecto del Milenio de las Naciones Unidas [1], dar a las mujeres más espacios y oportunidades de desarrollo no sólo representa un beneficio para el género, sino también para la sociedad en general.

Referencias [1] “Objetivos de Desarrollo del Milenio y Más allá de 2015”. Organización de las Naciones Unidas. http://www.un.org/es/millenniumgoals/gender.shtml

.BIO Fabiola Calderón cuenta con 20 años de experiencia profesional en la industria de software. Actualmente es desarrolladora independiente especializada en aplicaciones web y móviles, y cursa la Maestría en Ciencia e Ingeniería de la Computación, en el Instituto de Investigaciones en Matemáticas y Sistemas (IIMAS) de la UNAM.

PREGUNTAS QUE DEBES HACERTE

ANTES DE ACEPTAR UN TRABAJO (EN UN STARTUP) POR JEDUAN CORNEJO Nota del editor: El presente artículo es una versión editada de la nota “Preguntas que un ingeniero de software debería de hacer antes de aceptar un trabajo (en un startup)” publicada por Jeduan Cornejo.

CON LA EXPERIENCIA DE TRABAJAR Y ENTREVISTARME CON STARTUPS, HE COMPILADO UNA LISTA PARA ENCONTRAR RÁPIDAMENTE BANDERAS ROJAS. ACLARO QUE NO ES UN PETITORIO Y QUE TODO DEBA CUMPLIRSE SATISFACTORIAMENTE, SIMPLEMENTE ES UNA GUÍA DE QUÉ COSAS DEBERÍAMOS SABER SOBRE UNA EMPRESA ANTES DE DECIDIR UNIRNOS A ELLA.

EMPRESA ¿De qué tamaño creen que es el mercado que están atacando? ¿Quiénes son los competidores? Si no hay competidores, ¿cuál es la hipótesis de por qué no hay nadie más en este mercado? Si hay competidores, ¿cuál es el diferenciador? Si la startup adapta un modelo extranjero que no existe ahora en el país, ¿cuál es el plan para competir con ellos si abren operaciones aquí? ¿Cuánto dinero hay en el banco y de dónde viene? Con este dinero, ¿a qué números esperan llegar? De esta inversión, ¿cuánto esperan gastar en tecnología? ¿cuánto en marketing? En un año, ¿qué números les harían decidir cerrar la empresa? ¿Cómo esperan que crezca el equipo en los siguientes 6 meses?

COMPENSACIÓN ¿Cuáles son mis responsabilidades y por qué importa lo que voy a hacer para el crecimiento de la compañía? De acuerdo al estudio de salarios de SG, el salario medio de un desarrollador en el DF es de $32,250 pesos antes de impuestos, ¿la compensación está en línea con eso? ¿Hay algún bono o compensación extra? ¿Me toca equity (un porcentaje accionario de la empresa)? Si es así, ¿cuál es la base legal? Basado en la valuación actual, ¿cuál es el valor de ese equity? ¿Quién paga los impuestos?, ¿quién está encargado de la nómina?

FLUJO DE TRABAJO ¿Quién toma las decisiones técnicas? ¿Tienen un roadmap que muestre a donde tiene que ir el producto en los siguientes 6 meses?, ¿cómo se planean los sprints/cargas de trabajo?, ¿cómo se valora la retroalimentación externa?, ¿en qué situaciones se cambian los objetivos?, ¿bajo qué circunstancias pueden los directivos cambiar en lo que se está trabajando? ¿Cuál es el flujo de trabajo?, ¿usan control de versiones?, ¿hay una guía de estilo del código?, ¿dónde se guardan las llaves y contraseñas compartidas?, ¿hay ambientes de staging y/o desarrollo?, ¿cómo y con qué frecuencia se hace deploy a producción? ¿Dónde se pueden consultar los bugs?, ¿cuál es la estrategia de testing?, ¿cuál es la estrategia de backups? ¿Quién escribió la base de código actual?, ¿todavía está en la empresa?, ¿hay documentación? ¿En qué situaciones habría que trabajar en fines de semana? ¿Qué equipo de trabajo (hardware y software) tengo y bajo qué condiciones?, ¿qué presupuesto hay para herramientas (IDEs, PaaS, colaboración, testing, etc) y hardware (segundo monitor, RAM, silla cómoda, SSD, dispositivos de prueba) que me hagan más productivo? ¿Hay un presupuesto para mejorar mis habilidades? (capacitación, cursos, libros) Finalmente, ¿tenemos todo por escrito?

.BIO Jeduan Cornejo es un ingeniero de software que ha colaborado con distintas empresas en México y Estados Unidos como Clevertech, Brandtrack, Yogome, Embly, y Out of The Box. Es un entusiasta de Javascript y es co-organizador de la comunidad de Javascript en la ciudad de México.

Software Guru

¿La empresa tiene una cultura?, ¿cuál es su misión y valores?, ¿cómo planean mantener dicha cultura conforme crece la empresa? ¿En qué creen como balance vida/trabajo?, ¿creen en el trabajo remoto? ¿Quiénes toman la decisión de a quién se contrata?, ¿en qué se fijan al contratar?

¿Tengo seguridad social, seguro de gastos médicos? Si no, ¿cuál es el plan si me enfermo? Si en algún momento no me pueden pagar mi salario a tiempo o completo, ¿con cuanto tiempo de anticipación sabría de esta situación? ¿Cuál es la política de vacaciones?

www.sg.com.mx |

CULTURA

.PORTADA

TENDENCIAS EN TALENTO POR PEDRO GALVÁN

EN LA INDUSTRIA DE TI TÍPICAMENTE UTILIZAMOS EL TÉRMINO “TENDENCIAS” PARA REFERIRNOS A ASPECTOS TECNOLÓGICOS, TALES COMO LENGUAJES O PARADIGMAS DE CÓMPUTO. SIN EMBARGO, CREO QUE TAMBIÉN HAY TENDENCIAS APLICADAS AL PERSONAL. TAN ES ASÍ, QUE INCLUSO EL TÉRMINO UTILIZADO PARA REFERIRNOS A LAS PERSONAS EN NUESTRA INDUSTRIA HA IDO CAMBIANDO EN LOS ÚLTIMOS AÑOS: ANTES ERAN “RECURSOS”, LUEGO “CAPITAL HUMANO” Y AHORA “TALENTO”. En el presente artículo compartiré algunas de las tendencias que actualmente detecto en relación a las personas en la industria de software en nuestra región.

Tecnológico de Lerdo (a 4 horas de camino); en Cancún fue algo similar, con más de la mitad de los participantes provenientes de la Universidad Tecnológica de la Riviera Maya.

EL CV CADA VEZ IMPORTA MENOS

VALORACIÓN DEL DISEÑADOR

Personalmente, para evaluar a un desarrollador, lo último que hago es ver su currículum. Lo primero que hago es buscar a la persona en internet y averiguar cosas como: • ¿Tiene apps publicadas?, ¿qué tipo de apps ha hecho?, ¿funcionan? • ¿Tiene código público (ej. en github)?, ¿qué tanto y en qué lenguajes?, ¿funciona bien su código?, ¿está documentado claramente?, ¿ha hecho pull requests a otros proyectos? • ¿Tiene un blog?, ¿qué tan bien explica sus ideas? No importa si publica artículos técnicos o reflexiones filosóficas, lo importante es que pueda sintetizar y transmitir ideas de forma clara.

Así como las empresas se pelean por buenos desarrolladores, también lo están haciendo por buenos diseñadores. No era así unos años atrás, cuando era muy difícil conseguir un trabajo de planta como diseñador y a la gran mayoría no le quedaba otra más que freelancear. Y no solo son las agencias digitales quienes buscan diseñadores (lo cual es natural), sino también los corporativos y las grandes integradores de sistemas como Accenture o IBM. Ahora, el conjunto de habilidades esperadas de un buen diseñador se ha ampliado significativamente en los últimos años. Hoy en día se espera que conozca de diseño de interacción y de arquitectura de información; es decir, que sea capaz de decir “esa pantalla se ve muy bonita, pero no tiene un ‘call to action’ claro y por lo tanto no es funcional”, o “de esta forma aseguramos que el usuario puede acceder a todas las funciones principales de nuestra app con un solo clic y a todas las secundarias en menos de tres clics”. Adicionalmente, el conjunto de herramientas que requiere dominar un buen diseñador se ha ampliado: desde herramientas de prototipado hasta colaboración y control de versiones. Definitivamente ya no basta con “saberle al photoshop”.

TECNOLÓGICOS AL RESCATE Érase una vez que las organizaciones de software se daban el lujo de solamente contratar a egresados de instituciones educativas “de renombre” como el Tec de Monterrey o la UNAM. Pero ante el crecimiento en la demanda de personal que ha tenido nuestra industria en los últimos 10 años, limitarse a estas instituciones es una receta para el fracaso. Adicionalmente, mi opinión (muy personal) es que los estudiantes de dichas instituciones están demasiado consentidos. Es aquí donde creo que están entrando al rescate los Institutos y Universidades Tecnológicas. Estas instituciones forman a una gran cantidad de personas, y creo que varias están haciendo un buen trabajo al menos en el ámbito de tecnologías de información. Varios responsables de reclutamiento en empresas de software me han comentado que el grueso de las personas que han contratado en los últimos años proviene de tecnológicos. Algo de lo que soy testigo de primera mano, es que los maestros de estas instituciones son bastante proactivos en cuanto a acercar a los alumnos a nuevas oportunidades de aprendizaje y vinculación. Por ejemplo, las sedes virtuales con más participantes en la edición más reciente de nuestro congreso en línea (SG Virtual) fueron: Instituto Tecnológico de Tlalnepantla (499), Universidad Tecnológica del Valle del Mezquital (308), Instituto Tecnológico de Piedras Negras (238), Instituto Tecnológico de Orizaba (198), Instituto Tecnológico de Querétaro (181). Otro caso que tengo cercano es el de los talleres de desarrollo de apps móviles que SG organizó recientemente: en el taller que realizamos en el ITAM (DF), cerca de la mitad de los participantes eran del Instituto Tecnológico de Celaya (a 3 horas de camino); en Monterrey, más de la mitad era del Instituto .BIO Pedro Galván Kondo es cofundador y director de Software Guru.

MEJOR COMPENSACIÓN COMO TÉCNICO Durante la encuesta de salarios, el CTO de un corporativo me comentó que la respuesta de compensación extra anual (aguinaldo, bonos, etc.) estaba topada en 600 mil pesos y él percibía más de eso. Al decirle que “qué presumido”, me respondió: “no, quiero que los jóvenes sepan que en nuestra profesión pueden tener ese tipo de compensación”. Por otro lado, platicando recientemente con César Salazar de 500 Startups sobre la problemática de las startups para encontrar talento, yo esperaba que me dijera lo mismo que de costumbre (“¿cómo le hacemos para formar y/o encontrar desarrolladores?”); pero no, lo que me dijo fue: “estamos trabajando para que nuestras startups tengan acceso a más capital para que puedan pagar lo suficiente para atraer buenos desarrolladores”. Estos y otros casos recientes, me hacen creer que por fin en México los desarrolladores están comenzando a tener buena compensación sin necesidad de irse a posiciones de venta o administración, lo cual es una gran noticia. En resumen, creo que es un interesante momento para los profesionistas en nuestra industria. No importa dónde o qué estudiaste; hay muchas oportunidades y bien compensadas.

www.sg.com.mx |

Software Guru

.PRÁCTICAS Gestión de procesos

Gestionando Procesos de Negocios Usando BPMN 2.0 ›› Por Enoc Cruz Nájera y Germán H. Alférez

n proceso de negocio es un conjunto de actividades que están relacionadas al logro de las metas específicas en una organización. Uno de los más grandes problemas encontrados en los procesos de negocios consiste en la dificultad para administrarlos. A menudo, falta claridad acerca del tamaño exacto del proceso y se desconoce cuáles son las tareas que lo componen. Además, algunos podrían desconocer dónde inicia y con qué tarea concluye dicho proceso. En el presente artículo se describe una solución para modelar procesos de negocios de forma que se tenga dominio sobre ellos. Para ello proponemos usar BPMN 2.0 como notación de modelado y Activiti como motor de ejecución. Ambos pueden ser usados para gestionar procesos de negocios.

Introducción

Un proceso de negocio consiste en un conjunto de actividades que se realizan de forma coordinada en un entorno organizacional y técnico conjuntamente con una meta del negocio [1]. Se ha encontrado que uno de los problemas de la gestión de procesos está relacionado con su diseño correcto [2]. Es así que resulta conveniente modelar dichos procesos. Un modelo de proceso de negocio consiste en la descripción y visualización de los procesos mediante un patrón que los represente de manera formal por medio de un diagrama para ilustrar claramente las actividades que una organización utiliza para lograr sus metas [3]. Existen varias aproximaciones para modelar procesos de negocios [4]. Una de ellas es BPMN 2.0, que consiste en un estándar que puede ser utilizado para diseñar diagramas que faciliten la comprensión del proceso de negocios en las organizaciones. Este artículo plantea tres contribuciones: una breve descripción de BPMN 2.0 como lenguaje de modelado de procesos de negocios; una corta descripción de Activiti como motor de ejecución; y un caso de estudio. A continuación describiremos a grandes rasgos la notación BPMN 2.0, posteriormente la herramienta Activiti, y por último presentmaos un caso de estudio en el que se aplican BPMN 2.0 y Activiti para la gestión de un proceso de negocio. 32

BPMN 2.0

Existen diversas herramientas para el modelado de procesos de negocios. No obstante, estas aproximaciones no ofrecen un estándar para el modelado de estos procesos. La Business Process Management Initiative propuso un estándar denominado Business Process Modeling Notation (BPMN). La primera versión del estándar BPMN fue lanzada en 2004, con la meta de producir un estándar gráfico que permitiera entender la lógica de los procesos, su configuración, administración, y monitoreo [5]. En el año 2010 se lanzó la versión BPMN 2.0. Este estándar fue calificado por el consorcio del Object Management Group como estable y maduro [6]. Respecto a la primera versión, BPMN 2.0 tiene las siguientes mejoras: soporta diagramas de procesos de negocios y de flujo de trabajo; es un estándar de código abierto que puede integrarse en cualquier entorno de programación; y permite el modelado de procesos a nivel de desarrollador y a nivel de usuario final. La notación BPMN 2.0 se visualiza gráficamente en un diagrama que muestra el flujo de trabajo de un proceso de negocio. Esto facilita el diseño del diagrama por medio de objetos gráficos con apariencia y nombres amigables [7]. Los objetos en un proceso de negocio se dividen en cuatro categorías: flow objects (objetos de flujo), connecting objects (objetos de conexión), swimlanes (carriles), y artifacts (artefactos).

Activiti

Existen herramientas para diagramar procesos de negocios mediante BPMN 2.0. Algunas de ellas son BPMN Visio Modeler, iGrafx Process y Borland Together. Otras herramientas funcionan como diagramadores y como motores de ejecución del proceso. Por ejemplo, Bonita BPM, Oracle Business Process Management Suite, e Intalio BPM son soluciones comerciales de este tipo. En esta sección se propone la utilización de Activiti para el diseño de modelos de procesos de negocios en BPMN 2.0 y para ejecutar estos modelos. Activiti es una alternativa viable porque se trata de software de distribución gratuita. Esto es ideal para organizaciones en economías emergentes.

.PRÁCTICAS

Gestión de

procesos

Activiti es ligero y fácil de usar. Su propósito principal no solo consiste en implementar un lenguaje general de procesos de negocios en notación BPMN 2.0, sino también en apoyar los lenguajes de implementación y de ejecución. Activiti está integrado por tres componentes fundamentales: Componente de modelamiento. Es un editor para diseñar y diagramar el modelo de procesos de negocios. Componente de tiempo de ejecución. Permite la actualización y/o combinación de procesos para su ejecución en un ambiente Java, por ejemplo, en Spring. Componente de administración. Es una aplicación Web que permite a los usuarios del sistema el acceso al proceso en tiempo de ejecución, administrando, supervisando y monitoreando los elementos del proceso.

Actualmente estamos trabajando en lograr administrar la variabilidad de procesos de negocios en tiempo de ejecución. Para ello estamos extendiendo las capacidades de BPMN 2.0 mediante la utilización del Common Variability Language [8]. Con el fin de evitar reconfiguraciones manuales, nuestra aproximación se basará en los principios de la Computación Autónoma, utilizando los resultados de nuestro trabajo previo.

Caso de estudio

Conclusiones y trabajo futuro

En este artículo se describió brevemente el estándar BPMN 2.0. Dicho estándar permite definir con una semántica correcta procesos de negocios. La utilización de Activiti para diseñar y ejecutar modelos de negocios en notación BPMN 2.0 es factible en el caso mexicano ya que esta herramienta es de bajo costo.

Figura 1. Diagrama del Proceso en notación BPMN 2.0.

[1] M. Wezke. Business Process Management: Concepts, Languages, Architectures. Springer, 2007. [2] E. Tello, J. Carreón & M. Castillo. Approach for Semantic Business Process Management using Ontologies. Ing. USBMed, 2013. [3] I. Moreno, et al. “Pragmatic Guidelines and Quality Metrics in Business Process Modeling: a Case Study”. Revista Cubana de Ciencias informáticas, 2014 [4] K. Baina & S. Baina. “User Experience-based Evaluation of Open Source Workflow Systems”. ISKO-Maghreb. 2013. [5] White, S. (2004). Introduction to BPMN. http://swgu.ru/pe [6] Object Management Group. Business Process Model and Notation (BPMN) Version 2.0. http://swgu.ru/pf [7] Earls, A. (2011). Feature: BPMN 2.0: The Emerging Star of Business Process Modeling. http://swgu.ru/pg [8] C. Ayora, V. Torres, V. Pelechano & G. H. Alférez. Applying CVL to Business Process Variability Management, 2012. [9] G. H. Alférez & V. Pelechano. Context-Aware Autonomous Web Services in Software Product Lines. IEEE Computer Society, 2011.

.BIO Enoc Cruz Nájera es profesor de Bases de Datos e Ingeniería de Software en la Facultad de Ingeniería de la Universidad Linda Vista en Chiapas. Actualmente es estudiante de la Maestría en Ciencias de la Computación con acentuación en Ingeniería de Software en la Universidad de Montemorelos. ecruznajera@ulv.edu.mx Germán Harvey Alférez Salinas es Catedrático en la Facultad de Ingeniería y Tecnología de la Universidad de Montemorelos. Obtuvo el título de Ingeniería de Sistemas en la Universidad EAFIT (Colombia), el de MSc in Information and Communication Technology en Assumption University (Tailandia), y el de Doctor en Informática en la Universidad Politécnica de Valencia (España). Alférez ha trabajado en universidades, grupos de investigación y en empresas tecnológicas de cuatro continentes. www.harveyalferez.com

Software Guru

Referencias

www.sg.com.mx |

En esta sección se presenta un caso de estudio basado en el proceso de negocio de matricula de la Universidad Linda Vista localizada en el Estado de Chiapas, México. El proceso inicia con la recepción de la solicitud de admisión de un estudiante por parte del Departamento de Admisiones y Registro. Posteriormente se asigna la carga académica al estudiante. Con base en los datos de las asignaturas se procede a calcular el pago. El pago se realiza en efectivo, con tarjeta de crédito, o tarjeta de débito. Una vez realizado el pago se imprime el comprobante de pago. El Departamento de Admisiones y Registro concluye el proceso cambiando el estatus del estudiante a ‘inscrito’. La Figura 1 describe gráficamente este proceso de negocio. Las anotaciones indican los nombres de los elementos BPMN del diagrama. En este proceso de negocio se pueden identificar actividades manuales y actividades automatizadas. Por ejemplo, Recibir Solicitud de Admisión y Cambiar Estatus a ‘Inscrito’ son tareas manuales. El resto de actividades son automatizadas.

.PRÁCTICAS Calidad

TDD

y Clean Code ›› Por Victor Luna y Fernando Arana

a sensación al modificar el código productivo es abrumante. Tecleas lenta y titubeantemente cada palabra y sentencia. ¿Cambiar un método que ya funciona? ¿Por refactor? ¿Estoy loco o qué? Modificar un simple «if» te revuelve el estómago al pensar en sus múltiples efectos colaterales. Temblar por cada cambio en el sistema, ¿es normal?, no debería de serlo, ¿verdad? Al detectar un problema uno debería tener una sonrisa si conoce la solución, y no quedarse inerte al pensar cómo se atacará ese problema. Es lo que pasa cuando no se tiene la garantía ni la certeza de que mover esa ficha de ajedrez dejará protegido al rey. Dentro de las responsabilidades del desarrollador está comprobar el correcto funcionamiento del código y que el sistema continúe trabajando en armonía, pero, ¿cómo se tiene la certeza de que el sistema no haya sido dañado? Validar que el sistema siga funcionando y no colapse es posible con ayuda de las pruebas de integración y pruebas unitarias. Siempre me han llamado la atención esos pequeños aparatos que utilizan los músicos para afinar sus instrumentos; estos garantizan que la guitarra o violín sigan tañendo correctamente, y no hay temor al cambiar una cuerda que ya está vieja. Las pruebas funcionan como ese pequeño aparato mágico que usan los músicos, las pruebas hacen que el sudar frío sea cosa del pasado y que el desarrollador haga adecuaciones con facilidad y libertad. Las pruebas forman parte de los aspectos más importantes dentro del mundo del Clean Code. Probar el código es tan valioso como producirlo y además es una excelente documentación de las reglas del negocio. Pero no sólo se trata de hacer pruebas por hacerlas; debe haber calidad en ellas y, si se desea una buena integración continua, éstas deben de ser automatizables y ser ejecutadas constantemente. Está prohibido crear pruebas que serán ejecutadas sólo una vez.

TDD

Las pruebas son importantes en el desarrollo del sistema y qué mejor que ese desarrollo esté guiado por esas pruebas de software (Test Driven Development). Es un cambio de mentalidad con grandes beneficios. Escribir primero una prueba y después 34

hacerla pasar es principio de un cambio de esquemas, dando como resultado una efectiva forma de trabajar, en donde los requisitos son traducidos a pruebas y, de este modo, cuando pasan se garantiza que el software cumple con las reglas del negocio. Además, el propósito del desarrollo guiado por pruebas da como consecuencia un código de calidad, limpio y funcional. Iniciar con la construcción de la prueba ayuda al desarrollador a pensar en el escenario más sencillo; dado este escenario el sistema se verá moldeado como esa vasija de barro que se va adornando poco a poco con detalles más finos. TDD es una forma de codificar que nos exige disciplina; combatimos la tentación de continuar escribiendo código productivo que aún no ha sido abstraído en una prueba, y hacen de esta práctica un verdadero examen de autocontrol. De seguir tecleando código previsor, los ansiosos dedos han de ser detenidos con freno de mano. Ponemos de manera constante nuestras emociones en el ring, pero el resultado es aplaudido, el código camina orgulloso, sonriente y con la cara en alto, al haber vencido la batalla con esos dedos indisciplinados.

Mi experiencia

Hacer una prueba antes de crear un código productivo me pareció en principio una locura, no una disparatada, pero sí una que no se puede conceptualizar en el mundo real. Cambiar de paradigmas es algo complicado, aun cuando uno está abierto a aprender y conocer sobre nuevas formas de trabajar y programar. Ahora, recapitulando mi pasado, siento que era como Jack, el famoso personaje de Tim Burton, fascinado con la celebración de la navidad, emocionado por conocer el nuevo y sorprendente concepto, pero atrapado por sus percepciones pasadas. En el tiempo que llevo dedicándome a este bello arte del desarrollo de software, he tenido la oportunidad de estar en muchos equipos de trabajo, y he podido ver líneas de código creadas por principiantes y maestros, pero al día de hoy, hablando de Clean Code, no puedo decir que vi en ellos algo a lo que puedas llamar código limpio. Quizá técnicamente sea código muy bueno, pero seguro a muchos de noso-

.PRÁCTICAS Calidad

ciones de código se ve la mejora, ya que rápidamente se entiende lo que hace dicho método o clase, y se puede dar una opinión valiosa para mejorar.

Criterios

¿Pero qué es Clean Code? ¿Cómo saber si mi código está limpio? ¿Cómo sé que va a seguir limpio con el tiempo? A continuación compartiré definiciones que considero muy buenas: “Me gusta que mi código sea elegante y eficiente. El Código limpio hace sólo una cosa y la hace muy bien”. — Bjarne Stroustrup “El código limpio es simple y directo. El Código limpio se lee como prosa bien escrita”. — Grady Booch “Código limpio: pasan todas las pruebas, no contiene código duplicado, expresa todas las ideas de diseño que están en el sistema y minimiza el número de clases, métodos, funciones y todo lo que se le parezca”. — Ron Jeffries

Conclusión

El hábito y la cultura de crear pruebas no es cosa fácil, se necesita confiar en ellas y valorarlas como la forma de seguir haciendo crecer el código. Generar código a partir de las pruebas es todo una aventura, que espero adoptes en tu futuro estilo de programación. El código limpio es esencial para el fortalecimiento de tus habilidades al programar y diseñar sistemas. Usar nombres adecuados y realizar métodos concretos son pequeñas pinceladas que harán ver la imagen más nítida. Existen grupos y personas que pueden ayudarte en los primeros pasos de Clean Code y TDD. En todas las ciudades se organizan code katas, code retreats o hackathons. Búscalos y anímate a participar.

Referencias [1] Clean code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) [2] Test Driven Development: By Example (Kent Beck) [3] Refactoring: Improving the Design of Existing Code (Martin Fowler) [4] Working Effectively with Legacy Code (Michael Feathers) [5] The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin)

.BIO Víctor Luna (victorhugo.lunar@gmail.com) es Ingeniero en Sistemas y después de 8 años desarrollando, ha encontrado en las metodologías ágiles una manera de hacer software con calidad y profesionalismo. Fernando Arana (fernando0044@hotmail.com) es ingeniero de software y continúa aprendiendo conocimientos y principios de las tendencias de desarrollo. Ambos trabajan en Tralix y colaboran en el blog http://codeamesta.blogspot.com

Software Guru

Para mí un código bueno es aquel que puede ser entendido por cualquier programador, pero un código limpio es aquel que puede ser leído y entendido por cualquier persona.

www.sg.com.mx |

tros nos ha tocado la oportunidad y necesidad de ver y modificar dichas líneas, y al igual que yo han dicho: «quién demonios hizo esto». Me refiero a esas funciones y clases tan largas como una fila de cajero automático en quincena y que, al verlas por primera vez, piensas que es más fácil aprender chino que entender lo que dicha función hace. Esto provoca miedo de tocar dicho código, porque no sabes qué más vas a romper y entre más le mueves más errores aparecen. Es como si hubieras abierto la caja de Pandora y el fin del mundo estuviera cerca; sólo esperaríamos la promesa de que un día llegará un salvador que rediseñe el software, debido a que el actual es tan poco sostenible que es mejor volverlo a hacer, por salud mental de todos. Prometeríamos que esta vez sí lo haríamos bien. Sin embargo, por más equipo SWAT y expertos que tengamos, ¿sólo las buenas intenciones nos garantizan que las malas prácticas se detengan? Ahora: ¿por qué Clean Code nos puede ayudar a detener estas malas prácticas? Primero veamos qué es limpiar; su definición nos puede ayudar: «Limpiar: quitar o eliminar lo que estorba o no sirve». ¿Por qué limpiar nuestro código? En primer lugar es para sentirnos a gusto de trabajar en lugar limpio, no es lo mismo llegar a trabajar a una oficina limpia que a una llena de basura. De entrada nos hace sentir mejor. La situación se complica cuando compartimos código; nadie trabaja solo. Es como cuando compartes un departamento. No te gustaría que alguno de tus roomates dejara un desorden en el baño o la cocina justo antes de que tú los utilices. Lo mismo pasa con el código: tenemos que entender que otras personas van a utilizarlo y es profesional no dejarles un desorden. ¿Cómo podemos llegar a tener un código limpio? Es recomendable que dentro de su equipo de trabajo tengan convenciones y estándares para la creación de clases, métodos, funciones y variables que se adecuen al lenguaje de programación que utilicen. Traten de que el código se pueda leer de forma clara de arriba a abajo y de izquierda a derecha, como si se tratara de un libro. El nombrado de variables, funciones y clases debe ser lo más descriptivo posible, sin importar que los nombres sean muy largos al principio. Sin ser todavía un experto en Clean Code, les puedo compartir que la calidad dentro de mi equipo de trabajo ha mejorado usando técnicas como TDD y principios como SOLID. Métodos que no pasan de cuatro líneas y que hacen sólo una cosa, la hacen bien y lo sabemos, dado que hay una prueba que lo respalda. No pasar más de tres o cuatro parámetros, ya que indica que el método está haciendo muchas cosas. Darle una oportunidad al polimorfismo para quitar varios if, switch y booleans como parámetros. Crear nuevas clases o interfaces basadas en un refactor. Al hacer inspec-

.PRÁCTICAS Ingeniería de Software

Ingeniería de Software Basada en Búsqueda ›› Por Abel García Nájera

n la ingeniería de software (IS), como en cualquier otra disciplina de la ingeniería, surgen de forma natural problemas de optimización, previamente, durante y después del desarrollo de software. En estos problemas intentamos encontrar los mejores valores para las variables que intervienen en ellos. Existen métodos que pueden resolver problemas de optimización pequeños de forma exacta, sin embargo, para problemas reales, cuyo tamaño es generalmente grande, el tiempo de ejecución de estos métodos se incrementa de forma considerable. Esta es la razón principal por la cual este tipo de problemas se resuelven mediante métodos heurísticos, los cuales, a pesar de no ofrecer una garantía de desempeño, usualmente encuentran soluciones buenas y prácticas. Precisamente, la ingeniería de software basada en búsqueda (ISBB) utiliza heurísticas para resolver los problemas que aparecen en la IS. El objetivo de este artículo no es explicar cómo funcionan las heurísticas ni cómo se resuelven estos problemas, sino plantear algunos problemas de la IS como problemas de optimización y presentar un panorama de la aplicación de la ISBB.

La IS como problemas de optimización

Un problema de optimización considera una o más variables de decisión, cuyos valores definen el espacio de búsqueda. Este espacio se explora con el fin de encontrar aquellos valores que ofrecen la mejor evaluación de la o las funciones objetivo que queremos minimizar o maximizar. Estas funciones objetivo comúnmente están en conflicto, es decir, la optimización de una de ellas implica la degradación de las otras. A continuación expondré tres problemas comunes en la IS y describiré las variables, el espacio de búsqueda y las funciones objetivo a optimizar.

Problema de la siguiente versión Idealmente, la siguiente versión de un producto debería considerar todos los requisitos de todos los clientes que han dado retroalimentación sobre la versión actual, esto con el fin de mantener a los clientes y, sobre todo, que estén satisfechos. Sin embargo, no siempre se pueden tomar en cuenta la totalidad de los requisitos, muchas veces por cuestiones de costo. En este caso surge la siguiente pregunta: ¿cuál es el subconjunto de requisitos que equilibra el costo de desarrollo de software y la satisfacción de los clientes? En este problema, la variable de decisión es un subconjunto de requisitos y tenemos que considerar

todos los posibles subconjuntos. Por ejemplo, si la cantidad de requisitos es 50, el número de subconjuntos posibles de requisitos, es decir, de soluciones potenciales, es 250, que son aproximadamente 1015. Considerar todos estos subconjuntos para encontrar aquél que ofrece la mejor evaluación de los objetivos es prácticamente imposible. Las funciones objetivo en este problema son: el costo de desarrollo de software, que se tiene que minimizar, y la satisfacción de los clientes, que se tiene que maximizar. Obviamente, si queremos que los clientes estén ampliamente satisfechos, deberíamos considerar, si no la totalidad de los requisitos, un subconjunto muy grande de éstos y, consecuentemente, esto implicaría un mayor costo de desarrollo. Por el contrario, si queremos que el costo de desarrollo sea mínimo, deberíamos considerar un subconjunto pequeño de requisitos, lo cual reduciría considerablemente la satisfacción de los clientes.

Problema de las pruebas de software Los sistemas reales generalmente son grandes y con cualquier cantidad de opciones y ramificaciones. Probar este tipo de sistemas de forma exhaustiva no es práctico, por lo que se deben definir casos de prueba. Aquí aparece la pregunta ¿cuál es el conjunto más pequeño de casos de prueba que abarca todas las ramas del sistema? La variable que interviene en este problema es un subconjunto de casos de prueba y el número de soluciones potenciales es similar al del problema de la siguiente versión. Las funciones objetivo en este problema son: la confiabilidad del sistema, que se debe maximizar, y el costo de probar el sistema, que se debe minimizar. Claramente, si queremos reducir el costo de la etapa de pruebas, el número de casos de prueba será reducido, consecuentemente la confiabilidad del sistema será baja o nula. Por el contrario, si queremos garantizar un producto confiable, se tendrá que invertir mucho en salarios de ingenieros de pruebas. Problema de la planificación de un proyecto de software Generalmente, cada uno de los ingenieros de software que pueden participar en un proyecto de desarrollo conoce sólo algunas de las tecnologías necesarias para llevar a cabo el proyecto. De acuerdo a sus conocimientos, una ingeniera de software comúnmente se clasifica como principiante, avanzada o experta y su sueldo depende de su categoría y su experiencia. Por otro lado, un proyecto de desarrollo de software se puede dividir en tareas y el inicio de cada una de éstas podría depen36

.PRÁCTICAS

Ingeniería de Software

La ISBB se propuso formalmente hace poco más de una década, aunque ya para entonces existían algunos estudios que aplicaban heurísticas, principalmente a las pruebas de software. De acuerdo con el Repositorio de la ISBB [1], ésta se ha aplicado a una variedad de problemas de la IS. Para tener una perspectiva de las aplicaciones, la Figura 1 muestra una gráfica de la proporción de artículos publicados por área de conocimiento de la IS. Como en muchas otras áreas de investigación, la gran mayoría de estas publicaciones son puramente académicas, sin embargo, el interés por aplicar la ISBB en la industria del software se ha incrementado en los últimos años. Un estudio reciente [2] destaca los siguientes casos de éxito. En Chrysler, una de las primeras empresas en utilizar la ISBB, experimentaron con estas técnicas para las pruebas funcionales de un sistema de estacionamiento y para las pruebas temporales de los controladores de las bolsas de aire. Microsoft utilizó la ISBB para la incorporación de cálculos de punto flotante en PeX, su herramienta de pruebas de software. Google integró la ISBB para la optimización de pruebas de regresión en su proceso de pruebas. La NASA, Motorola y Ericsson han hecho experimentos con la ISBB para el análisis y la optimización de requisitos.

conocimiento de la IS.

Además, se han identificado áreas potenciales para la aplicación de la ISBB [3], tales como la optimización de los objetivos en conflicto en los paradigmas ágiles, en los sistemas basados en cómputo en la nube y en los sistemas móviles y embebidos.

Conclusiones

Los problemas que surgen en la IS pueden ser tratados, como los de cualquier otra disciplina de la ingeniería, como problemas de optimización. Estos problemas consideran muchas variables y generalmente el número de soluciones potenciales es muy grande. Consecuentemente, no es posible utilizar métodos exactos para resolverlos, sino métodos heurísticos que aunque no garantizan la mejor solución, ofrecen soluciones buenas y prácticas. Con sus pocos 10 años, la ISBB es una área potencial de investigación aplicada que utiliza heurísticas para resolver los problemas de optimización que aparecen en la IS. La industria del software ha aplicado ISBB a algunos de estos problemas con logros significativos y se han detectado áreas prometedoras para su utilización.

Referencias [1] Y. Zhang, M. Harman, A. Mansouri. The SBSE repository: A repository and analysis of authors and research articles on Search Based Software Engineering. CREST Centre, UCL. http://crestweb.cs.ucl.ac.uk/resources/sbse_repository [2] M. Harman, A. Mansouri, Y. Zhang. Search-based software engineering: Trends, techniques and applications. ACM Computing Surveys, 45(1), 11. [3] M. Harman. Software engineering meets evolutionary computation. Computer, 44(10), 31-39.

.BIO El Dr. Abel García Nájera (@abelgn) es profesor-investigador en la Universidad Autónoma Metropolitana, Unidad Cuajimalpa. Sus actividades principales son la docencia y la investigación en temas relacionados con algoritmos, optimización, heurísticas e ingeniería de software. Además, tiene experiencia en consultoría para problemas de optimización. www.abelgarcia.mx

Software Guru

Aplicación de la ISBB

Fig 1. Proporción de artículos de la ISBB publicados por área de

www.sg.com.mx |

der de la terminación de algunas otras. Cada tarea tiene un esfuerzo estimado y se necesitan ingenieros de software con ciertas habilidades y conocimientos de ciertas tecnologías para que pueda concluirse. Este problema consiste en asignar ingenieros de software a cada una de las tareas del proyecto, de tal forma que el costo del mismo sea mínimo y la fecha de entrega sea lo más cercana a la fecha comprometida. Las variables involucradas en este problema son binarias y cada una corresponde a si una ingeniera de software es asignada o no a una tarea del proyecto. Entonces, el número de variables es igual al producto del número de ingenieros de software por el número de tareas. Como ejemplo, podemos considerar que 10 ingenieros de software van a participar en un proyecto se podría dividir en 10 tareas. Por lo tanto, estamos hablando de 100 variables binarias y la cantidad de soluciones potenciales es 2100, que son alrededor de 1030. Obviamente no podemos probar cada una de estas diferentes asignaciones para encontrar aquella que minimiza el costo. Este problema se puede complicar aún más. Por ejemplo, ¿qué pasa cuando una de las ingenieras deja de participar en el proyecto? En este caso, tenemos que encontrar una nueva asignación que provoque el menor cambio en la asignación actual, de tal forma que el incremento en el costo sea mínimo y la fecha de entrega se desplace lo menos posible.

.PRÁCTICAS Arquitectura

Arquitectura y Preventa ›› Por Humberto Cervantes (UAM-I)

“La identificación de tecnologías puede obedecer a las restricciones establecidas así como a los atributos de calidad indicados”.

n esta ocasión hablaré acerca del uso de técnicas de desarrollo de arquitectura de software como parte de la etapa de preventa de los proyectos de software. Por preventa me refiero a la etapa que ocurre cuando se hace una propuesta de solución para desarrollar un sistema de software. El cliente típicamente solicita propuestas a varios proveedores, da cierto periodo de tiempo para recibir propuestas (que puede ir de unos cuantos días a algunas semanas), y selecciona una propuesta/ proveedor para realizar el proyecto. Tradicionalmente se piensa que el desarrollo de la arquitectura inicia hasta la operación de un proyecto, sin embargo y como describiré en esta columna, es conveniente iniciar las actividades de desarrollo de arquitectura desde la etapa de preventa con el fin de lograr una propuesta más pertinente tanto para el cliente como para la organización que planea llevar a cabo el proyecto.

Preventa

La preventa se enfoca en establecer por un lado el alcance del proyecto y, por el otro, una estimación del tiempo y costo que llevará la realización del proyecto de desarrollo. La estimación que se genera durante la preventa permite al cliente tomar la decisión de si acepta o no que se realice el proyecto. Aunque en este artículo me estaré refiriendo a la preventa en un contexto de desarrollo de software a la medida, lo que aquí describo puede aplicarse también en otros contextos. La preventa cubre actividades de la fase de inicio y planeación del ciclo de vida tradicional de la administración de proyecto. Sin embargo, dado que el propósito de la preventa es conseguir la aprobación de la realización del proyecto, muchas veces las actividades que se realizan durante la preventa son menos detalladas que lo que se hace una vez que el proyecto ha iniciado de manera formal. Por ejemplo, durante la preventa es muy probable que no se tenga claridad sobre quiénes serán las personas específicas que ejecutarán el

proyecto; simplemente se determina cuántas personas y con qué perfiles se necesitarían para llevar a cabo el proyecto de acuerdo a la solución y tiempos propuestos. Hay que señalar que durante la preventa se tiene un contexto particular y complicado, en el cual muchas veces se deben considerar: • Información limitada: Generalmente no será sino hasta que se ejecute el proyecto que se levantarán los requerimientos de forma detallada, por lo que al momento de la preventa sólo se cuenta con requerimientos de alto nivel (que aquí llamaremos “características”). La figura 1 muestra un diagrama basado en la pirámide de requerimientos de Leffingwell donde está marcado en rojo el contexto de requerimientos con el que operamos durante la preventa. • Poco tiempo: Muchas veces las propuestas de preventa deben ser desarrolladas en tiempos cortos. Esto es porque generalmente el cliente solicita que se le entregue una cotización rápidamente pero, también, porque la empresa de desarrollo no desea dedicar demasiado esfuerzo en una actividad que muchas veces no se cobra y para la cual no hay garantía que haya un beneficio a largo plazo.

Desarrollo de arquitectura durante la preventa

Uno de los aspectos fundamentales del trabajo que se realiza en la preventa es la estimación. Lograr una estimación adecuada muchas veces requiere de establecer un esbozo de solución, por ejemplo, para dimensionar el hardware que se debe adquirir como parte del proyecto o para conocer el tipo de recursos que deben ser asignados o contratados para la ejecución del mismo. Es en el desarrollo de esta solución preliminar que las técnicas de desarrollo de arquitectura de software pueden aportar beneficios importantes si dichas técnicas son adaptadas para el contexto particular de la preventa. Recordemos que el ciclo de vida de la arquitectura de software consta de 4 etapas que incluyen requerimientos, diseño, documentación 38

.PRÁCTICAS

Arquitectura

Figura 1. Contexto de preventa.

Recordemos que dentro de los requerimientos de un sistema de software, una parte de ellos es la que influye de manera decisiva sobre la arquitectura. Estos requerimientos son conocidos como drivers de la arquitectura e incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG #28). Como mencioné previamente, al momento de realizar la preventa de un proyecto no se cuenta con requerimientos detallados del proyecto, ya que en general estos no serán levantados y especificados sino hasta que el proyecto esté siendo ejecutado. Muchas veces sólo se dispone de características o requerimientos de alto nivel. Con el fin de poder diseñar una solución preliminar con el fin de estimar, es importante que durante la preventa se considere obtener drivers de preventa que incluyen: • Características funcionales. A diferencia de los drivers tradicionales en donde sólo se considera la funcionalidad primaria, en general en la preventa es necesario considerar toda la funcionalidad pues la estimación del proyecto debe considerar todas las características funcionales del mismo. • Características de atributos de calidad. Durante la preventa es complicado hacer un levantamiento detallado de los atributos de calidad, y más particularmente, especificarlos como escenarios. Dos aspectos que se deben cuidar particularmente son, sin embargo, el identificar las categorías de atributos de calidad más relevantes para el proyecto y, por otro lado, un rango preliminar en relación con las métricas asociadas a estos atributos de calidad. • Restricciones. Es necesario identificar desde el inicio las restricciones al diseño de la solución. En particular es importante identificar restric-

Diseño de arquitectura durante la preventa

Una vez que se tienen identificados los drivers de preventa, es posible proceder al diseño de la solución. Algo que es importante considerar es que durante la fase de preventa, el objetivo principal del diseño de la arquitectura es de establecer una estructura que permita estimar el proyecto. Lo anterior diferencía el diseño de arquitectura que se hace en preventa del diseño de arquitectura que se hace durante la operación de un proyecto (ver SG #29). Generalmente el tiempo con el que se cuenta para diseñar la arquitectura durante la preventa es corto por lo que el nivel de detalle de la solución muchas veces es limitado. Con el fin de lograr la identificación de elementos que permitan realizar la estimación, es recomendable establecer estructuras generales de un punto de vista lógico y de un punto de vista físico. Cabe señalar que esto puede verse como la realización de rondas iniciales de diseño utilizando el método de diseño guiado por atributos o ADD.

Estructuración general del sistema de un punto de vista lógico

La estructuración general del sistema de un punto de vista lógico consiste en identificar, por un lado, el estilo arquitectónico que se usará y, por otro lado, los componentes que deberían soportar el conjunto de características funcionales del sistema. Para lograr esta descomposición, que tiene un enfoque funcional, es recomendable hacer uso de arquitecturas de referencia que definen la estructuración general de sistemas para dominios aplicativos bien establecidos. Un ejemplo de ello es una arquitectura de referencia para aplicaciones web empresariales, ya que establece las capas así como los tipos de componentes de este tipo de arquitectura. 39

Software Guru

Drivers de arquitectura durante la preventa

ciones que pueden influir en la estimación y que pueden tener que ver con el tipo de tecnología a utilizar, los sistemas con los que interactúa el sistema que se va a desarrollar y el entorno de operación del sistema.

www.sg.com.mx |

y evaluación (ver SG #27). A continuación veremos de qué manera puede ser adaptada cada una de estas etapas para el contexto de la preventa.

.PRÁCTICAS Arquitectura

“Lograr

una estimación adecuada requiere de establecer un esbozo de solución”.

Otro aspecto que puede ser importante en este punto es la identificación de las tecnologías asociadas con las partes que define la arquitectura de referencia. La identificación de tecnologías puede obedecer a las restricciones y también a los atributos de calidad del sistema.

Estructuración general del sistema de un punto de vista físico

La estructuración general del sistema de un punto de vista físico consiste en mapear los elementos de la estructura lógica hacia elementos físicos, más particularmente, nodos en los cuales se ejecutarán las partes de la aplicación. De esta forma se establece la manera en que será implantada la solución. La identificación del esquema de implantación es fundamental para establecer una estimación de los recursos físicos necesarios para el desarrollo de la solución. El esquema de implantación de la solución que se elige obedece, en general, a los atributos de calidad del sistema pero también a las restricciones. En general son atributos de calidad relacionados con la disponibilidad y el desempeño los que influirán directamente sobre el esquema de implantación de la solución. Por ejemplo, cuando se tienen requerimientos relacionados con una alta disponibilidad, muchas veces se opta por un esquema de implantación que implica la redundancia.

Documentación de arquitectura durante la preventa

La documentación del diseño de una arquitectura consiste en la representación de las distintas estructuras a través de vistas (ver SG #30). En el contexto de la preventa, en general la documentación que se produce del diseño es información que será usada como parte de la propuesta técnica que se le entrega al cliente, por lo que no es tan conveniente realizar una documentación demasiado técnica (a diferencia de lo que se hace durante la ejecución del proyecto). Muchas veces la documentación se limita a un diagrama usando un lenguaje menos formal, o lo que se conoce como diagrama de “Marketecture”.

Evaluación de arquitectura durante la preventa

Una de las actividades fundamentales del ciclo de desarrollo de la arquitectura es la evaluación del diseño (ver SG #31). Recordemos

que el propósito de la evaluación es la identificación de riesgos relacionados con la toma de decisiones relativas al diseño. Al igual que lo que se realiza como parte del ciclo de desarrollo de la arquitectura, es posible realizar una evaluación del diseño durante la preventa. En una evaluación basada en escenarios tradicional, se toman escenarios y se revisa detalladamente la manera en que el diseño de la arquitectura los soporta. Durante la preventa, el nivel de detalle del diseño del que se dispone no es el mismo. De hecho, muchas veces no se han tomado decisiones finas enfocadas a soportar escenarios concretos dado que no se dispone de ellos. Por lo anterior, la evaluación de la arquitectura durante la preventa no puede ser realizada de la misma manera que lo que se realiza durante la operación del proyecto. En general, durante la evaluación de arquitectura en preventa, lo que se evalúa son las decisiones primarias tomadas en relación al diseño: la elección del tipo de arquitectura de referencia, las tecnologías o el esquema de implantación. Generalmente la evaluación de arquitectura identifica riesgos asociados no únicamente con el diseño sino también con otros aspectos tales como los requerimientos. Por ejemplo, si al momento de realizar la evaluación se observa que no hay métricas asociadas a los atributos de calidad (como sucede frecuentemente), esto representa un riesgo. Finalmente, puede ser conveniente que como parte de la evaluación, se revise el plan que se tiene del proyecto para evaluar si la estrategia que se está considerando es adecuada en relación a los riesgos que se han identificado.

Conclusión

La preventa de un proyecto juega un papel crítico en relación a la aceptación de un proyecto de desarrollo. El utilizar métodos adaptados de desarrollo de arquitecturas de software durante esta etapa no sólo es posible sino que es recomendable pues puede permitir que se establezca una solución más adecuada y se realice una mejor estimación. En la URL siguiente el lector podrá encontrar un video de la presentación que realicé este año en la conferencia SATURN 2014 y de la cual se deriva este artículo: http://goo.gl/5ZC8W4 .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)

.COLUMNA Invitada

¿Por qué Documentar el Código?

Cada cabeza es un mundo. Al ser individuos, todos los desarrolladores piensan diferente, por lo tanto un pequeño módulo de consultas puede desarrollarse de miles de formas distintas. Incluso se puede contraponer la lógica llegando al mismo resultado. Es por eso que comúnmente los programadores dicen: ”es más fácil que lo programe nuevamente a que lo modifique”. Según el sapo es la pedrada. Algunas personas tienen la errónea idea de que un módulo de consulta en una aplicación de escritorio se hace igual que en una aplicación web, o que un servicio web en la nube o incluso que en un dispositivo móvil. Sin embargo cada desarrollo está hecho con cierto propósito y con esos ojos debe analizarse, de otro modo se pueden asumir alcances y funciones que no se desempeñarán. Los cambios tienen impacto. Es común escuchar algo como: “es lo mismo, solo ponle estos campos más”. No hay nada más estresante para un desarrollador de software que hacerle entender a alguien que sus “pequeños cambios” son más complejos de lo que a él le parece, que no entiende la magnitud de lo que pide y que el sistema no se diseñó para lo que se le ocurrió y/o necesita ahora. Las personas no son eternas. Los seres humanos, incluidos los desarrolladores de software, no somos eternos. Sin llegar a hechos trágicos, es muy común la rotación de personal. Cada vez es más común la inclusión de freelancers en proyectos y éstos no están siempre disponibles para los cambios y mejoras; lo que da como resultado invertir mucho mayor tiempo en investigar, analizar y hacer ingeniería inversa, y ni mencionar el asegurarse que no se afecten otras secciones del desarrollo. El tiempo es la mejor forma de olvidar. ¿Alguien se acuerda de esa clase que hiciste tan increíble y perfecta que sabes que funciona de maravilla y que jamás has necesitado darle mantenimiento en los últimos tres años? Solo algunos privilegiados poseen memoria eidética y aun así es improbable recordar la lógica que se aplicó para hacer algo hace muchos años.

Un ejemplo

Imaginemos el siguiente escenario: se compra una casa que alguien construyó hace algunos años y se necesita conectar un lavabo a la línea principal del desagüe y no se tienen los planos de la casa. ¿Qué se tendría que hacer?, pues romper paredes y excavar hoyos hasta encontrar la línea principal del desagüe y a partir de ahí ver cuál sería la forma más simple de conectar el lavabo. ¿Qué pasaría si se decidiera poner una ventana?, se podría romper un cable y generar un corto, o romper una tubería de agua o un ducto de gas o simplemente afectar la integridad estructural de la casa. Cualquiera de estos posibles resultados genera un problema mayor a la mejora que se planeaba hacer en un principio. Como se puede apreciar, un pequeño cambio puede tener afectaciones demasiado grandes que no se pueden apreciar a simple vista. De lo anterior se podría asumir desde un punto de vista lógico que una buena documentación ofrece: • Garantías de un producto final de la mayor calidad. • Seguridad en el cumplimiento de los tiempos y costos del proyecto. • La confianza de que se determina el mejor proceso para desarrollar su producto. • Que el producto contará con la escalabilidad necesaria para seguir creciendo. Desgraciadamente algunos clientes no aprecian todas las bondades que ofrece un desarrollo de software con una correcta documentación. Por el contrario, cuando un desarrollador comete el error de mencionar que se cobra la documentación, se suele malinterpretar como un abuso, provocando este tipo de reacciones: ¿para qué necesitas documentar si yo te puedo decir todo? Recordemos que el desarrollo de software es una disciplina nueva y la gran mayoría de los desarrollos se realizan de forma artesanal, como algún misterio que solo pocos entienden y muchos menos pueden explicar. Documentar es la solución del misterio. A través de la documentación se logra que muchos entiendan lo que alguien desarrolló años atrás; y es solo una cuestión de tiempo, disciplina y educación al cliente para que se vea con buenos ojos cobrar por una correcta documentación, tal como hoy José Sánchez cuenta con más de 10 un arquitecto cobra por los años de experiencia desarrollando software. Sus áreas de especialización son planos de una casa. la administración de proyectos y análisis de negocio. José vive felizmente en Veracruz, México con su esposa.

>> José Sánchez 41

Software Guru

ucho se discute sobre la documentación en el desarrollo de software: que si se debe de seguir por cumplir con la metodología al pie de la letra, que si es una buena práctica, que si se debe de realizar solo en algunos casos; y hasta en algunos casos los detractores de esta práctica opinan que solo es pérdida de tiempo. Considero que la documentación es muy útil y necesaria. Para reforzar esta postura, analicemos los siguientes hechos:

www.sg.com.mx |

.COLUMNA Invitada

Carta a la Tía Margarita

DEL SOFTWARE PARA MEJORAR TU NEGOCIO

Nota del editor: El presente artículo fue originalmente publicado por Marco en su blog y lo hemos retomado con su permiso para publicarlo en esta edición de SG.

uerida tía Margarita (o estimado emprendedor que quieres utilizar aplicaciones de software para tu negocio y apenas sabes cómo encender una computadora): Me has platicado del éxito en tu negocio y me da mucho gusto pues has dedicado muchos años para lograrlo. Me dices de tus ahorros y de tu intención de invertirlos en un proyecto para mejorar tu negocio e integrarlo al mundo de las posibilidades ofrecidas por las nuevas tecnologías interconectadas cada vez de forma más ubicua a través de internet. Dices que es un proyecto inevitable si no quieres perder el éxito obtenido. Deseo con sinceridad que logres tus propósitos y te diré algo que yo pensaría si estuviera en tus zapatos. Nicholas Carr publicó en 2003 un ensayo titulado “IT Doesn’t Matter”que contiene algunas observaciones sobre por qué las tecnologías de información se han convertido en materia prima para los negocios y ya no representan un criterio determinante de diferenciación con respecto a su competencia. Desde entonces se ha visto que no le faltaba razón. Así que un objetivo modesto para tu proyecto sería colocarte a la par de otros negocios con proyectos similares, y para lograrlo quizá no se requiera crear nada nuevo sino tan solo adquirir una solución tecnológica ya existente. Si tal adquisición está en el alcance de tus ahorros, y satisface tus necesidades prioritarias, entonces esa podría ser una buena opción. De otro modo, si eliges un objetivo más ambicioso para diferenciar tu negocio, entonces deberás pensar en crear una solución a la medida de lo que necesitas. No digo que sea fácil adquirir e integrar algo existente sino que, en definitiva, la creación de una solución basada en software para problemas o retos de negocio representa palabras mayores en términos de complejidad. La organización Standish Group investiga cada año las estadísticas para este tipo de proyecto y publica los resultados de su sondeo en el ya tradicional Chaos Report. Según dicho reporte, la fracción de proyectos que cada año logran los tres criterios de éxito (con la funcionalidad esperada, en el tiempo planeado y con el costo planeado) gira alrededor de un tercio. Año tras año el reporte contiene una relación de los factores que Marco A. Dorantes es un consultor en el desarrollo reflexivo y cooperativo de contribuyeron a los resultados, en sistemas computacionales que retornan ganancias. Practica el diseño de sisesos factores deberás concentrar tu temas de cómputo digital desde 1987. atención. Suelo agruparlos en las Su principal interés profesional es la aplicación tanto de las teorías como de siguientes categorías: el perfil del las prácticas del pensamiento sistémico para la creación de soluciones de negopersonal involucrado, el proceso cio basadas en software. de creación, la estrategia de diseño http://mdmartin.blogspot.mx y la tecnología utilizada. Al consi-

derar su impacto sobre el resultado, los factores en cada categoría tienen un impacto superior comparado con el de los factores de la categoría sucesiva. Es decir, por ejemplo, si la estrategia de diseño es impecable pero no se cuenta con un proceso adecuado para realizarla entonces su impacto es marginal; lo mismo ocurre si el proceso es muy bueno pero no se tiene al personal que sepa cómo adecuarlo sobre la marcha ante el dinamismo de los negocios. Las personas y su capacidad para enfocar tanto ideas generales como detalles específicos, y comunicarlos efectivamente, representan el factor más determinante para el éxito de tu proyecto; empezando por ti misma. Te sorprenderá el nivel de detalle al que es necesario especificar los requisitos para que puedas en efecto verlos realizados en una aplicación tecnológica. Ahora, en cuanto a la selección del proveedor. Si el caso fuese una cirugía a cerebro abierto entonces buscarías al mejor neurocirujano que puedas conseguir. El caso de tu proyecto no es tan distinto si consideramos el tipo de esfuerzo intelectual y el nivel de esmero requeridos para el éxito. Lo propio del caso es asegurarte que tratas no sólo con administradores sino directamente con quienes tienen la capacidad para crear, con su mente y manos, las piedras angulares del proyecto; desde contribuciones al diseño de un modelo extendido de negocio, pasando por el diseño de la nueva interacción con tus clientes y proveedores, hasta los componentes técnicos de alta calidad que harán funcionar tu solución tecnológica. Todavía hoy predominan proveedores de servicios de software cuya organización se basa en un taylorismo postindustrial. Como sabes, para que aquel modelo pudiese funcionar, los trabajadores debían ser baratos y de muy bajo perfil intelectual, realizar trabajo mecánico repetitivo en una línea de producción y saber obedecer los estrictos dictados del grupo de administradores de la fábrica. Los factores para el éxito, cuyas categorías ya mencioné, son claves para entender qué tipo de actividad es crear software y cómo realizarla en proyectos comerciales privados o proyectos gubernamentales del dominio público. Formular software es una actividad reciente que inició hace unos sesenta años. Durante esta naciente etapa la industria del software ha adoptado opiniones ya caducas de la industria de manufactura de siglos pasados. Por ejemplo, la idea de división de trabajo; esta idea está detrás de puestos de trabajo como ‘analista’, ‘arquitecto’, ‘diseñador’, ‘programador’, o ‘tester’. Estos puestos coinciden con las etapas del modelo en cascada (secuencia lineal de etapas sucesivas) para el ciclo de vida del software: análisis, arquitectura, diseño, programación y pruebas. Quizá te sorprenda saber que Winston W. Royce, el supuesto inventor del modelo en cascada, jamás dijo que ese modelo funcionaría. De hecho, en su publicación original advierte en contra de 42

No quiero dejar de mencionar otros aspectos importantes del proyecto. Aspectos como un modelo extendido de negocio, que añada posibilidades distintas a tu modelo actual para interactuar con clientes y proveedores; el relevante papel del software como medio para conservar entendimiento; un modelo financiero para la solución tecnológica acorde al dinamismo de tu negocio y a las cambiantes condiciones en su entorno; y otros aspectos decisivos. En todos podrán entremezclarse las meras opiniones y el conocimiento confiable, por ejemplo: “un proyecto para crear una solución de negocio basada en software es igual a uno para hacer un edificio o un puente, y ambos se administran igual: al inicio hay un conjunto fijo de requerimientos, un costo total fijo, y un plan para todo el proyecto.” Si bien es cierto que los requerimientos, el costo y la frecuente planeación son muy importantes, también es cierto que, precisamente por dicha importancia, podemos lograr una mejor aproximación a esos aspectos por medio de procesos empíricamente controlados, y no sólo por medio de racionalizaciones prematuras. ¿Qué significa un proceso empíricamente controlado? Bueno, para comenzar, significa que un proceso no es controlado sólo por racionalizaciones «a priori», es decir, por imaginar el futuro con independencia de la corroboración de la experiencia —lo cual sigue siendo una tendencia mayoritaria en la industria de hoy, con grandilocuentes arquitecturas por anticipado, gráficas de Gantt expresadas en meses o años, y estrategias y tácticas para la gestión del riesgo basadas en el miedo. Por otro lado, un proceso empíricamente controlado surge de estrategias y tácticas «a posteriori» ejecutadas continuamente y en lotes pequeños. Un ejemplo de tales estrategias y tácticas se puede encontrar en ejecuciones musicales y representaciones teatrales. Si te interesa aumentar la medida de confianza en el éxito de tu proyecto, entonces «¡ensayar, ensayar, ensayar!» es un hábito esencial para lograr excelentes resultados tanto en representaciones teatrales como en la creación de soluciones empresariales basadas en software. Por ejemplo, la publicación de la solución tecnológica a tus clientes y proveedores es una parte crucial que necesitarás que resulte muy bien; por lo que ensayos realistas de ese procedimiento deben ser ejecutados, temprano y a menudo, antes de tocar al usuario final. Hay mucho, mucho más, que debes considerar para no ser parte de las estadísticas de proyectos fallidos o deficientes, donde los inversionistas obtienen muy poco o nada a cambio de su inversión. Con mucho gusto continuaré en la siguiente oportunidad.

>> Marco A. Dorantes 43

www.sg.com.mx |

intentar una secuencia lineal de etapas sucesivas. En años subsecuentes afirmó que su trabajo fue gravemente malinterpretado. Como verás, la actividad de creación de soluciones de negocio basadas en software tiene mucho por madurar como profesión y como industria. Su actual imagen de glamour se debe más al buen trabajo de publicistas y comerciantes oportunistas que a una ética profesional interna y madura. Por supuesto, esta industria debe financiar su proceso de madurez de sus propios bolsillos y no a costa de los ahorros de personas como tú; es decir, no permitas que malformadas opiniones sobre los factores críticos de éxito afecten el potencial resultado de tu proyecto. Necesitarás una estrategia para que tú misma te formes buenas opiniones de los factores críticos de éxito; una estrategia para distinguir entre conocimiento confiable y mera opinión. Pues en un tema de moda, como lo son las computadoras e internet, con mucha frecuencia las meras opiniones son las más vociferadas. Por eso, para pensar tu proyecto, no digo que logres la erudición en el tema sino que salgas del analfabetismo computacional. De otro modo tú misma serías un factor de riesgo para tu proyecto pues, con mayor facilidad, fomentarías interpretaciones erróneas de lo que significa el avance y los hitos que cimentan el éxito final; por ejemplo, si al inicio del proyecto exiges una calendarización de todo el proyecto y luego usas tal proyección para juzgar avances y retrasos entonces estarás midiendo cantidad de actividad pero no cantidad de progreso. Para no tropezar con preconcepciones y meras opiniones debes practicar tres hábitos del conocimiento confiable: la duda, la razón y la experiencia. Entre más destreza tengas ejerciendo esos hábitos más oportunidades tendrás de lograr cada vez mejores opiniones en el tema. Tal estrategia no es otra que la usada por ti misma para salir del analfabetismo en otras áreas de la vida. Lograr una mera opinión es algo muy fácil, basta con dejarse llevar por la corriente actual de la cultura popular, y esa facilidad revela, en parte, por qué son tan frecuentes. Los problemas inician por mantener y propagar una opinión obtenida de esa manera y, para agravarlos, por afirmar que tal opinión es propia y que debe defenderse —cuando ni es propia ni debe defenderse sino evaluarse. La mera opinión será para tu proyecto como la comida chatarra es para tu salud: dañina. Por otro lado, lograr conocimiento confiable implica un trabajo muy duro. En tu caso no hay motivo para amedrentarse pues ya estás acostumbrada a ese tipo de trabajo; asimismo, ¿cómo podrías justificar el apego a una mera opinión si tú no eres un caso desesperado sin recursos ni salud?

Software Guru

.COLUMNA Invitada

.COLUMNA Código Innovare

Estrategia, Portafolio y Proyectos D

urante los últimos tres años (de 2011 a la fecha) he tenido la oportunidad de participar en una Comunidad de Práctica (CoP) que se enfoca en temas de planeación estratégica. Cada trimestre se comparten experiencias que provienen de cada una de nuestras organizaciones. Uno de los atractivos de la comunidad, es la naturaleza distinta de cada una de nuestras entidades: banca, entretenimiento, laboratorios farmacéuticos, industria automotriz, tecnologías de información, consultoría de negocios, gobierno, solo por mencionar algunas. Asimismo, otro punto a destacar son los distintos niveles de madurez en que nos encontramos, yendo desde quienes recientemente están impulsando la práctica hasta aquellos que han logrado profundizar y consolidar la misma, donde algunos incluso se han hecho merecedores a reconocimientos como empresas que han logrado demostrar que el ejercicio de la planeación estratégica efectivamente es un diferenciador que les ha permitido alcanzar de forma exitosa las metas que se han propuesto. Bajo esta línea de capitalizar experiencias prácticas e intercambiar ideas, afloran puntos de reflexión que comparto con ustedes. Son temas que se desprenden de nuestra misma historia que muchas veces resulta común y que adopta diferentes matices dado el contexto de cada organización.

Selección del portafolio de proyectos

Una vez que hemos definido nuestros objetivos estratégicos por perspectivas, más las metas e indicadores que estaremos considerando para dar seguimiento al avance, es indispensable identificar cada una de las iniciativas que se plasman en proyectos para que los objetivos estratégicos puedan ser una realidad. Justamente en este ejercicio, damos paso a la integración del portafolio de proyectos estratégicos. Es común, como resultado inicial, contar con un volumen de iniciativas que rebasan la capacidad de la organización para llevarlas a una fase de ejecución. Como razón de peso que delimita la frontera hasta dónde podemos abarcar, tenemos la disponibiliArmando Peralta Díaz es Director dad de recursos financieros, los Adjunto de Competitividad en INFOTEC , que es un centro de investigación cuáles de forma natural tienen e innovación en Tecnologías de la Información y Comunicación, adscrito establecido un techo. Aquí el al Consejo Nacional de Ciencia y Tecnología (CONACYT). Es autor del libro reto, consiste en seleccionar las “Punto Máximo”, que es una guía rápida iniciativas que mejor apuntalen para la gestión de proyectos y está por publicar un nuevo libro en torno al tema la estrategia de la organización, de “Agrupamientos industriales y tecnologías de la información en México”. teniendo en consideración los armando.peralta@infotec.com.mx distintos “business drivers” que

son relevantes para el negocio. No obstante, nos encontramos que en muchas ocasiones, el “arreglo institucional” impacta en que internamente las áreas pujan para que sus iniciativas salgan adelante y sean seleccionadas, pesando más los intereses particulares de las áreas que la estrategia institucional. Para facilitar el proceso de selección, cada iniciativa debe de contar con el respaldo de la elaboración de un “caso de negocio” que aporte los elementos técnicos, económicos y financieros. Sin embargo, la falta de rigor en este rubro, determina que la iniciativa tiene como soporte el bosquejo de una “idea”, limitando la toma de decisión o bien proceder a la toma de decisión sin contar con todos los elementos que verdaderamente la justifiquen. La estructuración del portafolio de proyectos de corte estratégico representa para la organización, dejar atrás prácticas donde cada directivo impulsa sus iniciativas para obtener su aprobación, o bien, asumir que muchas iniciativas deben dejar de ser del conocimiento exclusivo de las áreas. El reto ahora, es dar “visibilidad” y transparentar de manera que cada uno de los proyectos se encuentran alineados a la estrategia; que la organización en su conjunto tenga una visión de equipo de cual es el esfuerzo que se está desplegando.

Administración de proyectos incipiente

Muchas de las organizaciones que hoy se encuentran ejecutando esfuerzos de planeación estratégica, cuentan con un área dedicada a la planeación estratégica y otra área especializada en la gestión de proyectos (Oficina de Administración de Proyectos) lo cual pudiéramos observar como una buena solución que suma de manera positiva. El punto crítico en este apartado, es que en otros casos, ante la ausencia de una Oficina de Administración de Proyectos, las áreas ejecutan los proyectos una vez seleccionados, con recursos que se asignan de tiempo parcial o bien que no tienen las competencias técnico-profesionales, lo cual no arroja los mejores dividendos: atrasos, seguimiento y control laxo, ausencia de sistemas de control de cambios, entre otros que impactan desfavorablemente los resultados del portafolio. Si se observa con detenimiento, este es un punto que corresponde a la “ejecución”, la cual es foco de análisis de muchos especialistas, quienes normalmente la abordan bajo perspectivas que enriquecen su entendimiento. La ejecución resulta clave, ya que nos permite avanzar y dar cumplimiento a las metas de mediano y largo plazo. En caso contrario, nos enfrentamos al reto de no poder profundizar y consolidar el ejercicio de la planeación. Es difícil dar alcance y proyección 44

Equipo de la alta dirección más orientado a la operación

Una vez que las organizaciones abrazan la planeación estratégica, resulta crucial el involucramiento del cuerpo directivo ya que ellos son los actores principales para que la planeación estratégica pueda ser desdoblada hacia toda la organización. En ese sentido, los directivos deben ser cuidadosos de que los temas de la operación que muchas veces los envuelven en el día a día, no sea motivo para dar la espalda al sistema de gestión que requiere liderazgo y dedicación para integrar la estrategia y las operaciones. Una vez que ya nos encontramos en la fase de la ejecución, se requiere considerar la disciplina de llevar a cabo de manera periódica revisiones operativas y revisiones estratégicas las cuales son fuente directa para obtener retroalimentación y aprendizaje. Esta es una exigencia que en la medida que el cuerpo directivo la descuida, afecta la trascendencia de la planeación.

La ausencia de una oficina de gestión de la estrategia

Hemos mencionado, la importancia de contar con una Oficina de Administración de Proyectos, como una instancia que forma parte de la estructura orgánica, que coadyuva favorablemente en la gestión del portafolio de proyectos. Ahora, destacar que de las organizaciones que confluyen en la Comunidad de Práctica de la cual hemos hecho mención al inicio de este artículo, todas, invariablemente, cuentan con una Oficina de Gestión Estratégica. Aporta como valor, tomar roles específicos a nivel de los procesos de la gestión estratégica. Dentro de sus principales roles, está la de asumir el diseño de la arquitectura de la gestión estratégica en la organización, debiendo trabajar en el diseño del proceso que la acompaña. De igual forma, se convierte en el “pivote” para que la organización en su conjunto desarrolle y planifique la estrategia, alentar que la organización se alinee para seguir de manera puntual que la estrategia tome lugar y aplicar las adaptaciones que se requieran. También la Oficina de Gestión Estratégica toma roles de integración con los aspectos operativos y de soporte que va exigiendo el mismo despliegue de la estrategia (asignación de recursos, pre-

supuestos, recursos humanos, sistemas de información) y roles que apuntan hacia la consolidación y alcance de mayores niveles de madurez, tales como: la comunicación de la estrategia y la difusión de las mejores prácticas. Como puntos críticos que giran en torno a la Oficina de Gestión Estratégica, tenemos: patrocinio que se recibe desde la dirección de la organización; ubicación dentro de la estructura orgánica; nivel de retroalimentación y aprendizaje que se brinda a la organización. El patrocinio y la ubicación de la Oficina de Gestión Estratégica, son temas que van de la mano. Conforme la cercanía a la dirección de la organización sea mayor, en el mismo sentido será el patrocinio que se reciba y también una mayor visibilidad, lo cual en las organizaciones jerárquicas toma fuerza. Cuando el patrocinio y la cercanía se encuentran del lado de la oficina, tenemos un escenario donde la gestión estratégica contará con un entorno que la favorece tanto en su desarrollo como principalmente en su ejecución. Un punto donde las Oficinas de Gestión Estratégica muchas de las veces necesitan poner un mayor empeño, es en la retroalimentación y aprendizaje que deben proporcionar al resto de toda la organización. El mayor empeño, radica en la parte analítica de ir monitoreando hacia dónde se dirige el negocio ya que están posicionados en lugar privilegiado. Desafortunadamente, la ejecución demanda muchas energías que limita esta capacidad de ir marcando las pautas estratégicas. Ya para terminar, quisiera agregar, que la gestión de la estrategia va más allá que la simple integración de procesos, métodos, y herramientas, es indispensable contemplar el tipo de estructura vigente en cada organización, la cultura organizacional y el recurso humano disponible que determina el nivel de madurez en que nos encontramos y de allí reconocer cuál es la brecha a cerrar en el futuro. Dado a que el desempeño de la organización es dinámico y a que la gestión estratégica enfrenta diversos retos que pueden limitar sus resultados, es recomendable incorporar la gestión de riesgos y alinearla con la estrategia. Con ello, sin importar en qué nivel de madurez nos encontremos, estaremos en condición de identificar eventos potenciales que puedan afectar a la organización y gestionar el riesgo dentro de los límites del apetito por el mismo, con lo cual estaremos en condición de proporcionar una seguridad razonable sobre el logro de los objetivos estratégicos.

>> Armando Peralta 45

www.sg.com.mx |

a nuestra estrategia cuando no somos capaces de alcanzar con éxito nuestras iniciativas estratégicas en el corto plazo. Los bajos resultados, nos llevan a reprogramar o cancelar iniciativas que nos restan fuerza para asumir nuevos retos.

Software Guru

.COLUMNA Código Innovare

.COLUMNA Programar es un Modo de Vida

La Enseñanza

Y LO GENERATIVO DE LA COMPUTACIÓN

scribo el presente artículo en octubre de 2014. Resuenan aún fuertes los ecos del inicio del ciclo escolar, hace apenas poco más de un mes, y por la radio siguen sonando los anuncios de la SEP presumiendo al Programa de Inclusión y Alfabetización Digital — particularmente, acerca de la entrega de tabletas a todos los alumnos de 5° de primaria [1] en esta primera etapa en los estados de México, Colima, Sonora, Tabasco, Puebla y el Distrito Federal. Según la información que pude encontrar, esto significa la entrega de unas 700 mil tabletas, con un costo aproximado de 1,400 pesos cada una. No me corresponde hablar acerca del contenido desarrollado y cargado en estos equipos, dado que se aleja por completo de mi campo de conocimiento. Quisiera, sin embargo, aprovechar este espacio para compartir con los lectores de SG dos interesantes textos al respecto publicados por Luis Felipe Lomelí — y agregar algunas apreciaciones respecto a la potencialidad que estos equipos podrían presentar — y, como están planteados, no presentan. Lomelí publicó dos columnas en el sitio de periodismo digital sinembargo.mx: la primera el 24 de septiembre, titulada “Tabletas SEP: impacto ambiental” [2] y la segunda, el 1° de octubre, “Tabletas SEP: ¿mejoran la educación?” [3]. Recomiendo su lectura a quienes se interesen en profundizar en el tema; la primera comienza a rascar en dirección de un (necesario) estudio riguroso acerca del impacto ambiental que tendrán, una vez que el programa llegue a un despliegue pleno en el país, millones de equipos de cómputo con un tiempo de vida –siendo optimistas– de tres años; la segunda habla acerca de las ventajas y desventajas para el proceso enseñanza-aprendizaje del uso de estos equipos. Fue esta segunda columna la que me llevó directamente a abordar este tema.

La generatividad

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

No repetiré las reflexiones que Lomelí ya hizo. Más bien, me interesa continuar del texto al que hago referencia, y unirlo con otro tema al que llevo largo rato acercándome: el cambio en la generatividad de las herramientas de cómputo. Este planteamiento tampoco es mío de origen: en 2008, Jonathan Zitrain publicó el libro “The future of the Internet and how to stop it”; que está disponible para su lectura en línea [4]. Zittrain presenta el concepto de la generatividad, y argumenta acerca del por qué la existencia misma tanto de las computadoras personales como de internet: la principal razón por la que tanto las computadoras personales

como la “red de redes” pudieron crecer y adaptarse desde sus orígenes, limitadas e incompletas como estaban, hasta lo que son hoy en día: es que son plataformas abiertas, pensadas para que sean los usuarios quienes desarrollen, dicten y creen sus contenidos. Las computadoras personales presentaban una interfaz general, y sus usuarios necesariamente aprendían por lo menos los rudimentos de algún lenguaje de programación; internet, inicialmente creado como un proyecto del Departamento de Defensa de los Estados Unidos, fue desarrollando todos sus protocolos (y definiendo su funcionalidad y desarrollo) a través de documentos públicos, conocidos como RFCs (Request For Comments, solicitud de comentarios). Y desde el nivel mismo de la interfaz física: Una tableta ofrece algunas características atractivas. Sin partes móviles, compacta, y actual. Sin embargo, es claramente un dispositivo para consumir medios. Hay programas que permiten escribir, dibujar, y hasta cierto punto crear… Pero una tableta sencillamente ofrece una interfaz muy limitada para la exploración creativa.

El contenido educativo

Como ya lo dije, yo no soy la persona adecuada para hablar acerca de la idoneidad del contenido educativo precargado en las tabletas que repartió la SEP. Sin embargo, y haciendo eco de la columna que publiqué hace dos años aquí mismo [5], conviene preguntarnos qué es lo que buscamos al introducir la tecnología a las aulas. La propuesta actual de la SEP emplea tabletas: computadoras de interfaz muy sencilla, fáciles de emplear, y orientadas a administrar el contenido diseñado centralmente, ayudando a facilitar el aprendizaje de otras materias. Y sí, esto brinda lateralmente la oportunidad de emplear las tabletas para el entretenimiento: son, a fin de cuentas, dispositivos Android bastante estándar, esto es, todas las aplicaciones disponibles por Google Play. Y en este planteamiento radica parte importante de lo que se puede criticar a este proyecto: Los teléfonos inteligentes y las tabletas presentan todos interfaces ricas e interactivas para el consumo de medios, pero están naturalmente limitados para fomentar su creación, y más aún, cosa que deberíamos fomentar en nuestros niños, su apropiación — concepto fundamental al que volveré en breve. Queda claro que la idea de incorporar a las “nuevas tecnologías” a la enseñanza no es, redundemos, muy nueva que digamos. Para contrastar modelos, ¿cómo se presentaban las computadoras como auxiliar pedagógico hace veinte, treinta o cuarenta años? En la columna presentada en SG #38 argumento que el acercamiento al cómputo era presentado como una forma de pensar, como una forma de estructurar las ideas para explicarle a la computadora los pasos que debería seguir — y por qué eso debería verse como parte de las habilidades cognitivas básicas que son 46

.COLUMNA

Apropiación tecnológica

Apropiarse de la tecnología va mucho más allá de ver a una tableta como parte de las herramientas para realizar nuestro trabajo: Apropiarse de ella implica intimar con la tecnología: Perder el miedo para conocer sus secretos, su funcionamiento, la manera en que cada uno de los niños puede modificarla para que haga lo que él o ella quiere, y no sólo lo que está programada para hacer. Volvemos a la generatividad. Este concepto va más allá de lo que presenté hace dos años: No sólo es aprender a programar, sino que es poder moldear a la herramienta en particular. No sólo es aprender a programar en juguete, sino reconocer que eso que me enseñan puede tener impacto, repercusión real, sensible con las herramientas que uso a diario. No sólo poder bajar las apps (los jueguitos) que quieran, sino que poder desarrollarlos y modificarlos. Sí, este planteamiento puede sonar iluso e imposible. A fin de cuentas, quien escribe estas líneas se asume a sí mismo como ruido estadístico. La generación, como nos describí en la columna de hace dos años, de los hijos de Logo fuimos muy afortunados: No sólo nos tocó conocer al mundo del cómputo cuando éste era suficientemente sencillo como para que fuera posible para un niño comprender buena parte de los procesos que sucedían al interior de la computadora, sino que tuvimos la suerte de que nuestros padres tuvieran la sensibilidad de ofrecernos formación en cómputo cuando definitivamente no formaba parte de lo normal en la sociedad. Por excluyente que suene, es la realidad: Tuvimos la suerte de crecer en una familia –por lo menos– de clase media, que fuere como fuere tuvo la posibilidad de brindar acceso a una tecnología excepcional. No podemos perder de vista que el programa que ahora instrumenta la SEP está enfocado no a unos cuantos niños afortunados, sino que –en este momento– 700,000 niños en cinco estados y el Distrito Federal, y se espera que en los próximos años se extienda a todos los niños de quinto de primaria.

OLPC y Sugar

Sin embargo, la masividad del programa no se contrapone con un enfoque más integral. No podemos olvidar que el planteamiento original de proyectos tan ambiciosos como OLPC (One Laptop Per Child, Una Computadora por Niño) [6] puso como condición desde su punto de partida que sólo operaría a gran escala.

Recordemos que el proyecto OLPC nació en 2006, hace ya casi una década. Su impacto ha sido enorme: Resultó tan fundamental para proyectos como el de la SEP como la mera idea de dar equipos de cómputo en propiedad a los alumnos en vez de crear aulas digitales en las escuelas. Pero más allá de su modelo de distribución o el diseño de computadoras aptas para el trato que les darían los niños, el verdadero corazón de OLPC es el entorno de aprendizaje Sugar [7]. Partiendo de que los niños no son oficinistas, es un entorno orientado a actividades de aprendizaje, y con una fuerte carga constructivista: El niño no se enfrenta con las aplicaciones como cajas negras y cerradas definitivamente, entregadas como parte de un artefacto mágico y sellado, sino que se espera que las exploren — no solamente como usuarios, sino que desde su construcción, desde su código. Prácticamente todo puede ser tocado, modificado, y los niños pueden aprenden a moldear la herramienta a sus intereses. Claro está, sería demasiado triunfalista de mi parte cerrar esta columna implicando que OLPC y Sugar son el non plus ultra, el modelo a seguir para llevar la apropiación del cómputo a las aulas de nuestro país. OLPC tuvo severos problemas desde el primer momento, y su existencia no ha sido simple. Si bien las cifras que brinda su sitio son muy felices, son a fin de cuentas cifras agregadas de muchos años, y no todos los equipos que presumen están en operación hoy en día. Tampoco puede obviarse la importancia de brindar una adecuada y recurrente capacitación a los docentes, a quienes una herramienta generativa resultará un reto mucho más complejo que una simple terminal. Y, claro, la complejidad del aparato burocrático-educativo en nuestro país no es para ser despreciada. El importante paso que da la SEP es en la dirección correcta. Sólo resta esperar que el seguimiento que, en futuras ediciones, en futuros sexenios se dé a lo que ahora se está ensayando implique una verdadera apropiación.

>> Gunnar Wolf Referencias [1] http://www.primariatic.sep.gob.mx/ [2] http://www.sinembargo.mx/opinion/24-09-2014/27542 [3] http://www.sinembargo.mx/opinion/01-10-2014/27750 [4] http://futureoftheinternet.org/ [5] Programación en la Escuela: ¿Para qué?, http://sg.com.mx/revista/38 [6] http://one.laptop.org/ [7] http://sugarlabs.org/

www.sg.com.mx |

transmitidas a los niños a lo largo de su proceso formativo. Esto es, en la década de los ochenta la computación era presentada a los niños no sólo como la herramienta que se usaría para la transmisión del conocimiento, sino que como un área de conocimiento por sí misma, misma que podría potenciar nuestro desarrollo en todas las demás áreas.

Software Guru

Programar es un Modo de Vida

.COLUMNA

Invitada

Cuando el Big Data y el Internet de las Cosas Colisionan

l debate en torno al Big Data no cesa, y al mismo tiempo ha emergido el término Internet de las Cosas (Internet of Things o IoT por sus siglas en inglés), que ha irrumpido en numerosos círculos donde habitualmente se analiza la actualidad de la gestión de la información. El Internet de las Cosas ha eclosionado debido al crecimiento imparable del número de sensores que hoy día se embeben en cualquier cosa, desde nuestros dispositivos móviles hasta la infraestructura tecnológica que nos rodea, pasando por la ropa que vestimos. Avanzamos hacia un futuro en el que los objetos inteligentes pueden detectar el entorno en el que se encuentran, e interactuar no sólo con sus propietarios, sino incluso entre ellos. Los datos procedentes de las máquinas supondrán, en el corto plazo, el mayor flujo de información que aglutina internet, y, por ende, el mayor proveedor para los sistemas de Big Data.

Fenómeno sin precedentes

La evolución hacia este nuevo paradigma digital no tiene precedentes: Gartner considera que en 2020 más de 30 mil millones de dispositivos estarán conectados a internet — comparados con los cerca de 2,5 billones de 2009—. Hasta la fecha, por dispositivos hemos entendido principalmente PCs, tabletas y teléfonos móviles; pero en 2020 la amalgama crecerá notablemente en torno a todo tipo de sensores o tecnologías basadas en etiquetas RFID. La disponibilidad de esta información nos permitirá monitorizar cualquier cosa que nos imaginemos, desde el consumo de energía al tráfico. El Internet de las Cosas no es una tendencia tecnológica más. Para muestra de ello, dos datos extraídos de un informe reciente de The Economist: 95% de los directivos encuestados han afirmado que apostarán en sus compañías por el IoT en un plazo máximo de tres años; mientras que 63% considera que las organizaciones más lentas en la implantación de esta tecnología se quedarán atrás.

Manuel del Pino es Manager de Preventa en Information Builders Ibérica. Es especialista en business intelligence y analítica, integración y calidad de la información, así como en tendencias relacionadas como el Big Data, las redes sociales, la movilidad o la nube. manuel_delpino@ibi.com

Capitalizar la información

Al tiempo que el Internet de las Cosas genera el mayor volumen de datos nunca antes visto, también emerge la oportunidad de capitalizar en información todos estos datos, hasta el punto de que los nuevos negocios crecerán a la luz de la comercialización de dicha información. Si bien no se tratará de un avance trivial; estas compañías en un primer paso, habrán de asir el torrente de datos proveniente de millones de potenciales fuentes que aparecen y desaparecen; y, a continuación deberán emplear las soluciones necesarias para almacenar, organizar y aplicar técnicas de business analytics para transformar los datos en información de valor. Empleo el término business analytics en lugar de simplemente analytics, ya que sólo es posible extraer de los datos información real si los situamos en un contexto de procesos y modelos de negocio. Enfatizar el Internet de las Cosas proporcionará una fuente adicional de datos para optimizar los negocios, pero siempre si los vinculamos con otras fuentes de información como los data warehouses o las aplicaciones operacionales. Además, se habrán de canalizar todas las estrategias de datos maestros procedentes de cualquier tipo de fuente, ya sea máquinas, aplicaciones o seres humanos. El business analytics no sólo radica en computar la información correcta, sino también en posibilitar al consumidor de esa información un acceso sencillo a los datos que necesita. De manera similar, el Big Data que se compone de datos tanto estructurados como desestructurados, debe dotar al usuario de todas las facilidades posibles para que su acceso sea transparente en la medida de lo posible. El denominado enterprise search (búsqueda empresarial) es el paradigma más común para explorar los datos desestructurados, mientras que las herramientas más tradicionales de business intelligence se manejan mejor entre los datos estructurados. Sólo aquellas soluciones que emplean una plataforma informacional capaz de integrar el business intelligence con el enterprise search a través del big data y otras fuentes de datos podrán atender de manera óptima las necesidades del futuro consumidor de información.

>> Manuel del Pino 48

.COLUMNA Invitada

Más Allá del Software: Cuestionamientos y servicios

Comencemos con la típica labor de analizar la idea del producto y considera las siguientes cuestiones: • ¿Qué necesidad atenderá el producto?, ¿quién es el cliente final del producto? (no quien paga por él, sino el cliente de su cliente). • ¿A qué sector del mercado pertenece el cliente al que se atenderá?, ¿qué caracteriza a ese sector de mercado?, ¿qué le gusta o disgusta a ese sector? • ¿Qué tipo de servicios deberías ofrecer con tu desarrollo de software? • ¿Que modelo de licenciamiento es el indicado para tu software? • En caso de hacerse disponible bajo distintos modelos de licenciamiento, ¿qué necesitas como diferenciador entre uno y otro tipo? ¿Requieres algún control para responder a cada esquema? • Si fuera gratis ¿como obtendrás el retorno de tu inversión? ¿Debería tener algún esquema de comercio interno? ¿Venderá solo servicios asociados? • ¿Tienes los medios o interés para ofrecer los servicios relacionados tú solo, o debes buscar aliarse con alguien más? ¿Sería un esquema de mercados compartidos una buena opción? • Si decidieras no atender todos los servicios y compartir mercado, ¿cómo elegirías a tus aliados? ¿Qué ofrecerles como un esquema de negocio atractivo?, ¿cómo se asegu-

Planear servicios de forma paralela al desarrollo

Una vez aclarados los puntos anteriores, considera que tu proyecto de desarrollo de software deberá incluir actividades paralelas que permitan el desarrollo de servicios, de forma que ambos estén concluidos lo más cercano posible y no tengas la necesidad de esperar a concluir los servicios demasiado tiempo después de terminar tu código. Pero sin presionar actividades que necesitan tener un producto casi terminado para poderse realizar, como pudieran ser “manuales de usuario final” o “cursos de capacitación” o “listados FAQS y troubleshooting”, pues puede haber características que se incluyan o eliminen en la versión final. Aspectos que no puedes dejar para el último momento son la propiedad intelectual y derechos de autor. Considera que estos trámites legales tienen tiempos largos y no querrás esperar a terminar tu producto para realizarlos, pues pueden retrasar innecesariamente el lanzamiento y con ello los periodos de recuperación de las inversiones que hayas realizado. Motivo por el cual es recomendable que registres debidamente el nombre del producto, logotipo y demás características distintivas que sean parte de tu imagen comercial, incluso en las etapas iniciales de tu proyecto para asegurar que al concluir el mismo, ya tenga o esté próximo a contar con la protección de tu capital intelectual. No olvides que deberás además realizar el registro del código del producto, pues una cosa es la marca comercial y otra el contenido del código de tu producto, y ambos deben estar registrados y protegidos.

>> Víctor Hernández Victor Jesús Hernández Salinas es Coordinador de Servicios de Productos en INFOTEC. Es Licenciado en Sistemas de Computación Administrativa por la UVM. Desde 2003 colabora en INFOTEC en el equipo de Desarrollo de Nuevos Productos y Servicios. Fue creador y Coordinador del área de servicios a producto y su normatividad. Es además coordinador del programa de certificaciones para SWB. Ha impartido conferencias sobre Web Semántica, Ciudades Digitales y Servicios a Producto en diversos foros, participado en mesas redondas gubernamentales y publicado artículos en diversas revistas y sitios web.

Software Guru

Cuestionamientos

rará de que tus aliados hacen el trabajo adecuadamente y no desprestigian tu marca?

www.sg.com.mx |

odos hemos tenido una idea que creemos será la panacea que revolucionara el mundo, y la mayoría lamentablemente la dejamos de lado y solo unos cuantos siguen adelante. Sin embargo las muestras de coraje y entusiasmo no son los únicos ingredientes que se necesitan para lograr que un producto sea exitoso. Y con “producto” me refiero a la solución completa: desarrollo de software más servicios, pasando por todas las etapas; desde la concepción hasta el lanzamiento y desde la promoción hasta el periodo de postventa y evaluación de satisfacción del cliente. La intención de estas líneas es ayudarte a tener una idea del panorama general de los distintos elementos a considerar mientras realizas la construcción de esa visión revolucionaria que es tu producto.

.COLUMNA

Invitada

¿Cómo Sobrevivir a un Proyecto en Gobierno?

os proyectos de TICs en el sector gobierno típicamente son desgastantes. Así que después de haber vivido varios de estos, surge la pregunta… ¿hay una mejor manera? Ningún proyecto es igual, así como ninguna institución es igual a otra. Aún así, espero que la información presentada aquí sea útil para quienes se embarcan en proyectos de TIC con gobierno.

Estructura del gobierno

Lo primero de lo que hay que estar consciente es que —al menos en México— existen 3 niveles de gobierno: municipal, estatal y federal. Es importante resaltar que no hay una línea de autoridad entre el presidente de un municipio, el gobernador del estado donde se encuentra dicho municipio, y el presidente de la nación. Adicionalmente, los niveles estatal y federal están divididos en 3 poderes: Judicial, Legislativo y Federal. Todo esto es trascendente ya que genera una gran cantidad de combinaciones y contextos posibles.

Particularidades

A continuación menciono algunas particularidades del sector público que hay que tener en cuenta al participar en proyectos de este tipo: 1. Cualquier entidad, institución u organización pública, está sujeta a un marco regulatorio específico, y debe de crear “valor público”. 2. Por cada nivel de gobierno hay una planeación estratégica que es creada por una Dirección dentro de dicho gobierno. 3. Existen Programas Gubernamentales (como PROCAMPO y PROSOFT), mediante los cuales se pretende lograr objetivos y metas a mediano y largo plazo. 4. El sector gobierno tiene su propia “jerga” de palabras, o más bien dialecto. Es importante comprender no solo el significado de la palabra o acrónimo, sino sus implicaciones, tiempos y contextos. 5. Debe de existir transparencia y rendición de cuentas, además de un escrutinio tanto de los ciudadanos como de diversas entidades fiscalizadoras.

¿Qué ocurre en México?

La buena noticia, al menos en el caso del ejecutivo federal, es que los proyectos de TICs deben gestionarse de acuerdo al PMBoK del PMI. La mala noticia, es que no existe el conocimiento sintetizado sobre prácticas recomendadas en proyectos de gobierno. Así que a continuación menciono alguno de los aspecHéctor Santillán cuenta con 25 años de experiencia profesional como consultor, dedicando los últimos 12 años a la Administración Pública Federal. Sus áreas de especialidad incluyen arquitectura de procesos de negocios, mejora contínua, modelos de referencia y gobernabilidad.

tos más importantes a considerar: 1. Gestión de múltiples partes interesadas, que incluso pueden ser externas a la institución. De repente, descubrimos que existen muchas más partes interesadas de las que suponíamos. 2. Adaptación al cambio político. En el sector público es común que haya cambios repentinos en los niveles directivos, lo cual suele afectar a los proyectos. 3. Entendimiento de la política local, lo cual no solo se debe de entender de la “política”, sino de usos, costumbres y requisitos a satisfacer, muchos de ellos normativos o por disposición de alguna otra área. 4. Preparación al escrutinio. Es muy importante tener en mente que lo que se hace, estará bajo escrutinio. Además, por la naturaleza pública de las organizaciones, el escrutinio puede llegar previo, durante y posteriormente, incluso desde el extranjero. 5. Justificar la creación del valor público, es decir cómo el proyecto contribuye a la entrega de valor al ciudadano. Este valor no requiere ser económico.

Consideraciones

Al iniciar un proyecto de TIC con gobierno, hay que tener en cuenta los siguientes aspectos: • Conocer bien quién es el patrocinador del proyecto. No necesariamente es el área de tecnología, también podría ser el titular del área responsable del sistema, o superior. • Asegurar que es viable contar con la información inicial para arrancar el sistema. • Considerar el esfuerzo que implica la adopción de un nuevo sistema informático. Esto puede involucrar la capacitación a servidores públicos en distintas localidades. Otras consideraciones importantes incluyen: • El contexto jurídico observable, • La claridad respecto al proceso que va a soportar el sistema informático, • La identificación de todas las partes interesadas, • El entendimiento respecto al ciclo completo de vida del proceso, • La viabilidad de introducir cambios respecto a la normatividad vigente, • Las formas y costumbres propias del área o institución. Por último, recuerda que en la administración pública se audita el dinero gastado, con una visión de conformidad al marco normativo aplicable y las disposiciones vigentes. Esto puede llevar a situaciones complejas en donde se logró el resultado pero al no observarse las reglas puede haber una sanción.

>> Héctor Santillán

.COLUMNA Invitada

Cómo Aprovechar la Arquitectura Empresarial en la Administración de Proyectos de TIC

Como se puede observar, el impacto en el concepto de Arquitectura Empresarial es diverso y no solo está centrado en la documentación de una infinidad de mapas, planos o artefactos que definen cada capa de la organización, o como una herramienta para lograr una arquitectura orientada a servicios. Por el contrario, es una herramienta que se puede utilizar para la alineación de las TIC con el negocio y con la estrategia, para dimensionar y planear un proyecto o como un mecanismo de comunicación entre los diferentes involucrados que coadyuva en la concepción de una visión compartida del proyecto. Los administradores de proyectos y los ejecutivos de las organizaciones deben romper el paradigma que centra la Arquitectura Empresarial como una herramienta de los responsables de la unidades de TIC, y en su lugar apreciarla como un mecanismo que les permitirá hacer mejor las actividades de planeación estratégica, programación y administración de proyectos de TIC.

>> Oscar Gutiérrez Rodríguez Oscar Gutiérrez Rodríguez es Ingeniero Mecánico Electricista especializado en el área de Ingeniería Industrial. Durante los últimos 4 años ha sido responsable de la Subgerencia de Consultoría de Negocio de la Dirección Adjunta de Competitividad en el INFOTEC, así como de las especialidades y el portafolio de servicios de Planeación Estratégica, Gestión de Procesos de Negocio, Inteligencia de Negocio, Arquitectura de Negocio y Arquitectura Empresarial.

Software Guru

Figura 1. Estructura del marco VIA INFOTEC.

www.sg.com.mx |

no de los retos que tienen las organizaciones al hacer inversiones en TIC, es asegurar los resultados y el impacto que éstos generan al negocio y la estrategia de la organización, por lo que es necesario que se alinien a sus necesidades y al cumplimiento de los objetivos estratégicos, además de maximizar la relación costo-beneficio de la inversión. El marco de Arquitectura Empresarial permite mejorar el desempeño de los programas y proyectos al seguir un modelo de capas sucesivas de intervención, desde el nivel de la estrategia del negocio hasta el nivel de la infraestructura de TIC. INFOTEC plantea en sus proyectos el uso del marco VIA INFOTEC, que consiste en siete capas horizontales y dos verticales, por medio de las cuales y sus interrelaciones es posible contextualizar los proyectos dentro de la organización, identificando todos sus aspectos e impactos (ver figura 1). Dicho marco establece como principio fundamental la vinculación y transformación de las capas de la organización en propuestas de solución integradas para obtener los resultados deseados. La utilidad del uso del marco de Arquitectura Empresarial en la administración de proyectos de TIC consiste en contextualizar el proyecto en el ecosistema de la organización, con el fin de establecer adecuadamente el alcance, los riesgos, las condiciones, las restricciones y las oportunidades que cada proyecto conlleva. En este nivel no se pretende modelar y documentar cada una de las capas, la recomendación es contar con los elementos necesarios para realizar una planeación, ejecución, seguimiento y cierre del proyecto en un enfoque integral y estratégico. Cuando identificamos la capa en la que se centra el proyecto, podemos determinar la interrelación que tiene con las otras capas dándonos una visión global de los aspectos que generarán el éxito. El modelo también nos permite identificar a los grupos de interés del proyecto, que es un aspecto fundamental en la gestión, ya que podemos saber quién es el usuario final y quienes se verán afectados positiva o negativamente; así mismo permite formalizar la gobernabilidad al poder precisar los actores que conforman el grupo estratégico y el grupo táctico-operativo para delimitar la toma de decisiones y las acciones necesarias para alcanzar los objetivos del proyecto. Además, podemos reconocer los procesos que se verán afectados en los diferentes niveles (estratégicos, sustantivos, de apoyo y de TIC), lo que permite definir la estrategia de intervención y administración del proyecto, sin dejar supuestos o cabos sueltos.

.INFRAESTRUCTURA

La Importancia de la Arquitectura de Soluciones ›› Por Miguel Ángel Barajas

recuentemente los clientes se preguntan: ¿por qué es tan caro pagar una consultoría de arquitectura? ¿Realmente la necesito? ¿De qué me sirve que alguien haga esos “diagramitas” y documentos? Un arquitecto de soluciones, es una profesional con la experiencia necesaria para saber “de todo un poco” pero teniendo una visión end-to-end de la solución. Es el encargado de escuchar las necesidades del cliente y diseñar una solución, mapeando los requerimientos funcionales hacia tecnologías. De igual manera, el arquitecto es el puente entre el cliente con sus necesidades, y los ingenieros que implementarán la solución. Esto quiere decir que si algún requerimiento cambia, el arquitecto debe ser capaz de saber qué componentes de la solución son afectados y de qué manera. El arquitecto también es responsable en crear un diseño con miras al futuro y a las posibles integraciones que la solución pueda requerir. Y entre más compleja sea la solución o más integraciones tenga, más evidente se hace la necesidad de tener un diseño claro para poder implementar la solución. Es así que la importancia de un buen diseño es de gran valor para los proyectos de medianos a grandes. Tú no harías tu casa sin un diseño (planos), ¿o sí? De hecho, tal vez podrías hacer una casa muy sencilla sin necesidad de planos de diseño, pero ahora imagina un edificio de 500 oficinas o un hotel de 1,200 habitaciones. Ahí las cosas se empiezan a complicar, estacionamiento, tuberías, cimientos, instalaciones eléctricas, etcétera. Todo esto debe ser planeado y estimado. Y es un arquitecto quien lo hace. Ahora bien, pensemos en una solución compleja, como puede ser una nube privada para el Gobierno Federal de un país mediano. El objetivo es disminuir costos en infraestructura de TI y al mismo tiempo agilizar la provisión de recursos de cómputo. Para ello se decide centralizando todos los centros de datos de las diferentes dependencias en un solo gran centro de datos. De tal suerte que cuando una de las dependencias necesite infraestructura para un proyecto de IT, en lugar de darle presupuesto para comprar un nuevo equipo, simplemente se le aprovisionarán recursos a partir un pool centralizado que provee infraestructura como servicio (IaaS). La mejor solución para este ejemplo es una nube privada de tipo multi-tenant en la cual cada dependencia de gobierno será “cliente” de la nube centraliada y, dependiendo el tamaño de su presupuesto, se le estará asignando una serie de recursos virtuales (red, seguridad, cómputo, almacenamiento, etcétera). El arquitecto debe ser la persona encargada de planear a detalle cómo será implementada la solución, desde todos los puntos de vista: servicio,

oferta, integraciones, mediciones, monitoreo, etcétera. Conforme realiza esto, siempre debe tener en cuenta la sustentabilidad de la solución y las proyecciones de crecimiento. El resultado de este diseño y arquitectura es un documento estilo “receta de cocina” en el cual se plasman todos los detalles de la arquitectura, por ejemplo en este caso:

Servicio • Catálogo de servicio (ofertas de servicio y con qué opciones). • Cómo será entregado este servicio (portal de auto aprovisionamiento). • Cómo será cobrado el servicio (billing/chargeback).

Infraestructura • Qué infraestructura física se usará y cómo se dispondrán en la nube. • Qué almacenamiento y cómo se usará. • Qué infraestructura de red se usará y cómo se configurará la red (switches, IPS, ruteadores, firewalls, etc.).

Tecnologías • Qué hipervisor se usará y cómo. • Qué tecnología se usará para gestionar el aprovisionamiento de la nube. • Monitoreo. • Seguridad perimetral. • Reporteo. • Integraciones con otros sistemas (SAP por ejemplo). Todas estas tecnologías deben integrarse de una manera estandarizada en la cual todo funcione de forma integrada. Contar con una arquitectura bien diseñada desde antes de empezar la implementación es crítico, ya que esto contribuye a: • Identificar posibles fallas y/o retos desde antes de la implementación que podrían ser muy costosos después. • Tener una vista “punto a punto” de cómo funcionará la solución. • Tener un plan general de cómo se debe implementar la solución, facilitando así la asignación de actividades durante la implementación. • Evitar retrabajo. • Facilitar el mantenimiento y extensibilidad.

Conclusión

Esto es un primer vistazo del tipo de cosas que se definen en la arquitectura de soluciones de TI, y su importancia. En futuras entregas platicaremos más a fondo sobre esto. .BIO

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

www.sg.com.mx |

Software Guru

.TECNOLOGÍA Gadgets

Pretty Smart Lamp

Estimote Stickers Developer Preview Kit

La ola de los beacons está próxima a llegar, y Estimote es una de las empresas que parece estar al frente. Recientemente liberaron un kit para desarrolladores que incluye 10 pequeñas estampas que puedes adherir a cualquier objeto y utilizar junto con su SDK para construir apps de localización de alta fidelidad. Al igual que los beacons de mayor tamaño, las estampas tienen conectividad inalámbrica, así como sensores de temperatura y movimiento. Con esta información podrás construir una nueva generación de apps que conecten tu smartphone con todo tipo de objetos de la vida diaria. Las estampas cuentan con un procesador ARM M0 Cortex y un batería de litio no recargable con un tiempo de vida estimado de 1 año. El SDK está disponible tanto para iOS como Android. http://estimote.com

Como su nombre lo indica, la pretty smart lamp es una lámpara bonita e inteligente. Es un proyecto, actualmente en Kickstarter, desarrollado por un padre y su hija, de origen mexicano. Tiene un diseño elegante, hecho con caoba y alabastro extraído de Galeana en Nuevo León. La luz es generada por un arreglo de 48 LEDs ajustables. Cuenta con sensores de luz y temperatura, que le permiten automáticamente ajustarse a las condiciones. Puedes controlarla vía Bluetooth desde tu smartphone o incluso configurar otros dispositivos (como un termostato inteligente) en tu hogar para que puedan interactuar con la lámpara. Pero no te preocupes, también puedes prenderla y apagarla manualmente simplemente con tocarla, gracias a que cuenta con un acelerómetro. http://www.prettysmarthomes.com

Sable Láser Crossguard Personalizable de The Force Awakens

Todos los fanáticos y no tan fanáticos de la Guerra de las Galaxias hemos fantaseado alguna vez con sostener entre nuestras manos un sable láser. Y eso mismo pensó la tienda francesa de impresión en 3D: leFab-Shop que ha diseñado e impreso sus propios sables pieza por pieza para luego ensamblarlos. ¿Bastante increíble no? Tanto que han decidido compartirlo con el universo a través de Thingiverse. Ahí además podrás encontrar también videos que muestran todo el proceso paso a paso; y cuando menos lo esperes estarás enfrentándote a la fuerza, cualquiera que sea tu bando. http://www.thingiverse.com/thing:572485

MICA Brazalete Inteligente

MICA: My Intelligent Communication Accessory, creado en conjunto por la tienda neoyorkina Open Ceremony e Intel, es un brazalete muy fashion que combina piel de víbora de agua, gemas preciosas de diversas partes del mundo como Madagascar y Rusia; así como tecnología de punta e interesantes funciones digitales que permitirán a las mujeres no sólo estar a la moda sino también estar conectadas en todo momento y en todo lugar, ya que unas de sus principales características es la de conectarse con el teléfono celular para recibir alertas, enviar SMS, conectarse a redes sociales y consultar mapas. Tendrá un costo aproximado de 495 dólares con distribución exclusiva, por el momento, en los lujosos almacenes Barneys. http://www.intel.com/content/www/us/en/wearables/fashion-technology.html 54

Directorio Abiztar 4F www.abiztar.com.mx

SG Mobile Day México 3F sg.com.mx/mobileday

ITAM 2F www.quieroseritam.com.mx

SG Eventos 2015 01 sg.com.mx

SG Campus 09 www.sgcampus.com.mx

e-Quallity 15 www.e-quallity.net

SG Talento 31 360° 53

www.sg.com.mx |

www.360grados-ondemand.com

Software Guru

www.sgtalento.com

TENEMOS UN ESPACIO RESERVADO PARA TI SG se distribuye de manera impresa en la República Mexicana, y de manera digital llega a más de 25mil lectores de habla hispana. El anuncio en la revista digital cuenta con hiperliga directa a tu sitio web, lo que te dará la oportunidad de acercarte a nuevos clientes. “Es una gran oportunidad participar con Software Guru, pues comprobamos que es un medio efectivo.” -Novalys Latinoamérica Contáctanos en el (55)

5239.5502 o en publicidad@sg.com.mx

.BIBLIOTECA

It’s Complicated: The social lives of networked teens DANAH BOYD. YALE UNIVERSITY PRESS, 2014.

Esta reseña fue compartida por Mariel García (@faeriedevilish), colaboradora en SocialTIC que trabaja en el indeterminado terreno del uso de la tecnología para el cambio social. ¿Con quién se comunican los adolescentes en la red? ¿Por qué aceptan a sus familiares en Facebook, pero no en Twitter? ¿Con quiénes no quieren hablar? ¿Qué tanto valoran su privacidad y hasta dónde llegan para protegerla? Este es el tipo de preguntas que busca contestar el libro titulado “It’s Complicated: The social lives of networked teens” (Es complicado: la vida social de los adolescentes en la red). El libro es obra de Danah Boyd, etnógrafa reconocida en el estudio de jóvenes y uso de medios en Estados Unidos. En él presenta perspectivas que ha recopilado durante ocho años de entrevistas con jóvenes. Por ejemplo, ¿sabías que si desactivas tu cuenta en Facebook puedes reactivarla cuando quieras e inmediatamente recuperar tus contactos e historial? Eso es lo que hace una adolescente llamada Mikalah; cada que quiere usar Facebook reactiva su cuenta, ve el estatus de sus amigos, chatea un poco y al terminar la vuelve a desactivar. De esa forma, Mikalah mantiene su información alejada de sus “vigilantes”. La obra está organizada alrededor de temas que preocupan particularmente a las generaciones menos jóvenes: identidad, privacidad, adicción, peligro, bullying, desigualdad, analfabetismo digital, y búsqueda de audiencias propias. “It’s Complicated” está disponible en versión impresa en las principales tiendas de libros, y también se puede obtener gratuitamente en formato digital en http://www.danah.org/itscomplicated/

Seven More Languages in Seven Weeks

BRUCE TATE, FRED DAOUD, JACK MOFFITT, IAN DEES. PRAGMATIC BOOKSHELF, 2014.

En 2010 Bruce Tate publicó un libro llamado “Seven Languages in Seven Weeks” en el cual enseñaba los aspectos principales de los lenguajes que mayor impacto estaban teniendo en la forma en que desarrollamos software. Los lenguajes abordados fueron: Ruby, Io, Prolog, Scala, Erlang, Clojure y Haskell. El propósito es ir un paso más allá del “Hola Mundo” y llegar a suficiente profundidad para que el lector entienda la esencia y funcionamiento de cada lenguaje. En 2014 Tate regresa acompañado de otros expertos y ahora presentan “Seven More Languages ...”. Los lenguajes estudiados en esta ocasión son: Lua, Factor, Elm, Elixir, Julia, miniKanren e Idris. A excepción de Lua y Elixir, es muy probable que nunca hayas escuchado de ellos; sin embargo son excelentes para enseñar conceptos que se utilizan en los lenguajes modernos. Por ejemplo, Factor es ideal para aprender composición funcional, que es el corazón de la programación funcional. Elixir por su parte, hace énfasis en la capacidad de soportar fallas y recuperarse de éstas, por lo cual es ideal para sistemas distribuidos. En el caso de miniKanren, no es un lenguaje sino una librería para programación lógica que se puede utilizar en otros lenguajes como Haskell y Clojure. Cualquier desarrollador que quiera mantenerse a la vanguardia y continuar puliendo sus habilidades, estará interesado en echar un vistazo a “Seven More Languages”. 56