Sg-200706

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Sonia Sánchez Arte y Diseño David Gutiérrez Oscar Sámano

Editorial

Consejo Editorial Francisco Camargo, Ralf Eder, Raúl Trejo, Guillermo Rodríguez, ITESM-CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity - ITESO.

En este número podrán consultar el estudio de los resultados que obtuvimos al realizar la encuesta de salarios. Muchas gracias a todos los que se tomaron 5 minutos de su tiempo para responderla, colaborando con el contenido principal de estas páginas. Esperemos que los resultados obtenidos dejen un poco de conciencia de cómo están distribuidas las actividades en relación a las TI’s y el camino que podrían tomar en algunos años. Un resultado que debe concientizarnos a todos los involucrados en ellas. Esta edición tiene un sabor especial para todos los que nos vimos involucrados en su desarrollo, ya que no solo nos preocupamos por mantener la calidad a la que ya están acostumbrados a leer en estas páginas, sino que al mismo tiempo estuvimos trabajando en todos los detalles para la ejecución de SG’07. Entre la afinación de estos, las imprentas trabajando y todo el equipo que forma a SG Software Guru durmiendo en la oficina (literalmente, claro está), ninguno de estos esfuerzos hubiera estado completo sin la participación y colaboración temprana de nuestros amigos columnistas, ya que hubiera sido imposible salir, como el pan de la mañana, a tiempo.

02

NOV-DIC 2007

Y la última razón por la cuál el valor de este número se engrandece es sencilla: ¡cumplimos tres años! y no hay mejor manera de celebrarlo que llevando un número más hasta sus manos. El festejo se hace doble porque también es el último número del 2007. Aprovechemos estas líneas finales para agradecerles a todos los lectores, la gente nueva, los voluntarios en el congreso, el equipo base de la revista, los patrocinadores en todas sus categorías, los ponentes nacionales y extranjeros y muy especialmente a tí, que estás leyendo estas líneas. Gracias a tí cumplimos un año más de preferencia y asistencia a SG’07. Sin ustedes, parte importante de SG, este producto no sería lo que es hoy: un medio en el que el conocimiento se pone en práctica.

Colaboradores Erick Frausto, Jorge Valdés, Charlie Macías, Ariel García, Sergio Orozco, James Reinders, Marc A. Criley, Emilio Osorio, Carlos Ortega, Susana Tamayo, Luis Daniel Soto. Fotografía Gabriel González Ventas Claudia Perea Natalia Sánchez Marketing y RP Dafne Vidal Circulación y Suscripciones Daniel López Administración Araceli Torres Contacto [email protected] +52 55 5239 5502

¡Gracias por seguir nuestro paso! — Equipo Editorial

SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Queda prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. 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: 04-2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en noviembre de 2007 en Litográfica Roma. Distribuido

www.sg.com.mx

contenido nov-dic 2007

18

EN PORTADA Encuesta de salarios

Un análisis a la distribución de la compensación laboral de los profesionistas de las áreas de TI.

Productos

Columnas 06

Tendencias en Software por Luis Daniel Soto

44

Mejora Continua por Luis Cuellar

08

Cátedra y más por Raul Trejo

28

Noticias y Eventos

04

INFRAESTRUCTURA

48

Fundamentos

46

TECNOLOGÍA

50

BIBLIOTECA

54

En Cada Número

Entrevista

Danese Cooper

www.sg.com.mx

10

tutorial Una Introducción a Quartz.

12

NOVEDADES Microformatos.

14

Prácticas

Tejiendo Nuestra Red por Hanna Oktaba

16

LO QUE VIENE Adobe AIR, GeneXus, GridGain, Google Gears.

ADMINISTRACIÓN DE PROYECTOS 30 Límites de Estimación Reduzcamos el nivel de incertidumbre que se presenta al momento de realizar estimaciones, a través del establecimiento de límites claros en nuestra planeación. Conozcamos un poco más de ello en este artículo.

PROGRAMACIÓN Aprendiendo Ruby y Rails

32

Dentro de los lenguajes de scripting, Ruby ha tenido un crecimiento y desarrollo importante en los últimos años. Iniciamos con una breve introducción al uso del lenguaje.

UML Los nuevos diagramas: de tiempo y de estructura completa

38

Conozcamos cómo pueden ser modelados los sistemas de tiempo real a través de los diagramas de tiempo y de estructura, mostrando un par de la notación UML 2.X.

NOV-DIC 2007

03

// NOTICIAS

AMITI Congreso Internacional 2007 En el Centro Banamex de la Ciudad de México, el pasado 10 de octubre se realizó el Congreso Internacional AMITI 2007 bajo el lema: México Reinventado, Vive las Tecnologías de Información. Durante el evento, los asistentes conocieron algunas estrategias necesarias para dirigir a sus organizaciones en torno a la competitividad, de forma que vayan creciendo conforme a los cambios que se presentan actualmente. Dentro de este marco, también se hizo entrega de los Premios AMITI 2007.

CREANIMAX 2007 Del 5 al 7 de octubre pasados, se realizó en la ciudad de Guadalajara Jalisco Creanimax 2007. Entre talleres y conferencias el evento se fue desarrollando, con ponentes de la talla de Yves Bordeleau, de Wicked Studios, Alexander Fernandez de streamline-studios.com, Grayson Edge de epicgames.com entre otros. Sin dejar de mencionar la premiación de los concursos convocados para esta exposición. Uno de los aspectos que resaltó fue el interés de los padres de familia buscando alternativas educativas para que sus hijos aprendan de las herramientas necesarias para el desarrollo de videojuegos.

CIAPEM Del 12 al 14 de septiembre de 2007, se llevó al cabo la XXXI Reunión Nacional del Comité de Informática de la Administración Pública Estatal y Municipal -CIAPEM-, en el World Trade Center Veracruz. La inauguración del evento estuvo a cargo del Lic. Fidel Herrera Beltrán, Gobernador del Estado de Veracruz, el cual asumió la Presidencia del CIAPEM para el periodo 2007-2008. Con la participación de diversos sectores, las pláticas ofrecieron a los asistentes un panorama de análisis que giró en torno a la razón de ser de todo Gobierno: el ciudadano. Es así que durante el evento se plantearon diversos mecanismos para mejorar los servicios brindados por las administraciones públicas utilizando las Tecnologías de la Información.

04

NOV-DIC 2007

www.sg.com.mx

// EVENTOS

08 al 11 de noviembre 2007

14 de noviembre 2007

Mérida, Yucatán Info: www.canieti.org/convencion Tel: 01 (55) 5264-0808 e-mail: [email protected]

México, D.F. Info: www.idc-eventos.com/infrastructure07/ e-mail: [email protected]

CANIETI XXVIII Convención Nacional Anual

IDC – Dynamic Infrastructure & Storage Conference 2007

12 al 14 de noviembre 2007

26 al 27 noviembre 2007

Cancún, Quintana Roo Info: congresses.pmi.org/LatinAmerica2007/ e-mail: [email protected]

Monterrey, Nuevo León. Info: www.informationsecurity.com.mx e-mail: [email protected]

IDC Innovation Forum

ENC 2007

El pasado 11 de septiembre, en la ciudad de México se realizó el IDC Innovation Forum 2007, con importantes representantes de diferentes ramas de las Tecnologías de Información.

Del 24 al 28 de septiembre, se realizó en la Ciudad de Morelia el Encuentro Internacional de Computación 2007 (ENC2007), Este evento logó reunir a especialistas de México y el mundo en torno a los temas más actuales de la Ciencia de la Computación.

PMI Global Congress Latin America 2007

El uso de nuevas tecnologías como el Web 2.0, el papel que toma la innovación dentro del crecimiento de las entidades, la importancia de los procesos que se realizan y el papel que juega el tiempo de respuesta de las aplicaciones web, fueron entre otros, algunos de los temas que el público asistente no solamente conoció, sino que además, fueron elementos de retroalimentación entre ellos.

Gartner 10th Annual Future of IT Conference

Information Security Monterrey

Las personalidades internacionales estuvieron representadas por Martín Farach-Colton y Vibhu Mittal quienes forman parte humana del buscador más famoso del mundo: Google. Investigadores de Francia, Arizona y Florida y la gran presencia del investigador Gonzalo Navarro de la Universidad de Chile, quien en estos momentos es un candidato a la medalla Turing.

Concyteg

El pasado 19 de septiembre Gartner realizó en la Ciudad de México la décima edición de sus conferencias anuales sobre TI. Con duración de 3 días y tracks de temas diversos, la agenda presentada fue un claro ejemplo del futuro de las TI’s a nivel internacional.

Los días 8 y 9 de octubre tuvo lugar el 2° Foro de Desarrollo y Pruebas de Software del Estado de Guanajuato que organiza el Consejo de Ciencia y Tecnología del Estado de Guanajuato (CONCYTEG), a cargo del Dr. Pedro Luis López de Alba dentro de su programa de Desarrollo de la Industria de las Tecnologías de Información y Comunicaciones, cuyo Director y Coordinador es el Mtro. Raymundo González Castrejón.

Se presentaron las tendencias tecnológicas para 2008 y temas que están tomando importancia actualmente para consolidarse en los próximos años. Entre los temas que más destacaron podemos mencionar Business Intelligence, Virtualización y Web 2.0.

El evento contó con expositores de alto nivel y reconocimiento internacional, como la Dra. Juliana Herbert de Brasil, Oscar Valenzuela de Presidente ejecutivo de GNUCHILE (Free Software Foundation), el Dr. Luis Vinicio León, Andrés Simón Bujaidar del Programa Prosoft de la Secretaría de Economía, entre otros.

Empresas recientemente evaluadas en CMMI:

Empresa Adsum Cibernet Éxito Homex Northware Sigma Tao www.sg.com.mx

Evaluación CMMI 2 CMMI 2 CMMI 2 CMMI 2 CMMI 2 CMMI 5

Fecha abril 2007 abril 2007 abril 2007 abril 2007 abril 2007 agosto 2007

Apoyado por Innevo Innevo Innevo Innevo Innevo Ninguna

Lead Appraiser Viviana Rubinstein, Liveware Jorge Boria, Liveware Viviana Rubinstein, Liveware Andres Rubinstein, Liveware Jorge Boria, Liveware Dr. Miguel A. Serrano, Avantare NOV-DIC 2007

05

// COLUMNA // COLUMNA

/*TEJIENDO NUESTRA RED*/

Los Frutos de Ciudad Real y Popayán Avances del proyecto COMPETISOFT

La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

E

n el número 2 de este año de SG describí los objetivos y los primeros resultados del proyecto Iberoamericano COMPETISOFT. Es un proyecto a tres años (2006-2008), con la participación de los académicos y empresas de desarrollo de software de varios países de la zona. El objetivo principal del proyecto es generar la versión consensuada del modelo de procesos, del modelo de evaluación y un modelo de mejora de procesos adecuado para las PyMES Iberoamericanas. El proyecto está dividido en tres fases: • 2006- Selección y enriquecimiento de modelos de procesos, de evaluación y de mejora • 2007- Pruebas de los modelos con las empresas • 2008- Integración de los resultados y generación de la versión mejorada de los modelos. MoProSoft fue seleccionado como modelo de procesos de referencia, revisado minuciosamente por nuestros colegas académicos de otros países y, salvo unas pequeñas modificaciones, aceptado para ser usado en las pruebas. En este año se están llevando a cabo los experimentos de adopción del modelo de procesos en empresas de varios países bajo la asesoría de los académicos locales. Para asegurar la uniformidad de estos experimentos se organizaron dos talleres para capacitar a los asesores y a los representantes de las empresas e intercambiar las primeras experiencias. El primer taller se realizó del 4 a 6 de julio en la Universidad Castilla La Mancha (UCLM), Ciudad Real, España. Los instructores del taller fueron Maria Julia Orozco de Ultrasist (México) y Francisco Pino de la Universidad de Cauca (Colombia). La mayoría de los asistentes fueron españoles pero también asistieron representantes de Chile, Argentina y México. Los académicos —en su mayoría alumnos de doctorado— originaron además de ricas discusiones sobre modelo de procesos, varias sugerencias de mejora. Por otro lado, los representantes de empresas, quienes ya han hecho su primer ciclo de mejora de procesos, compartieron sus experiencias. La plática se enriqució al escuchar cómo se han apropiado del modelo y cómo lo defendían ante los académicos.

06

NOV-DIC 2007

Una cosa que me dio envidia es que una de las grandes empresas de desarrollo de software españolas (a través de un convenio) construyó un edificio moderno dentro de la UCLM. Con la construcción de este edificio se asigna un espacio al grupo de Ingeniería de Software Alarcos, el cual es dirigido por el Dr. Mario Piattini —para sus investigadores y alumnos de posgrado. Esto abrió la posibilidad de la vinculación más directa con la empresa, pero también la recepción de mayor número de alumnos de otros países para estancias temporales. Algunos de mis alumnos de maestría ya están gozando de este intercambio. El segundo taller se realizó en Popayán, Colombia del 23 al 25 de agosto. Aquí los anfitriones fueron la Universidad de Cauca y el Parquesoft. En esta ocasión la instructora mexicana fue Claudia Alquicira de Ultrasist y, nuevamente, Francisco Pino, quién además fungió como organizador local. La asistencia en este taller fue más nutrida: 15 personas llegaron de Argentina, Uruguay, Perú, Ecuador y México, 19 restantes fueron colombianos de Medellín, Calí y propio Popayán. Aquí los académicos fuímos minoría y la mayoría fueron los representantes de las empresas, incluyendo a los jóvenes de Parquesoft. Los que leyeron la entrevista con Orlando Rincón, en el número 5 de Software Guru de este año (septiembre - octubre), saben que él es el creador del Parquesoft y su concepto. De lo que me enteré en Colombia es que ya existen 15 Parquesoft, dispersos por todo el país, y uno de ellos está en Popayán. Tuvimos oportunidad de conocer de cerca como están organizados, cuales son sus valores y objetivos. Lo que más me llamó la atención fue la juventud de los integrantes de las pequeñas empresas y su creatividad. Durante el trabajo del taller ellos se dieron cuenta de que nuestro modelo les puede ser de mucha ayuda para ordenar los procesos de desarrollo que siguen y, agregando las prácticas de gestión, permitirles un crecimiento de manera ordenada. Varias empresas se comprometieron a participar en las pruebas. Además, una empresa se ofreció para desarrollar una versión libre de la herramienta que utiliza la base de conocimiento de MoProSoft basada en la herramienta de su creación para el manejo de conocimiento en las organizaciones.

www.sg.com.mx

“Durante el trabajo del taller ellos se dieron cuenta de que nuestro modelo les puede ser de mucha ayuda para ordenar los procesos de desarrollo que siguen ”.

Otro caso interesante fue el de un empresario colombiano, específicamente de Calí quien mostró al público presente cómo, usando el modelo de MoProSoft, generó los procesos de instalación de sus productos y de la mesa de atención a clientes para su negocio. Estos procesos no están, aún, contemplados en el modelo actual. Sabiendo que muchas empresas, que venden sus productos a varios clientes tienen la misma necesidad, convenimos con él la posibilidad de generalizarlos a partir de su definición e incluirlos en el modelo. Los académicos que participaron en este taller desde el primer día mostraron a los asistentes su gran compromiso con el proyecto COMPETISOFT. Entre ellos se encontraba gente con buena experiencia en la mejora de procesos con CMM y CMMI y conocimiento profundo sobre la gestión de calidad. Todos reconocen que los países latinoamericanos necesitan una alternativa viable y menos costosa para elevar las capacidades de sus industrias basadas en PYMES. Dos personas, que tienen representación ante los organismos de normalización de Argentina y Perú, nos comentaron el interés de sus países de tener una norma parecida a la norma mexicana.

comparado con lo que se pide en los procesos de Operación de MoProSoft. Sin embargo, MoProSoft tiene la “cabeza”, es decir, los procesos de Gestión de Negocio, de Procesos, de Proyectos y de Recursos, que ayudan a que sean exitosos NO solamente los proyectos, sino TODA la organización. Y esto, creo, es lo fundamental para una PYME. Estoy conciente de que, por el momento, está respuesta es una hipótesis, pero espero que pronto se comprobará con las evaluaciones y, lo más importante, con el sentir de los pequeños empresarios que dejarán de ser peques. Para finalizar, muchos me reprochan, que con los proyectos de WG24 de ISO y de COMPETISOFT abandoné a “mi niño” en México. Para aliviar un poquito esta culpa les invito a que se sumen al esfuerzo de crear una Comunidad MoProSoft activa y colaborativa a través del sitio virtual www.comunidadmoprosoft.org.mx. Los espero allá. —Hanna Oktaba

Popayán es una pequeña ciudad andina, muy colonial, con casas blancas, patios de vegetación exuberante y techos de teja, una mezcla de San Cristobal de Las Casas y Pátzcuaro. Nuestros anfitriones de la Universidad de Cauca y de Parquesoft nos colmaron de atenciones. Antes de ir a Popayán pasé un día en Medellín con la Dra. Raquel Anaya de la Universidad EAFIT. De esta corta estancia también tengo varios recuerdos de los cuales menciono solamente las fantásticas esculturas gordas de Botero y el metro que tiene partes de teleférico que suben a los cerros. La pregunta más difícil de contestar y que me están haciendo frecuentemente es: ¿Cómo se compara MoProSoft con CMMI? La respuesta que estoy dando es la siguiente: A través de MoProSoft se puede llegar a CMMI, pero no necesariamente al revés. El razonamiento que está detrás de esta respuesta es el siguiente: CMMI tiene mucho más detalle para lograr proyectos exitosos,

www.sg.com.mx

Asistentes al taller de Popayán

NOV-DIC 2007

07

// COLUMNA // COLUMNA

/*MEJORA CONTINUA*/

La Visión del Túnel Los cisnes negros del Software Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

E

n estos días he estado leyendo un libro sumamente interesante llamado “El Cisne Negro” (The Black Swan) de Nassim Nicholas Taleb. Este libro plantea la tesis de que el mundo está lleno de eventos impredecibles, que de alguna manera cambian por completo la forma en que percibimos las cosas, y hasta después de que sucedieron nos podemos explicar como es que llevaron a cabo. A estos eventos los llama “Cisnes Negros”, haciendo referencia a que antiguamente se pensaba que todos los cisnes eran blancos, pero al descubrir Australia se descubrió el primer Cisne Negro lo cuál impactó todo el conocimiento que se tenía sobre Cisnes hasta esa época. Eventos como el ataque a las Torres Gemelas, el surgimiento del Internet, y otros tantos que nos han cambiado la vida son considerados “Cisnes Negros”. El libro es sumamente interesante, y aunque es un poco difícil de leer, se los recomiendo mucho. Uno de los puntos que me llamó la atención tiene que ver con la imposibilidad que tenemos los seres humanos de estimar un proyecto en forma precisa, debido a la complejidad de nuestro ambiente y a ciertas características de la naturaleza humana. Según Taleb, una estimación tanto de software como de cualquier otro tipo de proyecto, falla debido a un concepto llamado visión de túnel. Básicamente, esto se refiere a que como seres humanos estamos condicionados sólo a ver lo riesgos que existen dentro de nuestro ámbito cotidiano y somos incapaces de tomar en cuenta riesgos que se encuentran fuera del mismo. Hagamos memoria, el último proyecto que llevamos a cabo que haya fracasado ¿por qué fracasó? Normalmente la respuesta tiene que ver con algo que no se incluyó en la estimación original: el cliente decía tener claros los requerimientos pero no fue así, no se consideró el diseño de seguridad en una tecnología, el líder de proyecto nunca había manejado un proyecto tan grande, etc. La mayoría de estas razones no tienen nada que ver con el proyecto porque son elementos externos. Normalmente nuestro sentimiento es que esos eventos no son atribuibles a nosotros, y por lo tanto no cuentan. Esto nos pone en un dilema interesante. Estamos diciendo que no importa el proceso que sigamos, la realidad es que no hay forma de hacer una estimación correcta. Adicionalmente, consideramos que las razones por las que las estimaciones fallan no son nuestra culpa o no tienen que ver con nosotros, así que ni siquiera estamos abiertos a ver como mejorar. A fin de cuentas así es siempre, y si algo sale mal no nos queda mas que negociar con el cliente.

08

NOV-DIC 2007

Algunos modelos como por ejemplo CMMI e ITIL tratan de resolver este problema a través de un control estadístico de tus estimados contra tus reales. Esto te lleva, dado el caso de que sigas el mismo proceso para hacer el estimado de todos tus proyectos, a que puedes utilizar esta información para detectar que tan exacto es tu modelo de estimación. El problema es que este método sólo contempla los procesos estadísticamente estables, así que no contempla los elementos que salen del estándar, que serían los Cisnes Negros en nuestra estimación. Otro elemento importante que maneja la teoría del Cisne Negro es que la cantidad de cisnes crece exponencialmente cuando el problema que estamos atacando es un tema desconocido o lejano en el futuro. Por otro lado, esta probabilidad se reduce considerablemente entre menor sea la distancia de la predicción y más conozcamos sobre el tema que se está estimando. Un modelo que trata de resolver esta problemática es el Proceso Personal de Software y Proceso de Equipos de Software (PSP/TSP por sus siglas en inglés). PSP/TSP ataca este problema desde un punto de vista algo diferente, ya que la estimación no es hecha por el líder del proyecto sino por todos los miembros del equipo a nivel individual, componente por componente, programa por programa, al inicio del proyecto. Toda esta información se une para formar el plan detallado global. Esto hace que el proceso de estimación sea mucho más predecible, ya que se está reduciendo la distancia y desconocimiento de la estimación. Adicionalmente, PSP/TSP mide la cantidad de tiempo aplicado a actividades del plan las cuales llama horas de tarea, así como actividades que están fuera del plan. Por ejemplo, normalmente las juntas de equipo no se encuentran dentro del plan, esas se consideran horas fuera del pan. El manejar este parámetro adicional nos da más control sobre como mejorar la estimación. En un proyecto normal la cantidad de horas que se aplican en el día con día a actividades del plan de trabajo es alrededor de quince por semana. ¡Sí! no es un error quince por semana, esto quiere decir que si logramos mejorar este número a veinte por semana tenemos un aumento de productividad del 33%, que nos puede ser de ayuda para controlar grandes Cisnes Negros. Esto definitivamente no quiere decir que estos procesos eliminan los Cisnes Negros, éstos seguirán existiendo. Lo único que podemos esperar lograr es controlar el medio ambiente lo suficiente para poder reducirlos al mínimo. La mejora continua no es la solución a todos los problemas, pero entre más sabemos que esperar de nuestros procesos más crecemos como individuos y como negocios. —Luis R. Cuellar www.sg.com.mx

www.sg.com.mx

NOV-DIC 2007

// PRODUCTOS

/* LO QUE VIENE*/

Adobe AIR

Las interfaces atractivas.

Google Gears.

La experiencia del offline Adobe liberó la beta 2 de Adobe AIR, antes conocido con el nombre clave Apollo. AIR (Adobe Integrated Runtime) permite desarrollar y ejecutar aplicaciones para el desktop en diferentes sistemas operativos, utilizando tecnologías web como HTML, Javascript, Flex, Flash y Ajax. AIR es una propuesta que intenta tener éxito donde otros ya han fallado o han tenido éxito marginal, nos referimos a desarrollo de aplicaciones desktop que se puedan ejecutar en distintas plataformas usando el mismo binario. Java fue la primer gran promesa en este sentido, pero como sabemos, el éxito de Java en el desktop ha sido poco exitoso. La fórmula que propone AIR para lograr el éxito es a través de interfaces de usuario visualmente muy atractivas, y la utilización de las mismas tecnologías de programación que se usan en el web, de tal forma que la curva de aprendizaje sea mínima. La beta 1 de AIR fue liberada en junio, y en octubre se liberó la beta 2. El rumor es que la versión final estará disponible a principios del 2008. AIR actualmente se encuentra disponible para Windows y OS X, y próximamente se agregará soporte para Linux.

Google nos vuelve a sorprender con una de sus API’s cuya característica principal es permitirle a los desarrolladores crear aplicaciones que puedan ser ejecutadas en un modo “offline”. Formada de tres componentes, Google Gears llega para revolucionar el mundo Web y su desarrollo. Así, el almacenamiento de recursos, el almacenamiento de datos y la ejecución asíncrona están consideradas en esta API. Las estrategias de conexión, es decir, que el usuario decida cuáles serán las características que se soporten de manera local e implementar la lógica de cuándo utilizar el almacenamiento local y cuándo hacer conexiones al servidor, son parte de las posibles opciones que pueden definirse a través de la API. Mayor información en gears.google.com

Mayor información en labs.adobe.com/technologies/air

GeneXus

Nombre clave: Rocha

GridGain

Cómputo en grid para aplicaciones java

Ante la necesidad y tendencia de cómputo distribuido en malla (grid computing), existen diversas opciones y herramientas. Sin embargo, una que nos llama la atención en este segmento es GridGain. GridGain es un framework para habilitar grid computing en aplicaciones Java. Una de las principales fortalezas de GridGain, además de ser open source, es su simplicidad de uso, ya que todo se hace facilmente a través de anotaciones. Otra característica atractiva es su integración con JUnit. GridGain viene listo para usarse con los principales servidores de aplicaciones JEE como JBoss, Websphere y Weblogic, y también soporta una fácil integración con otras tecnologías populares como Spring y AspectJ. Mayor información en www.gridgain.com

10

NOV-DIC 2007

La próxima versión de Genexus lleva el nombre clave Rocha, y actualmente está disponible como beta. Como hemos indicado en artículos anteriores, Genexus es un generador de aplicaciones que utiliza un lenguaje descriptivo para capturar la estructura y comportamiento de una aplicación, y a partir de esta base de conocimiento puede generar el código correspondiente para diferentes plataformas, lenguajes y bases de datos. Genexus siempre ha buscado mantenerse en la punta de las tendencias e innovaciones tecnológicas, y Rocha no es la excepción. Entre los aspectos principales de esta versión están: • Wiki interno para definición de requerimientos • Definición y aplicación avanzada de patterns • Refactorización de base de datos • Diseñador de workflow embebido Mayor información en www.genexus.com/rocha

www.sg.com.mx

// PRODUCTOS

/* TUTORIAL*/

Una Introducción a Quartz Calendarización de tareas en Java Por Erick Frausto

Al desarrollar aplicaciones corporativas es común encontrarse con la necesidad de calendarizar tareas para que sean ejecutadas en automático cada cierto tiempo. Por ejemplo, podemos requerir que todos los días a medianoche se dispare un trabajo de sincronización de datos, o que el último día de cada mes se borren los archivos temporales de algún directorio. Las necesidades de agendar tareas pueden ser diversas y las aplicaciones que requieran de esto también serán muy distintas en tipo y en tamaño. Debido a este amplio rango de aplicación, no es raro encontrarnos con distintas herramientas de scheduling dentro de las cuales unas serán más adecuadas que otras para cubrir nuestras necesidades. En el caso de aplicaciones desarrolladas con Java EE, podríamos pensar en las capacidades de scheduling que proveen los EJBs como primera opción. Conociendo que el desarrollo de una aplicación empresarial mediante EJBs pudiera no ser la opción mas adecuada para nuestras necesidades, podríamos apostar por desarrollar nuestra aplicación sobre un framework más ligero como Spring, y recurrir al API de Java Timer para resolver la funcionalidad de calendarización de tareas. Sin embargo, Java Timer solo es un API con funcionalidad básica para el manejo de tiempo, y se queda corto de lo que debería proveer un framework completo para calendarización. Es aquí donde entra en juego Java Quartz. Quartz es un framework de scheduling open source que provee funcionalidad avanzada para la calendarización de tareas en Java. Entre estas están: • Cualquier tarea escrita en Java es susceptible de ser agendada dentro del framework para ser ejecutada. • Podemos agendar tareas en donde solo indiquemos la fecha y hora de ejecución y a partir de ahí definir una frecuencia de ejecu-

ción (ejemplo, ejecutar la tarea el primero de enero a las 12:00 a.m. y a partir de ahí, ejecutarse cada 3 días) hasta agendar tareas mediante el poder de las expresiones de Cron (ejemplo, ejecutar la tarea el segundo lunes de los meses de enero a septiembre del año 2008 a partir de las 8:00 a.m. cada 15 min. hasta las 10:00 a.m.). • Definir un medio de persistencia donde se almacene la información de tareas y sus agendas para poder darle la posibilidad al framework de recuperar dicha información ante fallas de la aplicación. • Capacidad de trabajar en un ambiente de clusters. Con esta funcionalidad, es claro que Quartz es una excelente opción que nos proporciona un framework robusto de scheduling, con integración en aplicaciones empresariales que requieran de alta disponibilidad mediante sus características de persistencia y clustering, adicionalmente ofreciendo la posibilidad de integrarlo con cualquier framework sobre el cual se desarrolle nuestra aplicación.

Un ejemplo sencillo Después de haber comentado acerca de lo que es Quartz y las características que nos ofrece, el siguiente paso es aplicar Quartz en un ejemplo práctico y qué otra manera de iniciar un ejemplo de este tipo sino es con el clásico “¡Hola, mundo!”. Cualquier tarea escrita en Java es susceptible de ser agendada dentro de Quartz, con el único requisito de que la clase que desarrolle dicha tarea implemente la interfaz org.quartz.Job la cual define un método execute que luce de la siguiente manera: public void execute(JobExecutionContext context) throws JobExecutionException;

Después de hacer que nuestra clase que desarrolla la tarea que deseamos agendar

implemente la interfaz Job, el siguiente paso sería preparar el ambiente de ejecución, lo cual consiste en: 1. Crear un Job a partir de esta clase 2. Asociarle un objeto de tipo Trigger (donde indicaremos cada cuándo la tarea deberá ser ejecutada) 3. Obtener una instancia de la clase Scheduler donde registraremos el Job creado. El listado 1 muestra un ejemplo de la implementación de la interfaz Job, mientras que el listado 2 muestra como se prepara el ambiente de ejecución. package quartzdemo; import org.quartz.Job; import org.quartz.JobExecutionContext; import org.quartz.JobExecutionException; public class HolaMundoJob implements Job{ public void execute(JobExecutionContext jobExecutionContext) throws JobExecutionException { System.out.println(“¡Hola, mundo! :D”); } } Listado 1. Implementación de la interfaz Job package quartzdemo; import org.quartz.JobDetail; import org.quartz.Scheduler; import org.quartz.SchedulerException; import org.quartz.SimpleTrigger; import org.quartz.Trigger; import org.quartz.helpers.TriggerUtils; import org.quartz.impl.StdSchedulerFactory; public class Test { public static void main(String[] args) { try { // Creacion de una instacia de Scheduler Scheduler scheduler = StdSchedulerFactory.getDefaultScheduler(); System.out.println(“Iniciando Scheduler...”); scheduler.start(); // Creacion una instacia de JobDetail JobDetail jobDetail = new JobDetail( “HolaMundoJob”,

Erick Frausto se desempeña como Arquitecto Java EE para ISOL (Ingeniería de Soluciones). Actualmente está trabajando en un proyecto para Afores en conjunto con la empresa EFP (Especialistas en Fondos de Previsión Social) donde está aplicando Quartz. Es egresado de Ing. en Informática de UPIICSA-IPN, es desarrollar Java certificado por Sun. Erick dedica este artículo a su familia y a las hermosas personas que ha encontrado en su camino.

12

NOV-DIC 2007

www.sg.com.mx

Scheduler.DEFAULT_GROUP, HolaMundoJob.class); // Creacion de un Trigger donde indicamos //que el Job se // ejecutara de inmediato y a partir de ahi en lapsos // de 5 segundos por 10 veces mas. Trigger trigger = new SimpleTrigger( “HolaMundoTrigger”, Scheduler.DEFAULT_GROUP, 10, 5000); // Registro dentro del Scheduler scheduler.scheduleJob(jobDetail, trigger); // Damos tiempo a que el Trigger registrado //termine su periodo // de vida dentro del scheduler Thread.sleep(60000); // Detenemos la ejecución de la // instancia de Scheduler scheduler.shutdown(); } catch(Exception e) { System.out.println(“Ocurrió una excepción”); } } } Listado 2. Preparación del ambiente de ejecución

Al ejecutar este código veremos en consola un resultado parecido al siguiente: 30/09/2007 01:45:27 PM org.quartz.simpl.SimpleThreadPool initialize INFO: Job execution threads will use class loader of thread: main 30/09/2007 01:45:27 PM org.quartz.simpl.RAMJobStore initialize Iniciando Scheduler... INFO: RAMJobStore initialized. 30/09/2007 01:45:27 PM org.quartz.impl.StdSchedulerFactory instantiate INFO: Quartz scheduler ‘DefaultQuartzScheduler’ initialized from default resource file in Quartz package: ‘quartz.properties’ 30/09/2007 01:45:27 PM org.quartz.impl.StdSchedulerFactory instantiate INFO: Quartz scheduler version: 1.4.5 30/09/2007 01:45:27 PM org.quartz.core.QuartzScheduler start INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started. ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D ¡Hola, mundo! :D 30/09/2007 01:46:27 PM org.quartz.core.QuartzScheduler shutdown INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED

www.sg.com.mx

shutting down. 30/09/2007 01:46:27 PM org.quartz.core.QuartzScheduler pause INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED paused. 30/09/2007 01:46:27 PM org.quartz.core.QuartzScheduler shutdown INFO: Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutdown complete.

En los mensajes arrojados por la consola, nos daremos cuenta que al principio aparece la información de inicialización de la instancia de Scheduler que obtuvimos, posterior a estos encontraremos los “¡Hola, mundo!” producto de las ejecuciones de nuestro Job que registramos dentro del Scheduler y finalmente veremos los mensajes que arroja la finalización de la instancia de Scheduler. Como mencioné anteriormente, Quartz soporta el manejo de expresiones de Cron que permiten hacer agendas más complejas que tan solo indicar un número de lapsos y periodo de ejecución para un Job. Imaginemos el caso de una empresa que tiene un proceso para calcular el nivel de producción que se tuvo en un mes, por lo que quisiéramos ejecutar este proceso en automático el último día de cada mes a las 6:30 pm que es la hora en que se termina la jornada laboral. El cambio a realizar en nuestro ejemplo, sería en la forma de crear el Trigger. Ahora en lugar de hacer una instancia de SimpleTrigger crearíamos una instancia de CronTrigger de la siguiente manera: Trigger trigger2 = new CronTrigger(“HolaMundoTrigger”,

Scheduler.DEFAULT_GROUP,

“0 30 6 L * ?”);

La intención aquí no es explicar como funcionan las expresiones de Cron, simplemente quiero hacer ver las posibilidades que ofrece Quartz. Quartz puede ser aprovechado tanto por aplicaciones muy sencillas, como por aplicaciones empresariales de misión crítica que mantengan una alta disponibilidad. Los invito a conocer más sobre Quartz en http://www.opensymphony.com/quartz/

Referencias: • Chuck Cavaness. “Quartz Job Scheduling Framework”. Prentice Hall. NOV-DIC 2007

// PRODUCTOS

/* NOVEDADES*/

Microformatos El poder de la semántica Por Sonia Sánchez

La mayoría de las nuevas tecnologías, se orientan al rendimiento del hardware para hacerlo más eficiente. Pero, ¿qué pasa del lado de los humanos? Tal vez sean pocas las ocasiones en que las nuevas herramientas esten completamente orientadas a los usuarios finales. Este es el caso de los microformatos, pequeños fragmentos de bits que surgieron para facilitar el desarrollo de aplicaciones Web y la interacción con este tipo de desarrollos.

¿Qué son los microformatos? Los microformatos son un conjunto de sentencias contenidas dentro de la semántica de XHTML utilizados para codificar la información de los contenidos HTML y de esta manera extraer su contenido semántico. Con el surgimiento de este tipo de componentes, se inicia una nueva era en la evolución del diseño Web y la información. Otro factor importante que este concepto evoluciona, es el camino de la descentralización. Es decir, para los usuarios dedicados a publicar contenido en el Web, son una herramienta de ayuda debido a que los hacen independientes de otra persona que los ayude a programar componentes, motivando con esto su reutilización. La finalidad de los microformatos es buscar la simplicidad descentralizando las dependencias existentes entre la semántica y la funcionalidad, adaptándose a los comportamientos y uso de patrones.

Su filosofía y principios. Como toda buena herramienta, los microformatos fueron diseñados bajo la siguiente filosofía: 1. Simplicidad en los formatos. Aunque parezca repetitivo, este es el principal punto de los microformatos: deben ser fáciles de aprender y usar. 2. “Podar el pasto”. Es decir, solamente crear un nuevo formato para usarse en una aplicación existente. 3. Ejecutar código. Adoptar un lenguaje de tipo scripting tales cómo PHP, Python o Perl es una de las adopciones primordiales. 4. Ser adoptados por “gente real”. Ir más allá de las discusiones semánticas. Desprendiéndose de esta los siguientes principios: • Resolver un problema en específico. • Comenzar tan simple como se pueda. Es decir, resolver primero los problemas más sencillos. • Diseñados, primero para las personas, después para las máquinas. Bajo este principio, los microformatos son presentables y analizables; esto es, los datos visibles son mejores que los metadatos invisibles. • Reutilización de bloques existentes desde los estándares adoptados. • Modularidad / Emebebido. Diseñados para ser reutilizados y em-

14

NOV-DIC 2007

bebidos dentro de formatos existentes y otros microformatos. • Habilitar y fomentar el desarrollo decentralizado, contenido, servicios. Tal vez uno de los principios más importantes, explícito fomento del espíritu original del Web.

Algunos microformatos. Una muestra de los ejemplos que representan la filosofía de los microformatos son: • RSS, para la sindicación. • xfn, orientado a las redes sociales. • GeoURL, para localización. • hCalendar, para calendarios de eventos. • hCard, para libretas de direcciones. • XOXO, para los blogrolls. • Attention.XML, para mentener los temas que más han acaparado la atención del usuario en la Web. Todos estos microformatos ya existen y algunos se han vuelto parte común de un día de trabajo, para otros, tal vez sea un tema nuevo, pero en ambos casos son una herramienta fácil de utilizar.

¿Y cómo se usan? El ambiente más común del uso de microformatos son los blogs. No solamente porque tienen un gran número de usuarios (mejor conocidos como bloggers), sino que además, son un ejemplo claro de cómo los microformatos rompen la barrera de la dependencia cuando existen muchos usuarios, que no precisamente son personas con los conocimientos técnicos necesarios para desarrollar un componente desde cero. hCard, es uno de los ejemplos mencionados anteriormente; no es más que un formato simple, abierto y distribuido (filosofía de los microformatos) para representar personas, empresas, organizaciones y lugares utilizando una referencia de vCard (RFC2426) propiedades y valores en semántica XHTML. hCard es uno de los diversos estándares abiertos de microformatos adecuado para embeberse en (X)HTML, RSS, Atom y XML arbitrario. Existe un generador de hCard disponible en el Web, que no es más que una sencilla forma generadora de la tarjeta de presentación, que puede ser utilizada por cualquier usuario . Esta puede consultarse en: microformats.org/code/hcard/creator Como se muestra en la figura 1, la pantalla del generador del hCard, está dividida en tres secciones. La primera es la forma que llena el usuario, con los datos requeridos. Al mismo tiempo, en la parte derecha se forma el contenido del código que no es más que el conjunto de sentencias adaptadas con la información obtenida a través de la forma.

www.sg.com.mx

puede insertar fácilmente el código XHTML generado con un simple copiar y pegar. El resultado final se muestra en la figura 2.

Figura 2. Tarjeta de presentación generada con hCard. Figura 1. Formato de hCard.

La tercera parte, a la derecha y sombreada, es la vista previa del llenado de la forma y cómo aparecerá una vez colocada en la página Web, observando claramente la ubicación de los datos. Una vez que el usuario ha terminado de llenar la forma con los datos necesarios,

Con este breve ejemplo, mostramos cómo los microformatos rompen la dependencia entre el usuario final y el técnico que pueda desarrollar un componente con alguna funcionalidad específica.

Referencia. • www.microformats.org

Danese Cooper Conocida en la industria como la “Diva del Open Source”, Danese Cooper es una de las personas con mayor influencia en el mundo del open source actualmente. Hoy en día, Danese es directora del Open Source Initiative (OSI) y colabora con Intel ayudándolos a desarrollar su estrategia open source. Anteriormente, Danese dirigió la oficina de open source en Sun Microsystems donde fue la principal impulsora de proyectos como Open Solaris, Open Office, Net Beans y la apertura de Java.

16

NOV-DIC 2007

www.sg.com.mx

// ENTREVISTA

¿Consideras que el open source es visto de forma diferente en los países desarrollados que en aquellos en vías de desarrollo? Si, definitivamente. En la mayoría de los países desarrollados, las empresas están viendo al open source como una oportunidad para innovar. En principio lo usan exclusivamente para su beneficio y ahorrar costos, pero eventualmente se dan cuenta de que es un círculo virtuoso en el que también tienen que aportar a la comunidad. Existe otro grupo de países que están estancados en el paradigma antiguo, y están acostumbrados a valorar todo en términos de dinero, y al corto plazo. Este es el caso de un país como Suiza, donde a las empresas les cuesta mucho trabajo entender los intangibles del open source, dado que no son directamente monetizables. Un ejemplo de estos intangibles es la reputación que puede generar una empresa al participar con open source, o ser considerada un buen lugar para trabajar y lograr así atraer al mejor talento. Por otro lado tenemos a varios países en desarrollo que ven el open source como una oportunidad de disminuir la brecha digital y ser competitivos en el mundo moderno. ¿Puedes darnos un ejemplo de un país en este último grupo? Uno de los casos que más me entusiasma es el de Sri Lanka. Este es un pequeño país en una isla al sur de India, con una guerra civil intermitente, y muchos otros problemas. Sin embargo, hay buenas universidades y jóvenes inteligentes. Hace unos años, un ministro tuvo la visión de decir “Wow, si le enseñamos a los jóvenes a participar en proyectos de open source, podremos desarrollar una economía local de tecnología.” Es así que se creó la Lanka Software Foundation, la cual beca a desarrolladores talentosos que desean participar en proyectos de open source. El objetivo de esta fundación es tomar a los desarrolladores locales y ayudarlos a convertirse en desarrolladores de clase mundial, comprometidos con su país y el open source. Es así que actualmente hay muchos desarrolladores de Sri Lanka involucrados en algunos de los proyectos open source de mayor importancia a nivel mundial. De hecho, Sri Lanka es el país que tiene el índice de contribución per cápita al open source más alto. ¿Qué sucede en casos de países fuertes en la industria de TI como India y China, pero que no participan mucho en el open source? India se tardó muchísimo en entrar al open source, pero ya lo está haciendo. Lo que sucede en India es que las empresas de software propietario llevan mucho tiempo invirtiendo fuertemente en este país para prepararlo como frente tecnológico contra China. Entonces, la educación en India es en parte financiada por estas empresas y se tenía el temor de que si adoptaban open source el sistema educativo se colapsaría. Sin embargo, ese miedo se ha superado y actualmente hay varias provincias de India que se han declarado abiertamente a favor del open source, y la cantidad de personas de este país que participa en proyectos de open source está aumentando significativamente. En el caso de China, ellos ven el open source como una forma de asegurarse de que no tiene trampas escondidas en el software que usa. Entonces, se basan en infraestructura de open source para construir sus propias soluciones. Hasta ahora, más que nada utilizan el software y casi no contribuyen de regreso, todavía no entienden esa parte del círculo virtuoso, pero eventualmente lo harán.

www.sg.com.mx

¿Qué hay sobre la percepción de personas en países en desarrollo que argumentan que no pueden darse el lujo de contribuir al open source, porque necesitan “trabajar por dinero”? Un desarrollador que se toma el tiempo para contribuir al open source está construyendo una reputación, y ésta reputación le será útil, especialmente en un mundo globalizado. Debemos recordar lo que sucedió durante la burbuja de los .com, cuando los profesionistas de tecnología en Estados Unidos tenían una tasa de desempleo de .5%. Eso es demasiado bajo, significa que se le daba empleo aún a personas a quienes no se les debía dar. Y aun así, la industria estaba hambrienta de conseguir más gente. Hoy en día, la mayoría del desarrollo se hace en el Internet, así que las empresas no tienen inconveniente en buscar talento fuera de los Estados Unidos, y a las primeras personas que consideran son aquellos que demuestran que saben lo que están haciendo, y una excelente forma de conseguir esto es participando en proyectos de open source. ¿Qué nos puedes comentar sobre el tema de estándares abiertos? Los gobiernos en todo el mundo están empezando a hablar de estándares abiertos y buscan que sus políticas de compra fomenten la adquisición de productos que se apeguen a estándares abiertos. El problema es que no hay un consenso sobre lo que realmente significa un estándar abierto, y el caso de OpenXML es un buen ejemplo de esta polémica. Creo que en los próximos meses surgirá un consenso de lo que realmente debe significar un estándar abierto. En el caso de OSI, nuestra postura es que uno de los criterios que debe cumplir un estándar para ser considerado abierto es que pueda ser implementado con open source. ¿Qué opinas sobre la iniciativa reciente de Microsoft de hacer disponible el código fuente de partes de .Net? Siempre he dicho que tarde o temprano Microsoft debe entender e involucrarse de alguna manera en el open source. Creo que esta iniciativa es una señal de que se están dando cuenta de que deben ser parte de la fiesta. Y al igual que Sun, IBM, y cualquier otra de las grandes empresas de software que ha adoptado el open source en años recientes, no van a hacer las cosas perfectas desde un inicio. Esto no es posible por el cambio tan grande que significa. Por ejemplo en el caso de Sun, ellos empezaron creando sus propias licencias con su propio nombre y bajo sus propias condiciones. Después se dieron cuenta de que no estaban obteniendo lo que esperaban de parte de la comunidad, y desde entonces se han estado moviendo poco a poco hacia licencias de mayor aceptación. Creo que Microsoft está en ese mismo camino. Están empezando con pasos de bebé, haciendo el código fuente disponible pero no modificable. Eventualmente se darán cuenta que lo mejor es utilizar licencias que permiten modificar y redistribuir el código. ¿Algunas palabras para nuestros lectores? Debemos entender que el software se está convertido en algo crucial para nuestro modo de vida, y deberíamos ser capaces de saber que es lo que el software que usamos realmente está haciendo. No es un tema tecnológico ni filosófico, es un tema de calidad de vida. Es por ello que el cambio fundamental es hacia la transparencia, ya sea que la llamen open source, software libre o como quieran. En el fondo es un tema de transparencia, de entender que los secretos son algo malo cuando se refieren a algo que todos usamos y que es indispensable para nuestras vidas.

NOV-DIC 2007

17

Encuesta de Salarios2007 compensación que recibes es justa? ¿Crees ¿Sabessiquelapodrías ganar más en otro lugar? ¿Quieres saber qué área de especialización es la que más te conviene? ¿Vale la pena estudiar una maestría? Estas y otras preguntas nos hacemos a diario los profesionistas de sistemas. Estas son preguntas que los profesionistas de software actuales nos hacemos constantemente, y es por ello que periódicamente

18

NOV-DIC 2007

en SG realizamos una encuesta de salarios. La primera edición fue realizada en septiembre del 2005, y los resultados se publicaron en la edición de noviembre 2005. Dos años después, hemos realizado el mismo ejercicio para monitorear el estado de los profesionistas y salarios en nuestra industria. Veamos entonces que información nos arroja la encuesta de salarios 2007.

www.sg.com.mx

Acerca de la fuente de información La información presentada en las siguientes páginas es resultado de una encuesta abierta realizada por medio del website de SG en septiembre del 2007. La encuesta fue contestada por 2,346 personas, lo cual supero por más del doble la cantidad de respuestas obtenidas en la edición anterior de la encuesta de salarios (1,043) realizada en septiembre del 2005.

www.sg.com.mx

NOV-DIC 2007

19

Radiografía del Capital Humano de

A

ntes de iniciar con los detalles de sueldos y sus variaciones, consideramos pertinente estudiar la estructura y perfil demográfico de la muestra de personas que contestaron la encuesta. De la misma manera, esta información nos da una buena idea de cómo está compuesto el universo de profesionistas de software en nuestro país y permite obtener un análisis al respecto.

Esquema de contratación

Tipo de organización

La tabla 1.2 muestra el desglose de la muestra en base al esquema de contratación

Los profesionistas de sistemas laboramos en distintos tipos de organizaciones. Hay quienes forman parte del área de informática de una empresa cuyo negocio principal no es el software ni la tecnología (bancos, gobierno, manufactura, etc), otros tantos laboran en empresas cuyo negocio es proveer servicios de desarrollo, implantación y mantenimiento de TIs. Otro tipo de organizaciones son los ISVs (Independent Software Vendors) que son las empresas que crean tecnología propia para comercializarla, así como los distri buidores o canales que revenden tecnología de terceros, y por último tenemos a las organizaciones cuyo negocio son los servicios educativos relacionados con tecnología de información. La tabla 1.1 muestra el desglose de los encuestados de acuerdo al tipo de organización en que laboran. Tipo de organización Área de sistemas Proveedor de servicios Canal/distribuidor ISV Servicios educativos Otro

%

47.4 26.8 1.3 8.4 6.7 9.3

Tabla 1.1. Desglose por tipo de organización

Podemos ver que la mayoría de los profesionistas de sistemas trabajan en organizaciones cuyo negocio no es la tecnología de información. Esto denota una industria de TI poco madura, que es principalmente “usuaria”, en lugar de creadora o proveedora. De hecho, esta es una de las métricas que Secretaría de Economía rastrea para medir el avance de ProSoft, y se espera que esta relación sea revertida para el 2013. Es decir, que la mayoría de los profesionistas de software de nuestro país laboren en empresas proveedoras o creadoras de TI, dejando alrededor de un 30% en áreas usuarias.

20

NOV-DIC 2007

Uno de los temas tabú en México es el de si las empresas deben pagar por nómina u honorarios. El esquema de honorarios es conveniente para las empresas, debido a la flexibilidad que les brinda. Sin embargo, el problema es la falta de protección con que deja a los empleados, lo cual típicamente provoca insatisfacción.

Esquema

Nómina Honorarios Independiente Otro

%

66.2 24.1 6.3 3.4

Software

en conocimiento y requiere mucha preparación, por lo tanto no es ninguna sorpresa que la mayoría de los profesionistas de software por lo menos estén titulados de algún grado universitario. Es cierto que hay casos de excelentes profesionistas que a lo mucho terminaron la preparatoria, pero sabemos que son la excepción y no la norma. Escolaridad

Preparatoria Técnica Universidad sin titular Universidad titulado Posgrado Maestría Doctorado

%

1.2 2.7 26.7 47.0 4.8 16.7 0.9

Tabla 1.2. Esquema de contratación

Tabla 1.4. Máximo grado de estudios terminado

Edad

Género

La tabla 1.3 muestra el desglose por rango de edad de la muestra que contestó la encuesta. Como podemos ver, la gran mayoría está concentrada en los grupos de edad de 25 a 29 y 30 a 39. De hecho, en base a los porcentajes acumulativos nos damos cuenta que más del 50% de los profesionistas son menores a 30 años, y cerca del 90% son menores a 40. Podemos interpretar estos números como un indicador de que cada vez más jóvenes se están uniendo a nuestra profesión, pero también son un recordatorio de lo complicado que es mantenerse vigente y activo conforme van pasando los años. Edad

18 a 24 25 a 29 30 a 39 40 a 49 50 a 59 60 o Más

%

16.4 35.6 37.7 8.6 1.5 0.2

Tabla 1.3. Rango de edad

Escolaridad

A continuación revisamos el máximo grado de estudios terminado por las personas que contestaron la encuesta, el cual se puede apreciar en la tabla 1.4. Es bien sabido que nuestra profesión es intensiva

Definitivamente, uno de los inconvenientes de nuestra profesión es la poca cantidad de mujeres que hay en ella. Los resultados en la tabla 1.5 nos confirman esto. Género

Femenino Masculino

%

14.3 85.7

Tabla 1.5. Género

Antigüedad

¿Qué tanto tiempo nos mantenemos en la misma organización? Los números de la tabla 1.6 parecen indicar que somos una especie nómada, ya que nos dicen que más del 60% de los encuestados tiene menos de 3 años en su organización actual. Sin embargo, esta información es un poco engañosa y en la parte 3 de este artículo (“Información Escondida”) veremos por qué. Antigüedad

Menos de un año 1 a 3 años 3 a 5 años 5 a 10 años Más de 10 años

%

22.4 38.4 14.3 16.0 8.9

Tabla 1.6. Antigüedad en la organización actual

www.sg.com.mx

“Más del 50% de los profesionistas son menores a 30 años y cerca del 90% son menores de 40”

www.sg.com.mx

NOV-DIC 2007

21

Salarios y Factores Y

entonces, ¿cuánto gana un profesionista de software en México? La tabla 2.1 indica los tabuladores de salario que se manejaron en la encuesta, así como el porcentaje de personas que cae en cada uno. Nota: Todas las cantidades se refieren a pesos mexicanos.

Rango de salario Menos de 4 mil 4 a 6 mil 7 a 10 mil 11 a 15 mil 16 a 20 mil 21 a 25 mil 26 a 30 mil 31 a 40 mil 41 a 50 mil 51 a 60 mil 61 a 80 mil

%

3.6 8.2 14.9 18.5 17.5 12.1 9.6 7.9 3.0 2.0 1.7

Tabla 2.1. Tabuladores de salario mensual.

Estos números arrojan un promedio ponderado de $19,946 pesos. De acuerdo a la encuesta, esta cantidad es el salario bruto mensual de un profesionista de software en México. Al compararse esta cantidad con el resultado de la encuesta de salarios 2005, que fue de $18,469 pesos, obtenemos un aumento de 8%, el cual apenas coincide con la inflación en ese periodo.

Esquema

En la tabla 2.2 podemos ver los salarios promedio dependiendo del esquema de contratación. Se incluyen dos cantidades, la primera es el sueldo bruto mensual, y la siguiente es un salario integrado, que contabiliza las prestaciones e incentivos monetarios.

22

NOV-DIC 2007

Esquema

Nómina Honorarios Independiente

Bruto 20,384 19,455 18,220

Integrado 22,915 20,553 19,580

Tabla 2.2. Desglose por esquema de pago

Típicamente, se espera que la compensación bruta por honorarios sea mayor que por nómina, pero que al integrar las prestaciones e incentivos monetarios anuales, la compensación por nómina sea mayor. Sin embargo, los números arrojados por la encuesta nos dicen que incluso el sueldo bruto de las personas en nómina está siendo mayor que el de las personas por honorarios. Como era de esperarse, la compensación que reciben los independientes es menor tanto en forma bruta como integrada. Es el precio que hay que pagar por la independencia.

Variación por región

Como nos lo temíamos, los salarios varían muchísimo dependiendo del estado de la República al que nos refiramos. La tabla 2.3 muestra el sueldo mensual promedio desglosado por estado, e indica porcentaje que cada estado representa respecto al total de encuestados.

Estado

NL DF QRO MEX AGS MOR JAL CHIH TAB BC GTO MICH PUE SIN VER

%

9,1 35.1 2.8 7.4 2.7 1.5 8.2 2.0 1.7 3.3 2.5 1.9 2.8 3.1 2.9

Salario Prom. 25,068 24.742 23,523 21,247 18,847 18,788 18,538 16,630 16,224 16,147 15,857 13,571 12,133 11,993 9,054

Tabla. 2.3. Salario mensual promedio por estado

La lista solo incluye aquellos estados de donde obtuvimos una muestra mayor a 30 personas, ya que de otra forma la información sería muy poco representativa. Es así que por medio de este listado también podemos darnos una idea de qué estados son los que tienen mayor participación en la industria de software. En el 2005, el estado mejor pagado resultó ser el D.F., seguido por Nuevo León. Este año podemos ver que ambas entidades siguen a la cabeza, pero que Nuevo León ahora tiene el primer lugar. Los estados de donde obtuvimos los sueldos promedio más bajos fueron Chiapas ($6,690) y Colima ($7,346), aunque estos no fueron incluidos en la lista debido a que no se reunía la cantidad de muestras suficiente como para que fuera representativa. Sin embargo, mencionamos estos números para hacer ver que en los estados mejor pagados, el sueldo promedio puede

www.sg.com.mx

llegar a ser hasta tres veces mayor que en los peor pagados. En cuanto a salarios en otros países, la tabla 2.4 muestra los resultados que generamos a partir de las respuestas de lectores internacionales. En este caso bajamos el límite mínimo de muestras a cinco. Es decir, solo aparecen los países de donde se haya tenido un mínimo de cinco respuestas. La información no es científicamente representativa, pero nos ayuda a darnos una idea de cómo está la cosa en otros países.

País

EU Chile Guatemala España Argentina Colombia Perú Ecuador Venezuela Bolivia Uruguay

Salario Prom.

Al igual que en el estudio del 2005, los proveedores de servicios son los que resultaron con el salario más alto. De la misma manera, desgraciadamente las personas que laboran en instituciones educativas siguen estando muy por debajo del resto, manteniéndose de nueva cuenta en este rango.

Función

Sabemos que en las Tecnologías de Información hay una gran variedad de roles y jerarquías, y que la compensación varía significativamente dependiendo de ello. Entonces, ¿qué trabajos de T.I. son los mejores pagados? La figura 2.2 ilustra algunas de las funciones de T.I. más comunes, con su salario promedio.

Figura 2.3. Salario por rango de edad

62,727 33,500 27,000 26,864 18,944 15,917 15,278 12,000 10,625 10,500 9,000

Tabla 2.4. Sueldo mensual promedio internacional

Tipo de organización

Que conviene más, ¿trabajar para las empresas que proveen productos/servicios de TI, o para el departamento de sistemas de una empresa que los consume? La figura 2.1 nos muestra los salarios promedio clasificados por tipo de organización.

Figura 2.2. Salario por función

Género

Nuestra industria refleja una diferencia significativa entre el salario promedio de una mujer ($15,416) y el de un hombre ($20,713), lo cual significa una diferencia del 34%. Esta brecha aumentó respecto a los resultados obtenidos en 2005, donde la brecha era del 20%.

Escolaridad

Uno de los factores de mayor relevancia en nuestra industria es el máximo grado de estudios alcanzado. Esto tiene sentido ya que nuestra profesión es altamente intensiva en conocimiento. (Ver Figura 2.4).

Edad

La edad sigue siendo un factor importante en cualquier profesión, y en este estudio, la nuestra no es la excepción. La figura 2.3 nos muestra los salarios promedio por rango de edad.

Figura 2.1. Salario por tipo de organización

www.sg.com.mx

Podemos apreciar que el salario promedio va creciendo conforme aumenta la edad, alcanzando su tope en el rango de los 50 a los 59 años y posteriormente desciende.

Figura 2.4. Salario promedio por grado de estudios

NOV-DIC 2007

23

Conocimientos y habilidades

Como sabemos, nuestra profesión cuenta con una gran variedad de tecnologías y áreas de conocimiento en las que uno se puede especializar. ¿Qué tecnologías son las que mejor se cotizan en el mercado laboral? Las figuras 2.5a a 2.5d nos mues-

tran los resultados. Hemos incluido dos columnas para cada variable. La primer columna indica el salario promedio para personas con esta habilidad, y la segunda columna indica el porcentaje dentro del total de respuestas que indicaron tener dicha habilidad.

Figura 2.5a. Lenguajes de programación $35k $30k $25k $20k

17.3k

$15k

19.8k

19.6k

19.5k

21.8k

0

80%

25.8k

24.2k

60%

39%

40% 28%

$10k $5k

100%

32.4k

89%

20%

13%

DOS

9%

7%

Linux

Apple

Win

Win CE

6%

AS400

4%

Unix

Mainframe

0%

Figura 2.5b. Plataformas

Figura 2.5c. Bases de datos

24

NOV-DIC 2007

www.sg.com.mx

Variación en los últimos 12 meses

Los resultados en cuanto a variación de salario en los últimos doce meses son muy similares a los que se obtuvieron en el 2005. Alrededor del 65% reportaron que su sueldo no cambió en este año, o a lo mucho aumentó en 5%, lo cual parecer ser simplemente un ajuste inflacionario. Solamente un 17% logró aumentar su compensación más allá del 10%. Los detalles están en la tabla 2.5. Variación en el salario Disminuyó Sin cambio De 1 a 5% De 6 a 10% De 11 a20% De 21 a 30% De 31 a 50% De 51 a 100% Más de 100%

Figura 2.5d. Otras habilidades

Como podemos ver, las tecnologías más populares no necesariamente son las mejor pagadas. Lo que parece tener mayor impacto en el salario para cada tecnología, es qué tanto se utiliza esta en los grandes corporativos. Es por eso que tecnologías como Cobol y Mainframe, que se utilizan mucho en el sector financiero, tienen los salarios más altos a pesar de no ser nada nuevas. Podemos apreciar que las tecnologías open source ya cuentan con una buena base instalada de gente acostumbrada a utilizarlas. Uno de los casos que más nos llama la atención es el de MySQL, que está por encima de Oracle y solo está por detrás de SQL Server.

Certif icaciones

A pesar de que a muchas personas no les agraden las certificaciones ya que consideran que “el que sabe, sabe”, y que un papel no es garantía, sabemos que una certificación es de gran ayuda en el reclutamiento. La figura 2.6 muestra algunas de las certificaciones más populares entre profesionistas de software y el salario promedio para cada una. Al igual que en los resultados del 2005, la certificación mejor retribuida y por mucho, es la de Project Management Professional del PMI. Esta certificación requiere de un gran esfuerzo, posiblemente comparable al de una maestría, pero de acuerdo con los números es una inversión que bien vale la pena.

%

5.9 36.8 28.4 11.5 6.8 3.8 3.4 2.2 1.2

Tabla 2.5. Variación de salario en 12 meses

Prestaciones

Al analizar un esquema de compensación, no podemos dejar de revisar las prestaciones ofrecidas. La tabla 2.6 indica las prestaciones más comunes, y el porcentaje de los encuestados que recibe cada una. Prestación



%

Gastos médicos mayores Horario flexible Préstamos Bonos por desempeño Gastos médicos menores Teléfono celular Ayuda para educación Trabajo desde casa Ayuda familiar Automóvil Departamento Acciones (stock options)

42.6 38 33.3 26.4 20.7 18.2 12.3 12.3 6.5 6 6.2 4.7

Tabla 2.6. Prestaciones recibidas

Figura 2.6. Certificaciones www.sg.com.mx

NOV-DIC 2007

25 19

Satisfacción y Motivaciones H

abiendo analizado el perfil de los encuestados y la información de salarios, detengámonos un momento para analizar la satisfacción y motivaciones de los profesionistas de software.

La distribución por grupo se aprecia en la figura 3.2. 12%

25%

Satisfacción con empleo actual

Consideramos que la satisfacción con el empleo actual se puede calificar en dos aspectos, el primero tiene que ver con el tipo de trabajo que se realiza, y el segundo tiene que ver con la compensación que se recibe por éste. La tabla 3.1 nos muestra los resultados de satisfacción en ambos aspectos. Como era de esperarse, hay más gente satisfecha con su trabajo que con su compensación. Grado de satisfacción

Muy satisfecho Algo satisfecho Poco insatisfecho Muy insatisfecho

Con el trabajo %

37.2 43.8 13.8 5.1

Con la compensación % 18.0 52.7 21.8 7.5

17% Activamente

46% Pasivamente

Misma empresa

No buscando

Figura 3.2. Estatus de búsqueda de empleo

Analizando las razones por las que cambiarían de trabajo, tenemos lo siguiente:

Tabla 3.1. Satisfacción con empleo actual

Motivadores

Una pregunta que los empleadores deben hacerse si es que pretenden retener a su gente, es ¿qué es lo que más aprecian de su trabajo actual? Definitivamente los profesionistas de software estamos hambrientos de conocimiento y desarrollo profesional, lo cual se aprecia en la figura 3.1.

Figura 3.3. Razones para cambiar de empleo.

Benef icios buscados

Figura 3.1. ¿Qué es lo que más aprecias de tu empleo actual?

En cuanto al estatus de búsqueda de trabajo, tenemos 4 grupos: quienes activamente buscan trabajo, quienes considerarían una mejor oferta (pasivos), quienes están buscando una mejor posición en la misma empresa, y quienes no están buscando.

26

NOV-DIC 2007

Por último, en la tabla 3.2 podemos ver cuales son los beneficios que a la gente más le gustaría que sus empresas ofrecieran.

Beneficio

Bonos de desempeño Gastos médicos mayores Vivienda Ayuda para educación Flexibilidad de horario Automóvil Trabajo desde casa Gastos médicos menores Acciones

%

41.9 37.8 27.6 27.3 22.9 22.7 19.3 14.8 14.6

Tabla 3.2. Principales beneficios buscados www.sg.com.mx

Información Escondida P

rácticamente toda la información que se presentó en las secciones anteriores de este artículo se refiere a estadísticas descriptivas donde se analiza una sola variable al mismo tiempo. En esta sección hacemos un análisis más detenido de algunas variables clave para encontrar información que en principio parezca estar escondida.

Tipo de organización vs. esquema de contratación

La tabla 4.1 cruza las variables tipo de organización contra esquema de contratación, para averiguar que tanta relación hay entre estas. Esta tabla se lee por renglones, por ejemplo: “de la gente que labora en área de sistemas, el 78.7% está por nómina, el 16.4% por honorarios, el 3% es independiente y el 1.9% tiene otro esquema”.

Nómina % Honorarios % Independiente % Otro %

Área de sistemas Proveedor de servicios Distribuidor de TI ISV Servicios educativos

78.7 42.3

16.4 40.7



3.0 11.4

1.9 5.6

48.4

32.3



19.4

0

60.2 72.2

25.5 17.7



9.7 7.6

4.6 2.5

Tabla 4.1. Cruce tipo de organización y esquema de contratación

Como era de esperarse, en las áreas de sistemas predominan los empleados en nómina, con una relación de más de 4 a 1 contra los empleados por honorarios. Sin embargo, en el caso de los proveedores de servicios, esta relación es casi 1 a 1.

Nómadas o sedentarios

En la página 21 se indicó que el 60% de los profesionistas de software tenían menos de 3 años en su empleo actual, lo cual hace parecer que nos quedamos muy poco tiempo en la misma organización. Sin embargo, ya se había dicho que la mayoría de los profesionistas tienen menos de 30 años, así que puede ser que la razón por la que tanta gente tenga poca antigüedad en su empleo actual, es porque apenas es el primero. Para confirmar esto realizamos un cruce de antigüedad contra edad, y encontramos que la mayoría de las personas que tienen menos de 3 años en su organización son personas con edades entre 25 y 29 años, lo cual nos hace pensar que apenas se encuentran en su primer o segundo trabajo. Así que no somos tan gitanos como parecía en un principio (Ver Tabla 4.2).

Maestría o certif icación

Ya vimos el salario promedio para los diferentes grados de escolaridad, y también vimos los sueldos promedio para las diferentes certificaciones. Pero una pregunta que queda en el aire es ¿Qué conviene más, certificación o maestría? Sabemos que esto es comparar peras con manzanas, ya que los objetivos de ambos son muy diferentes, y los beneficios de la certificación son a corto plazo mientras que los de la maestría son a largo plazo. Aun así, no hemos resistido la tentación de hacer esta comparación. www.sg.com.mx

Antigüedad 18 a 24 25 a 29 30 a 39 40 a 49 50 a 59 60 o más Menos de un año 1 a 3 años 3 a 5 años 5 a 10 años Mas de 10 años

35.4%

38.6%

22.8%

2.7%

.6%

0

19.3% 6.6% .8% 0

49.4% 38.2% 15.4% 1.0%

27.1% 49.0% 68.6% 47.4%

3.4% 6.0% 12.8% 42.1%

.7% 0 2.4% 8.1%

0 .3% 0 1.4%

Tabla 4.2. Cruce de antigüedad y edad.

Para esta comparación hemos decidido no tomar en cuenta la certificación del PMI. Consideramos que es un caso aparte tanto por el esfuerzo que requiere como por el salario que arroja.* Es así que al obtener un promedio ponderado del salario de las personas con alguna certificación (excepto PMI) llegamos a un resultado de 24,300 el cual está por debajo de los 25,600 pesos de una maestría. Así que en términos económicos, sigue siendo más redituable una maestría que una certificación. Sin embargo, todos sabemos que el esfuerzo e inversión requerida para una maestría es mucho mayor que para una certificación, así que la certificación sigue siendo una opción bastante atractiva, al menos al corto plazo.

Horas trabajadas vs. sueldo

Para terminar con esta sección hemos hecho un cruce entre el salario y la cantidad de horas trabajadas por semana. Podemos ver que la gran mayoría de los encuestados están en el rango de las 41 a 50 horas trabajadas, independientemente de su salario. Sin embargo, vemos que en los rangos de salario mayores a 40 mil pesos, las jornadas de trabajo de 51 a 60 horas son mucho más comunes que en los rangos de salario menores. Salario

7 a 10 mil 11 a 15 mil 16 a 20 mil 21 a 25 mil 26 a 30 mil 31 a 40 mil 41 a 50 mil 51 a 60 mil 61 a 80 mil Mas de 80 mil

Horas trabajadas por semana 21-30 31-40 41-50 51-60 60+

7.7% 3.6% 3.3% 2.2% 1.9% 2.3% 3.0% 0 2.7% 0

25.4% 24.2% 22.7% 17.5% 18.8% 14.7% 10.4% 9.3% 5.4% 4.5%

54.0% 60.9% 57.1% 59.5% 66.5% 63.8% 56.7% 62.8% 51.4% 54.5%

9.4% 10.1% 14.4% 16.4% 8.7% 16.9% 20.9% 20.9% 32.4% 27.3%

3.5% 1.2% 2.5% 4.4% 4.1% 2.3% 9.0% 7.0% 8.1% 13.6%

Tabla 4.3. Cruce de salario y horas trabajadas

* Para aquellos curiosos que no se quieren quedar con las ganas de averiguar cual es el salario promedio de los certificados incluyendo PMI, les informamos que éste es de 25,900 pesos. NOV-DIC 2007

27

Comentarios de los Expertos “La mercancía de la nueva economía es el conocimiento. En el ámbito de las Tecnologías de Información esta mercancía ha resultado tan escasa, que de pronto se desvirtúa el parámetro del precio y se llegan a encontrar salarios con grandes diferenciales para trabajos muy similares. Por ello, resulta de capital importancia el esfuerzo de SG al aplicar esta encuesta.” Jose Luis Rodríguez Director de México, Kelly IT Resources.

“Hoy por hoy, el mercado laboral de TI se enfoca principalmente en los skills de Mainframe, Java, .Net, SAP, y Oracle. Estas son posiciones para las cuales siempre hay requerimientos abiertos. También hay posiciones de mayor especialidad, como por ejemplo gerentes de proyecto certificados bajo el PMI. La brecha entre las habilidades de los recién egresados y lo que requieren las empresas es enorme. Las instituciones educativas deben estar más atentas sobre las habilidades que está requiriendo la industria.” Ana Rivera,

“De acuerdo con encuestas realizadas por Manpower Professional, cuarenta y un por ciento (41%) de los empleadores en México enfrentan dificultades para cubrir las vacantes de puestos profesionales permanentes debido a la falta de talento disponible, lo cual amenaza los planes de crecimiento. Veinticinco por ciento (25%) de los empleadores están pagando salarios más altos por los mismos puestos, con respecto al año anterior, debido a la falta de talento profesional.” Roberto Cabrera

Gerente de Reclutamiento, Manpower Professional.

“Según datos proporcionados en Estados Unidos en su estadística de trabajo 2005, se estima que la demanda de profesionales en TI tendrá un crecimiento del 50% para el 2012 con más de 1.5 millones de empleos relacionados con la industria. Las certificaciones con reconocimiento mundial son la forma principal de desarrollo profesional en esta industria. Algunos de los per-

files más solicitados son: Desarrolladores ( Java, C#, ABAP, Cobol), especialistas de Middleware, DBAs, Consultores ERP (SAP, Oracle), Consultores en Business Intelligence y Project Managers” Joselyn Reynoso Consultor en reclutamiento para IT, Adecco México

“Las organizaciones deben poner atención y entender el comportamiento de los salarios y las características de los perfiles demandados y ofrecidos para el segmento de Tecnologías de Información, si es que desean hacerse llegar del talento necesario y conservarlo. Durante los dos últimos años se han observado incrementos salariales en este segmento de alrededor del 20%, mientras que para el total de los demás asalariados ha sido del 4% anual. Es evidente que la diferencia obedece a la alta demanda en la industria y la baja oferta sobre estos perfiles especializados. ” Edgar Murriatt Director Business Line IT, Adecco México

Consultor de Reclutamiento, Kelly IT Resources.

“La saturación de carreras administrativas y el decremento de ingreso en Ingenierías provocarán en el mercado un desequilibrio importante que no dará abasto a las empresas hambrientas de este recurso, que además tiene problemas para integrarse rápidamente al ritmo de trabajo actual. Una tendencia importante son las certificaciones durante la formación profesional. Las certificaciones serán un puente muy importante para poder insertar rápida y eficazmente a los nuevos egresados en la industria.” Laura Garza

Coordinadora Capital Humano, Sieena Software.

“En base a la información que nosotros tenemos, actualmente un profesionista de software aspira a un sueldo ligeramente por encima de los 20 mil pesos mensuales. En el interior de la República existe una leve variación estando la media en 18 mil. En cuanto a las habilidades y perfiles mejores pagados, entre los roles más solicitados puedo mencionar Consultores de Oracle, Consultores de ERPs, desarrolladores en .Net y Arquitectos Java.” Susana Jiménez M. Gerente de RH, Hildebrando.

28

NOV-DIC 2007

www.sg.com.mx

www.sg.com.mx

NOV-DIC 2007

// PRÁCTICAS

/* ADMINISTRACIÓN DE PROYECTOS*/

Límites de Estimación Una consideración crítica al momento de integrar el plan de trabajo del proyecto Por Jorge Valdés Garciatorres

Como decía el célebre físico alemán Neils Bohr: “Hacer predicciones es muy difícil … sobre todo si se trata acerca del futuro”. No hay que perder de vista que cuando de estimaciones se trata, estamos tratando de predecir el futuro, y en ese sentido nadie tiene la verdad absoluta. Para reducir el nivel de incertidumbre asociado a las estimaciones, existen varias técnicas que, en muchos de los casos, proponen reducir el horizonte de planeación, de manera que podamos manejar bloques de trabajo con menor riesgo inherente. Otra recomendación es la de descomponer (desglosar) el trabajo hasta que: • Podamos establecer un criterio de terminación binario. Es decir, al término del periodo (una o dos semanas máximo), el entregable debe estar concluido o bien existe un retraso en el proyecto. • Que este paquete de trabajo pueda ser asignado a una sola persona, de manera que esté asignada, claramente, la responsabilidad de su conclusión. Una recomendación más, y que es en la que se enfoca este artículo, es que el horizonte de planeación establezca límites muy claros para la planeación de los proyectos. Esta limitación de la estimación, sin lugar a dudas ayuda a mitigar riesgos e incrementar las posibilidades de éxito de un proyecto. Veamos entonces en que consisten los límites de estimación.

Aplicando límites de estimación al WBS La creación de una estructura de división del trabajo (WBS – Work Breakdown Structure) requiere de un desglose repetitivo de grandes bloques de trabajo en unidades pequeñas denominadas paquetes de trabajo. Una pregunta común, y muy apropiada es: ¿Qué tan pequeños tienen que ser los paquetes de trabajo antes de que no sea necesario separarlos más? Justamente este

es el límite de estimación, el momento en el cuál no tiene sentido continuar con el proceso de descomposición del trabajo. No existe una receta de cocina para el límite, pero existen algunas normas generales y algunas excepciones aplicables. Por ejemplo, aun para los proyectos más grandes no deberían existir actividades con un esfuerzo mayor a 80 horas. Es así que cualquier paquete de trabajo mayor a 80 horas de esfuerzo, debería ser descompuesto en piezas de trabajo más pequeñas. En el caso de proyectos medianos este límite se puede establecer en 40 horas y para proyectos pequeños podríamos descomponer el trabajo hasta llegar a actividades de 20 horas. Es necesario recordar que estos límites son máximos, es decir que podemos tener actividades más pequeñas en caso de que tengan sentido, pero lo que no podemos es tener actividades que representen un esfuerzo mayor al límite establecido.

Excepciones Al aplicar los límites de estimación hay dos excepciones que debemos tener en cuenta. La primera excepción se refiere a aquellas actividades a ser desarrolladas en un futuro distante que no pueden ser descompuestas debido a que hay gran incertidumbre sobre ellas. Si este es el caso de solo algunas actividades de gran duración, entonces no hay problema en dejar ese trabajo en un nivel alto. Sin embargo, si se dificulta definir y estimar gran parte de este trabajo futuro, puede ser mejor el separarlo completamente en otro proyecto. Por ejemplo, puede ser difícil planificar y estimar el trabajo de construcción y pruebas, sin que antes se tengan claros los requerimientos de negocio. En este caso, el primer proyecto debe estar limitado a la recopilación de requerimientos de negocio, y otro proyecto sería el que se encargue del diseño, la construcción y las pruebas de la solución. Con base en los resultados del primer proyecto, el segundo proyecto puede establecerse claramente y en consecuencia, puede ser estimado

Jorge Valdés Garciatorres es Director de la firma global de consultoría y educación en procesos de negocio y dirección de proyectos TenStep y representante de la firma a nivel Latinoamérica. También es vicepresidente de certificación y desarrollo profesional en el PMI Capítulo México. Puede ser contactado en [email protected]

30

NOV-DIC 2007

www.sg.com.mx

con precisión. Si no se tiene la opción de múltiples proyectos, este trabajo futuro puede dejarse a un nivel superior al límite. El riesgo, por supuesto, es que las estimaciones tendrán un margen de error mayor y se puede descubrir más adelante que el trabajo fue subestimado y que requiere que la fecha límite del proyecto y el presupuesto sean excedidos. Asimismo, la contingencia estimada puede ser incrementada considerando el aumento de incertidumbre asociado a este trabajo futuro. La segunda excepción se refiere a cuando una actividad es demasiado obvia como para dividirla. Una de las razones para detallar las actividades en piezas de trabajo más pequeñas es ganar claridad en cuanto a qué exactamente tiene que realizarse. Si la actividad es suficientemente obvia para el equipo al que fue asignada, entonces, quizás no sea necesario detallarla mucho más allá del límite o incluso puede ser dejada un nivel por arriba del límite de estimación. El PMBOK hace referencia a este fenómeno como planning package. Si el trabajo que está representado en la actividad no se conoce bien, entonces será necesario detallarlo aún más para ganar claridad. Por ejemplo: si una actividad estimada en 70 horas, nunca ha sido realizada con anterioridad, entonces, será necesario “romperla” en una serie de actividades menores con el fin de asegurar que las personas que estarán asignadas, sepan exactamente lo que se espera.

Límites de duración En general, la duración de las actividades debe ser detallada hasta un nivel que no sea mayor al ciclo de reportes del proyecto. Por ejemplo: Si se establece que el equipo debe entregar un reporte de estado del proyecto quincenalmente, entonces el límite de duración no debería ser mayor a dos semanas. Esta regla asegura que no habrá más de dos periodos de revisión del proyecto antes de que una actividad sea terminada o bien marcada como retrasada. Como ejemplo, si un equipo de trabajo se reúne con el Gerente del Proyecto cada semana para revisar el estado del proyecto, entonces la duración de ninguna actividad podrá ser mayor a una semana, de tal forma que ninguna actividad estará en ejecución por más de dos semanas antes de ser concluida. Por otra parte, si se tiene una actividad con 5 semanas de duración, entonces sería posible sostener hasta 6 juntas de revisión antes de saber con certeza si ésta se terminará a tiempo o no. Este ejemplo muestra porqué esa tarea debería ser descompuesta en dos y hasta tres niveles. Las actividades más pequeñas, permiten que los problemas emerjan y se descubran de forma oportuna, antes de que afecten seriamente el proyecto. Debe tomarse en cuenta que el límite de duración entra en juego hasta que la estructura de división de trabajo (EDT) ha sido definida y se han asignado recursos. Antes de esto, lo único que se conoce son las actividades y el estimado de horas de esfuerzo, pero como no se han asignado recursos, no puede conocerse la duración de las actividades.

www.sg.com.mx

NOV-DIC 2007

// PRÁCTICAS

/* PROGRAMACIÓN*/

Aprendiendo Ruby y Rails Parte 1. Introducción a Ruby Por Carlos Ortega El presente artículo es el primero de una serie que tiene la intención de introducir los principales elementos del lenguaje de programación Ruby y del framework Ruby on Rails. En esta primera parte se explican los elementos básicos del lenguaje, de forma que posteriormente se pueda comprender y explotar a Rails como plataforma arquitectónica de desarrollo.

Conceptos Básicos del Lenguaje

Antecedentes

Comentarios En Ruby hay dos formas de definir comentarios dentro del código.

Ruby es un lenguaje ROO (Radical Object Oriented Language) a diferencia de otros lenguajes con un perfil de objetos como C# y Java que son menos Orientados a Objetos en su sintáxis y semántica. Ruby fue creado en Japón por Matz (aka. Yukihiro Matsumoto) en 1995 y se empezó a utilizar en el hemisferio occidental a partir del año 2000. Es un lenguaje que desde sus inicios fue diseñado para ser simple, elegante, funcional, fácil de emplear, confortable y que brinde libertad al programador, y desde su diseño toma elementos de otros lenguajes tales como: Perl, Python, Java y SmallTalk. Entre las principales características de Ruby podemos citar: • Lenguaje de Scripting. • Radicalmente Orientado a Objetos. • De tipos dinámicos. • Funcional. • Altamente reflexivo. • Permite la creación de lenguajes de dominio específico. Debido a lo anterior Ruby: • Es fácil de escribir. • Típicamente es interpretado. • Favorece el desarrollo rápido sobre ejecución rápida (en gran medida debido a la facilidad que permita la utilización de tipos dínámicos). • Permite la integración e interface con componentes escritos en otros lenguajes. Uno puede encontrar intepretes de Ruby en prácticamente cualquier plataforma, siendo las más populares las derivadas de Linux en cualquiera de sus sabores: Fedora, RedHat, Ubuntu, Debian, etc. e incluso en MacOS X (Tiger) y Windows XP/2000.

32

NOV-DIC 2007

Como ya se había mencionado en un principo, Ruby es un lenguaje radicalmente Orientado a Objetos, esto es, su sintaxis y semántica presentan que en su mayoría todos los tipos son objetos, de hecho muchos operadores son métodos de los objetos. A continuación se explicarán los elementos principales.

La primera es cuando el comentario sólo abarca una línea o parte de una línea. Para este caso se utiliza el carácter de gato ( # ) y después se agrega el comentario. Por ejemplo: #--- Esto es un comentario que abarca toda una línea variable = objeto.metodo(parametro) # Este es otro comentario!!! # y este es otro mas!!!

La segunda es cuando el comentario abarca un bloque de líneas. Para este caso se utiliza el bloque =begin =end Por ejemplo:

... =begin Aún no se decide si Pedro tendra a su cargo 2 o 4 personas. El metodo podrìa invocarse de esta forma: objEmpleado.setSubordinados( “Emp23”, “Emp24”)



o de esta otra: objEmpleado.setSubordinados( “Emp23”, “Emp24”, “Emp32”, “Emp34” ) =end ...

En este ejemplo Ruby toma como comentarios todas las líneas que se encuentran situadas en medio del bloque =begin =end. NOTAS: • En este momento la versión actual del intérprete de Ruby (1.8.5) no permite hacer comentario embebidos. • Tanto =begin como =end deben de aparecer al inicio de linea.

www.sg.com.mx

“Las reglas que utiliza para definir el nombre de una clase son similares a la sintaxis de Java y C#”.

Clases La sintaxis para definir en Ruby una clase es similar a lo que pasa en C++, Java y C#: class NombreDeLaClase end

Igualmente las reglas que aplican para definir el nombre de una clase son similares a lo que acontece en Java y C#, cualquier sucesión alfanumérica con mayúsculas o minúsculas incluyendo el guión bajo, siempre que el nombre inicie con un carácter alfabético (no numérico).

de ser regresado mediante la cláusula return, o si ésta no es incoporada el método devolverá la última expresión evaluada. Constructores De igual manera que en C++, Java y C# Ruby tiene un método especial que permite la construcción de un objeto en tiempo de ejecución (constructor). Sin embargo a diferencia de otros lenguajes, en Ruby la sintaxis de constructor NO sigue las convenciones de nombrado del constructor. Esto es, no se llama igual que el nombre de la clase. La sintaxis es:

Métodos La sintáxis para definir en Ruby el método de una clase es:



def nombreDelMetodo( param1, param2, … paramN ) return( valor ) #--- Ojo! usar return es opcional end

initialize sigue el resto de las convenciones respecto a parámetros y valor de retorno que cualquier otro tipo de método.

Si el método pertenece a una clase este debe ser declarado dentro del cuerpo de la clase, por otra parte, las reglas que aplican para definir el nombre de un método son similares a lo que acontece en Java y C#, alfanumérica con mayúsculas o minúsculas incluyendo el guión bajo, siempre que el nombre inicie con un carácter alfabético (no numérico).

Variables de Instancia y Atributos En Ruby una variable de instancia es similar a lo que en C++, Java y UML se conoce como atributo y a lo que en C# se le denomina campo (field). Esto es es una propiedad o parte de la clase que puede representar un valor específico o un objeto completo.



def initialize( param1, param1, param3 ) end

Una variable de instancia se declara de la siguiente manera: Los parámetros son opcionales y se diferencian uno de otro mediante comas, cuando no se desea incluir ningun parámetro es opcional incorporar o no los paréntesis que rodean a los parámetros. Tres puntos importantes a remarcar respecto a los métodos: • A diferencia de lo que acontece en lenguajes como Java y C#, en Ruby un método puede o no ser parte de una clase. En este sentido, un método se puede comportar más como una función de C/C++ o JavaScript, ya que puede ser declarado en cualquier lugar del archivo o proyecto. • Los tipos de los parámetros no requieren ser declarados. Esto se debe a que Ruby es un lenguaje dinámico, el intérprete resuelve en tiempo de ejecución la relación correcta de los tipos que son pasados como parámetros a un método. • Los métodos siempre devuelven un valor por default, el valor pue-

www.sg.com.mx



@variableDeInstancia = valor

En Ruby, un atributo se refiere a un método que tiene el mismo nombre de una variable de instancia y que sirve para modificar el valor de dicha variable. Por ejemplo, supongamos que tenemos el siguiente código:

class CEmpleado #... def sueldo( sueldoAsignado ) @sueldo = sueldoAsignado end end

NOV-DIC 2007

33

// PRÁCTICAS

/* PROGRAMACIÓN*/

“Los métodos pueden o no ser parte de una clase y ser declarados en cualquier lugar del archivo o proyecto”.

Aquí el método sueldo coincide con la varible de instancia @sueldo, y además estamos empleando este método para asignarle un valor específico a la variable de instancia. Esta construcción nos permitirá hacer realizar declaraciones como la siguiente:

objEmpleado.sueldo( 100000 )

Una vez entendido el concepto de atributo, comparémoslo con el concepto de atributo en C#, en el cual un atributo es un tipo de anotaciones de código (metadatos) que puede ser aplicado a un tipo (clase, interface, estructura, etc.), miembro (propiedad, método, etc.), assembly o módulo… Ambos conceptos son bastante diferentes ¿verdad? Es por eso que debemos poner atención cuando nos referimos a atributos en Ruby. Idiomas comunes Analicemos el siguiente código para una clase que represente a un usuario.

class CUsuario



attr_accessor :nombre, :password, :permisos attr_accessor :IDUsuario



def initialize( nombre, password, permisos ) @nombre = nombre @password = password @permisos = permisos end def nombre=( nombre ) @nombre = nombre return( true ) end



def password=( password ) @password = password return( true ) end



def permisos=( permisos ) @permisos = permisos return( true ) end



end



34

NOV-DIC 2007

Si se dan cuenta, en este caso no declaramos atributos. En lugar de eso empleamos el idioma común attr_accessor que en conjunción con los símbolos :nombre, :password, :permisos y los atributos nombre=, password=, permisos= permitirán lograr el mismo efecto y obtener mayores beneficios. Veamos con más calma a que nos referimos con todo esto. Empecemos con el elemento attr_accesor, el cual a todas luces pareciera ser un keyword. En realidad este elemento es lo que se conoce como un idioma común en Ruby. Un idioma común es cuando existen construcciones que se repiten continuamente durante el desarrollo de programas. Cuando esto pasa, los equipos de mantenimiento de compiladores, intérpretes, frameworks y librerías de uso común de los lenguajes generan estructuras o elementos que declarativamente son “atajos” y que tienen la intensión de reducir la cantidad de código y/o hacerlos más legibles. En el caso de Ruby el equipo de mantenimiento de las librerías se percató de esta situación y creó una serie de idiomas que reducen la cantidad de código a escribir (aún cuando en realidad en tiempo de ejecución estos idiomas se desglosan en otras estructuras o declaraciones más grandes o complejas). Los siguientes son los idiomas más comúnes para los atributos en Ruby:

attr_reader :metodo attr_writer :metodo



#--- solo lectura #--- solo escritura



attr_accessor :metodo



#--- lectura y escritura

Para comprender mejor como funcionan estos idiomas mostraremos un ejemplo. Supongamos que declaramos

attr_accessor :direccion

Este idioma tiene el mismo efecto que si declararamos



def direccion @direccion end def direccion=( direccion ) @direccion = direccion end

www.sg.com.mx

En este caso, el primer método sirve como un “getter” de la variable de instancia. Es decir, permite colocar a la variable como un RValue a través de una sentencia como:

unaDireccion = objeto1.direccion

El segundo método sirve como un “setter” de la variable de instancia. Es decir, permite colocar a la variable como un LValue dentro de una sentencia: #...

#... Objeto1.direccion = otraDireccion # O Objeto1.direccion = objeto2.otraDireccion

A este último tipo de método se le conoce como atributo escribible (Writable Attribute) porque permite “escribir” el valor de una variable de instancia utilizando un método del tipo atributo. Antes de finalizar con esta sección es importante remarcar que cuando utilizamos este tipo de idiomas comunes debemos incorporar también el nombre del método que tratamos de definir como getter o setter (y que además coincide con el nombre de la variable de instancia). En nuestro caso, dichos métodos fueron: :nombre, :password, :permisos y :IDUsuario. La razón por la que llevan dos puntos se explica a continuación. Symbols Cuando utilizamos los 2 puntos antes de un identificador ( : ), en realidad lo que estamos definiendo es un alias para identificar cosas. Este tipo de alias se le conoce como símbolo (o Symbol en Inglés) y es muy utilizado en Ruby y Rails para identificar o nombrar a otros elementos. Algunos ejemplos son:

#--- nombrado de relaciones has_many :clientes



#--- identificar parametros nombrados Cliente.find( :all )



#--- como parametros keyword Cliente.find( :all, :limit =>5, :order=>”nombre” )

Herencia En Ruby al igual que en otros lenguajes como C++, Java y C# es posible definir relaciones de generalización (o especialización según el punto de vista) en donde una clase puede tener una o más hijas y así conformar toda una jerarquía.

www.sg.com.mx

NOV-DIC 2007

// PRÁCTICAS

/* PROGRAMACIÓN */

“Los idiomas comunes definen construcciones que se repiten frecuentemente durante el desarrollo de programas”.

La sintaxis para declarar que una clase deriva (hereda) de otra es: class NombreClaseHija < NombreClasePadre

#... end

Por ejemplo, si queremos crear una clase para representar aun administrador de sistema, la cual herede de nuestra clase de usuario, lo haríamos con código como el siguiente:



class CAdminSistema < CUsuario def initialize(nombre, password, permisos ) super( nombre, password, permisos ) end def cambiaPermisos( permisos ) super.permisos=permisos end end

Podemos apreciar que dentro del código se tiene la declaración:

super( nombre, password, permisos )

super es una palabra reservada que invoca al método asociado en la clase padre. En nuestro caso, como super estaba incorporada dentro del método initialize, en realidad adentro de éste se está invocando al método initialize de la clase padre (CUsuario.initialize).

En los artículos subsecuentes abarcaremos más elementos del lenguaje como arreglos, hashes y bloques que permitirán apreciar la potencia, facilidad y elegancia de Ruby. Iniciamos con el análisis de estos elementos porque consideramos fundamental que para comprender de manera general la arquitectura de Rails y poder emplearlo como framework de desarrollo, se necesita partir de una base. En las siguientes entregas, ejemplificaremos el uso del lenguaje a través de un caso práctico e iniciaremos con el uso de Rails. Mientras tanto, los invito a que visiten www.ruby-lang.org y descarguen el interprete de Ruby para que puedan empezar a realizar algunos ejercicios con este fascinante lenguaje.

Referencias • Thomas David, Fowler Chad, Hunt Andy. “Programming Ruby”. 2nd Edition. The Pragmatic Bookshelf, 2005. • Thomas David, Heinemeier Hanson David , et al. “Agile Web Development with Rails”. 2nd Edition. The Pragmatic Bookshelf, 2006. Black, David A. “Ruby for Rails”. Manning Publications Co., 2006 • Troelsen, Andrew. “Pro C# 2005 and the .NET 2.0 Platform” 3rd Edtion. Apress, 2005. • Lucas Carlson, Leonard Richardson. “Ruby Cookbook”. O’Reilly Media, 2006. • www.ruby-lang.org • www.rubyonrails.org



Resumen A lo largo de este tutorial iniciamos la revisión de diferentes características de Ruby y las herramientas básicas para iniciar la programación con el lenguaje, así mismo analizamos brevemente algunas particularidades que lo hace diferente respecto a otros lenguajes como C++, Java y C#.

Carlos Ortega es consultor en metodologías y prácticas ágiles (XP, TDD, Refactoring, Pair Programming, etc.), cuenta con certificaciones en RUP, OOAD, UML, etc. Es Certified ATAM Evaluator y Certified Professional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como Banco de Mexico, Elektra, Banco Azteca, Fandelli, Oracle, IMSS, Heinson, Accenture, EDS, etc. Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Crystal, etc.)

36

NOV-DIC 2007

www.sg.com.mx

// UML

Los nuevos diagramas: de tiempo y de estructura compUESTA UML en el Modelado de Sistemas de Tiempo Real Por Charlie Macías y Sergio Orozco

Antecedentes La puntualidad (timeliness) es el común denominador en los sistemas de tiempo real. La puntualidad es la capacidad que tiene un sistema de responder de la manera esperada a los estímulos externos dentro de un intervalo de tiempo aceptable. Esto es, si un sistema contra incendios detecta que hay una temperatura por encima del umbral debe activar tanto la alarma como los aspersores a fin de evitar que el conato de incendio se propague y debe hacerlo con oportunidad, quizá el retraso podría tener efectos devastadores. Esta característica abarca un sin número de sistemas de tiempo real, desde los puramente dirigidos por el tiempo hasta los puramente dirigidos por los eventos, desde los sistemas de tiempo real “suave” hasta los sistemas de tiempo real “duro”. Por años, estos sistemas emplearon para su desarrollo sus propios lenguajes, patrones de diseño y estilos de modelado, pero también tenían en común el uso de una herramienta para su modelado ROOM. ROOM es acrónimo de Real-Time Object Oriented Modeling y es una notación de propósito específico para el modelado de los sistemas en tiempo real. Una las grandes virtudes de ROOM radica en la definición de una serie de construcciones arquitectónicas que recaban la experiencia colectiva de varios equipos de desarrollo en varios proyectos y que contiene las bases del diseño arquitectónico para este tipo de sistemas. En 1998, Bran Selic y Jim Rumbaugh llevaron a cabo una investigación para determinar la viabilidad de modelar Sistemas de Tiempo Real usando una notación de propósito ge-

neral: UML. En esta investigación se enfocaron en los Sistemas en Tiempo Real que se caracterizan por ser complejos, dirigidos por eventos y potencialmente distribuidos. Este tipo de sistemas son los empleados comúnmente en aplicaciones de telecomunicaciones, aplicaciones aeroespaciales y aplicaciones de control automático. Los proyectos para desarrollar el software asociado a los mismos demandan un gran esfuerzo inicial e involucran a grandes equipos de desarrollo y, al igual que la mayoría de los proyectos, deben adaptarse ágilmente a los inevitables cambios. Con lo anterior quiero resaltar que la definición de una arquitectura bien diseñada es un factor determinante de éxito, como en todo. Los resultados de la investigación, en pocas palabras, arrojó que las construcciones definidas por ROOM podrían modelarse en UML usando simplemente sus mecanismos de extensión estándar. La investigación mencionada en el párrafo anterior define tres construcciones para el modelado de estructura: Las cápsulas, los puertos y los conectores. Las cápsulas y los puertos no son otra cosa que clases con el estereotipo de “capsule” y “port” respectivamente a los cuales se les asocian una serie de restricciones y características adicionales. Estas construcciones empleaban principalmente para su modelado diagramas de clases y diagramas de colaboración. Así mismo, la extensión para el modelado de sistemas en tiempo real definieron tres construcciones para el modelado del com-

portamiento: El protocolo, las máquinas de estados y los servicios de tiempo.

La Evolución Con la especificación de UML 2.X se incorporaron dos nuevos diagramas que son la nueva alternativa para el modelado de los sistemas de tiempo real, nos referimos a los Diagramas de Estructura Compuesta y los Diagramas de Tiempo. En los Diagramas de Estructura Compuesta las cápsulas se generalizaron en las partes mientras que los puertos y los conectores conservaron su nombre. La debilidad de UML 1.x en un enfoque fuerte en el tiempo derivó en la incorporación de los Diagramas de Tiempo en UML 2.x. La Figura 1 muestra un diagrama de estructura compuesta para un sistema contra incendios. UnidadCentralControl, Sirena, Aspersor y MonitorTemperatura son partes; los cuadros pequeños son los puertos y las líneas que los unen son los conectores. SistemaContraIncendio

UnidadCentralControl

MonitorTemperatura

Sirena

Aspersor

SensorTemperatura SensorTemperatura

Figura 1. Diagrama de estructura compuesta.

En la Figura 2 se muestra un Diagrama de Tiempo que relaciona los elementos que conforman al sistema contra incendio haciendo énfasis en sus cambios de estado en el tiempo.

Sergio Orozco es Director General e Instructor Senior, Charlie Macías es Consultor Senior e Instructor Senior, ambos especializados en temas relacionados con UML en Milestone Consulting. Milestone Consulting (UML Value Added Training Center), es una empresa especializada en capacitación práctica-intensiva y consultoría en UML, BPMN y PM. Milestone Consulting es la primer empresa mexicana miembro de la OMG, además de ser REP del PMI. [email protected] www.milestone.com.mx

38

NOV-DIC 2007

www.sg.com.mx

MonitorFuego

Sirena

Aspersor

Conclusión

fuego detectado {2} fuegoDetectado {2}

Activ o Inactiv o

Sonando

sonarAlarma

Inactiv a

combatirIncendio combatirIncendio

Activ o Inactiv o 0

10

20

30

40

Figura 2. Diagrama de Tiempo

50

60

70

80

90 100

Al utilizar UML para el modelado de sistemas en tiempo real, recomendamos: • Capturar y entender los requerimientos usando un modelo de casos de uso. • Estudiar las distintas partes que conforman al sistema y cómo interactúan, reflejando las interfaces, protocolos e intercambio de señales; apoyándonos de los diagramas de clases, estructura compuesta y comunicación.

• Estudiar el comportamiento del sistema en el tiempo y el dependiente del estado usando diagramas de interacción, diagramas de transición de estados y diagramas de tiempo. Por supuesto esta no es una relación exhaustiva, en caso de ser necesario adicione (o elimine) los diagramas que sean necesarios, lo importante es tener una comprensión aceptable del problema y especificar una solución que lo resuelva.

// REFLEXIONES

Confesiones de un Pésimo Programador Lecciones de los maestros Zen Por Marc A. Criley

Soy un pésimo programador. Cualquiera pensaría que después de 25 años haciendo esto, ya debería ser bueno. Sin embargo, todavía meto bugs en el código, uso tipos de datos incorrectos en mis variables y argumentos de funciones, olvido invocar las librerías adecuadas, pongo al revés la expresión lógica de una sentencia if, y muchos errores más que sigo cometiendo. A veces el código no compila, indicando mis errores, y eso me permite arreglarlos rápidamente. Pero el resto de las ocasiones, tengo que ejecutar el programa para darme cuenta de las fallas. Cuando tengo suerte, el programa arranca y luego truena arrojando mensajes de error a placer, los cuales puedo utilizar para rastrear que es lo que hice mal. Cuando no tengo tanta suerte, el programa arranca y termina inmediatamente sin ninguna indicación, o se queda perdido en el limbo. Peor aun es cuando un programa arranca y parece funcionar bien, pero después de un tiempo de uso empiezan sutilmente a aparecer las fallas. Por supuesto que también están las fallas que se manifiestan solamente cuando cierta secuencia especial de eventos se lleva a cabo (dicha secuencia podría originarse de forma externa) bajo condiciones específicas. Lo curioso con los programas que desarrollo es que una vez que los entrego, típicamente funcionan bien. Acostumbro entregar sistemas a tiempo, con la funcionalidad esperada, y muy pocos errores. Esto es un logro sorprendente para un pésimo programador.

Prácticas de un pésimo programador ¿Así que cual es mi secreto? Bueno, lo que sucede es que recurro a uno de los secretos Zen de los grandes maestros del software, el cual dice que:

“Para convertirte en un gran programador, debes estar conciente de que siempre serás un pésimo programador”. Tal y como pueden ver en la primera oración de este artículo, yo completamente acepto esto. Pero dado que me fascina programar, y también vivo de ello, entonces tengo que lidiar con esta situación y sacarle el mejor provecho posible. Afortunadamente existen diversas prácticas y técnicas que utilizo para esconder lo malo que soy programando. Aquí comparto algunas de ellas: 1. Elige un lenguaje restrictivo. Cuando puedo escoger el lenguaje a utilizar para un programa en particular, mi elección es hacerlo en Ada. Si, yo sé que en la era moderna este es un lenguaje prácticamente desconocido. Sin embargo, pocos lenguajes son comparables con Ada a la hora de mostrar lo mal programador que soy. Con todas las restricciones para compilación y revisiones en tiempo de ejecución, es fácil entender porque a la mayoría de los programadores no les gusta Ada, ya que constantemente está indicando errores en el código. Cuando no puedo usar Ada, entonces mi siguiente opción es Java, dado que incluye muchas de esas capacidades para detección de bugs. El lenguaje que busco evitar a toda costa es C++, el cual deja pasar los errores para que el código compile, pero luego requiere de largas sesiones de depuración para hacer que funcione bien. 2. Utiliza afirmaciones (assertions). Utiliza afirmaciones en cada oportunidad que tengas. En mi caso, soy paranoico con esto. Si alguna variable nunca debería ser nula, y aunque Grady Booch jure sobre una pila de estándares UML que nunca lo será,

de todos modos pongo una afirmación para verificarlo. Aun cuando tengo el control sobre los diferentes lados de una interfaz de comunicación, establezco afirmaciones para verificar la validez de lo que el proveedor está enviando y lo que el receptor está recibiendo. ¿Por qué hago esto? Porque parte de los errores que cometo al ser un pésimo programador, es llegar a cambiar un lado de la interfaz sin hacer el cambio correspondiente del otro lado, así que las afirmaciones me ayudan a atrapar esos casos. 3. Sé un masoquista de las pruebas. Se despiadado con tu código y trata de hacerlo tronar a toda costa. Los programadores normalmente quedamos satisfechos con que un programa funcione correctamente con los datos del caso de pruebas que tenemos. Para qué buscar problemas, ¿cierto? Es difícil desarrollar esa mentalidad de intencionalmente hacer fallar tu propio código, pero si tú no lo haces, alguien más lo hará, y entonces tu identidad secreta como pésimo programador será revelada. 4. Haz que otros programadores inspeccionen tu código. A pesar de todo lo que hago, siempre quedan bugs en mi código. Así que necesito la ayuda de otros programadores para revisar mi código y encontrarlos. No me refiero a que alguien le eche una ojeada a mi código y vea que librerías estoy utilizando, ¡quiero una inspección real y despiadada! Alguna vez tuve que llamarle la atención a un inspector porque me estaba “haciendo un favor” al no registrar todos los defectos que encontró, porque no quería hacerme sentir mal. Mi vida no gira alrededor de si tengo o no errores en mi código, no es algo por lo que me voy a suicidar. Se que soy un pésimo programador, y por lo tanto para gene-

Marc A. Criley es miembro Senior del staff técnico en Cohesión Force Inc, en Huntsville, Alabama. A lo largo de su carrera ha colaborado como programador, diseñador y arquitecto en el desarrollo de sistemas de comando y control, análisis de datos y simulación. Marc espera poder conservar su trabajo a pesar de haber revelado el gran error que cometieron al contratarlo.

40

NOV-DIC 2007

www.sg.com.mx

rar buen código necesito toda la ayuda que pueda obtener. Con estas y otras técnicas neutralizadoras de pésima programación, mi código comúnmente parece como si hubiera sido escrito por un buen programador, lo cual me ha permitido desarrollar software profesionalmente para sistemas de misión crítica para la industria aero-espacial.

Manteniéndose como un pésimo programador Hasta ahora he logrado esconder lo mal programador que soy, pero necesito asegurarme de que puedo continuar en este camino, por lo menos hasta mi retiro. Así que haciendo caso a la gran sabiduría de Han Solo cuando le decía a Luke que no empezara de presumido, llegamos al segundo consejo Zen de los maestros del software: “Te mantendrás como un gran programador siempre y cuando no se te olvide que todavía eres un pésimo programador”.

intento. El gerente del proyecto se dio cuenta de la gran cantidad de fallas de sistema que teníamos durante las pruebas, y quería saber porqué el sistema rediseñado tronaba mucho más que el original. La explicación de que estábamos destapando los errores para arreglarlos en el momento no lo dejó del todo satisfecho, ya que había que cumplir con las fechas de entrega, y la taza de errores no estaba bajando tan rápido como a él le hubiera gustado. Sin embargo, nos aferramos a esta práctica, y cuando terminamos (en tiempo y presupuesto), el sistema funcionaba de forma correcta y confiable. Esta experiencia afianzó mi imagen como pésimo programador. Si mediante técnicas para descubrir mis fallas antes de que llegaran al producto final logré que este proyecto fuera exitoso, entonces me convencí de que podría seguir engañando al mundo por el resto de mi carrera.

Conclusión

En mi caso, a lo largo de los años he aprendido nuevas formas de esconder mis fallas. Una técnica muy valiosa es simplemente dejar que el programa truene. Veamos a que me refiero con esto. Hace un tiempo formé parte de un proyecto de software donde los desarrolladores originales habían tenido tantos problemas con excepciones de runtime que simplemente empezaron a introducir en el código manejadores de excepciones nulos (es decir, atrapar todas las excepciones no esperadas, suprimirlas y continuar como si nada). Es así que el sistema funcionaba aparentemente bien por un tiempo, pero después de algunas horas de uso empezaba a tener ciertas “discrepancias” por llamarlas así.

Si echas un vistazo a mi código, muy probablemente opines que es bastante malo. Eso es normal, prácticamente cualquier programador que revisa el código de otro programador piensa que es una porquería, y proclama que la única forma de arreglarlo es rehaciéndolo por completo. No me explico a que se deba esto, pero así sucede.

Cuando tuve oportunidad de rediseñar el sistema, mi primera petición fue eliminar los manejadores de excepciones nulos. Si una excepción no esperada ocurría, quería que se propagara hasta que tumbara la aplicación, de tal forma que la conociéramos y arregláramos en ese momento. Obtuve mi deseo, pero estuve cerca de perecer en el

La version original de este artículo está publicada como parte del blog de Marc Criley en http://kickin-the-darkness. blogspot.com/2007/09/confessions-ofterrible-programmer.html. Fue traducido al español por el staff de SG, y publicado con el permiso del autor.

www.sg.com.mx

Pero si estás dispuesto a tomarte el tiempo de revisar el código conmigo y decirme lo que está mal, entonces creo que podremos trabajar juntos para mejorarlo y entonces convertirlo en código grandioso. Y entonces posiblemente lleguemos a ser buenos programadores.

NOV-DIC 2007

// COLUMNA

// TIERRA LIBRE

SOA para Humanos

De la competencia a la cooperación

Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones. Ferviente entusiasta de la aplicación social de la tecnología, a últimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estará encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en [email protected]

L

as Arquitecturas Orientadas a Servicios y los proveedores con productos casi mágicos para implementarlas, proponen un nuevo paradigma para agilizar la automatización de procesos de negocio. Sin embargo, existe una letra chiquita en estas promesas que normalmente los proveedores de soluciones no hacemos énfasis hasta después de recibir la orden de compra: Implementar SOA en una organización requiere de un cambio cultural profundo y radical. Hasta la fecha, no he visto una “suite integrada” de soluciones SOA que provea una solución mágica a este problema, no hay una licencia de software que resuelva el problema de SOA para los humanos. Las organizaciones deben tener claro que SOA implica antes que nada un cambio organizacional, requiriendo una estrategia centrada en las personas antes que en la infraestructura. A continuación comparto cinco estrategias que pueden ayudarles a asegurar que su organización contemple el factor humano en su adopción de SOA y aumentar las probabilidades de éxito: 1.- Liderazgo y Consenso: El lider de una estrategia de SOA requiere de poder crear un ambiente donde las decisiones se toman por consenso. La única manera de que una organización cambie es que todos sean escuchados, sus preocupaciones sean atendidas y se logren acuerdos donde nadie salga perdiendo. El mayor reto de SOA es pasar de una organización competitiva a una organización cooperativa. El establecer métricas que promuevan la cooperación y no la competencia entre áreas, el reconocimiento a la labor de equipo y un sistema efectivo de toma decisiones consensuado es un primer paso ineludible hacia SOA. 2.- Establecer un Lenguaje Común: El concepto de SOA no tiene estandares, cada proveedor da su versión particular de SOA en el cual mágicamente su producto cumple con todas las expectativas. Esto es increiblemente dañino para

42

NOV-DIC 2007

una organización, ya que dentro de la misma empresa, dependiendo del proveedor favorito de cada grupo de sistemas, se entenderá SOA como cosas fundamentalmente distintas. Antes de iniciar un proyecto de adopción de SOA debemos definir y divulgar lo que significa SOA para nuestra organización, y los beneficios particulares que buscamos. Lograr que todos hablen el mismo idioma es indispensable para una toma de decisiones en consenso. 3.- Diseñar nuestra propia receta: No existen recetas secretas para SOA. Cada organización tiene retos de negocio, cultura e historia distintas. Se tiene que aceptar que ningun proveedor va a poder darle un SOA “llave en mano” por que no hay otra organización igual a la suya en este sentido. La metodologia de Factores Criticos de Exito (Rockart) está más vigente que nunca al ser una estrategia basada en consenso y en la recopilación de la inteligencia colectiva para planear de forma adecuada. El definir a traves de una sesión formal de factores criticos de éxito, que contemple contextos humanos, organizacionales, tecnológicos, y administrativos es una buena manera de garantizar que se cubren todos los aspectos de una estrategia de cambio hacia SOA. 4.- El negocio antes que la arquitectura: El principal motivo de fracaso en los proyectos de TI es muy claro: el beneficio esperado por el negocio nunca llega. Más que centrarnos en si contamos con una arquitectura con todas las “capacidades”, debemos de centrarnos en un enfoque donde primero entregamos el resultado que las personas de negocio esperan y después nos preocupamos por la arquitectura técnica. Sé que va en contra de todo lo que los “profesionales” de sistemas les decimos, pero la realidad es que si entregamos primero el resultado de negocio sera mas fácil que nos den tiempo y dinero para hacer la arquitectura soñada. En SOA esto quiere decir, primero analizamos los procesos más importantes para el negocio y hacemos lo mínimo indispensable para entregar mejoras en ellos. Nada más.

5 .- La disciplina en el diseño: Existe una multitud de “conectores” y “componentes” que prometen facilitar todo. Sin embargo SOA es antes que nada una disciplina de diseño. Como toda disciplina son los humanos quienes la practican, no el producto de software. Un buen equipo de SOA entiende a todos los niveles que preservar el estilo de diseño es indispensable para obtener los beneficios. Se acabaron los “hacks” y mejoras propietarias. Todo diseño debe de obedecer los principios de diseño de SOA, los arquitectos y desarrolladores deben de practicar esta disciplina. Un comite guía puede ser de gran ayuda para asegurar que esta disciplina se aprenda y se regule. 6.- El valor de aprender: La cultura de hacerlo bien y a la primera no aplica enteramente para SOA. Somos humanos, estamos aprendiendo globalmente como cambiar hacia SOA. Habrá cosas que nos pareceran buena idea en un principio y con el paso del tiempo mostrarán que no lo son. Debemos estar abiertos a rediseñar o refactorizar. Es mejor aceptar de antemano que tendremos que variar el diseño y trabajemos de acuerdo a esto. Con SOA necesitamos iterar y protegernos de los cambios, pero más que nada necesitamos promover la experimentación y el consenso. Nada peor para paralizar SOA que desarrolladores temerosos a “exponerse” con sus compañeros porque no se imaginaron todo bien a la primera. SOA fue pensado para el cambio, aprovechémoslo. Al final, lo que es indispensable considerar en la implementación de SOA en una organización es cómo lograr el cambio que se requiere para que los beneficios de esta arquitectura den resultado y no nos vaya a pasar que dentro de 10 años tengamos que cambiar a otra bala de plata, porque simplemente hicimos lo mismo que toda la vida, pero ahora con estandares de SOA. Buena suerte. —Emilio Osorio www.sg.com.mx

www.sg.com.mx

NOV-DIC 2007

// COLUMNA

/*TENDENCIAS EN SW*/

Software más Servicios Comprendiendo el nuevo paradigma

Luis Daniel Soto es director regional de desarrolladores y difusión de plataforma en Microsoft para América Latina. Es miembro de la orden nacional al mérito de México (ministro de educación). Luis Daniel obtuvo el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn.com/luisdans

U

sted se estaciona en una zona con parquímetros obligatorios. Con la infraestructura de una ciudad moderna es posible efectuar el pago no solo con monedas sino con tarjeta. Un “servicio” puede cambiar la experiencia positiva del cliente aun más: Imagine que demora más de lo esperado y recibe una llamada en su celular ofreciendo extender el tiempo de uso del estacionamiento. Esto puede ser un ejemplo de la nueva experiencia esperada.

El “software” es bien entendido, excepto que la mayoría del software actual no fue diseñado para que instantáneamente se pueda enviar al exterior, a ser ofrecido como un “servicio”.

33% de las empresas utilizará también este modelo. Desde luego con reglas muy claras, tales como: • Primariamente escenarios de auto-servicio. • Escenarios donde la interactividad y experiencia visual son relevantes. • Publicidad “no disruptiva”. • Publicidad basada en roles y contexto.

Bumeran.com es un tercer ejemplo: De nacer como un sitio de búsqueda de empleos en Internet, han evolucionado para ahora también ofrecer “en sitio” un sistema de recursos humanos, o el mismo administrado por ellos. Es de nuevo, la evolución inminente a “software más servicios”. Extendiendo su negocio para ofrecer mejores formas de apoyar a sus clientes.

El “servicio” debe ser definido más claramente ya que no solo representa aplicaciones. De hecho, podríamos considerar al menos tres tipos: • Bloque de construcción. Se refiere a los servicios o capacidades hospedados remotamente, que los desarrolladores pueden aprovechar para utilizar en una aplicación que desarrollan. Ejemplos comunes pueden ser servicios de almacenamiento (Silverlight Streaming), gestión de identidad corporativa (Biztalk Identity Services), o mapas (MSN Virtual Earth y Google Earth). • Servicio complementario. Enriquecen la funcionalidad de un producto. Por ejemplo, las consolas de videojuegos modernas pueden utilizarse no solo para jugar, sino que proveen servicios adicionales para interactuar con el mundo real. • Servicio terminado. Se refiere a ofrecer el beneficio de uso sin la complejidad de administración. Pueden ser operadas por una empresa de telecomunicaciones, un socio, un tercero calificado o el proveedor mismo. En el caso de Microsoft, sus ofertas “Live” requieren mínimo apoyo técnico para ofrecer funcionalidad. Otro ejemplo claro en la industria sería el mismo salesforce.com

El nuevo paradigma

Publicidad llegando a la empresa

Referencias :

Hoy existen 4 mundos informáticos aislados: el escritorio en hogares y casas; el mundo en línea de Internet; el de cómputo empresarial y el de dispositivos electrónicos (Fig 1.). La visión “software más servicios” representa una posibilidad final de convergencia de los mismos.

El nuevo paradigma incluye muchos temas adicionales, como la capacidad de pago tradicional, pago por uso, pago transaccional o pago realizado por patrocinador. Es claro que este último ya se demostró (Google). Los estudios recientes de McKinsey & Co. y Sand Hill Group muestran que en 2 años,

• partner.microsoft.com/global/40044076 • msdn2.microsoft.com/en-us/ architecture/aa699384.aspx • www.informationweek.com/news/ showArticle.jhtml?articleID=199204001

En el ámbito empresarial, mucho se escribió sobre salesforce.com; un sistema que elimina la necesidad de cualquier infraestructura de cómputo y en línea da las herramientas de fuerza de ventas que los corporativos utilizan. Esta empresa originalmente “pura” de servicios, descubrió que la demanda real es de “software más servicios” y calladamente liberó una pieza “fuera de línea” que permite actualizar los registros en ocasiones tales como durante un vuelo aéreo.

44

NOV-DIC 2007

Beneficios Más adelante en esta columna compartiré más sobre los beneficios del modelo “software más servicios”, el cual tiene una propuesta clara de valor real para consumidores, profesionales de informática, y tomadores de decisión. Finalmente significa la transformación de T.I. en una nueva era. Sea pionero de este nuevo ecosistema.

Figura 1. Cuatro mundos informáticos aislados

—Luis Daniel Soto

www.sg.com.mx

www.sg.com.mx

NOV-DIC 2007

// FUNDAMENTOS

Assertions. (Afirmaciones) Un primer acercamiento Por Sonia Sánchez

El concepto de afirmaciones (assertions) se atribuye a aquellas sentencias booleanas colocadas en un punto específico de un programa, las cuales serán verdaderas hasta que se demuestre lo contrario. Este tipo de sentencias se utilizan como ayuda en las correcciones de un programa. Por ejemplo: • Una precondición: es una afirmación colocada al inicio de una sección de código, determinando el conjunto de sentencias bajo las cuáles se espera que el código sea ejecutado. private void setRefreshInterval(int interval) { // Confirma la precondición en un método no público. assert interval > 0 && interval <= 1000/MAX_REFRESH_RATE : interval; ... // Define interval }

• Una postcondición se coloca al final, describiendo la sentencia esperada al final de la ejecución.

case Carta.DIAMANTES: ... break; case Carta.CORAZONES: ... break; case Carta.ESPADAS: ... }

Esto probablemente indica una afirmación que la variable “carta” tendrá uno de los cuatro valores definidos. Para probar esta afirmación se debe agregar el siguiente caso tipo default: default: assert false : carta;

Si la variable carta adquiere otro valor y las afirmaciones están definidas, la afirmación fallará y un AssertionError será generado. Una alternativa aceptable es:

public BigInteger modInverse(BigInteger m) { if (m.signum <= 0) throw new ArithmeticException(“Negativos: “ + m);

default: throw new AssertionError(carta);

... // Se realizan los cálculos

Esta opción ofrece protección aún si las afirmaciones no están definidas, de esta manera la sentencia throw no se ejecutará hasta que el programa halla fallado.

assert this.multiply(result).mod(m).equals(ONE) : this; return result; }

Manejo de afirmaciones fallidas.

Algunos lenguajes de programación modernos incluyen sentencias de tipo “assertions”, que son analizadas en tiempo de ejecución. Lenguajes de programación tales como Java, utilizan este concepto. Así, la declaración de una afirmación sería: assert Expression i;

Dónde Expression i es una expresión booleana.

Si una afirmación falla, el primer paso es comunicarle al usuario que existe una falla, este aviso puede ser a través de mostrar un mensaje de error en la terminal o guardarlo en un archivo de log. Una vez que la falla se ha analizado y el mensaje de error ha sido desplegado, existen diferentes alternativas: • Terminar el programa. • Permitir su ejecución. • Seguir una excepción para regresar a la ruta de código que tiene el error.

Un candidato para su uso es un bloque tipo switch sin la definición de un tipo default. La ausencia de este caso, indica que un programador asume que uno de los casos siempre será ejecutado. Suponiendo que un ciclo case está definido de la siguiente manera:

Esto intenta ser más fácil de depurar que un mensaje de error o un comportamiento de falla que podría resultar si la afirmación fuera falsa y sin revisión.

switch(carta) { case Carta.TRÉBOLES: ... break;

El rol de las afirmaciones es identificar errores en un programa. Idealmente, a través de las realización de pruebas de un programa, se encontrarían sus errores aún sin el agregado de las afirmaciones.

46

NOV-DIC 2007

Beneficios de las afirmaciones.

www.sg.com.mx

En la práctica, el mayor beneficio de este concepto es hacer pruebas más efectivas. Esto es un punto importante. Una afirmación que nunca se ejecuta no dice nada. Una afirmación es solamente útil si el código es ejecutado. Asumiendo que el código está siendo propiamente probado, las afirmaciones tienen varios utilidades: • Detectar errores que posiblemente en otras condiciones no serían visibles. • Detectar errores más rápido después de que han ocurrido. • Crear una sentencia acerca de los efectos del código que está garantizado para ser verdadero.

Diferencia entre afirmaciones y manejo de errores rutinarios Debemos aclarar que las afirmaciones se distinguen del manejo de errores rutinario. Las afirmaciones deben utilizarse para documentar situaciones lógicamente imposibles, de tal forma que cuando se disparen es porque se ha descubierto un error de programación. Es decir, si lo imposible ocurre es porque hay algo fundamental que está mal, ¿cierto? Esto es distinto al manejo de errores tradicional, ya que la mayoría de las condiciones de error son posibles, y por eso contemplamos que puedan suceder y nos preparamos para manejarlas adecuadamente, sin necesidad de detener la ejecución del programa (cosa que sucede al encontrar una afirmación fallida).

Limitaciones de las afirmaciones. Como cualquier otro código, las afirmaciones están sujetas a tener errores. Un error en una afirmación puede provocar que ésta reporte un error en donde no existe tal. Esto no es tan grave ya que al analizar el error, el desarrollador puede facilmente darse cuenta que en realidad el programa está funcionando correctamente y la afirmación es la que está mal definida.

www.sg.com.mx

Otro problema ocasionado por una mala definición de una afirmación es que no logre detectar las condiciones que se supone que debería atrapar. Es por esto que al igual que cualquier otro elemento de código, también deberíamos probar las afirmaciones para asegurarnos de que funcionan como esperamos. Otro inconveniente con el uso de afirmaciones es que pueden llegar a afectar el desempeño de un programa debido al procesamiento adicional que requieren. Esto no es de gran importancia en ambientes de desarrollo, pero definitivamente en ambientes de producción debemos tenerlo en cuenta. Lo que se hace para evitar esto es que las afirmaciones normalmente se eliminan del código que va a ser utilizado en producción. Para facilitar esto y deshabilitar las afirmaciones sin necesidad de modificar el código, la mayoría de los lenguajes modernos soporta la habilitación o deshabilitación de afirmaciones en tiempo de ejecución a través del uso de banderas al momento de invocar un programa. Cuando una afirmación falla debido a que encuentra un error, la ejecución del programa se detiene por completo. Esto es útil porque las fallas detectadas por afirmaciones son condiciones completamente anormales, las cuales se deben resolver en el momento. Sin embargo, esto puede llegar a ser un inconveniente durante el ciclo de pruebas de un programa, ya que las afirmaciones pueden entorpecer el proceso de pruebas ya que no permiten continuar la ejecución de pruebas hasta que la condición que causa la afirmación es arreglada, o la afirmación es deshabilitada por completo.

Conclusión Las afirmaciones son una herramienta de gran utilidad para mejorar la calidad de nuestros programas. Sin embargo, debemos estar concientes de que no sustituyen otras prácticas de depuración, sino que las complementan.

NOV-DIC 2007

// INFRAESTRUCTURA

Guía a los Microprocesadores Modernos Entendiendo cual se ajusta a tus necesidades Por Ariel García

Hoy por hoy, el mercado de procesadores x86 sigue avanzado a una velocidad impresionante. El pasado mes de septiembre Advance Micro Systems (AMD) presentó su nuevo procesador quad-core, mientras que Intel ya había liberado su primera generación de procesadores de este tipo a finales del 2006, y se espera que antes de que termine este año libere la segunda generación. Esto es tan solo un simple ejemplo de cómo se esta moviendo el mercado de procesadores. El rápido desarrollo de este mercado ha ocasionado que una decisión como la compra de una computadora de escritorio o portátil, implica el conocimiento de los distintos procesadores que existen en el mercado. La oferta que ofrecen ambos proveedores es amplia y requiere ser comprendida de forma sencilla para poder satisfacer la necesidad de cómputo como puede ser: programación, simulación, diseño multimedia, trabajo en casa etc. En este mercado que se mueve tan rápido es fácil encontrarnos con la pregunta. ¿Cuál es procesador indicado para satisfacer nuestras necesidades de cómputo? En este artículo presentamos las familias de procesadores actuales ofrecidos por Intel y AMD. Para ello se presentaran cuadros con las necesidades de cómputo del mercado al que los procesadores van orientados y las familias de procesadores que satisfacen a dicho mercado. Los cuadros están basados en la información presentada por cada proveedor en su sitio web. Posiblemente existen procesadores que podrían aparecer en distintos segmentos, pero los cuadros se diseñaron para presentar la información de la forma más sencilla al criterio del autor. Tomando como base a la información recopilada en los sitios web de cada proveedor, los procesadores de ambas compañías fueron divididos en tres principales mercados: Equipos de escritorio, Equipos portátiles y Servidores/Estaciones de trabajo.

Equipos de escritorio El mercado de procesadores de los equipos de escritorio se divide a su vez en tres subcategorías, dependiendo de las necesidades de uso. La tabla 1 muestra dichas categorías y los procesadores que corresponden a cada una. Necesidades

Intel

AMD

Alta demanda de desempeño Hard core gamers, aplicaciones multitareas de respuesta rápida, lo último en tecnología de procesamiento, experiencia multimedia de alta definición.

Intel® Core™2 Extreme processor Intel® Core™2 Quad processor Intel® Core™2 Duo processor

AMD Athlon™ 64 FX Processor AMD Athlon™ 64 X2 and AMD Athlon™ X2 DualCore Processor

48

NOV-DIC 2007

Power user / procesamiento de oficina Aplicaciones multitarea, creación y distribución de multimedia, múltiples aplicaciones de oficina, desarrollo, power user de Internet.

Intel® Pentium® processor Extreme Edition Intel® Pentium® DualCore processor Intel® Pentium® D processor Intel® Pentium® 4 processor Extreme Edition supporting Hyper-Threading Technology Intel® Pentium® 4 processor supporting HyperThreading Technology

Procesamiento robusto y confiable. Experiencia multimedia, paquetería de oficina, acceso a Internet, clientes delgados.

Intel® Celeron® processor AMD Sempron™ Intel® Celeron® D Processor for Desktop processor

AMD Athlon™ 64 Processor

Tabla 1. Características de los procesadores de escritorio

La diferencia entre las distintas familias de procesadores está principalmente dada por el número de cores, las velocidades del bus de datos, cantidad y disponibilidad de memoria cache, chipsets soportados, tamaño y espaciado de los transistores del procesador. Sin embargo, otro factor importante de diferenciación son las tecnologías propietarias adicionales que pueda tener cada familia. En el caso de Intel, sus principales tecnologías de diferenciación para el desktop son Enhanced SpeedStep (habilita el control de la velocidad de reloj del procesador por medio de software), Hyper Threading (mejoras en procesamiento paralelo), y Execute Disable Bit (un mecanismo para evitar ataques de overflow del buffer). En el caso de AMD, las principales tecnologías a las que recurren para diferenciarse en el desktop son HyperTransport (comunicación interna de datos a alta velocidad), Cool’n’Quiet (bajo consumo de energía), y AMD Digital Media XPress (aceleración de aplicaciones multimedia).

Equipos Portátiles La segmentación del mercado de equipo de escritorio aplica de forma similar en el mercado de equipos portátiles. Las características adicionales en los procesadores de equipos portátiles son el consumo de batería (administración de la energía) y manejo de tecnologías inalámbricas. Esto se aprecia en la tabla 2. Necesidades

Intel

AMD

Alta demanda de desempeño móvil Gamers, aplicaciones

Intel® Centrino® Duo Intel® Core™2 Extreme mobile processor

AMD Turion™ 64 X2 DualCore Mobile Technology

www.sg.com.mx

multitareas de respuesta rápida, último en tecnología de procesamiento móvil, experiencia multimedia de alta definición, administración eficiente de energía.

Intel® Core™2 Duo mobile processor Intel® Core™ Duo mobile processor Intel® Centrino® Intel® Core™2 Solo mobile processor Intel® Core™ Solo mobile processor

Power user / procesamiento de oficina Aplicaciones multitarea, múltiples aplicaciones de oficina, consumos bajos de energía, conectividad inalámbrica eficiente, conectividad remota.

Intel Pentium dual-core mobile processor Intel® Pentium® M processor

Estaciones de trabajo para: Diseño CAD, simulaciones, diseño multimedia de alta definición, alto procesamiento de punto flotante, edición de video.

AMD Athlon™ 64 X2 Dual-Core Processors for Notebooks

Intel® Xeon® processor 3000 sequence Intel® Core™2 Quad processor Intel® Core™2 Duo processor Intel® Core™2 Extreme processor Intel® Pentium® D processor Intel® Pentium® 4 processor supporting Hyper-Threading Technology

Quad-Core AMD Opteron™ Processor Second-Generation AMD Opteron™ Processor with DDR2 and AMD Virtualization™

Tabla 3. Características de los procesadores en servidores y estaciones de trabajo

Procesamiento robusto y Intel® Celeron® processor Mobile AMD Sempron™ confiable. Intel® Celeron® M Processors Experiencia multimedia, processor paquetería de oficina, acceso a Internet, equipos básicos de buen desempeño.

Tanto en el caso de Intel como AMD, las diferencias entre familias siguen girando alrededor del número de cores, velocidad de bus, memoria cache y tamaño y espaciado de los transistores. Sin embargo, en este caso las tecnologías propietarias son diferentes a las usadas en procesadores de escritorio o portátil, ya que se centran principalmente en el manejo de virtualización, cómputo de 64 bits, seguridad, cómputo verde (eficiencia de energía), y facilidades para la administración.

Tabla 2. Características de los procesadores portátiles

En el segmento de laptops, la diferenciación entre familias también se da a través de los factores tradicionales ya mencionados (cantidad de cores, velocidad de bus, memoria caché, etcétera) así como el uso de tecnologías propias de cada proveedor. En este segmento entran diversas tecnologías para un mejor manejo de la energía (prolongando así la duración de la carga de la batería). Es así que Intel ofrece tecnologías como Intelligent Power Capability y Enhanced SpeedStep, mientras AMD hace lo propio con la tecnología PowerNow.

Servidores / Estaciones de Trabajo En el caso de los procesadores para servidores y estaciones de trabajo, ambos proveedores enfocan el diseño de sus procesadores para ofrecer productos con un alto soporte en: tecnologías multicore, virtualización, seguridad y eficiente consumo de energía entre otros. Necesidades

Intel

AMD

Servidores para: Aplicaciones transaccionales, aplicaciones para toma de decisiones, servicios web, correo electrónico, impresión, recursos de red

Intel® Xeon® processor 7000 sequence Intel Xeon processor 5000 sequence Intel Xeon processor 3000 sequence Intel® Itanium® 2 processor 9000 sequence

Quad-Core AMD Opteron™ Processor Second - Generation AMD Opteron ™ Processor with DDR2 and AMD Virtualization™

www.sg.com.mx

Conclusión El objetivo de presentar la información contenida en este artículo es presentar un marco de referencia para identificar las ofertas de los principales proveedores de microprocesadores, para las necesidades de cómputo de cada segmento. Estos cuadros nos facilitan la identificación del procesador adecuado para la necesidad de cómputo que deseamos satisfacer. Este artículo no recomienda una marca o producto sobre otro, simplemente informa sobre las características de cada segmento. También cabe señalar que las necesidades de cómputo presentadas para las ofertas de ambos proveedores, no están limitados a las mencionadas en estos cuadros. Estas necesidades claramente pueden ampliarse, sobre todo en el cuadro de servidores y estaciones de trabajo. El comparativo entre tecnologías específicas de ambos proveedores, así como la descripción detallada de cada una de las tecnologías propietarias esta fuera del alcance de este artículo. En entregas futuras se podrán realizaran análisis de estas tecnologías y se podrá analizar las diferencias de arquitectura entre ambos proveedores, así como se presentaran las ofertas y mercados de los proveedores de procesadores RISC.

NOV-DIC 2007

49

////TECNOLOGÍA TECNOLOGÍA

/* #include <paralelo.h> */

Retos del Nuevo Cómputo ¿Listo para pensar en paralelo? Por James Reinders

Nota del editor En los últimos meses hemos visto que el común denominador de los procesadores modernos es de múltiples núcleos y esa es una tendencia irreversible. Ante esta realidad, consideramos que los desarrolladores de software modernos deben aprender (o reaprender) a desarrollar sus aplicaciones de forma óptima para ejecución en múltiples cores. Por ello estamos iniciando una serie de artículos orientados a hablar sobre paralelismo y mejores prácticas para el desarrollo multicore.

Debido a los procesadores multicore, el procesamiento paralelo es una nueva realidad – y debemos aprender a programar de acuerdo a este paradigma. Pero, ¿qué retos quedan por delante? ¿Qué dolores de cabeza nos esperan? En mi opinión, hay 3 retos clave: escalabilidad, confiabilidad y facilidad de mantenimiento.

Escalabilidad De los tres retos mencionados, la escalabilidad es el más relacionado con el paralelismo. Viéndolo de forma simplista, cualquiera esperaría que dos procesadores fueran más rápidos que uno. Incluso podríamos esperar que al usar dos procesadores obtuviéramos el doble de desempeño que al usar uno. Dependiendo del tipo de aplicación, y la forma en que la programamos, podríamos acercarnos a este tipo de desempeño. Sin embargo, sin las prácticas de programación adecuadas, podríamos quedar en el escenario de que las aplicaciones que desarrollemos solo obtengan mejoras mínimos en desempeño, o incluso vernos en el caso de aplicaciones que corran más lento en varios procesadores que en uno solo.

La clave para la escalabilidad bajo un paradigma paralelo está en el cómo estructuras tu programa – el algoritmo que escoges. El procesamiento paralelo de datos (muchos datos que deben procesarse de la misma forma) tiende a ser más fácilmente escalable que el procesamiento paralelo de tareas. Si dividimos un problema en exactamente dos partes, no vamos a lograr obtener beneficios más allá de dual-core. En cambio, lo que debemos hacer es dividir los problemas en la mayor parte posible de partes, ya que así podremos maximizar los beneficios de procesamiento paralelo ahora y en el futuro. Debemos tener una mentalidad del tipo “¿Cómo resolvería este problema si tuviera mil procesadores?”. Esta mentalidad es la que nos ayuda a obtener las mejores soluciones posibles. Otra clave para la escalabilidad es la de utilizar algoritmos de administración de threads robustos y correctamente implementados. Por esta razón cobra especial importancia la utilización de librerías como OpenMP o Intel Thread Building Blocks, que proveen utilerías altamente optimizadas que resuelven tareas comunes en la programación paralela. Por otro lado, la confiabilidad y facilidad de mantenimiento son retos que siempre hemos tenido, pero que arrojan nuevos retos en el contexto de cómputo paralelo.

Confiabilidad La confiabilidad en un programa se logra a través del aseguramiento de calidad, lo cual típicamente implica realizar un gran número de pruebas para simular el ambiente que experimentará un programa durante su ejecución en producción. El paralelismo agrega nuevas variables de prueba: el número de procesadores y la sincronización de los hilos de ejecución. Errores simples de programación al manejar la división de tareas entre hilos pueden tener graves consecuencias, asi que hay que tener cuidado con ellos. Sin embargo, los problemas

más graves y molestos son aquellos errores no deterministicos que permanecen latentes y de pronto aparecen sin que estemos seguros de que es lo que los ocasiona. Los principales errores de este tipo son los bloqueos (deadlocks) y condiciones de secuencia (race conditions). Un deadlock es cuando múltiples threads están bloqueados esperandose mutuamente – un ejemplo de este concepto es el clásico problema de “la cena de los filósofos”. Un deadlock es facil de detectar una vez que se presenta, pero lo complicado es eliminar la posibilidad de que suceda. Cuando un thread bloquea un recurso y no lo suelta hasta que se libere otro, y al mismo tiempo otro thread realiza lo mismo, entonces tenemos un deadlock. Mientras se tengan más hilos de ejecución, aumenta la posibilidad de bloqueos. Ante esta situación, la lógica de nuestros programas debe evitar tener que esperar a otros hilos, cuando esta espera puede significar que los otros hilos no logren terminar. Las condiciones de secuencia son fallas en las que el resultado de una operación es dependiente de la secuencia o tiempo en que se realicen otros eventos. Normalmente, cuando un thread es dependiente de datos desde otro thread, éste se sincronizará utilizando una bandera o bloqueo para saber que el dato ha sido calculado y está disponible. Si la sicronización es omitida, el programa trabajará en cualquier momento y tendremos resultados inestables. A través del análisis estático de código se pueden encontrar algunas de estas fallas, pero no todas. Es por ello que existen herramientas especializadas para encontrar este tipo de fallas. Una de estas herramientas es el Intel Thread Checker, que es una herramienta de análisis dinámico de código. Les recomiendo fuertemente utilizarla. No es muy rápida,

James Reinders es ingeniero senior en Intel Software y actualmente funge como evangelista en jefe de la unidad de productos para desarrollo de software. James es autor del libro “VTune Performance Analyzer Essentials”, y también colaboró en el nuevo libro “Multi-Core Programming”, ambos editados por Intel Press.

50

NOV-DIC 2007

www.sg.com.mx

pero es de gran ayuda para encontrar errores de este tipo.

Facilidad de Mantenimiento La facilidad de mantenimiento es el tercer reto. A través de los años, hemos migrado de lenguajes de bajo nivel como ensamblador hacia lenguajes de más alto nivel para incrementar la facilidad de programación y mantenimiento de programas. La clave aquí es la abstracción. Muchos detalles de la programación en ensamblador son abstraídos por los lenguajes de alto nivel. Esto tiene el deseable efecto de hacer a FORTRAN más portable que el código en ensamblador de una IBM 360. De la misma forma, debemos estar conscientes de que el control de threads a través de librerías de bajo nivel como pthreads de Windows o mensajes MPI, es el equivalente a usar ensamblador.

www.sg.com.mx

Es por esto que las abstracciones como OpenMP o Intel Threading Building Blocks que proveen librerías de mayor nivel para el manejo de threads, son bastante atractivas. Es cierto que todavía no resuelven todas las posibilidades, pero aun así son de gran utilidad para la mayoría de los casos.

favorita fue que esto se ejecutó mejor y fue más escalable. ¿Por qué? Simplemente porque hay un grupo de ingenieros continuamente enfocados en optimizar al máximo el desempeño de estas librerías.

Recientemente vivi un ejemplo del poder de la abstracción en una pieza critica de código. El código original eran 182 líneas de C++. Para paralelizarlo usando manejo de hilos explícito (pthreads) se requerían otras 143 líneas de código, lo cual daba un total de 325 líneas. En cambio, hacer lo mismo utilizando Intel Threading Building Blocks requirió solamente 17 líneas de código para un total de 199 líneas de código, lo cual nos da una solución mucho más fácil de mantener. Mi parte

En este artículo he presentado lo que considero que son los principales aspectos a tener en cuenta al comenzar a desarrollar aplicaciones bajo un paradigma de cómputo paralelo.

Conclusión

Pensar en la escalabilidad de tus programas, cómo hacerlos confiables y faciles de mantener, es un gran paso al éxito en la programación paralela.

NOV-DIC 2007

////TECNOLOGÍA TECNOLOGÍA

/* GADGETS */

ThinkGeek

Wi-Fi Detector Shirt Para no tener que sacar la computadora, buscar un lugar dónde conectarla, prenderla y activar el port para localizar señales Wi-Fi. ThinkGeek piensa en las necesidades de los que no pueden vivir sin conexión a Internet (802.11b u 802.11g), y para simplificarles la vida ofrecen una playera negra 100% algodón que detecta la fuerza de las conexiones a Internet donde quiera que vayas, puedes presumir mientras caminas la recepción de la señal, gracias a un display luminoso que se puede quitar para facilitar el lavado (las instrucciones precisas de cómo hacerlo vienen incluidas). Funciona con tres baterías AAA que se encuentran en un pequeño bolsillo hilvanado por dentro de la playera. Ahora sí, se acabaron los pretextos para dejar la computadora en casa.

ACME Systems

3 LCD Surround System LPG370TS LPG370TS es una computadora robusta en forma de lonchera cuyo chasis está fabricado con metal de alto rendimiento para uso rudo y fácil transportación. Viene equipada con tres pantallas LCD de alta resolución de 17” SXGA; sistema dual de enfriamiento con ventiladores laterales, y fácil acceso a los puertos de expansión para actualizaciones de sistema o mantenimiento. Es extra fuerte, su construcción y diseño están pensados para resistir golpes, caídas o cualquier otro tipo de condición adversa, o individuo descuidado. La propuesta de ACME con este modelo es ofrecer un “todo en uno” que integra teclado, mouse y pantalla. ¿Ingenioso, no? Cuenta con un procesador Quad Core Intel Core 2 Duo, tarjeta Dual nVIDIA 8800GTX, ocho canales de audio, conectores Firewire 400 y USB 2.0, red Dual Gigabit LAN, chipset nForce 680i y memoria de “GB DDR2 PC2 6400. Todo esto en una caja de lunch.

52

NOV-DIC 2007

Firefox

Echo Bot Si bien es cierto que hay una gran cantidad de gadgets con formas curiosas que no sirven para gran cosa, no podemos ignorar aquellos que por lo menos proponen algo. Tal es el caso del Echo Bot, un robot —como su nombre lo indica— que además de simpático y colorido, permite grabar mensajes de voz a través de su pequeño micrófono. El Echo Bot se puede colocar en cualquier parte de la oficina e incluso sobre la computadora. Se activa gracias a un sensor que capta el movimiento a pocos metros de distancia, de tal manera que cuando alguien pasa por ahí, se escucha el mensaje previamente grabado que, puede ser desde el recordatorio de una reunión, hasta un: “aléjate de mi computadora”. La duración de los mensajes puede ser hasta de 10 segundos. Requiere baterías AG13 que vienen incluidas.

www.sg.com.mx

Sennheiser

VMX100

Wifi Frame

Portarretrato digital Los portarretratos digitales han llegado para quedarse, y poco ha poco están evolucionando para satisfacer mejor las necesidades de los usuarios. La nueva tendencia en estos productos está en habilitarlos con WiFi y una dirección propia de correo electrónico. ¿Y para qué sirve un portarretrato con WiFi y correo electrónico? Bueno, esto permite actualizar remotamente por email las fotografías que despliega. Si quieres ir un paso más alla, puedes configurarlo para que lea feeds de RSS, de tal forma que podría desplegar imágenes que tengas en repositorios en Internet como Facebook o Flickr.

Ahora que el nuevo reglamento de tránsito marca severas multas a todos aquellos que conduzcan y hablen por teléfono al mismo tiempo, la oferta de auriculares manos libres ha ido creciendo, un ejemplo y también buena opción para atender llamadas en el auto es el inalámbrico VMX100 Bluetooth de Sennheiser. Éste cuenta con tecnología VoiceMax que elimina los ruidos e interferencias producidos por el viento o el tráfico gracias a un sistema direccional con base en dos micrófonos y un procesamiento digital de señal que identifica la voz por sobre otros distractores auditivos. El diseño del VMX100 es completamente ergonómico y ligero con tan solo 15 gramos; así pues se adapta al contorno de la oreja (izquierda o derecha) haciéndolo muy cómodo. El boom del micrófono por su parte, se puede ajustar de acuerdo a las preferencias personales de cada usuario, y también está diseñado para abrir o cerrar el paso de la corriente de audio.

Alienware

Hangar18 HD Home Entertainment Center Ver, escuchar, compartir y descargar son las cuatro acciones primordiales que definen a la perfección este centro de entretenimiento para el hogar de Alienware. Además de contar con un diseño moderno y con verdadera actitud, su poder y capacidad son perfectas para quienes disfrutan de ver, pausar y grabar películas, programas de televisión, fotografías y videos de Internet en pantalla ancha y alta definición. Así como para escuchar música a través de su amplificador con sonido surround 5.1. Cuenta con stream inalámbrico para compartir contenidos entre PCs, dispositivos móviles y extensiones de medios a través de toda la casa. Además permite descargas de Internet hacia una locación segura para almacenar dentro o fuera del hogar. Por si todo lo anterior no fuera suficiente, el Hangar18 viene cargado con Blu-ray, por lo que además de disfrutar alta definición a 1080p, ofrece una capacidad de almacenamiento de 50GB por disco. Su capacidad total en disco duro es de 2 terabytes para concentrar toda tu vida digital en un solo sistema.

www.sg.com.mx

NOV-DIC 2007

53

////BIBLIOTECA TECNOLOGÍA

Business Rules Management and Service Oriented Architecture: A pattern language. Ian Graham Wiley, 2006

01

Libro de Ian Graham, editorial Wiley. El autor nos habla en 7 capítulos sobre los sistemas BRMS y de componentes SOA, así cómo las metodologías y herramientas que se pueden utilizar para este concepto. Graham hace un comparativo de tres productos: Blaze Advisor, JRules y Haley. Aunque de los dos primeros hable de versiones pasadas, el contexto comparativo de las características base es suficiente para presentar el comparativo. A través de las páginas de este libro el lector podrá comprender los conceptos relacionados con los componentes SOA, la teoría sobre los BRM, cómo utilizar UML para expresar estas reglas, además de conocer las características de los BRMS, por mencionar algunos ejemplos. Esta es una buena opción para aprender de las reglas de SOA y aprender de los patrones de requerimientos, desarrollo, definición y organización de las reglas de negocio.

El libro también aborda problemática común en proyectos de sistemas, tales como: • Falta de involucramiento por parte del usuario. • Los objetivos no son claros y tampoco hay vision. • Falta de claridad en las solicitudes de requerimientos. • Falta de liderazgo en el equipo de desarrollo • Carencia en la planeación. Por último, otro aspecto que resalta de este libro es que contiene un capítulo completo dedicado al lenguaje de patrones para el desarrollo de BRMS (Business Rules Managemente Systems), abarcando desde las definiciones base de qué son los patrones hasta ejemplos avanzados con lenguajes de patrones.

Designing with Web Standards (2nd edition). Jeffrey Zeldman AIGA, 2007

02

Jeffrey Zeldman comparte con sus lectores este libro que resulta ser una guía de temas relacionados con los estándares Web. De fácil lectura, muy informativo y fácil de comprender. El reconocido autor ha demostrado cómo a través de los estándares se ha creado la guía hacia una ingeniería de búsqueda más amigable, además de enseñarle al lector, que el uso adecuado de elementos como CSS y otros estándares existentes hacen que los sitios Web se vuelvan más accesible su contenido a través de cualquier tipo de navegador. Este libro habla de los estándares Web, desde los conceptos que nos ayudarán a identificar si nuestro sitio web es uno de los que forman el 99.9% de obsolecencia, la comprensión del utilizar estándares para crear nuestro sitio, hasta diseñar y construir considerando estos conceptos. Algo que llama la atención de esta obra es que Zeldman no ignora

54

NOV-DIC 2007

los problemas con los estándares existentes, y de hecho dedica un capítulo a este tema, brindándole al lector la entera confianza que leerá un libro objetivo en el que pone a la luz las dos caras del concepto. Si queremos saber el ¿qué?, ¿cómo?, ¿para qué? y ¿por qué? utillizar estándares web, esta es la mejor guía para responder a todas esas interrogantes. “Designing with web standards” definitivamente es lectura obligada para cualquier webmaster. Es una excelente opción si no se tienen los conocimientos suficientes sobre estándares Web y una buena opción para madurar los que ya se tienen.

www.sg.com.mx

INDEX

DIRECTORIO

Anunciante

Páginas

Sitio

TENEMOS UN ESPACIO RESERVADO PARA TI

Avantare Adecco CANIETI Compusoluciones e-Quallity Intel Itera Linux World Microsoft Milestone Consulting Netec Roca Sistemas SafeNet SG Sun Microsystems S&C TenStep

47 09 45 41 31 F0 13 F3 F2, 1 F4 15 11 29 43,55 39 51 35

www.avantare.com www.adecco.com.mx www.canieti.com.mx www.compusoluciones.com.mx www.e-quallity.net www.intel.com.mx www.itera.com.mx www.linuxworld.com www.microsoft.com.mx www.milestone.com.mx www.netec.com.mx www.rocasistemas.com.mx www.safenet-inc.com www.sg.com.mx/sg07 www.sun.com.mx www.syc.com.mx www.tenstep.com.mx

Si deseas anunciarte contáctanos en el (55) 5239 5502 o en [email protected]

www.sg.com.mx

NOV-DIC 2007

55

// COLUMNA

/*CÁTEDRA Y MÁS*/

Crónicas de un Estándar De subcomités y el surrealismo Mexicano

Dr. Raul A. Trejo es Profesor Investigador del Departamento de Sistemas de Información del Tec de Monterrey, campus Estado de México. Sus áreas de interés incluyen Ingeniería de Software, Negocios Electrónicos e Inteligencia Artificial. Es miembro del Sistema Nacional de Investigadores (SNI) y ha presentado sus trabajos de investigación en diversos foros nacionales e internacionales. El Dr. Trejo es miembro fundador de la Asociación de Sistemas de Información de América Latina y del Caribe.

H

ace un par de meses fui invitado a formar parte del subcomité treinta y cuatro de ISO/IEC. Este subcomité tenía la muy importante misión de decidir la postura de México sobre si el formato OOXML para guardar documentos debía o no ser aprobado por la vía rápida como un estándar de ISO.

desafía mi lógica y dejo en el tintero). La sala de juntas de CANIETI estaba a reventar, como nunca la he visto. Lo que siguió realmente hubo que vivirlo para creerlo, y yo aún pienso que ese día fui trasladado a una especie de dimensión desconocida, por lo surrealista que de pronto se volvió la situación.

Como he realizado pruebas beta y pruebas de concepto con Office 2007, me pareció buena idea participar. Durante los siguientes días nos hicieron llegar el documento del estándar propuesto, un enorme documento de más de 1000 hojas tan solo para la especificación básica. Honestamente no creo que nadie lea un documento de ese tamaño en su totalidad, de modo que yo me concentré en cuestiones de seguridad, cuestiones de compatibilidad, cuestiones de derecho de copia y de uso, y finalmente, pero no menos importante, cuestiones de usabilidad: de nada sirve un estándar si no es de uso práctico para los usuarios.

Resulta que lo que debió ser una reunión para determinar la pertinencia de OOXML como estándar se convirtió en un debate de software libre contra software comercial, y yo solo pude contenerme una sonrisa incrédula cuando el primer punto de discusión fue ese documento bajado de noooxml.org. Parece ser que más personas habían hecho su tarea. Los minutos se hicieron horas y las horas eternidades mientras ambas facciones (por que en este momento eran facciones) exponían su caso, sobre las ventajas del nuevo estándar, sobre sus peligros, sobre la necesidad de dos estándares, sobre las virtudes y deficiencias de cada uno de ellos.

Junto con mis alumnos, exploramos el formato y construimos aplicaciones para leer y escribir documentos en OOXML. Mientras, revisé los puntos de compatibilidad, seguridad y derecho de copia en el documento. Y, como buen miembro de la generación X, me dediqué a leer información adicional en Internet. Ahí me encontré con muy acalorados discursos a favor y en contra de la adopción de OOXML como estándar. Me parece que ISO recibe, revisa y aprueba o rechaza una buena cantidad de estándares cada año, y muchas de estas decisiones ocurren sin más que una mención en alguna revista especializada. Pero este estándar en particular tenía que ver con un formato originado por la empresa de las ventanitas, y tras unos cuantos minutos de visitar páginas en Internet pude darme cuenta que para algunos la adopción del estándar se había convertido en un avatar de la eterna pugna entre el software libre y el software comercial. Revisé la documentación técnica de Microsoft. Revisé la documentación técnica de ODF, el formato para documentos que utiliza OpenOffice y que ya ha sido aprobado como un estándar ISO. Definitivamente descarté el discurso de las páginas de mercadotecnia de Microsoft, pero del mismo modo descarté el discurso extremista de www.noooxml.org, que descalificaba a OOXML de entrada con información incompleta.

Yo me desconecté de la discusión por la siguiente hora, porque ahora yo me sentía como en la cámara de senadores, en uno de esos grandes ejemplos de madurez de nuestra política nacional. Simplemente me quedé ponderando sobre la utilidad de un estándar oficial, si no es un estándar que vive feliz en mi computadora personal.

En fin, armado de todas mis lecturas y mi experiencia con el formato, emití mi voto y asistí a la reunión final del comité (el porqué se emitió el voto primero y luego fue la reunión es un tema aparte que

56

NOV-DIC 2007

Entonces nuestro moderador mostró los resultados de la votación, porque como les comenté, estimados lectores, ya habíamos votado durante la semana. Todo nuestro interesante debate había sido en vano, pues la decisión de nuestro valiente comité estaba tomada de antemano. Ahora había que discutir la validez de los votos, momento que yo aproveché para una graciosa huida. Dicen que si Salvador Dalí hubiese nacido en México, hubiera sido un sujeto más. Después de esta experiencia, no puedo estar más de acuerdo. Y, ¿qué pasó con OOXML? En lo que a México respecta, se optó por una abstención del voto. El resultado de la votación internacional es que OOXML tendrá que buscar ser aceptado como estándar ISO por la vía normal, ya que no lo consiguió a través del fast track. Mientras tanto, los diferentes formatos del documento conviven felices en mi computadora, sin que este evento surrealista parezca afectarlos. —Raul A. Trejo

www.sg.com.mx