// CONTENIDO
directorio
Editorial
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.
02 NOV-ENE 2009
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
Dirección Editorial
Pedro Galván
Dirección de Operaciones
Mara Ruvalcaba
Coordinación Editorial
Alejandro Escamilla
Arte y Diseño
Grisel 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.
Colaboradores
Carlos 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
Contacto
info@sg.com.mx
+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.
www.sg.com.mx
 contenido
nov 2008 - ene 2009

26 EN PORTADA
Cloud Computing
Te mostramos los recursos ilimitados
del “Cómputo en la nube”

Especial 18
Encuesta de Salarios 2008.

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

Herramientas 14
Beneficios de la Automatización de
Pruebas.

TUTORIAL 16
Silverlight, Parte 2.

Columnas Prácticas
Tejiendo Nuestra Red 08 Tendencias en Software 48 PROGRAMACIÓN 36
por Hanna Oktaba por Luis Daniel Soto Ofuscación de Código
Conozcamos como proteger nuestro código
Mejora Continua 10 Prueba de Software 50 para que no sea reutilizado por terceros.
por Luis Cuellar por Luis Vinicio León
ADMINISTRACIÓN DE BASE 40
Columna Invitada 46 DE DATOS
por Carlos Ordoñez Diseño de Base de Datos
Aprendamos a utilizar los catálogos para hacer
más eficiente nuestra manera de codificar.
En Cada Número
ARQUITECTURA 42
Noticias y Eventos 04 GADGETS 60 Una Receta para Desarollar
Arquitecturas
INDUSTRIA 06 FUNDAMENTOS 62 Presentamos el marco de trabajo para
desarrollar arquitecturas propuesto por
INFRAESTRUCTURA 52 CARRERA 64 The Open Group.

PM CORNER 44
La integración de un equipo de
trabajo funcional

24
Tácticas y técnicas para integrar de manera
eficiente a tu equipo de trabajo.

Entrevista
Tom DeMarco

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

 // NOTICIAS

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 2008

El 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 Latina

La 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.

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


5 al 7 de Noviembre 2008
BAJA TECH Business Solutions 2.0
Grand Hotel Tijuana, Baja California
Info: www.itbaja.com/web-bajatech
e-mail: enlace@itbaja.com
5 y 6 de Noviembre 2008
Seminario Gratuito “Squeeze your metrics”
Avantare, MS SPI Solutions, y Secretaría de Economía
Torre Insurgentes de Secretaría de Economía, Cd. de México
e-mail: capacitacion@avantare.com
12 al 14 de Noviembre 2008
SEPG LA 2008 – Combinando Disciplina con
Métodos Ágiles
ESI Tecnalia, SEI, y ESICenter Cono Sur
Hotel Hermitage, Mar del Plata, Argentina
Info: www.esi.es/SEPGLA
e-mail: sepgla@esi.es
CIAPEM 2008
Los 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.
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.
www.sg.com.mx
// EVENTOs
11 al 13 de Noviembre 2008
Agile Management - Creating
Business & Technical Value
Cutter Consortium
Hotel JW Marriott, Cd. de México
Info: www.cutter.com.mx/eventos2008
e-mail: agile@cutter.com.mx
12 al 14 de Noviembre 2008
50 Años de la Computación en México
Palacio de Minería, Cd. de México
Info: computo50.unam.mx
5 al 7 de Diciembre 2008
Expo Robótica, Ciencia y Tecnología
WTC, Cd. de México
Info: www.exporobotica.com.mx
e-mail: info@exporobotica.com.mx
CIISA 2008
Del 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.
NOV-ENE 2009 05
 // INDUSTRIA
50 Años de la Computación en México
Reseña histórica
Por Alejandro Escamilla
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éxico
La 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 universidades
Posteriormente, 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 posgrados
El 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 perdida
La 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”.
16
06 NOV-ENE 2009
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 Conacyt
En 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 XXI
En 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.
Conclusión
En 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.”
Referencias:
[cs.cinvestav.mx/SemanaComputoCINVESTAV/Computo.html]
[lajornadadeoriente.com.mx/2008/01/28/puebla/]
[computo50.unam.mx/computoenmexico2.html]
www.sg.com.mx

25 Años Haciendo Investigación
Un Vistazo al Pasado, Presente y Futuro en el CINVESTAV-IPN
Por 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.
www.sg.com.mx
// industria
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. ]
NOV-ENE 2009 17
07
 // COLUMNA
Aprovechando Áreas de Procesos de MoProSoft
Reunión del WG24 en México
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.
L a 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:
08 NOV-ENE 2009
/*TEJIENDO NUESTRA RED*/
¿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:
Financieras
• 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.
Relación con el Cliente
• 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.
Proceso Interno
• 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, infraes-
tructura y del portafolio de proyectos se
realiza de manera informal.
Aprendizaje y Crecimiento
• 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.
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
www.sg.com.mx
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 y
Mantenimiento 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.
www.sg.com.mx
• 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
NOV-ENE 2009 09
 // COLUMNA
“Premio Nacional de Calidad”,
y La Norma MoProSoft
Estrategias de Implantación
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
E l 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ón
La 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”).
10 NOV-ENE 2009
/*MEJORA CONTINUA*/
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
www.sg.com.mx
www.sg.com.mx NOV-ENE 2009 11
 // PRODUCTOS /* LO QUE VIENE*/

VSTS 2010
Nue 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 Mono 2.0
Ya l l e g ó s up e r c h a n g o

Microsoft dió a conocer los planes para la próxima

generación de sus herramientas y plataforma de de- Mono 2.0 por fin fue liberado. Mono es una im-
sarrollo: Visual Studio 2010 y .NET 4.0. Como parte plementación en software libre del Framework
de esta plataforma también habrá una nueva versión .NET de Microsoft. A pesar de que todavía le
de la herramienta para la colaboración de equipos de falta bastante para cubrir todo el espectro de
trabajo, Visual Studio Team System (VSTS) 2010. Las APIs de .NET, con esta versión ya se soportan
innovaciones en VSTS 2010 se enfocan principalmente los componentes de mayor relevancia y que
en mejorar las capacidades para el modelado visual y utilizan el grueso de las aplicaciones.
la administración de pruebas de software. Las nuevas
capacidades de modelado en VSTS 2010 son un compo- Entre los APIs soportados por Mono 2.0
nente central de la iniciativa de modelado de Microsoft, resaltan ADO.NET 2.0, ASP.NET 2.0, Windows.
conocida con el nombre clave “Oslo”. Forms 2.0, System.XML 2.0, System.Core
(LINQ), y System.Drawing 2.0.
La información que ha liberado Microsoft hasta el momen-
to es bastante vaga, y se espera que el panorama quede En el área del compilador, la capacidad de
más claro después de la conferencia de desarrolladores mayor importancia en esta versión es el so-
(PDC 2008) que se realizará a finales de octubre. porte completo de C# 3.0, incluyendo LINQ to
Objects, y LINQ to XML.
Más información en msdn.microsoft.com
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

Beehive
Oracle se une al Web 2.0 e mpr 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

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

www.sg.com.mx NOV-ENE 2009
 // PRODUCTOS /*herramientas*/
Beneficios de la Automatización de Pruebas
Ahorrando Tiempo y Recursos
Por Benjamín Alonso
¿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.
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 benalonso@pickyware.com
14 NOV-ENE 2009
Beneficios de las pruebas automatizadas
Las 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.
www.sg.com.mx
 “¿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 Testing
Despué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.
www.sg.com.mx
• 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ón
Hoy 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.]
NOV-ENE 2009 15
 // PRODUCTOS /*tutorial*/

Desarrollo de Aplicaciones Silverlight

Parte 2. Eventos desde XAML y Javascript
Por Guillermo Morales

Height=”100” Width=”100”
Canvas.Left=”100” Canvas.Top=”50”
Bienvenidos a esta segunda parte de nuestro tutorial sobre Stroke=”Black” StrokeThickness=”10” Fill=”Blue”/>
desarrollo de aplicaciones Silverlight.
<TextBlock
x:Name=”miTexto”
En base a lo que hicimos en la parte 1 (SG Num. 21), debería- Canvas.Left=”70” Canvas.Top=”180”
mos tener los siguientes archivos: Text=”Dame Click” FontSize=”30”/>
</Canvas>
• crearSilverlight.js Noten que tanto el TextBlock como el Rectangle, tienen una propiedad
• Default.html x:Name por medio de la cual podemos identificar a cada elemento den-
• Mixaml.xaml tro del XAML. Utilizaremos esto más adelante en el código Javascript.
• Silverlight.js
Al visualizar nuestra página web, obtendremos lo que se ve en la
siguiente figura.
Respondiendo al click del mouse
Vamos 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”>
Insertando código javascript
El siguiente paso es definir las funciones de Javascript que respon-
<Canvas.Background> dan a los eventos que se disparan desde el XAML. Para esto, inser-
<LinearGradientBrush EndPoint=”0.5,1” StartPoint=”0.5,0”> taremos en nuestra página web el código Javascript del listado 2.
<GradientStop Color=”#FFDCEF1B” Offset=”0”/> Este código lo pueden insertar dentro del mismo bloque de código
<GradientStop Color=”#FF801A1A” Offset=”1”/>
<script> donde se encuentra la obtención de la referencia al plugin de
</LinearGradientBrush>
</Canvas.Background> Silverlight que ya se tiene.

<Rectangle Listado 2. Funciones en Javascript

x:Name=”r1” function r1Entrar(sender, args) {
MouseEnter=”r1Entrar” MouseLeave=”r1Salir” sender.stroke = “red”;
MouseLeftButtonDown=”r1Abajo” sender.findName(“miTexto”).Text = “Rojo”;
MouseLeftButtonUp=”r1Arriba” }

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.

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

 “Crearemos un elemento que pueda
responder a eventos del mouse, para
comenzar a darle más interacción a
nuestros sitios Silverlight”.

function r1Salir(sender, args) {

sender.stroke = “black”; • Mediante el método findName localizamos a elementos específicos
sender.findName(“miTexto”).Text = “Negro”; dentro del XAML, en este caso, el objeto que estamos localizando y
} manipulando es el Rectángulo al cual nombramos “miTexto”.
function r1Abajo(sender, args) {
sender.stroke = “yellow”;
sender.findName(“miTexto”).Text = “Diste Click”;
Con esto tenemos una página cuyos elementos XAML disparan even-
} tos en javascript.
function r1Arriba(sender, args) {
sender.stroke = “Green”;
sender.findName(“miTexto”).Text = “Verde”;
}
Conclusión
Ya tenemos una página cuyos elementos XAML responden al com-
En este código podemos observar dos cosas: portamiento del mouse y disparan funciones javascript.En futu-
• Los eventos disparados desde el XAML, reciben dos parámetros: ros artículos incluiremos una animación, un video y más eventos
para atraparlos con el mouse. Suerte, y hasta la próxima.
- sender: Corresponde al objeto que inicia la acción
- args: Corresponde a información relacionada al evento disparado

www.sg.com.mx NOV-ENE 2009

 Encuesta de Salarios 2008 Por Pedro Galván

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.

Acerca de la fuente de información

La 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.

Salarios a primera vista

Primero, 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.

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

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

El promedio ponderado de estos valores nos centaje de los encuestados que recibe cada Como es costumbre, varios colegas inter-
indica que el salario promedio de un profe- una. Estos valores son prácticamente igua- nacionales (o expatriados) nos hicieron
sionista de TI en México es de $22,570 pesos les a los de hace un año. favor de contestar la encuesta. Mostramos
mensuales. Este valor significa un aumento el listado de aquellos países de los que ob-
de 13% comparado con el valor obtenido en Prestación % tuvimos un mínimo de 10 respuestas. Otros
el 2007, de $19,946. Habría que comparar países fueron descartados por tener una
esto con la inflación real en este periodo de muestra de respuestas demasiado pequeña
Gastos médicos mayores 44.7%
tiempo para determinar si hubo un aumen- como para ser confiable.
Horario flexible 36.5%
to real en el salario o si simplemente fue un
ajuste inflacionario. Préstamos 33.1%
Estado Salario %
Bonos por desempeño 29.5%
Remuneración adicional Gastos médicos menores 22.2%
Teléfono celular 19.2% DF 28,899 35.2%
Aunque el principal componente de la com-
Trabajo desde casa 13.5% NL 25,885 8.3%
pensación laboral es el salario, otro elemen-
Ayuda para educación 12.1% Edomex 22,232 9.7%
to muy importante son las remuneraciones
Automóvil 7.2% Querétaro 21,031 4.5%
adicionales. La tabla 2 es un tabulador del
Ayuda familiar 6.5% Jalisco 19,842 8.7%
valor al que ascienden las prestaciones re-
cibidas anualmente, tales como aguinaldo, Departamento 6.1%
bonos, reparto de utilidades, etc. Acciones (stock options) 4.5% Tabla 4. Estados con salarios más altos

Rango de compensación extra anual Tabla 3. Prestaciones recibidas

De acuerdo a la región
Ninguna 21%
El DF recuperó su liderazgo en este año
Menos de 10 mil 20%
como el estado de la República con los mejo-
De 10 a 25 mil 27% res sueldos para profesionistas de software,
De 25 a 50 mil 16% dejando a Nuevo León en segundo lugar y
De 50 a 100 mil 9% al Estado de México en tercero. Como es de
Más de 100 mil 6% esperarse, estos estados son también los
que emplean a un mayor porcentaje de los
Tabla 2. Tabulador de compensación extra anual profesionistas de software en nuestro país.

Prestaciones En la no muy honrosa lista de los estados

Como elemento final de la compensación con los sueldos más bajos tenemos a Tlax-
tenemos a las prestaciones. La tabla 3 indi- cala, Colima, Chiapas, Oaxaca y Veracruz.
ca las prestaciones más comunes, y el por-

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

 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
Estado Salario % 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%
Tlaxcala 9,667 0.7% en nómina y el resto están por honorarios o contratados como independientes.
Colima 11,273 0.5%
Chiapas 11,632 0.9% Tipo Salario Prestaciones %
Oaxaca 11,708 0.6%
Veracruz 12,127 2.9% 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%
Tabla 5. Estados con salarios más bajos
Otra organización 20,314.01 2,155.80 9.9%
Desarrollo de productos
País Salario empaquetados 19,906.25 1,625.24 8.4%
Educación/Capacitación 15,150.35 1,739.51 6.8%
USA 64,588
España 41,000 Tabla 7. Salarios y prestaciones por tipo de organización
Perú 20,938
Chile 20,333
Tipo Nómina Honorarios Externo
Colombia 12,600
Argentina 9,667
Proveedor de servicios 48.0% 40.0% 12.0%
Área usuaria 84.5% 13.1% 2.4%
Tabla 6. Resultados de otros países
Distribuidor/Canal 67.7% 29.4% 2.9%
Tipo de organización ISV 70.4% 19.5% 10.1%
La tabla 7 divide las respuestas obtenidas a Educación 80.8% 16.1% 3.1%
partir del tipo de organización donde laboran.
El patrón es el mismo que hemos encontrado
en años anteriores. Las empresas proveedo- Tabla 8. Relación entre tipo de organización y esquema de pago
ras de servicios de TI son las que ofrecen los
mejores salarios (aunque ofrecen prestacio- Género
nes muy bajas, mientras que las áreas usua- Como podemos ver en la tabla 9, la participación del sexo femenino en nuestra profesión
rios son las que ofrecen la compensación to- sigue siendo muy baja, y con un salario significativamente menor. La diferencia de salario es
tal (salario mas prestaciones) más alta. del 33%, la cual es prácticamente igual que la estimada el año anterior (33%).

Aunque la mayoría de los profesionistas de Genero Salario %

TI todavía laboran en áreas usuarias, poco
a poco va aumentando el porcentaje que la-
bora en empresas proveedoras. Esto es una Femenino 17,513.25 14.4%
consecuencia natural de la tercerización de Masculino 23,423.23 85.6%
los servicios de TI.
Tabla 9. Salario por género
Un punto que llama la atención sobre los re-
sultados de este año es el salario promedio Edad y Experiencia
en los ISV. Estas son las empresas que se Tal como lo hemos visto en las encuestas de años anteriores, el salario de un profesionista
dedican a desarrollar productos de software de TI sube paulatinamente de acuerdo a su edad, y llega a un máximo entre las personas que
propios para posteriormente comercializar- tienen 50 a 59 años. Posteriormente baja drásticamente después de los 60.

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

Como es de esperarse, el comportamiento Función Salario %
respecto a los años de experiencia es simi-
lar, tal como se puede apreciar en la tabla 11.
Alta Dirección 45,263.9 3.4%
Analizando esta tabla, vemos que le hacen
falta más escalas después de los 10 años de Dirección de sistemas 41,892.9 4.7%
experiencia, para poder analizar a este seg- Ventas 30,902.4 2.0%
mento en mayor detalle. Haremos ese ajuste Arquitecto 28,754.5 5.4%
para la próxima encuesta de salarios. Project Manager 27,498.4 14.9%
Consultor 23,553.9 8.0%
Seguridad 23,404.8 1.0%
Estado Salario %
Administrador de sistemas 21,450.8 6.3%
TI en General 21,351.4 6.6%
18 a 24 11,410 14.6% DBA 17,800.0 2.6%
25 a 29 17,378 31.9% Aseguramiento de Calidad 17,449.4 3.8%
30 a 39 25,563 40.5% Desarrollador 17,256.9 31.2%
40 a 49 37,166 10.4% Soporte 14,884.6 3.7%
50 a 59 46,276 2.3% Redes 13,939.4 1.6%
60 o mas 27,143 0.3% Docente 13,710.5 2.7%
Webmaster 12,913.0 2.2%
Tabla 10. Salarios de acuerdo a la edad
Tabla 12. Salarios por función
Estado Salario %

Menos de un año 10,328 6.4%

Escolaridad
El máximo grado de estudios completado brinda un fiel reflejo de la compensación a la que
1a3 12,746 20.8%
se puede aspirar. En esta ocasión, nos llama la atención el hecho de que la compensación de
3a5 17,706 17.1%
quienes tienen maestría quedó por debajo de quienes solamente tienen otro tipo de postgrado
5 a 10 23,304 25.0%
(como un diplomado) que requiere menos dedicación. La explicación pudiera estar en que este
Mas de 10 33,871 30.7%
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,
Tabla 11. Salarios de acuerdo a la experiencia 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.

De acuerdo al tipo de trabajo Escolaridad Salario %

Como sabemos, existe una gran cantidad
de perfiles y tipos de trabajo en nuestra Doctorado 40,523 1.1%
profesión. Obviamente, unos son mejor Postgrado 31,201 6.1%
pagados que otros. Como es de esperarse,
Maestria 29,827 16.2%
los directores son los mejor pagados, pero
Universidad titulado 21,853 46.3%
veamos como se compara el sueldo para el
Universidad sin titular 17,552 27.5%
resto de las funciones.
Bachillerato 16,848 2.8%

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.
Tabla 13. Salario por grado de estudios terminado
Conocimientos y habilidades
Los 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.

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

 Lenguaje Salario % Base de Datos Salario % Certificaciones
La mejor forma de demostrar nuestros co-
Cobol 30,909 3.9% DB2 29,251 13.5% nocimientos sobre alguna práctica o tec-
.Net 27,827 20.7% Informix 27,965 8.8% nología específica es una certificación. La
JEE 26,577 26.7% Sybase 27,342 6.5% certificación reina sigue siendo la de Project
Flex 26,000 3.2% Oracle 26,217 39.3% Management Professional (PMP) del PMI. Por
Perl 24,719 4.7% SQL Server 23,140 59.8% otro lado, la gran demanda de consultores
JME 23,928 4.3% PostgreSQL 20,656 9.8% de SAP que ha habido en los últimos años ha
JSE 23,639 32.5% MySQL 20,025 38.9% provocado que esta certificación aumente su
ASP 23,256 25.5% Firebird 19,015 3.2% valor significativamente, ya que de tener un
C 23,039 17.8% sueldo promedio hace un año de poco más de
VB 20,432 34.1% Tabla 14c. Bases de datos 30 mil pesos, este año supera los 40 mil. Otra
Delphi 19,807 7.7% certificación que también se está codiciando
Php 18,530 23.6% Aplicación Salario % bastante es la de Microsoft Systems Engineer,
cuyo sueldo promedio aumentó más de 10 mil
Tabla 14a. Lenguajes de programación pesos respecto al año pasado.
BPM 35,922 7.9%
BI 28,978 24.6%
Plataforma Salario % Certificación Salario %
CRM 28,734 14.5%
ERP 24,483 52.3% PMP 43,215 5.5%
Mainframe 33,454 4.7% SAP 40,826 2.1%
Unix 28,607 27.8% Tabla 14d. Aplicaciones empresariales Microsoft - Systems
AS400 27,898 5.6% Engineer 40,794 1.6%
Windows Mobile 25,907 10.3% Seguridad 38,000 1.6%
Otras habilidades Salario %
Windows 22,423 90.0% Sun - Solaris 37,048 1.0%
Mac 22,212 7.2% OMG - UML 35,929 1.3%
Linux 21,777 36.0% EDI 29,022 3.3% Oracle 35,577 3.1%
DOS 21,300 12.8% PM 28,045 51.0% IBM - DB2 35,405 1.0%
Procesos 26,431 35.7% Calidad - SQA 35,023 2.1%
Tabla 14b. Plataformas Test 26,294 24.6% IBM - Rational 34,229 1.2%
UML 22,970 44.9% Microsoft - DBA 31,000 1.4%
Redes 20,234 27.4% Ingeniería de
Diseño Gráfico 18,150 19.1% software (SEI) 29,429 3.7%
Microsoft - Solution
Tabla 14e. Otras habilidades
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

Conclusión
Los 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.

28
22 NOV-ENE 2009 www.sg.com.mx
 Las Mejores Empresas para Trabajar
Prácticas de RH que llevan al Éxito
Por Emmanuel Olvera

Recuerdo perfectamente cuando en un congreso internacional de portantes en tiempos de inseguridad económica. Y, precisamente,
Recursos Humanos, uno de los ponentes preguntó cuantos directo- las empresas más admiradas son más exitosas en mantener altos ni-
res generales había presentes entre la audiencia, y menos de cinco veles de lealtad y motivación en tiempos difíciles. Una de las claves
manos se levantaron entre cientos de participantes. ¿No sería im- es asegurar que las oportunidades de ascenso y crecimiento perso-
portante que los directores generales conocieran las mejores prácti- nal estén disponibles para todos, sin importar cuál sea el contexto
cas para la gestión de recursos humanos? ¿No les interesará conocer económico.
el impacto que tienen estas prácticas en la rentabilidad del negocio?
Las Mejores en México
En un estudio realizado por Hay Group entre empresas del Fortune Hace unos meses, Great Place To Work Institute publicó los resulta-
500 se detectaron las 7 mejores prácticas comunes entre estas em- dos de su estudio para determinar cuales eran las mejores empresas
presas, y resultó que 3 de estas prácticas están directamente rela- para trabajar en México.
cionadas con el factor humano.
En el área de Tecnologías de Información y Telecomunicaciones, la
GE, Toyota, Berkshire Hathaway, Nokia, y BMW son algunas de las or- lista de las mejores empresas en México para trabajar en el 2008 de
ganizaciones que encabezan este ranking, y son de las empresas más acuerdo con Great Place To Work es la siguiente:
admiradas del planeta. Entre 2004 y 2007, por ejemplo, brindaron a
sus accionistas una rentabilidad media de 19,6 por ciento, casi el tri- 1. Compusoluciones
ple que el 7,1 por ciento del ranking de Standard & Poor’s para el mis- 2. IBM
mo período. ¿Qué han hecho para llegar (y mantenerse) en la cima? 3. Nokia   
¿Cuáles son los factores que explican el desempeño sobresaliente? 4. Compac
5. EADS   
A continuación doy una breve descripción de las prácticas de RH co- 6. Everis   
munes entre estas organizaciones: 7. Ingram Micro   
8. Microsoft   
1. El éxito a través de las personas. Probablemente, el factor más 9. NCR   
importante que distingue a estas empresas es un enfoque para lo- 10. Nextel   
grar el éxito a través de la gente. Los líderes de estas organizaciones 11. Perot System   
dedican el 30 por ciento de su tiempo a desarrollar talento y entre- 12. Pink Elephant   
nar al personal. Estas compañías son más proclives a implementar 13. Progress Software   
estrategias y métricas relacionadas con el cuidado del capital hu- 14. Sabre   
mano. Suelen tener planes de sucesión bien definidos y contratar al 15. Telefónica Movistar
CEO dentro de la organización.
Creo que hay que reconocer y aprender del esfuerzo que estas em-
Como expresó Jack Welch, ex CEO de GE: “Mi trabajo principal era presas hacen al interior y exterior de sus organizaciones, al crear
desarrollar talento. Era un jardinero que proveía agua y otros nu- un ambiente óptimo donde los colaboradores se pueden sentir re-
trientes a nuestras mejores 750 personas. Por supuesto, también conocidos, valorados, recompensados para desarrollar al máximo
tuve que eliminar algunas malas hierbas”. su potencial humano y profesional. Dichas empresas desarrollan
estrategias que van más allá de retener y desarrollar a su personal.
2. Fuerte cultura organizacional. La cultura organizacional repre- Adicionalmente cuentan con el apoyo y compromiso por parte de la
senta, en general, la forma en que se hacen las cosas y los valo- dirección o presidencia de la empresa junto con el área de RH para
res que guían la conducta de los miembros de la compañía. En las crear este tipo de cultura organizacional con enfoque centrado en el
empresas más admiradas, los líderes suelen compartir una visión colaborador.
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 Referencias
equipo, impulsando la innovación y la lealtad de los empleados. [ greatplacetowork.com.mx ]
[ materiabiz.com ]
3. Profundo compromiso del empleado. El entusiasmo por el trabajo
y la alineación con el éxito organizacional son particularmente im-

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

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

 // 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.

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

¿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
www.sg.com.mx
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.
NOV-ENE 2009 25
 El Nuevo Esquema de Entrega de Servicios de TI
Por Pedro Galván

30
26 NOV-ENE 2009 www.sg.com.mx
 “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.

Una definición más formal ¿Qué servicios hay en la nube?

Gartner 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.
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. ]

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

 La Nueva Frontera
Por Pablo Resendiz
El estado de la nube
Cloud 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 perfecta
Hoy 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
28 NOV-ENE 2009
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 nube
Actualmente, 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-
www.sg.com.mx

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-
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.
www.sg.com.mx
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.
NOV-ENE 2009 29
 ¿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.

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.
Conceptos SaaS
Para 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.

• 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.
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:

32
30 NOV-ENE 2009 www.sg.com.mx
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.
www.sg.com.mx
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 software
Actualmente 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.
NOV-ENE 2009 33
31
 Una Vista al Futuro de S+S
Por Gilbert Corrales
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.  forma de dicha magnitud.
34 2008
NOV-ENE 2009
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-
 
www.sg.com.mx
• 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.  taforma permite desde el punto de vista de
• 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. 
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.
www.sg.com.mx
Funcionando en un mundo de
armonía: FeedSync
Live 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-
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!
2008
NOV-ENE 2009 35
 Desarrollo de aplicaciones SaaS
El 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.
Requerimientos
En 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.
32 NOV-ENE 2009
Análisis
La 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ño
La 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.
www.sg.com.mx
Implementación
Ademá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.
Pruebas
La 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).
Javier Mijail Espadas Doctoral Research Assistant Ph. D. Information Technology and Communications ITESM Campus Monterrey
CETEC SouthTower Monterrey, Nuevo León, México.
www.sg.com.mx
• 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.
Conclusión
Nuevas 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. ]
NOV-ENE 2009 33
 // PRÁCTICAS
Ofuscación de Código Dinámica
Mecanismo de Protección o Amenaza
Por Juan Olivares, Sandokan Barajas
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.
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.
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.
36 NOV-ENE 2009
/*PROGRAMACIÓN*/
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
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.
www.sg.com.mx
 “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”.
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-
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
www.sg.com.mx
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.
NOV-ENE 2009 37
 // PRÁCTICAS /*PROGRAMACIÓN*/
“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”.
• 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-
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.
38 NOV-ENE 2009
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.
www.sg.com.mx
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.

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.

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. ]

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

 // PRÁCTICAS
Diseño de Base de Datos
La 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
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.
40 NOV-ENE 2009
/*administración de base de datos*/
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
www.sg.com.mx
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:

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.

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

 // PRÁCTICAS
Una Receta para Desarrollar Arquitecturas
Con Procesos Bien Definidos
Por Miguel Armas
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 la
arquitectura?
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).
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. info@milestone.com.mx www.milestone.com.mx
42 NOV-ENE 2009
/*arquitectura*/
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 de
arquitectura de software
El 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 para
arquitectura
The 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.
www.sg.com.mx
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.
TOGAF
Para 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.
www.sg.com.mx
TOGAF más que ayudarnos a describir una tura definiendo el alcance y la estrategia
Arquitectura Orientada a Servicios (SOA por para lograrla.
sus siglas en inglés) particular, nos ayudará a
decidir si SOA es lo mejor para el proyecto. • Fase B. Arquitectura de negocio, se busca
tener clara la arquitectura de negocio y sus
La metodología de TOGAF ayuda al arquitec- metas para posteriormente poder alinear la
to a destilar el proyecto hasta el punto de TI al negocio.
tomar la decisión de si SOA es el estilo de
arquitectura que nos ayudará a resolver me- • Fase C. La arquitectura de sistemas de in-
jor el problema original. formación contempla las arquitecturas par-
ticulares para datos y aplicaciones.
El método para desarrollar la
arquitectura • Fase D. La arquitectura tecnológica define
El ADM de TOGAF es una especie de “CMMI la arquitectura integrada que se desarrolla-
para arquitectura”. Nos presenta un proceso ra en fases futuras.
iterativo con fases que se deben realizar para
desarrollar la arquitectura, definiendo las en- • Fase E. La fase de oportunidades y solucio-
tradas y salidas de cada fase pero sin indicar- nes permite determinar qué partes se com-
nos como hacer cada uno de los entregables. prarán, construirán o reutilizarán y cómo se
implementará la arquitectura de la fase D.
Prelim:
Framework
and • Fase F. El plan de migración sirve para prio-
Principles
rizar los proyectos y desarrollar el plan de
migración.
A. • Fase G. Control de la implementación es la
Architecture
H. Vision ejecución de los proyectos para construir las
B.
Architecture
Change Business soluciones de TI.
Management Architecture
• Fase H. La administración del cambio de
C.
la arquitectura implica monitorear y evaluar
G.
Implementation Requirements Information
Systems
los sistemas existentes para determinar
Governance Management
Architecture cuándo iniciar un nuevo ciclo de ADM.
F.
Migration
D.
Technology
Conclusión
Planning
E.
Architecture
Contar con y conocer un proceso bien
Opportunities
and definido que nos indica paso por paso
Solutions
cómo se debe desarrollar la arquitec-
tura empresarial es indispensable para
Figura 1. Fases del ADM de TOGAF un buen arquitecto. De otra forma no
existe un consenso respecto a los do-
La fase preliminar es el momento en el cual cumentos y diagramas que se deben
se inicia el proceso de adopción del ADM al tener para definir la arquitectura de un
interior de la organización, difundiendo los sistema de software. Sin embargo el
beneficios e involucrando a todos las perso- ADM, como cualquier modelo de pro-
nas necesarias. cesos, debe adoptarse gradualmente,
sin intentar implementarlo de inmedia-
• Fase A. Visión de la arquitectura, impli- to al 100% y en todos los proyectos.
ca desarrollar una visión de la arquitec-
NOV-ENE 2009 43
 // PM CORNER
La integración de un equipo de
trabajo funcional
Reto del Líder de Proyectos de Tecnologías de Información
Por Francisco Vaca
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.
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.
44 NOV-ENE 2009
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?.
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
www.sg.com.mx
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”.
www.sg.com.mx
• 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.
• 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.
Conclusión
Podemos 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.
NOV-ENE 2009 47
 // COLUMNA invitada
Desarrollo de Software, Analogías
y Algo Más…
Cuidado con las Semejanzas
Por Carlos Ordóñez
D esde 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
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. fofo@iteso.mx
46 NOV-ENE 2009
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
www.sg.com.mx
 “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
www.sg.com.mx
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 software
La 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ón
Podemos 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.
NOV-ENE 2009 47
 // COLUMNA /*tendencias en SOFTWARE*/

¿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. luisdans@microsoft.com luisdans.com\Twitter

E l debate sobre que el 90% del software que hoy se utiliza pueda
ser entregado como servicio está energizando las conversaciones
¿Cómputo en la nube?
Aquí hay una primera confusión de términos: Web 2.0 se refiere a habi-
del futuro del software, creando encabezados alarmistas. El anuncio litar “la era de la participación” y “un internet más allá de texto e imá-
de la muerte del software en su forma actual es prematuro: estamos genes”. El problema es que el desarrollo de estas aplicaciones es muy
observando una evolución y no una revolución. 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
Antes y después de Internet proveedor. ¿Es un outsorcing convencional? EDS e IBM han jugado en
Hay que señalar que el requerimiento de las empresas, es utilizar el este campo por años. En Microsoft creemos que la diferencia funda-
software para desarrollar mejor su negocio y ofrecer ventajas com- mental está en la capacidad de construir software a la medida de forma
petitivas, sin importar el mecanismo de entrega. Es absurdo el abrir- simple. Windows “Strata” es el nombre clave que ofrece:
se a ultimatum “todo o nada”. Aclaremos las razones iniciando por
entender las ventajas de dos modelos. • Menores costos. Mediante economías de escala de Internet, se ofrece
arquitectura y ambiente escalable para que los desarrolladores ofrez-
Software tradicional Software entregado como servicio 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-
· Respuesta inmediata por el · Redundancia de datos
uso de recursos locales · Alcance mundial mos que todas las funciones de la plataforma aplicativa .NET, SQL
· Opera fuera de línea, sin red · Aprovisionamiento sencillo Server y Biztalk operen para construir todo tipo de aplicaciones.
· La privacidad está en control · Agilidad empresarial • Mayor productividad. Visual Studio no solo ofrecerá desarrollo para
del usuario · Administración
· Usuarios acostumbrados a esta · Instalación casi nula cliente, dispositivos portátiles y servidor: también para la nube.
experiencia · Acceso sencillo
· Alta capacidad de ser · Mantenimiento y nuevas versiones Windows “Strata” incluye servicios fundamentales y servicios para
personalizado ocurren de forma automática
· Visibilidad y control · Acceso desde casi cualquier dispositivo a
construir aplicaciones, que permiten a los terceros entregar software.
· Alta manipulación de datos (casi) cualquier hora La mejor manera de disipar dudas de disponibilidad y seguridad es
con aplicaciones · Nuevos modelos de negocio iniciando su evaluación inmediatamente.

Servicios
ServiciosTerminados
terminados Bloques
Bloques
de de
construcción
construcción Servicios
Servicios
Básicos
básicos
Pocos argumentarían que Internet ha transformado nuestras vidas • Soluciones personales Dispositivo, Sincronizar, Admi- Cómputo (10% CPU, 1 CPU,
de forma muy amplia. Casi nadie está en desacuerdo con que el te- “Windows Live” nistración de aplicaciones, 5000 CPUs), Almacena-
ner la flexibilidad y opción de seleccionar una forma mixta de operar • Soluciones empresa- Identidad, Control de acceso, miento, Administración de
es crítica para el negocio. Es poco realista pensar que una empresa riales “Microsoft online” Gestión de Base de datos, Flu- servicios, Redes, Distribu-
Fortune 50 tiene los mismos requerimientos que una empresa pe- jos de Trabajo, Bus de servicios... ción, Operaciones, Hardware
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 Los clientes como Windows 7 y Windows Mobile 6.5; y el software
cómputo en otros más avanzados?. La visión miope de entrega como en servidor continuarán un trayecto de evolución que responde a la
servicio es incapaz de permitir conversaciones balanceadas. juventud de la industria: hay mucho por hacer y ofrecer.

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
Conclusión
El 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

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

www.sg.com.mx NOV-ENE 2009
 // COLUMNA
Complejidad del Software
Una 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.
E n 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):
50 NOV-ENE 2009
/*PRUEBA DE SOFTWARE*/
(n) {
1: I1.1;
2: I1.2;
La externa nos habla de la complejidad del
problema, de la funcionalidad que se re-
… quiere del producto.
10: I1.10; }
Una subrutina de 7 LCs con instrucciones Una métrica utilizada para medir este tipo de
compuestas y primitivas: complejidad son los puntos de función3, que
f2 (n) { tienen la interesante ventaja de que se pueden
1: I2.1;
obtener incluso a partir de los requerimien-
2: if Cond2.1 then
3: I2.2; tos. Una desventaja es que, si bien el algorit-
4: else mo para calcularla no es complejo, no es tri-
5: while Cond2.2 vial y sí es laborioso; lo peor es que obtenerla
6: I2.3; automáticamente a partir de requerimientos
7: I2.4; }
–cuando resultaría más útil– es prácticamen-
Una subrutina de 5 LCs con instrucciones te imposible a menos que éstos hayan sido
compuestas y primitivas: especificados utilizando un lenguaje formal
f3 (n) { (como los de programación), situación casi
1: I3.1;
exclusiva de los métodos formales4.
2: if Cond3.1 then
3: f3 (Exp3.1);
4: else Impacto de la complejidad en la
5: f3 (Exp3.2); } prueba de software
Como mencionamos, ahí donde la comple-
Si no tomáramos en cuenta la complejidad jidad en el software es mayor, hay más pro-
interna, sino sólo el criterio del tamaño, di- pensión a errores, lo que en particular impli-
ríamos que f1 es la más grande de las 3 su- ca que debemos probar más.
brutinas, pues tiene más LCs. Sin embargo,
puede verse que no tiene la misma compleji- Esto también podemos verlo si comparamos
dad una secuencia de x instrucciones primi- los grafos de control asociados a las prime-
tivas, que otra de llamadas recursivas. ras subrutinas mostradas arriba:
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. Figura 1. Izquierda: grafo de f1; derecha: grafo de f2
www.sg.com.mx

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.
www.sg.com.mx
“Podemos hablar de dos vistas de la
complejidad de un producto de software:
interna y externa”.
• 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. ]
NOV-ENE 2009 51
 // TECNOLOGÍA
Tecnología RFID Como Dispositivo de Seguridad
Novedades 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 RFID
La 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.
52 NOV-ENE 2009
/*INFRAESTRUCTURA*/
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.
www.sg.com.mx
 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

El presidente actual de Colombia declaró que se podrían implantar • Etiquetas pasivas. Tienen 2 componentes conectados entre sí,
estos chips a los ciudadanos colombianos que quisieran ir a tra- un microchip y una antena. Estas etiquetas son las de menor ta-
bajar a Estados Unidos, para que el gobierno de ese país pudiera maño, por ende las más livianas y con una vida útil que puede ir
controlar su ubicación4. hasta los 99 años8.

Un reconocido club en Barcelona, España, utiliza un VeriChip para Pueden proporcionar información sobre la identificación y localiza-
identificar a sus clientes VIP, lo utilizan para comprar las bebidas. ción sobre el producto marcado con la etiqueta como por ejemplo
El departamento de policía de la Ciudad de México ha implantado precio, color, fecha de compra, etcétera, son usadas en los puntos
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ón
Las etiquetas RFID se pueden clasificar principalmente en tres cate-
gorías, dependiendo del alcance y capacidad de memoria: pasivas,
activas y semiactivas o semipasivas.

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

 // TECNOLOGÍA /*INFRAESTRUCTURA*/

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.
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.

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 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.

• Etiquetas semipasivas. Poseen baterías pero permanecen dor- Se utilizan en bibliotecas y seguimiento de libros, control
midas hasta que reciben una señal proveniente de un lector. El de acceso en edificios, seguimiento de equipaje en aerolí-
rango de lectura de una etiqueta semiactiva, o semipasiva, puede neas, seguimiento de artículos de ropa y en pacientes de cen-

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

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


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
Identificación En 2006, la FDA (Food and Drug
de Pacientes 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.
www.sg.com.mx
Pasaporte 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.
Licencia de El estado de Virginia ha pensado en poner
Conducir etiquetas RFID en las licencias de condu-
cir, para hacerlos mas confiables y evitar
que se puedan conseguir documentos de
identidad falsos.
Tráfico y En Londres, el control de acceso con
Posicionamiento 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.
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ía6.
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.
NOV-ENE 2009 55
 // TECNOLOGÍA /*INFRAESTRUCTURA*/
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
56 NOV-ENE 2009
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 2008
1. 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
www.sg.com.mx
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.
Conclusión
La 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
www.sg.com.mx
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.
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 ]
NOV-ENE 2009 57
 // tecnología
Perdiendo el Miedo a la Programación Paralela
Ejemplo 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-
58 NOV-ENE 2009
/*multicore*/
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 paralelismo
Primero 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;
} de que dos threads accedieran el arreglo de
} la misma letra al mismo tiempo .El listado
}
}
}
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 OpenMP
Actualmente 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
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
www.sg.com.mx
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 Thread
Checker
Para 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.
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.
www.sg.com.mx
Figura 1. Resultados del Intel Thread Checker
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;
}
}
} Este artículo abordó la implementación (a
} través de OpenMP) y depuración (con Intel
} Thread Checker). Para este pequeño programa
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.
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 ]
NOV-ENE 2009 59
 // tecnología /*gadgets*/

Tivoli
NetWorks Radio
Hay 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.

Firebox
Brick USB
Para 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.

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

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. Casio
Adicionalmente, soporta
acceso seguro a servidores Exilim EX-Z300
de documentos SharePoint.
Así que si buscas un dispo- Como parte de las nuevas tendencias en cámaras di-
sitivo móvil que te permita gitales para la temporada otoño - invierno 2008, Casio
manejar los mismos docu- lanzó seis modelos de la serie Exilim, y elegimos la
mentos que manejas en la EX-Z300 por llevar consigo la etiqueta de “el mejor des-
oficina de forma rápido y empeño” y por estar dirigida hacia aficionados exigen-
sencilla, el Treo Pro puede tes, que también disfrutan subiendo videos a YouTube.
ser una gran opción. 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 PC
Como 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ía
de 3 ó 6 celdas con rendimiento de hasta 55 horas. Opera con Windows Vista, XP o Linux.

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

 // fundamentos
¿Por qué Cuesta Tanto Darle una Oportunidad
a la Usabilidad?
Mejorando la experiencia del usuario
Por Romeo Márquez
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 real
Es 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 hicimos
Romeo: ¿ 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
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 romeo@gelattina.com
62 NOV-ENE 2009
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.
www.sg.com.mx
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
Conclusión
Siempre 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.
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 ]

INDEX

DIRECTORIO Anunciante Páginas Sitio

Adecco 2F, 1 www.adecco.com.mx

Avantare 41 www.avantare.com
AMITI 49 www.amiti.org.mx
Brio 39 www.brio.com.mx
Compusoluciones 45 www.compusoluciones.com
Compushow 51 www.compushow.com.mx
IT Institute 9 www.it-institute.org
Microsoft F0 www.microsoft.com.mx
Milestone Consulting 4F www.milestone.com.mx
NYCE 3F www.nyce.org.mx
SafeNet 11 www.safenet-inc.com
SG Campus 13 www.sgcampus.com.mx
SIE Center 17 esicenter.itesm.mx

TENEMOS UN ESPACIO
RESERVADO PARA TI
Si deseas anunciarte contáctanos
en el (55) 5239 5502 o en
publicidad@sg.com.mx

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

 // carrera
¿Cómo Enseñar a los Programadores del Futuro?
¿Estructurada, POO o Scripts?
Por Gunnar Wolf
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-
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.
64 NOV-ENE 2009
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 ]
www.sg.com.mx