sg22 (noviembre 2008 - enero 2009)

NOV-ENE 2009 www.sg.com.mx

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Coordinación EditorialAlejandro Escamilla

Arte y DiseñoGrisel Otero

Consejo Editorial Jorge Valdés - PMI; Luis Cuellar - Softtek;

Francisco Camargo, Luis D. Soto - Microsoft; Hanna Oktaba - UNAM; Ralf Eder, Raúl

Trejo, Guillermo Rodríguez - ITESM CEM;Emilio Osorio - Sistemas Humanos;

Luis Vinicio León - e-Quallity.

ColaboradoresCarlos Coello, Benjamín Alonso,

Guillermo Morales, Javier Espadas,Pablo Resendiz, Gilbert Corrales,Juan Olivares, Sandokan Barajas,

Victor García, Miguel Armas,Francisco Vaca, Carlos Ordoñez,

Beatríz Ríos, Luis Joyanes,Shannon Cepeda, Romeo Márquez,

Gunnar Wolf , Susana Tamayo.

Ventas Claudia Perea

Circulación y Administración Edgar Dorantes

[email protected]

+52 55 5239 5502

SG Software Guru es una publicación trimestral 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 octubre de 2008 en Roma Color, S.A. de C.V. Distribuido por Sepomex.

directorio

Editorial

// CONTENIDO

02

Muchos hemos oído acerca de Cómpu-to en la Nube, pero ¿qué es esto?, ¿dónde se está aplicando?, ¿qué opinión tienen los expertos al respecto? Más allá de la moda, es importante entender cuales son los con-ceptos fundamentales de este modelo, así como el impacto que tendrá en la forma en que desarrollamos software.

En cuanto a la portada, seguramente se preguntarán qué fumamos para salir con el concepto artístico. Queremos aclarar que no se usaron sustancias alucinantes durante su desarrollo (no que nos cons-te), ni nos basamos en libros de “Donde está Wally”. Simplemente le explicamos a nuestra diseñadora, Grisel Otero, el con-cepto de cloud computing, y le pedimos que ella hiciera una interpretación artísti-ca de él. Después del shock inicial de ver su propuesta, nos dimos cuenta de cómo ella entiende y plasmó el concepto: bási-camente, una masa de elementos diver-sos que a pesar de ser diferentes, tienen elementos comunes, convergen y generan sinergia ... y justamente eso es lo que es.

Desde hace tiempo que teníamos ganas de en-trevistar a Tom DeMarco, y por fin se nos hizo. Tom es una de esas personas que nos hace abrir los ojos y darnos cuenta de tantas cosas. Muchas gracias a Tom y a la gente de Cutter Consortium por facilitar esta entrevista.

En este número tenemos también la edición 2008 de nuestra Encuesta de Salarios, que se está convirtiendo en el reportaje más es-perado del año. Para complementar el resto del contenido de este número, ofrecemos un panorama sobre ofuscación de código, un artículo bastante completo sobre RFID, así como las secciones de costumbre con prácticas de ingeniería de software, y la perspectiva de nuestros columnistas.

Queremos también aprovechar esta oportunidad para recordarles sobre el proyecto más reciente de SG, denominado SG Campus. Este es un servicio de aprendi-zaje continuo en línea para profesionistas de TI. Ya están abiertos varios cursos y los resultados han sido muy satisfactorios. Si todavía no te unes a SG Campus, hazlo en www.sgcampus.com.mx.

Dado que el último número del año, no queremos quedarnos sin desearles unas felices fiestas navideñas, y un próspero 2009. Ante el panorama financiero que hemos vivido últimamente, sabemos que esto último será complicado. Pero bien di-cen que “a río revuelto, ganancia de pesca-dores”. Así que hay que ponernos las pilas para aprovechar esta oportunidad.

» Equipo Editorial

NOV-ENE 2009www.sg.com.mx

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

Columna Invitada 46 por Carlos Ordoñez

Tendencias en Software 48por Luis Daniel Soto

Prueba de Software 50por Luis Vinicio León

24

Productos

LO QUE VIENE 12VSTS 210, Mono 2.0 y Oracle Beehive.

HERRAMIENTAS 14Beneficios de la Automatización de Pruebas.

TUTORIAL 16Silverlight, Parte 2.

Prácticas

PROGRAMACIÓN 36Ofuscación de CódigoConozcamos como proteger nuestro códigopara que no sea reutilizado por terceros.

ADMINISTRACIÓN DE BASE 40DE DATOS Diseño de Base de DatosAprendamos a utilizar los catálogos para hacermás eficiente nuestra manera de codificar.

ARQUITECTURA 42Una Receta para DesarollarArquitecturasPresentamos el marco de trabajo paradesarrollar arquitecturas propuesto porThe Open Group.

PM CORNER 44La integración de un equipo detrabajo funcionalTácticas y técnicas para integrar de maneraeficiente a tu equipo de trabajo.

EN PORTADA

Cloud ComputingTe mostramos los recursos ilimitados del “Cómputo en la nube”

Especial 18 Encuesta de Salarios 2008.

contenido nov 2008 - ene 2009

03

En Cada Número

NOTICIAS y EVENTOS 04

INDUSTRIA 06

INFRAESTRUCTURA 52

EntrevistaTom DeMarco

GADGETS 60

FUNDAMENTOS 62

CARRERA 64

26


// NOTICIAS

04

XXIX Convención Nacional CANIETI Tras tres días de reunión, debate y reflexión conjunta, concluyó la XXIX Convención Nacional CANIETI, la cual bajo el título “Gobierno, Academia e Industria: Triple Play Ganador” reunió a representan-tes de estos sectores con un solo objetivo: sentar las bases del desarrollo de las industrias representadas en el corto y mediano plazo. La Convención fue inaugurada por el Presidente Constitucio-nal de México, el Lic. Felipe Calderón Hinojosa, y precedida por el Presidente Nacional de CANIETI, el Dr. Eduardo Ruiz Esparza, quien agradeciendo el dinamismo y visión de los afiliados, así como al apoyo de los programas del Gobierno Federal, comentó que ha sido posible mejorar la posición competitiva de nuestro país en cinco posiciones, con respecto de otros jugadores internacionales, men-cionando los programas más sobresalientes: ProSoft, MexicoIT, ProMedia y Mexico FIRST.

IBM Rational Comes to You, México 2008El pasado 10 de septiembre se realizó en la ciudad de México el evento “IBM Rational Comes To You”, donde los asistentes tuvieron acceso a varios de los temas y conferencistas que es-tuvieron presentes unos meses antes en la conferencia anual de Rational que se celebra en Orlando (IBM Rational Software Development Conference). Entre los conferencistas estuvo Te-rry Quatrani, que es la evangelista en jefe de Rational y quien había estado recientemente en México como keynote speaker en SG ’08 Conferencia y Expo.

El tema que dominó las sesiones fue la nueva familia de herra-mientas Rational Team Concert, la cual está construida sobre Jazz, una nueva plataforma open source para el desarrollo de herramientas de colaboración.

Cutter Consortium Summit América LatinaLa edición para América Latina del Cutter Summit 2008 se llevó a cabo del 1 al 3 de octubre en el Hotel JW Marriott en la ciudad de México. El evento reunió a expertos del campo tales como Tom De-Marco, Robert Benson, Tim Lister, Alfredo Funes, Lou Mazzuchelli, Mike Rosen y Alejandro Pisanty.

El tema con el que se abrió el Summit fue el de “Manejo Efectivo de las Finanzas de TI”, el cual cobra especial importancia ante la actual situación económica. Como parte de la exposición de este tema se revisaron a detalle prácticas y recomendaciones para estimar y monitorear el costo total de un servicio de TI, y cómo justificar su valor hacia la alta dirección.


// EVENTOS

05

CIAPEM 2008Los pasados 1ro. al 3 de octubre, en Mundo Imperial Acapulco, se llevó a cabo la XXXII Reunión Nacional del Comité de Informá-tica de la Administración Pública Estatal y Municipal (CIAPEM). Encabezado por el gobierno de Guerrero en el período 2008-2009, el CIAPEM tendrá como objetivo establecer políticas y vínculos entre las administraciones estatales, municipales, fe-derales y privadas que permitan acelerar el crecimiento cons-tante y equitativo de la aplicación y uso de las tecnologías de información. De igual manera buscará establecer una metodo-logía para definir la situación actual que mantienen el uso de la tecnología y las comunicaciones, impulsando a la Sociedad de la Información y el uso de las TICs en México.

CIISA 2008Del 3 al 5 de septiembre se realizó en la ciudad de Guada-lajara, Jalisco el Congreso Internacional de Ingeniería de Software y sus Aplicaciones (CIISA) 2008. Este evento fue organizado por el SIE Center de México en conjunto con el Tec de Monterrey Campus Guadalajara, y apoyado por la Secretaría de Economía y el Gobierno del Estado de Jalisco. Se contó con la presencia de prestigiados conferencistas como Watts Humphrey y Suzzane Garcia del SEI, Lauro Cantú de Gartner, y Kerrie Holley de IBM, entre otros. Los temas cen-trales fueron arquitectura de software, calidad, y tecnologías de desarrollo, agregando también un espacio para explorar oportunidades de negocio.

DebConf 8 El noveno congreso de desarrollo de Debian, DebConf, fue ce-lebrado del 10 al 16 de agosto, en la ciudad de Mar del Plata, Argentina. Participaron aproximadamente 250 desarrolladores, de 37 países, en más de 100 charlas y talleres programados. Además durante la semana previa de trabajo (3 al 9 de agosto), se llevó a cabo el DebCamp, enfocado en el trabajo colaborativo. Participaron personalidades tales como el líder del proyecto Debian, Steve McIntyre, y el jefe de tecnologías Linux y Open Source de Hewlett Packard, Bdale Garbee. Los temas incluyeron la organi-zación del equipo global, internacionalización, desarrollos y políti-cas internas, virtualización, y administración de sistemas y redes.

5 al 7 de Noviembre 2008BAJA TECH Business Solutions 2.0Grand Hotel Tijuana, Baja CaliforniaInfo: www.itbaja.com/web-bajateche-mail: [email protected]

5 y 6 de Noviembre 2008Seminario Gratuito “Squeeze your metrics”Avantare, MS SPI Solutions, y Secretaría de EconomíaTorre Insurgentes de Secretaría de Economía, Cd. de Méxicoe-mail: [email protected]

12 al 14 de Noviembre 2008SEPG LA 2008 – Combinando Disciplina con Métodos ÁgilesESI Tecnalia, SEI, y ESICenter Cono SurHotel Hermitage, Mar del Plata, ArgentinaInfo: www.esi.es/SEPGLAe-mail: [email protected]

11 al 13 de Noviembre 2008Agile Management - CreatingBusiness & Technical ValueCutter ConsortiumHotel JW Marriott, Cd. de MéxicoInfo: www.cutter.com.mx/eventos2008e-mail: [email protected]

12 al 14 de Noviembre 200850 Años de la Computación en MéxicoPalacio de Minería, Cd. de MéxicoInfo: computo50.unam.mx

5 al 7 de Diciembre 2008Expo Robótica, Ciencia y TecnologíaWTC, Cd. de MéxicoInfo: www.exporobotica.com.mxe-mail: [email protected]

Congreso Internacional ANIEI 2008 Organizado por la ANIEI y teniendo como sedes el ITESM Campus Monterrey, la Universidad de Monterrey y la Univer-sidad Regiomontana, se llevó a cabo el XXI Congreso Nacio-nal y VII Congreso Internacional de Informática y Computa-ción, los días 1, 2 y 3 de Octubre. Con el objetivo de aportar conocimientos y experiencias a nuestros próximos profesio-nales en tecnologías de la información, el congreso presentó conferencistas e investigadores de prestigio reconocidos a nivel mundial, contando con la asistencia de más de 1,300 estudiantes y egresados de las carreras de TI.

NOV-ENE 2009 www.sg.com.mx16

// INDUSTRIA

06

Este año estamos celebrando los 50 años de la computación en México, y se han venido realizando una serie de eventos al respecto. Aprovechemos esta oportunidad para echar un vistazo a los princi-pales acontecimientos durante estos 50 años.

La primera computadora en MéxicoLa historia comienza en 1955, año en que el Ing. Sergio Beltrán Ló-pez plantea al Dr. Nabor Carrillo Flores (entonces rector de la UNAM) la adquisición de una computadora. El Ing. Beltrán se había intere-sado en esto a raíz de los resultados de un proyecto de resolución de ecuaciones simultáneas que hicieron en conjunto con la Universidad de California en Los Angeles (UCLA). En la resolución de este proyec-to los investigadores mexicanos habían tardado 9 meses, mientras que la UCLA solo había tardado 3 semanas utilizando una computa-dora IBM-650. Fue así que la UNAM firmó un contrato con IBM para rentar una IBM-650 por un total de $25,000 pesos mensuales.

El 8 de junio de 1958 abrió sus puertas el Centro de Cálculo Electrónico (el CCE), ubicado en el sótano de la antigua Facultad de Ciencias, don-de se instaló la IBM-650. Esta máquina operaba con un tambor mag-nético con capacidad para 20,000 dígitos, realizaba 1,300 operaciones de suma y resta por segundo y funcionaba con lectora y perforadora de tarjetas, adoptando un sistema numérico llamado bi-quinario. Las primeras tareas que se le encomendaron a esta computadora fueron las de resolver problemas de astronomía, física e ingeniería química.

Se unen otras universidadesPosteriormente, en 1961 el IPN inauguró su centro de cómputo, el CENAC, y en 1964 el ITESM instaló su primera computadora, y poco después inauguró la primera carrera de computación en el país. La UNAM, el IPN y el ITESM se convirtieron en polos de atracción de estudiantes curiosos y tenaces que deseaban acercarse a ese nuevo universo de la computación.

Los primeros posgradosEl Centro Nacional de Cálculo del IPN instituyó a fines de los años sesenta la primera maestría en ciencias de la computación. La UNAM hizo lo propio en 1975. Para finales de los años 70, el Instituto de Investigaciones en Matemáticas Aplicadas y Sistemas (IIMAS) de la UNAM contaba con 20 doctores en computación.

La década perdidaLa década de los ochenta fue muy difícil para las ciencias de la com-putación en México. En un periodo menor a tres años, todos los grupos de investigación de las universidades públicas en México se redujeron considerablemente y en algunos casos desaparecieron por completo. A finales de esa década, el escenario económico en las universidades públicas hizo muchos estragos en los grupos de investigadores dedicados al cómputo; a este episodio de la historia de la computación en México se le denominó “La década perdida”.

50 Años de la Computación en MéxicoReseña históRicaPor Alejandro Escamilla

No obstante, para instituciones privadas como el ITAM, la UDLA, o el ITESM, fue un período clave para la formación y crecimiento de su plantilla de doctores en computación dirigidos hacia la investigación.

Nuevo impulso de ConacytEn la década de los noventas, el CONACYT da un fuerte impulso a la realización de investigación a nivel nacional y se crean nuevos centros de investigación tales como: El Centro de Investigación en Computación (CIC) del Instituto Politécnico Nacional, el Laboratorio Nacional de Informática Avanzada (LANIA) en Xalapa, Veracruz; la Coordinación de Ciencias Computacionales del Instituto Nacional de Astrofísica, Óptica y Electrónica (INAOE) y el Departamento de Cien-cias de la Computación del Centro de Investigación Científica y de Educación Superior de Ensenada (CICESE), entre otros.

La llegada del siglo XXIEn la primera década de este siglo, se dieron avances notables como el primer enlace internacional de voz sobre IP nativo en 2002 ; el pri-mer enlace de comunicación interactiva con formato para televisión digital en Internet en 2003 , la Inauguración de la Red Inalámbrica Universitaria (RIU) en 2006, la inauguración de la supercomputadora KanBalam en 2007 entre otros.

Referencias:[cs.cinvestav.mx/SemanaComputoCINVESTAV/Computo.html][lajornadadeoriente.com.mx/2008/01/28/puebla/][computo50.unam.mx/computoenmexico2.html]

ConclusiónEn estos 50 años de la computación en México se ha demos-trado el desarrollo que ha tenido esta floreciente ciencia gra-cias al tenaz esfuerzo de hombres y mujeres que están con-vencidos de que en este país hay oportunidad de alcanzar un sueño. Tal es el caso de los más de 400 doctores en computa-ción o áreas similares que se encuentran en diferentes institu-ciones de educación superior en nuestro país.

Vale la pena reflexionar sobre las palabras del Dr. Renato Itu-rriaga durante la conferencia de inauguración de los festejos por los 50 años de la computación en México: “La computación en el mundo ha tenido avances espectaculares y en el futuro lo serán aún más. Pero toda esa tecnología no ira al frente del hombre, sino detrás de él. El desarrollo de la computación en México lo han realizado, y lo están realizando, personas. Dicho desarrollo solo tiene sentido en tanto esté orientado a servir a los intereses de la sociedad en general y de las personas en lo individual. En 24 siglos no ha perdido vigencia el aforismo de Protágoras: el hombre es la medida de todas las cosas.”


contando con destacados conferenciastas como: el Dr. Edmund Clar-ke (ganador del Premio Turing 20074 por haber desarrollado la he-rramienta conocida como Model Checking) de la Universidad Carne-gie-Mellon, el Dr. Héctor García Molina (quien tiene el factor H más alto en computación a nivel mundial) de la Universidad Stanford, y el Dr. Alan Kay (ganador del Premio Turing 2003 y pionero de la POO e interfaces gráficas) del Viewpoints Research Institute, en-tre otros eminentes expertos. En este evento participaron tam-bién los 4 únicos computólogos de México que ostentan el nivel 3 en el Sistema Nacional de Investigadores: el Dr. Adolfo Guzmán Arenas, el Dr. Felipe Lara Rosano, el Dr. José Luis Marroquín Zaleta y el Dr. Carlos Artemio Coello Coello. Durante el evento se realizaron mesas redondas tratando temas como la situación actual de la computación en México, se llevó a cabo el “Primer Encuentro de Estudiantes que Cursan un Doctorado en Computación en México”, y el concurso de cuento titulado “La Computación del Siglo 21: entre lo natural y lo artificial de la inteligencia y la vida”.

Tras la culminación de este año de celebraciones, bien nos vendría abrir un espacio para reflexionar sobre la dirección hacia donde qui-siéramos que se moviera el grueso de la comunidad de computa-ción en México en los años por venir. Ciertamente, esperamos un crecimiento importante de una comunidad que cuenta actualmente con unos 550 doctores, con un consecuente aumento del número de posgrados, así como de nuestra capacidad para vincularnos con el sector productivo. Sin embargo, también se espera que este cre-cimiento conlleve a una mayor consolidación de nuestros investiga-dores, de manera que esta comunidad tenga mayor peso específico en la toma de decisiones en torno a políticas científicas en México. De lograrlo, ese sería, sin duda, el mejor homenaje que se le po-dría rendir a una disciplina que, querámoslo o no, ha cambiado para siempre nuestro modo de vida.

Referencias[ 1. Anónimo. “Propuesta de Creación del Departamento de Computa- ción del CIEA del IPN. Etapa I: Sección de Computación”. Presentado por el Departamento de Ingeniería Eléctrica, CIEA del IPN. 1983. ][ 2. Coello Coello, Carlos Artemio. “El Departamento de Computación del Cinvestav”. Cinvestav. Abril-Junio 2007 . Vol. 26. No. 2, pp. 4-13. ][ 3. cs.cinvestav.mx/SemanaComputoCINVESTAV ][ 4. El Premio Turing (Turing Award) es otorgado por la Association for Computing Machinery (ACM), y es considerado como el reconocimiento técnico más importante que se otorga en el área de computación. ]

1707

25 Años Haciendo InvestigaciónUn Vistazo al Pasado, PResente y FUtURo en el cinVestaV-iPnPor Carlos Coello

El año 1983 evoca para muchos, incontables memorias. Ese año se introdujo la IBM PC XT; la revista Time eligió a la computadora como la “máquina del año” (en vez del tradicional “hombre del año”), dedi-cándole su portada del ejemplar del 3 de enero; ARPANET estandarizó el protocolo TCP/IP (el cual se sigue usando hoy en día en Internet) y también se anunció el lanzamiento del Windows de Microsoft.

Qué lejanos lucen esos días, en que aparecían los discos compactos en el mercado por primera vez y el uso del correo electrónico y el in-ternet eran prácticamente desconocidos. El Centro de Investigación y de Estudios Avanzados del Instituto Politécnico Nacional (CINVESTAV-IPN) contaba en aquel entonces con 7 minicomputadoras, distribuidas en los Departamentos de Fisiología, Farmacología, Toxicología e Inge-niería Eléctrica. Así mismo, habían decenas de microcomputadoras y se tenía acceso a un mainframe a través de diversas terminales.

El Departamento de Ingeniería Eléctrica del CINVESTAV-IPN llevaba ya, en aquel entonces, varios años de impartir cursos sobre computación electrónica tales como “Introducción a la Computación”, “Teoría de Au-tómatas” y “Arquitectura de Computadoras”, entre otros. Así mismo, el uso de computadoras electrónicas se hacía cada vez más común.

Fue en esta atmósfera que se gestó una propuesta1 para establecer un Departamento de Computación en el CINVESTAV-IPN hacia principios de 1983. En este punto, bien vale la pena reconocer los esfuerzos que rea-lizaron los Dres. Héctor Nava Jaimes (entonces Director General del CIN-VESTAV-IPN), Juan Milton Garduño (entonces Jefe del Departamento de Ingeniería Eléctrica) y Adolfo Guzmán Arenas (fundador y primer Jefe de la Sección de Computación del CINVESTAV-IPN) para llevar a cabo esta empresa. Fue así como se gestó una propuesta que contemplaba 3 eta-pas. La primera etapa arrancó en el mismo 1983, creándose la Sección de Computación del Departamento de Ingeniería Eléctrica. Sin embargo, por diversas razones, fue hasta el año 2006 (más de 20 años después de lo esperado) que la segunda etapa, la creación del Departamento de Computación, se volvió finalmente una realidad2. La tercera etapa, crea-ción de secciones dentro del Departamento de Computación, bien po-dría tomar más tiempo del que el autor viva para volverse una realidad.

Actualmente, el Departamento de Computación del CINVESTAV-IPN cuenta con 16 investigadores de tiempo completo y 7 investigadores más en el CINVESTAV Tamaulipas. A la fecha ha graduado a más de 280 estudiantes de maestría y doctorado.

En la semana del 1 al 5 de septiembre, se celebraron los 25 años de existencia de los programas de computación en el CINVESTAV-IPN3,

Carlos Artemio Coello Coello se doctoró en Ciencias de la Computación en la Universidad Tulane (en Estados Unidos), en 1996, haciendo trabajo pionero en el área de “optimización evolutiva multi-objetivo”. Actualmente es Investigador 3-D y Jefe del Departamento de Computación del CINVESTAV-IPN. Pertenece al Sistema Nacional de Investigadores (nivel 3) y a la Academia Mexicana de Ciencias.

// INDUSTRIA


• Conciencia de la importancia de estándares.• Falta de recursos humanos informados o capacitados en estándares.• Falta de conocimientos sobre la mejora de procesos y las evaluaciones.

• Desarrollo de software bajo contrato u orden de trabajo.• Prácticas precarias de administración de proyectos y de desarrollo de software. • Desarrollo progresivo y consistente con los requerimientos del cliente.• Un solo canal de comunicación entre el grupo de desarrollo y el cliente.• Productos a desarrollar pueden tener más de una versión y estas deben ser resguardadas y controladas.• Gestión de recursos humanos, infraestructura y del portafolio de proyectos se realiza de manera informal.

• Un cliente por proyecto• Satisfacción del cliente depende de: • Cumplimiento de requerimientos que pueden cambiar durante el proyecto. • Información sobre los avances. • Entregas a tiempo. • Baja tasa de defectos encontrados después de la entrega.

08

Aprovechando Áreas de Procesos de MoProSoft ReUnión del WG24 en México

/*TEJIENDO NUESTRA RED*/// COLUMNA

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

La próxima reunión del grupo de trabajo WG24 del subcomité SC7 del JTC1 ISO/IEC se realizará del 10 al 14 de noviembre de este año en la Ciudad de México en las instalacio-nes de CANIETI. En esta ocasión se revisarán los comentarios, enviados por los países participantes en SC7, sobre la siguiente ver-sión, Proposal Draft, de la ISO/IEC TR 29110 Software Engineering — Lifecycle Profiles for Very Small Enterprises (VSE).

Este documento consta de las siguientes partes:• Part 1. Overview • Part 2. Framework and Taxonomy • Part 3. Assessment Guide • Part 4-1. Specification – Basic Profile • Part 5-1. Management and Engineering Guide – Basic Profile

La primera parte explica por qué se decidió hacer un trabajo especial para acercar los estándares internacionales a organizacio-nes, departamentos o proyectos con me-nos de 25 personas, llamados Very Small Enterprises (VSE).

La parte 2 propone marco y posible taxo-nomía para crear perfiles, subconjuntos de estándares existentes, con la finalidad de satisfacer necesidades específicas de este tipo de organizaciones.

La parte 3 ofrece guía para la aplicación de evaluaciones de los perfiles usando como referencia el estándar ISO/IEC 15504-2.

La parte 4-1 y 5-1 contienen la especificación y la guía de interpretación, respectivamente, del primer perfil definido para VSE, llamado Perfil Básico.

A continuación trataré de contestar breve-mente las siguientes preguntas:

¿A quién está dirigido este perfil? y ¿qué ele-mentos de NMX-I-059-NYCE-2005 MoProSoft se aprovecharon para crearlo?

El Perfil Básico está dirigido a las VSE con las siguientes características:

Para crear la guía de interpretación del Per-fil Básico se aprovecharon los dos procesos de la categoría de operación de MoProSoft, llamados en inglés Project Management y Software Implementation. Se eligieron las actividades, tareas, productos y roles de estos procesos correspondientes a los si-guientes elementos:

Proceso de Administración de Proyectos Específicos (Project Management)• Planificación del proyecto con la identifi-cación y estimación de tareas para un ciclo y su calendarización.

• Monitoreo del avance del proyecto, ac-ciones correctivas y cierre del proyecto con aceptación del cliente.

• Recepción y análisis de las solicitudes de cambio tanto del cliente como del equipo de desarrollo. El análisis considera el im-pacto de cambio sobre los aspectos técni-cos, costo y tiempo. Si el caso lo amerita, se actualiza el plan del proyecto.

• Reuniones de revisión con el equipo de tra-bajo y con el cliente registrando los acuerdos.

• Identificación y registro de riesgos durante el proyecto.

• Identificación de elementos de configura-ción de software, definición y aplicación de

• Fuerte dependencia de ganancias de cada proyecto,• Necesidad de ingreso frecuente de dinero,• Proyectos de bajo presupuesto, bajo riesgo y duración de unos cuantos meses.

Financieras

Aprendizaje y Crecimiento

Relación con el Cliente

Proceso Interno

NOV-ENE 2009www.sg.com.mx 09

la estrategia de control de versiones, res-guardo y recuperación.

• Aseguramiento de calidad de producto y de procesos mediante el cumplimiento de requerimientos y del plan del proyecto.

Proceso del Desarrollo yMantenimiento de Software(Software Implementation)• Realizar tareas acorde al plan del proyecto.

• Definición y análisis de requerimientos, con el fin de asegurar que sean correctos y susceptibles a ser probados, se validan con el cliente, se resguardan como línea base y se comunican a los interesados.

• Se desarrolla el diseño arquitectónico de-tallado y se establece la trazabilidad con los requerimientos.

• Se producen componentes de software de acuerdo al diseño, se les aplican pruebas unitarias para asegurar la consistencia con el diseño y con los requerimientos. Se es-tablece la trazabilidad de los componentes con el diseño y con los requerimientos.

• Se definen pruebas para la integración de los componentes. Se integran los compo-nentes aplicando las pruebas, se registran los defectos y se corrigen.

• Se integra y resguarda la configuración de software con la documentación correspon-diente y los manuales de usuario, operación y mantenimiento.

• Se realizan las actividades de verifica-ción y validación de los productos selec-cionados para asegurar la consistencia entre ellos y la satisfacción del cliente.

Los defectos encontrados quedan registra-dos y corregidos manteniendo el control de versiones y el resguardo correspondiente.

Los que conocen MoProSoft fácilmente iden-tificarán lo que quedó incluido en el Perfil Básico y los que quieren conocerlo a mayor detalle pueden solicitar los documentos al comité de normalización de CANIETI.

Una buena noticia que quiero compartir para finalizar esta entrega es que México cambió el estatus ante el ISO/IEC JTC1 SC7 dejando ser miembro O (Observador) y con-virtiéndose en miembro P (Participante), lo que significa que no solamente podemos emitir comentarios sobre las normas sino que también podemos votar por ellas.

» Por Hanna Oktaba


“Premio Nacional de Calidad”,y La Norma MoProSoftestRateGias de iMPlantación

/*MEJORA CONTINUA*/// COLUMNA

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.

Premio Nuevo León a la Calidad

El mes pasado SOFTTEK ganó el premio Nuevo León de Calidad. Esta es la prime-

ra vez que una empresa de software gana este premio. Me parece que a veces esta-mos dando mucha importancia a certifica-ciones estadounidenses con la finalidad de incrementar nuestras exportaciones pero tal vez estamos menospreciando recursos muy importantes que tenemos en nuestro país.

El Premio Nuevo León de Calidad que se hace disponible en todos los estados de la República y la norma MoProSoft, son op-ciones que tenemos en nuestro país para establecer márgenes de mejora continua en nuestra industria de software.

Mi experiencia es que estos modelos, aun-que no todos están totalmente enfocados al desarrollo de software (MoProsoft sí está ligada directamente al software), se adap-tan bastante bien a las ideas de manejo de procesos, toma de decisiones en base a métricas y mejora continua que son la base de todo modelo de calidad, adicionalmente las normas mexicanas tienden a ser más amplias a diferencia de CMMI. MoProSoft abarca no sólo el desarrollo de Software en sí, sino también temas complementarios como la planeación estratégica y prácticas de ecosistema de la organización. Creo que como industria de software deberíamos in-vestigar más sobre estas normas y buscar como pueden apoyar a nuestras estrategias de calidad.

Estrategias de implantaciónLa semana pasada mientras realizaba una presentación, volvió a surgir la duda de si es mejor hacer implantaciones proyecto por pro-yecto, o si es mejor implementar prácticas in-dividuales en toda la organización (lo que en métodos numéricos se le conoce como “Depth First o Breath First”).

Lo que yo veo en la industria del software en México es que tenemos comprada la idea de que lo más importante es implementar a pro-fundidad un concepto en un proyecto para después pasar al siguiente. En mi opinión esta es la razón principal por la que los pro-yectos de implementación fallan. Implemen-tar a profundidad sólo funciona en organiza-ciones pequeñas, ya que ésta puede hacerse rápido en todos los proyectos, pero en una organización mayor a esto es un fracaso.

Por ejemplo, supongamos que implemen-tamos un modelo para estimar el costo de cambios dentro de los proyectos. Usualmen-te lo que se hace es tomar los proyectos que tienen la mayor cantidad de problemas con el crecimiento de número de requerimien-tos y se asigna el proyecto a la persona que tiene más experiencia en estimar para que haga lo necesario para cambiar la forma en la que se está estimando el cambio. Esta persona maneja la resistencia al cambio, el entendimiento de la problemática del clien-te en especifico, y seguramente después de algo de trabajo se logrará arreglar la situa-ción con ese primer proyecto y estaremos listos para continuar al siguiente.

Desafortunadamente, los demás líderes de proyecto se sienten atacados por el éxito descrito anteriormente, y se dedican a ar-gumentar que su proyecto es muy diferente y por lo tanto estas prácticas no son aplica-bles a su proyecto.

Mientras esto sucede, nuestro proyecto ini-cial termina y nuestro experto en estimación es reasignado como analista en un proyecto dirigido por otra persona, por lo que ya no tiene el control, y tampoco tiene la habilidad de convencer al líder actual de cómo mane-jar la estimación. Esto hace que se pierda el trabajo y finalmente lo que tenemos es a un experto constantemente asignándose a

proyectos en problemas y tratando de sacar adelante la situación.

La otra forma de implementar esto mismo sería: generar un curso del nuevo modelo de estimación, y entrenar a todos los líderes de proyecto. Después se auditan los proyectos para evaluar quien implementó qué, y se crea una estrategia en donde el experto en estimación salta de proyecto en proyecto asesorando a los líderes para que cada vez apliquen mejor el proceso de estimación.

Como primer paso, logramos que todos en-tiendan que la estimación se logra en base a definir tamaños de los productos, que entien-dan cómo calcular líneas de código o puntos funcionales en sus proyectos. Después que entiendan como pasar de líneas funcionales a horas, y así sucesivamente.

Esta estrategia ofrece las siguientes ventajas:

1. Nuestro experto en estimación invierte un tiempo muy parecido al anterior, pero ahora ayudando y convenciendo más que haciendo él mismo.

2. Permite que la responsabilidad de la esti-mación recaiga en donde tienen que recaer, el líder del proyecto.

3. No se esta detrás de los problemas todo el tiempo. Cuando un líder sale de un proyecto y pasa a otro, el otro líder está más o menos en el mismo nivel que estaba él en su proyecto, por lo que permite que hablen el mismo idioma y que pueda aplicar lo que aprendió en su pro-yecto anterior para mejorar el nuevo proyecto.

A final de cuentas vamos pasando de un mo-delo reactivo a un modelo pasivo. ¿Qué nos acerca mas a nuestro objetivo?.

» Por Luis Cuellar


/* LO QUE VIENE*/// PRODUCTOS

VSTS 2010n U e Va s c a Pa c i d a d e s d e M o d e l a d o y t e s t i n G

Microsoft dió a conocer los planes para la próxima generación de sus herramientas y plataforma de de-sarrollo: Visual Studio 2010 y .NET 4.0. Como parte de esta plataforma también habrá una nueva versión de la herramienta para la colaboración de equipos de trabajo, Visual Studio Team System (VSTS) 2010. Las innovaciones en VSTS 2010 se enfocan principalmente en mejorar las capacidades para el modelado visual y la administración de pruebas de software. Las nuevas capacidades de modelado en VSTS 2010 son un compo-nente central de la iniciativa de modelado de Microsoft, conocida con el nombre clave “Oslo”.

La información que ha liberado Microsoft hasta el momen-to es bastante vaga, y se espera que el panorama quede más claro después de la conferencia de desarrolladores (PDC 2008) que se realizará a finales de octubre.

Más información en msdn.microsoft.com

Mono 2.0 y a l l e G ó s U P e R c h a n G o

Mono 2.0 por fin fue liberado. Mono es una im-plementación en software libre del Framework .NET de Microsoft. A pesar de que todavía le falta bastante para cubrir todo el espectro de APIs de .NET, con esta versión ya se soportan los componentes de mayor relevancia y que utilizan el grueso de las aplicaciones.

Entre los APIs soportados por Mono 2.0 resaltan ADO.NET 2.0, ASP.NET 2.0, Windows.Forms 2.0, System.XML 2.0, System.Core (LINQ), y System.Drawing 2.0.

En el área del compilador, la capacidad de mayor importancia en esta versión es el so-porte completo de C# 3.0, incluyendo LINQ to Objects, y LINQ to XML.

Mono funciona en una gran variedad de plata-formas que van desde las tradicionales como Windows, Linux y OS X, hasta el iPhone y el Nintendo Wii.

Más información en www.mono-project.com

Beehiveo R a c l e s e U n e a l W e b 2.0 e M P R e s a R i a l

Durante el reciente Oracle OpenWorld, uno de los nuevos productos que recibió mayor atención fue Oracle Beehive. Beehive es una plataforma integrada para colaboración empresarial. Esencialmente, es una plataforma que busca integrar espacios de trabajo colaborativos, calendarios, mensajería instantánea y correo electrónico.

A pesar de que en el mercado ya existen productos empresariales con funcionalidad muy similar, tales como Lotus Connections y Microsoft Sharepoint, Oracle argumenta que su producto brinda ventajas en cuanto a seguridad e integración con productos de terceros. Aun así, seguramente lo que estaremos viendo es que las empresas optarán por una u otra solución dependiendo del resto de la infraestructura que ya tengan. Aquellos clientes que ya estén usando el middleware de Oracle, seguramente se sentirán más cómodos con Beehive que con las opciones competidoras.

Más información en www.oracle.com/products/middleware/beehive


Beneficios de la Automatización de Pruebas ahoRRando tieMPo y RecURsos

Por Benjamín Alonso

14

/*hERRAMIENTAS*/// PRODUCTOS

Benjamín Ruvalcaba Alonso tiene más de 18 años de experiencia en proyectos de informática. Ha trabajado en Microsoft, GE, y otras empresas públicas y privadas. Ha dedicado los últimos seis años al testing de diversas aplicaciones web en ambientes .Net. Puedes contactarlo en [email protected]

¿Cómo sabes que el sistema funciona? Una respuesta común a esta pregunta es “porque el equipo de testing le echó un vistazo”. El problema viene al tener que determinar la extensión y profun-didad de las pruebas realizadas. Si eres afortunado y trabajas en una empresa con buenos procesos, podrás acreditar lo probado a través de una lista de casos de prueba. Si trabajas en una empresa de clase mundial, entonces hay una gran posibilidad de que tengas la fortuna de tener a tu disposición herramientas para la gestión y automatización de pruebas.

De acuerdo con Elfriede Dustin, las herramientas de automatización de pruebas consolidan y mejoran la efectividad de las pruebas siem-pre y cuando se manejen las expectativas, se entiendan las herra-mientas, y se seleccione una herramienta compatible con el ambien-te de programación. Si necesitas probar un sistema no trivial que conste de algo más que unas cuantas pantallas y reportes, enton-ces es muy posible que por medio de pruebas manuales no logres realizar todas las pruebas que necesitas para verificar la calidad del sistema. Con la ayuda de herramientas de automatización puedes ejecutar más pruebas, lo cual se traduce en una mayor cobertura del sistema que se está probando.

Capers Jones, en su libro de estimación de costos de software, men-ciona que las pruebas de funcionalidad, regresión y rendimiento son comúnmente apresuradas (o incluso omitidas) por presiones de tiempo. Esto resulta en sistemas con baja calidad. ¿Alguna vez te has visto en la necesidad de apurar u omitir alguna de estas prue-bas? ¡Por supuesto que sí! Es una práctica común en los proyectos de desarrollo.

Las compañías más exitosas automatizan sus pruebas para mejorar la flexibilidad de su equipo de desarrollo. Algunas de las metas de sus esfuerzos incluyen:• Detectar cambios desestabilizadores en nuevas construcciones del sistema.• Exponer defectos de regresión tan pronto como es posible.• Reportar problemas rápidamente porque esto facilita su corrección.

Beneficios de las pruebas automatizadasLas herramientas de automatización no van a solucionar todos tus problemas de pruebas. Sin embargo, puedes obtener muchos bene-ficios con una implementación apropiada. Hablemos de algunos de estos beneficios:

• Mejor organización de las pruebas. Cuando inicias la automatiza-ción de tus pruebas, analizas de manera más estructurada. Exami-nas tu sistema como ingeniero, ya no de manera empírica. Al crear casos de pruebas formulas preguntas tales como: ¿es repetible esta prueba?, ¿con qué frecuencia necesito ejecutar esta prueba?, ¿tiene alguna semejanza esta prueba a pruebas existentes?, ¿cómo auto-matizaría esta prueba?

• Realización de un mayor número de pruebas. Algunos de los pro-blemas hallados por la automatización, tal vez no hubieran sido encontrados utilizando solo pruebas manuales, debido a limitan-tes de tiempo.

• Mejoras en la comunicación con el equipo. Kaner, Bach, y Petti-chord argumentan que la automatización fortalece las pruebas al proporcionar un sistema para recolectar y diseminar información de manera eficaz, proporcionando retroalimentación oportuna al equi-po de programación.

• Estabilización temprana del código. Conforme encontremos los errores más temprano, tendremos más rápido una base de código estable. Esto evitará retrabajo posterior ya que no estaremos cons-truyendo encima de un código con errores.

• Habilitación de pruebas de regresión. Con un conjunto apropia-do de pruebas, y habilitados por una herramienta de automatiza-ción, cada que generamos un nuevo build de nuestro sistema de software podemos probarlo por completo. Esto es de vital impor-tancia, ya que de acuerdo con un estudio realizado por Capers Jo-nes, en promedio el 7% de las correcciones de defectos inyectan a su vez un nuevo defecto.


“¿Alguna vez te has visto en la necesidad de apurar u omitir alguna de estas pruebas?

¡Por supuesto que sí!”.

De hecho, Dustin argumenta que si las pruebas de regresión no es-tuvieran automatizadas, ciertas pruebas regresivas nunca serían ejecutadas, dejando grandes vacíos en los esfuerzos de prueba.

• Mayor confiabilidad en los resultados. El sistema de automa-tización no se cansa, nunca tiene prisa, y mientras las pruebas o su información no cambie, deben de obtener siempre el mismo resultado; son consistentes, confiables, y repetibles. Como seres humanos te cansas, preocupas, o simplemente apresuras en sacar tu trabajo a tiempo. Todo esto lleva a simples errores humanos que afectan tu capacidad de ser eficiente en pruebas rutinarias. La au-tomatización de pruebas repetitivas que requieren una ejecución frecuente, te permite tiempo para integrar pruebas más comple-jas, probar nuevas funciones dentro de la aplicación y su integra-ción con el resto del sistema.

• Capacidad para aplicar pruebas complicadas. Algunos tipos de prueba son difíciles de aplicar o muy complicadas de ejecutar de manera manual; entre esta rama podemos encontrar aquellas en las que es necesario el acceso a la base de datos para verificar que la información del sistema sea correcta, o tal vez sea preciso hacer cálculos manuales para verificar la validez de los resultados arrojados por el sistema. Muchas herramientas de automatización proporcionan estas funcionalidades. Además, los sistemas de au-tomatización nos pueden auxiliar a introducir grandes cantidades de información, configurar la versión de prueba de la base de da-tos, y generar información aleatoria entre otras cosas.

Como No Justificar el TestingDespués de revisar los principales beneficios de la utilización de herramientas de pruebas automatizadas, quiero compartir con uste-des algunas recomendaciones planteadas por James Bullock acerca de lo que debemos evitar a toda costa al justificar un esfuerzo de testing hacia nuestros superiores.

• La narrativa sin fin. Una cosa es hacerle ver a nuestros superiores que sabemos de lo que estamos hablando, y otra es perderlos en los detalles técnicos. Lo que tus jefes quieren que les contestes es ¿cuánto?, ¿cómo?, y ¿dónde?; Debes estar preparado para contestar estas preguntas en forma abreviada, concreta, y veraz.

• Vender funcionalidades en lugar de beneficios. Cuando hablamos de testing se nos olvida mencionar cómo beneficia al cliente, pro-ducto, o empresa. Tendemos a hablar de todo lo que vamos a poder hacer sin mencionar los beneficios. No importa lo avanzada que sea la herramienta de automatización o ese nuevo proceso manual que deseas implementar, si no puedes ligarlo a beneficios tangibles. Ne-cesitas identificar que el testing, ya sea automatizado o no, sí bene-ficia al cliente, producto o empresa.

• La solución única. A algunos de nosotros nos gusta pensar que nuestra función es la más importante en la compañía. Sin embar-go, tenemos que observar nuestro trabajo como una pieza más en el ecosistema de la empresa. Esto nos facilita analizar cómo nuestra labor complementa y asiste a otras áreas. Somos más va-liosos como parte integral de la empresa que como un elemento aislado de la misma.

ConclusiónHoy en día, la automatización de pruebas es una tarea esen-cial para proporcionar un servicio de testing adecuado. Los sistemas que probamos han crecido tanto en tamaño como en complejidad. Necesitamos tener el tiempo de probar las nuevas funcionalidades de nuestros sistemas sin ignorar la funcionalidad previa. Una estrategia de automatización imple-mentada apropiadamente nos ayudará a lograrlo junto con los demás beneficios mencionados en este artículo.

Referencias [ Bullock, James. “Calculating the Value of Testing”. Software Testing and Quality Engineering. May/June 2000 ][ Jones, Capers. Estimating Software Costs: Bringing Realism to Estimating. McGraw Hill, 2007. ][ Dustin, Elfriede. Effective Software Testing: 50 Specific Ways to Improve Your Testing. Addison-Wesley, 2002.][ Kaner, Cem; Bach, James; Pettichord, Bret. Lessons Learned in Software Testing: A Context Driven Approach. Wiley, 2001.]


Desarrollo de Aplicaciones Silverlight PaRte 2. eVentos desde xaMl y JaVascRiPt

Por Guillermo Morales

16

/*TUTORIAL*/// PRODUCTOS

Guillermo Morales colabora actualmente en InterSoftware, empresa dedicada a la capacitación especializada en desarrollo de software. Con un perfil técnico, se ha desenvuelto en varias áreas del proceso de desarrollo de aplicaciones, desde la implementación, hasta la administración de proyectos. Es cofundador de la comunidad de desarrollo en México www.developersdotnet.com en donde frecuentemente se reúne con otros expertos de desarrollo de aplicaciones para la difusión de nuevas tecnologías.

Respondiendo al click del mouseVamos a crear un elemento que pueda responder a eventos del mouse, para comenzar a darle más interacción a nuestros sitios Silverlight.

La forma y el concepto son muy sencillos: en el XAML se declaran los eventos que queremos estar observando, y se indica la función de Ja-vascript que debe dispararse con cada evento. Dichas funciones de Javascript las podemos definir en el archivo HTML o en un archivo .js.

Veamos como se implementa esto en código. Primero, modificare-mos nuestro archivo XAML para que quede como el listado 1.

Listado 1. mixaml.xaml<Canvas Width=”300” Height=”300” xmlns=”http://schemas.microsoft.com/client/2007” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”>

<Canvas.Background> <LinearGradientBrush EndPoint=”0.5,1” StartPoint=”0.5,0”> <GradientStop Color=”#FFDCEF1B” Offset=”0”/> <GradientStop Color=”#FF801A1A” Offset=”1”/> </LinearGradientBrush></Canvas.Background>

<Rectangle x:Name=”r1” MouseEnter=”r1Entrar” MouseLeave=”r1Salir” MouseLeftButtonDown=”r1Abajo” MouseLeftButtonUp=”r1Arriba”

Bienvenidos a esta segunda parte de nuestro tutorial sobre desarrollo de aplicaciones Silverlight.

En base a lo que hicimos en la parte 1 (SG Num. 21), debería-mos tener los siguientes archivos:

• crearSilverlight.js• Default.html• Mixaml.xaml• Silverlight.js

Height=”100” Width=”100” Canvas.Left=”100” Canvas.Top=”50” Stroke=”Black” StrokeThickness=”10” Fill=”Blue”/>

<TextBlock x:Name=”miTexto” Canvas.Left=”70” Canvas.Top=”180” Text=”Dame Click” FontSize=”30”/></Canvas>

Noten que tanto el TextBlock como el Rectangle, tienen una propiedad x:Name por medio de la cual podemos identificar a cada elemento den-tro del XAML. Utilizaremos esto más adelante en el código Javascript.

Al visualizar nuestra página web, obtendremos lo que se ve en la siguiente figura.

Insertando código javascriptEl siguiente paso es definir las funciones de Javascript que respon-dan a los eventos que se disparan desde el XAML. Para esto, inser-taremos en nuestra página web el código Javascript del listado 2. Este código lo pueden insertar dentro del mismo bloque de código <script> donde se encuentra la obtención de la referencia al plugin de Silverlight que ya se tiene.

Listado 2. Funciones en Javascriptfunction r1Entrar(sender, args) {sender.stroke = “red”;sender.findName(“miTexto”).Text = “Rojo”;}


“Crearemos un elemento que puedaresponder a eventos del mouse, paracomenzar a darle más interacción a

nuestros sitios Silverlight”.

function r1Salir(sender, args) {sender.stroke = “black”;sender.findName(“miTexto”).Text = “Negro”;}function r1Abajo(sender, args) {sender.stroke = “yellow”;sender.findName(“miTexto”).Text = “Diste Click”;}function r1Arriba(sender, args) {sender.stroke = “Green”;sender.findName(“miTexto”).Text = “Verde”;}

En este código podemos observar dos cosas:• Los eventos disparados desde el XAML, reciben dos parámetros:

- sender: Corresponde al objeto que inicia la acción- args: Corresponde a información relacionada al evento disparado

• Mediante el método findName localizamos a elementos específicos dentro del XAML, en este caso, el objeto que estamos localizando y manipulando es el Rectángulo al cual nombramos “miTexto”.

Con esto tenemos una página cuyos elementos XAML disparan even-tos en javascript.

ConclusiónYa tenemos una página cuyos elementos XAML responden al com-portamiento del mouse y disparan funciones javascript.En futu-ros artículos incluiremos una animación, un video y más eventos para atraparlos con el mouse. Suerte, y hasta la próxima.


Ha llegado ese momento del año en que echamos un vistazo a la compensación

que recibimos por nuestro trabajo y evaluamos qué tan justa es la compensación

que recibimos, y cuales son las habilidades o características que debemos desa-

rrollar para aspirar a un mejor salario. Sin más preámbulo, compartimos con

ustedes los resultados de la Encuesta de Salarios SG 2008.

Encuesta de Salarios 2008Por Pedro Galván

Salarios a primera vistaPrimero, lo primero. Y eso es averiguar como están actualmente los sala-rios de profesionistas de tecnologías de información en México.

La tabla 1 muestra el tabulador de salarios por rangos, indicando el por-centaje de personas que caen en cada uno.

Acerca de la fuente de informaciónLa información que se muestra aquí es resultado de una encuesta abierta contestada por 2,162 personas a través del sitio web de SG durante el mes de octubre del 2008.

Rango de salario mensual

Menos de 4 mil 66 3.15%

4 a 6 mil 103 4.92%

7 a 10 mil 296 14.14%

11 a 15 mil 354 16.91%

16 a 20 mil 351 16.77%

21 a 25 mil 278 13.28%

26 a 30 mil 214 10.22%

31 a 40 mil 199 9.51%

41 a 50 mil 97 4.63%

51 a 60 mil 48 2.29%

61 a 80 mil 44 2.10%

Más de 80 mil 43 2.05%

Tabla 1. Tabuladores de salario mensual


Encuesta de Salarios 2008

El promedio ponderado de estos valores nos indica que el salario promedio de un profe-sionista de TI en México es de $22,570 pesos mensuales. Este valor significa un aumento de 13% comparado con el valor obtenido en el 2007, de $19,946. Habría que comparar esto con la inflación real en este periodo de tiempo para determinar si hubo un aumen-to real en el salario o si simplemente fue un ajuste inflacionario.

Remuneración adicionalAunque el principal componente de la com-pensación laboral es el salario, otro elemen-to muy importante son las remuneraciones adicionales. La tabla 2 es un tabulador del valor al que ascienden las prestaciones re-cibidas anualmente, tales como aguinaldo, bonos, reparto de utilidades, etc.

Rango de compensación extra anual

Ninguna 21%

Menos de 10 mil 20%

De 10 a 25 mil 27%

De 25 a 50 mil 16%

De 50 a 100 mil 9%

Más de 100 mil 6%

Prestación %

Estado Salario %

Tabla 2. Tabulador de compensación extra anual

PrestacionesComo elemento final de la compensación tenemos a las prestaciones. La tabla 3 indi-ca las prestaciones más comunes, y el por-

centaje de los encuestados que recibe cada una. Estos valores son prácticamente igua-les a los de hace un año.

Gastos médicos mayores 44.7%

Horario flexible 36.5%

Préstamos 33.1%

Bonos por desempeño 29.5%

Gastos médicos menores 22.2%

Teléfono celular 19.2%

Trabajo desde casa 13.5%

Ayuda para educación 12.1%

Automóvil 7.2%

Ayuda familiar 6.5%

Departamento 6.1%

Acciones (stock options) 4.5%

Tabla 3. Prestaciones recibidas

De acuerdo a la regiónEl DF recuperó su liderazgo en este año como el estado de la República con los mejo-res sueldos para profesionistas de software, dejando a Nuevo León en segundo lugar y al Estado de México en tercero. Como es de esperarse, estos estados son también los que emplean a un mayor porcentaje de los profesionistas de software en nuestro país.

En la no muy honrosa lista de los estados con los sueldos más bajos tenemos a Tlax-cala, Colima, Chiapas, Oaxaca y Veracruz.

Como es costumbre, varios colegas inter-nacionales (o expatriados) nos hicieron favor de contestar la encuesta. Mostramos el listado de aquellos países de los que ob-tuvimos un mínimo de 10 respuestas. Otros países fueron descartados por tener una muestra de respuestas demasiado pequeña como para ser confiable.

DF 28,899 35.2%

NL 25,885 8.3%

Edomex 22,232 9.7%

Querétaro 21,031 4.5%

Jalisco 19,842 8.7%

Tabla 4. Estados con salarios más altos


País Salario

2020

Tabla 5. Estados con salarios más bajos

Estado Salario %

Tlaxcala 9,667 0.7%

Colima 11,273 0.5%

Chiapas 11,632 0.9%

Oaxaca 11,708 0.6%

Veracruz 12,127 2.9%

USA 64,588

España 41,000

Perú 20,938

Chile 20,333

Colombia 12,600

Argentina 9,667

Tabla 6. Resultados de otros países

Tipo de organizaciónLa tabla 7 divide las respuestas obtenidas a partir del tipo de organización donde laboran. El patrón es el mismo que hemos encontrado en años anteriores. Las empresas proveedo-ras de servicios de TI son las que ofrecen los mejores salarios (aunque ofrecen prestacio-nes muy bajas, mientras que las áreas usua-rios son las que ofrecen la compensación to-tal (salario mas prestaciones) más alta.

Aunque la mayoría de los profesionistas de TI todavía laboran en áreas usuarias, poco a poco va aumentando el porcentaje que la-bora en empresas proveedoras. Esto es una consecuencia natural de la tercerización de los servicios de TI.

Un punto que llama la atención sobre los re-sultados de este año es el salario promedio en los ISV. Estas son las empresas que se dedican a desarrollar productos de software propios para posteriormente comercializar-

los. En países desarrollados, estas empresas son las que ofrecen los salarios más altos, ya que son las que tienen mayor necesidad de talento e innovación. Sin embargo, en nuestro país parece ser todo lo contrario.

En la tabla 8 mostramos un cruce entre el tipo de organización y el esquema de pago maneja-do (nómina, honorarios o externo subcontratado). Como era de esperarse, las áreas usuarias son las que tienen un porcentaje mayor de personas en esquema de nómina, con casi el 85% de su personal. En cambio, las empresas proveedoras de servicios tienen solamente un 48% en nómina y el resto están por honorarios o contratados como independientes.

Tabla 8. Relación entre tipo de organización y esquema de pago

GéneroComo podemos ver en la tabla 9, la participación del sexo femenino en nuestra profesión sigue siendo muy baja, y con un salario significativamente menor. La diferencia de salario es del 33%, la cual es prácticamente igual que la estimada el año anterior (33%).

Tipo Salario Prestaciones %

Tipo Nómina Honorarios Externo

Proveedor de servicios 25,122.48 1,680.30 28.5%

Area de sistemas 23,102.14 2,600.71 44.7%

Distribuidor de producto de TI 21,986.11 2,708.33 1.7%

Otra organización 20,314.01 2,155.80 9.9%Desarrollo de productos empaquetados 19,906.25 1,625.24 8.4%

Educación/Capacitación 15,150.35 1,739.51 6.8%

Tabla 7. Salarios y prestaciones por tipo de organización

Proveedor de servicios 48.0% 40.0% 12.0%

Área usuaria 84.5% 13.1% 2.4%

Distribuidor/Canal 67.7% 29.4% 2.9%

ISV 70.4% 19.5% 10.1%

Educación 80.8% 16.1% 3.1%

Tabla 9. Salario por género

Genero Salario %

Femenino 17,513.25 14.4%

Masculino 23,423.23 85.6%

Edad y ExperienciaTal como lo hemos visto en las encuestas de años anteriores, el salario de un profesionista de TI sube paulatinamente de acuerdo a su edad, y llega a un máximo entre las personas que tienen 50 a 59 años. Posteriormente baja drásticamente después de los 60.


Como es de esperarse, el comportamiento respecto a los años de experiencia es simi-lar, tal como se puede apreciar en la tabla 11. Analizando esta tabla, vemos que le hacen falta más escalas después de los 10 años de experiencia, para poder analizar a este seg-mento en mayor detalle. Haremos ese ajuste para la próxima encuesta de salarios.

Tabla 10. Salarios de acuerdo a la edad

Estado Salario %

Estado Salario %

18 a 24 11,410 14.6%

25 a 29 17,378 31.9%

30 a 39 25,563 40.5%

40 a 49 37,166 10.4%

50 a 59 46,276 2.3%

60 o mas 27,143 0.3%

De acuerdo al tipo de trabajoComo sabemos, existe una gran cantidad de perfiles y tipos de trabajo en nuestra profesión. Obviamente, unos son mejor pagados que otros. Como es de esperarse, los directores son los mejor pagados, pero veamos como se compara el sueldo para el resto de las funciones.

Hay que resaltar que en comparación con los resultados del año anterior, el único perfil cuyo salario promedio no aumentó es el de webmaster. Y si tomamos en cuenta la infla-ción, nos daremos cuenta que la compensa-ción real disminuyó. Tal parece que conforme las herramientas han hecho más fácil la insta-lación y administración de sitios web, hay más personas que pueden hacer esta actividad y por lo tanto este perfil se ha devaluado.

Menos de un año 10,328 6.4%

1 a 3 12,746 20.8%

3 a 5 17,706 17.1%

5 a 10 23,304 25.0%

Mas de 10 33,871 30.7%

Tabla 11. Salarios de acuerdo a la experiencia

Tabla 12. Salarios por función

EscolaridadEl máximo grado de estudios completado brinda un fiel reflejo de la compensación a la que se puede aspirar. En esta ocasión, nos llama la atención el hecho de que la compensación de quienes tienen maestría quedó por debajo de quienes solamente tienen otro tipo de postgrado (como un diplomado) que requiere menos dedicación. La explicación pudiera estar en que este tipo de postgrados normalmente están más apegados a las actividades reales que se realizan en el trabajo, y por lo tanto es más fácil aplicar los conocimientos adquiridos. Adicionalmente, al requerir menos esfuerzo, permiten que las personas no se tengan que despegar tanto de su trabajo y por lo tanto no afectan tanto su ritmo de crecimiento profesional.

Función Salario %

Alta Dirección 45,263.9 3.4%

Dirección de sistemas 41,892.9 4.7%

Ventas 30,902.4 2.0%

Arquitecto 28,754.5 5.4%

Project Manager 27,498.4 14.9%

Consultor 23,553.9 8.0%

Seguridad 23,404.8 1.0%

Administrador de sistemas 21,450.8 6.3%

TI en General 21,351.4 6.6%

DBA 17,800.0 2.6%

Aseguramiento de Calidad 17,449.4 3.8%

Desarrollador 17,256.9 31.2%

Soporte 14,884.6 3.7%

Redes 13,939.4 1.6%

Docente 13,710.5 2.7%

Webmaster 12,913.0 2.2%

Tabla 13. Salario por grado de estudios terminado

Escolaridad Salario %

Doctorado 40,523 1.1%

Postgrado 31,201 6.1%

Maestria 29,827 16.2%

Universidad titulado 21,853 46.3%

Universidad sin titular 17,552 27.5%

Bachillerato 16,848 2.8%

Conocimientos y habilidadesLos profesionistas de software nos enorgullecemos principalmente por nuestros conocimientos técnicos, y sabemos que estos tienen un gran impacto en el salario al que podemos aspirar.

En términos de estos conocimientos, el patrón se mantiene respecto a años anteriores. Co-bol y Mainframe siguen siendo el lenguaje y plataforma mejor pagados.


Tabla 14b. Plataformas

Lenguaje Salario %

Plataforma Salario %

Base de Datos Salario %

Aplicación Salario %

Cobol 30,909 3.9%

.Net 27,827 20.7%

JEE 26,577 26.7%

Flex 26,000 3.2%

Perl 24,719 4.7%

JME 23,928 4.3%

JSE 23,639 32.5%

ASP 23,256 25.5%

C 23,039 17.8%

VB 20,432 34.1%

Delphi 19,807 7.7%

Php 18,530 23.6%

Tabla 14a. Lenguajes de programación

Mainframe 33,454 4.7%

Unix 28,607 27.8%

AS400 27,898 5.6%

Windows Mobile 25,907 10.3%

Windows 22,423 90.0%

Mac 22,212 7.2%

Linux 21,777 36.0%

DOS 21,300 12.8%

CertificacionesLa mejor forma de demostrar nuestros co-nocimientos sobre alguna práctica o tec-nología específica es una certificación. La certificación reina sigue siendo la de Project Management Professional (PMP) del PMI. Por otro lado, la gran demanda de consultores de SAP que ha habido en los últimos años ha provocado que esta certificación aumente su valor significativamente, ya que de tener un sueldo promedio hace un año de poco más de 30 mil pesos, este año supera los 40 mil. Otra certificación que también se está codiciando bastante es la de Microsoft Systems Engineer, cuyo sueldo promedio aumentó más de 10 mil pesos respecto al año pasado.

DB2 29,251 13.5%

Informix 27,965 8.8%

Sybase 27,342 6.5%

Oracle 26,217 39.3%

SQL Server 23,140 59.8%

PostgreSQL 20,656 9.8%

MySQL 20,025 38.9%

Firebird 19,015 3.2%

Tabla 14c. Bases de datos

BPM 35,922 7.9%

BI 28,978 24.6%

CRM 28,734 14.5%

ERP 24,483 52.3%

Tabla 14d. Aplicaciones empresariales

Otras habilidades Salario %

EDI 29,022 3.3%

PM 28,045 51.0%

Procesos 26,431 35.7%

Test 26,294 24.6%

UML 22,970 44.9%

Redes 20,234 27.4%

Diseño Gráfico 18,150 19.1%

Tabla 14e. Otras habilidades

ConclusiónLos salarios de los profesionistas de TI aumentaron alrededor de un 13% del 2007 al 2008. Las posiciones de mayor complejidad administrativa tales como la alta dirección, la gerencia de proyectos y las ventas son las que acaparan los mayores sueldos. La excepción es el perfil de arquitecto de sistemas, el cual es netamente técnico y alcanza a manejar un salario mayor que el de un gerente de proyectos.

En el caso de los conocimientos técnicos y certificaciones, Cobol sobre Mainframe se man-tiene como la que es mejor compensada, debido a la escasez de personal. .Net y Java EE se mantienen como opciones bien compensadas ya que la cantidad de personal calificado disponible no es suficiente para la demanda del mercado.

Para el 2009, el panorama económico actual nos hace pensar que los salarios no recibirán un ajuste más allá de la inflación. La recomendación es mantenerse en su empleo actual y apro-vechar el año para desarrollar sus habilidades y conocimientos, con miras a que las cosas mejoren hacia final de año. Hay que ser cautelosos pero tampoco es para alarmarse, ya que la demanda existente de profesionistas de TI asegura que cualquier persona con dominio de inglés y capacidad para desarrollar software tenga un empleo estable.

Certificación Salario %

PMP 43,215 5.5%

SAP 40,826 2.1%Microsoft - Systems Engineer 40,794 1.6%

Seguridad 38,000 1.6%

Sun - Solaris 37,048 1.0%

OMG - UML 35,929 1.3%

Oracle 35,577 3.1%

IBM - DB2 35,405 1.0%

Calidad - SQA 35,023 2.1%

IBM - Rational 34,229 1.2%

Microsoft - DBA 31,000 1.4%Ingeniería de software (SEI) 29,429 3.7%Microsoft - Solution Developer 28,039 3.1%

Sun - Java 27,981 7.7%Microsoft - Professional 26,418 7.0%

Linux 25,900 2.9%

Tabla 15f. Salario por Certificaciones


Recuerdo perfectamente cuando en un congreso internacional de Recursos Humanos, uno de los ponentes preguntó cuantos directo-res generales había presentes entre la audiencia, y menos de cinco manos se levantaron entre cientos de participantes. ¿No sería im-portante que los directores generales conocieran las mejores prácti-cas para la gestión de recursos humanos? ¿No les interesará conocer el impacto que tienen estas prácticas en la rentabilidad del negocio? En un estudio realizado por Hay Group entre empresas del Fortune 500 se detectaron las 7 mejores prácticas comunes entre estas em-presas, y resultó que 3 de estas prácticas están directamente rela-cionadas con el factor humano.

GE, Toyota, Berkshire Hathaway, Nokia, y BMW son algunas de las or-ganizaciones que encabezan este ranking, y son de las empresas más admiradas del planeta. Entre 2004 y 2007, por ejemplo, brindaron a sus accionistas una rentabilidad media de 19,6 por ciento, casi el tri-ple que el 7,1 por ciento del ranking de Standard & Poor’s para el mis-mo período. ¿Qué han hecho para llegar (y mantenerse) en la cima? ¿Cuáles son los factores que explican el desempeño sobresaliente?

A continuación doy una breve descripción de las prácticas de RH co-munes entre estas organizaciones: 1. El éxito a través de las personas. Probablemente, el factor más importante que distingue a estas empresas es un enfoque para lo-grar el éxito a través de la gente. Los líderes de estas organizaciones dedican el 30 por ciento de su tiempo a desarrollar talento y entre-nar al personal. Estas compañías son más proclives a implementar estrategias y métricas relacionadas con el cuidado del capital hu-mano. Suelen tener planes de sucesión bien definidos y contratar al CEO dentro de la organización. Como expresó Jack Welch, ex CEO de GE: “Mi trabajo principal era desarrollar talento. Era un jardinero que proveía agua y otros nu-trientes a nuestras mejores 750 personas. Por supuesto, también tuve que eliminar algunas malas hierbas”. 2. Fuerte cultura organizacional. La cultura organizacional repre-senta, en general, la forma en que se hacen las cosas y los valo-res que guían la conducta de los miembros de la compañía. En las empresas más admiradas, los líderes suelen compartir una visión común sobre la cultura actual y cómo debería ser en el futuro. Esta cultura tiende a promover la iniciativa individual y el trabajo en equipo, impulsando la innovación y la lealtad de los empleados. 3. Profundo compromiso del empleado. El entusiasmo por el trabajo y la alineación con el éxito organizacional son particularmente im-

portantes en tiempos de inseguridad económica. Y, precisamente, las empresas más admiradas son más exitosas en mantener altos ni-veles de lealtad y motivación en tiempos difíciles. Una de las claves es asegurar que las oportunidades de ascenso y crecimiento perso-nal estén disponibles para todos, sin importar cuál sea el contexto económico.

Las Mejores en MéxicoHace unos meses, Great Place To Work Institute publicó los resulta-dos de su estudio para determinar cuales eran las mejores empresas para trabajar en México.

En el área de Tecnologías de Información y Telecomunicaciones, la lista de las mejores empresas en México para trabajar en el 2008 de acuerdo con Great Place To Work es la siguiente:

1. Compusoluciones 2. IBM 3. Nokia 4. Compac5. EADS 6. Everis 7. Ingram Micro 8. Microsoft 9. NCR 10. Nextel 11. Perot System 12. Pink Elephant 13. Progress Software 14. Sabre 15. Telefónica Movistar

Creo que hay que reconocer y aprender del esfuerzo que estas em-presas hacen al interior y exterior de sus organizaciones, al crear un ambiente óptimo donde los colaboradores se pueden sentir re-conocidos, valorados, recompensados para desarrollar al máximo su potencial humano y profesional. Dichas empresas desarrollan estrategias que van más allá de retener y desarrollar a su personal. Adicionalmente cuentan con el apoyo y compromiso por parte de la dirección o presidencia de la empresa junto con el área de RH para crear este tipo de cultura organizacional con enfoque centrado en el colaborador.

Referencias[ greatplacetowork.com.mx ][ materiabiz.com ]

Las Mejores Empresas para Trabajar PRácticas de Rh qUe lleVan al éxitoPor Emmanuel Olvera

Emmanuel Olvera Avendaño es responsable del área de Reclutamiento y Selección en Resource IT de México. Ha colaborado por más de 4 años en el área de Recursos Humanos en varias empresas de Tecnologías de la Información en México. Es egresado de la Maestría en Desarrollo Humano por la Universidad de Celaya. http://eolvera.blogspot.com


// ENTREVISTA

Tom DeMarco es uno de los decanos de nuestra profesión. Fue reconocido en 1986 con el premio Warnier por su “contribución vitalicia al campo de la computación”, y en 1999 con el premio Stevens por su “contribución a los métodos de desarrollo de software”. Es autor de algunos de los libros más reconocidos en la gestión de proyectos de software, tales como “Peopleware”, “The Deadline”, y “Waltzing with Bears”.

Actualmente, Tom es socio distinguido en Cutter Consortium. Se dedica a dar consultoría estratégica en TI, y rea-liza actividades de investigación en el litigio de proyectos. Tom estuvo en México durante el Cutter Summit en el mes de octubre, y tuvimos oportunidad de platicar con él.


¿Qué haces en el litigio de proyectos?La litigación se da cuando fracasa un proyec-to subcontratado. Entonces, se trae a un ter-cero (como yo) para investigar qué salió mal en el proyecto, y si las fallas corresponden al cliente o al proveedor. Esto puede parecer poco atractivo, pero para mi es fascinante porque me permite ser un “arqueólogo” de los proyectos.

¿Consideras que la práctica de desarrollo de software realmente ha evolucionado en los últimos 20 años?Me extraña esta pregunta. Yo creo que he-mos transformado el mundo. Gracias a las TI, el mundo hoy es completamente diferente a lo que era hace 20 años. Lo hemos converti-do en un mundo donde los bits ya son más importantes que los átomos. No hubiéramos podido lograrlo sin hacer las cosas bien.

Tal vez puedas voltear a ver las prácticas de la industria y pensar: “eso es simplemente lo que Yourdon o Dijkstra plantearon hace 30 años, no hay un avance”. Para mí el avan-ce es que hemos tomado eso y lo hemos lle-vado de los laboratorios a la industria, a una industria que ha cambiado al mundo.

¿Entonces por qué hay un índice tan alto de fracaso en proyectos de TI? Las personas que promueven los índices de fracaso en los proyectos son reporteros tratan-do de vender una historia, y es difícil vender una historia con buenas noticias. Yo soy un ingeniero, y para nosotros el fracaso es algo sobre lo que se construye. Es algo necesario para poder hacer algo grandioso. Por supues-to que hay proyectos que fracasan, y yo creo que continuamente aprendemos de ellos.

¿Cómo ha cambiado el rol de los profesio-nistas de software en este tiempo?Los roles técnicos han evolucionado sustan-cialmente en cuanto a que se han especiali-zado. Hace 30 años, tanto los compiladores, como los sistemas operativos, y aplicacio-nes de negocio eran construidos usando las mismas técnicas y lenguajes. Hoy en día, puedes conocer a otro profesionista de soft-ware y darte cuenta de que no tienes nada de que platicar con él debido a que hacen cosas completamente diferentes.

Por otro lado, creo que la comunidad de ge-rentes de proyecto también ha madurado bas-tante. Creo que todos hemos comprendido

que el aspecto sociológico de los proyectos es igual o más importante que el tecnológico.

La formación de equipos de personas en nues-tra industria es algo único. La noción de tener a 20 o 30 personas realizando tareas intelec-tuales en conjunto –donde nadie es dueño de todo sino que cada quien es dueño de una pequeña parte– es algo que no tiene muchos paralelos en el mundo antes de nosotros, y que sirve de guía en cuanto a la forma de tra-bajar en otras industrias hacia el futuro.

¿Podrías dar un ejemplo de este impacto en otras industrias?Por ejemplo, uno de mis clientes es Pixar, quienes hacen las películas de animación. Si analizamos la forma en la que se desa-rrolla una de sus películas, y un proyecto de software, encontramos una gran cantidad de analogías. Tienen los mismos elementos y pa-trones: la formación de equipos intelectuales con habilidades diversas y complementarias, la planeación de actividades, el diseño, la im-plementación, la gestión de la configuración de los artefactos. Este es un ejemplo de cómo la evolución que se ha dado en la forma en que trabajamos en la industria de TI, se está propagando a otros campos.

Considerando la triada de “herramientas, personas y procesos”, ¿cual nos hace falta trabajar más?Cuando mencionas “herramientas, procesos y personas” implicas que hay una especie de balance, pero en realidad no lo hay. El proce-so y las herramientas son elementos menores de un proyecto. Los procesos son el aspecto más fácil de ver y representar, y por lo tanto tendemos a exagerar su importancia. Sin em-bargo, su importancia es mucho menor que la de aspectos humanos tales como el desa-rrollo de talento o la formación de equipos.

¿Cual es la habilidad más importante que debe tener un desarrollador de software?Precisamente la habilidad de desarrollar nuevas habilidades. Nuestro campo cambia continuamente y no podemos estancarnos en un solo método ni tecnología. Esto aplica no solo a las personas, sino también a las organizaciones.

¿Qué tan importante es que un proyecto salga en costo y tiempo?La capacidad de predecir efectivamente el costo y tiempo de un proyecto es algo de-

seable, pero no es lo más importante. La ob-sesión de poder predecir efectivamente nos obliga a adoptar estrategias de mayor con-trol, lo cual se traduce en menor velocidad. Esta presión se da principalmente cuando el valor de lo que construimos es marginal res-pecto a su costo. Si voy a construir un siste-ma que está presupuestado en un millón de dólares y va a traer un millón y medio de ga-nancias, entonces debo tener mucho cuidado porque el proyecto puede terminar costando más que su ganancia. Pero si voy a desarro-llar un proyecto que va a costar un millón de dólares y va a traer 200 millones de ganan-cia, entonces no importa si termina costando más de lo planeado. ¿Alguien se acuerda de si Photoshop se terminó a tiempo? No, lo que importa es que cambió al mundo.

Ante esto, la pregunta que hago a los lecto-res de SG es ¿Por qué están construyendo sistemas cuyo valor es tan cercano a su cos-to? Mi recomendación es que digan no a es-tos proyectos y busquen aquellos cuyo valor sea al menos 10 veces su costo.

¿Qué tendencias de la industria llaman tu atención actualmente?Una de las tendencias que estoy vigilando y que creo que tendrá un gran impacto en la industria es la de las tiendas de aplicaciones, como la Apple App Store. Creo que este con-cepto de tener un mercado en línea donde los usuarios puedan adquirir aplicaciones por unos cuantos dólares es algo que no debemos perder de vista. Lo que esto hace es habilitar a legiones de desarrolladores de software independientes para que puedan obtener dinero por sus servicios directamen-te del mercado, sin intermediarios. Es cierto que Apple (o las otras empresas que coor-dinan tiendas de este tipo) son una especie de intermediario, pero su interés principal es facilitar la transacción, más por el efecto que esto tendrá en la venta de su hardware, que por la comisión que puedan llevarse.

Actualmente, las ventas del Apple App Store exceden el millón de dólares diarios. Apple se lleva una comisión del 30%, pero aun así estamos hablando de 700 mil dóla-res diarios que de pronto le están llegando a la comunidad de desarrolladores de soft-ware. Y esto es solo el principio. Estamos hablando de algo que puede cambiar la forma en la que se desarrolle y mercadee el software hacia el futuro.

el nUeVo esqUeMa de entReGa de seRVicios de tiPor Pedro Galván



Una definición más formalGartner define el cómputo en la nube como “un estilo de cómputo donde se entregan como servicio capacidades de TI escalables ma-sivamente, a clientes externos a través de tecnologías de Internet”. Los detalles de traducción hacen que la redacción de esta definición no sea muy clara, así que detengámonos a analizar esta definición.

El concepto fundamental es que se basa en la entrega de servicios; es decir, resultados a diferencia de componentes o productos. La implementación no importa siempre y cuando los resultados se pue-dan definir y medir en términos de un acuerdo de servicio. Este pa-radigma implica el pago basado en el uso, no en los activos físicos. El costo puede ser pagado por completo por el cliente, o subsidiado (por ejemplo, a través de publicidad).

El segundo concepto importante de esta definición es el de la esca-labilidad masiva. Las economías de escala reducen el costo de los servicios. La escalabilidad también implica flexibilidad, y barreras de entrada bajas para los clientes.

¿Qué efecto tiene esto? Para los proveedores de servicios de TI, cloud computing significa la posibilidad de proveer servicios especializados de TI, de forma in-dustrializada. Es decir, que dichos servicios no tengan que construir-se de forma individualizada para un cliente específico. Por otro lado, para los usuarios de servicios de TI, significa que pueden enfocarse en aprovechar dichos servicios sin tener que preocuparse por cómo implementarlos y mantenerlos.

¿Qué servicios hay en la nube?Actualmente, los servicios más comunes que se puede adquirir a través de la nube son:

• Almacenamiento de datos. Por ejemplo Amazon Simple Storage Services en el caso de las empresas, o Windows Live Skydrive en el caso de personas.

• Capacidad de cómputo para “rentar” ciclos de CPU sin necesidad de comprar servidores. Tal vez el servicio más conocido es el Elastic Compute Cloud (EC2) de Amazon.

• Servicios aplicativos, a través del esquema SaaS (software as a service). Uno de los proveedores pioneros de este esquema es salesforce.com, que ofrece servicios de CRM sin que los usuarios tengan que comprar software; simplemente acceden a la aplicación desde su navegador por medio de Internet.

Estos ejemplos representan apenas el inicio, y en los próximos me-ses seremos testigos de cómo aumentan y evolucionan para entre-gar servicios complejos a toda clase de negocios y personas.

Referencias:[ Autores varios. Cloud Computing: Defining and Describing an Emerging Phenomenon. Gartner Research. Junio 2008. ][ Kumar, Sushil. Oracle Database Backup in the Cloud. Oracle Whitepaper, Septiembre 2008. ]

“Cómputo en la nube” (cloud computing) es el término que mayor

atención genera actualmente en la industria de Tecnologías de Información.

Descrito de forma sencilla, el cómputo en la nube permite a los usuarios acceder a

través del Internet a un fondo de recursos de cómputo virtualmente ilimitado. A dife-

rencia del esquema tradicional de TI, los usuarios de la nube tienen poca visibilidad

y control de la infraestructura subyacente, y solo interactuan con la nube a través de

los APIs proporcionados por los proveedores de la nube. Lo más importante de este

esquema es que permite a los usuarios adquirir recursos de cómputo dinámicamente

en un esquema de autoservicio, y solamente pagar lo que utilizan, tal como sucede

con servicios públicos como la energía eléctrica, o el agua.


la nUeVa FRonteRaPor Pablo Resendiz

El estado de la nubeCloud Computing es un término que se ha adueñado de diversos ámbitos del mundo de las TI. La definición de este término era, al principio una práctica donde se utilizaban recursos de varias máquinas para crear una “supercomputadora virtual”. Fue utilizado principal-mente para proyectos cooperativos que requerían de una gran cantidad de poder de procesamiento, con un presupuesto limitado. De esta manera, se reunían com-putadoras en línea, descargando un programa cliente que permitía utilizar una parte del poder de procesa-miento de la computadora inscrita y con todas ellas, ar-mar una supercomputadora virtual. Actualmente, “Cloud Computing” es la condensación de las actividades del usuario en línea, haciendo que lo único esencial para realizar esas tareas sea una computadora, acceso a In-ternet y un navegador. Hemos dado el salto gigantesco que eso significa, en términos de estar anclados, en el siglo pasado, a las máquinas de casa u oficina, enfren-tando una realidad de la que apenas alcanzamos a uti-lizar una pequeña parte de su potencial: múltiples dis-positivos adaptados a un uso particular, unidos a una gran nube de dispositivos de otros tipos, todos ellos ac-cediendo a la misma información con idéntica facilidad y coherencia. Estas actividades pueden ser el envío de correos electrónicos, el compartir documentos en línea para su edición y el respaldo de información.

La nube perfectaHoy en día, existen empresas enfocadas a proporcionar todo tipo de recursos para satisfacer cualquier aplica-ción que se les pida, utilizando un gran poder de proce-samiento y almacenamiento disponibles, lo que permi-te que el usuario tenga acceso a un número de recursos virtualmente ilimitados para tareas específicas.

La nube será sin duda, la nueva frontera. Y ésta se ex-tenderá en dos ámbitos: el de usuario y el corporativo. Actualmente, el usuario ya disfruta de sus beneficios, experimentando una transición gradual pero estable de las actividades que usualmente tenía frente a un mo-nitor en distintos dispositivos portátiles, además de tener acceso a sus datos, disponibles desde cualquier terminal tras una autenticación simple, pero que debe-rá ser robusta y confiable. Esta práctica cautivará poco a poco a los usuarios, que demandarán cada vez más

su correo, agenda y procesador de textos en un estado permanente, evitando así, estar lejos de él o encontrar-se con una computadora apagada. De entre estas apli-caciones la que experimenta un alto aumento es la de almacenamiento en línea.

Pero la evolución que marcará la tendencia más fuerte es la del mercado corporativo. Es cierto que el Cloud Com-puting nos ha demostrado su vulnerabilidad en un par de ocasiones (servicios de correo, agenda y documentos compartidos inaccesibles por horas y a veces días), sin embargo, la tecnología seguirá avanzando lo suficiente como para que sea confiable en un esquema de imple-mentación corporativo similar al que tuvo en su momento el propio correo electrónico empresarial. Con esta evolu-ción, las empresas comenzarán a tener los datos más allá de sus muros de protección y gozarán de costos menores, funciones de acuerdo a sus necesidades, y soporte para una colaboración sencilla, y sobre todo segura.

Poco a poco, los centros de datos corporativos estarán fuera de las empresas. Las únicas que seguirán con esta tendencia serán las que por su tamaño, tengan que re-currir a un data center propio, su nube particular.

El software, pieza clave de la nubeActualmente, la guerra de sistemas operativos es el precedente de la conjunción de aplicaciones que experi-mentaremos en la plataforma de la nube. El sistema ope-rativo deberá responder a tres exigencias: Seguridad, Estabilidad y Competencia. Sea cual sea la plataforma (Windows, MacOS, Linux), deberá tener en cuenta que los usuarios requieren sistemas amigables con el usua-rio, que utilicen los recursos de las computadoras de ma-nera óptima, y que no representen un problema de confi-guración, compatibilidades o restricciones excesivas.

Por su parte, el navegador será la puerta de entrada a este conjunto, utilizando recursos de ambos lados de la línea, cada uno en su medida, para ejecutar las ta-reas necesarias. En este posible estado de las cosas entra una pregunta fundamental: ¿Qué pasará con el software de aplicación como lo conocemos?

La apuesta principal en este sentido es el Software as a Service (SaaS, por sus siglas en inglés), una platafor-


ma que está íntimamente relacionada con el concepto de ultraportabilidad que plantea el Cloud Computing.

Los analistas de Gartner aventuran que en 2011, el gasto en SaaS alcanzará el 25% de la inversión total en software. Mientras que otro estudio de la consultora Saugatuck Technology, indica que el porcentaje de empresas y ejecutivos de TI que utilizan al menos una tecnología SaaS aumentó de un 11% a un 26% en el 2006. Por su parte Saugatuck Technology prevé que para el 2010, el 65% de las organizaciones habrá in-troducido al menos una aplicación siguiendo el modelo de SaaS, dicho así; las compañías de TI dedicadas al software encontrarán una nueva parcela para explotar.

Esta tendencia contará con tres actores principales:• Usuarios Finales. Los usuarios comen-zarán a utilizar un esquema de pagos por software basados en cuotas mensuales. Con esta opción, podrán probar y evaluar el servicio online en lugar de proporcionar recursos de su CPU necesarios para analizar el software, o instalarlo en sus máquinas. Al no estar atado a un espacio físico, la imple-mentación y el mantenimiento del software se puede administrar desde cualquier lugar. Los datos tendrán una estructura central, ac-cesible y segura, en lugar de estar dispersos en varios servidores y computadoras. Ade-más, el usuario no tendrá que experimentar pérdida de datos en caso de una falla eléc-trica o descarga en su localidad.

• Organizaciones. Ahorrarán en costos de aplicación, debido a que no tendrán que in-vertir en un área especializada para sopor-

tar el sistema, por lo que bajarán sus costos y su riesgo de inversión.

Esto representa un reto enorme para las compañías de software que opten por este camino, ya que la disponibilidad de la solu-ción deberá ser total. En este esquema, las caídas del servicio o las “horas muertas” deberán desaparecer. Esto significa que la garantía de disponibilidad de la aplicación y su correcta funcionalidad, son parte del servicio que otorga la compañía proveedora del software y no puede darse el lujo de una pérdida de disponibilidad, ya que eso reper-cutirá negativamente en su percepción con los usuarios y clientes.

Esto dará como resultado mejores aplicacio-nes, que tengan un acercamiento más prác-tico a las necesidades del usuario y con una calidad exigida que beneficiará al usuario.

• Distribuidores Independientes de Soft-ware (ISVs). El software puede desplegarse en un entorno controlado centralizado, con lo que se reducen las llamadas al escritorio de ayuda así como los costos de soporte. Esto permite una respuesta más rápida a los po-sibles problemas que pudieran presentarse y una mayor eficiencia en el manejo de recur-sos de los ingenieros involucrados.

Al ser un entorno de acceso controlado, los usuarios no tendrán que preocuparse por actualizaciones constantes o que los hagan perder tiempo o utilizar a su departamento de TI. Estas actualizaciones serán transpa-rentes para el usuario y no afectarán su tra-bajo, sino que mejorarán las aplicaciones sin que el usuario se moleste por configurar.

Además, el tema de la seguridad será un factor fundamental para los proveedores del

servicio, quienes tendrán que invertir más y de mejor manera en un esquema que permita autentificaciones confiables de los usuarios.

Con estas aplicaciones la confianza en el servicio crecerá, ya que el usuario se sen-tirá tranquilo de que sus datos están segu-ros, a prueba de robo, modificación o ingre-so no autorizado.

En la cuestión financiera, los ISVs tendrán una mejora en el manejo de sus finanzas, ya que el esquema de servicio de software les creará una cartera de pagos programa-dos mensualmente, lo que traerá una esta-bilidad que permitirá administrar mejor las entradas de Investigación y desarrollo.

Las pequeñas y medianas empresas entra-rán a este sistema, permitiendo que la base de clientes de los ISV crezca. El software ya no será una herramienta que requiera una experiencia previa de manejo o un desplie-gue de aplicaciones de instalación comple-jas. Con esto, las PyMEs podrán utilizar esta tendencia para mejorar sus procesos y opti-mizar sus recursos de TI.

Cuando la lluvia nos alcance El Cloud Computing será una de las solu-ciones que más ahorro va a suponer a las empresas, al ser un esquema libre, con am-plio mercado y gran competitividad, cuyo único costo fijo será la conexión a Internet. Las empresas que ofrecen este esquema naciente deben tener eso en cuenta al mo-mento de diseñar su estrategia de negocios y productos.

¿Está realmente la industria preparada para el Cloud Computing? Los primeros resultados son alentadores. Será la tecnología la que determine el rostro del mercado y las apli-caciones que ganarán la próxima apuesta, la siguiente frontera de TI: Las nubes.

Pablo Reséndiz se desempeña actualmente como Gerente de Negocios de Soluciones BURA (Backup, Recovery & Archiving) en EMC México. Con una experiencia de más de 10 años en la Industria TI, ha trabajado en empresas como IBM; desarrollándose como Ingeniero de Soporte a ventas para soluciones de Administración de Contenido.


Ahora bien, antes de definir ciertos conceptos en cuanto a este tema, creo que es importante mencionar algunas tendencias de negocio en este mercado; Gartner predice que:

• Para el 2010, 20% de las compañías de comercio electrónico usa-rán el modelo SaaS y 15% de las grandes compañías reemplazarán sus soluciones de ERP con soluciones basadas en SaaS.

• Para el 2011, 25% de los nuevos negocios de software usarán el modelo SaaS.

• Para el 2012, las suites de BPM (Business Process Management) serán embebidas en soluciones SaaS y más del 66% de los ISVs (In-dependent Software Vendors) ofrecerán sus servicios como SaaS.

IDC también estima que las empresas gastarán US$14.8 billones en soluciones SaaS y que dos de cada tres negocios considerarán com-prar software con modelos de subscripción. Estas cifras son verdade-ramente importantes, ya que representan un amplio mercado en la industria del software para los próximos años. Ejemplos de negocios que usan este enfoque son Salesforce.com, Google Apps, Appian, OpSource, CogHead, entre otros. Con esta tendencia, es importante también definir la forma en que este tipo de software es desarrollado y entregado al cliente. Este artículo analizará este aspecto y sus impli-caciones en la metodología tradicional del desarrollo del software.

Conceptos SaaSPara comenzar, podemos decir que SaaS no es una tecnología ni una metodología. Tampoco es un modelo de negocio específico. SaaS es un enfoque que consiste en varios componentes:

• Un modelo de negocio basado en subscripción. • Una plataforma SaaS que permite desarrollar y desplegar aplica-ciones sobre demanda.• Proveedores que desarrollan y/o comercializan esas aplicaciones.• Un modelo de entrega a través de Internet hacia múltiples clientes.

El modelo de subscripción debe soportar diferentes tipos de cobro, como son pago por transacción o periodo de tiempo. Los clientes de SaaS, a diferencia de los modelos ASP (Application Service Provi-der), son entidades de negocio y no usuarios finales. La plataforma SaaS provee soporte para diferentes aplicaciones, tanto las que son entregadas para los clientes como para aplicaciones propias de los proveedores. Comúnmente se usa el termino tenant para referirse tanto a los clientes como proveedores que usan la plataforma para consumir o proveer las aplicaciones SaaS.

• Plataforma SaaS. Una plataforma debe proveer infraestructura (tanto de hardware como de software) que soporte el desarrollo y entrega de aplicaciones sobre Internet como servicios. Arquitectu-ras comunes tienen los siguientes atributos de diseño:

¿Modelo, PlataFoRMa o seRVicio?Por Javier Mijail Espadas Pech M.C.

Recientemente me encontraba impartiendo una clase de Arquitecturas de Software. En un experimento rápido pregunté si alguien conocía el término Software-as-a-Service (SaaS). La respuesta fue una rotunda negativa de todos. Luego pregunté si alguien había usado alguna vez Google Docs y la gran mayoría respondió afirmativamente. Les comuniqué mi conclusión: aunque no conocían el término, ya habían usado SaaS.


1. Multi-tenant. La arquitectura soporta múltiples clientes y proveedores. 2. Versión simple. Existe una versión de cada aplicación y es com-partida para todos los clientes.3. Separación lógica de datos. Cada tenant tiene su propio dominio de información, pero almacenados en una misma base de datos.4. Contenedor de dominio. Es un punto de entrada a las aplicaciones de un proveedor.5. Integración de aplicaciones. Las aplicaciones SaaS deben comu-nicarse entre sí, pero mantenerse independientes.6. Componentes de soporte. La plataforma proporciona componen-tes compartidos para las aplicaciones: seguridad y autenticación, manejo de cuentas de usuario, logging, control de uso y métricas, soporte para diferentes modelos de subscripción, entre otros com-ponentes importantes.

Figura 1. Arquitectura SaaS

La figura 1 muestra la arquitectura de alto nivel de una plataforma SaaS. En el nivel más alto se encuentran las aplicaciones proporcio-nadas por los proveedores. La plataforma expone componentes de soporte para estas aplicaciones. Otros servicios son de meta-datos y administración de tenants. Infraestructura de software y hardware también es proporcionada por la plataforma. Sobre esta arquitectu-ra, las aplicaciones SaaS son desarrolladas, desplegadas y entrega-das a un número considerable de clientes.

• Aplicación SaaS. Básicamente, una aplicación es una serie de mó-dulos y funciones que puede ser desplegada bajo demanda dentro de una plataforma. Una aplicación SaaS es desarrollada acorde a la plataforma que la soporta. Las características de estas aplicaciones pueden definirse como sigue:1. Accedidas por Internet.2. Desarrolladas y desplegadas sobre una plataforma específica.

3. Soportadas por componentes compartidos de la plataforma.4. En sentido estricto, solo deben contener lógica de negocio e interfaz de usuario.

Impacto sobre el desarrollo de softwareActualmente los proveedores de SaaS no han establecido las mejo-res prácticas para desarrollar este tipo de aplicaciones ni tampoco estándares en la industria. Las metodologías tradicionales son sufi-cientes para desarrollar modelos SaaS muy simples, pero cuando se trata de especializar y escalar hacia un negocio más avanzado, aún se carece de técnicas bien establecidas. Por el lado de ingeniería de software, las aplicaciones SaaS presentan diferencias en cuanto a su ingeniería de requerimientos con las aplicaciones empaquetadas (por ejemplo, desde la perspectiva del cliente, la instalación y man-tenimiento son diferentes). Pioneros del modelo SaaS argumentan que se requiere un enfoque alterado de ingeniería de software para este tipo de aplicaciones.

Una pregunta importante es cómo el enfoque SaaS afecta a los proveedores de software y su incentivo a invertir en el desarrollo de productos. Transformar un producto empaquetado a un modelo SaaS no es una simple cuestión de reescribir código. Estas compa-ñías necesitan examinar sus modelos de ingeniería y mercadeo para adaptarse a este nuevo enfoque de negocio y de desarrollo.

Figura 2. Ciclo de Vida en Aplicaciones SaaS

La figura anterior describe que las actividades son diferentes a un pro-ducto tradicional. Una de las causas principales de estas diferencias, es que las aplicaciones SaaS están acopladas a una plataforma y en cada etapa esta plataforma juega un rol importante en el ciclo de vida SaaS. La siguiente tabla analiza el impacto en cada etapa del desarro-llo cuando el software es entregado como producto y como servicio.


La magia detrás del Mesh Hasta el día de hoy cada vez que iniciamos el desarrollo de una aplicación distribuida o de acceso a servicios, tendemos a pensar en todas las diferentes estrategias y soluciones posibles para nuestros problemas, invirtien-do gran parte de nuestro tiempo en tareas que repetimos con cada solución y cada dis-positivo que incluyamos. Sin embargo con la introducción de esta nueva plataforma, Microsoft espera minimizar la cantidad de tareas repetidas y permitirnos como desa-rrolladores, el enfocarnos en lo realmente necesario: la lógica de negocios y la com-posición de una experiencia perfecta para nuestros clientes. Tres capas definen la plataforma Mesh, con una cuarta que nos engloba el conjunto de experiencias con las que, como usuarios fi-nales interactuamos. Desde la infraestructu-ra física, servicios generalizados, así como toda una base de Protocolos e Interfaces de los que sacaremos provecho desarrollando y publicando nuestros servicios, Live Mesh se presenta como el cimiento sobre el cual el futuro de nuestras interacciones podran ser construidas. • Servicios de infraestructura. Así como otros servicios Live, Mesh tiene sus fun-daciones en una infraestructura diseñada desde el día uno, para soportar las necesi-dades de alta disponibilidad y escalabilidad del mundo actual. Con servicios de infraes-tructura y de administración que permiten no solo el acceso y almacenamiento de da-tos, sino tambien la disponibilidad de toda una gama de medios computacionales, Live Mesh permitira que tanto individuos como organización puedan publicar aplicaciones y servicios propios, haciéndolos disponibles a nuestras organizaciones y clientes a tra-vés de la nube y por medio de sus propios Mesh. Siempre dentro de los confines de seguridad y respaldo propios de una plata-forma de dicha magnitud.

Gracias al acelerado crecimiento en el acce-so a Internet de avanzada y a la disponibi-lidad de redes inalámbricas, la naturaleza de como las personas interactúan ha cam-biado. La sociedad inclina su balanza hacia la simplicidad de servicios y de aplicaciones

de software interconectadas que “sencilla-mente funcionan”; mientras que los nego-

cios consideran con mayor seriedad las economías basadas en servicios tales, que les permitan escalar a la vez de redu-cir costos de infraestructura, permitiendo

implementaciones a la carta o bajo mode-los de subscripción. Este mes, Microsoft introdujo su plata-forma de servicios en la nube, Live Mesh, con la fe de servir mejor a este cambio.

Como medio de lanzamiento a una serie de ofertas de desarrollo e implementación,

Mesh permite que tanto personas como em-presas puedan sacar provecho de una infraes-

tructura diseñada desde sus inicios para escalar y soportar la demanda de acceso a la información

que vivimos hoy en día, independientemente del lu-gar o dispositivo que tengamos a mano. Para Microsoft, Live Mesh es una combinación en-tre una plataforma y un conjunto de experiencias diseñadas para traer “a la vida” las computadoras

tradicionales y otros dispositivos. Haciendo que estos puntos de interacción sean con-sientes de su disponibilidad y existencia, Live Mesh permite a sus usuarios el po-der administrar, acceder y compartir archi-vos y aplicaciones de manera simple y dis-tribuida a lo largo de un amplio mundo de

dispositivos.

Live Mesh pertenece a una iniciativa mayor lla-mada el Live Platform Services, cuyos inicios da-tan del año 2005, encerrando toda una colección de Interfaces de Desarrollo que permiten el acce-so a diferentes servicios de infraestructura que Microsoft provee bajo la marca Live y dando poder tan-to a servicios gratuitos como Live Spaces, Messenger y Photo Gallery, así como a aplicaciones de terceros.

Una Vista al FUtUro de s+sPor Gilbert Corrales

NOV-ENE 2008


• Plataforma de servicios. Sobre la capa de infraestructura la Plataforma de Servicios pone a nuestra disposición, en una segunda capa, el acceso a una serie de funcionalida-des generales de las cuales podremos sacar provecho para construir tanto aplicaciones como servicios orientados a la nube. Algunos de estos servicios son el de Identificación y Directorio, como el Live ID, coordinación de conectividad y acceso entre dispositivos y, hasta almacenamiento y sincronización de nuestros datos entre los diferentes disposi-tivos que conformen nuestro Mesh, siendo la nube otro mas de estos puntos. • Pilar de desarrollo. Parte fundamental de Live Mesh es la incorporación de un pilar de desarrollo. Esta capa nos expone toda la fun-cionalidad de la Plataforma de Servicios a través de un conjunto de Protocolos e Inter-faces, conocidas como MeshFX, que corren sobre un motor de composición de servicios llamadao MOE o Mesh Operating Engine. Este motor es accesible desde todas las pla-taformas soportadas por Mesh incluyendo PC y Macs así como dispositivos móviles y navegadores Web tradicionales. Este ulti-mo con su propia experiencia llamada Live Desktop, una solución Web que provee acce-so a toda la información, aplicaciones y dis-positivos disponibles en el Mesh, utilizando como base de desarrollo las herramientas y protocolos Web comunes hoy en día. • Experiencias del Live Mesh. En este cuarta capa se engloban todas aquellas experien-cias que, tomando provecho de la platafor-ma descrita por los 3 niveles anteriores, nos proveen los medios de acceso necesarios para llevar a cabo nuestras tareas, sacando provecho del poder de procesamiento y de la experiencia disponible desde nuestros dispositivos. Este capa esta compuesta no solo por los servicios de interacción básicos que Live Mesh provee, sino también por la gama de aplicaciones y servicios que no-sotros y otros desarrolladores dentro de la comunidad construyen y hacen disponible a nuestro Mesh.

Funcionando en un mundo dearmonía: FeedSyncLive Mesh tiene como parte de su misión, el proveer una plataforma de servicio que haga posible el incorporar las capacidades necesarias para que estas estén disponibles virtualmente desde cualquier lugar, donde exista conectividad a la web, de manera ágil, segura y eficiente. Con un motor de alma-cenamiento con capacidades para poder llevar a cabo nuestras tareas de manera desconectada y de la misma manera, una vez resumida la conectivi-dad, poder sincronizar los cambios con los di-ferentes puntos de nuestro Mesh, esta pla-taforma permite desde el punto de vista de usuario, así como el desarrollo, la simpli-ficación de nuestro día a día, trayendo en si armonía dentro de nuestra información y una accesibilidad casi universal.

Fundación de esta característica es la sincronía de datos. Mesh implementa FeedSync entre sus capas, una tecnología desarrollada por Microsoft que utiliza los protocolos de RSS y ATOM, proveyendo así un mecanismo para sincronizar información entre 2 o más puntos de manera instantánea o asíncrona. Es con base a estos protocolos que nuestras aplica-ciones podrán sacar provecho de capacidades de des-conexión sin mayores complejidades, lo cual hace mantener copias sincronizadas de nuestros datos una tarea tan simple como el habilitar dichos puntos dentro de nuestro Mesh, traduciéndose así en una plataforma esencial para el éxito de nuestros servicios.

Nuestro futuro en la nube Live Mesh no es mas que el inicio de un mundo interconectado, un mundo en el que nuestras vidas inician a tener acceso a los recursos a la hora y lugares indica-dos. Es nuestra realidad la que cambia y evoluciona según estas necesidades y esta en nosotros hacerla realidad a lo largo de toda una gama de servicios y apli-caciones que, como sociedad 2.0 estamos empezando a dar luz. Nuestro futuro es disperso y accesible a todas horas. Nuestro futuro es una nube de conexiones sincronizadas entre nuestra realidad física y virtual que unidas nos facilitarán el día a día. Hagámosla realidad!

Gilbert Corrales, es Evangelista de Tecnología de Aggiorno y Profesor de Diseño de la Interacción en Cenfotec Costa Rica. Con más de 7 de años de experiencia en la industria, ha trabajado en proyectos tanto de investigación como comerciales para compañías como Unisys, Intel, y la agencia interactiva Schematic; Gilbert se enfoca en el diseño de la interacción con visión en tecnologías Web y medios de uso alternativos.

NOV-ENE 2008


Desarrollo de aplicaciones SaaSEl impacto en el proceso de desarrollo de software presentado ante-riormente debe ser tomado en cuenta cuando una aplicación es de-sarrollada como servicio. Las metodologías tradicionales son ahora analizadas y redefinidas para cumplir los nuevos requerimientos im-puestos por este nuevo enfoque. Podemos redefinir las actividades de cada etapa en esta propuesta:

Figura 3. Redefinición de las actividades en el ciclo de vida SaaS.

El desarrollo de aplicaciones sobre plataformas SaaS requiere de consi-deraciones en los diferentes escenarios del ciclo de vida del software.

RequerimientosEn el enfoque tradicional, los requerimientos consisten en definir una serie de funciones que satisfagan las necesidades de un cliente. En el caso de las aplicaciones SaaS, los desarrollos son meramente basados en un modelo de negocio. Eso es, una aplicación SaaS debe cumplir con los requerimientos de un mercado meta. Debido a que las aplicaciones serán consumidas por un gran número de subscrip-tores (empresas clientes) y cada uno puede tener potencialmente un número grande de usuarios, entonces más requerimientos no-funcionales son introducidos al proceso, como por ejemplo: soporte para alta concurrencia, almacenamiento escalable, virtualización/clustering entre otros. Las actividades propuestas son:

• Definición de un plan de requerimientos de negocio. Deben ser identificadas las características del plan de negocio (del proveedor) para ser transformadas a requerimientos funcionales.

• Análisis del mercado meta. Catalogar y puntualizar las necesida-des principales del mercado meta. Se deben evaluar las necesidades del mercado y definir características de alto valor para los clientes potenciales. En esta actividad se van identificando los requerimien-tos no-funcionales que se mencionaron anteriormente.

• Definición de las funcionalidades. Puntualizar las características principales como funciones de cada aplicación que será entregada como servicio. Estas funcionalidades deben ser completamente ali-neadas al mercado y no a los requerimientos de un solo proveedor.

AnálisisLa etapa de análisis debe ser realizada también desde la perspectiva de negocio. Esto es debido a que cada aplicación tratará de satisfa-cer las necesidades de un amplio número de clientes. La definición de los procesos de negocio que soportará cada aplicación es un paso importante en este tipo de aplicaciones, ya que debe permitir la per-sonalización y definición de procesos similares para cada cliente. • Análisis de procesos de negocio. En esta actividad se deben ana-lizar los procesos de negocio que serán automatizados con la apli-cación. Por ejemplo, si se desarrolla un CRM, se deben analizar los procesos de venta y su integración con otros procesos como cade-nas de suministro, por ejemplo. Cada proceso con sus actividades, roles y reglas de ejecución debiera ser documentado.

• Desarrollar casos de uso. Tarea formal en metodologías existen-tes, que debiera hacerse para documentar y modelar las funciona-lidades de la aplicación. Artefactos tradicionales son casos de uso descriptivos y sus diagramas.

DiseñoLa fase de diseño consiste en desarrollar documentación que sopor-te la etapa de construcción.

• Investigación de tecnologías. Es importante en esta etapa hacer investigación sobre las tecnologías que soporten las necesidades identificadas. Un artefacto entregable puede ser un documento de investigación acerca de plataformas SaaS, proveedores existentes, frameworks, componentes Web 2.0, etc.

• Evaluación de tecnologías. Es importante definir cuál es la pla-taforma y las tecnologías que serán usadas en el proceso de desa-rrollo. Las pruebas de concepto en esta etapa son necesarias, para realmente determinar si la plataforma y tecnologías cumplen con los requerimientos tanto de negocio como técnicos.

• Arquitectura de servicios. En este caso, las decisiones arquitec-turales están basadas en las premisas SaaS y la plataforma que las soporta. Debido a que las plataformas SaaS están diseñadas para ofrecer una infraestructura de servicios, los componentes de la apli-cación deberían ser diseñadas bajo este enfoque.

• Ingeniería de procesos de negocio. Incluso cuando la aplicación debe proveer una definición predeterminada del proceso de negocio que ejecutará, su valor incrementa cuando es posible redefinir cada proceso de acuerdo al cliente.

• Documentación tradicional. Esta actividad involucra diversas tareas comunes como diagramas UML. Se trata de la documentación formal de la aplicación y depende de las especificaciones de la misma.

• Diseñar casos de prueba. Esta tarea resulta obviamente importan-te para cualquier desarrollo serio. Se deben incluir mecanismos de pruebas unitarias, de integración, de rendimiento, etc.

• Prototipos. Los recursos y la agilidad de generar y desplegar apli-caciones en plataformas SaaS puede ser explotado a través de la construcción de prototipos.


ImplementaciónAdemás de las tareas comunes involucradas en la implementación, dentro del desarrollo SaaS es necesario considerar a la plataforma que soporta las aplicaciones.

• Desarrollo de servicios de negocio. Se trata de codificar las inter-faces principales de la aplicación, así como sus implementaciones. • Integración con los servicios de la plataforma. Desarrollar el código para consumir los servicios que la aplicación necesita para operar. Estos servicios consumidos pueden ser de seguridad, logging, métricas, etc.• Desarrollar la lógica de negocio. Implementación de las reglas de negocio para los módulos de la aplicación.• Desarrollar el front-end. Diseño y desarrollo de interfaces de usuario.• Desarrollo de integración. Si es necesario, desarrollar código para integrarse con otros sistemas.• Implementación de tecnología. Asegurarse que toda la implemen-tación trabaja correctamente. Esta actividad cubre revisión de códi-go, mejores prácticas, revisión de complejidad ciclomática, pruebas funcionales, entre otros.

PruebasLa principal diferencia entre las metodologías tradicionales y la pro-puesta para SaaS radica en que las pruebas de integración necesitan validar la integración correcta entre las aplicaciones y la plataforma. Otra diferencia importante es en cuanto a las pruebas de rendimien-to y métricas de uso.

• Pruebas unitarias. Estas pruebas son desarrolladas y ejecutadas por cada desarrollador.

• Pruebas de integración. Pruebas importantes en cuanto a la inte-gración con la plataforma, con otros módulos de la aplicación y con otras aplicaciones.

• Pruebas de rendimiento. Cada aplicación tiene sus propios requeri-mientos de rendimiento, en este caso, las aplicaciones SaaS tienen una fuerte dependencia en el número de usuarios y sus especificaciones.

• Pruebas de medición de tenants. La aplicación no debiera imple-mentar código para logging o medición de uso. Estos componentes son responsabilidad de la plataforma misma. El objetivo de estas pruebas es asegurar que el uso y debug de cada aplicación es co-rrectamente registrado y para cada tenant (cliente y/o proveedor).

• Aprobación Técnica. Consiste en correr todas las pruebas sistemá-ticamente y asegurarse que la aplicación es correctamente desple-gada a producción. En el caso de actualizaciones y bugfixes, la pla-taforma debe proporcionar mecanismos de rollback cuando existan fallas y se pueda regresar a versiones anteriores.

Javier Mijail Espadas Doctoral Research Assistant Ph. D. Information Technology and Communications ITESM Campus MonterreyCETEC SouthTower Monterrey, Nuevo León, México.

ConclusiónNuevas plataformas conocidas como Software-as-a-Service (SaaS) serán un importante canal de distribución para el software empre-sarial en un futuro cercano. El proceso de desarrollo sobre estas plataformas debe considerar diversos factores que no presentan los métodos actuales de desarrollo de software. Las diferencias entre desarrollar software como servicio o como producto empa-quetado son evidentes y estas diferencias cambian la manera en que las aplicaciones SaaS son desarrolladas. Dadas estas diferen-cias, este trabajo analiza las consideraciones necesarias para cada etapa de desarrollo en este nuevo tipo de aplicaciones y también presenta una guía para desarrollar aplicaciones en ambientes de negocio Software-as-a-Service.

Referencias[ Turner, M.; Budgen, D.; Brereton, P. “Turning software into a service”. Computer. Volume 36, Issue 10, Octubre 2003. ][ Predicts 2007: Software as a Service Provides a Viable Delivery Model. Gartner Inc. 2006. ][ Wolde, Erin Ten. Research Analyst, IDC. Agosto 2007. ][ Natis, Yefim V. Introducing SaaS-Enabled Application Platforms: Features, Roles and Futures. Gartner Inc. 2007. ][ Choudhary, V. “Software as a Service: Implications for Investment in Software Development”. Annual Hawaii International Conference on System Sciences, 2007. ][ Olsen, E.R. “Transitioning to Software as a Service: Realigning Software Engineering Practices with the New Business Model”. Service Operations and Logistics, and Informatics, 2006. ][ Carraro, Gianpaolo; Chong, Fred y Page, Eugenio Pace. “Efficient Software Delivery Through Service-Delivery Platforms”. The Architecture Journal. Microsoft MSDN Architecture Center ][ Chou, Timothy. The End of Software. Sams Publishing, 2005. ]


/*PROGRAMACIÓN*/// PRÁCTICAS

36

Ofuscación de Código DinámicaMecanisMo de Protección o aMenaza Por Juan Olivares, Sandokan Barajas

La ofuscación de código dinámica es una técnica que transforma el código en garabatos incomprensibles, esta técnica puede ser utilizada con dos propósitos principales, el primero como una he-rramienta de protección de derechos de autor del código de los programas, y el segundo como una amenaza a los mecanismos ac-tuales de seguridad en la red.

La mayoría de las empresas tratan de evitar que su código fuente pueda ser obtenido por alguien más, es por esto que hacen uso de herramientas que les permitan evitar que alguien lo pueda obtener.

Sin embargo la ofuscación también sirve como un mecanismo de para generar muchas versiones del mismo código, logrando de esta manera sobrepasar los mecanismos usuales de análisis de los siste-mas de seguridad, como los antivirus.

La amenaza oculta En la actualidad, a pesar de que los antivirus son cada día más poten-tes y hacen uso de técnicas mucho más complejas para lograr evitar las amenazas, nace una nueva técnica que logra poner en dificultad a estos sistemas actuales de defensa, esta nueva técnica es llama-da ofuscación de código dinámica, y se basa en la transformación o enmascaramiento del código para evitar que se pueda determinar la forma que tenía originalmente.

La ofuscación de código dinámica empezó a funcionar con javascript un poco después de que fuera liberado este lenguaje en 1995, se hizo por la principal razón de proteger el código que tanto trabajo les costaba desarrollar a los programadores, y que cualquier usuario podía ver usando un explorador con esas características.

La ofuscación también hace uso del polimorfismo que ya ha sido utiliza-do con anterioridad en los virus, y en la actualidad se está utilizando con los exploits de javascript para ocultar su peligrosidad y poder incrustar-lo en páginas Web, a las cuaes son invitados a entrar los usuarios.

Mecanismo de protección El código fuente de un programa es muy valioso, siendo una creación intelectual, es susceptible de ser utilizado sin haber tenido que pasar por un proceso creativo nuevamente, es decir, una vez que se desarro-llo el código puede volver a ser utilizado sin haber tenido que emplear tiempo en su desarrollo, es por esto que las empresas y desarrollado-res protegen tan celosamente su código.

Una manera de entre muchas que existen en la actualidad para pro-teger su código, en otras palabras su propiedad intelectual, es la ofuscación, que se ofrece como una manera de poder ejecutar el código por otras personas, sin que estas puedan llegar a entender cómo funciona en realidad.

La ofuscación de código ha sido propuesta por un gran número de investigadores como un medio para dificultar la realización de inge-niería inversa sobre el código. Pero las transformaciones típicas de ofuscación se basan en razonamientos estáticos sobre ciertas pro-piedades de los programas, lo cual da como resultado que la ofus-cación del código pueda ser fácilmente desentrañada mediante una combinación de análisis estáticos y dinámicos.

Resumen La ofuscación de código dinámica es una nueva forma de en-mascarar el código, a lo largo de este artículo veremos las ven-tajas y riesgos que implican el descubrimiento de esta nueva técnica, así como algunos de las métodos que existen tanto para ofuscar el código, como para lograr la desofuscación del mismo, además de las principales formas y lugares donde esta técnica puede ser aplicada.

Juan Carlos Olivares Rojas es Maestro en Ciencias de la Computación por el Centro Nacional de Investigación de Desarrollo Tecnológico (CENIDET), actualmente es Profesor de Tiempo Parcial del Instituto Tecnológico de Morelia, sus áreas de interés son los Sistemas Distribuidos y la Ingeniería de Software.

Figura 1. Existen muchas herramientas que ayudan a la fácil ofuscación de código, las cuales permiten proteger los códigos dinámicos o de scripting, aunque también se puede utilizar con fines malignos


Conceptualmente se pueden distinguir dos tipos de ofuscación de código: la ofuscación superficial y la ofuscación profunda. La primera siendo solamente un reacomodo de la sintaxis del progra-ma, ya sea cambiando nombres de variables o algún otro método similar, y la segunda que intenta cambiar la estructura actual del programa, cambiando su control de flujo o modo de referenciar sus datos, esta última teniendo menos efecto en el proceso de estar oculto a la ingeniería inversa, ya que no se ocupa de disfrazar la sintaxis del código.

Técnicas de ofuscación Una de las técnicas de ofuscación es la llamada “aplanamiento de control de flujo básico”, la cual intenta esconder la lógica de flujo del programa para que simule que todos los bloques básicos tienen el mismo antecesor y el mismo predecesor.

El control de flujo actual es guiado mediante un despachador de va-riables, el cual en tiempo de ejecución asigna a cada bloque básico un valor variable, que indica cual es el siguiente bloque básico que debe ser ejecutado a continuación. Entonces un bloque switch utiliza el despachador de variable para saltar de manera indirecta, a través de una tabla de saltos hacia el sucesor de control de flujo que debe ser.

Existen varias mejoras en esta técnica de ofuscación, siendo una de ellas el flujo de datos interprocedimental, las variables que asignaba el despachador se encontraban disponibles dentro de la función mis-ma, debido a lo cual aunque el comportamiento del control de flujo del código ofuscado no sea obvio, puede ser reconstruido mediante un análisis de constantes asignadas por el despachador de variables.

La ofuscación del código puedes ser más difícil de reconstruir si ade-más de lo anterior agregamos el paso de variables entre los procedi-

mientos, la idea es utilizar un arreglo global para pasar los valores asignados por el despachador de variables, así cada vez que se llame a la función se pasará el valor al arreglo de variables global, logrando de esta manera que los valores asignados cada vez que se llama la función no sean constantes, sino que al examinar el código ofuscado no sea evidente el proceso que se realizó en la llamada a la función.

Otra mejora que se puede agregar a la técnica de ofuscación men-cionada es la adición de bloques básicos al de flujo de control del programa, algunos de los cuales nunca van a ser ejecutados, pero lo cual es muy difícil de determinar mediante análisis estáticos, de-bido a que las llamadas se generan de manera dinámica durante la ejecución del programa.

Entonces se agregan funciones de cargas hacia esos bloques inal-canzables a través de punteros, lo cual tiene el efecto de confundir a los análisis estáticos sobre el posible valor que asignó el despa-chador de variables.

Técnicas de desofuscación Así como existen varias técnicas y mejoras para la ofuscación del código, también existen técnicas para lograr desofuscar el código, o mejor dicho, técnicas de ingeniería inversa sobre el código ofuscado algunas de las cuales se describen a continuación.

• Clonación. Muchas de las técnicas de ofuscación se basan en la creación de rutas de ejecución falsas para engañar a los programas de análisis estáticos, debido a que esas rutas nunca van a ser toma-das en el momento de ejecución del programa, mas sin embargo, causan información engañosa que se propagará a lo largo del aná-lisis y reducirá la precisión de la información obtenida, lo cual hará más difícil de entender la lógica del programa analizado.

Esa información defectuosa tiene la característica de introducir im-precisiones donde los caminos de ejecución se cruzan.

Una forma de resolver este problema o desofuscar el código es me-diante la clonación de porciones de código, de tal manera que las ru-tas de ejecución falsas no se unan con la ruta de ejecución original.

Esta transformación tiene que ser aplicada con sumo cuidado, debi-do a que si no se hace de esta manera, puede incrementar el tamaño del código, y más aun que lograr desofuscar el código, empeore el problema de desofuscación, sin embargo como la meta de la deso-fuscación del código es la de remover código ofuscado, la clonación implica que se tenga un conocimiento previo de la ruta de ejecución actual, lo cual podría lograrse mediante la clonación selectiva en ciertos puntos donde las rutas de ejecución se unen.

“El código fuente de un programa es muyvalioso, siendo una creación intelectual, es

susceptible de ser utilizado sin haber tenido que pasar por un proceso creativo nuevamente”.

Figura 2. Análisis de un código ofuscado en Javascript. Se puede notar que son pocas las cadenas de texto legibles por humanos. Determinar la semántica de un código (el que realiza) es sumamente complicado, por este motivo la mayoría de las herramientas de protección bloquean en su totalidad programas de Javascript


“La ofuscación de código ha sido propuesta por un gran número de investigadores como

un medio para dificultar la realización de ingeniería inversa sobre el código”.

38

/*PROGRAMACIÓN*/// PRÁCTICAS

Sandokan Barajas es pasante de la carrera de Ingeniería en Sistemas Computacionales próximo a obtener el títiulo. Trabaja dentro del Centro de Investigación en Ecosistemas (CIECO) de la UNAM Campus Morelia.

• Análisis de factibilidad de ruta estática. Este es un análisis es-tático basado en cadenas, que evalúa la factibilidad de una ruta de ser ejecutada.

En este análisis primeramente se debe crear una cadena que corres-ponda con la ruta de ejecución, la construcción de esta cadena se puede realizar de varias maneras, pero la meta, es que tome en cuen-ta los efectos de las operaciones aritméticas sobre los valores de las variables de los bloques de código, y que nos represente la propaga-ción de constantes a través de una ruta de ejecución del programa, y después se evalué si esa ruta de ejecución es factible o no.

Algunas de las formas de crear las cadenas anteriormente descritas son las siguientes:

• Asignación• Aritmética• Indirección• Bifurcaciones

• Combinación de análisis estáticos y dinámicos. Los análisis es-táticos convencionales son inherentemente conservadores, por lo tanto al aplicar técnicas de desofuscación meramente estáticas al código ofuscado, el conjunto de resultados son en realidad un su-perconjunto de ese código ofuscado, inversamente a lo que resulta si se aplican técnicas de desofuscación dinámica, que no pueden tomar todos los posibles valores de entrada, por lo cual este análisis solamente nos regresa un subconjunto del código ofuscado.

La naturaleza dual de estos dos tipos de análisis sugieren que se debe intentar realizar un análisis que abarque estas dos aproxi-maciones de solución para desofuscar un código, lo cual se puede realizar de dos maneras, primero realizando un análisis dinámico y después uno estático para agregar partes al control de flujo del pro-grama, o se puede realizar de manera contraria, empezando primero con el análisis estático y después el dinámico, lo que nos servirá para reducir partes del control de flujo del programa.

De cualquier manera, cuando se realiza una combinación de estos dos tipos de análisis no se puede garantizar la precisión, sin em-

bargo si lo vemos desde el punto de vista de la ingeniería inversa, al unir estos dos tipos, nos podemos sobreponer a las limitaciones que nos causan el hecho de realizar un análisis estático o uno sim-plemente dinámico.

La Web 2.0 y Ajax La Web 2.0 ofrece soluciones para compartir casi cualquier contenido digital pero también presenta desventajas. En algunos casos, el usuario pierde el control de sus creaciones en favor de las empresas que prestan el servicio. Aunque O’Reilly sostenga que la persona controla sus pro-pios datos, esto sólo sería cierto en algunos casos, pero no en todos.

Un consumidor tiene la libertad de decidir qué contenidos publicar en una Web, pero una vez que están dentro del servicio, en muchos portales se pierde parte del control sobre la información aportada, además, surge el peligro potencial de que algunos de los usuarios suban código potencialmente peligroso.

Ajax surge como una nueva forma de lograr tener aplicaciones a tra-vés de la Web, que a diferencia de las paginas estáticas, permite a los usuarios participar, interactuar y compartir de una manera más plena la información con los sitios Web, lo anterior abre un mundo de posibilidades de interacción con los usuarios de estos sitios, pero además trae consigo el correspondiente aumento de riesgos en la seguridad, tanto para los usuarios como para los mismos sitios.

El principal riesgo de seguridad que nos trae esta nueva tecnología es el que el usuario no siempre está consciente del código que pue-de estarse ejecutando en su máquina, ya que Ajax nos proporciona una manera de interactuar de forma asíncrona con los sitios, lo cual puede ser muy útil, ya que evita tener que estar recargando constan-temente el código de las páginas.

Así mismo, esta característica que nos permite la comunicación asíncrona, también presenta el mayor riesgo, ya que en una página se pueden tener objetos incrustados, que a primera vista parezcan inofensivos, y no tengan mayor propósito destructivo, pero que posteriormente se encarguen de descargar o incrustar mas códi-go, que al ser ofuscado logre burlar a los mecanismos actuales de análisis de seguridad.


Referencias [ Sharath, U. “Deobfuscation Reverse Engineering Obfuscated Code.” Proceedings of the 12th Working Conference on Reverse Engineering (WCRE’05), 2005. ] [ Amit, V. “Cobra: Fine-grained Malware Analysis using Stealth Localized-executions”. Proceedings of the 2006 IEEE Symposium on Security and Privacy (S&P’06), 2006. ] [ Karen, H. “New attacks tricks antivirus software”. Innovative technology for computer professionals. Volume 40, Number 5, May 2007. ] [ Arboit, G. “A method for watermarking java programs via opaque predicates”. Procedings of 5th. International Conference on Electronic Commerce Research (ICECR-5), 2002. ] [ Collberg, C.; Thomborson, C.; Low, D. A taxonomy of obfuscating transformations, 1997. ][ de Roo, Arjan; van den Oord, Leon. Stealthy obfuscation techniques: misleading the pirates. ] [ Ernst, Michael D. “Static and dynamic analysis: Synergy and duality”. In WODA 2003: ICSE Workshop on Dynamic Analysis, Portland, OR, May 2003. ] [ Arnaud, G. “Automated Metamorphic Testing”. Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03), 2003 IEEE. ] [ Karl, L. “Towards a Metamorphic Testing Methodology for Service-Oriented Software Applications”. Proceedings of the Fifth International Conference on Quality Software (QSIC’05), 2005. ]

Conclusión La ofuscación de código dinámica es una nueva técnica que tiene varias ventajas y desventajas, dependiendo del punto de vista y uso que se le de a la misma. Pues si es aplicada como un mecanismo de seguridad, puede ser muy prometedora, ya que aunque sea una técnica que puede ser vulnerada mediante el uso de algunos análi-sis estáticos y dinámicos, proporciona un nivel un poco más elevado de seguridad. En cambio si es utilizada como una arma para lograr burlar los actuales mecanismos de defensa puede ser muy peligrosa, pues aunque se podría detectar su peligrosidad mediante algunos de los análisis mencionados en este artículo, consumiría mucho tiempo y lo más probable es que mientras se realizara este tipo de análisis, se descui-dara algun otro aspecto de la seguridad.

En cuanto a la web 2.0 como la llamo O’Reilly, existe un riesgo potencial debido princi-palmente a las características que la hacen tan útil, pero a la vez tan peligrosa, debido a que esa manera de compartir contenidos a través de la web podría traer consigo la diseminación de código ofuscado dañino y que sería difícilmente detectable por su capacidad de transformarse de una infinidad de maneras, y el hecho de que el motor de generación no se encontraría en el mismo código sino en otra ubicación, lo cual imposibilitaría realizar un análisis de ese motor para lograr averiguar la forma en que el código ofuscado es generado.

Es por esto que la Web 2.0 como tal, tiene que mejorar sus actuales mecanismos de seguri-dad, pensando especialmente que los beneficios que nos pueda brindar su versatilidad tiene asociados nuevos riesgos y novedosas formas de lograr vulnerar la seguridad.


/*AdMINIstRACIÓN de bAse de dAtOs*/// PRÁCTICAS

Victor Hugo García es Líder de Desarrollo Web en C-Technologies. Es egresado del Instituto Tecnológico de Ciudad Guzmán. Cuenta con experiencia en el diseño de base de datos y programación con tecnologías .NET y PHP. Actualmente se encuentra desarrollando software en diversas verticales de negocio para clientes en Estados Unidos. Durante el 2007 colaboró con proyectos en el Gobierno del estado de Guanajuato.

Diseño de Base de Datosla iMPortancia de los catálogos

Por Victor Hugo García

Los catálogos, en una base de datos, son indispensables para un buen diseño de la misma. Es por eso la importancia de conocer las ventajas y desventajas de su uso. Comencemos definiendo “catálo-go” en una base de datos. Un catálogo es una tabla de datos que contiene información relevante sobre las opciones finales de un usuario en una aplicación. A continuación menciono las ventajas y desventajas de los catálogos en el diseño de base de datos:

Ventajas• Permite una rápida obtención de los datos requeridos al momento de realizar una consulta.

• Permite una reducción de tiempo en programación.

• Permite al usuario final la posibilidad de realizar una modificación de manera dinámica a las opciones del software, fácil y rápidamente desde una administración.

• Permite crear una base de datos normalizada.

Desventajas• El uso de memoria en el servidor SQL puede verse afectado.

La desventaja puede ser solucionada con el uso correcto de las consultas SQL, tal es el caso de evitar productos cartesianos al mo-mento de dicha consulta y en su reemplazo utilizar INNER JOIN, LEFT JOIN, RIGHT JOIN según se requiera.

Ciertos desarrolladores necesitan ver un proceso de normalización de una base datos, sin embargo, si comienzas a diseñarla utilizando catálogos, dicho proceso puede llegar a ser innecesario.

Ejemplo 1“Un sistema requiere que almacene el país de origen de un clien-te” pero este dato puede cambiar y/o aumentar en base a las ne-cesidades del usuario final. El desarrollador puede elegir entre varias opciones:a. Agregar un campo de tipo cadena de caracteres, permitiéndole al usuario escribir el dato en un campo de texto.b. Añadir un campo de tipo entero y colocando un campo de selec-ción obteniendo la información desde el código de manera estática.

Los problemas que se generan cuando se utiliza un campo de tipo cadena de caracteres, radica en la integridad de los datos, pues en

esta se pierde completamente. Los errores humanos siempre hay que tenerlos presentes y por tanto, alguien como usuario final pue-de llegar a escribir el nombre de un país de la manera incorrecta. Además la normalización no está presente en este caso.

Cuando se obtienen los datos de manera estática en el código, se presenta el problema en el tiempo invertido que se requiere en la programación de los elementos, así como el mantenimiento de ciertos módulos.

Enseguida muestro una solución utilizando los catálogos: Se dise-ña la tabla –Cliente- y la tabla –Pais-, La tabla Pais almacena los da-tos que necesitamos con dos simples campos: “idPais y nomPais”, dicha tabla siendo relacionada 1:N con la tabla clientes, de esta ma-nera es posible obtener la información necesaria del cliente con una simple consulta SQL, además de que el proceso de normalización e integridad de los datos se está dando de manera automática.

Si el usuario final desea que su sistema sea capaz de aumentar los datos de los países, el administrador del catálogo Pais podrá agre-garlo fácil y rápidamente. Inclusive, los reportes que se hayan pro-gramado no requerirán de inversión de tiempo, puesto que la infor-mación que se pida será obtenida mediante una consulta SQL.

En la siguiente figura muestro un diagrama de clases de lo que sería una relación de la tabla cliente con la tabla país (1:N).

Ejemplo 2“Un sistema requiere que se almacene la especialidad de un médico” este dato se puede aumentar, actualizar y/o eliminar.

La solución fácil y rápida pero errónea, sería crear un campo en la tabla médico llamado “especialidadMedico” y que este sea de tipo


Realizar búsquedas, generar reportes, obtener información para desplegar en alguna lista, etc., todo esto puede llevarse a cabo de manera rápida y eficiente. En todos los sistemas una búsqueda es básica e indispensable, por lo tanto imaginemos esto: El cliente desea una lista desplegable con las especialidades que se tienen para realizar un mejor filtrado de la información. Ahora, imagina esto en más de 10 páginas. Por ultimo imagina que el usuario final te comenta que se requiere agregar una nueva especialidad.

Considerar la creación de un catálogo para un mejor control e integridad de la información sería ideal para solucionar varios problemas como el que se describe en el párrafo anterior. Si se re-quiere un reporte de todos los médicos de cierta especialidad, esto sería muy sencillo de obtener mediante una consulta SQL. Permitirle al usuario modificar las opciones de un sistema es siem-pre ideal, pues el usuario verá lo sencillo que es hacerlo desde un ambiente grafico.

Cuando se necesita cotizar una aplicación, se debe dejar en claro al cliente, que el adminis-trador del sistema será capaz de modificar opciones del sistema de manera fácil y rápida; tu cliente verá esto como un buen desarrollo.

Cuando me encuentro en reuniones con clientes para hablar sobre las opciones que se de-sean en el sistema, siempre hay un punto en el que se comenta “Este módulo debe ser así, porque CASI NO se eligen esas opciones” es entonces cuando se tiene que realizar un análisis de ese caso, puesto que si eliges una opción errónea, al momento de entregar tu software se te diga que SIEMPRE SI se usarán dichas opciones, para solucionarlo te podrías ver en la ne-cesidad de reprogramar uno o varios módulos; sin embargo, al elegir la opción de catálogos, simplemente se agrega el dato a la base de datos y listo.

Finalmente podemos concluir que si los desarrolladores ven la importancia del uso de ca-tálogos, esto puede significar auténticos ahorros en tiempo de programación, proceso de normalización y mejorar la integridad de los datos en la aplicación.

43

cadena de caracteres. Como he venido platicado, esta solución pierde completamente la integridad de los datos y por consiguiente la normalización de la base de datos no existe. Por tanto si se elige la solución por catálogos como se muestra en la figura siguiente:


/*ARquIteCtuRA*/// PRÁCTICAS

Cuando llega el momento de desarrollar la ar-quitectura de un sistema de software, es nor-mal que surjan dudas como: ¿Por dónde em-pezar?, ¿qué documentos y diagramas hay que hacer? ¿cuáles hacemos primero y qué orden seguimos? y muchas de las veces incluso du-damos de ¿qué es la arquitectura de software?

En esta ocasión haremos un resumen del marco de trabajo para arquitecturas y en particular del método para desarrollar ar-quitecturas propuesto por The Open Group. Método que nos puede ayudar a responder las preguntas planteadas.

¿Qué es y para qué sirve laarquitectura?La arquitectura de un sistema de software nos ayuda a satisfacer los requisitos de ca-lidad que debe cumplir un sistema de soft-ware permitiendo que la solución creada sea confiable, mantenible, estable, usable y todos los “able” que nos enseñan en la pre-paración académica acerca de este tema.

Otro hecho en la vida de un proyecto es que la única constante en el desarrollo del soft-ware es el cambio. Una buena arquitectura nos ayuda a realizar estos cambios con me-nos tiempo y esfuerzo, además de facilitar la implementación de una estrategia de re-uso.

El término arquitectura de software es uno de los más extensos y documentados, y me refiero a lo siguiente, si le preguntas ¿qué es arquitectura de software? a cinco desa-rrolladores, seguramente obtendrás cinco respuestas distintas, incluso el SEI (Software Engineering Institute) en su sitio en internet tiene una sección que recopila definiciones de arquitectura de software (www.sei.cmu.edu/ architecture/published_definitions.html).

Una Receta para Desarrollar Arquitecturascon Procesos Bien deFinidosPor Miguel Armas

Mike Armas es consultor e instructor senior certificado por la OMG en Milestone Consulting, primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en UML y las mejores prácticas de ingeniería de software. [email protected] www.milestone.com.mx

Nos quedaremos con la siguiente definición de arquitectura de software, proveniente del libro Software Architecture in Practice: La arquitectura de software de un progra-ma o sistema de cómputo es la estructura o estructuras del sistema, la cual incluye los elementos del software, las propiedades ex-ternamente visibles de esos elementos y las relaciones entre ellos.

Por elementos del software, debemos enten-der prácticamente todo lo que podamos re-presentar en UML y aún más, clases, objetos, componentes, hardware, pantallas, requisi-tos, casos de uso, etc. Pero ¿cuáles son los pasos para describir y plantear las relaciones entre todos esos elementos? Es precisamen-te eso lo que veremos a continuación.

Madurez en la disciplina dearquitectura de softwareEl desarrollo de software ha dejado de ser un arte y poco a poco se ha ido convirtiendo en una ingeniería, lo mismo ha sucedido con la discipli-na de arquitectura de software, esta madurez es tangible por los siguientes elementos:• Un cuerpo de conocimiento (Body of Knowledge, BOK) de arquitectura.• Certificaciones como arquitecto de software.• Modelo de procesos para desarrollar la ar-quitectura de software.

Aún falta trabajo por realizar, ya que actual-mente contamos con varias iniciativas para formar un BOK de arquitectura, habría que unificar estas iniciativas para ganar aún más madurez. Lo mismo sucede con respecto a las certificaciones como arquitecto de software, existen certificaciones de Microsoft, Sun e IBM solo por mencionar algunas. Espere-mos que en el futuro veamos la unificación de todas las certificaciones existentes, pues

sería un buen paso en beneficio de la comu-nidad de arquitectos de software.

Anteriormente no contábamos con un mo-delo de proceso para desarrollar la arquitec-tura de un sistema de software. Y en todo caso, algunos de estos pasos se llegan a contemplar en los modelos de procesos para desarrollo de software como el Proceso Unificado en el Marco de Trabajo para Solu-ciones de Microsoft (UP y MSF), Iconix, sólo por mencionar algunos.

La buena nueva es que ya existe un modelo de procesos creado específicamente para el desarrollo de arquitecturas de software, el cual complementa muy bien a los procesos de desarrollo de software existentes, como los antes mencionados.

Un marco de trabajo paraarquitecturaThe Open Group es un consorcio de usua-rios y fabricantes de la industria de TI que cuenta con varios foros, de los cuales el de arquitectura ha sido uno de los más activos, una de las conclusiones de este foro en 1994 fue que era necesario desarrollar un marco de trabajo para la arquitectura empresarial, resultando de esta iniciativa el Marco de Tra-bajo para Arquitecturas de The Open Group (TOG Architecture Framework, o TOGAF).

Aunque TOGAF no es el único marco de tra-bajo para la arquitectura de software. Algu-nos de los más relevantes al momento son:

• The Zachman Framework for Enterprise Architecture.• TOGAF.• The Federal Enterprise Architecture (FEA).• The Gartner Methodology.


Sin embargo estos marcos de trabajo tienen una estructura y enfoque distintos entre ellos. Al de Zachman se le conoce mas como una taxonomía, el de TOGAF se enfoca más en el proceso, el FEA es una arquitectura empresarial implementada y el de Gartner es la experiencia y conocimiento acumulada por algunos expertos para desarro-llar buenas arquitecturas empresariales.

Dado el interés de la industria, en nues-tra empresa hemos decidido seleccionar a TOGAF como la opción para incrementar el catálogo de cursos al público. Además de ser la opción más madura al plantear un proceso para desarrollar la arquitectura.

TOGAFPara TOGAF la arquitectura de TI empresa-rial no tiene que ver sólo con las aplicacio-nes de la organización. Pues, propone una arquitectura de TI que funcione para el ne-gocio, es decir, que este alineada y apoye a las estrategias del negocio.

La arquitectura de TI empresarial considera las arquitecturas técnicas y de negocio, crea una visión estratégica y lleva esa visión has-ta su implementación.

TOGAF tiene tres componentes principales para lograr lo anterior:

• Método para desarrollar la arquitectura.• Enterprise continuum.• Base de recursos de TOGAF.

El enterprise continuum es un repositorio virtual de patrones, modelos, descripciones de arquitectura y otros artefactos, que cons-tituyen en si un marco de trabajo dentro del marco de trabajo de TOGAF, que sirve para clasificar tanto el material del repositorio como al resto de modelos relevantes y simi-lares que existen en la industria.

La base de recursos es el conjunto de linea-mientos, plantillas e información relaciona-da. El Método para desarrollar la arquitectu-ra (Architecture Development Method, ADM) lo detallaremos en la siguiente sección.

TOGAF más que ayudarnos a describir una Arquitectura Orientada a Servicios (SOA por sus siglas en inglés) particular, nos ayudará a decidir si SOA es lo mejor para el proyecto.

La metodología de TOGAF ayuda al arquitec-to a destilar el proyecto hasta el punto de tomar la decisión de si SOA es el estilo de arquitectura que nos ayudará a resolver me-jor el problema original.

El método para desarrollar la arquitecturaEl ADM de TOGAF es una especie de “CMMI para arquitectura”. Nos presenta un proceso iterativo con fases que se deben realizar para desarrollar la arquitectura, definiendo las en-tradas y salidas de cada fase pero sin indicar-nos como hacer cada uno de los entregables.

Figura 1. Fases del ADM de TOGAF

La fase preliminar es el momento en el cual se inicia el proceso de adopción del ADM al interior de la organización, difundiendo los beneficios e involucrando a todos las perso-nas necesarias.

• Fase A. Visión de la arquitectura, impli-ca desarrollar una visión de la arquitec-

tura definiendo el alcance y la estrategia para lograrla.

• Fase B. Arquitectura de negocio, se busca tener clara la arquitectura de negocio y sus metas para posteriormente poder alinear la TI al negocio.

• Fase C. La arquitectura de sistemas de in-formación contempla las arquitecturas par-ticulares para datos y aplicaciones.

• Fase D. La arquitectura tecnológica define la arquitectura integrada que se desarrolla-ra en fases futuras.

• Fase E. La fase de oportunidades y solucio-nes permite determinar qué partes se com-prarán, construirán o reutilizarán y cómo se implementará la arquitectura de la fase D.

• Fase F. El plan de migración sirve para prio-rizar los proyectos y desarrollar el plan de migración.

• Fase G. Control de la implementación es la ejecución de los proyectos para construir las soluciones de TI.

• Fase H. La administración del cambio de la arquitectura implica monitorear y evaluar los sistemas existentes para determinar cuándo iniciar un nuevo ciclo de ADM.

ConclusiónContar con y conocer un proceso bien definido que nos indica paso por paso cómo se debe desarrollar la arquitec-tura empresarial es indispensable para un buen arquitecto. De otra forma no existe un consenso respecto a los do-cumentos y diagramas que se deben tener para definir la arquitectura de un sistema de software. Sin embargo el ADM, como cualquier modelo de pro-cesos, debe adoptarse gradualmente, sin intentar implementarlo de inmedia-to al 100% y en todos los proyectos.

RequirementsManagement

C.InformationSystems

Architecture

G.Implementation

Governance

F.MigrationPlanning

E.Opportunities

andSolutions

D.TechnologyArchitecture

B.Business

Architecture

A.Architecture

Vision

Prelim:Framework

andPrinciples

H.Architecture

ChangeManagement


// PM CORNER

La integración de un equipo detrabajo funcionaLreto del líder de Proyectos de tecnologías de inForMaciónPor Francisco Vaca

Francisco Vaca Gómez es socio director TEDE de 2006 a la fecha. Ha realizado diseño e implementación de proyectos de educación basados en competencias, instrucción de programas de educación basados, investigación y promoción de la educación basada en competencias.

En este artículo reflexionamos sobre la difi-cultad que tienen los líderes de proyectos para integrar equipos de trabajo altamente funcionales y productivos. En muchos casos la solución consiste en utilizar enormes can-tidades de energía personal y de la organiza-ción para “hacer que las cosas sucedan” con lo cual pudiera parecer que se logran los re-sultados sin embargo los altos costos y efec-tos negativos secundarios no son evidentes. Proponemos que la labor de líder más que asegurar que “todos estén trabajando” con-sista en crear un contexto apropiado de tra-bajo en el que las personas que participan en el proyecto o en la tarea se integran de forma voluntaria y ordenada.

“El mercado laboral para los profesionistas de TI demanda cada vez más personas con competencias para la conducción de grupos de trabajo bajo condiciones de alta presión, ambigüedad y recursos limitados”

Esta afirmación no parece contener gran sabiduría ni grandes capacidades de obser-vación para llegar a ella, sin embargo para el profesional de las tecnologías de informa-ción de principios del siglo XXI puede arrojar algunas reflexiones interesantes.

Centrémonos en las competencias para la conducción de equipos de trabajo: Una carrera profesional exitosa conduce, en muchos casos, a un punto en el que se tie-ne a un grupo de personas sobre las que hay poco o ningún poder formal, un objeti-vo que cumplir, recursos limitados y unas expectativas enormes para cumplir fechas y presupuestos para entregar un produc-to terminado.

Al final a base de “puro músculo” vamos avanzando y unos pocos días, semanas, meses o años más tarde entregamos un producto que hace cosas que se planearon, más cosas que no se planearon, otras más que ni se pidieron ni se planearon pero que ahí están a un costo 10%, 50%, 200% más alto del que se estimó al principio.

¡Listo!, ¡El siguiente! y vamos de nuevo… a vivir otra vez la misma película.

Una forma más razonable para iniciar el pro-ceso de conducción del equipo consiste en tener un mejor punto de partida:

• Las personas no son integradas, las perso-nas se integran. No hay autoridad formal por grande que sea, que ordene a una persona “intégrate” y que ésta se integre. A la larga (posiblemente más temprano que tarde) ha-brá problemas que pueden ir desde una re-sistencia pasiva hasta resistencias activas que producen conductas “tóxicas” para el equipo.

• Las personas tienen una jerarquía de valo-res a partir de los cuales actúan y no necesa-riamente están alineados con los valores que se necesitan para cumplir con los objetivos.

• Las personas tiene egos que los hacen ac-tuar de forma individual, defensiva, y hasta de forma agresiva.

• Las personas no comparten un objetivo por el simple hecho de comunicarlo y por más que creamos que es atractivo y deseable.

La labor del líder consiste en crear las con-diciones apropiadas para que las personas

En este momento “crítico” los únicos patro-nes de conducta para conducir al equipo de trabajo posiblemente sean los aprendi-dos en la propia empresa o institución, los cuales resultan insuficientes con mucha frecuencia y los aprendidos en otros sitios posiblemente no se puedan aplicar.

Ante el reto de la conducción del equipo planteemos el primer paso: La integración del mismo lo cual supone encontrar res-puestas a peguntas como; ¿por dónde em-piezo?, ¿cómo “integro” al equipo?, ¿cómo hago para que “se pongan la camiseta”?.

Hemos visto como muchas personas (aún profesionales con largas carreras) no tienen buenas respuestas ya que su punto de parti-da contiene supuestos falsos u obsoletos:• “Son profesionales, tienen que cumplir el objetivo planteado”• “Es su chamba, no se los tengo que pedir”• “Estamos en el mismo barco”• “Hay que echarle ganas”• “Sé que tenemos algunas indefiniciones, pero vamos comenzando y las vamos resolviendo”• “Nos llevamos muy bien”

Poco tiempo después comienzan los proble-mas y las frustraciones: cada quien “jala” por su lado, la gente dice que sí pero no cumple, no hay compromiso, no hacen caso… los trucos que utilizamos parecen no funcionar: hablarles suavecito o duro, leerles la cartilla, acusarlos con los jefes, hacer minutas detalladas, listas de tareas, estar detrás de ellos presionándo-los… nada parece moverlos hacia delante ni motivarlos lo suficiente… a pesar de esto los vemos ocupados y dedicándole largas horas a su trabajo pero ¿y los resultados?.


puedan elegir de forma libre y voluntaria for-mar parte del equipo. Estas condiciones son:• Mantener el ego del líder bajo control.• Alinear los valores de las personas con los valores que necesitamos.• Objetivo compartido.• Claridad del rol.• Claridad en la responsabilidad.

A continuación procedemos a describirlas:

• Mantener el ego del líder bajo control. Un ego bajo control consiste en primer lugar en reconocer que necesitamos cambiar, ajustar o adquirir conductas más efectivas para in-tegrar un equipo.

En segundo lugar aceptar a las personas tal como son: con sus fortalezas, debilidades, valores y objetivos personales.

Por último significa aceptar que nuestra res-ponsabilidad es asegurar que permitimos y facilitamos el crecimiento y desarrollo de los demás, inclusive en circunstancias que im-pliquen “el de ellos antes que el mío”.

• Claridad del rol. Tener claridad sobre el rol que le toca a cada persona consiste en que ésta, tiene claro cómo es su aportación al equipo, en general los roles que definen, aprueban, construyen y controlan.

• Claridad en la responsabilidad. La res-ponsabilidad consiste en que cada miembro del equipo conoce y acepta los resultados que dependen de su intervención directa y por supuesto las consecuencias de que esos resultados no se den.

• Alinear los valores de las personas con los valores que necesitamos. La alineación de los valores consiste en lograr un acuer-do sobre lo que es importante para el logro del objetivo y el desempeño del equipo, por ejemplo ¿qué es más importante el tiempo o el presupuesto?, ¿la rapidez o la calidad?, ¿la innovación o la confiabilidad de la solución?.

En los casos que mencionamos podemos ver que lograr uno, es a costa de no cumplir el otro, esta situación puede provocar que una persona nos diga “SI” y luego descubramos que hizo otra cosa muy diferente.

• Objetivo compartido. No lograremos que las personas compartan un objetivo repi-tiéndolo una y otra vez; una forma segura de lograr que las personas compartan el ob-jetivo es hacerlos participes del proceso de formulación y acuerdo de los objetivos.

Pudiéramos recibir un objetivo general pero podemos establecer muchos objetivos in-termedios que vayan conformando el cum-plimiento del gran objetivo.

ConclusiónPodemos agregar que una barrera muy significativa que encontramos para “iniciar por el principio” consiste en que recibimos presión o nosotros mismos nos presionamos para pasar de inmediato a la acción, sin darnos cuenta que se van a evitar muchos conflictos, reprocesos y errores por no dedicarle el tiempo necesario a inte-grar al equipo.


// COLUMNA INvITAdA

46

Carlos “Fofo” Ordóñez es Ingeniero en Sistemas Computacionales por el ITESO. Cuenta con varias certificaciones por IBM y Sun Microsystems. Actualmente dirige un conjunto de proyectos de desarrollo en el centro de entrega global de TATA Consultancy Services. Es profesor asociado del ITESO, donde imparte materias de diseño, programación e Ingeniería de Software. La información en este artículo representa el punto de vista del autor y no necesariamente el de TATA Consultancy Services o ITESO. [email protected]

Desde hace mas de 40 años, cuando se adopta a la ingeniería de software como modelo para crear programas de cómputo, los inge-nieros de software nos hemos dado a la tarea de asignar diferentes analogías acerca de cómo entender el desarrollo de software, basta con hacer una búsqueda con el texto “Desarrollar software es como” para darnos cuenta de la utilidad y creatividad que encontramos para explicar nuestra realidad, pues al final, un sistema de cómputo es una abstracción, una simulación en bits de lo que nos acontece.

Una analogía se realiza asumiendo que si dos entes son semejantes en uno o varios aspectos, entonces es probable que se parezcan en otras facetas, este escrito pretende ser un panfleto técnico donde se analizan algunas analogías planteadas y cuyo único objetivo es el sembrar la semilla de la reflexión en todos aquellos colegas que se apasionan por eso que llamamos: Ingeniería de software…

De la poesía

Esta analogía, parte del hecho que el software, al tener un lengua-je, se lee y se escribe, Richard Gabriel dijo: “Desarrollar software es como escribir poesía, antes de hacer un buen poema tienes que leer miles de fuentes para aprender a escribir con la métrica adecuada y adoptar un estilo propio”. Esta analogía parece muy buena, pues si analizamos el proceso de escribir poesía, normalmente se comienza por redactar un párrafo, para luego evaluarlo y darnos cuenta que no es lo que buscamos y destruimos el papel donde está escrito.

Después escribimos un nuevo párrafo, y nuevamente lo desecha-mos porque no cumple con las características necesarias y a generar un nuevo párrafo, este último parece no estar tan mal, se adapta, se

mejora y al terminar el proceso tenemos un excelente párrafo, claro, con la inversión/desperdicio de una considerable cantidad de tiem-po al haber tirado tres borradores antes de llegar al definitivo.

Esta analogía al igual que todas aquellas donde se compara la in-geniería de software con un proceso de arte creativo (producción cinematográfica, escultura, pintura) por experimentación, ha sido de gran utilidad pues al evaluar nuestro proceso desde este enfoque nos damos cuenta que esta aproximación, jamás será la opción mas óptima cuando ya sabemos qué es lo que queremos desarrollar y conocemos las restricciones, pero sí funcionará para la creación e investigación de nuevas e innovadoras piezas de software.

De la línea de producción

Esta analogía nos permite comprender como el proceso de desa-rrollo de software, desde una perspectiva de fabricación en serie, donde con base en una especificación inicial, el producto se cons-truye, se valida, se empaca y se entrega, en esta categoría caen to-das aquellas analogías que hacen referencia a una cadena de valor: manufactura, restaurantes de comida rápida, ensambladoras, etc. Principalmente se enfocan en como detectar lo que realmente le está agregando valor a mi producto terminado.

Esta es una analogía muy común, y que llega a su formalización con la liberación del “Framework for Software Product Line Practice”, un marco de trabajo creado por el SEI (Software Engineering Institue) donde claramente se define una línea de producción de software como: “(…) Subconjunto de sistemas de software que comparten funcio-nalidades comunes satisfaciendo las necesidades específicas de un

Desarrollo de Software, Analogíasy Algo Más… cUidado con las seMejanzasPor Carlos Ordóñez


“Comparar con otras actividades, es útil cuando te permite formular preguntas, pero es peligroso cuando lo utilizas para justificar

tus respuestas”.

segmento en particular, y que son previamente desarrolladas con base en un conjunto de activos de forma preescrita”

Ese proceso de fabricación implica el uso de entornos de desarro-llo especializados y configurados como esquemas, Domain Specific Languages (DSLs), patrones, frameworks, generadores de código, librerías especializadas, etc, todos coordinados y definidos de tal forma que integrados formen un tipo determinado de aplicaciones.

“Los conceptos de fábrica se aplican de forma correcta a compañías donde se necesitan desarrollar varias versiones de sistemas simila-res o la construcción de soluciones basadas en un conjunto de re-querimientos bien entendidos y con muchas restricciones externas” (CUSUMANO Michael, “The business of Software”, Nueva York, 2004).

Como lo escribe Cusumano, esta aproximación funciona para desa-rrollos repetitivos y para un dominio o industria en especifico, pero como podemos notar, el proceso creativo queda completamente mermado por el proceso de construcción, y los problemas comien-zan cuando queremos incluir como parte del proceso de fabricación un desarrollo de investigación para crear nuevas piezas de software, donde no existe un conjunto de activos que nos permiten fabricar los componentes de nuestra aplicación.

De la ingeniería civil

Esta analogía ha sido utilizada por muchos años y se fundamenta en las similitudes que existen entre el proceso de construcción inmobi-liaria y el proceso de desarrollo de software.

Es un hecho que no es lo mismo edificar una casa pequeña, que construir un rascacielos, pero para ambos se necesita analizar las necesidades, diseñar un conjunto de planos, comenzar la cons-trucción, validar que esté quedando como fue acordado y final-mente entregarla.

Como en cualquier proyecto de ingeniería, necesitas un plan para gestionar el proyecto, considerar componentes existentes que se

pueden integrar, un conjunto de principios y herramientas estanda-rizadas para la construcción. Puedes gestionar el proyecto de inicio a fin, o dividirlo en pequeñas mejoras (Iterativas) con revisiones pe-riódicas con los involucrados.

La polémica comienza cuando incorporamos la siguiente cuestión: Los edificios son bienes físicos, mientras que el software, es un bien intelectual”, y desde esta perspectiva, el software nos permite rea-lizar transformaciones imposibles en el mundo físico. Esto cambia por completo el panorama, pues los principios y reglas de los que hablamos anteriormente, en el mundo del software permanecen en constante evolución, y es entonces cuando nuestros proceso de di-seño, con base a un conjunto de necesidades tiene que tomar en cuenta que el entorno se modificará y los involucrados cambiarán de parecer, y será entonces necesario crear una nueva pieza de soft-ware, donde este proceso es un proceso creativo, mas parecido al de escribir poesía.

De la ingeniería de softwareLa ingeniería de software es un campo muy joven aun, tan-to que resulta imposible evitar su evolución, y como conse-cuencia las analogías con las que la describimos tienden a cambiar por completo, de ser complementarias a ser conflic-tivas, algunas mejores que otras, todas tratando de expli-car nuestra experiencia, lo que no es válido es tratar de forzar nuestros procesos para adaptarlos a la analogía, pues al final, la ingeniería de software es un modelo procesal para desarro-llar sistemas de cómputo que cumplan con las necesidades de los involucrados, y jamás será: “hacer hamburguesas de McDonalds”, “edificar construcciones”, “escribir novelas”, “fabri-car panecillos”, “hacer una película” o “cocinar chilaquiles”.

“Comparar con otras actividades, es útil cuando te permite formu-lar preguntas, pero es peligroso cuando lo utilizas para justificar tus respuestas (…), esto nos puede ayudar a revisar nuestras prácticas desde un punto de vista diferente, a cuestionarnos sobre como tra-bajamos”. Martin Fowler, December 2004.

ConclusiónPodemos utilizar las analogías para facilitar la comprensión y explicar partes del proceso, pero jamás para explicar todo el ciclo, porque ese ciclo es único y flexible, pues desde mi punto de vista eso hace que la nuestra, sea un rama única e incomparable.


/*teNdeNCIAs eN sOFtWARe*/// COLUMNA

¿La Muerte del Software en su Forma Actual?el FUtUro de WindoWs: “strata”

Luis Daniel Soto Es Director de Divulgación Tecnológica para Microsoft . Responsable de la cuarta área de trece a nivel mundial en atención a desarrolladores de software. Coordina el esfuerzo de un grupo de 100 personas encargadas de Divulgación Tecnológica en América Latina. Ingeniero en computación por la Fundación Arturo Rosenblueth, especialista en el tema de liberación al mercado de nuevas tecnologías y toma electrónica de decisiones. [email protected] luisdans.com\Twitter

El debate sobre que el 90% del software que hoy se utiliza pueda ser entregado como servicio está energizando las conversaciones del futuro del software, creando encabezados alarmistas. El anuncio de la muerte del software en su forma actual es prematuro: estamos observando una evolución y no una revolución.

Antes y después de InternetHay que señalar que el requerimiento de las empresas, es utilizar el software para desarrollar mejor su negocio y ofrecer ventajas com-petitivas, sin importar el mecanismo de entrega. Es absurdo el abrir-se a ultimatum “todo o nada”. Aclaremos las razones iniciando por entender las ventajas de dos modelos.

¿Cómputo en la nube?Aquí hay una primera confusión de términos: Web 2.0 se refiere a habi-litar “la era de la participación” y “un internet más allá de texto e imá-genes”. El problema es que el desarrollo de estas aplicaciones es muy complejo. Integrarlo a los sistemas existentes es otro reto significativo. Hay que entender cuál es la visión de “cómputo en la nube” de cada proveedor. ¿Es un outsorcing convencional? EDS e IBM han jugado en este campo por años. En Microsoft creemos que la diferencia funda-mental está en la capacidad de construir software a la medida de forma simple. Windows “Strata” es el nombre clave que ofrece:

• Menores costos. Mediante economías de escala de Internet, se ofrece arquitectura y ambiente escalable para que los desarrolladores ofrez-can servicios en Internet a costos menores que operados localmente.• Capacidades totales. Las ofertas iniciales de almacenamiento en la nube imponen restricciones en manipulación de datos. Pretende-mos que todas las funciones de la plataforma aplicativa .NET, SQL Server y Biztalk operen para construir todo tipo de aplicaciones.• Mayor productividad. Visual Studio no solo ofrecerá desarrollo para cliente, dispositivos portátiles y servidor: también para la nube.

Windows “Strata” incluye servicios fundamentales y servicios para construir aplicaciones, que permiten a los terceros entregar software. La mejor manera de disipar dudas de disponibilidad y seguridad es iniciando su evaluación inmediatamente.

· Respuesta inmediata por el uso de recursos locales· Opera fuera de línea, sin red· La privacidad está en control del usuario· Usuarios acostumbrados a esta experiencia· Alta capacidad de ser personalizado· Visibilidad y control· Alta manipulación de datos con aplicaciones

· Redundancia de datos· Alcance mundial· Aprovisionamiento sencillo· Agilidad empresarial· Administración· Instalación casi nula· Acceso sencillo · Mantenimiento y nuevas versiones ocurren de forma automática· Acceso desde casi cualquier dispositivo a (casi) cualquier hora

· Nuevos modelos de negocio

Software tradicional Software entregado como servicio

Pocos argumentarían que Internet ha transformado nuestras vidas de forma muy amplia. Casi nadie está en desacuerdo con que el te-ner la flexibilidad y opción de seleccionar una forma mixta de operar es crítica para el negocio. Es poco realista pensar que una empresa Fortune 50 tiene los mismos requerimientos que una empresa pe-queña o un estudiante. Las normas de privacidad de datos en algunos países hacen difícil entender un escenario 100% en la nube. ¿Cómo una PyME en crecimiento puede transferir requerimientos básicos de cómputo en otros más avanzados?. La visión miope de entrega como servicio es incapaz de permitir conversaciones balanceadas.

La combinación de “clientes” y “centros de datos” tanto internos como externos permiten edición dinámica en una PC, movilidad del teléfono y ubicuidad de trabajo. Las suites web como Netsuite y Zoho ofrecen ahora operación fuera de línea con Microsoft Office. Salesforce.com y Google Gears son ejemplos del reconocimiento de este modelo. Apple también lo reconoce:

“I think the marriage of some really great client apps with some really great cloud services is incredibly powerful and right now, can be way more powerful than just having a browser on the client ”– Steve Jobs

Los clientes como Windows 7 y Windows Mobile 6.5; y el software en servidor continuarán un trayecto de evolución que responde a la juventud de la industria: hay mucho por hacer y ofrecer.

ConclusiónEl debate real es como las empresas atenderán las necesida-des de los distintos tipos de usuarios aprovechando los avan-ces de hardware en los dispositivos electrónicos portátiles y la innovación de software – la ubicación no importa... La nube es todo, pero sola, no es nada.

» Por Luis Daniel Soto

Servicios Terminados

• Soluciones personales

“Windows Live”

• Soluciones empresa-

riales “Microsoft online”

Bloques de construcción

Dispositivo, Sincronizar, Admi-

nistración de aplicaciones,

Identidad, Control de acceso,

Gestión de Base de datos, Flu-

jos de Trabajo, Bus de servicios...

Servicios Básicos

Cómputo (10% CPU, 1 CPU,

5000 CPUs), Almacena-

miento, Administración de

servicios, Redes, Distribu-

ción, Operaciones, Hardware

Servicios terminados Bloques de construcción Servicios básicos


// COLUMNA /*PRuebA de sOFtWARe*/

Complejidad del SoftwareUna Métrica iMPortante Para la PrUeBa de soFtWare

Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software. Fue profesor-investigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de dicha disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos relacionados con la prueba de software.

En el número pasado, al hacer el aná-lisis de los resultados del Concurso e-Quallity 2008 (ver e-quallity.net), ha-cíamos referencia a la complejidad de los productos participantes.

Aunque no es el único, la complejidad es un atributo del software muy útil al distri-buir adecuadamente el esfuerzo de prueba, porque ahí donde hay más complejidad hay más propensión a errores1.

No estamos hablando de dificultad de desa-rrollo, que es algo más bien subjetivo que guarda dependencia con el nivel de expe-riencia del desarrollador, sino de un aspecto que puede ser medido de manera objetiva.

Veamos a detalle esta característica.

Las caras de la complejidad del software Podemos hablar de dos vistas de la comple-jidad de un producto de software: la exter-na, que tiene que ver con el problema que resuelve el sistema (el proceso de negocio); y la interna, que se refiere a la manera como está programada la solución.

En la interna podemos distinguir al menos los siguientes aspectos:

• Su tamaño. Entre más grande sea un pro-ducto, mayor será su complejidad. Una mé-trica de tamaño (bastante primitiva, pero muy accesible y común) son las líneas de código (LCs).

• Su estructura. Consideremos las siguien-tes abstracciones de subrutinas:

1. Una subrutina de 10 LCs con instrucciones primitivas (v.gr. asignaciones):

(n) { 1: I1.1; 2: I1.2; … 10: I1.10; }

Una subrutina de 7 LCs con instrucciones compuestas y primitivas:

f2 (n) { 1: I2.1; 2: if Cond2.1 then 3: I2.2; 4: else 5: while Cond2.2 6: I2.3; 7: I2.4; }

Una subrutina de 5 LCs con instrucciones compuestas y primitivas:

f3 (n) { 1: I3.1; 2: if Cond3.1 then 3: f3 (Exp3.1); 4: else 5: f3 (Exp3.2); }

Si no tomáramos en cuenta la complejidad interna, sino sólo el criterio del tamaño, di-ríamos que f

1 es la más grande de las 3 su-

brutinas, pues tiene más LCs. Sin embargo, puede verse que no tiene la misma compleji-dad una secuencia de x instrucciones primi-tivas, que otra de llamadas recursivas.

Durante el análisis sintáctico, los compiladores se dan cuenta de la cantidad de instrucciones de las que consta el programa que se procesa, y verifican si la estructura de los programas siguen las reglas gramaticales del lenguaje en cuestión2. Sería relativamente sencillo im-plementar una métrica inductiva dentro de los compiladores, que durante el procesamiento de un programa asociara una complejidad a cada tipo de construcción (tanto de datos como de control) para obtener la complejidad del todo combinando las de las partes.

Del programa se puede obtener automática-mente la complejidad interna de la solución.

La externa nos habla de la complejidad del problema, de la funcionalidad que se re-quiere del producto.

Una métrica utilizada para medir este tipo de complejidad son los puntos de función3, que tienen la interesante ventaja de que se pueden obtener incluso a partir de los requerimien-tos. Una desventaja es que, si bien el algorit-mo para calcularla no es complejo, no es tri-vial y sí es laborioso; lo peor es que obtenerla automáticamente a partir de requerimientos –cuando resultaría más útil– es prácticamen-te imposible a menos que éstos hayan sido especificados utilizando un lenguaje formal (como los de programación), situación casi exclusiva de los métodos formales4.

Impacto de la complejidad en la prueba de software Como mencionamos, ahí donde la comple-jidad en el software es mayor, hay más pro-pensión a errores, lo que en particular impli-ca que debemos probar más.

Esto también podemos verlo si comparamos los grafos de control asociados a las prime-ras subrutinas mostradas arriba:

Figura 1. Izquierda: grafo de f1; derecha: grafo de f2


“Podemos hablar de dos vistas de lacomplejidad de un producto de software:

interna y externa”.

En el segundo grafo, la cantidad de rutas distintas necesarias para visitar todas las aristas es mayor, lo que hace crecer también la cantidad de casos de prueba que se de-ben diseñar y aplicar.

Algunas reflexiones• Es muy importante tratar de mantener lo más simple posible los diseños y los progra-mas de los sistemas que se desarrollan. Esto no solo reduce la probabilidad de introducir errores, sino que puede facilitar el manteni-miento, el reuso, y la prueba de software.

• La complejidad interna que considera la es-tructura de un sistema ofrece un dato más pre-ciso que la métrica primitiva de la cantidad de líneas de código. Sin embargo, a pesar de que ese dato podría proporcionarlo fácilmente los compiladores, no es algo que suelan proveer.

• Sería muy útil obtener de manera automática la complejidad externa de un sistema (asociada a la funcionalidad) en fases tempranas del pro-ceso de desarrollo de software (luego de espe-cificar los requerimientos), pues ello aceleraría también el resto del proceso (comenzando con las estimaciones e incluyendo las pruebas).

Referencias[ 1. León-Carrillo, L. “The Impact of Software Testing in small Settings”, en Oktaba, H. and Piatini, M. Software Processes in small Enterprises. IGI Global, 2008. ][ 2. Aho, A.; Lam, M.; Sethi, R.; Ullman, J. Compilers: Principles, Techniques, and Tools. Second edition. ][ 3. Garmus, E.; Herron, D. Function Point Analysis: Measurement Practices for Successful Software Projects. Addison- Wesley ][ 4. Jean-Francois Monin, J-F. Understanding Formal Methods. Springer Verlag. ]


// TECNOLOGÍA /*INFRAestRuCtuRA*/

52

Tecnología RFID Como Dispositivo de SeguridadnoVedades en el 2008

Por Beatríz Ríos y Luis Joyanes

El presente artículo pretende mostrar un resumen del estado del arte sobre las tecnologías RFID (Radio Frequency Identification, identifi-cación por radiofrecuencia), se presentan algunas noticias importan-tes publicadas en la página oficial de RFID en España y las distintas controversias que la tienen en el campo de la investigación.

Tecnologías RFIDLa seguridad de las computadoras se enfoca principalmente a evitar que la información almacenada sea alterada, robada o interceptada para realizar delitos informáticos, el campo incluye la protección de transferencias de fondos electrónicas, información propietaria (dise-ños de producto, listas de cliente, etc.), programas de computadora, otras comunicaciones y la prevención de los virus.

Existen en la actualidad un gran número de soluciones, herramien-tas y dispositivos disponibles, dependiendo de lo que requiera mayor atención, entre ellos, los nuevos y avanzados dispositivos usados como herramientas de monitoreo, la tecnología llamada: RFID, que ha creado un gran debate entre diversos planos secto-riales, ya que tiende a suponer grandes beneficios en la gestión de la cadena de suministros, sobre todo en el sector de alimentación, farmacéutico y bebidas.

Su implementación abarca un radio amplio de aplicaciones como: salud, alimentación, fabricación, transporte, distribución, ventas, seguimiento de ganado, localización de niños y animales, anti-robo, construcción, alquiler de equipos, pago inteligente, venta inteligente de boletos, control de acceso a edificios, servicios pú-blicos, aéreo, etc3.

¿Qué es RFID? Es un sistema basado en agentes dentro de tarjetas y lectores, es una tecnología, un método de identificación automática para el in-tercambio de datos remotos usando dispositivos llamados etiquetas de RFI o repetidores1.

Una etiqueta RFID es un dispositivo pequeño, que puede ser adheri-da o incorporada a un producto, animal o persona.

Beatríz Ríos catedrática del Instituto Tecnológico de San Luis Potosí, México. Ha trabajado en la banca en México, participado en el desarrollo de sistemas para empresas y docencia en ingeniería de software, sistemas operativos, lenguajes de programación. Actualmente estudiante del doctorado en Informática en ingeniería de Software en Universidad Pontificia de Salamanca en Madrid, España.

RFID es un término genérico para describir un sistema que transmite la identidad de un objeto o persona (en forma de un único número de serie) de forma inalámbrica, usando ondas de radio. Está agrupa-da en la categoría de tecnologías de identificación automática. Las tecnologías de identificación automática incluyen códigos de barras, lectores ópticos de caracteres y algunas tecnologías biométricas, como escaneo de retinas1.

Esta tecnología, junto al EPC (Código Electrónico de Producto), harán posible el rastreo y seguimiento de productos en tiempo real permitien-do una “visibilidad” casi perfecta de la mercancía desde el almacén de materia prima hasta el punto de venta1. El Código Electrónico de Pro-ducto es un número único que se graba en el chip contenido en una etiqueta RFID y se coloca en cada producto, lo que permite hacer un seguimiento exacto de cada unidad física en la cadena de suministros.

¿Dónde empezó todo?Durante la Segunda Guerra Mundial los Británicos desarrollaron el sistema llamado IFF, (Identify: Friend or Foe, Identificación: amigo o enemigo), sobre el que está basado el sistema actual de control de aviación privada y comercial. Esta aplicación fue el primer uso obvio de la tecnología de RFID. Otras de la primeras aplicaciones comerciales para RFID fueron en 1980 y 1990 las etiquetas de inven-tarios en pagos de tarifas de peaje en caminos, en pisos de tiendas o directamente en el ensamblado de automóviles.

Existen también versiones de este sistema para implantes en hu-manos, como VeriChip en 2006. La práctica de implantar el chip a las personas es limitada, la mayoría de los implantes son usados para fines clínicos, para alertar al personal médico de las condicio-nes que un paciente tiene, en el caso de que esa persona no pueda comunicar los síntomas.

México fue el primer país donde se usó para implantes en humanos en el 2004 se colocó un chip diminuto, menor que un grano de arroz a 18 agentes de la Procuraduría General de la República (PGR) para identificarlos cuando tuvieran contacto con documentos confiden-ciales y evitar así la corrupción4.


El presidente actual de Colombia declaró que se podrían implantar estos chips a los ciudadanos colombianos que quisieran ir a tra-bajar a Estados Unidos, para que el gobierno de ese país pudiera controlar su ubicación4.

Un reconocido club en Barcelona, España, utiliza un VeriChip para identificar a sus clientes VIP, lo utilizan para comprar las bebidas. El departamento de policía de la Ciudad de México ha implantado el VeriChip a unos 170 de sus oficiales de policía, para permitir el acceso a las bases de datos de la policía y para poder seguirlos en caso de ser secuestrados.

Un empresario del estado de Washington se implantó un chip RFID en su mano izquierda a principios de 2005. El chip medía 12 mm de largo por 2 mm de diámetro y tenía un radio de acción para su lectu-ra de dos pulgadas (50 mm). Cuando le preguntaron qué pretendía hacer con el implante, él respondió: “estoy escribiendo mi propio software y lo estoy soldando sobre mi propia materia, prácticamente esto es lo que deseo”.

ClasificaciónLas etiquetas RFID se pueden clasificar principalmente en tres cate-gorías, dependiendo del alcance y capacidad de memoria: pasivas, activas y semiactivas o semipasivas.

• Etiquetas pasivas. Tienen 2 componentes conectados entre sí, un microchip y una antena. Estas etiquetas son las de menor ta-maño, por ende las más livianas y con una vida útil que puede ir hasta los 99 años8.

Pueden proporcionar información sobre la identificación y localiza-ción sobre el producto marcado con la etiqueta como por ejemplo precio, color, fecha de compra, etcétera, son usadas en los puntos

Fábrica Almacén Supermercado

El Código de Producto (EPC) identiica inmediata-mente el contenido de los pallets descargados en el almacén de distribución.

Figura 1. Diagrama de cadena de suministro con RFID

53


Luis Joyanes Aguilar Dr. Ingeniería Informática, Dr. Sociología, Lic. en Ciencias Físicas y Lic. de Enseñanza Superior Militar. Titular de la cátedra de Lenguajes y Sistemas Informáticos de la Universidad Pontificia de Salamanca, Madrid. Ex-Decano de la facultad de Informática y Dir. del Departamento de Postgrado en Inge-niería Informática. Ha publicado más de 60 libros sobre tecnologías de la Información, profesor del programa de doctorado en Sociología, Guatemala. Ha impartido cursos de doctorado en las Universidades Complutense, Politécnica de Madrid y Oviedo. casadellibro.com/libros/joyanes-aguilar-luis/joyanes2aguilar32luis


de venta en estaciones de gasolina y edificios con sistema de control de accesos, no tienen fuente de alimentación propia.

Ejemplos de ellas tenemos: el sistema de compra rápida SpeedPass, funciona cuando el llavero con la etiqueta ondea enfrente de una área especial de la bomba de gasolina, una etiqueta lectora dentro de la bomba, lee el número secreto contenido dentro del disposi-tivo, que corresponde a la cuenta del cliente en curso del sistema SpeedPass, en este punto una insignia enciende la luz, (en este caso el tigre saltando) firmando el comienzo de la compra y es cargada a una tarjeta de crédito conectada a la cuenta del sistema SpeedPass, también se pueden comprar otros artículos como: botellas de agua, bolsas de botanas, etcétera.

En restaurantes de comida rápida trabaja exactamente igual, el clien-te coloca su orden, entonces ondea su llave enfrente del controlador del lector, si todo funciona como debería, el dispositivo se iluminará y dará la comida. Se espera implementar este sistema SpeedPass en 400 restaurantes.

Las etiquetas RFID de baja frecuencia se utilizan comúnmente para la identificación de animales, seguimiento de barricas de cerveza, y como llave de automóviles con sistema anti-robo. En ocasiones se insertan en pequeños chips en mascotas para que puedan ser de-vueltas a su dueño en caso de pérdida.

En algunos modelos de coches desde el 2004, está disponible una “llave inteligente” como opción. La llave emplea un circuito de RFID ac-tivo que permite que el automóvil reconozca la presencia de la llave a un metro del sensor, el conductor puede abrir las puertas y arrancar el automóvil mientras la llave sigue estando en la cartera o en el bolsillo.

Desde el 2004 se usa en el seguimiento de presos a los que se les colocan unos transmisores del tamaño de un reloj de muñeca que pueden detectar si los presos han estado intentando quitárselas y enviar una alarma a las computadoras de la prisión.

• Etiquetas semipasivas. Poseen baterías pero permanecen dor-midas hasta que reciben una señal proveniente de un lector. El rango de lectura de una etiqueta semiactiva, o semipasiva, puede

•Etiquetas activas. Las etiquetas activas RFID tienen cuatro com-ponentes: un microchip, una antena, una tarjeta de fuente de po-der y tarjetas electrónicas. La antena y el microchip tienen simi-lar función a las pasivas, las etiquetas activas poseen su propia fuente de energía y son capaces de alcanzar mayores distancias (10 metros aproximadamente), al poseer una batería su vida útil es de hasta 10 años.

Se utilizan en bibliotecas y seguimiento de libros, control de acceso en edificios, seguimiento de equipaje en aerolí-neas, seguimiento de artículos de ropa y en pacientes de cen-

ser de 30 metros bajo condiciones ideales, son mucho más pe-queños que las activas y tienen más memoria de almacenamiento que las pasivas.

En el manejo en la cadena de suministros de tiendas y librerías han usado artículos electrónicos de vigilancia de 1 bit desde RFID para controlar robos desde 1960. Etiquetas semiactivas indican si un ar-tículo ha sido robado o propiamente sacado de la tienda, ya que un cajero usualmente desactivará la etiqueta antes de salir.

El departamento de la Defensa de US y varios minoristas están condu-ciendo ya ensayos en la plataforma de RFID, de hecho una gran cade-na americana de supermercados dentro de EUA y México, exigió a sus 600 proveedores que adopten este sistema desde enero del 2007.


tros hospitalarios para hacer un seguimiento de su historia clínica. Las etiquetas RFID de microondas se utilizan en el control de acceso en vehículos de gama alta, algunas auto-pistas, como por ejemplo la FasTrak de California, el sistema I-Pass de Illinois, el telepeaje TAG en las autopistas urbanas en Santiago de Chile y la Philippines South Luzon Expressway E-Pass para recaudación con peaje electrónico. Las tarjetas son leídas mientras los vehículos pasan, la información se utiliza para cobrar el peaje en una cuenta periódica o descontarla de una cuenta prepago. El sistema ayuda a disminuir el tráfico causado por las cabinas de peaje6.

Aplicaciones

Desde 2004 Lisboa también hace uso de este sistema de control de acceso al centro de la ciudad. Estocolmo ha decidido usar la tecno-logía RFID para reducir gastos en el control del acceso. El sistema de peaje ha logrado reducir el tráfico en un 25% y ha incrementado el uso del transporte público en 40.000 usuarios más cada día

6.

Un dispositivo colocado en los vehículos permite identificarlos y aplicarles vía Internet un cargo de peaje con precios variables según la hora, el sistema también identifica las matrículas de los vehículos que no tienen ese dispositivo, obligándoles a realizar el pago opor-tuno en bancos o establecimientos autorizados.

Noticias importantes sobre futuras aplicaciones• Compras con RFID. Algunos clientes están considerando tener im-plantes de microchips para poder hacer compras7.

En 2006, la FDA (Food and Drug Administration) aprobó los primeros chips RFID de EE.UU. que se pueden implantar en seres humanos. El uso de RFID para prevenir mezclas entre esperma y óvu-los; en las clínicas de fecundación in vi-tro también se está considerado. Pueden incorporar información médica personal, podrían salvar vidas y limitar lesiones causadas por errores en tratamientos mé-dicos. También se ha propuesto su aplica-ción en el hogar para permitir por ejem-plo, que un frigorífico pueda conocer las fechas de caducidad de los alimentos que contiene, pero ha habido pocos avances más allá de simples prototipos.

Identificación de Pacientes

El nuevo documento de pasaporte a partir de agosto 2007 se emitió con este chip, algunos países como Canadá, Australia, EE.UU, Pakistan y en países de la Unión Europea ya lo tienen implantado. Tiene una mini antena que permite comunicarse con los datos, por medio de un lector RFID entre un radio de acción de 2 a 100 m.

Pasaporte

El estado de Virginia ha pensado en poner etiquetas RFID en las licencias de condu-cir, para hacerlos mas confiables y evitar que se puedan conseguir documentos de identidad falsos.

Licencia de Conducir

En Londres, el control de acceso con vehículos particulares en el centro está desde hace un tiempo limitado mediante un peaje, cuando lo instalaron decidie-ron apostar por un sistema de más de 800 cámaras que controlaran el acceso y pago del peaje mediante dispositivos RFID en los autos1.

Tráfico yPosicionamiento



El sujeto es identificado desde que entra (nombre, domicilio, tar-jeta de crédito, última visita a la tienda, tendencias de compra y gustos sobre ropa). La ropa lleva incorporada etiquetas RFID in-visibles. Antes de pagar, se le somete a una prueba de reconoci-miento facial para comprobar si efectivamente es quien su tarjeta de identidad dice que es. El sistema utiliza Internet y puede avisar a la policía si la persona sale de la tienda sin abonar la mercancía, así como proporcionarles información sobre dónde obtener foto-grafías on-line del sospechoso4.

• Planean “etiquetar” a los pasajeros aéreos. BBC News anuncia nuevos y espeluznantes avances en la dudosa ciencia del pre-crimen. El proyecto Optag desarrollado en el University College London, ha llegado a la brillante conclusión científica, de que etiquetar a los pa-sajeros de los aviones ayudaría a combatir el terrorismo7.

• La tarjeta inteligente, Visa con RFID. La Caixa introducirá en España las tarjetas de crédito equipadas con chip RFID, legibles a distan-cia sin necesidad de contacto físico con el aparato lector. La Caixa será la primera entidad financiera española en incorporar tecnología RFID a sus tarjetas de crédito12.

• Parece Polvo. El novedoso chip RFID de Hitachi que mostraron al mundo el pasado 13 de febrero 2007. Estos tienen un tamaño de 0.05 x 0.05 mm y son hasta 64 veces más pequeños que sus actua-les mu-chips de 0.4 x 0.4 mm, aparecerán en el mercado dentro de dos ó tres años más.

Pero no todo es perfecto con RFID• Logran clonar el VeriChip. Un investigador Canadiense anunció en el 2007 que logró clonar el implante subcutáneo RFID de VeriChip Corporation, pese a lo cual la empresa sigue afirmando en su Web que el chip provee de un identificador único y que el sistema es ab-solutamente seguro 8.

• El VeriChip podría causar la muerte. El bio-chip está compues-to de un transponder, un sistema de almacenamiento, lectura de información a control remoto y una batería de litio recargable, la que se recarga por un sistema termopar (dispositivo capaz de convertir la energía calorífica en energía eléctrica) que produce fluctuaciones de la temperatura del cuerpo, razón por la que se determinó después de varias investigaciones millonarias, que el mejor lugar para implantarla es en la cabeza o la mano derecha. Aunque la empresa sigue asegurando que el bio-chip es seguro, la verdad es que el litio que contiene al ser derramado en el in-terior del cuerpo, produce úlceras y daños en los tejidos, que si

se intentase quitarlo sin control médico podría producir daños severos y hasta la muerte13.

• Problemas de lectura con los pasaportes RFID. No sólo son menos seguros; ahora también sabemos que la lectura de los pasaportes con el chip son menos fiables (prácticamente la mitad) que la de los tradicionales, requiriendo más tiempo y atención por parte de los empleados. Eso es lo que afirma un estudio del propio Departamen-to de Estado de los EUA 8.

• Detectan fugas de información en las nuevas tarjetas de crédito con RFID. Herald Tribune publica un artículo que revela que infor-mación sensible de las tarjetas de crédito de última generación que incorporan chips RFID, puede ser leída por un intruso mediante un equipo electrónico cuyo costo aproximado son 150 dólares, pero que podría reducirse en tamaño hasta algo similar a un paquete de chicles y precio de construcción seri de 60 dólares. Las pruebas se han realizado sobre 20 tarjetas de Visa, MasterCard y American Express. Algunos fabricantes habían hecho creer a los usuarios que los datos irían cifrados.

• Peligros en datos biométricos. Fallos en RFID hacen peligrar los datos biométricos de los millones de personas que visitan Estados Unidos, para rastrear a los visitantes extranjeros tras su entrada por las dos fronteras terrestres de Estados Unidos, México y Canadá8. El controvertido RFID sigue “ganando enemigos” a lo largo y ancho de este mundo. Ahora son los usuarios del metro en Rheinberg, Alemania, que han descubierto que sus tarjetas llevaban escondi-do un chip RFID. Por el diminuto tamaño que está adoptando estos dispositivos, cada vez es más sencillo esconderlos en casi cualquier parte, desde billetes de banco, hasta boletos de metro.

Aún con todos los problemas mostrados con la tecnología RFID, re-presenta un gran avance su uso en la industria, ahorrará grandes tiempos en las líneas de producción, administración y distribución.

Las novedades de RFID en el 20081. Empresas en México con productos perecederos como las frutas y legumbres, implementarán RFID en su cadena de abasto, para mo-nitorear el estado de cualquier fruta y determinar cual deberá ser puesta primero en el mercado y ahorrarse una gran cantidad de di-nero al no tener que tirarla por estar en mal estado 9.

2. Se ha puesto en marcha el primer centro de distribución dirigi-da por voz en Colombia atreves de RFID. La distribución esta dirigi-da por voz y permite a los operadores recibir instrucciones paso a


Referencias[ 1. RFID, Identificación con seguridad. rfidding.com/1_definicion. html ][ 2. RFID, España, rfid-spain.com ][ 3. Tornton, Frank. et al. Computers Comunications NetWorking. 2006. ][ 4. Ribeiro, Silvia. “Chips Espías, manipulación del consumo e impactos sobre la salud”. La Jornada. México, 10/12/2006. ][ 5. Pink tentacle. pinktentacle.com/2007/02/hitachi-develops-rfid- powder/ ][ 6. “RFID para ayudar a reducir el tráfico”. Gobierno de Estocolmo. xataka.com/2006/04/12-rfid-para-reducir-el-trafico ][ 7. “RFID, Nineteen, eighty four,Etiquetar a los pasajeros en los aeropuertos”. Video: spychips.com/RFIDairport.html ][ 8. “RFID, Nineteen, eighty four”. Protestas e invasión a la privacidad. spychips.com/index.html, spychips.com/press-releases/verichip-hacked.html, kriptopolis.org/problemas-de-lectura-con-los-pasaportes-rfid ][ 9. RFID, México. mexicorfid.com ][ 10. Arkansas University. Video de proyecto U. Arkansas. es.youtube. com/watch?v=pNPG02uILXY ][ 11. DNI electrónico España. dnielectronico.es/oficina_prensa/ noticia_destacada/mapa_provin_desp_dnie.html ][ 12. Visa Europe. visaeurope.es/saladeprensa/notasdeprensa/ press42.jsp ][ 13. “VeriChip, VeryVIP, VeryDangerous”. trinityatierra.wordpress. com/2008/03/10/verichip-verivip-very-dangerous/[ 14. RFID Europe. rfid.idtechex.com/rfideurope08/en/rfidin2008.asp ]

ConclusiónLa aplicación más importante de esta tecnología es con propó-sitos comerciales, ahora tiene la atención en el mundo de los negocios, esta tecnología tiene un amplio rango de industrias con una gran variedad de usos.

La identificación de artículos mediante el código de barras, prácticamente estarán desapareciendo en un futuro inmedia-to, serán sustituidos por dispositivos con RFID, estándares y middleware sobre la tecnología RFID serán desarrolladas, también otras versiones sobre la seguridad y privacidad. Más de 250 corporaciones en 20 países están ya distribuyendo el

paso directamente del sistema de control de almacén a través de un Talkman Vocollect que se porta en la cintura y una diadema con mi-crófono, dejando las manos y la vista libres para realizar las labores sin interrupciones ni tiempos muertos 2.

3. La Universidad de Arkansas está utilizando una tecnología de van-guardia para explorar las ventajas potenciales de RFID usando un detallado hospital virtual creado en Second Life, los expertos están examinando la manera en que los dispositivos basados en RFID pue-den mejorar el sistema de salud en el mundo real 10.

4. Ahora no solo son utilizados los RFID en mascotas como perros y gatos, sino que además, se ha etiquetado algunos peces de las 20 especies más exóticas con el fin de mostrarles a los espectadores su ubicación en una pantalla, esto fue en un acuario en Singapur.

5. El 30% de las empresas españolas de logística y distribución ya han implantado RFID y el 83% se muestra satisfecho con ella.

6. Un 48% de las empresas (grandes y pymes) de diversos sectores en Es-paña, tienen pensado implantar RFID para control de procesos y logística.

7. Este año se ha anunciado como funciona los sistemas biométricos de huellas digitales y su uso en el nuevo DNI electrónico español 11.

8. Se ha anunciado la disponibilidad en España del nuevo lector de RFID modelo IP30, un dispositivo pequeño y compacto que puede integrarse en los dispositivos moviles más extendidos. De esta for-ma es posible combinar la RFID con otras tecnologías como la locali-zación por GPS y las redes extendidas inalámbricas 2.

VeriChip y muchas naciones ya fueron privilegiadas para usarlo, entre ellas: Reino Unido, Canadá, E.U.A., Australia, Nueva Ze-landa, Israel, Hong Kong, China, Indonesia, Macau, Malasia, Fi-lipinas, Singapur, Tailandia, India, Taiwán, Sri Lanka, Costa Rica, Guatemala, Nicaragua, Panamá, Honduras, el Salvador y Brasil.

El RFID Europa14, ha publicado que los países que más usan el dispositivo son: en primer lugar Asia con el 46% donde el país mayoritario es China además del tamaño de su población y de los proyectos de los juegos olímpicos que influyeron para subir los porcentajes de uso, le sigue Norteamérica con el 27% donde los países líderes son EUA y Reino Unido, Europa le sigue a la lista con el 17% donde lideran Alemania y Francia y el resto del mundo solo con 10% donde está incluido a Latinoamérica5.


/*MultICORe*/// TECNOLOGÍA

Perdiendo el Miedo a la Programación ParalelaejeMPlo de ordenaMiento de BUrBUja Paralelo Por Shannon Cepeda

Al igual que la mayoría de los ingenieros de sistemas, tengo malos recuerdos de lidiar con threads en mi clase de sistemas opera-tivos en la universidad. Así que cuando me encontré en la necesidad, ya como profe-sional, de aprender a hacer programas que se ejecuten en distintos threads paralelos, debo aceptar que tuve mucho miedo. Sin embargo, descubrí que actualmente hay herramientas que hacen esto mucho más sencillo de lo que pensaba.

Para reiniciarme en la programación parale-la, decidí comenzar haciendo el ejercicio de implementar un ordenamiento de burbuja (bubble sort) paralelo. Éste es uno de los algoritmos de ordenamiento más sencillos y lentos. La forma en que funciona es que se recorre una lista de elementos, y se va com-parando el elemento i con el i+1, y en caso de que el orden esté equivocado, se intercam-bia estos valores de posición. Este recorrido se repite n-1 veces (donde n es el número de elementos que contiene la lista) para asegu-rar que se hayan realizado los cambios ne-cesarios y la lista está ordenada.

Decidí ordenar palabras, ya que esto me daba una forma sencilla de repartir mis datos entre distintos threads (un thread podría ordenar las palabras que comienzan con “A”, otro las que empiezan con “B”, etc.).

Al iniciar, el programa debe leer un archivo con palabras, contar cuantas palabras co-mienzan con cada letra (sin diferenciar entre mayúsculas y minúsculas), y guardar esta cuenta en un arreglo unidimensional de 26 elementos llamado letter_counts. Esto signifi-ca que el valor de letter_counts[0] es la canti-dad de palabras que empiezan con la letra ‘a’, letter_counts[1] es la cantidad de palabras que empiezan con ‘b’, y así sucesivamente. El siguiente paso es volver a leer las palabras del archivo, y almacenarlas en un arreglo de arreglos (my_array), de acuerdo a la letra con la que empiezan. Es decir, my_array[0] apunta a un arreglo que contiene las palabras que comienzan con la letra ‘a’, my_array[1] contie-

ne un arreglo con las palabras que comien-zan con la letra ‘b’, y así sucesivamente.

Una vez que se genera este arreglo “semior-denado” –ya que las palabras se encuentran agrupadas de acuerdo a la letra con la que empiezan –, se puede invocar a la función que se encarga del ordenamiento.

Ordenamiento sin paralelismoPrimero realicé la prueba haciendo el orde-namiento de la forma tradicional, es decir sin paralelismo. El listado 1 muestra el códi-go en lenguaje C para hacer esto.

void bubble_sort (char *** &my_array, int letter_counts[26]){ char * temp; for (int letter =0; letter < 26; letter++) { for (int i =0; i < letter_counts[letter] - 1 ; i++){ for (int j =0; j < letter_counts[letter] - 1 - i; j++){ if (strcmp(static_cast<char *>(my_array[letter] [j+1]), static_cast<char *>(my_array[letter][j])) < 0){ temp = my_array[letter][j+1]; my_array[letter][j+1] = my_array[letter][j]; my_array[letter][j] = temp; } } } }

}

Listado 1. Ordenamiento sin paralelismo

El programa se ejecutó en una máquina con dos procesadores de cuatro núcleos, y al monitorear la ejecución me di cuenta que solo se usaba un núcleo. El tiempo de ejecu-ción del programa fue de 7.4 segundos.

Implementando paralelismo con OpenMPActualmente existen diversas librerías que abstraen y simplifican el manejo de threads. Una de ellas es OpenMP, la cual usé para este ejemplo. OpenMP es un API para pro-gramación paralela en C/C++ y Fortran. Es soportado por una gran variedad de compi-ladores incluyendo el compilador de Intel, gcc, y Visual Studio (2005 o mayor). Con OpenMP, es posible convertir un programa de un modelo single threaded a un modelo multithreaded sin necesidad de escribir un

solo fork, join, o siquiera crear un thread de forma explícita. Se implementa en el código por medio de directivas “pragma”. Como programador, lo único que necesitas hacer es determinar qué patrón de paralelismo re-quiere tu código, y entonces indicar la direc-tiva pragma correspondiente.

Uno de los elementos más sencillos y utili-zados de OpenMP es el pragma “parallel for”. Este corresponde a lo que sería un “for” en programación single threaded. Lo que hace es dividir un ciclo de tareas en rangos, y asigna un segmento de tareas a cada pro-cesador. OpenMP se encarga de crear los threads y asignarlos a cada procesador. En el caso de mi ejemplo, el pragma “parallel for” es justo lo que necesitaba, ya que mi algoritmo estaba estructurado en base a un ciclo maestro donde se trabaja de forma se-parada los distintos grupos de palabras en base a la letra con la que empiezan. Usando el parallel for a este nivel, no corría el riesgo de que dos threads accedieran el arreglo de la misma letra al mismo tiempo .El listado 2 muestra el código correspondiente, agre-gando el parallel for.

void parallel_bubble_sort (char *** &my_array,int letter_counts[26]){ char * temp; #pragma omp parallel for for (int letter =0; letter < 26; letter++) { for (int i =0; i < letter_counts[letter] - 1 ; i++){ for (int j =0; j < letter_counts[letter] - 1 - i; j++){ if (strcmp(static_cast<char *>(my_array[letter] [j+1]), static_cast<char *>(my_array[letter][j])) < 0){ temp = my_array[letter][j+1]; my_array[letter][j+1] = my_array[letter][j]; my_array[letter][j] = temp; } } } }

}Listado 2. Ordenamiento usando el parallel for

Eso fue bastante sencillo … ¿podría ser tan bello? Al ejecutar este código y monitorear el sistema me di cuenta que ya había acti-vidad en los distintos núcleos de procesa-miento. El tiempo de ejecución fue de 6.4


Shannon Cepeda ha laborado en Intel durante 7 años en roles relacionados con el análisis y optimización de desempeño de sistemas. Shannon es Ingeniero en Ciencias Computacionales, y Maestra en Ciencias de la Computación por la Universidad de Carolina del Norte.

segundos, lo cual significó una pequeña reducción. Sin embargo, al verificar los re-sultados encontré que había errores ya que el arreglo no había sido ordenado correcta-mente. Muy probablemente esto se debía a que generé un error de data race. Un data race es cuando distintos threads acceden y modifican una misma variable de forma no coordinada; típicamente esto genera resul-tados erróneos en el valor de las variables.

Depurando con Intel ThreadCheckerPara encontrar el error, decidí utilizar el In-tel Thread Checker. Este es un depurador para programas multithreaded. Lo que hace es monitorear la ejecución de un programa para encontrar errores como data races, deadlocks, fallas de sincronización, y tiem-pos de espera. La figura 1 muestra los resul-tados del Intel Thread Checker.

Los primeros dos errores indicaban que mis sospechas eran correctas. Al revisar las lí-neas referidas, noté que la línea 96 era la sentencia:

temp = my_array[letter][j+1];

y la línea 98 era:my_array[letter][j] = temp;

Así que lo que estaba sucediendo es que distintos threads estaban recurriendo al mismo tiempo a la misma variable temp para reordenar los valores de los arreglos; también encontré warnings, indicando que había threads que esperaban más de 3 segun-dos para obtener acceso a un recurso, esto es bastante tiempo para un programa cuya eje-cución total dura 6 segundos. Probablemente esto se debía a la pelea entre los 8 threads para acceder la misma variable temp. Ya que había encontrado el problema, tendría que pensar en la solución adecuada. Una opción era encerrar las líneas 96 a 98 en una sección crítica, o sincronizada, de forma que al mismo tiempo solamente un thread pudiera estar en esta sección, y hasta que terminara todas las operaciones de la sección liberaría el control para otro thread. Otra opción era hacer que la variable temp fuera local para cada thread.

Esta opción me pareció mucho mejor, ya que esta variable no necesitaba ser compartida, y por medio de este mecanismo se evitó que cada thread tuviera que esperar a que los demás terminen.

Afortunadamente, en OpenMP es muy senci-llo marcar variables como locales para cada thread. Simplemente se utiliza el comando pri-vate. El listado 3 muestra el código resultante.

void parallel_bubble_sort (char *** &my_array,int letter_counts[26]){ char * temp; #pragma omp parallel for private(temp) for (int letter =0; letter < 26; letter++) { for (int i =0; i < letter_counts[letter] - 1 ; i++){ for (int j =0; j < letter_counts[letter] - 1 - i; j++){ if (strcmp(static_cast<char *>(my_array[letter] [j+1]), static_cast<char *>(my_array[letter][j])) < 0){ temp = my_array[letter][j+1]; my_array[letter][j+1] = my_array[letter][j]; my_array[letter][j] = temp; } } } }}

Listado 3. Código corregido

En esta ocasión, cuando ejecuté el progra-ma el resultado fue correcto, y el tiempo de ejecución disminuyó significativamente. En lugar de los 7.40 segundos originales, ahora el ordenamiento se ejecutó en 1.60 segun-dos. Un vistazo al Intel Thread Checker indi-có que ya no había errores ni avisos.

¡Perfecto! Afortunadamente, mi primera expe-riencia como profesional en la programación paralela no fue tan mala como mis memorias de manejo de threads en la universidad. Por supuesto, fue un ejemplo bastante sencillo. Sin embargo, refleja que utilizando un proce-so adecuado y aprovechando las herramientas disponibles (las que mencioné en este artícu-lo son gratuitas), hacer programas paralelos es mucho más fácil de lo que pensábamos.

El método adecuado para desarrollar pro-gramas paralelos involucra cuatro pasos:• Análisis. Determinar los mejores lugares para usar threads• Implementación. Introducir en el código los elementos para ejecución paralela.• Depuración. Asegurar que todo esté fun-cionando correctamente.• Optimización. Realizar ajustes para maxi-mizar desempeño.

Este artículo abordó la implementación (a través de OpenMP) y depuración (con Intel Thread Checker). Para este pequeño programa el análisis fue automático. Sin embargo, para problemas reales, con mayor complejidad, es crítico comenzar con un buen análisis.

Referencias[ openmp.org/wp/ ][ intel.com/software/products ][ softwarecommunity.intel.com/isn/home/ ][ devx.com/go-parallel ]

Figura 1. Resultados del Intel Thread Checker


/*GAdGets*/// TECNOLOGÍA

Firebox

Brick USBPara recordar aquellas épocas en las que todo era tan sencillo como unir bloques de colores para construir una casa o una nave espacial; ¿por qué no traer de regreso esas lindas memorias de la infancia a nuestro acelerado ritmo de vida en el que todo es llevar, traer y compartir información a través de pequeños dispositivos con gran capacidad? Y en respuesta a tan larga pregunta... unos legos USB (que no son oficialmente legos) disponibles en rojo, azul o ama-rillo con opción para guardar 2GB ó 4GB de documentos importantes, música, imágenes o cualquier otro tipo de ar-chivo digital. Lo mejor de ellos es que se pueden unir unos con otros, de tal forma que a primera vista, pareciera que sólo se trata de un grupo de bloques de colores.

Tivoli

NetWorks RadioHay equipos de audio que se ven bien, otros que resultan funciona-les, y los que proveen audio en alta definición. Pero hay pocos que logran combinarlo todo y además le agregan ese “pequeño extra” que los hace especiales. Tal es el caso de NetWorks Radio, fabricado por Tivoli, que luego de preguntarse: ¿qué haría un radio ideal? Mate-rializaron esta monada que además de su diseño sencillo y moderno, permite el acceso a las ventajas del broadcasting por Internet de tal manera que con él se sintonizan estaciones de radio de cualquier par-te del mundo sin interferencias, ofreciendo sonido cristalino y en el idioma original; o escuchar la música que se tiene almacenada en la PC desde cualquier habitación de la casa, a través de conexión Ether-net o de manera inalámbrica. Incluso cuando NetWorks es sólo un ga-binete, se puede expandir conectándole un par extra de altoparlantes estéreo, un subwoofer o un reproductor de CD. Cuenta con control de balance, panel de iluminación LCD, reloj digital con fechador, vo-lumen de alarma independiente, entradas auxiliares, control remoto, cable de corriente desmontable y capacidad de almacenamiento de hasta 200 estaciones para guardar favoritos; entre muchas otras ca-racterísticas que lo hacen un equipo high-tech con estilo.


Casio Exilim EX-Z300Como parte de las nuevas tendencias en cámaras di-gitales para la temporada otoño - invierno 2008, Casio lanzó seis modelos de la serie Exilim, y elegimos la EX-Z300 por llevar consigo la etiqueta de “el mejor des-empeño” y por estar dirigida hacia aficionados exigen-tes, que también disfrutan subiendo videos a YouTube. Con 10.1MP y zoom óptico de 4x, modo Make up para corrección de imagen, pantalla de 3” TFT LCD súper bri-llante, grabación de video en HD, objetivo de gran an-gular de 28 milímetros, modo de disparo especial para escenas nocturnas, detección de rostros y 300 imáge-nes con una sola carga de batería, resulta una pequeña gran opción, portátil, digital y, a buen precio.

HP

Mini-Note PCComo la nueva era de computadoras portátiles es una realidad, HP presenta su minicomputadora HP 2133, diseñada para el mercado empresarial, pero perfecta para usarse en la oficina, en la casa, en viajes de negocios o sim-plemente para llevarla a cualquier parte. Dentro de sus características principales destacan su peso de 1.10 kilogramos, cubierta de aluminio cepillado resistente, HP DuraKeys, que es una capa transparente apli-cada sobre el teclado para proteger el acabado, las letras y caracteres impresos. Pantalla resistente a ralladuras de 8.9” y armazón reforzado con bisagras de magnesio. Tecnología inalámbrica Wi-Fi WLAN integrada y Bluetooth opcional. Memoria de 512MG y 1GB; disco duro desde 120GB; bateríade 3 ó 6 celdas con rendimiento de hasta 55 horas. Opera con Windows Vista, XP o Linux.

Palm

Palm Treo Pro Bajo el lema “Acelerar en lugar de complicar” Palm lanza su telé-fono inteligente Palm Treo Pro, dirigido al segmento corporativo. Este modelo está dirigido a los usuarios empresariales que requie-ren un dispositivo sencillo de usar, que ejecute de forma transpa-rente aplicaciones basadas en plataforma Microsoft. Esto se logra gracias a que el Treo Pro funciona sobre la plataforma Windows Mobile 6.1 Professional, así que utiliza Outlook como cliente de correo, y permite abrir y editar nativamente archivos Word, Excel y Power Point. Adicionalmente, soporta acceso seguro a servidores de documentos SharePoint. Así que si buscas un dispo-sitivo móvil que te permita manejar los mismos docu-mentos que manejas en la oficina de forma rápido y sencilla, el Treo Pro puede ser una gran opción.


¿Por qué Cuesta Tanto Darle una Oportunidada la Usabilidad?Mejorando la exPeriencia del UsUarioPor Romeo Márquez

// fUNdAMENTOS

Romeo Márquez Guzmán es fundador de gelattina, una compañía especializada en web 2.0, diseño de interfaces, E-Marketing, widgets y video para web y podcasting). Adicionalmente es miembro de la Usability Professionals’ Association. Para Gelattina, ha dirigido proyectos de diseños de interfaces para The Home Depot, Coca-cola, Banorte, Hoteles Marriott, Aba Seguros entre otros. www.gelattina.com [email protected]

Cada vez más compañías descubren el alto valor de tener sitios web o Software desa-rrollados con principios de usabilidad. Aún así, el 80% de las empresas desarrolladoras de Software ignoran por completo el tema.

Usabilidad: casos de la vida realEs muy común que no se tome en cuenta o que se deje para el último aplicar usabilidad durante el proceso de desarrollo de un sitio web o una aplicación.

La siguiente es una conversación que he te-nido en más de una ocasión con diferentes compañías de desarrollo de software:

Cliente: Necesitamos que hagan bonita nuestra aplicación.Romeo: Muy bien, ¿cuando empiezan el aná-lisis de requerimientos con el usuario?Cliente: Eso ya lo hicimosRomeo: ¿ Ah si?Cliente: Así es, el desarrollo lo terminaremos en una semana más, por eso estamos vien-do quien va a hacer la interfaz de usuario.Romeo: Plop!

Claro que es posible mejorar en términos de usabilidad un sitio o un software ya diseña-dos, más vale tarde que nunca, pero ¿por qué dejarlo para el último o en las manos equivocadas?

A veces queda la responsabilidad en los pro-gramadores de determinar el lugar de cada cosa en la interfaz, sin embargo la experien-cia indica que eso es un grave error.

A continuación veremos por qué tomar en cuenta a la usabilidad desde el inicio del proyecto, ayuda a obtener mejores resul-tados en el producto final, evitar reescribir

código y lo más importante: mejorar la ex-periencia del usuario.

Diseño y usabilidad• Arquitectura de información. En un sitio web, una buena arquitectura es fundamental pues determinará si los usuarios podrán o no llegar a la información preparada para ellos.

Suena sencillo, ¿no?; A pesar de eso, la gran mayoría de los sitios web NO cuen-tan con una verdadera arquitectura de in-formación. Esto se traduce en menús mal organizados con opciones interminables, secciones del sitio con nombres extrava-gantes, visitantes desubicados y lo más grave: usuarios frustrados.

Las estadísticas lo confirman: • El 83% de los visitantes abandonan un sitio si tienen que hacer demasiados clicks para encontrar lo que buscan.• El 62% deja de buscar un artículo mientras visitan una tienda en línea.• 40% de los usuarios no regresan al sitio debido a una mala experiencia relacionada con la falta de usabilidad.

Es importante definir bien la arquitectura de información en una aplicación, pues determi-nará si el usuario la considera fácil de utilizar y presenta menos resistencia al cambio.

Esto puede determinar si un software ten-drá aceptación en el mercado o dentro de la compañía.

A menos que quieras ser como el dueño de una compañía de software que dijo: No que-remos que nuestra documentación para el usuario final sea muy clara. Hacemos mucho dinero capacitando a nuestros clientes.

• Diseño centrado siempre en el usuario. Para lograr un buen diseño de sitio o apli-cación, será importante saber quién es el usuario promedio: cuales son sus hábitos de navegación, cómo usa la tecnología o que tipo de información busca.

Si se incorpora esa información al diseño, el resultado será de mayor utilidad para el usuario final.

Es indispensable diseñar el sitio tomando en cuenta el tiempo de descarga. Los usuarios son cada vez menos pacientes y el tiempo promedio de espera para un sitio Web es de 2 a 10 segundos.

Esto no significa restringirse de usar mul-timedia en el proyecto, sin embargo será importante que el usuario mismo sea quien decida cuando y bajo que circunstancias de-sea verla en vez de forzarlo.

Si tu proyecto tiene más de un tipo de usua-rio, será mejor diseñar secciones específicas para mostrar el contenido preparado para cada tipo de usuario.

La Usabilidad en un sitio Web o aplicación debe:

• Facilitar el acceso a la información.• Reducir la posibilidad de cometer errores.• Incrementar la productividad del usuario.• Reducir el tiempo dedicado a la capacitación.• Reducir el costo de dar soporte al usuario.

• Pruebas de usabilidad. Nada peor que ha-cer todo el esfuerzo de lanzar un sitio Web o software para descubrir que el usuario no encuentra lo que necesita, ni puede realizar sus actividades con facilidad.


INDEX

Anunciante Páginas Sitio

Adecco 2F, 1 www.adecco.com.mxAvantare 41 www.avantare.comAMITI 49 www.amiti.org.mxBrio 39 www.brio.com.mxCompusoluciones 45 www.compusoluciones.comCompushow 51 www.compushow.com.mxIT Institute 9 www.it-institute.orgMicrosoft F0 www.microsoft.com.mxMilestone Consulting 4F www.milestone.com.mxNYCE 3F www.nyce.org.mxSafeNet 11 www.safenet-inc.comSG Campus 13 www.sgcampus.com.mxSIE Center 17 esicenter.itesm.mx

TENEMOS UN ESPACIO RESERVADO PARA TISi deseas anunciarte contáctanosen el (55) 5239 5502 o en [email protected]

DIRECTORIO

El mejor método para detectar esas fallas es realizar pruebas de usabilidad.

Aunque hay métodos sumamente sofistica-dos para hacer pruebas de usabilidad, inclu-sive pueden realizarseen papel.

En cualquiera de los casos, es mejor realizar las pruebas durante las etapas más tempra-nas del diseño y repetirlo varias veces a lo largo del proyecto, para asegurar una inter-faz con un alto nivel de usabilidad.

Algunas citas interesantes• “¿Cual es el costo de hacer feliz al usua-rio?; Es bajo si se hace al inicio del ciclo de desarrollo web.

Si cuesta $1 hacer el cambio en papel, en-tonces cuesta $10 hacerlo en el código y $100 cuando el sitio está en línea”- Theresa Cunnington, ComputerWorld

• “La acción mas común de un usuario en un sitio Web es huir!”- Edward Tufte, Information Design Guru

• “La Usabilidad es crítica para cualquier aplicación, sin embargo, para el software orientado a mercados masivos, la usabi-lidad significa el éxito o fracaso más que cualquier otra característica.”- Dr. Jerrold Grochow, CTO, American Management Systems

Referencias[ “Google en 28 palabras”. tinyurl.com/5ak6fa ][ “El laboratorio de usabilidad de Google”. tinyurl.com/6no9mo ][ “La usabilidad incrementa las utilidades: 2 casos de éxito”. tinyurl.com/55wrol ]

ConclusiónSiempre será mejor aplicar conceptos de usabilidad desde el inicio del proce-so de diseño y desarrollo de un proyec-to. Para lo cual es importante incluir a los usuarios y realizar pruebas de usabi-lidad durante el proceso de diseño.


// CARRERA

¿Cómo Enseñar a los Programadores del Futuro?¿estrUctUrada, Poo o scriPts?Por Gunnar Wolf

Gunnar Wolf ha sido usuario y promotor de Software Libre en México por más de diez años. Es fundador del Congreso Nacional de Software Libre (CONSOL) y miembro externo del Departamento de Seguridad de Cómputo en la UNAM. Participa como desarrollador en el proyecto Debian desde el 2003. Trabaja como administrador de red y en el desarrollo de sistemas para el Instituto de Investigaciones Económicas de la UNAM.

Nuestro gremio se caracteriza por conformar-se por dos principales perfiles: Autodidactas y escolarizados. Esto obedece a que el cam-po es aún novedoso, y es aún posible para un aficionado ir obteniendo de manera gradual e independiente los conocimientos para llegar a un nivel de competencia comparable con quien estudió una carrera formalmente.

El programador autodidacta tí picamente es un miembro muy valioso del equipo de desa-rrollo, dado que llegó a acumular sus conoci-mientos -teóricos y prácticos por motivación propia. Si bien es común que su formación muestre importantes “agujeros” cognitivos en aquellos campos que requieren mayor rigor teórico/matemático, o en aquellos por donde el interés no lo llevó, comúnmente los subsanará tan pronto se enfrente a situacio-nes que los requieran. Sin embargo, es justa-mente en las áreas más teóricas y áridas del cómputo donde hay una mayor proporción de profesionales con éste perfil.

No puede ser casualidad que dentro de los desarrolladores de Software Libre haya tan alta proporción de autodidactas, gente for-mada en otras disciplinas, que ha ido en-contrando su nicho de interés y trabajo en el cómputo, encontrando que en la creación de herramientas cubran sus necesidades parti-culares de una nueva vocación.

Podríamos dedicar un amplio espacio a analizar la relación entre el conocimien-to adquirido formal e informalmente, y en cómo insertar a estos en un esquema aca-démicamente más formal... Pero el tema del que quiero ocuparme en esta ocasión es de quien viene de una enseñanza escolarizada.

¿Cómo transmitir el conocimiento, el inte-rés y el entusiasmo, a los programadores escolarizados, para que alcancen un nivel de habilidad similar al de los autodidactas? Para esto, es fundamental que nos pregun-

temos, ¿qué y cómo enseñan a los alumnos las universidades en nuestro País, las ca-rreras relacionadas con el cómputo? ¿Qué perfiles reales de egreso hay de cada una de estas carreras (desde la Licenciatura en Informática Administrativa, pasando por las Ingenierías, con perfiles orientados más ha-cia Sistemas, Electrónica u otras variantes, y hasta las Ciencias de la Computación)? ¿Y cómo explicamos que, a la hora de buscar un trabajo, tan frecuentemente todos son pues-tos dentro de la misma bolsa?

El primer obstáculo al que creo todos los programas académicos deben reaccionar es que, muchos alumnos sienten que progra-mar es una tarea tediosa, un rol que se verán forzados a desempeñar durante los prime-ros años de su trabajo, en lo que logran un ascenso a un puesto de “responsabilidad”. Esto es, en buena medida, por lo torpe que resulta la enseñanza de los conceptos y ha-bilidades básicos de la programación.

Hay dos escuelas básicas: Comenzar ense-ñando programación utilizando un lenguaje mí nimo aunque completo, apto para transmitir los fundamentos de la estructura y el control de flujo (al estilo de C o del venerable Pascal). En contraposición a ellos, muchos otros acadé-micos defienden comenzar enseñando con un paradigma completamente POO, con lengua-jes como Java o como C#. Y ambas alternativas nos dejan importantes huecos por llenar.

Para alguien que inició con lenguajes de muy alto nivel, resulta más difícil com-prender la traducción a código de más bajo nivel y la implementación en hard-ware del mismo, especialmente lo relativo a administración de memoria y el órden de complejidad; en este sentido, una de las más brillantes exposiciones la hace Ul-rich Drepper, en su texto “What Every Pro-grammer Should Know About Memory” 1. Para todas las aplicaciones que corren

“cerca del metal”, como desarrollos de siste-mas tiempo real, embebidos, controladores de hardware o software orientado al alto rendi-miento, es fundamental dominar estos temas.

Por otro lado, para los programadores que par-ten de un entorno meramente procedimental, la POO se presenta como una complejidad adi-cional, un obstáculo para la manera que tienen y conocen de solucionar los problemas.

Si bien la discusión académica respecto a es-tas dos escuelas está tan viva como cuando se planteó por primera vez hace más de 20 años (p.ej. 2 y sus respuestas en3), creo yo que el problema de la motivación reside en no enfocarnos en lenguajes y marcos “sim-ples” (sin ser de juguete), que no permiten al alumno experimentar la “gratificación instantánea” de lograr resultados atractivos tras apenas un primer acercamiento. Los len-guajes denominados “de scripts” (Python, Ruby, Perl, y un largo etcétera) deben ser enseñados de otra manera, mucho más gra-dual, pero sin duda ayudan a mantener alta la motivación y baja la frustración.

Pero... ¿No son lenguajes con relativamente baja penetración corporativa? Así es, y eso representa otra ventaja - Una de las principa-les cualidades de un programador debe ser la capacidad de aprender tecnologías nuevas. Al enseñar con herramientas distintas, ayu-damos a que los estudiantes desarrollen la importante habilidad de “aprender a apren-der”, no encasillarse en una herramienta. ¡Que se hagan el hábito de aprender nuevos lenguajes para diferentes retos!

Referencias[ 1. Drepper, Ulrich. “What Every Program- mer Should Know About Memory”people. redhat.com/drepper/cpumemory.pdf ][ 2. “Just say ‘A Class Defines a Data Type’”, mags.acm.org/communications/200803 ][ 3. “Forum” , mags.acm.org/communications/200805 ]

sg22 (noviembre 2008 - enero 2009)

Documents