www.sg.com.mx

CONOCIMIENTO EN PRÁCTICANoviembre 2011-Enero 2012

NovedadesWebSockets

México, $65.00

http://swgu.ru/sg34msdn

http://swgu.ru/sg34talento

ColumnasTejiendo Nuestra Red 06Por Hanna Oktaba

Mejora Continua 08Por Luis Cuellar

Tendencias en Software 11Por Luis Daniel Soto

Columna invitada 32Por Mark Settle

Código Innovare 46Por Jesús Arriola Villarreal

Tecno-lógico 48Por Mauricio Angulo

Programar es un Estilo de Vida 50Por Gunnar Wolf

.CONTENIDOPág.

22

34CONOCIMIENTO EN PRÁCTICA

02

En PortadaCómputo Físico 22¡El mundo es una interfaz! Hemos concentrado diversos artícu-los con información sobre algunos de los aspectos que consi-deramos más relevantes sobre el cómputo físico, desde el fe-nómeno provocado por Arduino y el open hardware, hasta la construcción y programación de robots.

Noviembre 2011-Enero 2012 | www.sg.com.mx

PrácticasUsabilidad 34La Navegación y los Esquemas de Organización de la InformaciónPor Pamela Rodríguez

Prueba de Software 36Un Buen Inicio para las Pruebas de SeguridadPor Berenice Ruíz y Miguel Angel Cortés

Project Management 38Estimación de CostosPor Héctor Cuesta-Arvizu y José Sergio Ruíz Castilla

Arquitectura 40Líneas de Productos de SoftwarePor Humberto Cervantes

Gestión de Riesgos 42Administración Colaborativa de RiesgosPor Leonardo G. Mrak

.CONTENIDO

Herramientas yNovedades

Lo que Viene 10Social Analytics, Open Compute Project, GitHub Enterprise, Apache Sqoop

Tutorial 12Versionando con GitPor Javier Novoa Novedades 16WebSocketsPor Gonzalo Ayuso

CarreraCapital Humano en Software 52Por Pedro Galván

En Cada NúmeroEditorial 04

Noticias 05

Publirreportaje 54

Gadgets 56

EmprendiendoGeneración de modelos de negocio 18Por Víctor Reyes

EspecialReseña del evento SG Conference & Expo 2011 20

Pág.

18

03

.EDITORIALBienvenida

. Alcanzando a la ficción

¡Esta es la última edición del 2011! Cumplimos un año más de generar conocimiento sobre la industria de T.I. y agradecemos a todos ustedes, nuestros lectores, que nos sigan eligiendo como el medio de

preferencia de habla hispana. En ésta ocasión les tenemos como parte del tema principal, diversos artículos sobre “cómpu-to físico” en los cuales se demuestra que el mundo no está aún conforme con los tipos de interacción con la tecnología que existen al día de hoy. El cómputo físico fomenta nuevos estilos de interacción en los que casi cualquier artefacto se puede transformar en una interfaz. Es muy importante conocer éste tipo de tendencias, ya que la historia ha comprobado que toda ficción tarde o temprano se alcanza y en éste caso, seguramente está sucediendo más temprano que tarde. También queremos compartirles que este año constatamos, una vez más, que hemos logrado junto con ustedes formar una verda-dera comunidad de especialistas de software, comunidad que durante éste año compartió momentos en la Conferencia Virtual, los espacios de aprendizaje colaborativo de SGCampus y en el evento SG Conference & Expo 2011.

››Equipo EditorialSOFTWARE GURU

“Gracias por todo lo compartido durante el 2011 ¡Nos vemos en el 2012 con más no-vedades!”.

DIRECTORIO SGDirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba

Coordinación Editorial Vanessa Amaya / Arte y Diseño Oscar Sámano / Suscripciones Denise Aguilar

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 / Mauricio Angulo - Tesseract Space

Colaboradores Antonio Toriz, Berenice Ruiz, Gonzalo Ayuso, Gunnar Wolf, Héctor Cuesta, Hugo Fernández, Humberto Cervantes, Javier Novoa, Jesús Arriola Villareal, José Sergio Ruíz Castilla, Leonardo G. Mrak, Mark Settle, Mauricio Angulo, Miguel Angel Cortés, Miguel Angel Ramírez,

Pamela Rodríguez, Víctor Reyes

Ventas Claudia Perea / Alianzas Montserrat Ramírez / Webmaster Karen Rodríguez / Educación contínua Ana Karen RosalesContacto info@sg.com.mx

SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., Temístocles 34 piso 3, México DF 11560. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 2.5 México. Todos los artículos son responsabilidad de sus propios autores y no necesariamente

reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: En trámite. ISSN: 1870-0888. Registro Postal: PP15-5106. Distribuido por Sepomex. Se imprimió en noviembre de 2011 en 4Press.

04

.NOTICIAS

.Adobe Max 2011Adobe Max, la conferencia anual para usuarios y desarrolladores de Adobe, se realizó en Los An-geles del 2 al 5 de octubre. Entre las notas principales de este evento está el próximo lanzamiento del Adobe Creative Cloud, un espacio colaborativo en la nube donde los profesionistas pueden almacenar y organizar sus activos digitales, y compartir avances con sus clientes para que éstos puedan visualizarlos desde la nube. La agenda incluyó un buen número de sesiones relacionadas con HTML5, lo cual muestra el compromiso e interés que tiene Adobe en esta tecnología. De hecho, uno de los anuncios realizado durante estos días fue que Adobe compró a Nitobi, crea-dores de la plataforma PhoneGap para desarrollar aplicaciones móviles con Javascript y HTML. Los videos de los keynotes están disponibles en http://swgu.ru/adobemax2011

.El Futuro en Tus Manos 2011 Estudiantes, empresarios, docentes, y público interesado en la tecnología, acu-dieron el 3 y 4 de noviembre al congreso “El Futuro en Tus Manos 2011” orga-nizado por CITI Tabasco en la ciudad de Villahermosa. El evento contó con la participación de importantes figuras en el mundo de la tecnología tales como Juliano Tubino (Microsoft), Adelina Filigrana (@wera_supernova), Claudio Cossío (AppCircus), Engel Fonseca (Neurona Digital), Jorge Soto (Citivox), Andrés Barreto (OnSwipe), Juan Lozada (Microsoft) y el investigador Ruy Cer-vantes, quien comentó sobre el ecosiste-ma de emprendimiento en México y su naciente industria de internet.

.Dell WorldDell compartió su visión sobre el impacto de las principales tendencias en la industria de tecnologías de información durante la primera edición de su evento Dell World, realizado en la ciudad de Austin. Entre las personas que presentaron en Dell World estuvieron los CEOs de varias de las empresas más importantes de la industria como Steve Ballmer (Microsoft), Paul Maritz (VMware), Marc Benioff (salesforce.com), Paul Otellini (Intel). Los temas que dominaron la agenda fueron el cómputo en la nube, cómputo móvil en las empresas y aprovechamiento de redes sociales en las em-presas. Los videos de las sesiones están disponibles en http://swgu.ru/dellworld2011

.Alpha Consultoría reconocida como Empresa de Capacitación del Año por el PMIEl evento “Best of the Best in Project Management 2011” fué celebrado el pasado 22 de Octubre duran-te el Congreso Global del PMI® en Grapevine, Texas. Celebramos que lo mejor de lo mejor ahora se quedó en México, ya que la empresa Alpha Consultoría fue premiada como Proveedor de Capacitación del Año 2011, siendo la primera empresa latinoamericana honrada con esta distinción. El objetivo de este pre-mio en especial, es reconocer y honrar al proveedor que hubiera demostrado capacidades excepcionales para la implementación y presentación de un pro-grama en dirección de proyectos, en esta ocasión reconociendo los programas de capacitación de van-guardia en Administración de Proyectos impartidos por Alpha Consultoría.

.Gartner - The Future of ITGartner celebró su 14va Conferencia Anual The Future of IT del 4 al 6 de octubre en el Centro Banamex de la Ciudad de México. En dicho evento participaron 12 destacados analistas que platicaron con los asistentes sobre estrategias tecnológicas para transformar los negocios, con el objetivo de ayudar a los CIOs y altos ejecutivos de la TI a llevar sus negocios hacia nuevos niveles de expansión y rentabilidad. El evento incorporó gran variedad de sesiones, workshops, mesas redondas, casos de estudio, sesiones sobre cuadrantes mágicos, sesiones por solución de proveedor, foro de demostración de productos y las ya tradicionales one-on-one con los analistas.

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

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

05

06

Medellín, Colombia, agosto de 2011

En mi columna de mayo-junio de este año les co-menté sobre la iniciativa del SEMAT (Software Engineering Method and Theory) promovida

por Ivar Jacobson, entre otras personalidades. En agosto tuve la oportunidad de escucharlo en persona en Mede-llín, Colombia. El Dr. Carlos Mario Zapata de la Uni-versidad Nacional de Colombia logró que Ivar aceptara visitar este país. Carlos aprovechó la oportunidad para convocar a varios colegas académicos de América Latina para dos cosas. Lo primero que nos pidió fue que escri-biéramos un capítulo cada quien para un libro que refleje el estado de investigación en Ingeniería de Software en esta zona geográfica y lo segundo fue para constituir el capítulo Latinoamericano del SEMAT. Así, entre el 11 y 12 de agosto de 2011 nos encontramos con Jacobson en

.COLUMNATejiendo nuesTra red

La Dra. Hanna Oktaba es profe-sora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPATISOFT. hanna.oktaba@ciencias.unam.mx

Entre Medellín, Rio de Janeiro y Miahuatlán

Medellín escuchando un llamado a evolucionar la forma en que desarrollamos software identificando lo esencial de lo que ha servido de los métodos tradicionales y agre-gando lo más útil de las propuestas de métodos ágiles.

Lo que deberíamos buscar es:• Hacer mejor software – útil, extensible y confiable• Hacerlo más rápido y más barato- aplicando reusabilidad a gran escala• Hacerlo con equipos más felices – gente competente y motivada

Parece tan sencillo y a la vez tan difícil.

Ivar estaba acompañado de una mujer joven, de origen chino, Shihong Huang quien nos contó la ex-periencia de la creación del primer capítulo de apoyo al

Hanna Oktaba, Ivar Jacobson y Magdalena Dávila

SEMAT constituido en China. Su servidora y Magdalena Dávila, mi alumna de doctorado, presentamos una propuesta de la estruc-tura de prácticas indispensables para desarrollar un proyecto de software (Software Development Project Kernel), la cual quedó incluida en el libro “Software Engineering Methods, Modeling and Teaching”, editado por la Universidad de Medellín. Tam-bién quedó constituido el capítulo Latinoamericano del SEMAT (www.sematla.org), coordinado por Carlos Mario Zapata y con Ivar Jacobson como testigo de honor.

Durante el evento Ivar mencionó que está preparando un nuevo libro, que presentará la propuesta de Casos de Uso 2.0. A principio de octubre ya lo dio a conocer con mayor detalle y probablemente se pu-blicará en forma electrónica en noviembre. A los interesados les sugiero visitar el sitio de Ivar Jacobson International.

_

Río de Janeiro, Brasil, septiembre de 2011

RIOINFO es un evento anual en el cual se encuentran los em-presarios de la industria de TI con los representantes del gobierno para discutir los temas de interés y buscar caminos para fortalecer la industria brasileña. El evento dura tres días y está más enfocado a mesas de discusión que a las conferencias técnicas. En este evento me enteré de que la industria brasileña de software y de servicios está formada por cerca de 75 mil empresas, lo que me pareció des-orbitante en comparación con alrededor de 2800 de las mexicanas, mencionadas en agosto en la reunión de la constitución del Conse-jo Nacional de Clusters de Software y TICs.

Los brasileños estiman que en sus empresas trabajan alrededor de 600 mil personas, que sumados a las 370 mil involucradas en empresas usuarias forman casi un millón.

Dos eventos de RIOINFO me llamaron mucho la atención. Los empresarios invitaron en dos sesiones separadas a los represen-tantes de PETROBRAS (la homóloga de PEMEX) y del Ejército y la Armada para convencerlos de que estas instituciones públicas deberían de comprar el software y sus servicios a las empresas bra-sileñas. El Secretario de Ciencia y Tecnología (ellos si lo tienen en ese rango) habló de convertir los resultados de estas discusiones en políticas públicas. ¿Y en México cúando?

Con Claude Laport, editor del ISO/IEC 29110, nos tocó promo-ver el nuevo estándar internacional en este foro. Tuvimos oportunidad de discutir la necesidad de combinar el Perfil Básico con las prácticas

de los métodos ágiles para integrar las bondades de ambos enfoques. Encontramos un entusiasmo e interés de trabajar de manera conjunta en este tema con los brasileños.

La lección que aprendí en este evento resumo citando al Coor-dinador General de RIOINFO 2011, Benito Paret: “Las reservas de petróleo, por mayores que sean, un día se acaban. Las copas del mundo y las olimpiadas pasan. El conocimiento permanece.”

_

Minahuatlán, Oaxaca, octubre de 2011

Cuando me invitaron a dar una plática en la 4ta Jornada de In-formática en la Universidad de la Sierra del Sur ubicada cerca de Miahuatlán, Oax., yo ni sabía que existía una ciudad con este nombre. La encontré a medio camino (pésimo por cierto) entre la ciudad de Oaxaca y Huatulco.

Cuando me enteré de que esta universidad es la hermana de la Universidad Tecnológica de la Mixteca, sabía que me espera un viaje muy aleccionador y muy agradable. Hace años ya visité a la Mixteca fundada por el rector Modesto Seara Vázquez en un espacio rural y me impresionó su organización y el nivel académico. Uno de mis mejores alumnos de la maestría es egresado de allá. El proyecto tuvo tanto éxito que hoy el mismo rector dirige y coordina toda una red de universida-des públicas estatales en Oaxaca.

En Miahuatlán me encontré con un campus muy bonito para 1500 alumnos, con áreas verdes bien cuidadas y con un grupo de jóvenes profe-sores de la carrera de Informática muy entusiastas y muy bien preparados. La Ingeniería de Software no es desconocida ni para los profesores ni para los alumnos y ya están desarrollando proyectos muy interesantes. El rec-tor me estuvo presumiendo que en los últimos años los egresados de estas universidades salen muy bien en las evaluaciones de CENEVAL, pero que normalmente tienen que migrar a grandes ciudades para conseguir trabajo. Generar espacios de trabajo locales para elevar el nivel de aprovechamiento de TI en poblaciones marginadas podría ser una solución, ¿pero quién va a invertir? Este es un reto para todos y no sólo en Oaxaca.

››Por Hanna Oktaba

.COLUMNATejiendo

nuesTra red

07

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

››“Las reservas de PeTróLeo, Por mayores que sean, un día se acaBan. Las coPas deL mundo y Las oLimPiadas Pasan. eL conocimienTo Permanece.” - BeniTo PareT

08

La Estrategia de Mejora de Software

Me encuentro leyendo un libro en el que se define a la estrategia como: “El arte de encontrar formas de cooperar aun cuando

las diferentes partes están motivadas por intereses personales”. La industria de subcontratistas de servicios de sistemas está basada precisamente en esta idea, lograr una cooperación entre diferentes compañías, a veces hasta competidoras, para lograr un fin en común que beneficie a todas las partes. Por lo que veamos si podemos aplicar la teoría de juegos a nuestros problemas.

El dilema del prisioneroUno de los ejercicios más comunes en teoría de juegos es “el dilema del pri-sionero”, el ejemplo clásico de este problema es el siguiente: dos hombres son arrestados por la policía, pero esta no cuenta con información suficiente para una condena. Tras la separación de los dos hombres, la policía ofrece un trato a ambos, si uno declara en contra de su pareja y el otro permanece en silencio, el traidor queda libre y el otro hombre recibe una condena de cinco años de prisión. Si ambos permanecen en silencio, ambos son condenados a seis meses de carcel por un cargo menor y si ambos se traicionan mutuamente, cada uno recibe una sentencia de un año de prisión. Cada prisionero debe elegir entre traicionar o per-manecer en silencio, ¿qué deben hacer? Lo importante en este juego es que ambos están separados y no saben lo que el otro hará y aunque lo mejor para ambos es no decir nada, la pregunta es si confías en tu compañero lo suficiente como para no hacerlo. Este problema ilustra cómo en ocasiones estamos en circunstancias que motivan a apoyar una decisión contraproducente. ¿Qué harían ustedes?

Ahora veamos este juego desde otro punto de vista: Yo estoy contratando a un proveedor para que desarrolle una aplicación critica para mi organización, de la cual depende mi futuro en la misma. Sé que tengo que trabajar en conjunto con mi proveedor para lograr el éxito del proyecto, pero por otro lado quiero asegurarme de que el proveedor esté tan comprometido como yo, por lo que coloco en el contrato una penalización alta en caso de que los niveles de servicio no se cumplan. De esta manera, al menos si el proyecto fracasa recuperamos parte de la inversión.

El proveedor sabe que en ocasiones los niveles de servicio no se cumplen por razones ajenas a él, como: cambios de alcance, problemas con los entrega-bles de entrada, falta de definición por parte del usuario, etc. El contrato no

previene nada de esto y aunque lo hiciera no es posible pensar en todos las posibles fallas, por lo que se “infla” la propuesta y se busca hacer los objetivos más holgados.

El resultado: El proyecto está inflado y estamos más preocupados en cómo defendernos de nuestra contraparte que en sacar el proyecto exitosamente. El dilema del pri-sionero es un problema de confianza, en donde la duda realmente es si confío en que la otra parte hará lo correcto o no. En teoría de juegos, existen varias formas de resolver el dilema del prisionero, estos son algunos ejemplos que he experimentado con organizaciones exitosas.

Generar una relación a largo plazoTodas las soluciones del “problema del prisionero” tienden a ser a largo plazo. Lo que se busca es generar una relación

de confianza lo cual normalmente surge a través del tiem-po. Las compañías que son más exitosas con el manejo de proveedores generan una estrategia de socios con sus proveedores, se genera una selección de proveedores en-focada principalmente en las habilidades, conocimiento, valores y cultura de las organizaciones para elegir un grupo limitado que puede participar en mis licitaciones, gene-ralmente llamados proveedores preferentes. Es cierto que esto implica que muchas compañías que pueden ayudar a problemas particulares se quedan fuera, pero la idea es que la selección está diseñada para asegurar que a largo plazo el desempeño y afinidad ayude a tener proyectos exitosos.

Aprendizaje y crecimiento mutuoEn compañías excelentes se desecha la noción de que el cliente lo sabe todo y se busca un modelo de cooperación en donde tanto cliente como proveedor están aprendiendo a hacer un mejor trabajo. La principal herramienta de apren-dizaje en estos proyectos son las métricas, por lo que son de suma importancia. Estas métricas son primero utilizadas para controlar el proyecto y después para mejorar continuamente el trabajo del equipo logrando no solamente un proyecto exi-toso, sino en muchas ocasiones mejor de lo esperado.

Muchos de los clientes que conozco, sí generan penali-dades en los proyectos, pero estos no están ligadas a métricas u objetivos específicos sino más bien a la falta de acción y proactividad para corregir problemas. Por ejemplo, la pri-mera vez que no se alcanza un objetivo se espera un plan de acción. Si la siguiente ocasión no se ha corregido, cliente y proveedor buscan soluciones en conjunto. Si las métricas no mejoran entonces si surge una penalización. De forma similar, si las métricas se cumplen arriba de lo esperado va-rios meses continuos se puede manejar un bono al proyecto. Lo importante es que una penalización es un último recurso para asegurar que estamos en el mismo canal.

El dilema del prisionero es muy difícil de resolver pero estudios indican que las personas tienden a escoger coope-rar especialmente en relaciones a largo plazo. La industria de software está en constante crecimiento y definitivamen-te en la era de la información necesitamos cada vez más de sistemas rápidos y de mejor calidad, por lo que la coopera-ción es indispensable para todos. Hagamos de la industria del software algo de que sentirnos orgullosos en nuestro país, y no una batalla campal.

“Primera llamada, primera”.

››Por Luis Cuellar

Luis R. Cuellar es director de calidad a nivel mundial de Softtek. Es reco-nocido por la ASQ como Certified Quality Manager, Certified Software Engineer y Six Sigma Black Belt. @lcuellar

.COLUMNAmejoraconTinua

http://swgu.ru/sg34infotec

.HERRAMIENTAS Y TECNOLOGÍASLo queviene

2OCP es una iniciativa creada por Facebook para compartir abiertamente diseños de data centers, con el objetivo de mejorar la estandarización y eficiencia en la industria. Facebook ha abierto como parte de OCP los detalles de diseño y construcción de su nuevo data center, para el cual construyeron sus propios servidores, racks y fuentes de poder, logrando superar en 38% la eficiencia de su data center previo, a un costo de construcción 24% menor. Recientemente se formó una fundación que manejará OCP, y en ella están involucradas empresas como ASUS, Dell, Huawei, Red Hat, Cloudera, Rackspace y Netflix, por nombrar a algunas.

http://opencompute.org

Open Compute ProjectData centers abiertos

10

2Apache Sqoop es una herramienta para transferir datos de forma eficiente y confiable entre clusters basados en Apache Hadoop, y fuentes de datos estructuradas tales como bases de datos relacionales, data warehouses empresariales y almacenes NoSQL. Con Scoop, puedes importar datos hacia el Hadoop Distributed File System (HDFS) o hacia sistemas relacionados como Hive y HBase. De forma similar, con Sqoop puedes extraer datos de Hadoop y exportarlos a ba-ses de datos estructuradas. Sqoop hace todo esto de forma sencilla y eficiente, ya que a partir de los metadatos puede inferir su estructura y guardarla en un metaalmacenamiento Hive, y utilizar MapReduce para transferir los datos en paralelo.

http://incubator.apache.org/sqoop

Apache SqoopMejora tu transferencia de datos a Hadoop

1Microsoft está experimentando un nuevo servicio llamado Social Analytics que facilitará integrar en aplicaciones de negocio la capacidad de analizar corrientes de datos (data streams) de sitios sociales como Twitter, Facebook, YouTube, y obtener inteligencia. Esto permite que las empresas puedan obtener y analizar inmediatamente la respuesta de los clientes hacia las decisiones de negocio que se toman. Microsoft provee dos mecanismos para consumir servicios de Social Analytics. El primero es por medio de una herramienta llamada “Engagement Client”, y el segundo es directamente accedien-do su API basado en REST y OData.

http://www.microsoft.com/en-us/sqlazurelabs/labs/socialanalytics.aspx

Social AnalyticsAnálisis de datos sociales

3GitHub EnterpriseHospeda GitHub en tus servidores

Como muchos de ustedes saben, GitHub es un servicio en internet para hospedar proyectos de software que utilizan el sistema de control de versiones Git, rápidamente GitHub se ha convertido en el meca-nismo default entre desarrolladores para compartir código. GitHub recientemente anunció la disponi-bilidad de GitHub Enterprise, el cual permite que organizaciones hospeden instancias de GitHub en sus propios servidores. De esta forma, las empresas pueden fácilmente establecer repositorios de código fuente versionado para sus proyectos y empleados, manteniendo todo dentro de su firewall.

http://enterprise.github.com

11

esto era viable para organizaciones con recursos de cómputo masivos. Con tecnologías como Hadoop para Windows y el conector Hive de Excel, hoy esto es mucho más accesible.

El diluvio de datos se tendrá que enfrentar con nuevas herramientas interactivas para “explorar” cantidades masivas de información —la visualización continuará siendo muy re-levante. Las plataformas de datos tendrán que evolucionar para administrar cualquier tipo de datos, gigantes o pequeños, desde cualquier lugar. La información deberá ser consumida desde cualquier dispositivo portátil y en un contexto que haga senti-do al usuario. Los metadatos son fundamentales para habilitar los mercados de datos descritos.

Big Data se refiere al procesamiento de información no estructurada (video, audio) o semi-estructurada (bitácoras del web). Es tal la cantidad de datos que es impensable que un humano pueda realizar el análisis, por lo que el “aprendizaje basado en máquinas” será fundamental.

En el “nuevo mundo de datos” hay una variedad de nuevas tecnologías. Por ejemplo, hoy en día la respuesta a una búsqueda en sitios de búsqueda como Bing es distinta para cada usuario, las recomendaciones son específicas para el usuario de entre millones de combinaciones. Mediante Bing será posible extender aplicaciones de negocio, por ejemplo “obtener el sentimiento de medios sociales” de un producto en una zona geográfica. IntoNow me parece un interesante ejemplo del nuevo conjunto de tecnologías que hacen posible la magia de mejorar en tiempo real nuestro entendimiento. Sugiero leer http://swgu.ru/sg3408

En los años por delante, un área de gran acción será la de “los datos como plataforma” y tecnologías asociadas. Aunque la privacidad de datos continuará siendo tema de discusión, eventualmente las empresas explorarán la venta de datos. Em-prendamos pues una conversación al rumbo de la auténtica economía de la información.

>> Por Luis Daniel Soto

.COLUMNATendencias en

sofTware

Datos como Plataformarumbo a la auténtica economía de la información

El costo de la “captura manual” de un petabyte de información en la década pasada rebasaba,

dependiendo de la precisión, varios millones de dólares. Gracias a los avances tecnológicos, hoy el gran volumen de información “nace de forma digital”. Al ritmo actual de compresión y depuración automática de datos, el costo de almacenar un petabyte al final de la década será menor a cinco dólares estadounidenses.

El “valor” de la información será mayor que el “cos-to” de almacenarlo.

Las implicaciones son enormes. Todos debemos estar entu-siasmados con las nuevas oportunidades que se abren:

Mashup de datos. La capacidad de mejorar el diagnóstico mé-dico ANTES de llegar a la sala de urgencias se está volviendo una realidad en los países desarrollados y no me refiero a temas altamente relacionados con la privacidad como los productos que compramos en el supermercado y hábitos de ejercicio que podrían ser extraídos de nuestra “estela” transaccional, o el almacenamiento del registro médico en la nube. Expongo un ejemplo: Con los sensores de ubicación de las ambulancias “unido” a los patrones de tránsito en las ciudades es posible optimizar el movimiento para atender urgencias.

Enriquecimiento de información. Hasta hoy, la “inteligencia de negocios” se ha centrado al interior de la organización, pero la capacidad de conectar los datos con el resto de los que exis-ten en el mundo abre nuevas puertas a realizar preguntas más sofisticadas, que antes era imposible contestar. Seguramente veremos el nacimiento de “mercados de datos” privados como una primer etapa y la creación de un nuevo ecosistema de datos públicos enriquecidos. RealtyTrac es un ejemplo real de empre-sa que revende información pública enriquecida por analistas financieros sobre compra de propiedades.

Nuevas posibilidades. Para generar más utilidades, un analista desea poner a prueba un nuevo modelo con datos históricos de la bolsa de valores. Para que el modelo funcione es necesario analizar épocas de auge y de crisis, digamos 30 años. Se de-sea incluir mercados internacionales y por supuesto, tomar la fuente con actualizaciones en tiempo real. Hasta recientemente

Luis Daniel Soto Maldonado es Di-rector de Technical Product Manage-ment para SQL Server en Microsoft Corporation.@luisdans

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

››es TaL La canTidad de daTos que eL aPrendizaje Basado en máquinas será fundamenTaL.

12

.HERRAMIENTAS Y TECNOLOGÍASTuToriaL

En este artículo explico los aspectos básicos para aprender a usar el sistema de control de versiones (VCS) Git.

Para explicar mejor el funcionamiento de Git, estaremos usando la línea de comandos. Mi recomendación para enten-der Git es entender los conceptos con los comandos asociados, y después si así se desea, buscar alguna interfaz diferente más acorde a los gustos personales.

El modo GitMuy al contrario de como se maneja un VCS tradicional (como Subversion), Git maneja los repositorios, y los conceptos mismos de un VCS de una manera particular. Mientras que para Subversion, el control de versiones se hace archivo por archivo, sobre cada directo-rio que integra un proyecto, para Git el control de versiones se hace sobre los distintos ‘snapshots’ que se tomen de todo el proyecto. La diferencia radica en que para sistemas como Subversion, cada ver-sión del proyecto incluye la versión de cada uno de los archivos del mismo. Mientras tanto, para Git cada versión del proyecto incluye solamente un manifiesto con las diferencias de cada archivo, es decir de cómo se ve el proyecto en su totalidad en determinado momento. Entendiendo Git así, será fácil adaptarse a su modo de funciona-miento, e incluso salir de usar un VCS centralizado y comenzar a usar la genial idea que representan los VCS distribuidos.

Generando un repositorioEl primer paso para utilizar Git es tener un repositorio. El repositorio Git se representa por un directorio especial llamado .git y que reside en el directorio raíz del proyecto mismo. Git sólo genera un único directorio para todo el repositorio, en donde almacena toda la infor-mación del mismo (versiones, historial, etc.).

Hay dos maneras de generar un repositorio para trabajar con Git sobre un proyecto:

a) Inicializando un directorio como repositorio Git. Supo-niendo que se tiene un directorio en el que reside el proyecto a ver-sionar, el comando git init crea el repositorio para el proyecto dado. Esta generación del repositorio es completamente local a la máquina y el directorio donde reside el proyecto. $ cd proyecto

$ git init

b) Copiando un repositorio Git. Ahora supongamos que de-seamos colaborar en algún proyecto (o simplemente queremos ob-

tener su código fuente para compilarlo y usarlo, o para mirarlo - y admirarlo. Para esto, lo que debemos hacer es clonar el repositorio origen del proyecto para así tenerlo como un repositorio local. Los repositorios git tienen una URL, y con ella se utiliza el comando: git clone [url] para clonar el repositorio remoto a un repositorio local sobre el cual trabajar.

Para los ejercicios de este artículo utilizaremos un repositorio que ya he creado, así que para clonarlo hay que ejecutar lo siguiente desde línea de comandos:

$ git clone git://github.com/jstitch/masterm.git

Esto clonará el repositorio remoto y creará un repositorio lo-cal bajo el directorio masterm. De tal forma que ahora podemos entrar a nuestro directorio local y ver los archivos. Si se observa el contenido de los archivos ocultos de este directorio, se podrá notar un directorio .git.

Si no se ha hecho aún, es necesario indicarle a Git los datos que utilizará el sistema para saber qué usuario será el responsable de los cambios hechos. De otra manera no tendría sentido usar un VCS, sin tener a quién echarle la culpa, perdón digo darle gracias, por los cambios hechos al código. Esto se logra con los siguientes comandos:$ git config --global user.name ‘Tu nombre’

$ git config --global user.email tu@dominio.com

Usando el repositorio localEl funcionamiento básico de Git consiste en trabajar de forma local lo más posible: modificando archivos, generando branches, hacien-do merges entre branches, agregando los archivos con cambios que se deseen versionar, versionándolos y así sucesivamente. Solamente cuando ya se tiene un conjunto de código y cambios hechos y pro-bados se procede a mandarlos al repositorio origen desde el cuál se clonó (o a solicitar que se integren los cambios hechos al mismo en caso de no tener los permisos adecuados).

En resumen, se utiliza git add para agregar los cambios a los ar-chivos que se desea que Git tome en cuenta para la siguiente versión del código, git status y git diff para observar los cambios puntuales que se realizarán para la siguiente versión y git commit para alma-cenar dicha versión en el historial del repositorio. Este es el flujo principal que se sigue al trabajar con Git, y hay que destacar que todo se hace de manera local, sin interacción con repositorios remotos: recuérdese que se está trabajando sobre un repositorio local y que precisamente éste es el sentido de los VCS distribuidos.

Versionando con Gitcomprendiendo los comandos básicos

››Por Javier Novoa

13

git add. Inicialmente, ningún cambio a ningún archivo sobre el que trabajemos, es considerado por Git para versionar. Es necesario hacer un git add para que Git sepa en particular qué archivos con cambios serán versionados. Esto proporciona un control muy fino del proceso de versionado. En sistemas como SVN si un archivo es considerado para versionar, lo es desde que es agregado al repositorio y hasta siem-pre. Si deseamos modificar este archivo aún cuando esa modificación no tenga nada que ver con las modificaciones a otros archivos, el proceso de commit se llevará de una sola vez a todos los archivos versionados. En Git sin embargo tenemos la opción de elegir pun-tualmente qué archivos con cambios se van a versionar.

Así, si hacemos una modificación que sea una corrección de un bug en varios archivos, y a la vez modificamos otros archivos para corregir errores de tipografía en la documentación, Git nos permite versionar cada una de estas modificaciones por separado, permitien-do identificar más fácilmente qué archivos cambiaron como parte de qué modificación, sin confundir con otros archivos relacionados a otras modificaciones.

Por ejemplo:$ touch new_file

$ echo “” >> README.md

$ git status

El resultado que obtendremos será el estatus de git, reconociendo que se modificó un archivo existente (README.md) y se agregó uno nuevo (new_file), pero ninguno de los dos está contemplado para incluirse en el próximo commit. Para que sean considerados debemos agregarlos:$ git add README new_file

$ git status

Y ahora sí, Git sabe que ambos archivos deben ser versionados.

git status. El comando git status, que ya utilizamos, nos permite conocer el estatus con el que Git tiene identificado a los archivos del proyecto. Se puede agregar la opción -s para que nos entregue una respuesta resumida. En dicho caso, el estatus aparece en dos colum-nas: la primer columna indica los cambios que hará Git en la siguien-te versión del código, y la segunda columna indica cambios que Git reconoce como tales pero que no versionará.

git diff. Otra operación muy común al trabajar con archivos ver-sionados es la de observar y analizar los cambios hechos, así como las diferencias entre la nueva versión y la que se tiene en una versión anterior.

Git utiliza diff para esto mismo, como puede verse en el si-guiente ejemplo:

$ echo “hola mundo” >> new_file

$ git diff

El mensaje de resultado nos indica que Git detecta cambios que no han sido marcados para versionarse en el archivo new_file. Si se deseara ver las diferencias que Git detecta tomando en cuenta los cambios en los archivos que ya fueron marcados para versionar, aunque todavía no se les haya hecho commit, se utiliza el parámetro --cached.

Por último, si lo que se desea es ver todos los cambios, tanto de lo marcado para versionar como lo que no, se le pasa a git diff como parámetro la versión contra la cual se quiere comparar el código ac-tual. El nombre HEAD se refiere a justamente la última versión que se tiene almacenada el repositorio.

$ git diff HEAD

git commit. Finalmente, una vez hechos los cambios deseados y agregando a los archivos que se desea sean incluidos en esta versión, se realiza el commit al repositorio (recuérdese: es local, ¡no hay nece-sidad de conexión a la red todavía!):$ git commit -m “cambios al README y creando new_file”

Como se puede observar, con el argumento -m indicamos un mensaje descriptivo de esta versión. Este es obligatorio.

Si ahora verificamos el estatus con git status, veremos que sólo queda un cambio detectado por Git: aquel que hicimos posterior al git add, y por lo tanto no está marcado todavía para ser versionado.

Branches y MergesPara los provenientes de VCS centralizados como SVN, muy proba-blemente el nombre ‘Branch’ ya dibujó en su mente la idea de una pesadilla dantesca. La realidad es que el manejo de branches en ver-sionadores centralizados suele convertirse en una molestia más que en una herramienta útil. Tan es así que muchos proyectos renuncian a su uso y se dedican únicamente a versionar sobre un árbol principal de código, dejando de lado una de las ventajas esenciales que propor-ciona un versionador. Pero la buena noticia es que en los versiona-dores distribuidos, y en Git en particular, el manejo de branches es, dicho llanamente, maravilloso.

Una manera de entender los branches en Git es verlos como con-textos en los que se trabaja una versión específica del código. Digamos que bajamos el código fuente de un software que utilizamos mucho y detectamos un bug. El modo Git de afrontarlo sería, luego de clonar el repositorio, crear un branch y ahí trabajar la corrección del bug.

.HERRAMIENTAS Y TECNOLOGÍASTuToriaL

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

.HERRAMIENTAS Y TECNOLOGÍASTuToriaL

14

Si además resulta que tenemos una propuesta de mejora al soft-ware, lo correcto desde el punto de vista del modo Git de trabajarlo sería crear otro branch a partir del original (o maestro) y ahí trabajar los cambios. Finalmente cuando el bug esté corregido, se integran (vía merge) con el branch maestro. Y cuando nuestros cambios es-tén hechos y probados también, se hace lo mismo desde aquel otro branch al maestro de nuevo. Así, al final, se tiene un código limpio, probado y bien versionado, todo gracias al uso de branches.

Los comandos principales para el manejo de branches son:• git branch para crear branches• git checkout para hacer cambio de contextos• git merge para unir branches

Otra característica notable del manejo de branches de Git es que los branches no se creados como subdirectorios separados como en SVN. Más bien, el directorio .git contiene toda la información (en for-ma de snapshots o diferencias entre cada archivo y sus branches), y así en un sólo directorio de trabajo del proyecto, al cambiar de contexto, todo el código del mismo directorio pasa a ese nuevo estado. Se puede cambiar entre contextos libremente y sin pérdida de información, y sin el estorbo de un directorio dedicado a cada branch del proyecto.

git branch y git checkout. Al crear un nuevo repositorio en Git, por defecto se tiene un único branch, el inicial o principal del proyecto. Se le llama master por default. El comando git branch lista todos los branches existentes actualmente en un proyecto. En caso de haber varios, uno de ellos será marcado con un asterisco, para indicar cual es el branch o contexto actual. Para crear un nuevo branch, se utiliza el comando git branch [nombre_del_branch].$ git branch testing

$ git branch

Como se puede observar, ya existe un nuevo branch en el proyec-to (testing). Este branch está hecho a partir del código en su último estado: tanto los últimos commits como los archivos con cambios que han y no han sido añadidos para versionar. Y para pasar a ese nuevo contexto y trabajar sobre él, se utiliza git checkout [nombre_del_branch]:$ git checkout testing

$ git branch

Ahora es testing el contexto actual sobre el que se trabajará en el proyecto. Si hacemos algunos cambios en un archivo, y luego regre-samos al contexto original (masterm_lang), como no se le indicó a Git que los cambios se irían a versionar en ese contexto, los cambios pasan transparentes entre contextos:$ echo “hola README” >> README.md

$ git checkout masterm_lang

Si hacemos un git status, nos indica que los cambios que no se han marcado para versionar (recuerden que new_file aún tiene cambios sin marcar) pasan entre contextos de manera transparente. Si ahora marca-mos algún cambio para versionar en uno de los contextos:$ git add new_file

$ git status -s

$ git checkout testing

$ git status -s

Como se puede observar, aquí también los cambios marcados para versionar pasan transparentes entre contextos. Git no puede sa-ber si la marca agregada para versionar es para uno u otro contexto, y sólo sabrá información más concreta hasta hacer un commit:$ git commit -m “agrego texto a new_file, como prueba”

Y ahora sí, los cambios hechos a new_file quedan en el branch testing, no en la rama principal. Si vemos el contenido de new_file, veremos que tiene el texto “hola mundo” que agregamos. Pero si nos regresamos al branch masterm_lang, veremos que new_file aquí no tiene el texto “hola mundo”. Solamente está en el branch testing, que es donde se hizo el commit de ese cambio. $ git checkout masterm_lang

$ cat new_file

git merge. Supongamos que ahora deseamos que el cambio en tes-ting quede reflejado también en masterm_lang. Lo que debe hacerse es un merge, una operación que la mayoría de las veces Git puede hacer por su propia cuenta.$ git branch

$ git merge testing

$ cat new_file

¿Pero qué pasaría si otro usuario hubiera hecho cambios a new_file sobre masterm_lang antes que nosotros hubiéramos hecho el commit? Entonces Git generaría lo que se conoce como un conflicto, que no es otra cosa sino la forma en que Git indica que no sabe como hacer el merge por sí solo y necesita de la ayuda externa de los usuarios. Los conflictos no ocurren siempre, incluso aunque muchos usuarios hagan cambios al mismo archivo muchas veces. Básicamen-te si los cambios se hacen sobre líneas diferentes del dicho archivo, Git sabrá hacer el merge sin problemas. Es cuando se hacen cambios que inmiscuyen líneas iguales en el archivo cuando Git puede verse en problemas... veámoslo con un ejemplo, recordando que aún hay un cambio sin versionar en README:$ git checkout testing

$ git add README.md

$ git commit -m “agrego cambio a README esperando generar conflicto en master”

Hasta aquí versionamos el cambio al branch testing...$ git checkout masterm_lang

$ echo “hello README” >> README.md

$ git add README.md

$ git commit -m “agrego cambio a README esperando conflicto en merge”

Ahora regresamos a masterm_lang y ahí hicimos un cambio diferente sobre el mismo archivo, en la misma línea (la última) que el cambio que se versionó en testing. Todo eso antes del merge. Y ahora a ver que pasa:$ git merge testing

$ git status -s

$ tail README.md

¿Qué sucedió? Pues que Git no supo qué hacer y generó un conflic-to al hacer el merge. Este conflicto queda marcado para Git (según el resultado de git status -s, y también dentro del mismo archivo READ-ME, como puede verse por los marcadores que se agregaron automá-ticamente al archivo en los lugares en donde ocurrió el conflicto. Para resolver el conflicto, se necesita la intervención humana. Normalmente aquí es donde los desarrolladores responsables de los cambios que oca-sionaron el conflicto se baten en duelo y se ponen de acuerdo para decidir cómo resolver el conflicto. Al final, uno de los desarrolladores deberá editar el archivo con conflicto, dejar el cambio adecuado y reti-rar las marcas de conflicto (<<<< y >>>>) que colocó Git. Esto lo puede hacer editando manualmente el archivo o con alguna herramienta de resolución de conflictos, invocando git mergetool.

git log. Un sistema que maneja tan eficientemente tanta información como Git no sería nada útil si no permitiera también mostrar de ma-nera ordenada dicha información al usuario, de forma que él pueda saber con exactitud algún pedazo que le sea realmente útil. Para eso existe git log.

Este comando tiene en realidad muchos usos y muchas formas diferentes de generar y reportar la información con que cuenta Git, por lo que veremos solamente algunos ejemplos que podrían ser útiles:$ git log

git log muestra en bloques cada uno de los commits que se han hecho dentro del branch actual. Se puede observar que entre la in-formación mostrada para cada commit, además del mensaje, autor y fecha, se da una cadena de identificación. Este identificador de los commit se puede usar como parámetro a comandos como git diff para comparar el estado actual del proyecto contra alguna versión específica.

git log puede usar algunos parametros opcionales. Con el pa-rámetro --oneline se muestra solamente el identificador corto y la descripción del mismo, para un resumen breve. Con el parámetro --graph se puede ver incluso de manera visual cómo han evoluciona-

do los branches y los posibles merge hechos entre ellos.

git tag. Para terminar con este asunto de los branches, vamos a men-cionar los tags. Casi cualquier versionador permite manejar este con-cepto (unos más fácilmente que otros). La idea detrás de un tag es tener una especie de fotografía fija del proyecto en cierto momento. De esa forma, cuando se quiera tener el código del proyecto justo como se tuvo en el momento de tomar la ‘fotografía’, simplemente uno va al tag y lo recupera.

Esto es sumamente útil cuando, por ejemplo, se tiene el proyecto en un estado listo para liberar a un entorno de producción, diga-mos que ya tenemos la versión 1.1.2 y queremos liberarla. Entonces se genera un tag del momento del proyecto deseado, se le etiqueta como ‘versión 1.1.2’ y listo. Git tiene la información que nosotros podemos usar cuando deseemos, por ejemplo regresamos el código al estado de ese tag y luego empaquetamos o compilamos o lo que fuera necesario...$ git tag -a v1.1.2

$ git log --oneline --decorate --graph

Como se puede observar, al usar el parámetro --decorate de git log (que muestra más información sobre los branches), también se muestra ahora el tag que acabamos de generar para el HEAD del repositorio. Obviamente, también se puede dar tag a alguna versión diferente al HEAD, para lo cual al comando git tag simplemente se le agregaría el identificador del commit al que deseemos ponerle el tag.

Para pasar el código de un tag a otro, se puede usar el mismo comando git checkout, pero en lugar de usar el nombre de un branch como parámetro, se usa el nombre dado al tag (también se puede usar el identificador de un commit cualquiera). El parámetro -l nos informa de todos los tags que tenga creados el repositorio:

$ git tag -l

ConclusiónEn este tutorial aprendimos los aspectos básicos para manejar un re-positorio git local. El siguiente paso es aprender a interactuar con un repositorio remoto. Por razones de espacio no se ha incluido esa sec-ción aquí, pero pueden consultarlo en la versión original y completa de este artículo, que está disponible en http://swgu.ru/sg3407

.BIOJavier Novoa es ingeniero en sistemas con maestría en ciencias de la computación con preferencia por la administración de servidores GNU/Linux y el desarrollo en Python/PHP/Java/C++. Radica en la Ciu-dad de México y es fanático de la literatura fantástica, la astronomía amateur, el ajedrez y la música rock. jstitch@gmail.com@JaviStitch

15

.HERRAMIENTAS Y TECNOLOGÍASTuToriaL

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

16

.HERRAMIENTAS Y TECNOLOGÍASnovedades

WebSocketseventos a tiempo real en nuestro navegador

››Por Gonzalo Ayuso

HTML5 ha llegado. La quinta revisión de HTML nos trae muchas novedades y los Web-

Sockets es una de ellas, que tendrá un gran impacto en la forma en que desarrollamos aplicaciones web. Los WebSockets son dos están-dares en uno: el estándar del protocolo de comunicaciones desarro-llado por el IETF; y el estándar de la API JavaScript para utilizarlos en nuestras páginas Web. En este artículo vamos a ver qué son y cómo funcionan.

AntecedentesAntes de comenzar, hagamos un poco de historia y remontemos unos años atrás. Imaginemos que queremos hacer una aplicación con co-municación a tiempo real, como por ejemplo un chat. La aplicación es muy simple. Un cuadro de texto donde el usuario introduce un mensaje, un botón para enviar y un listado con los mensajes del chat. Si nos planteamos hacer esta aplicación en un cliente pesado, el desa-rrollo es trivial. Abrimos un puerto y lo ponemos a la escucha para que actualice la lista de mensajes cuando alguien crea un mensaje nuevo. El problema está cuando queremos hacer esta misma aplicación en el navegador web. Básicamente, el dilema está en que no podemos abrir un puerto en el navegador y ponerlo a la escucha, tal y como lo haríamos con una aplicación de escritorio. Podemos hacer algo usando tecnologías como Flash o Java Applets, pero no es el escenario ideal y es muy probable que tengamos problemas con firewalls.

Si nos centramos en el protocolo HTTP, vemos que podemos mantener abierta la conexión e ir enviado información poco a poco usando tecnología Push, este nuevo modelo de aplicación Web se denomina COMET. En teoría es perfecto, pero en la práctica tiene algunos inconvenientes:

• En el servidor. Los servidores web tradicionales no están di-señados para este tipo de cosas. Nos encontramos directivas del tipo keep-alive y MaxClients. Los servidores Web, en sus con-figuraciones por default, interpretan que estas conexiones que mantenemos abiertas mucho tiempo, son scripts que se nos han quedado colgados, y las cierran.

• En el navegador. Los navegadores tampoco están preparados para mantener conexiones abiertas con el servidor durante un tiempo indefinido. En teoría funciona, pero en la práctica las conexiones terminan muriendo.

En resumen, tenemos un modelo de aplicación web llamado COMET que en teoría nos permite hacer notificaciones a tiempo real en el navegador, pero en la práctica tenemos problemas con los servidores y con los navegadores.

Para resolver los problemas en el lado del servidor podemos usar servidores alternativos a los tradicionales. Por ejemplo, un servidor he-cho con Node (node.js) puede funcionar muy bien para manejar co-nexiones de este tipo, gracias a la naturaleza no-bloqueante de Node.

Resolviendo el problema del servidor, ahora enfoquémonos en el navegador. Aquí normalmente usamos técnicas para si-mular eventos en tiempo real. Lo más común es hacer Short-Polling, que básicamente consiste en preguntar al servidor cada x segundos si ha habido algún evento, para ello se usa un timer con JavaScript (setInterval o setTimeout) o la histórica etiqueta meta http-equiv=”refresh”. Es como cuando viajamos con niños en coche y nos preguntan cada 5 segundos si falta mucho para llegar. Esta técnica cumple el propósito, pero no es escalable. Por otro lado tenemos el Long-Polling que consiste en dejar abierta una conexión hasta que haya información nueva para enviar al navegador. Tampoco es una solución ideal porque so-brecargamos los recursos de nuestro servidor, y podemos encon-trarnos con timeouts.

WebSocketsAfortunadamente, con la llegada de HTML5 nos llegan los fla-mantes WebSockets. Básicamente es la solución a todos los pro-blemas mencionados con anterioridad. Los nuevos WebSockets nos dan una interface JavaScript para manejar conexiones no bloqueantes con el servidor.

El listado 1 muestra un ejemplo de uso de WebSockets en el navegador.

17

Como podemos ver, el interface es similar al de los WebSocket. Esto viene acompañado de la parte del servidor, que socket.io la implementa por medio de node.js:

var io = require(‘socket.io’).listen(80);

io.sockets.on(‘connection’, function (socket)

socket.emit(‘news’, hello: ‘world’ );

socket.on(‘my other event’, function (data)

console.log(data);

);

);

Listado 3. Implementación de servidor en Socket IO.

Socket IO soporta los siguientes modos de transporte:

• WebSocket• Adobe® Flash® Socket• AJAX long polling• AJAX multipart streaming• Forever Iframe• JSONP Polling

Esto le permite soportar una amplia lista de navegadores y versiones, que incluye: Internet Explorer 5.5+, Safari 3+, Google Chrome 4+, Firefox 3+, Opera 10.61+, iPhone Safari, Android WebKit. Así es, incluso IE 5.5 es soportado, y todo esto usando el mismo interface para el desarrollador.

Por donde empezarGracias a Socket IO podemos tener notificaciones a tiempo real de forma sencilla y soportada por prácticamente todos los navegadores. Un sueño imposible hace unos años, al alcance de nuestra mano a día de hoy. Merece la pena echarle un vistazo.

Referencias[1] Socket IO. http://socket.io

[2] WebSocket. http://websocket.org

[3] D. Zavala. “Introducción a Node.js”. http://swgu.ru/intro_node

var ws = new WebSocket(url);

ws.onopen = function()

// When the connection opens

;

ws.onmessage = function()

// When the server sends data

;

ws.onclose = function()

// When the connection is closed

;

ws.send(‘Hi all’);

// later...

ws.close();

Listado 1. Uso directo de WebSockets en el navegador.

¿Genial, no? Entonces, del lado del servidor resolvemos nuestros problemas implementando un servidor en Node y del lado del clien-te utilizamos WebSockets. Asunto resuelto ... bueno, no en realidad, no cantemos victoria todavía. Desgraciadamente, los WebSockets no están soportados en todos los navegadores. Nuestro gozo en un pozo. Tenemos la tecnología, pero tenemos que esperar a que todos nuestros usuarios usen navegadores de última generación (incluso que los nave-gadores incorporen esta nueva especificación a sus versiones estables).

Socket IO al rescateEntonces ¿Podemos usar WebSockets hoy? Pues la respuesta es sí. Y digo sí con rotundidad gracias a una gran libreria llamada Socket IO (socket.io). Socket IO es, por decirlo de alguna manera, el jQuery de los WebSockets.

La gracia de esta genial librería es que no necesita un navegador que soporte WebSockets. Si nuestro navegador los soporta, los usará. Si por lo contrario usamos un navegador más viejo, socket.io emula-rá el comportamiento de los WebSockets usando el mejor modo de transporte soportado por ese navegador, y todo esto de una forma transparente para nosotros.

El listado 2 contiene un código en javascript que ejemplifica como podemos usar socket.io en el navegador.

<script src=”/socket.io/socket.io.js”></script>

<script>

var socket = io.connect(‘http://localhost’);

socket.on(‘news’, function (data)

console.log(data);

socket.emit(‘my other event’, my: ‘data’ );

);

</script>

Listado 2. Código para cliente con Socket IO.

.HERRAMIENTAS Y TECNOLOGÍASnovedades

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

.BIOGonzalo Ayuso es Desarrollador y arquitecto web con más de 10 años de experiencia, especializado en tecnologías open source. Puedes leerle en su blog http://gonzalo123.wordpress.com y seguirle en @gonzalo123.

18

Constantemente le pregunto a mis alumnos de la Maestría de Negocios del ITESO en Guadalajara, a los participantes del

Bootcamp en TechBA Silicon Valley y en los Startup Weekends ¿qué es más importante: un excelente producto o un excelente modelo de negocio? Y normalmente llegamos a la misma conclusión, es más importante tener un buen modelo de negocio. Tal y como menciona Henry Chesbrough: “A mediocre technology pursued with a great Busi-ness Model may be more valuable that a great technology exploited via a mediocre Business Model.”

Del artículo de “Reinventing your Business Model” de Harvard Business Review [1] destacaré dos cifras que dan una idea de la im-portancia del concepto.

1. 11 de las 27 compañías nacidas en los últimos 25 años y que han crecido hasta estar dentro de las Fortune 500 en los úl-timos diez años, lo hicieron a través de la innovación en sus mo-delos de negocio.2. Una encuesta del 2005 practicada por la Unidad de Inte-ligencia de The Economist, reportó que más del 50% de los ejecutivos creen que la innovación en el Modelo de Negocio llegará a ser más importante para el éxito que la innovación en productos y servicios.

Con el propósito de generar un entendimiento común sobre el con-cepto de Modelo de Negocio les pido hacer una reflexión, pregunten a la gente que tengan alrededor, ¿qué es un Modelo de Negocio? Apuesto a que una gran parte de ustedes obtuvieron la siguiente respuesta… “es la

manera en que hacemos dinero”. Esta respuesta es parcialmente correcta, ya que la corriente de ingresos es uno de los nueve elementos del modelo, al igual que la fórmula de rentabilidad, pero no lo es todo.

El Modelo de Negocio es cómo la compañía crea, entrega y captura valor.

Alexander Osterwalder es un renombrado consultor en innova-ción y modelos de negocio que se dio a la tarea de crear algo que hacía mucha falta: un texto metodológico completo sobre modelos de negocio. Es así que en 2010 en conjunto con Yves Pigneur publicó el libro “Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers” [2].

La metodología planteada por Osterwalder plantea de for-ma simple y puntual los elementos básicos pero suficientes para integrar el negocio. No se necesita un extenso documento con decenas o cientos de páginas que diga cómo se quieren generar los ingresos para la compañía. Debemos ser capaces de mostrar en una sola imagen todos los elementos que le dan viabilidad y sustentabilidad a nuestro negocio.

Los nueve bloques constructoresEl modelo se describe a través de nueve dimensiones o bloques que muestran la lógica de cómo una compañía pretende ganar dinero y la interacción entre cada uno de los bloques. Dichos bloques se ilustran en la figura 1.

Obviamente, la definición de modelo tendrá que ver con la nece-saria interconexión o interrelación entre todos los bloques, los cuales

Generación de Modelos de Negociopilar del emprendimiento

››Por Víctor Reyes

Fo

tog

rafí

a co

rtes

ía d

e S

anti

ago

Zav

ala.

no se pueden ver de manera aislada; unos son consecuencia de otros y por lo tanto se trata de poder construir un flujo basado en ellos. En el centro está la propuesta de valor, hacia el lado derecho a quién se entrega y cuánto nos genera y en el lado izquierdo cómo se construye y cuánto nos cuesta.

Siguiendo la lógica anterior explicaremos brevemente a qué se refiere cada bloque.

Segmento de clientes. Este es el primero de los bloques con el cual se debe iniciar la lógica del modelo, debiendo entender cuál es el racional en base al cuál vamos a segmentar al grupo de personas u organizaciones que vamos a servir, cuál es su necesidad a satisfacer y una vez entendida, se puede diseñar el modelo de negocio.

Propuesta de valor. Describe cuál es el paquete de productos y servicios que crean valor para esos segmentos específicos de clientes. Es lo que hace a las compañías únicas y diferentes y por lo cual sus clientes van a preferirlos por sobre otras empresas. Se basa en la sa-tisfacción de problemas o necesidades de los clientes entregándoles beneficios valiosos. Algunos de los elementos que crean valor para los clientes pueden ser la novedad, la mejora en desempeño, la indi-vidualización, el precio, la reducción de riesgos, la conveniencia, etc.

Canales. Cómo una compañía se comunica y llega a sus segmentos de clientes para entregar la propuesta de valor. Son los puntos de contacto que juegan un papel importante en la experiencia de usuario del cliente. Aquí la principal definición es si los canales serán directos o indirectos, lo que obviamente tiene una afectación en margen pero puede potenciar el alcance. El balance adecuado será el que maximice los ingresos.

Relaciones con clientes. El tipo de relaciones que se mantengan con los clientes es fundamental para la adquisición, retención y creci-miento de los clientes y obviamente tendrá una relación directa con el canal que se haya elegido.

Flujos de ingresos. Representa el efectivo que la empresa genera de cada segmento de clientes. Básicamente los ingresos pueden ser de dos tipos, transaccionales, de única ocasión, o recurrentes. Los

ingresos llegarán a la compañía si esta entiende bien cuál es el valor por el cual los clientes realmente están dispuestos a pagar. Aquí en-contramos varias maneras en cómo se pueden generar esos ingresos: por la venta de un producto, cobrar suscripciones, renta, licenciar propiedad intelectual, publicidad, etc.

Actividades clave. Este bloque describe las actividades más im-portantes que una compañía debe hacer para que su modelo de nego-cio funcione. Dichas actividades pueden ser divididas en producción, que tiene que ver con la entrega física de un producto; de solución de problemas o de creación de una plataforma.

Recursos clave. Este bloque incluye a los recursos o activos que se requieren para desempeñar dichas actividades clave. Los recursos pueden ser materiales, financieros, humanos y más importante aún, intelectuales como patentes, marcas, etc.

Alianzas clave. Describe la red de proveedores y socios que se requieren para que el modelo funcione adecuadamente, creando di-chas alianzas sobre todo para optimizar el modelo por economías de escala, la reducción de riesgo e incertidumbre o la adquisición de re-cursos para el desempeño de ciertas actividades. Pueden ir desde una simple relación proveedor-comprador hasta una alianza estratégica.

Estructura de costos. Cuáles son los costos que se generan a pro-pósito de las actividades y los recursos necesarios para desempeñarlos. Las estructuras de costos se pueden basar en dos enfoques principal-mente: aquellos guiados por el costo y aquellos guiados por el valor. El primer enfoque se basa en minimizar el costo al máximo posible, mientras que el segundo se centra en el costo que sea necesario para crear el valor necesario para entregar.

La expresión gráfica del modelo se lleva a cabo en lo que se llama el Business Model Canvas que proviene y recuerda al lienzo de un pintor. Normal-mente lo desarrollamos a través de talleres con expertos en los temas dentro de una empresa, y es una actividad colaborativa que busca fomentar el entendi-miento, discusión, creatividad y análisis. Se puede desarrollar de manera física en un poster en donde podemos pintar o pegar notas o de manera elec-trónica en donde ya existe la aplicación para iPad creada por el propio Osterwalder.

.EMPRENDIENDOindusTria

19

Referencias:[1] M. W. Johnson, et al. “Reinventing your Business Model”. Harvard Business Review, December 2008. http://swgu.ru/sg3405 [2] A. Osterwalder & Y. Pigneur. “Busi-ness Model Generation”. http://swgu.ru/r3406

.BIOVíctor Reyes ha tenido una trayec-toria de más de 20 años en pues-tos gerenciales y directivos en los sectores privado y público. Es ex Director de Negocios de Innova-ción del CONACYT y actualmente es fundador, cofundador y/o parti-cipante activo de varias iniciativas que buscan impulsar el emprendi-miento e innovación tecnológica como MexicoInnova, INPROTEC, Startup Dojo, Mexican VC, Startup Weekend, TechBA Silicon Valley. @vmreyesp

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

“El ModElo dE NEgocio Es cóMo lacoMpañía crEa, ENtrEga y captura valor.”

Figura 1. Los 9 bloques del modelo de negocio.

20

SG Conference & Expo 2011Integrando la comunidad de Profesionistas de TI

››Por Equipo organizador

La sexta edición del evento insignia de Software Gurú se llevó a cabo exitosamente el pasado 7 y 8 de septiembre en la Cd. de México. A lo largo de dos días, el evento logró reunir a más de 800 dignos representantes de la industria de TI, así como a reconocidos ponentes

nacionales e internacionales, contando con la participación de prestigiadas empresas de la industria de software a nivel global.Como ya es costumbre este evento fué el punto de reunión de los más destacados profesionistas, hackers y emprendedores de TI, que

compartieron su experiencia y conocimiento fomentando una excelente dinámica de networking.Con gran gusto nos encontramos con asistentes que nos acompañan y colaboran con SG desde el primer congreso, y es un orgullo saber

que de alguna manera hemos apoyado al desarrollo de estos profesionistas.

21

.ESPECIALreseña

La entradaLa inauguración se llevó a cabo por el Director y socio fundador de Software Gurú, Pedro Galván, quien además de reconocer el esfuerzo de los participantes por asistir al evento, compartió con la audiencia el futuro y visión de SG, presentando nuevos productos como SG Ta-lento y Nearshore Link. El evento fué moderado por la coordinadora editorial de la Revista SG, Vanessa Amaya, y contó con la participación de Elizabeth Argüello, Directora de Economía Digital de la Secretaría de Economía, quien nos compartió su visión de la industria de TI, así como los avances que han tenido los diversos Programas que la apoyan.

El plato fuerteY de la entrada nos fuimos directo al plato fuerte, ya que los conferen-cistas magistrales nos compartieron una diversa gama de interesantes temas. Iniciamos con el keynote “Fact and Fallacies of Software De-velopment” presentado por Venkat Subramaniam, fundador de Agile Developer, Inc. quien demostró su experiencia de haber entrenado y asesorado a miles de desarrolladores de software y con una ponencia sumamente amena logró la participación activa de la audiencia.

Finalizando el primer día, contamos con la plática de Brad Hipps, Gerente de Soluciones de software en HP, quien compartió su expe-riencia en el ciclo de vida de las aplicaciones, y su implementación en diversas organizaciones a nivel mundial.

No podía faltar la participación de expertos y apasionados desarro-lladores de software Mexicanos, como fué el caso de Raúl Guerrero, quien nos platicó sobre la Gestión del Proceso de Desarrollo utilizando Scrum, donde compartió experiencias de su trabajo actual en Micro-soft como Especialista en Herramientas de Desarrollo, así como reco-mendaciones gracias a su participación activa en Comunidades.

Ash Maurya inició las conferencias del segundo día, con el tema “Running Lead”, creador del libro que lleva el mismo nombre, ma-terial de referencia esencial para los emprendedores en la web, de-mostrando la razón por la cual es una de las figuras más reconocidas en el ámbito de los nuevos emprendimientos basados en tecnología.

Gustavo Garnica, fue el encargado de dar el toque final al plato fuerte, quien gracias a su amplia experiencia como Arquitecto Senior de Middleware, en proyectos para clientes en México y LA, nos compartió la visión altamente esperada sobre el futuro de la plataforma Java.

Una variada ensalada: Ignite sobre emprendimientoCon una combinación de múltiples ponentes, quienes en 5 minutos nos compartieron sus ideas, perspectivas, propuestas relacionadas a la creación y ejecución de startups en México, se presentó el Ignite dedicado al emprendimiento tecnológico.

Para acompañar: Más de 20 sesiones Para compartir el conocimiento y la práctica real, contamos con la participación de los expertos locales, combinando una interesante agenda de conferencias.

Alcanza para todos: La Feria de ReclutamientoAcompañando al lanzamiento de SG Talento, se realizó la feria de reclutamiento “Buscando Talento”, organizada en conjunto con la empresa Empleos TI, durante la cual las empresas participantes contactaron con diversos profesionistas. Las empresas participantes fueron: Kelly IT Resources, 4thSource, Neoris, Porto Mx, Adecco, Congnizant, Tacit Knowledge, Softtek, IDS, Hildebrando, ABS, ScreenIT, Randstad, e-global Consultores, Nearsoft, IBM, Oracle, Alpha Consultoria, App Studios, Global Lynx, Extend Solutions, In-fotec, Ironbit y Ultrasist.

La cereza del pastel: AppCircusAppCircus es una feria itinerante, escaparate de las aplicacio-nes móviles más creativas e innovadoras, que en esta ocasión se presentó en SG Conference & Expo. Durante esta dinámi-ca 10 emprendedores presentaron sus aplicaciones. El ganador fue José Balcázar de la empresa Huawei, quien ahora tiene la oportunidad de pertenecer a las apps nominadas para los Mobi-le Premiere Awards (MPA) 2012 en Barcelona. AppCircus fue patrocinado por BlueVia.

La CharlaTodo momento fue aprovechado para networking, visitas a Expo, las comidas, y los deliciosos “startup-waffles”, que fomentaron la convi-vencia entre los participantes, quienes crearon nuevas relaciones y se reencontraron con colegas.

El Postre: La ExpoLa Expo contó con la participación de diversas empresas y organis-mos, a quienes reconocemos su compromiso con la industria y agra-decemos su apoyo: Oracle, HP, Infotec, Pronatura, Microsoft, Global Lynx, México First, Blackberry, Qualtop, Alpha Consultoría, Vinkos, Fumec, Ironbit, Ultrasist, AppStudios, CIAPEM, CANIETI, AMITI, emprende.la, CITI Tabasco, IJALTI y al Consejo de Software de Nuevo León. En especial agradecemos a Secretaría de Economía por apoyar al evento mediante el programa Prosoft 2.0.

El Digestivo: La Noche de casinoSiendo un evento tan esperado, quisimos celebrarlo en grande jugan-do y apostando, donde los asistentes vivieron una noche divertida, con baile, bocadillos y brindis. Y para los que no les late el casino, jugaron como niños con el Kinect. El ambiente era de total algarabía y esta se agrandó al participar en la subasta de grandes premios.

La preparación y realización del evento fueron una ardua labor, que finalmente gracias a la mezcla de contenidos de alta calidad, en-tusiastas asistentes, y una logística excepcional, logramos un delicioso menú, consolidando una vez más a SG Conference & Expo como un evento de clase mundial.

La mayoría de nosotros, los profesionistas de software contemporáneos, llevamos toda nuestra vida profesional programando software cuya interacción con el mundo físico se limita a recibir comandos de un teclado o mouse y entregar resultados desplegándolos en una pantalla. Cier-tamente, esta modalidad de cómputo ha generado un mercado muy grande, y nos ha dado empleo, alegrías, tristezas y muchas anécdotas.

Sin embargo, no debemos olvidar que “hay un mundo allá afuera”, un mundo físico con distancia, peso, luz, sonido, tacto. Y en ese mundo también hay infinidad de oportunidades donde los sistemas de cómputo pueden aportar valor.

El cómputo físico se refiere a la utilización de dispositivos electrónicos para crear objetos interactivos que pueden inte-ractuar con el mundo físico utilizando sensores y accionadores controlados por el comportamiento programado en un micro-controlador.

Anteriormente, crear sistemas de cómputo físico era algo re-servado para unos cuantos, no solo por la complejidad y diversi-dad de conocimientos requeridos, sino por la poca accesibilidad y alto precio de los materiales necesarios, así como la falta de estan-darización. Pero en los últimos años esta situación ha mejorado

significativamente, y hoy en día contamos con herramientas más sencillas, materiales accesibles, mayor estandarización y mucho mayor apertura. Todo esto ha provocado que el interés y popula-ridad del cómputo físico esté explotando.

En las siguientes páginas hemos concentrado diversos artícu-los con información sobre algunos de los aspectos que considera-mos más relevantes sobre el cómputo físico, desde el fenómeno provocado por Arduino y el open hardware, hasta la construcción y programación de robots.

Pero antes de continuar, les recordamos un pasaje del libro “The Tao of Programming” the Geoffrey James.

“Sin el viento, el pasto no se mueve. Sin software, el hardware es inútil.”

El Despertar del Cómputo Físico

22

.PRINCIPAL

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

23

24

.PRINCIPAL

La finalidad es tener bien claro qué quieres que tu robot haga, por-que no sólo para movimientos está hecho, sino también para sentir, interactuar, e incluso pensar por medio de inteligencia artificial.

Los robotsExisten distintas opciones de robots humanoides en el mercado. Po-siblemente el más popular es el robot NAO fabricado por la empresa francesa Aldebaran Robotics, y que es el utilizado en la competencia internacional Robocup, donde equipos de todo el mundo programan equipos de robot autónomos que compiten jugando futbol.

Herramientas y tecnologías de programaciónAntes, programar un robot era una tarea complicada. Sin embargo, hoy en día se cuenta con herramientas poderosas y bastante amigables. Generalmente, la programación de robots se clasifica en varios niveles de complejidad con la finalidad de que los usuarios puedan ir esca-lando sus conocimientos y cada vez tener un mayor control sobre el comportamiento del robot y realizar actividades más avanzadas.

En el nivel básico está la programación visual utilizando ambientes de desarrollo como Choregraphe. En estas herramientas se cuenta con librerías de bloques de comportamiento predefinidos y se programa visualmente el comportamiento del robot al arrastrar y conectar dichos bloques, creando así una secuencia de actividades o coreografía. La fi-gura 1 muestra una pantalla de Choreographe.

Figura 1. El ambiente de desarrollo Choreographe

El siguiente paso es poder programar tus propios bloques de com-portamiento, para integrarlos en tus coreografías. Esto típicamente se hace un lenguaje de programación de alto nivel. En el caso de Chore-graphe, se puede hacer en Python o urbiscript (un lenguaje de scripting para robótica). Otras herramientas utilizan el lenguaje RoboBasic, que

como su nombre lo indica es un lenguaje tipo Basic, pero especiali-zado y orientado a robots. Este lenguaje te proporcionará comandos específicos para controlar al humanoide. Por medio de los simuladores de los ambientes de desarrollo, puedes probar fácilmente los nuevos comportamientos y comprobar que haces correctamente tu trabajo.

Otra posibilidad consiste en crear nueva funcionalidad utilizando información de lo que el robot está viendo y sintiendo por medio de sus sensores. Este tipo de programación típicamente se hace en lengua-jes como Python o C++, y aprovecha los SDKs que ofrecen los robots (la gran mayoría de los robots actuales cuenta con SDKs).

Quienes estén acostumbrados a desarrollar aplicaciones con tecnolo-gías de Microsoft tal vez se sientan en casa usando Microsoft Robotics Developer Studio, la cual aprovecha las plataformas .NET y XNA además de soportar el sensor Kinect. Adicionalmente, ya hay quienes están experi-mentando con programar y controlar robots en tiempo real. Por ejemplo, la Universidad del Norte de Carolina lo está haciendo con éxito, y han lo-grado que un robot NAO sirva azúcar en una taza de café con una cuchara, incluso sorteando obstáculos inesperados. El campo de la programación de robots humanoides se está desarrollando muchísimo. Tan es así, que la competencia RoboCup tiene como objetivo que para el año 2050 un equi-po de robots pueda competir en un juego de futbol contra los campeones de la FIFA. Por otro lado, algunas empresas ya han comenzado a crear app stores para aplicaciones robóticas, de forma que usuarios de todo el mundo puedan descargar los desarrollos de otros.

Robótica humanoide en MéxicoEn México también se realiza investigación en el campo de la robótica. Uni-versidades como el ITAM, UNAM, INAOE e ITESM cuenta con huma-noides para que los alumnos puedan programarlos. En el caso del ITAM, cuentan con robots NAO desde el 2008 que participaron en RoboCup en la Liga de Plataforma Estándar (esta primera versión se entregó únicamente a 20 instituciones del mundo). Una excelente noticia es que la edición 2012 de RoboCup se llevará a cabo en la ciudad de México en junio del 2012. Esto seguramente impulsará el interés en nuestro país por la robótica.

Referencias:[1] “Configuración de NAO”. http://www.naomexico.mx/html/config.html [2] Canal de videos de Aldebaran Robotics. http://www.youtube.com/aldebaranrobotics[3] RoboCup. http://www.robocup.org

El ABC de la Programación de un Robot Humanoidemás fácil de lo que crees

››Por Miguel Ángel Ramírez

Abrir la puerta, jugar futbol, recordarle a una persona que tiene que tomar sus medicinas, leer co-rreos electrónicos o bailar, son algunas de las funciones que los robots humanoides pueden realizar actualmente. Para lograrlo, existe software que permite simular comportamientos en un robot, aplicaciones para programar actividades complejas y herramientas de monitoreo. Esto se hace por medio de los ambientes de desarrollo y Kits de Desarrollo de Software (SDK) de los robots.

.BIOMiguel Ángel Ramírez es Director de Tecnología en GRE, empresa mexicana dedicada a la comercialización de soluciones robóticas. Miguel es egresado de la Universidad La Salle como Ingeniero en Cibernética. www.naomexico.mx

25

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

.PRINCIPAL

El movimiento de hardware abierto o libre, busca crear una gran librería accesible para todo el mundo, lo que ayudaría a las compañías a reducir en millones de dólares en trabajos de diseño redundantes. Ya que es más fácil tener una lluvia de ideas propues-ta por miles o millones de personas, que por solo una compañía propietaria del hardware, tratando así de que la gente interesada entienda cómo funciona un dispositivo electrónico, pueda fabri-carlo, programarlo y poner en práctica esas ideas en alianza con las empresas fabricantes, además se reduciría considerablemente la obsolencia programada y en consecuencia evitaríamos tanta ba-sura electrónica que contamina el medio ambiente. Al hablar de open hardware hay que especificar de qué tipo de hardware se está hablando, ya que está clasificado en dos tipos;

• Hardware estático. Se refiere al conjunto de elementos materiales de los sistemas electrónicos (tarjetas de circuito impreso, resistencias, capacitores, LEDs, sensores, etcétera).• Hardware reconfigurable. Es aquél que es descrito me-diante un HDL (Hardware Description Language). Se de-sarrolla de manera similar a como se hace software. Los di-seños son archivos de texto que contienen el código fuente.

Para tener hardware reconfigurable debemos usar algún len-guaje de programación con licencia GPL (General Public Li-cense). La licencia GPL, al ser un documento que cede ciertos derechos al usuario, asume la forma de un contrato, por lo que usualmente se la denomina contrato de licencia o acuerdo de licencia. La Organización Europea para la investigación Nuclear (CERN) publicó el 8 de julio de 2011 la versión 1.1 de la Licen-cia de Hardware Abierto.

Existen programas para diseñar circuitos electrónicos y aprender de la electrónica como EDA (Electronic Design Au-tomation) y GEDA (GPL Electronic Design Automation), son aplicaciones de software libre que permitan poner en práctica las ideas basadas en electrónica.

Es posible realizar el ciclo completo de diseño de hardware re-

configurable desde una máquina con GNU/Linux, realizándose la compilación, simulación, síntesis y descarga en una FPGA. Para la compilación y simulación se puede usar GHDL (http://ghdl.free.fr) junto con GTKWave (http://gtkwave.sourceforge.net), y para la síntesis el entorno ISE de Xilinx. Este último es software comercial pero existe una versión gratuita con algunas restricciones.

Sabemos que tanto en el caso del software como el hardware, libre no es lo mismo que gratis. Específicamente, en el caso del hard-ware, como estamos hablando de componentes físicos que son fabri-cados, la adquisición de componentes electrónicos puede ser costosa. Aun así, es un campo que no solo es apasionante sino que también tiene mucho futuro y representa grandes oportunidades.

Evolución digitalLa idea del open hardware no solo es importante en la aplica-ción del modelo comunitario y colaborativo para el crecimiento intelectual libre sobre los sistemas electrónicos digitales, sino también para impulsar a nuevos talentos y desarrollo tecnológi-co en México, evitar la fuga de cerebros e incentivar la creación de empresas de hardware para no depender tanto de tecnologías extranjeras.

El principal desafío es lograr que más gente se interese en el Open Hardware para crear grupos de trabajo y pasar del primer problema que es la iniciativa, para posteriormente interesarse por la investigación y fabricación de los componentes. Sabemos que esto no será fácil, pero confío plenamente en que poco a poco podremos lograrlo.

Open Hardwareel hardware también puede ser libre››Por Antonio Toriz

El término open hardware, u open source hardware, se refiere al hardware cuyo diseño se hace publicamen-te disponible para que cualquiera pueda estudiarlo, modificarlo y distribuirlo, además de poder producir y vender hardware basado en ese diseño. Tanto el hardware como el software que lo habilita, siguen la filo-sofía del software libre. Hoy en día, el término “hágalo usted mismo” (DIY por sus siglas en inglés) se está popularizando en el hardware gracias a proyectos como Arduino que es una fuente abierta de prototipos

electrónicos, una plataforma basada en hardware flexible y fácil de utilizar que nació en Italia en el año 2005.

.BIOAntonio Toriz Cureño (@ingbruxo) es egresado de la Universidad Autónoma del Estado de México, Campus Valle de Chalco. Actual-mente trabaja como profesor de Preparatoria. Sus áreas de especiali-dad incluyen ingeniería inversa de computadoras, hardware libre y se-guridad informática. Lee su blog en http://antoniotoriz.blogspot.com

En este artículo vamos a explicar como utilizar el SDK de Kinect para inicializar y mostrar las diferentes cámaras y funciones de reco-nocimiento de gestos.

PrerrequisitosPara poder realizar este tutorial es necesario contar con lo siguiente:

• Sensor Microsoft Kinect.• Cable conversor de puerto KINECT a USB (este cable esta incluido cuando compras el KINECT por separado, para la versión que viene con el Xbox 360 no viene con esta extensión, pero se puede conseguir fácilmente en tiendas de electrónicos). • Computadora con Microsoft Windows 7 (en sus diferentes versio-nes) compatible con tarjetas gráficas con Direct X 9.0c• Microsoft Visual Studio 2010 Express o cualquier edición • Microsoft .NET Framework 4.

Adicionalmente necesitamos instalar el Kinect SDK, el cual se puede descargar en http://swgu.ru/r3401

ComencemosLo primero que hacemos es crear un nuevo proyecto en Visual Studio, el tipo de proyecto que necesitamos es “Aplicación WPF”, nombraremos este proyecto “HelloWorldKinect”.

Posteriormente, en la vista de diseño nos situamos en el código XAML y colocamos dos controles de tipo imagen. El primer control, de preferen-cia que abarque toda la ventana, lo llamaremos depthImagen y lo utilizare-mos para la cámara de profundidad. El segundo control, que llamaremos videoImage, mostrará el contenido de la cámara de video. Éste último po-demos hacerlo más pequeño y será más pequeño y lo posicionaremos en la esquina superior derecha.

Para poder utilizar las librerías de Kinect en nuestro proyecto de-bemos agregar la referencia correspondiente. Para ello, en la pestaña del Explorador de Soluciones hacemos click derecho en la carpeta Re-ferences, seleccionamos Add Reference y seleccionamos la referencia Microsoft.Research.Kinect.

El códigoPara agregar la referencia desde el código de nuestro formulario, vamos a

la parte superior de nuestro código donde están los “using” y agregamos Microsoft.Research.Kinect.Nui.

using Microsoft.Research.Kinect.Nui;

Para poder manejar el dispositivo, haremos referencia a este desde una variable de tipo Runtime. Así que debemos declarar dicha variable.

Runtime runtime = new Runtime();

A continuación registramos métodos para manejar los eventos Loaded y Unloaded del control MainWindow, y tam-bién registramos métodos para manejar la señal de las dos cá-maras de Kinect: la de video y la de profundidad. El listado 1 muestra esto.

public MainWindow()

InitializeComponent();

this.Loaded += new RoutedEventHandler(MainWindow_Loaded);

this.Unloaded += new RoutedEventHandler(MainWindow_Unloaded);

runtime.VideoFrameReady += new EventHandler

<Microsoft.Research.Kinect.Nui.ImageFrameReadyEventArgs>

(runtime_VideoFrameReady);

runtime.DepthFrameReady += new EventHandler

<ImageFrameReadyEventArgs>(runtime_DepthFrameReady);

Listado 1.

En el método MainWindow_Loaded que es la que llamamos cuando se carga el dispositivo, vamos a inicializar el dispositivo y llamar dos rutinas, una para el stream de video (cámara RGB) y otra para el stream de profun-didad. El listado 2 muestra esto.

26

.PRINCIPAL

Hola Mundo Kinectobteniendo datos de las cámaras de kinect

››Por Hugo Fernández

Como muchos de ustedes saben, Kinect es un accesorio para el Microsoft XBox 360 que consiste en una cámara sensible a la profundidad, lo que le permite identificar lo que ve en un contexto de 3 dimensiones. En principio fue pensado como accesorio para videojuegos, pero sus capacidades permiten que también sea un dispositivo útil para otros fines. De hecho, apenas algunos días después de su lanzamiento, comenzaron a aparecer drivers de Kinect creados por desarrolladores

independientes. Reconociendo este potencial, Microsoft liberó posteriormente un SDK oficial.

27

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

.PRINCIPAL

void MainWindow_Loaded(object sender, RoutedEventArgs e)

runtime.Initialize(Microsoft.Research.Kinect.Nui.RuntimeOptions.UseC-

olor |

Microsoft.Research.Kinect.Nui.RuntimeOptions.UseDepth);

runtime.VideoStream.Open(ImageStreamType.Video, 2,

ImageResolution.Resolution640x480, ImageType.Color);

runtime.DepthStream.Open(ImageStreamType.Depth, 2,

ImageResolution.Resolution640x480, ImageType.Depth);

Listado 2.

En el método para manejar el evento unloaded, simplemente nos limi-tamos a cerrar el dispositivo.

void MainWindow_Unloaded(object sender, RoutedEventArgs e)

runtime.Uninitialize();

Listado 3. Código para cerrar el dispositivo.

Como último código vamos definir los métodos VideoFrameReady y DepthFrameReady que manejan la recepción del video y la profundidad respectivamente. El contenido de ambos métodos es muy similar, con muy ligeras variaciones.

Comenzamos creando una variable de tipo PlanarImage y asignándo-le el valor del atributo ImageFrame.Image de nuestro argumento, el cual siempre tiene la imagen que está tomando la cámara en ese momento. Después definimos una variable de tipo BitmapSource cuyo valor es cons-truido a partir del stream correspondiente, pasándole como parámetros, el ancho, el alto, los DPI de cada imagen (por defecto son 96), el formato de sus pixeles en lo que la diferencia de que una es RGB o BGR32 para el vi-deo y para profundidad daré una paleta de colores gris de 16 bits o Gray16, luego los bits en memoria a partir de la variable image. Por último, en cada método se asigna el BitmapSource que definimos, como valor del atributo del control de imágen que definimos en un inicio, videoImage para el con-trol de video y depthImage para el control de profundidad.

void runtime_VideoFrameReady(object sender,

Microsoft.Research.Kinect.Nui.ImageFrameReadyEventArgs e)

PlanarImage image = e.ImageFrame.Image;

BitmapSource source = BitmapSource.Create(image.Width, image.Height,

96, 96,

PixelFormats.Bgr32, null, image.Bits, image.Width * image.BytesPer-

Pixel);

videoImage.Source = source;

void runtime_DepthFrameReady(object sender, ImageFrameReadyEventArgs

e)

PlanarImage image = e.ImageFrame.Image;

BitmapSource source = BitmapSource.Create(image.Width, image.Height,

96, 96,

PixelFormats.Gray16, null, image.Bits, image.Width * image.BytesPer-

Pixel);

depthImage.Source = source;

Listado 4. Métodos VideoFrameReady y DepthFrameReady.

Nuestro código está listo, ahora solo corremos la aplicación presionan-do F5 y podremos ver en nuestra pantalla la señal capturada por el Kinect.

No se incluye aquí el screenshot de la imagen generada por el sensor de profundidad porque son tonalidades muy obscuras que no se distinguen en la revista impresa, pero te invito a que lo intentes, es algo bastante sencillo.

El código utilizado en este artículo está disponible en http://swgu.ru/sg3400 Este código prácticamente es el mínimo esencial preestablecido por Microsoft para comenzar a trabajar con el Kinect.

La versión original de este artículo se encuentra publicada en http://swgu.ru/

sg3403 Fue editada y publicada en Software Guru con permiso del autor.

Referencias:[1] “Kinect for Windows SDK”. http://swgu.ru/sg3402

[2] “The Kinnect Effect”. http://swgu.ru/sg3404

.BIOHugo Fernández es cofundador y director de CIACOM Systems en Venezuela. Es Microsoft Certified Technology Specialist y se especia-liza en el desarrollo de aplicaciones web. @hughfernandez

Las personas que desean construir aplicaciones robóticas se en-cuentran con que existe una gran variedad de robots disponibles en el mercado, con poca estandarización entre ellos y gran variedad en capacidades y precios. Ante esta problemática, el equipo de Microsoft Robotics se dio a la tarea de definir las características esenciales de un robot que aproveche los servicios de RDS. El objetivo es que las personas puedan facilmente construir su propio robot, o que terceros construyan y vendan robots “listos para usarse”, de manera que los desarrolladores pueden concentrarse más en construir las aplicacio-nes del robot, que en construir el robot en sí. El resultado de este es-fuerzo es la “RDS Reference Platform”. Esta plataforma de referencia es una guía que describe el diseño recomendado para crear un robot “real” (es decir, un robot físico) que pueda operarse con RDS.

MARKEl diseño robótico de referencia utiliza al sensor Microsoft Kinect, el cual provee una cámara de video, sensor de profundidad 3D y micrófono. Este diseño fue bautizado como MARK (Mobile Auto-nomous Robot using Kinect). El diseño del MARK se basa en cuatro principios: mobilidad, autonomía, interactividad y extensibilidad.

La mobilidad es provista por una tracción diferencial, la cual es fácil de controlar y permite que el robot gire en su mismo lugar.

Para ser autónomo, el robot recurre a una computadora a bordo. Las capacidades avanzadas como visión computarizada, reconocimiento de voz, o conectividad a redes, requieren capa-cidad de procesamiento mucho mayor a la que proveen los mi-crocontroladores de bajo rango. Incorporar una PC en el diseño también permite comunicación inalámbrica con otras PCS y/o robots por medio de WiFi.

La interactividad considera dos aspectos: la interacción humano-robot, y la interacción del robot con el ambiente. El campo de la robótica personal tiene la necesidad de interfaces de usuario sencillas y confiables. La interactividad es facilita-da por la inclusión del sensor Kinect, lo cual puede simplifi-car dramáticamente la programación de la interfaz de usuario, proporcionando datos 3D e información esqueletal. Los datos 3D también son muy útiles para que el robot pueda desplazarse exitosamente a través de obstáculos.

La extensibilidad es inherente al diseño de referencia ya que no especifica detalles de bajo nivel, por lo que no está restringido a una construcción en particular. Este permite que los usuarios y partners de Microsoft Robotics puedan cambiar piezas o variar el diseño siem-pre y cuando se respeten los aspectos fundamentales.

Arquitectura de hardware.La figura 1 muestra el ejemplo de una implementación de un robot MARK.

Figura 1. Ejemplo de implementación de un robot MARK.

A continuación se describe de forma general el hardware de este robot.

Bases. Se requiere un mínimo de dos bases o plataformas en el robot. En la base inferior va el sistema de tracción y en la superior va la computadora y el Kinect. La base de mayor tamaño (típicamente la inferior) debe ser circular y ningún componente debe rebasar su circunferencia, esto permitirá que el robot pueda girar en su lugar sin golpear objetos externos. Se recomienda que las bases tengan un diá-metro menor a 60 cm para que puedan pasar por las puertas de una casa. La base superior debe tener un soporte para montar la cámara del Kinect. Para maximizar el campo de visión del Kinect, la altura ideal a la que se debe montar es a 60 centímetros del suelo.

Sistema de tracción. La tracción diferencial consiste en dos ruedas cuya velocidad puede variar de manera independiente. Los motores tí-picamente se controlan utilizando circuitos de tipo puente H (H-brid-

28

.PRINCIPAL

Diseño de un Robot Compatible con RDSconoce a mark

››Por Pedro Galván

Microsoft Robotics Developer Studio (RDS) es una plataforma para el desarrollo de aplicaciones robóticas. RDS provee un framework de programación, ambiente de ejecución (runtime), herra-mientas para creación y simulación de aplicaciones, ejemplos de código, plantillas y tutoriales entre otras cosas. En este artículo veremos los aspectos fundamentales de un robot diseñado para operar aplicaciones creadas con RDS.

ge). El sistema de tracción considera: las ruedas, el eje de las ruedas, los motores que las mueven, los sensores de rotación de las ruedas (wheel encoder), los puentes H, y los accesorios de montaje. Se recomienda utilizar motores silenciosos, no solo para evitar la molestia del ruido, sino también porque afecta la capacidad de reconocimiento de voz. Dado que la tracción diferencial consiste de solamente dos ruedas, para que el robot tenga estabilidad se recomienda agregar ruedas (una al frente y otra atrás) para que den estabilidad. Estas ruedas deben ser giratorias para no obstruir el desplazamiento y rotación del robot.

Sensores de proximidad. A pesar de que podríamos utilizar el sensor de profundidad del Kinect para detectar obstáculos y evadir-los, se recomienda tener sensores de proximidad dedicados para la evasión de obstáculos. Se debe incluir al menos dos tipos distintos de sensores, ya que combinar distintos tipos incrementa la probabilidad de detectar obstáculos. Por ejemplo los sensores infrarrojos no detec-tan vidrio pero los de sonar sí, asímismo hay objetos que no son bien detectados por los de sonar pero sí por los infrarrojos.

Controlador de I/O. El controlador de I/O, conocido como brick (ladrillo) es una tarjeta de circuitos que actúa como interfaz entre el hardware del robot y la PC.

Sistema de energía. La energía para el robot debe ser provista por una o más baterías recargables. Se recomienda utilizar baterías de 12V tipo SLA (Sealed Lead Acid). Los componentes del robot que requieren energía incluyen: Kinect (12V a 1.1A), motores y controladores, senso-res de proximidad, controlador IO. Por simplicidad, la computadora a bordo puede utilizarse con su batería por lo que no es necesario contem-plarla en la lista de componentes soportados por el sistema de energía.

Arquitectura de softwareLa figura 2 ilustra a grandes rasgos la arquitectura de software de la plataforma de referencia del RDS.

29

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

.PRINCIPAL

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

Figura 2. Arquitectura de software de la plataforma de referencia.

En la capa superior tenemos servicios de alto nivel que pue-den ser provistos por RDS, terceros, o creados por el desarrollador. Un servicio en esta capa que ya está incluido como parte del RDS es el Robot Dashboard, un aplicativo que funciona como consola maestra para permitir al usuario controlar al robot y consultar su estatus. Otro servicio de esta capa que ya es provisto por RDS es el de evasión de obstáculos.

Los servicios de bajo nivel son una capa de abstracción de hard-ware. Proveen servicios para interactuar con el hardware (Kinect, sistema de tracción, sensores) mediante el controlador de I/O. Los servicios de esta capa son programados por el fabricante del robot, o el usuario en caso de estar construyendo su propio robot.

El CCR (Concurrency and Coordination Runtime) y DSS (De-centralized Software Services) son componentes de RDS. Todos los servicios se ejecutan en el contexto de un nodo DSS, y varios nodos DSS se pueden comunicar entre sí a través de una red.

RDS está basado en .NET, el cual a su vez opera sobre el sistema operativo Windows.

En la capa más baja está el hardware. Algunos dispositivos, como el control de Xbox están directamente soportados por drivers para Windows. El controlador de I/O contiene firmware que se comunica via Windows utilizando un puerto serial, USB, red u otro medio.

Para crear aplicaciones robóticas que funcionen con RDS se re-quiere una computadora con el siguiente software: Windows 7 (32-bit o 64-bit), Visual Studio 2010 Express o superior, Kinect for Win-dows SDK (y prerrequisitos asociados), Robotics Developer Studio 4 (y prerrequisitos asociados).

ConclusiónHemos visto algunos aspectos fundamentales para el diseño de un robot con RDS. Te invito a que consultes la especificación completa [2] y que comiences a desarrollar aplicaciones robóticas. Te comento que RDS incluye una versión simulada de esta plataforma de referen-cia, de modo que puedes comenzar a desarrollar aplicaciones robó-ticas en un ambiente simulado sin necesidad de contar con el robot físico. La figura 3 muestra este ambiente de simulación.

Referencias:[1] Microsoft Robotics. http://www.microsoft.com/robotics

[2] “RDS: Reference Platform Design Specification”. http://swgu.ru/sg3409

Figura 3. Ambiente de simulación de RDS.

30

.PRINCIPAL

En este artículo veremos como se hace un “Hola Mundo” en Arduino.

El hardwareDado que Arduino es open hardware, tú mismo puedes construir tarjetas guiándote en los esquemas de diseño, o puedes comprar tar-jetas preconstruidas. Para este ejercicio nos basaremos en una tarjeta Arduino Uno, que es la más básica y se puede adquirir por alrededor de 40 dólares. La figura 1 muestra una imagen.

Figura 1. Una tarjeta Arduino Uno

El softwareLas tarjetas Arduino se programan en un ambiente de desarrollo (IDE) basado en el lenguaje Processing, que es un lenguaje bastante sencillo. Ya que tienes tu programa listo, el IDE lo convierte a C, compila un binario y lo carga al microprocesador. El ciclo de progra-mación es básicamente el siguiente:

1. Conecta la tarjeta a tu computadora via USB2. Escribe el programa en el IDE.3. Envía el programa a la tarjeta y espera a que se reinicie.4. La tarjeta ejecuta el programa.

El códigoNuestro hola mundo consistirá en hacer que un LED (diodo de luz) se prenda y apague. Para ello, conectamos nuestra tarjeta a la computadora, y conectamos un LED en el pin digital #13.

Nota: La pata larga es el ánodo, el cual va al pin, y la pata corta es el cátodo que va a tierra. El listado 1 muestra el código que necesitamos.

const int LED = 13;

void setup()

pinMode(LED, OUTPUT);

void loop()

digitalWrite(LED, HIGH);

delay(1000);

digitalWrite(LED, LOW);

delay(1000);

Listado 1. Código para prender y apagar LED

El código es bastante sencillo. Primero definimos una constan-te para indicar el número de pin donde tenemos el LED. Luego tenemos el método obligatorio setup() que es donde hacemos las configuraciones necesarias para ejecutar un programa. En nuestro caso, estamos indicando que queremos usar el pin 13 como salida (los pines digitales pueden usarse ya sea como entrada o salida). Posteriormente tenemos el método obligatorio loop() el cual ejecu-ta el ciclo maestro del programa. En nuestro ciclo lo que estamos haciendo es prender el voltaje del LED al enviarle una señal HIGH, esperar mil milisegundos, bajar el voltaje del LED al enviar una señal LOW, y esperar. Este ciclo se ejecutará de forma continua mientras el sistema se encuentre encendido.

Como has podido constatar, Arduino es muy sencillo. Te reco-miendo que le hagas caso a ese gusanito curioso dentro de ti y consi-gas cuanto antes una tarjeta y empieces a jugar.

Referencias:[1] Arduino Homepage. http://www.arduino.cc

[2] M. Banzi. “Getting Started with Arduino”, 2nd edition. Make Books, 2011.

Conociendo a Arduinohola mundo con leds

››Por Pedro Galván

Arduino es una plataforma abierta para cómputo físico que se basa en hardware y soft-ware sencillo y libre. Los sistemas Arduino pueden sondear el ambiente al recibir infor-mación de una gran variedad de sensores, y pueden afectar al ambiente al controlar luces, motores u otros actores.

http://swgu.ru/sg34sgcampus

32

Hoy que estoy en el año 2015 y miro hacia atrás, me pregunto como es que yo —al igual que la mayoría de los CIOs— vivimos durante tantos

años bajo la falsa noción de que el hardware era barato. En ese entonces permitíamos que la mayoría de las aplicaciones corrieran sobre hardware dedicado. Adicionalmente, acos-tumbrábamos comprar hardware con capacidad de sobra, para disminuir el riesgo de problemas de desempeño. Para ser francos, tampoco hacíamos planeación de la capacidad, porque no queríamos conocer la respuesta.

Cuando los proveedores de nubes públicas comenzaron a ofrecer infraestructura de TI bajo demanda en un esquema de “paga lo que usas”, todos despertamos y nos dimos cuenta de que estas opciones desplazarían nuestros centros de datos internos. Fue así que comenzamos a actuar como proveedores de cómputo en la nube dentro de nuestra propia organiza-ción, estableciendo las llamadas nubes privadas. Metimos en cintura a nuestros clientes y les dijimos que solo soportaría-mos determinadas arquitecturas y middleware. Convencimos a nuestros CFOs de que si nos permitían hacer grandes ad-quisiciones de infraestructura anticipando demanda futura, y de esta forma eliminar las compras incrementales, podríamos lograr mayores tasas de retorno sobre el hardware. Para que esta política fuera aceptada, aceptamos comenzar a medir y reportar el nivel de utilización del hardware. Y llego enton-ces el día en que tuvimos que rendir cuentas ante los CFOs, admitiendo que todo el hardware que nos habían permitido comprar en los últimos años, estaba sentado en el data center con utilizaciones menores al 50%.

Es increible cuantas excusas pusimos en ese entonces so-bre la seguridad en nubes públicas. Ahora, continuamente seleccionamos a proveedores de nube pública para manejar tipos específicos de cargas de trabajo. Definimos los requeri-mientos de seguridad de cada carga y utilizamos las técnicas apropiadas de encripción y aliasing para asegurar la confi-dencialidad de los datos enviados a proveedores externos. Aunque algunos tipos de información son muy sensibles y no pueden salir de nuestro data center, esta decisión ya se toma por un proceso automatizado. Ya no tenemos debates filosóficos sobre que sí puede o no pasar por el firewall.

Hace diez años, el simple hecho de aprovisionar un servidor podía tomar de 3 a 6 semanas de juntas, emails, evaluaciones de hardware y negociaciones de precio. En el 2010, gracias a la utilización de configuraciones estándar y scripts de automatización en ambientes virtualizados, esta tarea se redujo a medio día. Hoy, podemos hacerlo en minutos. Esto no solo nos ahorra costo de staff, sino que

.COLUMNAcoLumnainviTada

Mark Settle es CIO en BMC Soft-ware, y anterior-mente fue CIO en cuatro compañías de la lista de las Fortune 300: Cor-porate Express, Arrow Electronics, Visa Internatio-nal, y Occidental Petroleum.

Cómputo en la Nuberetrospectiva desde el 2015

sustenta la agilidad que requiere el negocio.Qué bueno que en el 2011 tomamos la decisión de co-

menzar a adoptar agresivamente el cómputo en la nube. De no haberlo hecho no hubieramos tenido la flexibilidad y re-cursos requeridos para soportar la explosión que han tenido las aplicaciones móviles en los últimos años.

Antes, si en un año lograbamos poner en producción 2 o 3 aplicaciones de negocio importantes, además de sos-tener los sistemas legados, era todo un logro. Para nuestros clientes internos, que nos comparaban con las app stores de Apple y Android donde tenían miles de aplicaciones nuevas cada trimestre, eramos demasiado lentos. Entre el 2005 y el 2010 aumentamos significativamente el uso de versiones SaaS de varias de nuestras aplicaciones y servicios de co-municación. Los usuarios estaban fascinados por la rápida introducción de nueva funcionalidad provista por los pro-veedores Saas, mientras que nosotros notamos que el costo era menor en comparación de mantener sistemas legados internos. A través de los últimos años, nosotros mismos nos hemos convertido en proveedores SaaS para la empresa. La mayoría de las aplicaciones que ofrecemos en realidad solo son “mash-ups” que combinan servicios de negocio granu-lares. La mayoría de nuestros usuarios no sabe si un servi-cio está siendo provisto por un ERP, el sistema de comercio electrónico o una fuente de datos externa. Simplemente se suscriben a los servicios que necesitan para hacer su trabajo.

Otro de los grandes beneficios del cómputo en la nube en nuestra organización es que liberó mucho del tiempo que usabamos para administrar la infraestructu-ra. Hemos redireccionado ese tiempo a administrar la in-formación y alimentarla a nuestras aplicaciones, lo cual ha tenido un gran impacto en el negocio.

Vivimos en un mundo radicalmente diferente al que existía en el 2010. Ya no dedicamos el 60% de nuestro presupuesto a simplemente mantener funcionando los sistemas legados. Ahora dedicamos ese mismo porcentaje a entregar nuevos servicios aplicativos y “datos limpios” a nuestros usuarios. El staff está mucho más contento ya que están conscientes de que generan valor real para el negocio. También estamos mucho más cerca de ese estado mítico de “alineación de TI y negocio”.

Este artículo fue originalmente publicado en Clo-udbook.net y se encuentra disponible en http://swgu.ru/sg3410. Esta versión fue traducida y editada por SG con el permiso del autor.

››Por Mark Settle

http://swgu.ru/sg34appstudios

34

.PRÁCTICASusaBiLidad

La Navegación y los Esquemas de Organización de la Información

›› Por Pamela Rodríguez

La definición de una arquitectura de información sólida es quizá el paso más importante a realizar en cualquier

proyecto. Una vez que ha sido establecida, es momento de pasar a otros aspectos estructurales como lo son la navegación y la organiza-ción de la información, dos factores muy importantes de los cuales dependerá el que la arquitectura previamente definida sea asimilada por el usuario.

La arquitectura establecida ya define las principales rutas de na-vegación que se manejarán, mas no define la manera en la que estas serán presentadas para el usuario. También es importante mantener en mente que no existe una única manera de llegar a un destino dentro del proyecto, sobre todo si su contenido es de alta relevancia.

Organización del contenido Antes de comenzar a pensar en los tipos de navegación y en las presentaciones de los mismos, es necesario establecer los esquemas para organizar el contenido que, aunque puede no estar completado en su totalidad, ya fue definido de manera general en la arquitectura de información.

El mayor seccionamiento de la información se lleva a cabo por medio de esquemas de navegación subjetivos, los cuales dependen de la índole del proyecto. Uno de estos esquemas comprende una organización por temas o categorías definidos con base en caracte-rísticas o clasificaciones en común del contenido. Un ejemplo claro de este esquema es prácticamente cualquier sitio web de comercio electrónico asociado a una tienda departamental. La amplia gama de productos es clasificada por categorías (libros, discos, ropa, acceso-rios, entre otros).

Otra manera de organizar contenido es por tareas, es decir, acti-vidades posibles a realizar por el usuario dentro del sistema. Google Docs, la aplicación web de manejo de documentos auspiciada por Google, tiene un menú de opciones dividiendo la creación de los diferentes tipos de documentos existentes (crear hoja de estilo, crear documento de texto, entre otros).

Sin embargo, y aunque los métodos anteriores son de gran utili-dad, también es importante tener en cuenta que la presentación de la información (sobre todo en web, donde la atención del usuario es limitada) debe seguir un flujo común al usuario, de modo que este

encuentre lo que busca con el menor esfuerzo posible. Este método de organización es el de flujo conversacional que se asegura de que la información se presente respondiendo a tiempo las preguntas que el usuario puede ir generando a través de su experiencia.

El sitio de Mint.com lleva a cabo esta clasificación de manera muy efectiva. Al entrar al sitio, la primera opción del menú responde a una pregunta que cualquier lector que no haya escuchado hablar de Mint antes debe estar haciéndose en este momento, y está etiquetada como tal: ¿Qué es Mint? Una vez que ya se conoce esto, la siguiente interrogante es ¿Cómo funciona?, la cual corresponde a la segunda opción del menú.

Existen otras maneras de clasificar la información cuando se ma-nejan grandes volúmenes de la misma, las cuales resultan más ob-jetivas. El esquema alfabético, por ejemplo, debe ser utilizado con cuidado pues no siempre resulta efectivo. Funciona cuando, por ejemplo, se presenta un listado de autores de novelas mas no funcio-na para un listado de países de nacionalidad de un usuario, puesto que un estudio de mercado podría arrojar que el mayor porcentaje de usuarios es proveniente de México y por ello poner este país al principio resultaría más congruente. Otro ejemplo de organización objetiva es el esquema cronológico, utilizado comúnmente para ar-chivar los artículos de un blog, presentados por orden de publicación del más reciente al más antiguo.

Los distintos tipos de navegación Trabajando en conjunto con los esquemas de organización de la información, existen distintas maneras de manejar la navegación dentro de un proyecto de desarrollo, considerando la relevancia de los destinos comprendidos por cada sistema de navegación a utilizar.

En primera instancia está el sistema global de navegación, el cual no solo es el más relevante si no también el más sencillo de comprender. Esta navegación incluye las ligas que estarán presentes en todas las páginas o pantallas dentro de nuestro pro-yecto. Por esta razón se encuentra siempre claramente separado del resto del contenido, formando parte de la plantilla general del diseño de las pantallas.

Adicionalmente está el sistema de navegación local, el cual tam-bién suele formar parte de la plantilla de diseño (es decir, visualmen-

.BIOPamela Rodríguez es egresada de la Universidad de Monterrey de la carrera de Ingeniería en sistemas computacionales con estudios avanzados en diseño web. Actualmente es Diseñadora de interfaces para aplicaciones móviles en Naranya Apphouse, docente, conferencista y autora de artículos relacionados. @thepam http://thepam.blogspot.com

te separado del contenido cambiante de la página o pantalla), pero las ligas que lo conforman varían dependiendo de la sección. Ilustrando este punto, las opciones locales dentro de la sección de ¿Quiénes Somos? dentro de un sitio web (Historia, Visión, Misión, entre otras similares) no serán las mismas que aquellas de la sección de ¿Qué Hacemos? (Proceso, Meto-dología, Herramientas, entre otras).

Es importante definir qué secciones necesitarán manejar navegación local por su comple-jidad o robustez y qué ligas comprenderá esta navegación en cada una de ellas.

Otro sistema de navegación de apoyo es el sistema de navegación de cortesía, cuya repre-sentación es fácil de localizar dentro de los sitios web existentes en la actualidad. Se trata del conjunto de ligas que aparece en la parte inferior de todas las pantallas, comúnmente fijo en todo el sitio al igual que la navegación global. Comprende ligas a información adicional o ‘de cortesía’ como lo son los términos y condiciones de uso, contacto de la empresa, avisos legales, etcétera.

Por otra parte, todas las ligas dentro del resto del contenido (entre los párrafos, botones, etc.) forman parte del sistema de navegación contextual. Y existen también los sistemas de navegación adicionales, que proveen alternativas organizacionales del contenido de un pro-yecto. Estos son los mapas de sitio, los glosarios y los índices de conceptos, dependiendo del tipo de contenido que se esté manejando.

Posteriormente, al avanzar más en el proceso de diseño de una interfaz, la navegación traerá a la mesa consideraciones que involucrarán principalmente la correcta aplicación de la primera heurística de Nielsen que tiene que ver con la visibilidad de estado del sistema: en todo momento, el usuario debe tener muy claro qué camino fue el que siguió para llegar hasta donde se encuentra y saber exactamente dónde se encuentra.

Resumiendo Existen muchos argumentos que ayudarían a resumir la importancia real de tener un buen diseño de navegación, pero quizá uno de los más efectivos se resume en una actualización reciente de Twitter del consultor estadounidense Jared M. Spool:

“A veces los sistemas de navegación son como los armarios. Hay cosas colgando dentro que no nos sirven y nunca encontramos lo que estamos buscando.”

Lo principal de trabajar a conciencia en el diseño de la navegación de un proyecto es, precisa-mente, hacer todo lo posible por no terminar diseñando un armario convencional.

“a vEcEs los sistEMas dE NavEgacióN soN coMo los arMarios. Hay cosas colgaNdo dENtro quE No Nos sirvEN y NuNca ENcoNtraMos lo quE EstaMos buscaNdo.”

.PRÁCTICASPrueBa desofTware

Un Buen Inicio para las Pruebas de Seguridaduso de nslookup para extracción de información inicial del sut

››Por Sandra Berenice Ruiz Eguino y Miguel Ángel Cortés Dueñas

El rápido crecimiento que en años recientes ha tenido el uso de las aplicaciones web, ha traído como consecuen-

cia que cada vez más información de vital importancia sea almace-nada y procesada por dichos sistemas. Las transacciones a través de Internet que hoy en día se realizan dentro de estas aplicaciones pue-den incluir desde información personal, datos laborales, números de tarjetas de crédito hasta información empresarial o gubernamental de carácter confidencial. En este contexto, la realización de pruebas seguridad a estas aplicaciones adquiere una gran relevancia, ya que nos ayudan a identificar vulnerabilidades en las mismas y que en un momento dado pudieran permitir la explotación de información de manera malintencionada, como por ejemplo SQL Injection, Cross-site Scripting –XSS-, Directory Traversal, software con versiones no actualizadas, desbordamientos de búfer, ataque de denegación de servicio, páginas con información técnica sensible/datos sensibles sin cifrar, etc. Si no se atienden dichas vulnerabilidades pueden derivar en accesos no autorizados, filtraciones no deseadas de datos confi-denciales o incluso pérdida en la integridad de los mismos, entre otras implicaciones mayores.

Una de las actividades que se recomienda llevar a cabo en prime-ra instancia cuando nos es asignado un proyecto de Pruebas de Segu-

ridad, es recabar la mayor cantidad de información posible sobre los objetivos con que estaremos traba-jando. Esta recopilación inicial nos ayuda a tener datos más concisos so-bre el SUT (System Under Test) con el cual interactuaremos. En otras pa-labras, entre más información ten-gamos sobre el sistema o aplicación que estaremos probando, mejor será la estrategia que definamos para diseñar y ejecutar nuestras Pruebas de Seguridad. Como resultado de lo anterior, se incrementarán sus-tancialmente las probabilidades de encontrar un mayor número de vul-nerabilidades en el SUT. La era de Internet en la que actualmente vivi-mos nos otorga la facilidad de obte-ner pequeños trozos de información sobre casi cualquier cosa, desde dife-rentes y muchas veces insospechadas fuentes. Es posible que en un prin-cipio, dichos trozos de información

carezcan de sentido pero, al igual que en un rompecabezas, conforme se van juntando pueden ir adquiriendo relevancia como un todo.

Por ejemplo, una muy buena herramienta con la que podemos iniciar recabando información sobre el sistema objetivo, es “Ns-lookup” (Name Server Lookup), técnicamente es una herramienta administrativa que permite diagnosticar y solucionar problemas que se pueden presentar con los servidores DNS. Es por lo anterior, que “nslookup” puede ser una muy buena fuente de información inicial sobre un objetivo ya que, como veremos a continuación, nos permite resolver nombres de host o dominios a direcciones IP y viceversa, pero además nos ayuda a identificar otros elementos importantes dentro de una red como lo son servidores de correo, servidores de nombres de dominio, etc. En los entornos Windows, Unix y Linux, “nslookup” normalmente se encuentra disponible a través de la lí-nea de comando, ya que se instala por defecto junto con la pila de protocolos TCP / IP. Esto nos facilita un poco más las cosas, ya que no es necesario realizar la descarga e instalación de ningún software adicional al que ya tenemos instalado en nuestra computadora.

Cuando lo usamos sin ningún parámetro, “nslookup” nos de-vuelve en primera instancia tanto el nombre como la dirección IP del servidor DNS al que nos encontramos conectados localmente. Después de que nos muestra dicha información, se despliega en pan-talla el “prompt” del programa, representado por el signo de “mayor que (>)”. Cuando este “prompt” aparece, nos indica que estamos en el modo de ejecución interactivo de “nslookup”.

Si deseáramos trabajar con el modo no interactivo, bastaría so-lamente con utilizar el comando acompañado de los parámetros co-rrespondientes, por ejemplo: “nslookup [- opciones] [nombre_de_host] [nombre_de_servidor]”. Esto, sólo nos regresaría la respuesta a dicha solicitud. Sin embargo, para mayor comodidad y convenien-cia, normalmente se usa el modo interactivo.

Una vez que estamos en el modo interactivo, podemos simple-mente teclear después del “prompt”, el nombre del host o dominio sobre el cual queremos solicitar información. Por ejemplo, www.do-miniodeprueba.com, como se muestra a continuación:

> www.dominiodeprueba.comServidor: UnKnownAddress: 192.168.1.254Respuesta no autoritativa:Nombre: www.l.dominiodeprueba.comAddresses: 192.168.1.99, 192.168.1.104, 192.168.1.103, 192.168.1.147, 192.168.1.106, 192.168.1.105Aliases: www.dominiodeprueba.com

.BIOSandra Berenice Ruiz Eguino es Directora de Operaciones de e-Quallity, además ha participado como Consultora Senior en proyec-tos de mejora de organizaciones de Prueba de Software. Cuenta con certificación internacional en Prue-bas por el ASTQB. Se ha desempe-ñado también como Ingeniero de Pruebas Senior, Líder de Proyectos, Administradora de Proyectos na-cionales e internacionales, analista y desarrolladora. Ha sido profesora de la Universidad Autónoma de Guadalajara (UAG), donde realizó sus estudios de Maestría en Cien-cias Computacionales.

-

Miguel Ángel Cortés Dueñas es Líder Técnico de Proyectos de Pruebas y Consultor Especialista en Pruebas de Seguridad en e-Quallity. Cuenta con certificación internacional en Pruebas por el ASTQB, así como certificación CEH (Certified Ethical Hacker) por el EC Council. En su trayectoria profesio-nal ha participado también en pro-yectos nacionales y en el extranjero como Ingeniero de Pruebas Senior, realizando pruebas funcionales manuales y automatizadas.

36

Como podemos ver, “nslookup” nos devuelve las distintas direc-ciones IP asociadas al host o dominio capturado, en este caso www.dominiodeprueba.com. En otras palabras, se realiza una sencilla resolu-ción de nombre a dirección IP. De esta manera, contando solamente con la URL del sistema, podemos resolver su IP o rango de direcciones.

De manera inversa, si al comando “nslookup” lo acompañamos con una dirección IP en lugar del nombre del host o un dominio, nos devolverá como resultado el nombre del host o dominio asociado a la dirección IP ingresada.

Ahora bien, en el resultado obtenido, el servidor DNS local (192.168.1.254) es el servidor que por defecto nos está respondiendo nuestras solicitudes. Esto debido a que no hemos realizado ninguna modificación a la configuración inicial del programa. Sin embar-go, esto puede ser modificado de manera muy sencilla utilizando el comando “server” como lo muestra el siguiente extracto en el cual asignamos como nuevo servidor DNS, al ubicado en la dirección 192.168.100.1 para que sea él quien ahora atienda nuestras solicitu-des de información:

> server 192.168.100.1Servidor predeterminado: dns-publico-prueba.comAddress: 192.168.100.1

A pesar de lo anterior, las funciones que nos ofrece “nslookup” no se limitan a la resolución de dominios. Las combinaciones de comandos “set type” nos permiten realizar búsquedas sobre ciertos registros de recursos DNS en específico. Por ejemplo, un registro de recursos DNS que puede ser de particular interés, es el representado por el valor “MX” el cual corresponde a un servidor de correo (Mail eXchange). La sintaxis de uso es la siguiente:

>set type=MX

Las búsquedas que se lleven a cabo después de que se estableció el valor “MX”, retornarán solamente los servidores de correo (si es que existen) que se localicen en el dominio ingresado. Por ejemplo, la siguiente combina-ción de comandos, devolverá los servidores de correo que existan dentro del dominio “dominiodeprueba.com” como se muestra a continuación:

>set type=MX>dominiodeprueba.comdominiodeprueba.com MX preference = 20, mail exchanger = m1.mx.dominiodeprueba.comdominiodeprueba.com MX preference = 30, mail exchanger = m2.mx.dominiodeprueba.comdominiodeprueba.com MX preference = 40, mail exchanger = m3.mx.dominiodeprueba.comdominiodeprueba.com MX preference = 10, mail exchanger = mx.dominiodeprueba.com

Adicional a los registros de recursos DNS con valor “MX” existen más valores que pueden ser asignados con los comandos “set type” que nos permiten obtener información específica sobre otros elemen-tos tal y como lo muestra la siguiente tabla:

Una vez obtenida la información anterior, estaremos en posibi-lidades de definir con mayor claridad los objetivos sobre los cuales enfocaremos nuestro mayor esfuerzo de pruebas.

A pesar de ser una herramienta que ha estado disponible desde hace un tiempo considerable, de carecer de una interfaz gráfica que haga más amigable su uso y de la existencia de muchas nue-vas aplicaciones que pueden reemplazarla fácilmente, “nslookup” cumple su cometido de ayudar, en muy buena manera, a obtener información inicial importante que puede ser empleada para la planeación y posterior ejecución de nuestras Pruebas de Seguri-dad. Después de todo, es muy probable que muchas de las aplica-ciones que actualmente están en el mercado destinadas al escaneo de vulnerabilidades o pruebas de penetración, en algún punto de su estructura interna contengan la funcionalidad del discreto pero efectivo “nslookup”.

.PRÁCTICASPrueBa desofTware

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

Valor Modo de Uso Descripción

A >set type=A Obtiene Información de un host de la red.

Es el modo de búsqueda que viene

predeterminado en “nslookup”.

ANY >set type=ANY Especifica que se regresan resultados de todos

los tipos de datos, no de uno en particular.

CNAME >set type=CNAME Permite obtener información relacionada con

los nombres canónicos de un alias.

MX >set type=MX Como se explicó arriba, permite obtener

información relacionada con él o los

servidores de correo de un dominio.

NS >set type=NS Especifica que se regresen resultados sobre

él o los servidores de nombres relacionados

al dominio seleccionado.

SOA >set type=SOA Especifica que se obtengan resultados

relacionados con el campo “SOA”

(Start of Authority) de un dominio.

37

38

.PRÁCTICASProjecTmanagemenT

Estimación de Costos:un vistazo a cocomo ii

›› Por Héctor Cuesta-Arvizu y José Sergio Ruíz Castilla

El Cliente dice: “¡Te damos tiempos límite razonables! ¿Por qué no puedes cumplirlos?”

Ese argumento es muy común en el desarrollo de software y el he-

cho de fijar la fecha de entrega antes de establecer los requisitos, es el problema más antiguo de la ingeniería de software, pero si ya estamos consientes de todo esto ¿por qué la improvisación parece ser el estándar? y ¿por qué no se tienen procesos de estimación bien definidos?

Hoy en día existen diversas herramientas y metodologías que nos permiten estimar costos como SPR KnowledgePlan de Capers Jones o COCOMO II de Barry Boehm, por comentar algunos. Sin embargo fenómenos como el “Proyecto interminable” y la “Marcha de la muerte” siguen siendo comunes en muchos desarrollos. Existen muchos factores que afectan las estimaciones de costo como:

• Incertidumbre en los requerimientos.• Términos contractuales rígidos.• Salud financiera (ganar licitaciones sacrificando costo y tiempo).• Falta de experiencia con “X” tecnología.

No existe una forma simple de calcular el esfuerzo requerido para desarrollar un proyecto de software. Las estimaciones inicia-les se hacen bajo la base a la definición de requisitos que el cliente provee a un alto nivel (funcionalidades o pantallas). Los pasos típicos en una estimación son:

1.Análisis de los requisitos.2.Predicción del tamaño.3.Descripción de las Actividades.4.Estimación de fallas potenciales y métodos de eliminación de de-

fectos en el software.5.Estimación de requisitos del personal.6.Ajuste de suposiciones basadas en capacidades y experiencia.7.Estimación del esfuerzo y fechas límite.8.Estimación de costos del desarrollo.9.Estimación de costos de mantenimiento y mejora.

A medida de que los proyectos de software aumentan en com-plejidad, se observa que no existe una relación simple entre el pre-cio de software al cliente y los costos involucrados en el desarrollo, así como la falsa creencia que hay una relación entre el número de desarrolladores contra el número de funcionalidades del proyecto. Por eso y para facilitar el proceso de estimación se han establecido a lo largo del tiempo, métricas que ayudan a dar una idea aproxi-mada del tamaño del software:

Medidas relacionadas con el tamaño del código ( LOC - Lines of code). Esta forma de medir el tamaño de un software era utilizado cuando los lenguajes de programación, patrones de desarrollo y en-tornos de desarrollo (IDE), no estaban ampliamente desarrollados. Hoy en día es impráctico tratar de estimar el software a través de sus líneas de código ya que depende de la experiencia de los programa-dores o si hablamos de lenguajes de programación dinámicos como Ruby, Scala y Groovy o herramientas e IDEs que facilitan gran parte del trabajo de programación.

Medidas relacionadas con la función (UFC – Puntos de Fun-ción). El total de puntos de función no es una característica simple sino que es una combinación de características del software a las cuales se les asigna un valor que cambia dependiendo de su complejidad.UFC es igual a la suma de los “n” elementos evaluados por el peso asignado al tipo de función.

Sin embargo a lo largo del proyecto las funciones cambian, las mé-tricas de puntos de función tienen en cuenta esto y multiplican los UFC iniciales por un factor de complejidad (asignándoles un factor de peso que va desde 3 a 15 puntos). Una desventaja de los puntos de función se presenta cuando el sistema está orientado por eventos. Por eso algunos autores piensan que UFC no es muy útil para medir productividad.

Los Puntos de Objeto (PO). Los PO se utilizan en el modelo de estimación Cocomo II con el nombre de Puntos de Aplicación. Estos son una alternativa a los UFC, y son usados en los lenguajes orien-tados a objetos y de scripts. Dan valor a cada pantalla dependiendo de su complejidad: simples = 1, medianamente complejas = 2, muy complejas = 3. Los reportes van de 2 a 8 dependiendo del nivel de complejidad, y los módulos en lenguaje imperativo como Java o C++ se contabilizan como 10. Esto puede ser relacionado directamente a las historias de usuario de algunas metodologías agiles con lo cual facilita la estimación de la iteración.

Modelo Constructivo de Costo: COCOMO IIUno de los modelos de estimación más usados es COCOMO (Cons-tructive Cost Model) creado por el Dr. Barry Boehm. COCOMO apa-reció por primera vez en su libro Software Engineering Economics [1] en 1981. En 1999 se definió la segunda versión del modelo que toma en cuenta el proyecto, el producto, el hardware y la experiencia del equipo de desarrollo en sus fórmulas de estimación de costo, incluyendo meca-nismos de predicción de tiempo.

Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes momentos del desarrollo ya que la estimación de costos debe

“…El softwarE tiENE uNa tasa dE crEciMiENto dE los rEquEriMiENtos dEl sistEMa ENtrE El 2 y El 5 por ciENto MENsual…”

de ser un proceso dinámico a lo largo del desarrollo, actualizando cons-tantemente las variables, la evolución del equipo de desarrollo, las herra-mientas y lenguajes involucrados. Los distintos niveles son:

1. Construcción de prototipos. Las estimaciones de tamaño están ba-sadas en puntos de aplicación con base en componentes reutilizables, prototipos y la fórmula para estimar el esfuerzo requerido es muy simple: tamaño / productividad.

2. Diseño inicial. Está basado en los requerimientos originales del sis-tema a un alto nivel (pantallas, reportes, procesos, transacciones) lo que son traducidos a puntos de aplicación, esto nos sirve para hacer una pre-dicción temprana del costo.

3. Reutilización. Este nivel se utiliza para calcular el esfuerzo requerido para integrar el código generado por los IDE’s o herramientas de gene-ración de código reutilizable como Spring Roo o Genexus por ejemplo, tomando en cuenta componentes reutilizables que facilitan el desarrollo como Apache Commons.

4. Post-arquitectura. Ya diseñado el sistema se pueden hacer estimacio-nes más precisas del tamaño del software, aquí es importante señalar que el software tiene una tasa de crecimiento de los requerimientos del siste-ma entre el 2 y el 5 por ciento mensual, por lo cual no es posible hacer una estimación exacta pero las predicciones de costo se pueden acercar mucho a la realidad gracias a la aplicación de métricas que nos permiten tener una variación muy pequeña con respecto al producto final.

Cocomo está basado en fórmulas para hacer las estimaciones, véase la figura 1 donde se estima el esfuerzo del personal por mes (PM), des-pués se hace la estimación del tamaño del proyecto (SIZE) y finalmente se obtiene una proyección del esfuerzo requerido (B) contemplando los factores involucrados (SF).

Figura 1 Estimación de esfuerzo [3]

Obviamente el realizar los cálculos manualmente es una tarea lenta y tediosa por lo cual existen muchas aplicaciones que se encargan de rea-lizar todas las fórmulas, como USC COCOMO II que es la aplicación de la página oficial de COCOMO. Podemos descargar gratuitamente el software en http://swgu.ru/sg3414

ConclusiónLa estimación de costos es una actividad muy importante en el desarrollo de software. Esta actividad no es estática sino que cam-bia en diferentes puntos del ciclo de vida del desarrollo. Se tienen que hacer estimaciones desde diferentes puntos de vista, desde la predicción de costos hasta la retrospectiva de comportamiento del costo, para lo cual las herramientas de estimación nos ayudan a agilizar la tarea. Sin duda el poder hacer predicciones con respecto al costo del software nos da ventajas que facilitan el éxito de un proyecto, sin embargo esto no debe de ser exhaustivo ya que se tienen variables que el modelo no contempla totalmente como la incertidumbre, la complejidad o factores humanos de los cuales no se puede tener control, por lo cual se deben tomar en cuenta los riesgos del proceso de desarrollo de software.

Una de las ventajas de COCOMO es el poder medir el com-portamiento de costo de un proyecto de software de forma interna para la empresa de desarrollo. Lo que nos permite tener un referen-te en diferentes puntos del proyecto y así poder comprobar que las proyecciones de costo originales se cumplan.

Referencias:[1] B. Boehm. “Software Engineering Economics”. Prentice Hall, 1981.

[2] C. Jones. “Estimating Software Costs”. McGraw-Hill, 2007.

[3] “COCOMO II Model Definition Manual”. Center for Software Engineering, USC.

[4] B. Boehm, C. Abts, et al. “Software Cost Estimation with COCOMO II”.

Prentice Hall, 2000.

.PRÁCTICASProjecT

managemenT

.BIOHéctor Cuesta-Arvizu es Lic. en Informática y actualmente cursa la maestría en ciencias de la computación en la UAEM Texcoco. Cuenta con seis años de experiencia desarrollando y administrando proyectos de software en el ámbito de manufactura y recursos humanos. Adicio-nalmente se desempeña como instructor de TI para Nyce en el área de base de datos e ingeniería de software. @hmcuesta M. en C. José Sergio Ruíz Castilla es Profesor Investigador de la Uni-versidad Autónoma del Estado de México, estudia el Doctorado en In-geniería de Software y trabaja en proyectos de Ingeniería de Software y Sistemas de Gestión del Conocimiento.

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

39

40

.PRÁCTICASarquiTecTura

Líneas de Productos de Software››Por Humberto Cervantes

La arquitectura de software es el resultado de un esfuerzo importante y su desarrollo puede representar una parte

considerable del trabajo que se realiza en un proyecto de desarro-llo. De lo anterior surge la pregunta, ¿habrá manera de aprovechar el esfuerzo que se hace respecto al desarrollo de la arquitectura de un sistema en el desarrollo de otros sistemas similares? Las líneas de productos de software buscan justamente lograr promover la reuti-lización sistemática de artefactos de los cuales la arquitectura es uno de los más importantes. Este enfoque busca tener distintos beneficios asociados a la reutilización como pueden ser la reducción del tiempo de desarrollo (pues ya no se tienen que desarrollar ciertas partes del sistema), y la mejora de la calidad (pues se incorporan partes que ya han sido verificadas previamente). En esta ocasión hablaremos al respecto de éste tema.

ReutilizaciónEn el desarrollo de software, la reutilización se refiere a tomar uno o más artefactos realizados como parte de un desarrollo y utilizar-los nuevamente en el desarrollo de otro sistema. La reutilización no es un concepto nuevo y a lo largo de la historia del desarrollo de sistemas, han aparecido distintas técnicas que han facilitado de alguna manera la reutilización de artefactos de desarrollo de granularidad cada vez mayor, como lo muestra la figura 1:

Figura1.

Aún con las técnicas antes mencionadas, de manera general, la reutilización frecuentemente se realiza de manera oportunista, esto es que si durante el desarrollo los miembros del equipo de desarro-llo ven la posibilidad de reutilizar algún artefacto entonces lo hacen, pero eso no ocurre de manera sis-

temática. Dada su naturaleza, la reutilización oportunista presenta bene-ficios muy variables, pues todo depende de que en un momento dado se identifiquen posibles artefactos que puedan ser reutilizados. A nivel de una organización, lo deseable es lograr un enfoque de reutilización sistemática con el fin de lograr diversos beneficios asociados con retomar artefactos previamente construidos en cada desarrollo nuevo que se realiza.

Líneas de productosEl concepto de líneas de productos busca justamente lograr un enfoque de reutilización sistemático dentro de una organiza-ción de desarrollo. Éste es un concepto que se originó, y que se usa frecuentemente, en industrias distintas al software. En la industria automotriz, por ejemplo, es común que un fabricante produzca distintas variantes de un vehículo (o productos) a par-tir de una base común que se reutiliza en todas estas variantes.

De acuerdo al SEI (Software Engineer Institute), una línea de productos de software se refiere a un conjunto de sistemas de soft-ware que comparten características y que son desarrollados a partir de un conjunto común de bienes núcleo (core assets). De la ante-rior definición es importante subrayar que los productos dentro de la línea de productos son los distintos sistemas y que los bienes núcleo son las partes reutilizables que permitirán desarrollar los productos. Los bienes núcleo son la base de la línea de productos e incluyen entre otros la arquitectura, componentes reutilizables, modelos de dominio, requerimientos, documentación, planes de prueba, etc. Un aspecto importante a considerar dentro de la línea de productos es que se debe establecer un alcance en donde se des-cribe qué productos son parte de la línea.

Actividades del desarrollo de líneas de productoTambién de acuerdo al SEI, el desarrollo de líneas de productos in-volucra tres actividades principales: el desarrollo de los bienes núcleo, el desarrollo de los productos y la administración, y estas actividades están íntimamente ligadas entre ellas, como se muestra en la figura 2:

Figura 2.

.BIOEl Dr. Humberto Cervantes es profesor-investigador en la UAM-Iz-tapalapa. Ha realizado investigación en temas relacionados con arquitec-tura de software desde el año 2000 y en años recientes se ha enfocado en el estudio y la aplicación de métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www.humbertocervantes.net

retomados para construir una gran variedad de productos especí-ficos. Los productos específicos se construyen a partir de plug-ins que son conectados a la plataforma. Un aspecto interesante de Eclipse es que los plug-ins pueden, a su vez, definir puntos de extensión por lo cual un producto específico, conformado por la plataforma Eclipse y una serie de plug-ins, puede volverse a su vez un conjunto de bienes núcleo para una línea de productos más es-pecializada. Un ejemplo de esto se puede observar en un producto como EclipseUML, una herramienta UML construida por enci-ma de la plataforma Eclipse (http://www.ejb3.org/). De la línea de producto particular de EclipseUML se derivan dos productos específicos: el “Viewer” y el Editor. La parte administrativa de la línea de producto que establece la plataforma Eclipse se puede apreciar en la administración individual tanto del proyecto, que corresponde al desarrollo de la plataforma Eclipse, como la ad-ministración de los productos específicos que se producen por encima de la plataforma. La enorme variedad de aplicaciones so-fisticadas construidas sobre la plataforma Eclipse que existen hoy en día sirven de testimonio del éxito de este enfoque.

En conclusiónEn Ingeniería de Software frecuentemente se habla de reutili-zación y los avances tecnológicos de las últimas décadas indu-dablemente han logrado que hoy en día se reutilicen partes con un nivel de granularidad cada vez mayor. Lograr realizar una reutilización sistemática dentro de una organización requiere un enfoque específico y es ahí donde las líneas de productos pueden ser de mucha ayuda. La implantación de un esquema de línea de productos dentro de una organización requiere de un esfuerzo importante, sin embargo los beneficios que puede aportar pueden hacer que realmente valga la pena.

Un aspecto central de las líneas de productos es la arquitec-tura que soporta los distintos productos y ésta debe ser realiza-da tomando en cuenta las posibles variaciones que permitirán generar los productos específicos. Por último, es importante recalcar que al desarrollar una arquitectura para una línea de producto, es muy conveniente aplicar todas las actividades de desarrollo de arquitectura que hemos tratado en ediciones pre-vias de ésta columna.

Referencias[1] P. Clements y L. Northrop, “Software Product Lines: Practices and Patterns”, SEI

Series in Software Engineering, 2002.

.PRÁCTICASarquiTecTura

A continuación se describen estas actividades en mayor detalle:

• El desarrollo de bienes núcleo se refiere al establecimiento de las partes que serán reutilizadas. Cada uno de estos bienes debe ir acompañado de un proceso que explique la manera en que cada parte se usa al momento de incorporarla en un producto específico. Por otra parte, se establecen planes de producción que describen la manera en que los productos es-pecíficos son generados a partir de los bienes núcleo. • El desarrollo de productos cubre el objetivo último de la línea de producto: producir sistemas específicos dentro del alcance definido a partir de los bienes núcleo. Los insumos para esta actividad son los bienes núcleo, los procesos asocia-dos a los bienes, los planes de producción y los requerimientos específicos a cada producto. • La administración juega un papel fundamental en la implan-tación de una línea de productos. La administración ocurre a un nivel técnico y organizacional. A nivel técnico, cubre tanto la supervisión del desarrollo de bienes núcleo como de pro-ductos específicos. A nivel organizacional orquesta el esfuerzo general de la línea de productos.

Arquitectura y líneas de productoLa arquitectura es un elemento clave dentro de la colección de bienes núcleo pues será compartida por los distintos productos de una línea particular. La arquitectura de una línea de produc-tos es distinta a una arquitectura ‘típica’ pues para permitir la construcción de distintos productos por encima de ella, debe definirse una serie de puntos de variación que son necesarios para poder crear los distintos productos. En este tipo de ar-quitecturas, uno de los atributos de calidad más influyentes es entonces el que sea modificable.

Un ejemploUn ejemplo práctico de línea de productos puede observarse en la plataforma Eclipse que sirve de base al popular entorno de desarrollo (IDE) del mismo nombre (http://www.eclipse.org/pla-tform/). La plataforma Eclipse está basada en una arquitectura extensible a base de plug-ins y la plataforma establece una serie de puntos de extensión en los cuales se conectan dichos plug-ins. Los puntos de extensión que provee la plataforma representan los puntos de variación de la arquitectura. Los bienes núcleo son los distintos elementos que conforman a la plataforma Eclipse y son

“¿Habrá MaNEra dE aprovEcHar El EsfuErzo quE sE HacE rEspEcto al dEsarrollo dE la arquitEctura dE uN sistEMa EN El dEsarrollo dE otros sistEMas siMilarEs?”

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

41

42

.PRÁCTICASgesTión de riesgos

Administración Colaborativa de Riesgos››Por Leonardo G. Mrak

IntroducciónDespués de varios años trabajando y dando consultoría en empresas de diferentes giros, llego a la conclusión de que la administración de los riesgos es un asunto únicamente de los Project Managers. Son los únicos preocupados por la detección y seguimiento de los riesgos de sus pro-yectos. Esta situación crea una falta de preocupación por parte del resto del equipo respecto a los riesgos de su proyecto e imposibilita el análisis colaborativo y las ventajas que con éste podemos lograr.

Esta técnica surge enfocada en atender esta problemática, la cual consiste en administrar los riesgos de una manera Cola-borativa para que de esta forma todos los miembros del equipo se sientan involucrados y puedan aportar a la identificación y monitoreo de los riesgos de su proyecto.

Administración Colaborativa de RiesgosEs necesario que el Project Manager coordine la dinámica asu-miendo el rol de “Facilitador”. Él será el encargado de definir los asistentes para las sesiones de identificación y seguimiento de los riesgos, establecer un lugar con el tamaño adecuado para las sesio-nes, enviar las invitaciones y obtener los recursos necesarios para las sesiones (tarjetas, marcadores, plumas, proyector, etc.). Si exis-tieran asistentes virtuales, ocuparse de que las herramientas de tele-conferencia estén disponibles al momento de las sesiones.

1.Identificando RiesgosPropósito: detectar los riesgos por el EQUIPO del proyecto y otros invitados. Consiste en los siguientes pasos:

a. Dividir a la audiencia en grupos (si es menor a 6 personas, consi-derar a cada uno de los asistentes por separado), según el contexto invitar a otros stakeholders como por ejemplo: gerentes del área técnica, representantes del área usuaria, directores y/o gerentes del área usuaria, etc.b. Entregar tarjetas a cada uno y pedir que escriban los riesgos que

detectan, uno por tarjeta.c. Pedir a cada miembro o grupo que peguen los riesgos en una pizarra y los expliquen (ver figura 1). A través de este ejercicio obtendremos una mayor participación, una mejor cobertura y una comprensión compartida de las preocupaciones de todos.

2. Agrupando RiesgosPropósito: evitar tener riesgos repetidos o muy parecidos, para eso se utilizará la técnica de Agrupación por Afinidad.a. El facilitador leerá cada uno de los riesgos y los asistentes indi-carán si está relacionado con algún otro colocando la tarjeta del riesgo junto con la del que se relaciona.b. Repetir éste paso con cada uno de los riesgos y lograr el con-senso de la agrupación de ellos.

3. Categorizando RiesgosPropósito: priorizar los riesgos identificados, tener una represen-tación gráfica que proporcione información visual clara de los riesgos identificados y evaluados colectivamente por el equipo.a. Dibujar los ejes de Probabilidad/Impacto, considerando en el eje de las “y” la Probabilidad de ocurrencia del riesgo y en el eje de las “x” el Impacto del mismo (ver figura 2).b. Pedir a uno de los grupos o asistentes que coloque un riesgo entre los ejes y pasarle la posibilidad de ocurrencia al siguiente. Los riesgos más graves quedarán en el extremo superior derecho, los riesgos menos críticos en el extremo inferior izquierdo, pro-bablemente no vale la pena preocuparse por ellos (ver figura 3).

.BIOLeonardo G. Mrak es consultor en Qualtop, tiene más de 12 años de experiencia dirigiendo proyectos de distinta índole y apoyando a empresas a mejorar sus procesos de entrega de servicios e ingeniería de software. Lo-gró acreditar a la primer empresa en México en CMMI for Services Nivel 3 de Madurez. Es ITIL, PMP®, formó par-te del primer grupo de habla hispana certificado como Kanban Professional y tiene un MBA realizado en Madrid España. lmrak@qualtop.com

Figura 1. Figura 2.

c. Los siguientes pueden mover el riesgo anterior, colocar un nuevo riesgo o no hacer nada.d. Repetir éste paso hasta que todos ha-yan participado y no se necesiten más movimientos de los riesgos.4. Monitoreando Riesgosa. Una vez categorizados los riesgos, esta-blecer en conjunto con los asistentes un responsable para cada uno.b. Cada uno de los responsables tomará su riesgo y lo colocará en el “Tablero de Amenazas” (ver figura 3) según la estrate-gia de respuesta que seleccione.c. Cada uno de los responsables estable-cerá en una tarjeta las acciones que se lle-varán a cabo de acuerdo a la estrategia de respuesta seleccionada.d. Los riesgos podrán ser cambiados de lu-gar y sus actividades podrán ser tachadas o alteradas por el responsable de ellos.e. El tablero deberá estar en una parte donde mínimamente el equipo pueda ob-servarlo (si existieran miembros que par-ticipan de manera remota, utilizar algún software que permita establecer el tablero y el eje cartesiano, para poder adminis-trar los riesgos de manera virtual).

Figura 3.

44

.PRÁCTICASgesTión de riesgos

f. Establecer reuniones regulares en las que se monitorearán los riesgos con el grupo que participó en la identificación ini-cial. Durante este monitoreo se revisarán los riesgos que fueron detectados anteriormente y quedaron en el eje de Prioridad/Impacto como no críticos, ya que pueden cambiar su prioridad en el transcurso del proyecto. Luego se comienza con el paso 1 nuevamente.

Recomendaciones sobre el uso del Tablero de AmenazasEl Tablero de Amenazas (ver figura 3) consiste en dos filas horizon-tales aparte de la de Títulos, una de “Por Hacer” y otra de “Hecho”.

También contiene una columna por cada estrategia de res-puesta a riesgos:•Evitar: realizar acciones para remover por completo el riesgo.•Transferir: realizar acciones para traspasar el riesgo a otra perso-na o entidad. Esta estrategia presupone una inversión importante para poder hacer esta transferencia, obviamente que este gasto debería ser mucho menor al que se incurriría si el riesgo se trans-formara en problema.Uno de los ejemplos más claros de acciones para esta estrategia es la contratación de seguros.•Aceptar/Contener: el responsable del riesgo no ha identificado otra estrategia adecuada, esto se debe a que no siempre se pueden eliminar todas las amenazas de un proyecto. Esta estrategia de aceptación puede ser Activa o Pasiva, para el caso de la primera estrategia se establecen actividades de contingencia, mientras que para la segunda el riesgo directamente puede pasar a la fila de “Hecho” ya que no se llevarán a cabo actividades. •Mitigar/Contener: se establecen actividades para disminuir la pro-babilidad de ocurrencia y/o el impacto del riesgo. También se pue-den establecer actividades para la Contingencia, es por eso que en el riesgo 4 de la figura 3 (ver rectángulo con línea de punto) existen dos tarjetas de acciones asociadas al riesgo, uno relacionada a las actividades de Mitigación (marcada con una M en el extremo supe-rior derecho) y otro relacionada a las actividades de Contingencia (marcada con una C en el extremo superior derecho).

Establecer reglas básicas:a. El color de las tarjetas pueden indicar algo, por ejemplo para identificar los riesgos se utilizan las amarillas, para establecer

las acciones a realizar se utilizan las rosadas y para registrar las acciones que se fueron realizando las verdes.b. Establecer las secciones que contendrán cada una de ellas por ejemplo:Considerar escribir las reglas a un costado del tablero para que estén siempre visibles y cualquiera que vea el tablero lo pueda entender.

Consideraciones para el facilitador•Si hay una gran cantidad de movimiento que puede tomar un tiempo para que los riesgos se estabilicen, sea paciente, deje que el equipo sienta la divergencia en el grupo y permítales decidir cuándo es hora de dejar de mover los riesgos.•Si hay participantes remotos, dividir los ejes (ver figura 2) en una rejilla de 4x4 y enumere cada celda, pida a cada participante remoto que le diga en qué celda colocar los riesgos. Lo mejor es que lo visual sea compartido, considere el uso de una herramien-ta de conferencia web y una herramienta que pueda mostrar los ejes de riesgos.•Es bueno permitir debates sobre el movimiento que se realizan de los riesgos, siempre que contribuyan a comprender mejor el riesgo y su respuesta. Evite discusiones que no tengan este espí-ritu y obstruyan la dinámica.•Busque que todos los participantes colaboren, en grupos gran-des preste atención a los debates internos de los grupos y consi-dere las expresiones de los miembros.

ConclusionesPara terminar me gustaría recordar el significado de la palabra Riesgo, “es un evento incierto que puede provocar una pérdida, daño o perjuicio”. Esto quiere decir que un riesgo no es un pro-blema, ya que el problema es un evento cierto, algo que ya sucedió y que tenemos que solucionar. Esto es lo que hace tan importante desde mi punto de vista a la administración de riesgos y es por eso que si la ejecutamos de manera correcta y oportuna, nos puede evitar grandes dolores de cabeza.

Para lograr esto es necesario que todos los involucrados en el proyecto tengan las capacidades necesarias para realizar una administración de riesgos eficiente. El contar con diferentes puntos de vista debido a la colaboración de involucrados con diferentes habilidades, nos permitirá aportar mayor valor, cons-truyendo equipos de proyectos altamente proactivos.

“los projEct MaNagErs soN los úNi-cos prEocupados por la dEtEccióN y sEguiMiENto dE los riEsgos dE sus proyEctos.”

D entro de mi experiencia como especialista y arquitecto en soluciones de seguridad, centro de datos con base tecnológica en Software li-

bre y GNU/Linux, he conocido diversas distribucio-nes con muy variadas ideologías y esquemas de nego-cio. He recorrido desde RedHat desde los años 90s, pasando por Fedora, Mandrake, Mandriva, Debian, Suse, Slackware, Puppy. He observado maravillosas funcionalidades, ventajas, así como el aprendizaje que un sistema basado en GNU, cobijado por las cuatro libertades del software libre tiene. La simple idea de tener disponible miles de proyectos basados en Soft-ware Libre de los cuales he aprendido lo inimaginable me motivo a pensar en la idea de crear una distribu-ción con sabor propio.

Desde que instalé mi primer sistema GNU en una computadora he observado que de forma predetermina-da mucho software es instalado sin consentimiento del usuario, lo cual pienso que es muy útil, ejecutando un simple comando “top” se puede observar gran número de procesos que se están ejecutando, pero ¿Por qué, qué ha-cen, se necesitan realmente? Y de aquí se derivan algunas preguntas más. ¿Cómo está construido el sistema?, ¿con qué soportes se incorpora?, ¿Por qué no puedo tener un sistema que yo mismo construya desde sus herramientas más indispensables?

Aunado a lo anterior ha existido siempre la posibi-lidad de crear una distribucion “tropicalizada”, es decir basándose en una distribución ya hecha, modificar los componentes adecuándolos y dándoles un toque per-sonal. Lo anterior es un debate fuerte, ya que desde un principio supe que el desarrollar una distribución desde cero, involucra un fuerte trabajo posterior debido al mantenimiento que se debe dar a todos los paquetes que integran el sistema.

Buscando dentro de internet existe un proyecto lla-mado Linux From Scratch el cual consiste en una serie de documentos en formato html o pdf. Contiene una metodología para desarrollar un sistema gnu/linux des-de cero. El resultado de esto es un sistema muy perso-

.COLUMNAcódigoinnovare

Desarrollando un Sistema operativo

GNU/Linuxnalizado a la computadora donde se desarrolló, sin em-bargo, cuando se intenta instalar este sistema en otros equipos (laptops, pcs, servidores), se pueden descubrir multitud de problemas que nunca se pensaron encon-trar derivado de las siguientes razones:

• LFS no proporciona desde un principio un mecanis-mo de administración de paquetes (rpm, deb, tgz, etc), esto provoca que el mantenimiento del software resulte sumamente complicado de gestionar.• La compilación de los paquetes base del sistema sólo incluyen la incorporación de los soportes mas esenciales del sistema, por lo que posteriormente es probable que se requiera recompilar algún software.• Se sugiere en LFS el mecanismo de “kernel huge”, esto hace que la imagen del núcleo contenga todos los so-portes que son requeridos para bootear un sistema, lo anterior resulta práctico para que el sistema “bootee” rá-pidamente, pero para distribuir el sistema en otras com-putadoras no es lo más recomendable.• Se sugiere un ambiente para construir el sistema, pero dicho modelo puede ser mejorado para asegurar el éxito de la construcción.

Estas son algunas razones de las más poderosas que me orillaron a diseñar una metodología que permita construir un sistema basado en GNU/Linux distribui-ble , término que obedece a la idea de que forme parte de los Sistemas GNU, que pueda ser instalado en una gran variedad de Sistemas y también con amplia varie-dad de Hardware. El resultado de este proceso además de tener un sistema distribuible hecho desde cero, es tener un sistema igual de confiable que otras distribu-ciones e incluso con mayor rendimiento en tiempos de respuesta.

Retomando parte del método de LFS, el sistema GNU se desarrollará en las siguientes fases, donde se está agregando y modificando la metodología original de LFS con la experiencia propia para lograr que el sis-tema sea distribuible:

Ing. Jesús Arriola Villarreal Coor-dinador de la Unidad de Desa-rrollo de Software Libre de INFOTEC. Licenciado en Sistemas de Computación Ad-ministrativa por la UVM titulado con el trabajo “Desa-rrollo Integral Bajo Estándares de Calidad”. Cuenta con Certificación en Foundations ITIL. Desde 2003 colabora en el equipo de Desa-rrollo y Genera-ción de Modelos Tecnológicos ela-borando Servicios alrededor de los mismos. jesus.arriola@infotec.com.mx

jesus.arriola@beakos.org.mx

46

1. Implementar el ambiente de desarrollo, donde se prepara un sistema ideal para parchar, adecuar y compilar diversos pa-quetes de software libre. Este incluye un Sistema anfitrión, o un ambiente virtualizado con un kit de software para desarrollo, una partición, la obtención de Software y la adecuación de las variables del sistema.2. Preparación de las herramientas indispensables para cons-trucción, lo cual involucra: la biblioteca de Desarrollo GlibC, el compilador GCC, las herramientas GNU bintutils y la incorpora-ción de los headers del kernel.3. La construcción de un árbol de dependencias, el cual resul-tará muy útil para la siguiente etapa y para el usuario final.4. La incorporación de un sistema de administración de pa-quetes, la cual es sumamente importante. Este paso resulta com-plejo e involucra trabajo extra que al final del desarrollo genera documentación y un repositorio de software.5. Se procederá posteriormente a la preparación (parches/ade-cuaciones), configuración, compilación, creación de paquetes y su instalación correspondiente, esto genera al final un sistema base con las herramientas de espacio de usuario más indispensables.6. Instalación de los Scripts de Arranque. En este punto se de-cidirá el tipo de sistema: System V o BSD. Dichos scripts son ne-cesarios para el arranque del sistema.7. Hacer el sistema booteable, en esta etapa se incorpora el es-quema para agregar el mecanismo “Disco en RAM” así como la configuración correcta del kernel, esto es importante porque ase-gura que el sistema pueda ser instalado en una mayor cantidad de computadoras sin necesidad de hacer adecuaciones sumamente complejas a los componentes del sistema.8. Se implementa un programa hecho en Script Bash y un con-junto de Scripts del mismo lenguaje, para que el sistema pueda recuperarse creando un LiveCD y un sistema “Setup” para instalar la distribución GNU/Linux en otras computadoras.

Las metodologías de desarrollo que han utilizado los desa-rrolladores de sistemas operativos no ha sido publicado en su mayoría. Infotec como participe activo en la Sociedad del Co-nocimiento ha proporcionado los medios necesarios para que se desarrolle por mi parte esta metodología con el apoyo de otros ingenieros Mexicanos muy talentosos. El resultado es crear sis-temas basados en GNU/Linux con funcionalidades equivalentes a otros sistemas y de excelente calidad.

Considero que esta metodología debe ser tomada en cuenta como parte de la formación de los profesionales en TI, ya que es una carencia que existe dentro de algunas instituciones de educación superior y esto reforzara fuertemente la preparación académica. Esta metodología genera un conocimiento impresio-nante dentro del lector al conocer la forma en la cual un sistema se integra, las funciones de cada uno de sus componentes, las etapas por las cuales una simple llamada del sistema es proce-sada, y un amplio campo de áreas de oportunidad para otros proyectos de Software Libre.

El sistema que se genera con esta metodología es básico, se describe como “Un sistema base, con las herramientas de espa-cio de usuario básicas, y con las herramientas más importantes para el desarrollador”, en este momento se puede considerar al sistema obtenido como una metadistribución porque es una pla-taforma base, que posteriormente puede ser utilizada como un sistema para usuario final (con ambiente gráfico), un sistema de servidor u otro tipo de sistema.

Lo que sugiero a partir de este momento es continuar con el desarrollo o construcción de aplicativos de Software Libre, pequeños, de los cuales existe documentación muy desarrollada, sin olvidar la gestión de paquetes con el método seleccionado.

››Por Ing. Jesús Arriola Villarreal

.COLUMNAcódigo

innovare

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

››eL resuLTado de esTe Proceso es Tener un sisTema iguaL de confiaBLe que oTras disTriBuciones e incLuso con mayor rendimienTo en TiemPos de resPuesTa.

47

Diseñar interfaces gráficas requiere más trabajo de lo que los desarrolladores y líderes de proyecto les gusta pensar, no únicamente por el tiempo que

requiere la producción de estas interfaces sino porque tam-bién necesitan pasar un proceso de revisión y pruebas de manera similar al software, pero con criterios y lineamientos completamente diferentes a los que los ingenieros y arqui-tectos de software están acostumbrados. Adicional a esto, las formas y maneras en que los usuarios utilizan tanto software como la tecnología están cambiando y se están diversifican-do: lejos están los días en que los botones y las teclas eran los puntos focales de interacción humano-máquina y hoy en día podemos afirmar sin duda que el botón, como con-cepto, es una especie en peligro de extinción.

Tres tipos de interacciónEl término interfaz se utiliza para describir los instrumentos de comunicación e interacción entre un sistema y los usua-rios que los manejan.

El ratón, el teclado y el monitor de una PC son interfaces físicas, y los elementos que están en la pantalla, desde ventanas, cajas de diálogo o de texto, iconos y demás son interfaces visua-les. Los programas y servicios que corren en una computadora, un móvil o en la web realmente no necesitan interfaces, éstas existen para hacer el trabajo de sus usuarios más sencillo y para que no tengan que invertir demasiado tiempo aprendiendo comandos o realizando operaciones mecánicas una y otra vez.

La interfaz es un puente que comunica al sistema con su usuario. Las interfaces de sistemas se han hecho más sofisti-cadas con el tiempo, pasando de las incomprensibles tarjetas perforadas de los setentas a las sofisticados ambientes gráfi-cos que utilizamos hoy en día, no sólo en las computadoras personales sino también en las televisiones, en dispositivos móviles y prácticamente en cualquier otro dispositivo digital.

En la historia de la computación hemos visto tres tipos de modelos generales de interacción conforme la técnica evoluciona y los usuarios no tecnológicos se vuelven más relevantes para la industria: el primero fue aquel de las In-terfaces de Línea de Comando (Command Line Interface o CLI) donde el modelo de interacción estaba basado en la escri-tura de comandos en una consola que disparaban acciones en una aplicación. Este modelo es eficiente pero completamente desconectado del usuario y su buen funcionamiento depende de que tan bien el usuario conozca los comandos o “palabras mágicas” que lo hacen funcionar. Aunque es un entorno útil para un usuario con experiencia técnica, no es un buen punto de entrada a la tecnología en términos de una experiencia po-sitiva o lúdica y es percibido más como una barrera que como una ayuda en la adopción tecnológica.

El siguiente modelo fue el de las Interfaces de Usuario Grá-

.COLUMNATecno-Lógico

Mauricio Angulo es programador desde 1989 divul-gador, ávido escri-tor y emprende-dor. Actualmente es CEO y fundador de Tesseract Space donde realiza funciones de ase-sor y consultor de innovación tecnológica, mer-cadotecnia digital y experiencia de usuario.

La Muerte del Botónficas (Graphical User Interface o GUI), en el que imágenes y metáforas del mundo offline como un escritorio, carpetas, ar-chiveros y documentos sustituyen los comandos por un acerca-miento más humano e intuitivo. Los sistemas gráficos se basan en el reconocimiento de estas metáforas por parte del usuario y de la interacción basada en suposiciones, en prueba y error así como también de controles virtuales como menús, botones y ventanas. El problema con los entornos gráficos es que no hay consenso sobre su diseño e implementación y el usuario se ve forzado a aprender los cambios entre diferentes sistemas, aplicaciones e incluso en las diferentes versiones de los mismos.

En los últimos años las llamadas Interfaces Naturales (NUI: Natural User Interfaces) se han colocado como las pre-feridas de la industria de tecnologías de información porque favorecen la interacción de un usuario con la tecnología sin intermediarios físicos, como el mouse o el teclado. La idea es hacer la interacción con la tecnología lo más natural y simple posible, reemplazando los acercamientos tradicionales que vienen de las GUI como lo es la idea del botón.

Controles Naturales y No-NaturalesEl botón, como lo conocemos, es una abstracción humana desarrollada durante la revolución industrial que representa el disparo o ejecución de una acción: al presionar el botón se activa un proceso y diferentes botones están asociados con distintos procesos. En las interfaces digitales, desde te-léfonos inteligentes hasta páginas web, los botones son re-presentados por gráficas de diferentes formas para que el usuario tenga opciones de navegación y acción.

El problema con el botón es que, por común que se haya vuelto, ¡no es un control natural! Los botones y todos sus pa-rientes, los íconos, los switches, los links y los banners son solo una aproximación mental para resolver un problema pero por mucho no es la solución más óptima. La enorme cantidad de sistemas, dispositivos y herramientas que usamos hoy en día nos exigen mayor atención a las interfaces y entre más botones haya que tocar más difícil de manejar es un sistema.

Un experimento interesante al respecto es el que propone el Institute for Interactive Research con su sitio Don’t Click It (www.dontclick.it) en el que se proponen diferentes acerca-mientos acerca de cómo sustituir el clic en el ratón con gestos y movimientos simples sobre objetivos gráficos. El sitio ya tiene buen tiempo publicado -unos 7 años- y se ha ido enri-queciendo con la interacción y prueba de miles de usuarios que han experimentado con las interfaces del sitio.

Las nuevas interfaces táctiles en computadoras touch y en móviles inteligentes reemplazan el “clic” por el “tap”, el “flic-king”, el “pinch” y otras maneras de interacción que resultan más naturales para las personas.

48

El Usuario y su Experiencia DigitalEl diseño de interfaces digitales es un punto crucial en la aceptación o rechazo de un sis-tema, ya que si este es muy complicado de manejar, lo más probable es que sus usuarios no lo utilicen porque desde su punto de vista les ocasiona más problemas que soluciones. La búsqueda de esta experiencia positiva es el motor principal detrás de la evolución de las interfaces como las conocemos, conforme la tecnología se democratiza y cada vez más usuarios que no son ‘expertos’ en computa-ción la adoptan, la industria siempre está bus-cando crear interfaces más simples, intuitivas y sencillas de utilizar.

Llevando el concepto de interfaces natu-rales al extremo, el usuario ya no necesitará tocar siquiera sus computadoras: estas res-ponderán a la presencia del usuario, a su voz y a sus movimientos. Este tipo de interacción irá eliminando otros conceptos de las interfa-ces como las conocemos hoy tales como las contraseñas alfanuméricas, las identidades ba-sadas en correo electrónico o el uso de múlti-ples identidades en la Red, volviendo nuestra interacción con nuestros dispositivos y tam-bién con la información, software y servicios en la Nube mucho más dinámica y personal. La finalidad del desarrollo de NUI es, por un lado, volver más accesible la tecnología a las personas que las están conociendo por pri-mera vez (personas muy jóvenes, mayores o muy pobres) para cerrar la Brecha Digital y por otro lado, eliminar de nuestros procesos mentales la complejidad asociada con utilizar un sistema y permitirnos concentrarnos en simplemente utilizarlos.

La siguiente gran brecha digital existirá entre los Power Users que tienen años usando interfaces mecánicas basadas en palancas o botones y las personas que, siendo nativos di-gitales, aprendieron a utilizar las herramientas tecnológicas del siglo XXI de manera natural. El reto está, evidentemente, en que las empre-sas y personas que desarrollan software y sitios web puedan conocer e integrar los elementos de NUI a sus desarrollos para acercarnos cada vez má a una auténtica vida digital.

››Por Mauricio Angulo

50

Diversas personas me han preguntado qué certificaciones deberían buscar para afianzar

su carrera o posición o cuál conviene a una empresa buscar en un prospecto de contratación. Me llama la atención principalmente el que asuman la respuesta a un cuestiona-miento previo y condicionante a éste: ¿Vale la pena buscar certificaciones? Esta pregunta me puso a pensar en lo re-lativo a quién las pide (tanto desde el punto de vista del individuo que las persigue como del contratante que las valúa), dado el público alcanzado por esta revista, creo que puede ser de interés enfocar la columna hacia este tema.

¿Qué es una certificación?Para el presente análisis me centro en las certificaciones como un documento emitido por una entidad comercial no dedicada principalmente a la educación superior, vali-dando que el sustentante posee el dominio de un conjun-to específico de herramientas o tecnologías (típicamente, aunque no necesariamente, limitadas a las generadas por la organización certificadora).

Las certificaciones difieren de otros métodos de cali-ficación en que normalmente son otorgadas ante la pre-sentación y aprobación de un examen; comúnmente no requieren que el sustentante siga un curso.

Además de lo anterior, las certificaciones frecuentemen-te tienen –a diferencia de prácticamente cualquier programa académico– una validez determinada, ya sea por un tiempo preestablecido, o por estar atadas a tecnologías específicas, con un ciclo de vida y obsolescencia planificado.

Y un punto adicional: Las certificaciones, si bien se presentan a sus clientes potenciales como una oportuni-dad de obtener mejores calificaciones para aumentar sus evaluaciones (redundando directamente en beneficios eco-nómicos), en ningún momento buscan ocultar que son para sus promotores un negocio antes que ninguna otra

cosa. Lo cual, claro, no es ningún pecado, pero sí es un punto a considerar al evaluarlas. Consideremos dos perfi-les en particular — Los dos antiperfiles donde, a mi forma de ver, las certificaciones juegan en contra de la mayor par-te tanto de individuos como de empresas.

Antiperfil 1: El recién egresadoEl argumento para buscar certificaciones es simple: Si cuando un postulante es evaluado para un puesto labo-ral, el entrevistador de primer contacto no tiene un perfil técnico, sino que busca descartar a quien no cumpla con las características básicas que busca la empresa, en realidad la primer entrevista “real” se presenta una vez pasado ese filtro. El Can Cerbero corporativo no permitirá el paso del postulante si no cuenta con el altero completo de papeles.

Este punto de vista apunta a un postulante novato, probablemente recién egresado de la universidad, sin ex-periencia laboral en el mundo real, que no ha tejido aún redes profesionales y no encuentra una mejor vía de acce-so. Este punto crece especialmente cuando estos nuevos integrantes de la fuerza laboral buscan emplearse en una de las relativamente pocas grandes empresas consultoras de desarrollo que hay en nuestro país.

Las certificaciones que están al alcance de un recién egresado, sin experiencia en el campo, son relativamen-te pocas — Y el peso económico de perseguirlas resulta respectivamente elevado. Muchas universidades han in-corporado a los servicios que ofrecen a los alumnos el prepararlos para alguna certificación básica y reducir el precio a pagar por ella. Esto, en mi opinión, equivale a que dicha universidad se reconozca incapaz de ofrecer una formación suficiente para que sus egresados encuentren un puesto de trabajo adecuado y –al impulsar una tecnología específica– demerita la universalidad de la formación que dio nombre a las universidades desde un principio.

Antiperfil 2: El experto en certi-ficacionesUn perfil que nace como consecuencia lógica del anterior es el del experto en certificaciones. Si por cada examen que presento crece mi elegibilidad laboral, ¿por qué no acu-mularlos? Aprender el material necesario para presentar un examen es, a fin de cuentas, una habilidad que puede ser aprendida y dominada. Si bien muchas certificaciones incluyen la resolución de problemas prácticos, siguen pre-sentándose en un entorno donde, hasta cierto punto, las situaciones son muy distintas a las de la vida real.

.COLUMNAProgramar es unesTiLo de vida

Gunnar Wolf es administrador de sistemas para el Instituto de Inves-tigaciones Econó-micas de la UNAM y desarrollador del proyecto Debian GNU/Linux.www.gwolf.org

Repensando las Certificaciones

››quien Busca conTraTar a un ProfesionaL con TrayecToria no Puede LimiTarse a evaLuar en Base a Los cerTificados PresenTados.

Por otro lado, una persona altamente calificada no necesariamen-te sabrá presentar un examen, cosa que a ninguno de ustedes debe sorprender — los ejemplos abundan, traigo ante ustedes a uno en particular, aunque sea sólo como evidencia anecdótica: He tenido oportunidad de trabajar con algunas personas verdaderamente talen-tosas, referencia en el campo de la seguridad y administración de sistemas, que frecuentemente asesoran a los técnicos de empresas transnacionales. Uno de ellos intentó certificarse en uno de los temas en que es pionero en nuestro país y no logró aprobarlo.

¿Significa esto acaso que su conocimiento de la tecnología, las herra-mientas y los procesos es menor que el de quien sí aprobó el curso? De-finitivamente no. Solamente significa que los procesos mentales que ésta persona sigue no se alinean con los que la empresa certificadora sugiere. Y es precisamente esto lo que le ha permitido convertirse en su asesor: El seguir procesos creativos, no buscar dentro de lo predecible y tener un verdadero conocimiento profundo del sistema como un todo.

AlternativasY pasando de la crítica a la propuesta, ¿qué puedo aportar tras mi crítica a este modelo?

Para un recién egresado, enfrentarse al monstruo corporativo sin experiencia real previa no da espacio a la negociación. Mientras las empresas sigan imponiendo estos filtros previos a la entrevista real, ¿qué puede hacer quien inicia su carrera profesional?

Ser recién egresado no significa no tener experiencia real. Entrar a estudiar una carrera relacionada con la computación debería indicar una genuina afición al pensamiento analítico. En nuestro campo, te-nemos la gran fortuna de que un aficionado sin estudios, sin equipo profesional y sin cualificaciones formales, puede desarrollar proyectos en casi cualquier ámbito del campo. En el cómputo, todos ustedes podrán citar numerosos ejemplos que han contribuido al campo de forma decisiva, sin formación profesional.

Claro, sería iluso pensar que todos coordináramos proyectos de gran envergadura siendo aún adolescentes o que impulsar una idea exitosa nos lleve a abandonar los estudios profesionales y saltar a la fama como estrellas de la programación. Sí podemos, sin embargo, ir haciendo públicos los pequeños proyectitos que hacemos, los retos interesantes que vamos resolviendo, los programas que escribimos por gusto. Publicar código, especialmente como software libre, es una muy buena manera de demostrar capacidad profesional, com-promiso, capacidad de documentar y de brindar soporte a los usua-rios. Es más, si nuestro proyecto juguete fue adoptado por una dis-tribución de Linux, esto resulta clara muestra de que otros expertos juzgan nuestro trabajo digno de ser promovido.

Respecto al segundo antiperfil, el caso presentado ilustra que las competencias laborales de un profesional con trayectoria no pueden ser juzgadas de manera meramente cuantitativa — Los diversos campos relacionados con el cómputo requieren de una gran creatividad, y no pueden ser juzgados como una materia de la escuela, en que el desa-rrollo del resultado debe ser idéntico al que nos fue impartido en clase.

Quien busca contratar a un profesional con trayectoria no pue-de limitarse a evaluar en base a los certificados presentados. En mi experiencia, las veces que mi recomendación ha sido requerida para un proceso de selección de personal, coloco en último lugar todos los currículos que presentan certificaciones de forma destacada. Nunca me he arrepentido de hacerlo ya que estos tienden a ser los que me-nos conocimiento real tienen del campo.

El que una entrevista laboral para un puesto que requiere co-nocimientos especializados (sean de un estudiante recién graduado o de un experto) tenga que pasar por un filtro no conocedor de la materia es síntoma de un problema estructural: La tercerización a los corporativos de desarrollo de software ha crecido en detrimento de la capacidad de las entidades que las contratan. No con esto digo que deban desaparecer — Si bien debe ampliarse la capacidad de res-puesta de los departamentos de sistemas de quienes típicamente con-tratan a estas empresas (entiéndase: Ampliarse su tamaño, sus áreas de especialización y la seguridad laboral brindada a sus integrantes), muchos de los proyectos podrían perfectamente ser encargados ya sea a empresas de escala más humana (PyMEs) o contratar a grandes empresas verdaderamente especializadas en un ramo específico. Esto, claro, reduciría el tamaño de las consultoras — Pero aumentaría su calidad así como también las oportunidades laborales con una justa comparación basada en méritos reales, más cerca de quien verdadera-mente requiera del servicio.

Por otro lado, no todos los proyectos en que participamos –por hobby o por encargo– puede ser publicado. Sin embargo, permítan-me insistir en que la mejor carta de presentación es el trabajo reali-zado. En otras áreas laborales es común –incluso en algunos países, obligatoria– la pertenencia a colegios de profesionales — Cuerpos que establecen las normas mínimas de operación, calidad y cobro en el campo, y guardan registro de la actividad de sus agremiados. De tal suerte, en vez de requerir un certificado emitido por una empresa claramente parcial y con innegables intereses económicos en el área, habría una entidad a la cual preguntar acerca de la experiencia com-probable de un postulante.

Los colegios citados nacieron dada la necesidad de una entidad que validara, y asumiera responsabilidad ante dicha validación, a pro-fesiones en las que puede haber amplia responsabilidad civil, como la medicina o la arquitectura. La importancia que van adquiriendo los desarrollos hoy en día nos lleva a plantear si no es momento de una reglamentación similar en nuestra área.

Hay lugar para las certificaciones. Hay trabajos en que hace falta contratar a alguien que domine una tecnología específica, aún sin ser un experto en el ramo entero. La distorsión, a mi opinión, está más en la escala que han adquirido. No pueden ser requeridas como carta de presentación, no puede dárselas un peso comparable al de un es-tudio prolongado y general (como un título universitario) o al de las capacidades demostradas con trabajo.

››Por Gunnar Wolf

.COLUMNAProgramar es un

esTiLo de vida

51

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

universitaria te ayudará a conocerte mejor a ti mismo, relacionar-te con otras personas, y sobre todo te enseñará a aprender. Lo más importante no son los conocimientos duros que obtengas, sino el desarrollar la habilidad de aprender.

En el caso de países como Estados Unidos donde el costo de una carrera de cuatro años fácilmente supera los 150 mil dólares en co-legiatura, es comprensible que cada vez sea más popular la recomen-dación de no estudiar y mejor utilizar ese dinero para emprender. Incluso, Peter Thiel está dando 100 mil dólares a jóvenes para que dejen la escuela [1]. Pero en el caso de países como México donde el costo de la educación universitaria es mucho menor, recomiendo que si tienes la posibilidad de estudiar, no la desaproveches.

En el caso particular de México hay otro beneficio de graduarte de una carrera universitaria: la visa TN. Esta es una visa de trabajo temporal en Estados Unidos especial para ciudadanos mexicanos que se desempeñan en profesiones especializadas. Es la forma más rápida y sencilla de conseguir visa de trabajo en EU, pero requiere que estés titulado y tengas tu cédula profesional.

Conocimientos requeridosUna queja común de los alumnos es que en sus universidades les enseñan tecnologías muy viejas. Yo creo que en la universidad es más importante que aprendas bien los principios a que aprendas las tecnologías más modernas. Por ejemplo, si te enseñan Lisp, que es un lenguaje de 1958, te permitirá entender la programación funcional y así utilizar bien lenguajes modernos como Clojure o F#. Habiendo dicho esto, es necesario que sí conozcas lenguajes y tecnologías modernas, ya que cuando busques trabajo dudo mucho que les interese que sepas Lisp. Mi recomendación de los 10 len-guajes/tecnologías que un buen desarrollador debe conocer actual-mente son: Python, C#, Scala, Javascript, Node, HTML5+CSS3, git, gradle, NoSQL (Couch o Mongo), Hadoop. Lo más probable es que en la escuela te enseñen muy poco, o nada de ellos, así que tú tendrás que aprenderlos por tu lado. No te preocupes, si entien-des los principios será fácil. Adicionalmente, tu conocimiento con estas tecnologías debe ser comprobable con aplicaciones publicadas en algún lado. Ya te darás cuenta de que tener una aplicación publi-cada en un app store te servirá mucho más para conseguir empleo que un 10 final en el curso de compiladores.

¿Y entonces para qué aprender algebra lineal o compiladores, si no sirven para conseguir empleo? Los aprendes por dos razones: 1) Para desarrollar tu cerebro, y 2) Porque aunque lo más probable es que no te ayudarán a conseguir tu primer empleo, definitivamente son herramientas que te ayudarán a hacer mejor las cosas y por lo tanto potenciarán tu carrera profesional.

E n SG tenemos ya 7 años contribuyendo al desarrollo de capital humano de software por medio de la revista, even-

tos y SG Campus. Conforme estuvimos desarrollando nuestro nuevo servicio llamado SG Talento, he estado reflexionando sobre este tema y considero pertinente compartir con ustedes algunas perspectivas. Las he dividido en secciones dependiendo de a quién van dirigidas.

ProfesionistasLa revaloración del desarrolladorTradicionalmente en nuestra región los desarrolladores han sido obliga-dos a moverse a otros roles para poder mejorar su compensación econó-mica. Todos hemos conocido excelentes programadores que se hicieron malos gerentes. Sin embargo, hoy la profesión del desarrollador se está revalorando y cada vez más los desarrolladores se pueden mantener en su rol sin necesidad de renunciar a sus expectativas económicas. Para crecer no necesitan cambiar de rol, sino ser mejores desarrolladores pro-fundizando sus conocimientos, aprendiendo nuevas herramientas e in-corporando una mayor variedad de skills (por ejemplo DevOps). Uno de los factores que ha contribuido a esta tendencia es el renacimiento de los lenguajes de programación, sobre el cual reportamos en la edición de Mayo 2008 de SG. Otro factor es la popularidad de los métodos ágiles, donde la estructura organizacional es más plana y por lo tanto los miem-bros del equipo tienen mayor responsabilidad y visibilidad.

Desarrolladores independientesOtra tendencia es la creciente inclinación de los profesionistas por ser independientes. Antes, freelancer era sinónimo de desempleado. Hoy cada vez me encuentro con más personas que son independientes no por necesidad sino por elección, porque quieren poder escoger los pro-yectos, clientes, tecnologías, tiempos y tarifas con los que trabajan. Si te interesa tomar este camino debes construir una buena reputación. Algunas formas de lograr esto incluyen escribir artículos (ya sea para alguna publicación externa o tu propio blog), participar en foros es-pecializados y participar en proyectos de software libre (o crear el tuyo propio). Adicionalmente, github cada vez se posiciona más como he-rramienta no solo para guardar sino para “presumir” tu código.

EstudiantesEl valor de la educación universitaria¿Para qué estudiar? Después de todo ni Steve Jobs, ni Bill Gates ni Mark Zuckerberg terminaron la escuela.

Mi recomendación es que si tienes la posibilidad de estudiar una carrera universitaria –sin endeudarte significativamente–, lo hagas. El periodo universitario es una experiencia formativa en muchos sen-tidos más allá de los “conocimientos duros”. Una buena educación

Capital Humano en Softwarereflexiones y perspectivas

››Por Pedro Galván

.PERSONAScarrera

52

UniversidadesPrepara ingenieros de software, no IT ProsUn problema común que encuentro en los planes de estudio de las uni-versidades en nuestra región es que están orientados a formar “técnicos en informática” (IT Pros) en lugar de ingenieros de software. El trabajo del IT Pro consiste en administrar infraestructura de TI tal como com-putadoras y redes; pero su preparación dista mucho de lo que se requiere para desarrollar software profesionalmente, y es para esto último para lo que hay trabajo. Entonces, no es ninguna sorpresa que anualmente miles de graduados salen a buscar trabajo y se dan cuenta que no saben hacer lo que la industria demanda —desarrollar aplicaciones.

Recomiendo a las universidades que busquen formar ingenieros de software a que obliguen a sus alumnos a desarrollar aplicaciones desde los primeros semestres. Existen universidades donde se pasan 4 años estudiando teoría pero sin haber construido una aplicación de software de principio a fin. Creo que es mucho mejor que los alumnos comiencen a desarrollar aplicaciones completas (sencillas, pero completas) desde los primeros semestres y conforme vayan avanzando en su carrera vayan aprendiendo aspectos como configu-ration management, testing, distintos paradigmas de programación, que apliquen en sus proyectos para hacer mejor software. El objetivo es que cuando se gradúen lleven 4 años desarrollando software, no 4 años estudiando técnicas que nunca han aplicado.

EmpresasComo bien comenta Erick Camacho en su post “¿Y donde está el talen-to?”[2], los desarrolladores de software experimentados no están buscando ofertas de empleo en bolsas de trabajo. Las bolsas de trabajo tradicionales son un buen mecanismo para promover posiciones “entry level” donde buscas recién graduados, o personas que buscan un cambio de carrera, pero si buscas perfiles con mayor especialización, debes utilizar otras herramientas.

Menos tweets y más brandingNo importa cuantos tweets envíes con “urge” y “please RT”, si tu em-presa no tiene un “buen nombre” entre los profesionistas de software no vas a atraer talento. Y si logras atraer talento, solo lo vas a lograr a billetazos, y así como llegó, se va a ir al próximo mejor postor.

Una de las cosas que puedes hacer para mejorar tu branding hacia desarrolladores es participar en eventos dirigidos a esta audiencia. Depen-diendo del tipo de evento, así como presupuesto que tengas, hay distintas opciones desde poner un stand hasta patrocinar las cervezas o rifar libros.

Algo más que te recomiendo es fomentar que tus empleados compartan conocimiento con el exterior, ya sea escribiendo artículos, dando pláticas en eventos, o simplemente blogueando. No se trata de que explícitamente promuevan tu empresa, sino que compartan con colegas conocimiento técnico adquirido en proyectos reales de la empresa. El efecto que buscas es que la gente piense “aquí hacen proyectos interesantes y valoran el talento.”

Alimenta la curiosidad de tus devsLos desarrolladores son curiosos por naturaleza. Si no dejas que alimen-ten su curiosidad, dejarán tu empresa. Hay distintas cosas que puedes hacer, por ejemplo hay empresas donde por política los empleados de-ben dedicar cierto porcentaje de su tiempo a actividades que no estén relacionadas con el proyecto al que están asignados. Otra práctica que un colega de India me comentó que aplicaban en su empresa era que las personas no podían durar más de 12 meses en el mismo proyecto, y que al terminar un proyecto debían tomar 2 semanas de entrenamiento en nuevas tecnologías antes de entrar a un nuevo proyecto. Otra posibilidad es la de “donar” tiempo de nuestros empleados para participar en pro-yectos de software libre. De esta forma, pueden estar dedicando tiempo a algo que los apasione, al mismo tiempo que aprenden, contribuyen a la comunidad y dan un buen nombre a tu empresa.

Sé FlexibeLos profesionistas cada vez valoran más su libertad, incluso sobre el dine-ro. Un estudio recientemente realizado por Cisco [3] entre estudiantes y jóvenes profesionistas arrojó que este segmento valora la libertad más que el salario. ¿Libertad de qué? Principalmente la libertad de usar redes so-ciales, escoger tu computadora/teléfono o de trabajar fuera de la oficina.

ConclusiónLa situación no es sencilla. El reto de los candidatos es desarrollar los conocimientos prácticos que busca la industria, sin descuidar las habilidades y aptitudes fundamentales que lo ayudarán a ser un me-jor profesionista a lo largo de su carrera. Por su parte, las empresas requieren poder atraer y retener al capital humano que necesitan, y para ello necesitan cambiar muchas de sus prácticas actuales de RH.

En SG estamos conscientes de las necesidades en este rubro, es por ello que creamos un nuevo servicio llamado SG Talento [4] con el que buscamos que los profesionistas de software puedan evaluar y reflejar sus habilidades de forma sencilla, facilitando así a los recluta-dores encontrar el talento que buscan.

Referencias:[1] S. Ludwig. “Peter Thiel pays kids to drop out of college”,

Venture Beat. http://swgu.ru/sg3411

[2] E. Camacho. “¿Y dónde está el talento?”. http://swgu.ru/sg3412

[3] “Cisco Connected World Technology Report”. http://swgu.ru/sg3413

[4] SG Talento. http://talento.sg.com.mx

.BIOPedro Galván Kondo es director y socio fundador de Software Guru, y es un apasionado del desarrollo de capital humano.@pedrogk

53

.PERSONAScarrera

ww

w.sg

.com

.mx

| S

oft

war

e G

uru

“los dEsarrolladorEs soN curiosos por NaturalEza.si No dEjas quE aliMENtEN su curiosidad, dEjaráN tu EMprEsa.”

54

En SoftMty estuvieron presentes como patrocinadores algunas de las empresas más importantes del ecosistema de las TI en esta región, tales como:

• Softtek• Grupo Assa• Huawei• IBM• Mexico IT• EISEI• MexicoFirst• Protektnet• NYCE• Consiss• RedIT• Dimtec

También quedó claro el compromiso con el desarrollo de capital humano que tienen las principales instituciones educativas de Mon-terrey, tales como:

• Universidad Regiomontana• Universidad Autónoma de Nuevo León• Tecnológico de Monterrey

SoftMty 2011 fue posible gracias al apoyo de Secretaría de Eco-nomía, por medio del programa Prosoft, así como al apoyo del Go-bierno del Estado de Nuevo León.

El Consejo de Software de Nuevo León ya está planeando la edi-ción 2012 de este congreso, el cual sin duda continuará con el éxito obtenido en esta ocasión.

Encuentra mayor información sobre el Consejo de Software de Nuevo León en www.csoftmty.org

C on el tema central de: “TI como habilitador de la Agili-dad Empresarial”, los días 26 y 27 de octubre se llevó a

cabo con gran éxito el congreso SoftMty 2011 en la ciudad de Monte-rrey, Nuevo León. Este fue un evento dirigido a directivos de áreas de Tecnologías de Información, con el objetivo de difundir tendencias y mejores prácticas internacionales para mejorar la competitividad tanto de los corporativos “usuarios” de tecnologías de información, como de las empresas locales “proveedoras” de estos servicios.

SoftMty 2011 fue presentado por el Consejo de Software de Nue-vo León (CSoftMty) y coorganizado por Software Guru. CsoftMty es una alianza entre universidades, empresas y gobierno, que busca el crecimiento económico con calidad de vida vía la innovación.

Los participantes de SoftMty 2011 tuvieron oportunidad de asistir a pláticas de destacados conferencistas y analistas internacionales, tales como: Khalid Kark, Director de Investigación en Forrester Research, Gabe Piccoli, Consultor Senior en Cutter Consortium; Bob Benson, Fellow en Cutter Consortium; y David Chappell, uno de los conferen-cistas independientes más reconocidos en el ámbito de las TI.

Los paneles de discusión brindaron una excelente oportunidad para que algunos de los CIOs más experimentados y respetados de nuestro país pudieran compartir su experiencia y perspectiva. En estos páneles se contó con la participación de: Claudio Vivián (Grupo ICA), Felipe Villegas (DHL Express), Daniel Ortega (Merck), Alejandro Ra-mos (Actinver), Guillermo Güémez (Banorte), Víctor López (Homex) quienes fueron complementados con moderadores y analistas de lujo: Ricardo Zermeño, Director de Select; Edgar Fierro, Director en Méxi-co de IDC; y Luke Bujarski, Analista Sr. en Nearshore Americas.

Además de los valiosos contenidos de las conferencias, SoftMty 2011 contribuyó a generar relaciones de negocios entre los asistentes que potenciarán el crecimiento de nuestra industria, ya que reunió tanto a CIOs y líderes de organizaciones de TI, como a importantes proveedores y representantes clave de la industria.

SoftMTY 2011se lleva a cabo con gran éxito

.CONTENIDO PATROCINADO

DirectorioAlpha Consultoría Pág. 43http://www.alpha-consultoria.com

App Studios Pág. 33http://appstudios.mx

CsoftMty Pág. 54http://www.csoftmty.org

Extend Solutions Pág. 49http://www.extend.com.mx

Huawei Pág. 4Fhttp://www.huawei.com/enterprise

Infotec Pág. 09http://infotec.com.mx

Microsoft Pág. 2Fhttp://msdn.microsoft.com/es-mx

ProNatura Pág. 3Fhttp://www.pronatura.org.mx

Qualtop Pág. 35http://www.qualtop.com

SG Talento Pág. 01http://talento.sg.com.mx

SG Campus Pág. 31http://www.sgcampus.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TI

SG se distribuye de manera impresa en la República Mexicana, y de manera digi-tal 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 acer-carte a nuevos clientes.

“Es una gran oportunidad participar con Software Guru, pues comprobamos quees un medio efectivo.” -Novalys Latinoamérica

Contáctanos en el (55) 5239.5502 o en publicidad@sg.com.mx

56

SONYNuevos modelos VAIO

Para cerrar el año, Sony VAIO actualiza su línea de computa-doras personales, con modelos dirigidos a distintas audiencias. A los lectores de SG posiblemente les atraigan los modelos de la serie S que está dirigida a profesionistas, brindando alto des-empeño y confiabilidad. O si lo que buscas es una laptop muy ligera sin escatimar desempeño, está la serie Z con pantalla de 13.1 pulgadas, procesador i5-2410M, 6 GB de RAM y disco de estado sólido. www.sonystyle.com.mx

SPHEROPelota robótica

Para continuar con la temática de esta edición de SG les presen-tamos Sphero, una pelota robótica que puedes controlar desde tu smartphone. Así es, simplemente lo prendes y puedes jugar con el desde apps en tu smartphone. Entre las opciones de jue-gos está un simulador de manejo y un juego de golf virtual. Próximamente también se abrirá la posibilidad a terceros de desarrollar apps que interactúen con Sphero. Un buen detalle es que el Sphero puede cambiar de color, lo cual es útil cuan-do estás jugando con varias personas. Se puede controlar desde iPhone, iPod touch y Android. http://gosphero.com

LIBRATONE LIVESonido con estilo

La compañía danesa Libratone lanzó la línea de bocinas Live. Éstas son bocinas portátiles e inalámbricas que funcionan con la tecnología AirPlay. Además de su elegante y vistoso diseño, estas bocinas ofrecen un gran desempeño en sonido. Utilizan una tecnología denominada FullRoom para que el sonido no rebote en las pa-redes. Adicionalmente, por medio de una app para iPhone/iPod puedes proveer información sobre la ubicación de las bocinas y la app las calibra vía AirPlay para optimizar el sonido. http://libratone.com/live

.TECNOLOGÍAgadgeTs

JAWBONE UPAsistente para mejorar tu salud

UP es un sistema que consiste de una pulsera acompa-ñada de una app para iPhone, que registra tu actividad física, patrones de sueño y hábitos alimenticios para ayudarte a tener una vida más saludable. El sensor de movimiento está en la pulsera, que es resistente al agua, así que puedes traerla puesta todo el día, incluso para bañarte. UP monitorea tu actividad física (pasos, dis-tancia recorrida, ritmo de movimiento), patrones de sueño (horas dormidas, profundidad del sueño, calidad del descanso) y alimentación registrando qué y cuando comes. http://jawbone.com/up

http://swgu.ru/sg34pronatura

http://swgu.ru/sg34huawei