• Mejora de Procesos

• Mantenimiento
• Diseño orientado
a objetos

[ ENTREVISTA ]
Scott Ambler
La Evolución de Ágil
Software Guru CONOCIMIENTO EN PRÁCTICA
Año 03 No. 4 • Julio-Agosto 2007 • www.sg.com.mx

México, $65.00

WEB 2.0 El poder de la colaboración

Noticias • Eventos • Fundamentos • UML • Infraestructura • Biblioteca • Gadgets [ Tutorial ]
Apache Lucene
 // CONTENIDO
Editorial
Sabemos que cuando les llegue esta
revista probablemente ya vayan a estar
hartos de oír sobre Web 2.0 y estén listos
para ahorcar a la próxima persona que
se quiera hacer el interesante sacando a
colación este término. Definitivamente es
algo que ha sido sobreexplotado, y since-
ramente nos disculpamos por contribuir a
ello. Es solo que consideramos que real-
mente es algo notable, y por lo tanto no lo
podíamos dejar pasar sin atender. Hemos
hecho un gran esfuerzo por proveer artí-
culos serios y objetivos que los ayuden
a formar una opinión propia e informada
sobre esta tendencia.
Para nosotros, lo verdaderamente nota-
ble de Web 2.0 no es la tecnología, sino
la participación. Esto es lo que realmen-
te agrega valor y le da su sabor. Es por
ello que los invitamos a participar para
generar la creatividad de este número, y
estamos muy satisfechos con los resulta-
dos. La verdad es que no cualquier revista
puede darse el lujo de darle tan solo un
par de días a sus lectores para que en-
víen fotografías personales, y obtener tan
02 JUL-AGO 2007
buena respuesta. Muchas gracias. Espe-
ramos que les haya gustado el resultado,
y que logren encontrarse por ahí.
Esta edición de SG es una de las más den-
sas que hemos hecho, en términos de
contenido técnico. Esperamos que sea de
su satisfacción. Ya saben que con gusto
recibimos cualquier retroalimentación en
editorial@softwareguru.com.mx
Cada vez está más cerca SG ’07. Estamos
muy emocionados de volver a verlos y sen-
tir esa energía. Sabemos que ustedes tam-
bién están muy interesados en poder asis-
tir para aprender y compartir experiencias
con sus colegas. Les garantizamos que
estamos haciendo todo para que esta edi-
ción salga todavía mejor que el año pasa-
do. La visión sigue siendo la misma: tener
en México un congreso de clase mundial
para profesionistas de software.
— Equipo Editorial
directorio
Dirección Editorial
Pedro Galván
Dirección de Operaciones
Mara Ruvalcaba
Arte y Diseño
David Gutiérrez
Oscar Sámano
Consejo Editorial
Francisco Camargo, Ralf Eder, Raúl Trejo,
Guillermo Rodríguez, ITESM-CEM;
Hanna Oktaba, UNAM-AMCIS;
Luis Cuellar, Softtek;
Luis Vinicio León, e-Quallity - ITESO.
Colaboradores
Oscar Cortés, Miguel Ángel Morán,
Aldo Hernández, Alexis Castañares,
Edgar Parada, Carlos “Fofo” Ordoñez,
Rocío García Ocaña, José M. Esquivel,
Aquiles Santana, Juan M. Hernández,
Luis Daniel Soto, Sergio Orozco, Ariel García,
Emilio Osorio, Jorge Palacios, Susana Tamayo.
Fotografía
Lectores SG
Ventas
Claudia Perea
Natalia Sánchez
Marketing y RP
Dafne Vidal
Circulación y Subscripciones
Daniel Velázquez
Administración
Araceli Torres
Contacto
info@softwareguru.com.mx
+52 55 5239 5502
SG Software Guru es una publicación bimestral
editada por Brainworx S.A. de C.V., Malinche no.
6, Col. El Parque, C.P. 53398, Naucalpan, México.
Queda prohibida la reproducción total o parcial
del contenido sin previo aviso por escrito de los
editores. Todos los artículos son responsabilidad de
sus propios autores y no necesariamente reflejan el
punto de vista de la editorial. Reserva de Derechos
al Uso Exclusivo: 04-2004-090212091400-102.
Certificado de licitud de título: 12999. Certificado
de licitud de contenido:10572. ISSN: 1870-0888.
Registro Postal: PP15-5106. Se imprimió en julio de
2007 en Litográfica Roma. Distribuido por Rrecca
Comercializadora y Sepomex.
www.sg.com.mx
 contenido
jul-ago 2007

18 EN PORTADA
WEB 2.0
A través de una variedad de artículos
definimos qué es el Web 2.0, qué carac-
terísticas tienen las aplicaciones de este
tipo, y cómo es que se desarrollan.

Productos
LO QUE VIENE 10
Tecnologías RIA, Visual Studio 2008,
JBoss Seam 2.0, Spring Batch

TUTORIAL 12
Desarrollo de código seguro
con Visual Studio

Columnas Prácticas
Tejiendo Nuestra Red 06 Tendencias en Software 43 MANTENIMIENTO 32
por Hanna Oktaba por Luis Daniel Soto Mantenimiento de Software
José M. Esquivel hace un repazo sobre la impor-
Mejora Continua 08 Tierra Libre 46 tancia del mantenimiento de software, y algunas
por Luis Cuellar por Emilio Osorio mejores prácticas de esta disciplina.

Cátedra y Más 30 ADMINISTRACIÓN DE PROYECTOS 34

por Raul Trejo Análisis de Puntos Función, parte 3
Finalizamos este caso de estudio, donde apren-
dimos a aplicar la técnica de análisis de puntos
función a un caso real.
En Cada Número
MEJORA DE PROCESOS 37
Noticias y Eventos 04 INFRAESTRUCTURA 50 Las 7 Claves de la Mejora de Procesos
Rocío García comparte con nosotros algunos
Fundamentos 48 BIBLIOTECA 56 tips y recomendaciones clave para la mejora de
procesos en las organizaciones de software.

DISEÑO 40

14
El Mariachi Orientado a Objetos
Carlos Ordoñez adopta un enfoque divertido para
explicar un tema bastante complicado: la incor-
Entrevista poración de patrones para hacer más flexible y
Scott Ambler robusto un diseño orientado a objetos.
La Evolución de Ágil

www.sg.com.mx JUL-AGO 2007 03

 // NOTICIAS

SUN Tech Days 2007

La gira mundial Sun Tech Days 2007 realizó su visi-
ta correspondiente a la ciudad de México del pasado
16 a 18 de mayo. Este tour visitó 15 ciudades en todo
el mundo, y es una excelente noticia que se hayan in-
cluido 3 ciudades de América Latina: Buenos Aires,
Sao Paulo, y Ciudad de México. Algo que le dio mucha
fuerza al evento de Ciudad de México es que se reali-
zó apenas unos días después del JavaOne 2007, y las
presentaciones ya incluían mucho de lo que se vio en
dicho evento, así que los asistentes tuvieron oportuni-
dad de estar en contacto con lo último de lo último en
cuanto a tecnologías como Java, Solaris y NetBeans. Los
archivos de las presentaciones se pueden descargar en:
http://suntechdays.com.mx/downloads/

IBM Strategic Innovation Forum

Los pasados 29 y 30 de mayo, IBM llevó a cabo el Stra-
tegic Innovation Forum, uno de los eventos más im-
portantes de IBM en el 2007, donde acudieron clien-
tes de diferentes industrias en busca de propuestas
que les apoyen a mejorar sus procesos y estrategias
de negocio. Se revisaron temas como la optimización
de la infraestructura, el poder de la información, go-
bernabilidad, manejo de riesgos, y la flexibilidad en los
negocios. Eduardo Gutiérrez, Director de la división de
software en México, nos comentó que el siguiente paso
de IBM es convertirse en la empresa de software más
importante. Por lo que estaremos recibiendo noticias
de IBM en el segmento de software.

Directores TI 2007
Los días 13 al 15 de junio, hospedada en la Universidad Vera-
cruzana, se llevó a cabo la XVI Reunión Nacional de Directores
de Escuelas y Facultades de Informática y Computación, que
organiza la Asociación Nacional de Instituciones de Educación
en Tecnologías de la Información – ANIEI. Durante la reunión
se realizaron mesas de trabajo que revisaron temas como: mo-
delos curriculares, vinculación academia-industria-gobierno, y
siguientes metas para la estrategia 2 de PROSOFT, entre otros.
Como problemas prioritarios se identificó la baja en las matrí-
culas de las carreras de TI, la enorme brecha entre la oferta
y la demanda de capital humano; problemas que ya en la ac-
tualidad, impiden el desarrollo de la industria de software en
México. Ya los Directores de las carreras de TI se encuentran
trabajando al respecto, pero es necesario que todos los involu-
crados pongamos nuestro granito de arena.
Para mayor información visita: www.aniei.org.mx

04 JUL-AGO 2007 www.sg.com.mx


16 al 18 de Julio 2007
CIISA 2007
Guadalajara, Jalisco
Info: www.ciisa.gda.itesm.mx
e-mail: ciisa.gdl@servicios.itesm.mx
25 y 26 de Julio 2007
Mexico and the Knowledge Society
Strategic IT Training Cycle, Cutter Consortium
25 de Julio - Hotel Camino Real, Monterrey, N.L.
26 de Julio - Hotel JW Marriott, Cd. de México
Info: www.cutter.com.mx/ciclo2007
Tel: +52 (81) 2282 6266 y +52 (55) 5336 0418
e-mail: eventos@cutter.com
26 de Julio 2007
El Director de Proyectos y
el Analista de Negocios
Ciclo de conferencias, PMI Capítulo México y REPs
Cd. de México
Info: www.pmichapters-mexico.org/mexico
e-mail: info@pmichapters-mexico.org
AMITI elige nuevo Consejo Directivo
El pasado mes de mayo, los socios de la AMITI eligieron
por votación a los integrantes del nuevo Consejo Directivo
que ha de conducir los trabajos de esta asociación en el
periodo 2007 - 2009. Varios de los consejeros fueron rati-
ficados, lo que asegura continuidad en las iniciativas de la
asociación. Por su parte, el actual Presidente Rafael Funes,
Director General de DynaWare, ha sido un actor incansable
en pro del fortalecimiento de la industria. AMITI continuará
trabajando para hacer más competitivos a todos los actores
económicos y sociales del país, a través del uso y aprove-
chamiento de las TIs.
Empresas recientemente
evaluadas en CMMI y MoProSoft:
Empresa Evaluación Apoyado por:
Computación XXI MoProSoft 1 – nov 2006 SIE Center*
Praxis CMMI 4 – ene 2007 América XXI
Medisist CMMI 2 – feb 2007 SIE Center*
ST CMMI 2 - feb 2007 SIE Center*
Novutek CMMI 3 – may 2007 Itera
Mexware CMMI 3 – jun 2007 Itera
EISEI CMMI 2 – jul 2007 Innevo
*Ahora ESI Center
www.sg.com.mx
// EVENTOS
23 de Agosto 2007
Estrategia para una PMO y Equipos Virtuales
Ciclo de conferencias, PMI Capítulo México y REPs
Cd. de México
Info: www.pmichapters-mexico.org/mexico
e-mail: info@pmichapters-mexico.org
27 y 28 de Agosto 2007
IDC 3a. Cumbre de Gobierno y Tecnología
Centro Banamex, Cd. de México
Info: www.idc-eventos.com
e-mail: idc@simrel.com.mx
30 y 31 de Agosto 2007
Agile Project Management:
Innovation in Action
Strategic IT Training Cycle, Cutter Consortium
30 de Agosto - Hotel Camino Real, Monterrey, N.L.
31 de Agosto - Hotel JW Marriott, Cd. de México
Info: www.cutter.com.mx/ciclo2007
Tel: +52 (81) 2282 6266 y +52 (55) 5336 0418
e-mail: eventos@cutter.com
Gartner Outsourcing Summit
El pasado 27 de junio, Gartner presentó la tercera edi-
ción del Outsourcing Summit, tocando como tema prin-
cipal el aprovechamiento de los activos y servicios de
TI, para lograr mejores resultados del negocio. Los ana-
listas de Gartner presentaron temas relacionados con:
multisourcing, evaluación y selección de proveedores,
servicios tercerizados de TI y Business Process Outsour-
cing, entre otros. Al término del evento, los asistentes
lograron obtener una visión clara de las áreas del “Out-
sourcing”, con una perspectiva de todas las opciones,
riesgos y oportunidades disponibles.
Congreso ANADIC 2007
Con sede en Cancún, Quintana Roo, se llevó a cabo del 27
al 30 de junio el 7º Congreso Nacional de la ANADIC, en
el cual participaron mayoristas y distribuidores de TI de
toda la República. En el evento liderado por Francisco
Wilson, Presidente de la Asociación,  se reunieron  los
representantes de las diferentes empresas que forman
parte de ANADIC y ANADICSoft, además de diversos go-
bernadores y diputados. El evento estuvo lleno de dis-
tintas actividades como: foros, reuniones de trabajo,
presentaciones de productos, talleres, capacitación y
certificaciones.
JUL-AGO 2007 05
 // COLUMNA
// COLUMNA
Lo que Pasó en Moscú
El Tercer Capítulo de WG4
La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnolo-
gía Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS. Actualmente es miembro de
International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.
D el 21 al 25 de mayo de 2007 Moscú fue la sede de la se-
sión plenaria del comité ISO/IEC JTC1 SC7 dedicado a la
generación de normas para el área de Ingeniería de Software
y de Sistemas. Los lectores de SG ya saben que en este comité
se creó un grupo de trabajo WG24, para generar una norma de
Software Life Cycle Profiles and Guidelines for use in Very Small
Enterprises (VSE). También saben que hace un año en Bangkok,
este grupo decidió tomar la norma mexicana basada en MoPro-
Soft y EvalProSoft, como punto de partida para los trabajos del
grupo. En el número de noviembre-diciembre 2006 de SG, les
relatamos lo que pasó en la segunda participación de la Delega-
ción Mexicana en octubre pasado en la ciudad de Luxemburgo,
la que terminó en la selección de un subconjunto de procesos
de la categoría de Operación de MoProSoft como candidatos a
ser la primera guía de implementación de procesos identificado
como Perfil 1.
En Moscú, Ana Vázquez y yo, formamos la Delegación que re-
presentó a México. La sesión plenaria del lunes 21 de mayo em-
pezó con la presentación de alrededor de 140 delegados que
vinieron de varios países para participar en 13 grupos de traba-
jo. Uno de los grupos más importantes es el WG7 (Development
of Standards and Technical Reports on Life Cycle Management),
que tiene a su cargo la actualización de la norma 12207 (Soft-
ware Life Cycle Processes), y el otro es el WG10 (Development
of Standards and Guidelines Covering Methods, Practices and
Application of Process Assessment), que tiene a su cargo la ac-
tualización de la norma 15504 (Process Assessment).
Las Delegaciones más numerosas, de entre 10 y 20 personas,
provenían de países angloparlantes (Estados Unidos, Canadá,
Gran Bretaña, Australia) y de los asiáticos (Japón y Corea). Los
demás tuvieron representaciones más modestas. Nos sorpren-
dió que de la India llegara una sola persona; y que la Delega-
ción China la formaran solamente dos mujeres jóvenes, al igual
que la Delegación Mexicana (restando lo de joven en mi caso).
De los países latinoamericanos no hubo ninguna otra represen-
tación, pero, afortunadamente, España tuvo tres enviados con
quienes formamos una spanish connection que, por su alegría,
atraía en espacios de ocio a otros participantes para tomar cla-
ses de español gratis.
06 JUL-AGO 2007
/*TEJIENDO NUESTRA RED*/
Después de las formalidades de la inauguración, nos dirigimos
a los lugares de trabajo asignados a cada grupo. El grupo WG24
contaba, en su gran mayoría, con los mismos asistentes que en
Luxemburgo: los delegados de Bélgica, Luxemburgo, Finlandia,
Canadá (dos personas), Estados Unidos, Tailandia (dos perso-
nas) y Australia. También se incorporó un asistente de Japón y
algunos otros, como el de la India, que venían ocasionalmente
para enterarse de lo que pasaba en nuestro grupo.
El resumen de los resultados de trabajo de una semana del
WG24 en Moscú es el siguiente:
• La futura norma ya tiene su número: 29110 (apréndanselo por
favor, porque a mi me va a costar trabajo).
• Contará con cinco partes:
o La primera describirá el contexto y las características de em-
presas pequeñas de desarrollo de software a nivel mundial y las
razones por las cuales ameritan una atención especial de ISO.
o La segunda explicará el concepto de perfil y su taxonomía.
o La tercera describirá el perfil, que es el conjunto de requisitos
de otros estándares que se tomaron como base para crearlo.
o La cuarta se dedicará al modelo de evaluación de perfiles, y
o La quinta va a contener la guía para implementar el Perfil 1
basado en nuestro modelo de procesos y en paquetes de im-
plementación aportados por otros miembros del grupo.
El trabajo de nuestro grupo estuvo enfocado en obtener resul-
tados, pasamos de una etapa de propuestas a otra de decisio-
nes concretas, lo que permitirá que en octubre, al término de la
siguiente reunión, el WG24 entregue el primer Working Draft de
los cinco documentos.
Se estima que todas estas partes se convertirán en norma en
2010. No se sorprendan, ¡son los tiempos ISO! En México pode-
mos aprovechar que ya tenemos este perfil y unos cuantos más,
es decir: el MoProSoft completo, como norma nacional.
Por otra parte, nos dimos cuenta de lo importante que sería tener
representantes en otros grupos de trabajo del SC7, para estar dón-
de “se cuecen la habas” y poder transmitirlo rápidamente a nuestra
industria. En Moscú, también entendimos y reconocimos la visión y
la aportación personal de Arnoldo Díaz de Certum, que con sus re-
www.sg.com.mx
cursos y, a nombre de México, participó a mitad de los años 90 en
la definición de la norma 15504. Arnoldo tuvo el valor de demostrar
que México no sólo es un país “consumidor” de estándares, sino que
también puede ser “aportador” de ideas. Como parte de su partici-
pación organizó una reunión del comité en Acapulco, que todavía es
recordada con gusto por algunos de los delegados. Desafortunada-
mente cuando Arnoldo se retiró, la participación de nuestro país per-
dió continuidad y durante muchos años no tuvo representación en el
comité. A diferencia de otros países que tienen políticas y recursos
destinados para este tipo de actividades, México todavía no cuenta
con esquemas similares. Generarlos es un reto que debemos tomar.
con los delegados de otros países fue un elemento muy importante
de promoción para México. Sobre todo, en los primeros días, cuando
mis clases de ruso de primaria y secundaria en Polonia dieron por fin
sus frutos para facilitarme la lectura y el entendimiento de los letre-
ros en el metro, y los menús en los restaurantes, lo que aumentó la
popularidad de nuestra Delegación. También la belleza mexicana de
Anita tuvo su impacto entre algunos delegados de tierras frías.
—Hanna Oktaba

Para finalizar, les dejo alunas reflexiones de tipo turístico: Moscú,

“la ciudad de calles anchas”, como la define Jorge Volpi en su muy
recomendable novela “No será la Tierra”, es una ciudad grande, con
3 millones de carros y el tráfico poco envidiable de la Ciudad de
México. La Plaza Roja tiene una belleza especial, el metro es el mejor
medio de transporte y el vodka es el tequila de allá, nada más que
se consume en mayores cantidades y a todas horas. La convivencia

www.sg.com.mx JUL-AGO 2007

 // COLUMNA
// COLUMNA
Personas y Procesos
¿Donde Está el Problema?
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.
Hace algunas semanas me encontraba dando una asesoría cuando una
de las personas preguntó lo siguiente: “dado que un proceso es una
secuencia de actividades, y dado que toda mi gente ejecuta activida-
des y todos ellos utilizan alguna herramienta como SAP, PeopleSoft o
similar, que los obligan a seguir una secuencia, entonces: ¿no sería la
mía, una organización orientada a procesos? ¿Qué es lo que diferencía
a una organización orientada a procesos de otra que no lo está?”. Una
pregunta interesante. A fin de cuentas, todos ejecutamos secuencias de
actividades, lo cual, es la base de todo proceso. ¿Pero exactamente qué
hace que una organización se clasifique como orientada a procesos?
Las personas y los problemas
Antes que nada, la primera pregunta es: ¿para que moverse a una or-
ganización orientada a procesos? Todos hemos escuchado que en las
organizaciones de software, la gente es el activo más preciado. Para
brindar un servicio de excelencia, se requiere gente experimentada,
comprometida, y orientada al servicio. Lo importante es la gente, los
procesos no son nada sin ella. Por eso, si vamos a lograr un servicio
de calidad, la organización debe estar enfocada a la gente, y no a los
procesos. Dicho lo anterior, también debemos estar conscientes de que
los procesos aumentan la productividad y eficacia de la gente. Una orga-
nización de clase mundial está formada por tres componentes básicos
representados en la figura 1:
Figura 1. Los tres componentes de las organizaciones de clase mundial
Los tres vértices: personas, herramientas y procesos, están interrela-
cionados y forman un todo. Es un hecho que los procesos no existen
sin la gente, pero la gente sin procesos no puede lograr un servicio
consistente.
La felicidad esta en la moderación
El servicio orientado a procesos implica que existe un balance entre:
1. La gente que asegura la calidad y flexibilidad del servicio, en base a su
conocimiento y habilidades.
2. La tecnología que apoya a los individuos con información requerida
en forma rápida, concisa y oportuna para lograr los objetivos de calidad,
productividad y excelencia.
3. El proceso que entreteje todo esto en una serie de actividades y ser-
08 JUL-AGO 2007
/*MEJORA CONTINUA*/
vicios coherentes con la finalidad de sumar el trabajo de cada individuo
en un todo a gran escala, apoyando a asegurar la consistencia y produc-
tividad del servicio.
Detectando la madurez
Cuando se tiene algo de experiencia trabajando en áreas de calidad, es
relativamente fácil detectar la madurez de una organización con tan solo
unos minutos de diálogo con los empleados.
Una organización poco madura está principalmente basada en la ha-
bilidad adquirida de las personas asignadas. Esto quiere decir que
no importa lo que pase, cualquier eventualidad no planeada o no
definida es atribuible a la persona que tenía como responsabilidad
ejecutar correctamente esa actividad; lo que nos lleva a dos efectos
secundarios:
• Como parte de la naturaleza humana, cuando se echa la culpa de un
problema de la organización a una persona, ésta inmediatamente busca
otros culpables que tomen por lo menos parte de la responsabilidad (el
cliente, la gente que se me asignó, el área encargada de la infraestruc-
tura, etcétera). Esto hace parecer que todo lo que pasa en proyectos
depende de tantas variables fuera de nuestro control, que resulta impo-
sible o al menos poco práctico prevenirlas.
• Y el otro efecto tiene que ver con que la única forma de prevenir que
vuelva a suceder es llamarle la atención a la persona o asignar a alguien
más, ya que la otra persona demostró no ser capaz de resolver lo que
se le asignó. Normalmente, en una organización de este tipo la conver-
sación que se escucha tiene que ver con establecer culpables, deslindar
responsabilidades y criticar el trabajo de otros.
En una organización orientada a procesos, el individuo es en parte res-
ponsable del problema, pero una gran parte del análisis se enfoca en
detectar errores en el diseño o ejecución de un proceso. Si la persona
no ejecutó lo que debería ejecutar, se le llama la atención, pero el aná-
lisis real viene al revisar cómo falló el proceso de entrenamiento que
no le dio las habilidades necesarias, porqué el proceso no detectó la
falla antes de que se hiciera un problema. Las posibilidades de mejora
son infinitas. Esto crea otro efecto secundario: ya que la culpa no es
del individuo, en lugar de enfocarnos en, ¿cómo cambiamos a la per-
sona?, nos juntamos todos a buscar donde falló el proceso. La cultura
se vuelve de cooperación. Ya no son todos juzgando mi trabajo, somos
todos nosotros tratando de prevenir que vuelva a suceder.
Si quieres saber si una organización está orientada a personas o a pro-
cesos, simplemente espera que algo salga mal y observa si la conver-
sación se enfoca en culpar a las personas o en reparar los procesos.
Se puede predecir fácilmente el nivel de madurez de una organización
simplemente midiendo el grado de cooperación que existe entre los in-
dividuos, al encontrarse con un problema.
—Luis R. Cuellar
www.sg.com.mx
www.sg.com.mx JUL-AGO 2007
 // PRODUCTOS /* LO QUE VIENE*/
Flex, Silverlight y JavaFX
La guerra de las RIA
A pesar de todo el ruido que ha habido en el escenario de tecnologías
RIA en los últimos años, realmente no ha habido una competencia in-
terna fuerte. Los principales jugadores habían sido Ajax y Flex, siendo
ambos tan diferentes en su estructura y comportamiento, que estaban
más cerca de complementarse que de competir. Sin embargo, esto cam-
bió a principios de mayo, cuando Microsoft lanzó Silverlight, un plugin
para ejecutar aplicaciones enriquecidas y multimedia, lo cual compite
directamente con Flash/Flex. Todavía un par de semanas después Sun
Microsystems se agregó a la competencia dando a conocer JavaFX, una
tecnología para desarrollar y ejecutar clientes enriquecidos tanto para
desktops como dispositivos móviles. Es así que podemos declarar ofi-
cialmente iniciada la guerra de los RIA.
Uno de los primeros acontecimientos notables al respecto, es que Mi-
guel de Icaza ya se apuró a desarrollar una implementación de Silverlig-
ht basada en Mono, que lleva el nombre de Moonlight.
Por otro lado, JavaFX se está moviendo un poco más lento, ya que has-
ta el momento Sun solo ha liberado dos productos específicos: JavaFX
Script, que es el lenguaje de scripting para desarrollar aplicaiones, y
JavaFX Mobile, el ambiente de ejecución para dispositivos móviles.
Sun ha indicado que le restan varios productos por liberar dentro de la
familia de JavaFX, pero no ha dado detalles sobre cuales son, y cuando
saldrán. También ha anunciado que JavaFX será eventualmente libe-
rado como software libre bajo licencia GPL, sin embargo no ha dado
fecha para esto.
En SG estaremos al pendiente de lo que suceda en esta arena, y
estaremos publicando artículos relacionados con las diferentes
tecnologías para que puedan conocerlas más a fondo.
JBoss Seam 2.0
Uniendo Web 2.0 con Java EE
Tan solo tres meses después de liberarse la versión 1.2.1 de Seam, ya te-
nemos disponible un beta de la versión 2.0. Como ya hemos comentado
anteriormente, Seam es un framework Java para desarrollar aplicaciones
Web de nueva generación que unifica e integra tecnologías como Ajax,
Java Server Faces, EJBs, Java Portlets y capacidades de BPM.
Gavin King, desarrollador en jefe de Seam, nos comentó que entre las
principales características de esta versión están:
• Soporte a Groovy
• Soporte a Google Web Toolkit
• Integración de búsqueda con Hibernate
• Soporte para JSF 1.2
•Soporte para transacciones independientes de JTA
Más información en www.jboss.com/products/seam
10 JUL-AGO 2007
Visual Studio 2008
Ambiente de desarrollo para .NET 3.0
La próxima versión de Visual Studio, que anteriormente era
conocida por el nombre clave “Orcas” ya se aproxima a su
última etapa antes del lanzamiento. Actualmente está dispo-
nible como Beta 1, y se espera un Beta 2 este verano, para es-
tar lanzando el producto final antes de que termine el año.
Entre las características más esperadas de esta versión está
el soporte a la versión 3.0 del .NET Framework, incluyendo
C# 3.0 y LINQ (Language Integrated Query), lo cual tendrá un
fuerte impacto en la forma en que se desarrollan aplicacio-
nes .NET. Otra característica importante es que Visual Studio
Tools for Office –el componente para extender las aplicacio-
nes de Office– ya estará integrado dentro de Visual Studio
2008. Asimismo, Visual Studio Tools for Office –el compo-
nente para extender aplicaciones de Office– ya vendrá inclui-
do como parte de Visual Studio.
Más información en msdn2.microsoft.com/en-us/vstudio
Spring Batch
Framework para trabajos Batch
Como sabemos, recurrir a procesos batch es una
solución muy común en las empresas para procesar
grandes cantidades de datos. La falta de una arqui-
tectura estándar para procesos batch no le deja a las
organizaciones otra opción más que desarrollar so-
luciones in-house, haciendo un desarrollo diferente
cada vez que se encuentran con esta necesidad. El
objetivo de Spring Batch es cambiar esto, ya que es
un framework para facilitar la creación y administra-
ción de procesos batch.
Spring Batch fue creado por Interface21 en colabo-
ración con Accenture, quien aportó su experiencia
y ejemplos acumulados en décadas de desarrollar
procesos batch para sus clientes. La mejor noticia es
que Spring Batch es open source, de tal forma que
cualquiera puede descargarlo, utilizarlo, y extender-
lo o personalizarlo a sus necesidades específicas.
Hablar sobre procesos batch no es algo muy sexy, y por
lo tanto este producto no ha recibido mucha atención
por parte de los medios. Sin embargo, nosotros en-
tendemos la importancia y utilidad de un framework,
así que les recomendamos echarle un ojo, puede ser
de gran ayuda en su próximo proyecto.
Más información en:
www.springframework.org/spring-batch
www.sg.com.mx
www.sg.com.mx JUL-AGO 2007
 // PRODUCTOS
Apache Lucene y Solr
Búsqueda sencilla y poderosa
Por Pedro Galván
¿ Alguna vez han considerado que es iróni-
co de que la funcionalidad más impor-
tante y útil del web es la búsqueda, no existe
una solución común para agregar capacidad
de búsqueda a las aplicaciones web?
La mayoría de las aplicaciones simplemente
utiliza la funcionalidad básica que provee
el motor de base de datos que estén utili-
zando. Aquellas aplicaciones que requieren
un sistema de búsqueda más complejo y
flexible típicamente deben recurrir a pro-
ductos comerciales, o desarrollar una so-
lución desde cero. Afortunadamente esto
ya no será necesario, ya que el proyecto
Apache Lucene nos brinda una solución de
búsqueda sofisticada y flexible que provee
capacidades que compiten con las de los
productos comerciales.
Lucene es un motor de búsqueda de alto de-
sempeño escrito en Java. Está diseñado y de-
sarrollado de tal forma que se pueda utilizar
en prácticamente cualquier aplicación que
requiera búsqueda de texto completo, espe-
cialmente aplicaciones multiplataforma.
En esencia, Lucene es una librería que pu-
ede ser invocada desde aplicaciones Java
para realizar búsquedas. Pero si lo que que-
remos es una funcionalidad de mayor nivel,
y donde no necesariamente tengamos que
usar Java, podemos recurrir a Solr. Solr es
un servidor de búsqueda basado en Lu-
cene, que provee funcionalidad de más alto
nivel, como:
• APIs para XML/HTTP y JSON
• Resaltar resultados
• Cache
• Replicación
Dedicaré el resto de este artículo a expli-
car como instalar y utilizar una solución de
búsqueda utilizando Solr.
1. Instalación de Solr
Para ejecutar Solr requerimos tener insta-
lado un JDK 1.5 o posterior.
Teniendo instalado nuestro JDK, simple-
mente descargamos la versión más reciente
12 JUL-AGO 2007
/* TUTORIAL*/
de Solr de http://mirror.x10.com/mirror/
apache/lucene/solr/ y extraemos el con-
tenido en nuestra computadora.
Solr se puede ejecutar en cualquier con-
tenedor de Servlets como Tomcat o Jetty. Por
simplicidad, para este ejemplo utilizaremos
una versión de Jetty que viene incluida en el
directorio de ejemplos de Solr. Para arran-
car Solr simplemente entramos al directorio
examples y ejecutamos el comando:
java -jar start.jar
Esto inicia una instancia de Jetty en el
puerto 8983 de nuestra máquina, así que
si todo salió bien, debemos poder entrar a
http://localhost:8983/solr/admin/ y ver
el panel de administración de Solr.
2. Definiendo la estructura de
la información
Ya tenemos andando nuestro servidor Solr.
Sin embargo, no tenemos datos, por lo que
cualquier búsqueda que hagamos regresa
0 resultados. Para agregar datos a Solr
primero debemos definir la estructura de la
información que indexaremos y almacena-
remos para búsqueda.
Al igual que la mayoría de las aplicaciones
en Java, la configuración de Solr se guarda
en archivos XML. El esquema XML que con-
tiene la definición de la estructura de datos
para indexar y almacenar está en el archivo
solr/conf/schema.xml.
En schema.xml se definen los campos que
tendrán nuestros elementos de información.
Para cada campo se puede especificar si se
debe indexar (para que se pueda utilizar en
búsquedas) y si se puede almacenar (para
que se pueda obtener la información local-
mente). Si la información a buscar está alma-
cenada en una base de datos, puedes indicar
a Lucene que indexe los campos, pero que
no los almacene. A fin de cuentas, mientras
almacene la llave primaria de cada elemento,
el documento se puede reconstruir directa-
mente desde la base de datos. Esto reduce
fuertemente los requerimientos de almace-
namiento de Lucene, y evita duplicar datos.
La sección <fields> es donde se listan los
diferentes elementos tipo <field>, es decir,
los campos de información. Cada <field>
tiene un nombre que se utiliza como ref-
erencia al agregar documentos o realizar
búsquedas, y un <type> que identifica el tipo
de datos. Los tipos de datos son declarados
utilizando elementos <fieldType>. Los tipos
de datos estándar en la configuración de
ejemplo (text, boolean, sint, slong, sfloat,
sdouble) son suficientes para la mayoría de
las aplicaciones.
El siguiente listado muestra el contenido de
los campos definidos para un ejemplo de
un catálogo de productos:
<field name=”id” type=”string” indexed=”true” stored=”true”
required=”true”/>
<field name=”sku” type=”textTight” indexed=”true”
stored=”true” omitNorms=”true”/>
<field name=”nombre” type=”text” indexed=”true” stored=”true”/>
<field name=”fabricante” type=”text” indexed=”true”
stored=”true” omitNorms=”true”/>
<field name=”caracteristicas” type=”text” indexed=”true”
stored=”true” multiValued=”true”/>
<field name=”peso” type=”sfloat” indexed=”true” stored=”true”/>
<field name=”precio” type=”sfloat” indexed=”true” stored=”true”/>
Las búsquedas enviadas a Lucene utilizan un
solo campo, el cual se especifica utilizando
el elemento <defaultSearchField>. Dado que el
objetivo en la mayoría de los casos es buscar
en base a los valores de múltiples campos,
lo que se hace es crear un campo adicional
que sirva de sombrilla para contener el val-
or de todos los campos que queremos que
sean incluidos en la búsqueda. El valor de
los campos originales se copia utilizando el
elemento <copyField>. Un esquema de con-
figuración de Solr puede contener un núme-
ro ilimitado de declaraciones <copyField>.
Lo que hacen es indicarle a Solr que copie
los datos de un campo especificado por el
atributo “source” a otro campo especificado
por el atributo “dest”.
El siguiente listado muestra un ejemplo de
cómo definiríamos un campo múltiple para el
catálogo de productos. Definimos un campo
llamado “texto” que es el que utilizaremos
para buscar, y que contendrá los valores de
nombre, fabricante y características.
www.sg.com.mx
<field name=”texto” type=”text” indexed=”true” stored=”false” multiValued=”true” />
<copyField source=”nombre” dest=”texto”/>
<copyField source=”fabricante” dest=”texto”/>
<copyField source=”caracteristicas” dest=”texto”/>

3. Agregando documentos a indexar

La forma de alimentar datos a Lucene es a través de documentos XML que contienen instruc-
ciones de indexado para agregar, borrar o actualizar documentos. El siguiente listado mues-
tra un ejemplo del XML a través del cual agregaríamos un nuevo elemento de información.
Vean que los campos de información consisten con los que definimos en schema.xml.

<add>
<doc>
<field name=”id”>3007WFP</field>
<field name=”nombre”>Dell Widescreen UltraSharp 3007WFP</field>
<field name=”fabricante”>Dell, Inc.</field>
<field name=”caracteristicas”>30” TFT active matrix LCD, 2560 x 1600, .25mm dot pitch, 700:1 contrast</field>
<field name=”peso”>401.6</field>
<field name=”precio”>5199</field>
</doc>
</add>

El directorio exampledocs contiene ejemplos de instrucciones que Solr puede recibir, así
como una utilería en Java (post.jar) para alimentar instrucciones a Lucene desde la línea
de comandos.

4. Realizando búsquedas
Las búsquedas se realizan a través de peticiones por HTTP GET en el url /solr/select del servidor
donde estés ejecutando Solr. El query de búsqueda se pasa a través del parámetro “q”. Es po-
sible agregar parámetros adicionales para controlar la información que se obtiene. Un url con un
query sencillo se vería de la siguiente forma: http://localhost:8983/solr/select?q=monitor

Solr regresa los resultados en forma de XML, así que es posible manipularlos como queramos.
Incluso podemos utilizar Solr directamente utilizando un objeto XMLHttpRequest y manipular
los resultados con Javascript.

Conclusión
En este artículo apenas echamos un pequeño vistazo a Lucene y Solr. Estas tecnologías
son muy flexibles y nos proveen una amplia gama de posibilidades. De hecho, a quienes
les interese hacer un ejercicio más sofisticado les recomendamos buscar en Internet
los tutoriales que enseñan como utilizar Solr en conjunto con el API de Digg para poder
realizar búsquedas de los contenidos de Digg usando Solr.

Ahora que conocen estas tecnologías, esperamos que las tengan en cuenta la próxima
vez que requieran incorporar funcionalidad de búsqueda en sus aplicaciones.

Referencias:
• lucene.apache.org
• lucene.apache.org/solr

www.sg.com.mx JUL-AGO 2007

 Scott Ambler
La Evolución de Ágil
¿Cómo describirías el estátus actual de Ágil?
Hace unos años, Ágil era visto como un movimiento, una revolución.
Sin embargo, creo que actualmente Ágil ya es parte de la “corriente
principal” (mainstream) de los métodos de software. Justamente en
marzo de este año realicé una encuesta sobre el grado de adopción
de ágil, y de las 781 personas que contestaron, el 69% contestó que
su organización aplica técnicas derivadas de Ágil. Esto no quiere de-
cir que todo mundo ya esté usando algo como XP como su proceso
default, pero si nos indica que la mayoría ya está usando (o conside-
rando usar) una o más técnicas de Ágil.
¿Cuáles consideras que son los principales retos de Ágil en los
próximos años?
Creo que el principal reto para Ágil al corto plazo es demostrar que es
escalable a proyectos grandes. Precisamente el trabajo que hago con
IBM consiste en ayudar a clientes a aplicar técnicas ágiles en proyectos
grandes y complejos donde se tienen muchas restricciones de regulación,
y el equipo de desarrollo es grande, distribuido geográficamente, y for-
mado por distintos proveedores. Estas organizaciones están interesadas
en adoptar Ágil, precisamente porque están interesadas en maximizar su
eficiencia. En www.ibm.com/rational/agile tenemos varios documentos
y videos al respecto.
¿Crees que Ágil evoluciona? ¿Cómo?
Sin duda, las metodologías ágiles están evolucionando. Por ejemplo,
en los últimos años yo he hecho varios ajustes a Agile Modeling; Kent
Beck liberó la segunda versión de su libro “Extreme Programming
Explained”, donde presenta cambios significativos a la versión ori-
ginal de XP; Enterprise Scrum justo acaba de salir, y básicamente es
una extensión de Scrum que toma ideas del Rational Unified Process
(RUP). También está el Open Unified Process (OpenUP), que es un mé-
todo ágil open source que está disponible en www.eclipse.org/epf.
Así que en el espacio de las metodologías, claramente hay una evolu-
ción y actualización.
Por otro lado, es interesante ver que el Manifiesto Ágil parece resistir la
prueba del tiempo. Los valores y principios en que se basa no han sufrido
cambios, y parecen no necesitarlos. Sin embargo, también está el traba-
jo del Agile Project Leadership Network (APLN), www.apln.org, el cual en
cierta forma puede ser considerado una extensión al Manifiesto Ágil.
Al parecer, la gestión de datos (Data Management) también está siendo
impactada por Ágil, ¿podrías explicarnos algo sobre esto?
Introducir agilidad al mundo de la gestión de datos es una tarea cierta-
mente complicada. Desafortunadamente, la gestión de datos se manteni-
do relativamente estática en cuanto a métodos y procesos, y muchos de
los profesionistas de esa comunidad se siguen aferrando a concepciones
erróneas sobre como funciona el desarrollo de software en realidad. Por
ejemplo, muchos DBAs creen que es difícil evolucionar o refactorizar un
esquema de base de datos existente. Esto es algo que Pramod Sadalage
y yo demostramos que se puede hacer fácilmente a través de las técnicas
documentadas en nuestro libro “Refactoring Databases”. Sin embargo,
14 JUL-AGO 2007
Scott W. Ambler dirige la práctica de Desarrollo Ágil en IBM.
Es considerado como uno de los principales “agilistas” en el
mundo, y ha creado varias metodologías entre las que destacan
Agile Modeling (AM), Agile Data (AD), Agile Unified Process
(AUP), y Enterprise Unified Process (EUP).
Scott será uno de los conferencistas magistrales en SG ’07, así
que aprovechamos la oportunidad para publicar esta pequeña
entrevista donde nos comparte su perspectiva sobre Ágil y
otros temas que tratará durante SG ’07.
los DBAs que no comprenden esto se enfocan en hacer demasiado mode-
lado muy temprano en el ciclo de vida, lo cual en el libro “Agile Database
Techniques” demuestro que es una forma de trabajo altamente ineficien-
te. El Data Warehouse Institute estima que tan solo en Estados Unidos,
los problemas de calidad de datos generan un costo de $600 mil millones
de dólares anualmente. A pesar de esto, la comunidad de profesionistas
de datos ofrece muy pocas recomendaciones prácticas sobre lo que se
puede hacer para resolver esto.
En resumen, creo que hay problemas serios en la gestión de datos, sin
embargo la mayoría de los profesionistas se aferran a los métodos que
generaron estos problemas en primer lugar. Afortunadamente, la comu-
nidad Ágil está involucrándose y desarrollando alternativas para resolver
estos problemas. Yo he escrito varios artículos al respecto que están dis-
ponibles en www.agiledata.org y que pueden ser de gran ayuda para los
profesionistas de datos.
¿Es cierto que un desarrollador de un equipo que utiliza Ágil necesita
mayor habilidad y experiencia que en el desarrollo tradicional, o simple-
mente es cuestión de una mentalidad diferente?
El aspecto fundamental es la mentalidad. Los desarrolladores ágiles bus-
can colaborar estrechamente con otros, aprender de cada uno, y desarro-
llar nuevas habilidades. También tienen un fuerte enfoque a la calidad,
típicamente utilizando una estrategia “test-first” (probar primero). El he-
cho es que ser un desarrollador ágil requiere mayor disciplina que uno
tradicional, así que tal vez no sea para todos.
Últimamente has escrito sobre “lean development governance”, ¿de
qué se trata esto?
La gobernabilidad tradicional se enfoca en estrategias de comando y con-
trol, que buscan administrar y dirigir a los equipos de proyecto de forma
explícita. Aunque ésta es una estrategia válida en algunas situaciones, en
la mayoría de los casos es semejante a arrear gatos –se aplica un gran es-
fuerzo pero se obtienen pocos resultados. En cambio, “lean governance”
se enfoca en estrategias de colaboración que buscan habilitar y motivar a
los miembros del equipo implícitamente.
Por ejemplo, la forma tradicional de hacer que un equipo siga lineamien-
tos de programación es definirlos y luego realizar inspecciones formales
para asegurar que se estén siguiendo. En cambio, lo que se haría en un
enfoque “lean”, sería escribir los lineamientos en colaboración con los
programadores, explicando la importancia de que todos los sigan, y luego
proporcionando herramientas que faciliten la adopción y seguimiento de
los lineamientos. El enfoque “lean” es semejante a guiar gatos, si tomas
un pedazo de pescado, ellos te seguirán a donde vayas.
¿Consideras que el desarrollo dirigido por modelos (MDD) alguna vez
será el común denominador de cómo desarrollar software?
Eso depende de qué entiendas por MDD. La versión Ágil de MDD ha sido
el común denominador desde hace años, ya que es muy común que los
desarrolladores ágiles usen herramientas sencillas como pizarrones y ro-
tafolios para modelar. Lo que no es tan común es el enfoque que promue-
www.sg.com.mx

ven los profesionistas de modelado, donde todo se debe hacer en una
herramienta CASE. En teoría, esta estrategia es muy buena. Sin embargo,
en la práctica muy pocas organizaciones tienen suficiente gente con las
habilidades necesarias para lograr esto. Las organizaciones que llegan a
tener buenos modeladores, con buenas herramientas, logran muy bue-
nos resultados. Sin embargo, este es un porcentaje pequeño de todas las
organizaciones de software, y dudo que eso cambie en el futuro cercano.
¿Qué opinas sobre la programación orientada a aspectos (AOP)?
Creo que AOP es una solución muy interesante que todavía está buscan-
do un problema que resolver, y no veo que eso vaya a cambiar.
www.sg.com.mx
// ENTREVISTA
¿Qué está sucediendo en cuanto al Eclipse Process Framework (EPF)?
Este es un proyecto muy interesante. El EPF composer permite que las
personas puedan definir, personalizar y publicar procesos de software, e
incluirlos en la herramienta de desarrollo Eclipse. Hay mucho material dis-
ponible, incluyendo el OpenUP y la definición de Extreme Programming
para EPF. Últimamente no he estado muy involucrado en este proyecto,
pero espero poder hacerlo pronto, para agregar más material sobre mo-
delado de datos ágil.
¿Algunas palabras para nuestros lectores?
Estoy muy entusiasmado de visitar México. Nos vemos en SG ’07.
JUL-AGO 2007 15
 Creando una Personalidad “Web Tú”
A
finales de 2006, la revista Time anun-
ciaba a la persona del año y terminaba
con la incertidumbre. Para sorpresa de
muchos, esta vez no se trataba de un pa-
cifista o líder político o moral. La publicación nos
decía: “la persona del año eres tú”, o de manera
plural: “ustedes”. Para algunos, esto parecía una
broma, sobre todo porque la portada incluía una
imitación de espejo, invitando al lector a verse en
ella. Pero no, no era una broma. Y entonces, ¿que
habíamos hecho para recibir este honor?
2006 marcó el año en que los usuarios de Internet pasaron
de ser pasivos a activos. Es decir, no sólo fueron recepto-
res de información, sino que también fueron autores de
contenido. Y no es que los usuarios no quisieran partici-
par anteriormente, sino que la Web no lo permitía, porque
originalmente no estaba pensada de esa forma. Pero des-
de su inicio, la Web ha ido evolucionando cada vez más
del modo lectura, al modo lectura-escritura desde la pers-
pectiva del usuario común y corriente. Dicho movimiento
no bastó por si solo para ser una novedad, sino que fue la
masiva participación de los cibernautas. El concepto con-
formado por lo sistemas y prácticas alrededor de estos in-
gredientes una Web en modo de lectura-escritura y gente
usándola es lo que lo que hoy llamamos Web 2.0.
Web 2.0 es considerado un concepto, y no una tecnolo-
gía. Su construcción está basada en infraestructura y len-
16 JUL-AGO 2007
Sé parte de ella
Por Oscar Cortés Santos
guajes existentes. Lo que es nuevo son las herramientas
o aplicaciones construidas con dichos lenguajes. Estas
herramientas tienen algo en mente, algo que ha empeza-
do a tener resonancia en el mundo Web 2.0: “Inteligencia
Colectiva”. Es decir, brindan un mecanismo para que los
usuarios no sólo puedan comunicarse con el creador del
sitio, sino entre todos ellos. Y muchas veces, sólo entre
ellos. Juntos crean y mejoran conceptos y procesos. Es
un principio de Web 2.0: “nadie de nosotros puede saber
todo, pero cada uno de nosotros sabe algo”. Así, si junta-
mos nuestras habilidades y conocimientos individuales,
podemos hacer algo nuevo y mejor.
Un sitio Web 2.0 puede ser reconocido porque permite
la interacción con su audiencia, y deja huella de dicha in-
teracción en forma de nuevo contenido. Un sitio que no
permite tal colaboración no está usando el concepto Web
2.0. La comunicación debe circular en ambos sentidos y
quedar asentada para que la vean, juzguen y actualicen
otros usuarios. Pero reformulemos la pregunta original: ¿a
quiénes se está reconociendo como usuarios de Web 2.0?
Bueno, aunque cualquiera puede beneficiarse del conoci-
miento disponible, no todos los usuarios han participado
de la misma manera. Por ejemplo: un blog puede ser visi-
tado y habitualmente leído por muchas personas, pero no
todas participan con sus comentarios. Este tipo de usua-
rios contribuyen al tráfico, y muchas veces distribuyendo
las historias que leen enviándolas por correo electrónico.
Pero su participación es más bien de espectadores.
www.sg.com.mx
www.sg.com.mx JUL-AGO 2007 17
 Por otro lado, existen usuarios con una persona-
lidad muy definida: aquellos que son prolíficos
creando nuevo contenido. Estoy hablando de
los que tienen sus propios blogs, contribuyen
en Wikis, suben podcasts, videos o fotografías
a la red; tienen su propia página en MySpace o
Facebook; su perfil profesional en LinkedIn; y
participan activamente en foros, redes y grupos
de interés. Esta personalidad es lo que yo llamo
una personalidad “Web Tú”. Sí lo sé, aquí he ju-
gado un poco con la etiqueta, abusando de su
coincidencia con la pronunciación en inglés de
Web 2.0 (web two). Pero creo que al final, este
tipo de usuario deja un rastro digital y crea una
personalidad Web 2.0.
Crear este tipo de personalidad puede ayudar-
nos a aprender más y volvernos más produc-
tivos, ya que nos motiva a estar en contacto
constante con los temas que nos interesan, y
aprender de lo que otros están creando. Ade-
más podemos tomar ventaja del escenario para
darnos a conocer globalmente. El principio bási-
co es una cultura de participación, de compartir
nuestro conocimiento o experiencia. Las mane-
ras de convertirse en un usuario Web 2.0 son
variadas. Aquí las más comunes:
Compartiendo opinión. Qué mejor manera de
hacerlo que creando un blog. Hay varios ser-
vicios que te permiten crear uno propio, tales
como Blogger o WordPress. Lo más fácil de un
blog es activarlo, sin embargo muchos blogs
han decaído en ser sólo repetidores de noti-
cias. Aunque un blog puede usarse para temas
casuales, también es una oportunidad para
desarrollarse como una autoridad. Mi recomen-
dación es siempre ofrecer un análisis u opinión
acerca de lo que se esté hablando. Hay que
recordar que se trata de participar en la comu-
nidad agregando valor al contenido y de promo-
ver una conversación. Del mismo modo se debe
estar abierto para recibir y aceptar comentarios
tanto positivos, como negativos. Y sobre todo,
no lo abandonen si están interesados en la re-
putación de dicho blog.
Compartiendo creatividad. Con cada vez más
dispositivos portátiles que permiten tomar
imágenes digitales y video en cualquier rin-
cón, es más probable que podamos captar
Oscar Cortés Santos. Maestría en Ciencias en TI, McCallum Graduate School of Business en Bentley College, Boston, USA. Oscar cuenta con más de diez años de experien-
cia desarrollando aplicaciones para el mundo empresarial, tanto en Cliente/Servidor como Web, y es un entusiasta de tecnologías Web 2.0 y su convergencia con los negocios.
Trabaja como Software Engineer para Brightcove  en Boston, desarrollando aplicaciones RIA con Flex.
18 JUL-AGO 2007
esos momentos únicos que expresan parte de
nuestra creatividad, y compartirlos a través de
sitios como YouTube o Brightcove para video,
y Flickr o Photobucket para imágenes. En este
campo, ya empezamos a ver herramientas que
nos permiten mezclar videos, música e imáge-
nes directamente en los sitios. Dándonos la
oportunidad de crear no sólo nuevo contenido
en forma de texto, sino también como multi-
media. A su vez, es ya muy común el uso de
tags para clasificar el contenido que se suba a
estos sitios. Permitiendo así que el contenido
pertenezca a diferentes categorías al mismo
tiempo, agilizando futuras búsquedas.
Conectándose con otros. Tal vez el concep-
to de redes sociales es el más visible en el
mundo Web 2.0. El punto de partida es tener
intereses similares a los de otros y unirse a
comunidades con el mismo interés. Sitios
como MySpace, Facebook o LinkedIn reco-
lectan datos para relacionar individuos o
comunidades enteras. Esta gente se conecta
basada en sus intereses o pasatiempos, ubi-
cación, profesión o afiliación escolar.
Compartiendo experiencia. Al mismo tiempo
que se puede aprender del contenido creado
por otros usuarios, se puede compartir el co-
nocimiento que nosotros tenemos de alguna
tecnología o cualquier otro tema. Los medios
más conocidos son las Wikis, la más popular:
Wikipedia. Regularmente los proyectos de
software libre utilizan Wikis para facilitar la
colaboración, ya que en la mayoría de los ca-
sos los diferentes desarrolladores están dis-
tribuidos en todo el mundo. Una Wiki permite
a un grupo de personas actualizar la misma
página Web manteniendo una historia de ac-
tualizaciones. Otro recurso son los foros espe-
cializados, que brindan una gran oportunidad
para demostrar conocimiento respondiendo a
preguntas y dando ejemplos.
Mantenerse informado de nuevo contenido.
La mayoría de los sitios modernos difunden su
contenido hacia otros sitios o lectores usando
RSS (Really Simple Syndication). Para recolectar
todo este nuevo contenido sin tener que visitar
sitio por sitio, se puede usar un agregador de
noticias que consuma dichos feeds de RSS.
Web 2.0 en el mundo empresarial
El concepto de Web 2.0 se puede aprovechar
por las empresas en al menos dos maneras que
ayudan a generar ventaja competitiva:
> Para entender las comunidades donde sus
productos y servicios son introducidos.
> Para mejorar la administración de conocimien-
to e incrementar productividad.
El principio de Inteligencia Colectiva se vuelve
entonces relevante para las empresas. Al ofre-
cer una comunicación con los clientes para
saber qué piensan de sus productos, una com-
pañía puede seguir mejorando sus productos.
Tomemos por ejemplo: Amazon, que vende
infinidad de productos de terceros. Amazon
permite hacer críticas de los productos y éstas
quedan disponibles para futuros compradores.
Las empresas pueden subscribirse a las men-
cionadas críticas usando RSS y así enterarse de
cómo está siendo recibido su producto.
Herramientas Web 2.0 tales como Blogs y Wikis
en combinación con redes sociales, se pueden
usar internamente para identificar expertos
dentro de la empresa. Normalmente serán los
más activos participantes dentro del ecosiste-
ma. Además pueden servir para tener una co-
municación más clara y promover una cultura
de participación.
Existen otros componentes Web 2.0 utilizados
por las empresas: mashups, que tienen que
ver con colaboración con socios de negocios
externos y con interoperabilidad entre aplica-
ciones. Los mashups explotan los datos que se
proveen a través de RSS, WebServices y APIs
ofrecidas por entidades externas, y los mez-
clan en una sola interfaz, que regularmente es
sofisticada. Por ejemplo: se puede leer la lista
de casas en venta de alguna fuente y presentar
su localización usando Google Maps. Los mas-
hups típicamente son presentados usando
interfaces visuales ricas, denominadas RIAs
(Rich Internet Applications). Las RIAs permiten
crear aplicaciones con elementos visuales so-
fisticados e interactivos que brindan al usuario
una mejor experiencia de lo que se puede con-
seguir con HTML por sí solo. Actualmente la
tecnología que más se utiliza para hacer RIAs
es Ajax, seguido de Adobe Flex.
www.sg.com.mx
 Conclusión

Nuestra presencia en Web 2.0

puede ser tan extensa o compacta como se
quiera, y ser usada de manera personal o a
nivel empresarial. Las oportunidades en el
ecosistema Web 2.0 son inmensas, no sólo
de entretenimiento o aprendizaje, sino tam-
bién de negocios. El contenido existente en
Web 2.0 se puede utilizar de incontables
maneras, sólo limitadas a la imaginación.
Sin embargo, hay que entender a las comu-
nidades existentes en Web 2.0 para poder
tomar ventaja de ello. La mejor manera creo
yo, es perteneciendo, es desarrollando una
personalidad Web Tú. <<

www.sg.com.mx JUL-AGO 2007 19

 Mashups Qué Son y Qué No Son
Por Aldo Hernández

M
ashup es una palabra que ¿Qué no es un mashup? de las empresas crece exponencialmente. Se
proviene de un término mu- Antes de continuar, debemos aclarar dos necesita usar esa información para manipularla
sical en inglés, que significa concepciones erróneas que tienden a existir de manera rápida y sencilla.
la creación de una nueva relacionadas con los mashups. La primera es > La información se encuentra distribuida en di-
canción a partir de la mezcla o pedazos que un mashup no es un portal. Sin embar- ferentes fuentes de información.
de otras canciones. Desde este concepto se go, un portal puede complementarse por un > Integración dinámica temporal a fuentes de
basa el mashup de software. La Wikipe- mashup y viceversa. información.
dia lo define como “una aplicación o sitio > Integración realizada por el usuario y no nece-
web que combina contenido de una o más La segunda aclaración es que un mashup sariamente por el área de sistemas.
fuentes dentro de una nueva experiencia tampoco es una aplicación compuesta (com- > Acceso rápido a la información significa mayor
de usuario o manejo de información”. posite application). El término composite competitividad y productividad.
application se utiliza para referirse a apli-
Los mashups son un producto de la Web 2.0 caciones que en lugar de ser desarrolladas Clasificación de mashups
donde el usuario es el centro de todo. Va de la desde cero, son “ensambladas” a partir de Un mashup puede dividirse en dos tipos:
mano con conceptos como colaboración y dis- servicios disponibles en una arquitectura > Orientado hacia el navegador (browser).
tribución de la información. SOA. Este concepto puede parecer muy simi- Está más enfocado en la mezcla o composi-
lar al de un mashup, sin embargo hay una di- ción de información con imágenes del lado
Las características que podemos en- ferencia crucial: las composite applications del navegador, principalmente usando Java-
contrar actualmente en el Web 2.0 parten de un enfoque centrado en TI, mien- Script como lenguaje de programación para
son: tras que los mashups parten de un enfoque lograrlo. Un ejemplo clásico de este tipo de
> Hecho por el usuario para él mismo. centrado en el usuario. Bajo el modelo de mashups es aquél en que se usa el servicio
> Capacidad dinámica de integración de infor- las composite applications, el usuario final de Google Maps, con otro servicio, por ejem-
mación con otras fuentes. sigue dependiendo del departamento de TI plo: de precios de casas que muestre en una
> Integración concurrente limitada. para crear una aplicación (aunque ésta so- sola pantalla el precio y la ubicación donde se
> Utilización de servicios Web públicos. lamente se vaya a ensamblar, no a crear). En encuentra una casa en venta.
> Orientado al consumidor. cambio, con los mashups el objetivo es que > Orientado hacia el servidor (mashup empresa-
sean los usuarios quienes puedan crear (o rial). En éste, la integración y manipulación de la
Sin embargo, conforme el Web 2.0 comienza ensamblar) sus aplicaciones. información suceden en ambos lados: servidor
a ser adoptado en las empresas, empezamos y navegador. Su uso principal es interactuar con
a ver su evolución, que llevará a las siguientes ¿Por qué mashups? información de diferentes sistemas para gene-
características en el futuro: Las grandes tendencias de desarrollo de soft- rar vistas necesarias para la toma de decisiones.
> Hecho por el usuario para él y compartirlo con ware son la reutilización e integración. La mayor Este tipo de mashup es capaz de interactuar con
más usuarios. parte de los presupuestos de TI para los próxi- data centers para generar valor .
> Capacidad dinámica de compartir e integrar mos años estarán asignados al mantenimiento
de la misma manera con otras fuentes. y explotación de los sistemas existentes. Funcionalidades del
> Utilización tanto de servicios Web públicos, mashup empresarial
así como servicios internos. La funcionalidad de los mashups se justifica en Estas son algunas de las acciones más comu-
> Orientado hacia la empresa, sus clientes y base a los siguientes puntos: nes que se pueden realizar con un mashup
aliados de negocio. > La información disponible en Web y al interior empresarial:

Aldo Hernández Murguía es parte del equipo de JackBe en México. Aldo es Ingeniero en Cibernética y Sistemas Computacionales por la Universidad La Salle, México. Cuen-
ta con más de nueve años de experiencia en TI, y está certificado como Java Developer y Architect. JackBe ofrece soluciones para aplicaciones de negocios basadas en SOA y
servicios Web que resultan en aplicaciones interactivas basadas en browser que buscan optimizar las actividades diarias de las organizaciones.

20 JUL-AGO 2007 www.sg.com.mx

> Filtrar información: en ocasiones un ser-
vicio regresa información necesaria para PRESTO DASH
Integración dirigida
por los usuarios
construir una vista y por lo mismo es re- (AMBIENTE DE EJECUCIÓN)

querido aplicar un filtro para trabajar con la Enterprise Ajax

Acceso a servicios,
colaboración & mashups
información necesaria. Framework

> Conjuntar y unir diversos tipos de servicios de

información: con esto nos referimos a la virtua- RDBMS RSS
Envío de datos
lización de los servicios para abstraer la com- dirigido por eventos REST

plejidad de consultar o ejecutar operaciones en

diversas fuentes de información, como pueden POJO

ser base de datos, WSDLs, RSS, etcétera. Comunicación

Definición de fuentes de datos
> Analizar información resultante de servicios: GEO

tener la capacidad para aplicar funciones esta- Enterprise Ajax

Framework WSDL

dísticas como matemáticas, a los resultados de PRESTO EDGE

los servicios invocados. (Vgr. Tomar la informa-
ción de un servicio que nos da precios de accio-
nes y al resultado de la ejecución de ese servicio
poder aplicar una función matemática que nos
da el precio máximo de esa acción durante un
tiempo determinado).
> Transformar información: soportar tanto es-
tructuras diferentes de información así como
formatos diversos.
> Soporte gráfico de información: presentar al
usuario final la información a través de tablas,
calendarios, gráficos, etcétera.
> Orquestación de servicios: un mashup puede
crearse a partir de la ejecución secuencial o en
paralelo de varios servicios para la generación
de la vista final. Un ejemplo: generar un mashup
de la situación financiera de una persona. Por lo
mismo necesitamos conectarnos al banco con
un servicio “Y” que nos da la información bási-
ca de ésta, como sus cuentas y de qué tipo son.
Con dicha información, se hace una consulta
para conocer cuál es su calificación en el buró
de crédito y de ahí generar una vista final.
Arquitectura de un
mashup empresarial
Ya definidas las cualidades y funcionalidades
de un mashup empresarial, veamos la arqui-
tectura de sus componentes, para así, enten-
der cómo se integran la funcionalidad y los ser-
vicios antes mencionados. La figura 1 muestra
el ejemplo de una arquitectura para mashups.
En este caso, utilizamos como referencia la
plataforma Presto de JackBe. ( Ver Figura 1 )
En este diagrama se puede ver que el mashup
empresarial debe ser capaz de conectarse a
cualquier fuente de información (base de datos,
servicios Web, objetos Java o .Net) a través del
concepto “virtualización de servicios”. De esta
forma, las diferentes fuentes de información
hacen la base de una estructura fuerte para po-
der integrar, orquestar, mezclar, transformar y
visualizar nuevos servicios.
Caso de uso de un mashup
Usemos ahora un ejemplo específico para
RIAs construidas
por desarrolladores
PRESTO STUDIO
(AMBIENTE DE DESARROLLO)
entender cómo es que podríamos resolver un
problema de negocio a través de un mashup.
Imaginemos que cierto banco requiere que a
través de su website de eBanking personal se
pueda realizar la venta cruzada de diferentes
productos. Un caso particular es el de un pro-
ducto financiero hipotecario, donde para poder
otorgarlo se requiere como entrada el historial
crediticio y hábitos de consumo del cliente
prospecto. Estos servicios provienen de dife-
rentes fuentes y son de varios tipos: el historial
crediticio es de tipo WebService y los hábitos de
consumo nos llegan como RSS.
Para resolverlo necesitamos virtualizar estos ti-
pos de servicios, es decir, generar una manera
estándar de invocarlos sin importar de qué tipo
sean. Esta virtualización puede ser representa-
da a través de un XML como el siguiente:
<Servicios>
<Servicio nombre=”BuroDeCredito” tipo=”WebService”>
<operación nombre=”obtenerHistorialCrediticio”>
<parámetro tipo=”string”
nombre=”numeroDeTarjetaCredito” />
</operación>
</Servicio>
<Servicio nombre=”HabitosConsumo” tipo=”RSS”>
<operación nombre=”consumo”>
<parámetro tipo=”string”
nombre=”numeroDeTarjetaCredito” />
</operación>
</Servicio>
</Servicios>
Así se esconde la complejidad que involucra
tener varias fuentes de información; y se tiene
una manera estándar de ejecutar y trabajar con
sus respuestas.
Una vez virtualizados los servicios, se requie-
re generar un lenguaje que pueda definirse a
través de un mark up language capaz de des-
.NET
(SERVIDOR DE MASHUPS) WSRP
Figura 1. Arquitectura para mashups Presto
cribir la manera en que lo servicios pueden in-
teractuar, filtrarse, orquestarse, integrarse; es
decir, las operaciones básicas de un mashup
empresarial. Al tenerlo definido, a partir de este
lenguaje se podrá reutilizar o compartir entre
varias aplicaciones dando como resultado un
servicio de tipo mashup. Este nuevo servicio
nos arrojará la respuesta de si el usuario puede
obtener el crédito hipotecario y así ofrecerlo al
cliente en tiempo real.
Bajo este modelo, a través de herramientas
visuales para crear los mashups, ésta tarea
de definición puede ya estar en manos del
área de marketing, logrando así:
• Menor dependencia del área de sistemas
para generar este tipo de promociones.
• Mejores tiempos de reacción al mercado.
• Reducción de costos de creación y
mantenimiento de campañas.
• Estandarización para crear nuevos servicios.
Conclusión
Los mashups son parte funda-
mental de la denominada Web 2.0,
cuyo mayor beneficio será obtenido
por las organizaciones a través del uso
de lo que hemos explicado aquí como
mashups empresariales. Este nuevo
tipo de aplicaciones están provocando
un cambio que traerá a su vez una nue-
va generación de aplicaciones empre-
sariales centradas en los usuarios. <<
Referencias
• blogs.jackbe.com

www.sg.com.mx JUL-AGO 2007 21

 Prácticas Arquitectónicas
en Aplicaciones Web 2.0
Consideraciones que no puedes olvidar
Por Alexis Castañares

L
a forma de publicación y con- Y entonces, ¿qué consideraciones debo tener ofrecen las tecnologías más recientes para
sumo de información en la en cuenta al desarrollar aplicaciones de este la creación de este tipo de aplicaciones.
web de hoy en día ha sufrido tipo? Precisamente ese es el objetivo de este
un cambio fundamental. El artículo, explicar desde el punto de vista ar- En el pasado, muchas organizaciones han de-
advenimiento de un paradigma mu- quitectónico las principales consideraciones jado a un lado la experiencia de usuario en el
cho más proactivo en el uso de la web que debemos tener para el desarrollo de las desarrollo de sus activos en la web en aras de
por parte de los usuarios –que publi- aplicaciones de esta nueva generación. Co- buscar la ubicuidad de las aplicaciones, enten-
can su propio contenido en forma de mencemos entonces. diendo ésta como la posibilidad de contar con
blogs, wikis, videos, fotografías– ha ellas en múltiples dispositivos y en la mayor
provocado que anualmente se esté ge- Enfoque en la Experiencia de Usuario audiencia posible. Hoy en día los proveedores
nerando un volumen de información Los ejemplos más exitosos que podemos en- tecnológicos y las comunidades de desarrolla-
(estimado en 1.5 exabytes tan sólo contrar en el desarrollo de sitios y aplicaciones dores están dando prioridad a estas funciona-
para este año) que es mayor al que se de la web 2.0 han sido aquellos que implemen- lidades, pues la web 2.0 nos ha demostrado
ha producido en los últimos 5000 años taron una experiencia integrada y altamente que, con la nueva realidad de accesos de ban-
de la historia humana. funcional de uso. La alta cohesión en la inter- da ancha y usuarios altamente demandantes,
faz de usuario y el uso de tecnologías como es precisamente la experiencia de usuario el
Este nuevo paradigma ha dado pie a una inte- Ajax, que permiten proveer interactividad en el componente principal para que éstas aplica-
racción mucho más profunda entre los usua- browser similar a la ofrecida por las aplicacio- ciones tengan la capacidad de generar los al-
rios de la Internet, que han dejado atrás el rol nes de escritorio, han sido factores clave para tos volúmenes de lealtad, crecimiento y opor-
exclusivo de observadores y han comenzado fomentar la adopción masiva de aplicaciones tunidades de negocio que las organizaciones
a colaborar, discutir, formar comunidades e como YouTube o MySpace, pues permiten re- están buscando.
incluso amasar sitios ya existentes, en nue- ducir la curva de aprendizaje del usuario y por
vas aplicaciones o experiencias personaliza- lo tanto incrementar la productividad y lealtad Modelo de Programación 2.0
das usando mashups. El contar con un medio del mismo hacia la aplicación. Una de las premisas del concepto web 2.0
como la Internet para intercambiar información acuñado por Tim O’Reilly en 2005 es la ne-
correlacionada y catalogada a escala humana Actualmente, los desarrolladores tienen cesidad de contar con modelos ligeros de
supera la capacidad de cualquier individuo e al alcance diversas tecnologías para crear programación que permitan que las aplica-
incluso cualquier organización para generar aplicaciones enriquecidas (RIAs). Silver- ciones sean interconectadas para la creación
conocimiento, y se convierte en un proceso light, por ejemplo, es un plugin multipla- de funcionalidad personalizada. Las apli-
de inteligencia colectiva o “sabiduría de las taforma para el desarrollo de RIAs que caciones web 2.0 son inherentemente en-
masas”, como lo denomina Michael Platt en su utiliza lenguajes avanzados como JavaS- samblables y para ello es necesario que su
artículo “Web 2.0 in the Enterprise”. cript, C# ó VB e incorpora las funcionali- arquitectura considere la utilización de es-
dades de acceso a datos y comunicación tándares tanto en el manejo de datos como
Organizaciones de todos tamaños y en todas del framework de .NET con un sistema de en la comunicación, así como un esquema
las industrias han comenzado a investigar el entrega de video, habilitando el desarrollo que separe la funcionalidad en módulos que
poder de éstas tendencias para la generación de aplicaciones dinámicas multimedia. Los puedan ser reutilizables. Las aplicaciones
de nuevas oportunidades de crecimiento, sa- diferentes frameworks para el desarrollo que sigan estos modelos en su desarrollo
tisfacción en sus clientes, economías de escala de aplicaciones AJAX como Google Web estarán mejor preparadas para exponer pun-
basadas en la web, mercadotecnia viral, comu- Toolkit, ASP.NET Ajax, Prototype, DWR o tos de conexión que puedan ser usados para
nidades en línea y sistemas de distribución. Dojo son otro ejemplo de las opciones que la creación de mashups.

Alexis Castañares es Asesor Especialista en Arquitectura de Infraestructura en Microsoft México, donde está a cargo de la estrategia web.  Alexis cuenta con 15 años de ex-
periencia en Tecnologías de Información, y ha dirigido un gran número de proyectos Internet de gran escala para diversas organizaciones como el Grupo MVS Comunicaciones
y la Organización Mundial de Comercio. Es egresado de Ingeniería en Cibernética por la Universidad La Salle.

22 JUL-AGO 2007 www.sg.com.mx

Como ya se menciona en otros artículos de esta
edición, mashup es el término utilizado para
denominar la creación de nuevas aplicaciones
en la capa de usuario reutilizando aplicaciones
web ya existentes. Recientemente han surgido
iniciativas de proveedores tecnológicos para
crear editores de este tipo de aplicaciones
como Yahoo! Pipes ó Microsoft Popfly.
A pesar de que las herramientas y tecnologías
de exposición de información disponibles a la
fecha tienen aún un largo camino por recorrer
para ofrecer escenarios ideales de composi-
ción de aplicaciones, los mashups prometen
eventualmente ser capaces de reducir los lar-
gos tiempos de desarrollo de aplicaciones y
los costosos procesos organizacionales para
su adopción, habilitando a los usuarios finales
para crear sus propias aplicaciones con base
en sus muy particulares necesidades.
La programación del Web 2.0 se basa en el
principio arquitectónico de Transferencia Re-
presentativa de Estado ó REST por sus siglas
en inglés (Representational State Transfer). La
programación “RESTful”, como es comúnmen-
te denominada, se refiere a la separación de
tareas en recursos y a la utilización de los mis-
mos por medio de mensajes transmitidos sin al-
macenamiento de estado utilizando protocolos
de comunicación estándares y generalmente
transparentes a los firewalls, como HTTP.
Finalmente, la aplicación debe concebirse des-
de sus inicios bajo el paradigma de “lectura-
escritura” para promover la interactividad con
sus usuarios, así como de “colaboración” para
fomentar esta interactividad entre los propios
usuarios, aprovechando así la inteligencia co-
lectiva y el potencial de generación de comuni-
dad que describíamos al inicio.
Servicio (SaaS). La distribución de software
como servicio puede habilitar a las organi-
zaciones a generar economías de escala
en sus aplicaciones, particularmente si se
utiliza el patrón arquitectónico de Múltiples
Inquilinos (Multi-Tenancy) en una instancia
del aplicativo.
El beneficio que puede obtener la organi-
zación al utilizar este modelo proviene del
mejor aprovechamiento que puede hacer
de sus recursos de infraestructura y del
esfuerzo de desarrollo si en el proceso de
ingeniería de software se consideran estra-
tegias que permitan crear aplicaciones que
atiendan múltiples clientes en instancias de
ejecución compartidas. Empresas como sa-
lesforce.com han sido exitosas en la utiliza-
ción de este paradigma amasando grandes
volúmenes de usuarios en sus aplicaciones y
habilitando el “Long-Tail”, nombre coloquial
acuñado en 2004 por Chris Anderson en un
artículo de la revista Wired, quien argumen-
ta que los productos con bajos volúmenes
de venta pueden en conjunto igualar o su-
perar las ventas de los productos estrella de
una organización si se logra tener un canal
de distribución lo suficientemente grande.
La figura 1 ilustra en rojo el potencial de ga-
nancias que una organización podría tener
por la venta de un producto a un mercado
naturalmente reducido por el alto costo. En
contraposición el color naranja representa
las ganancias incrementales que podría ob-
tener la organización vendiendo el mismo
producto a un precio menor pero a un mer-
cado potencial mucho mayor. Las ganan-
cias netas por la venta del producto serían
mayores si la “Cola” de la gráfica logra ser
lo suficientemente larga.
podía brindar en un mercado tradicional.
La Internet ha venido a habilitar este tipo
de escenarios puesto que una aplicación
con una arquitectura adecuada puede dis-
tribuirse vía la web a un mercado poten-
cial de millones de usuarios, superando
evidentemente casi cualquier modelo de
ingresos por venta de productos de alto
costo a mercados reducidos.
Recientemente, el concepto de SaaS está
evolucionando e incorporando estrategias
de distribución como la de S+S (Software +
Servicios) en donde se combina la entrega
de servicios por medio de la nube, con la
riqueza en experiencia de usuario que pue-
den proveer las aplicaciones de escritorio
conectadas a estos servicios. De igual for-
ma, las empresas de desarrollo han comen-
zado a explorar el uso de Plataformas de
Distribución de Software o SDPs (Software
Delivery Platforms) para encapsular en un
sistema subyacente servicios comúnmen-
te requeridos por los aplicativos –como
subsistemas de facturación, análisis esta-
dístico, almacenamiento de datos– permi-
tiendo así a las organizaciones focalizarse
en la estructuración de las funcionalidades
más específicas del dominio de la aplica-
ción a desarrollar. Los trabajos realizados
por Gianpaolo Carraro sobre estos temas
pueden ser de gran utilidad para nuestro
lector en el entendimiento y utilización de
estas estrategias.

Estrategia para la Distribución En el pasado la generación de economías

de Aplicativos de escala alrededor de este concepto
El modelo aplicativo de la web 2.0 ha potencia- estaba limitada por la capacidad de dis-
lizado los logros del modelo de Software como tribución y atención que la organización Figura 1. The Long Tail

Conclusión

Haciendo un análisis somero de la arquitectura de ac-
tivos altamente exitosos en la web 2.0, visualizamos la presencia
recurrente de modelos, estrategias, patrones y paradigmas arqui-
tectónicos orientados a sacar provecho de los nuevos horizontes
que la “sabiduría de las masas” ha creado. La utilización de los
modelos planteados por el advenimiento de la web 2.0 encierra
un alto potencial de negocio así como de soporte a poderosos me-
dios de acercamiento con los clientes internos o externos de las
organizaciones por medio de sus activos en Internet.
Las consideraciones arquitectónicas aquí presentadas pueden servir
como premisas iniciales en la planeación y diseño de una solución
web 2.0. Con la vista puesta en el futuro inmediato, la organización
deberá incluir en su estrategia muchas otras, como la multiplicidad de
dispositivos de entrega ó los ciclos continuos de mejora en los aplica-
tivos. En incrementos exponenciales estos modelos van evolucionan-
do y siendo reemplazados por nuevas ideas que habilitan el potencial
y desencadenan el crecimiento de la máquina más compleja creada
por el hombre: El World Wide Web. <<

www.sg.com.mx JUL-AGO 2007 23

 Frameworks Habilitadores de AJAX
¿Cuál Elegir?
D
esde el año 2005 cuando Jesse James Garrett acuñó
el acrónimo AJAX (Asynchronous Javascript and
XML), las tecnologías relacionadas se han esparcido
de una manera francamente vertiginosa.
Ajax es una técnica de programación donde se explotan tecno-
logías ya existentes como Javascript y XML, para mejorar consi-
derablemente la interacción entre un usuario y una página Web.
Esto se logra mediante la transmisión y recepción de información
(postback) desde el cliente al servidor en segundo plano, evitando
los molestos pantallazos que implica el envío de datos, la admisión
de los mismos y la regeneración de la página Web por parte del
browser. El uso adecuado de este modelo trae como consecuencia
un aumento considerable de la usabilidad, velocidad y tiempo de
respuesta de un sitio Web.
Antecedentes
Aunque parezca increíble, la capacidad real de utilizar estas técnicas
ha estado entre nosotros desde 1999, cuando Microsoft lanzó la ver-
sión 5 de Internet Explorer, y con él un objeto llamado XMLHttpRe-
quest ideado originalmente para optimizar la interfaz de usuario del
24 JUL-AGO 2007
Por Miguel Ángel Morán
acceso Web de Outlook (OWA) . Este objeto se encarga de establecer
un canal de comunicación independiente del browser para enviar y re-
cibir datos, y así evitar que el usuario se percate de lo que está suce-
diendo tras bambalinas. Ya que la información está siendo procesada
en background.
Dado que este objeto es programable en Javascript, es posible escribir
scripts que interactúen con el DOM de la página y de esta manera lograr
páginas muy interactivas. Debido a su popularidad y su uso masivo, el
World Wide Web Consortium (W3C) ha definido ya una especificación
estándar para dicho objeto, y por lo tanto, ya lo implementan distintos
navegadores como Firefox, Safari y Opera.
Implementación básica
Uno de los principales atractivos de Ajax, es que al usar tecnologías que
ya se encuentran implementadas en los browsers actuales, no es nece-
sario instalar nada para comenzar a usarlo.
En el siguiente ejemplo definimos una implementación básica en la cual
buscamos que al momento de seleccionar un destino en el Panel 1, se
actualice la información en el Panel 2, sin redibujar de nuevo la página.
www.sg.com.mx
Para lograr nuestro cometido, debemos de escribir un script como el
siguiente:
<script language=”javascript”>
var objxmlHttp=null;
// Devuelve una instancia correcta del objeto XMLHTTPRequest de acuerdo al browser usado.
function ObtenerObjetoxmlHttp()
{ Frameworks de cliente
try // Instancia para navegadores no Microsoft
{objxmlHttp=new XMLHttpRequest();}
catch (e) // Instancias para navegadores Microsoft
{ try
{ objxmlHttp=new ActiveXObject(“Msxml2.XMLHTTP”);}
catch (e)
{ objxmlHttp=new ActiveXObject(“Microsoft.XMLHTTP”);}
} usando Prototype.
return objxmlHttp;
} <script language=”javascript” src=”prototype.js”></script>
// Envía la forma y los datos seleccionados en el control <select>
function EnviarForma() {
objxmlHttp=ObtenerObjetoxmlHttp();
objxmlHttp.open(“POST”,”Servidor.aspx”, true, “”, “”);
objxmlHttp.setRequestHeader(“Content-type”, “application/x-www-form-urlencoded;
charset=windows-1255”);
objxmlHttp.onreadystatechange=MostrarRespuesta;
objxmlHttp.send(“selLugares=”+document.getElementById(“selLugares”).selectedIndex);
} });
// Procesa la respuesta del servidor y la muestra en el <div> del Panel 2
function MostrarRespuesta() {
if (objxmlHttp.readyState==4)
document.getElementById(“divDescripcion”).innerHTML=objxmlHttp.responseText;
}
</script>
Listado 1. Implementación de Ajax sin framework
Implementar un código como el anterior no representa mayores proble-
mas cuando se trata de un ejemplo sencillo como el descrito. Sin embar-
go, conforme la interfaz de usuario tenga mayor complejidad, el código
para implementarla se incrementará exponencialmente, haciéndolo di-
fícil de crear y mantener.
Ante este panorama, muchos fabricantes y grupos han tratado de facili-
tar la vida a los desarrolladores mediante la creación de marcos de tra-
bajo que hacen más rápido y sencillo el uso de Ajax. Entre las principales
ventajas de utilizar frameworks están:
> Simplificación y reducción de la cantidad de código requerida.
> Estandarización del modelo de codificación.
> Integración con el modelo de programación de la tecnología del lado
de servidor.
> Aumento de la productividad en el desarrollo.
Podemos dividir los frameworks de Ajax en las siguientes dos categorías:
> Frameworks de cliente: básicamente scripts de Javascript pre-
escritos y listos para usarse con sólo insertarlos directamente en
nuestra página Web.
> Frameworks de servidor: son librerías implementadas del lado del ser-
vidor, que ayudan a una integración browser/server. Estos framewor-
ks suelen generar dinámicamente el Javascript requerido para Ajax de
www.sg.com.mx
acuerdo al modelo de programación, por ejemplo: ASP.NET o Java Ser-
vlets / JSP’s.
A continuación presento algunos de los frameworks más usados actual-
mente en la red.
Prototype: es un framework muy sencillo de entender, y bastante
popular. Para usarlo sólo es necesario incluir el archivo prototy-
pe.js y con esto estamos listos para poder utilizar los objetos que
incluye la librería. El listado dos muestra el código que necesita-
ríamos para lograr el mismo objetivo que en el listado uno, pero
<script language=”javascript”>
function EnviarForma(){
new Ajax.Request(‘Servidor.aspx’, {
method: ‘post’,
parameters: {selLugares:document.getElementById(“selLugares”).selectedIndex} ,
onSuccess:
function(strRespuesta){
document.getElementById(“divDescripcion”).innerHTML=strRespuesta.responseText;
}
}
</script>
Listado 2. Implementación con Prototype
Es evidente que el código anterior es mucho más limpio y sencillo que
la implementación original. Sólo hacemos uso del método Request del
objeto Ajax incluido en Prototype, y le pasamos como parámetros los
detalles de nuestra petición. Podemos ver que Prototype ha manejado
automáticamente la detección del browser, la suscripción del objeto y
la interpretación de la respuesta.
Cabe señalar que Prototype no sólo incluye funcionalidad para Ajax,
sino que también incluye funciones para manejo y optimización de arre-
glos, cadenas, objetos etc. Incluye métodos taquigráficos para hacer
el código más legible, extiende el DOM, soporta JSON, y muchas otras
características. Prototype tiene un compañero ideal llamado script.acu-
lo.us que es otro script que extiende aun más la interactividad de las
páginas mediante funciones de drag and drop, animaciones etc. y toma
como base Prototype
The Dojo Toolkit: se basa en los mismos principios que Prototype,
incluir un script del lado del cliente (en este caso dojo.js) para au-
mentar la funcionalidad de Javascript. Sin embargo, Dojo va más
allá e introduce todo un conjunto de características como gráficos
de vectores, un sistema de eventos muy completo, la capacidad de
crear widgets (componentes basados en HTML + Javascript) y por
supuesto, soporta Ajax. La desventaja de Dojo es que se ha vuel-
to sumamente complejo debido a su gran cantidad de funciones y
su escasa documentación. No obstante, empresas como Sun e IBM
están apoyando este proyecto, por lo que en un futuro cercano po-
dríamos ver un mejor soporte.
JUL-AGO 2007 25
 Frameworks de servidor
Microsoft ASP.NET AJAX: la implementación que sugiere Microsft,
obviamente gira en torno a su tecnología ASP.NET. Y nos ofrece una
solución completamente integrada al .NET Framework 2.0, expuesta
a través de controles de lado del servidor del ASP.NET. Quizá su prin-
cipal beneficio es que todo se puede hacer visualmente sin necesi-
dad de escribir una sola línea de código en Javascript; de tal forma
que si ya usas ASP.NET, sólo debes instalar las extensiones de Ajax,
arrastrar a tu página los controles adecuados y obtienes “Ajax ins-
tantáneo”; el .NET Framework se encarga de hacer “el trabajo sucio”
por ti. La idea es muy simple: diseñas y programas tu página ASP.
NET como de costumbre, y para agregar funcionalidad de Ajax reali-
zas los siguientes pasos:
> Arrastras desde el toolbox de Visual Studio un control del tipo
ScriptManager.
> Arrastras otro objeto llamado UpdatePanel y colocas dentro de él
todo lo que quieres que sea mostrado asíncronamente, como por
ejemplo: etiquetas, tablas de datos, cajas de texto, imágenes, y en
general todo lo necesario.
> Defines los eventos que dispararán la comunicación en background
y… ¡listo!
El listado tres muestra el código generado para lograr la funcionali-
dad que queremos con ASP.NET 2.0.
<asp:ScriptManager ID=”manEjemplo” runat=”server”/>
<asp:UpdatePanel ID=”upnContenedor” runat=”server”>
<ContentTemplate>
<asp:Label ID=”lblDescripcion” runat=”server”
Text=”Seleccione un destino y se le mostrara su descripcion” />
</ContentTemplate>
<Triggers>
<asp:AsyncPostBackTrigger ControlID=”drpDestinos” EventName=”SelectedIndexChanged”/>
</Triggers>
</asp:UpdatePanel>
Listado 3. Implementación con ASP.NET Ajax
Conclusión
Los frameworks de Ajax facilitan y aceleran el desarrollo de
las aplicaciones antes mencionadas. La elección del framework espe-
cífico depende de tus necesidades y restricciones:
Para quienes desean implementar Ajax a través de scripting
en el cliente, Prototype y Dojo son muy buenas opciones, que
además de la funcionalidad básica de Ajax, proveen capaci-
dades para extender las estructuras base de Javascript y del
DOM, con la ventaja agregada de su independencia de la pla-
taforma en el servidor.
Para los que desarrollamos en ASP.NET, sin lugar a dudas la
opción natural es Microsoft ASP.NET AJAX debido a su completa
integración con el modelo de controles de servidor de ASP.NET;
la ayuda del IDE donde ni siquiera es necesario implementar
una sola línea de código de Javascript, y el montón de controles
incluidos en el Control Toolkit que harán a nuestros sitios verse
espectaculares. Los programadores de Java tienen las opciones
de DWR y Google Web Toolkit, entre las más conocidas.
Miguel Ángel Morán Bolaños es Microsoft Most Valuable Professional (MVP) en C# y Microsoft Certified Trainer (MCT). Es Licenciado en Informática por la UNITEC y cuenta
con 10 años de experiencia desarrollando profesionalmente. Actualmente colabora en Intersoftware como Consultor en TI. Mantiene, junto a un grupo de colegas, la comuni-
dad DevelopersDotNet donde frecuentemente escribe y organiza eventos sobre tecnología. mmoran@developersdotnet.com
26 JUL-AGO 2007
Como podrán apreciar en este código, se declara el control ScriptMa-
nager (manEjemplo), y posteriormente el UpdatePanel que adentro
tiene una etiqueta que será actualizada en forma asíncrona con Ajax.
Al momento de visualizar la página, ASP.NET creará dinámicamente
todo el Javascript requerido.
Con ASP.NET, además de obtener la funcionalidad de Ajax a través
de Codeplex, también podemos obtener un conjunto de controles
llamados Ajax Control Toolkit, que automatizan e imprimen mucha
interactividad a nuestros sitios Web, como validadores, controles sli-
de, controles acordeón, calendarios, búsquedas, tabs etcétera.
DWR: es el acrónimo de Direct Web Remoting, y es una librería Ajax
para Java EE, que se instala en el servidor de aplicaciones (median-
te un archivo .war) y su principal ventaja es que permite a los brow-
sers utilizar métodos de Java ubicados en el servidor como si estu-
vieran realmente en el browser. Esto se logra mediante un servlet
que procesa las peticiones de los browsers y envía las respuestas
a los mismos; y código de Javascript generado dinámicamente en-
cargado de procesar las respuestas del servidor. De esta manera,
el uso de DWR se convierte en una gran alternativa para minimizar
los costos y el tiempo de implementación de Ajax para los progra-
madores en Java.
Google Web Toolkit (GWT): es un framework que proporciona el so-
porte a Ajax mediante la utilización de Java. Con GWT, el desarro-
llador escribe su página en Java (integrando las clases del GWT), y
el compilador de la herramienta se encarga de generar el HTML y el
Javascript correspondiente. El modelo de programación es muy pa-
recido a Swing, y actualmente ya existen varios IDEs que proveen
integración con GWT para facilitar el desarrollo. Entre los que están
IntelliJ IDEA, Eclipse (a través del plugin Cypal Studio), y NetBeans (a
través del plugin gwt4nb).
Con esto, he presentado tecnologías representativas (por cierto, to-
das gratuitas), que a pesar de ser muy distintas entre sí, todas ellas
facilitan y aceleran el desarrollo de aplicaciones con Ajax. Como po-
drán apreciar, gracias a estas herramientas puede ser muy sencillo
implementar Ajax en nuestros sitios Web. Los invito cordialmente a
programar sitios fantásticos sumergiéndose de lleno en Ajax.
El código fuente completo de los listados de este artículo se encuen-
tra disponible en www.developersdotnet.com <<
Referencias
• www.prototypejs.org
• dojotoolkit.org
• script.aculo.us
• ajax.asp.net
• getahead.org/dwr
• code.google.com/webtoolkit
www.sg.com.mx
 FLEX
El sabor de Adobe para RIA
Por Edgar Parada

H ablar de una tecnología como Flex con una perspectiva

de Web 2.0 forzosamente nos lleva a entender parte de
la evolución de la industria del software, darnos cuenta del
porqué del sufijo 2.0, y conocer un término que está íntima-
mente ligado con Flex, nos referimos a la expresión de RIA
(Rich Internet Application).

www.sg.com.mx JUL-AGO 2007 27


Evolución de las Aplicaciones
Como sabemos, las tecnologías y arquitectu-
ras de las aplicaciones de software están en
continua evolución para satisfacer mejor las
necesidades de tanto los usuarios como los
departamentos de TI. Es así que pasamos por
los “mainframes”, y luego por la arquitectura
cliente/servidor, cuyas características permi-
tían una mayor productividad, a costa de com-
plicaciones en la distribución y despliegue.
Posteriormente, un nuevo modelo vio la luz, y
fue tiempo de darse cuenta del potencial del
web como un ambiente para ejecución de apli-
caciones. En este modelo, los navegadores ac-
túan como clientes ligeros donde se interpreta
HTML, y a través de este se hacen peticiones
y se reciben respuestas de un servidor. Co-
múnmente esta interacción también se cono-
ce como arquitectura basada en páginas. Con
este modelo se resolvieron los problemas de
distribución y despliegue, ya que las aplicacio-
nes residen en el servidor. Sin embargo, esto
se logra a costa de la experiencia del usuario.
Esto se debe a las limitantes de HTML, así
como del protocolo HTTP.
Es entonces que llegaron las denominadas
RIA (Rich Internet Applications). Este térmi-
no fue acuñado en el 2002 por la empresa
Macromedia, y en ese entonces significaba
muchas cosas pero todo se veía sintetiza-
do en la frase “Experience that matters”.
Las RIAs proponían una experiencia para
el usuario muy diferente a la interacción de
cambio de página de las aplicaciones web
tradicionales, aquellas que en ese momen-
to se fueron haciendo obsoletas y formaron
parte de lo que se conoce como Web 1.0
Una RIA combina lo mejor de dos mundos:
> Aprovecha las ventajas del web como pla-
taforma para entregar aplicaciones.
> Brinda al usuario una experiencia por lo
menos comparable a la de las aplicaciones
de escritorio actuales.
28 JUL-AGO 2007
Figura 1. Algunos de los términos más representativos del Web 2.0
En una RIA se eliminan los viajes innecesa-
rios al servidor, lo cual impacta positivamen-
te el desempeño de las aplicaciones, ya que
la mayor parte del procesamiento se ejecuta
en el cliente. Este es un cliente enriquecido
(rich client) cuya funcionalidad va mucho
más allá del comportamiento default de un
navegador web. Algunas tecnologías utiliza-
das para clientes enriquecidos son los prác-
ticamente extintos Java Applets, o el novedo-
so Silverlight de Microsoft por citar algunos,
pero sin duda alguna el de mayor adopción a
nivel mundial es el Flash Player de Adobe.
Nociones de Web 2.0
Fue en el año 2004 cuando Tim O’Reilly utiliza
el término Web 2.0, aunque nunca ha sido de-
finido un esquema formal para decir qué sitio
es 2.0 y qué sitio no lo es. Si algo se ve lo sufi-
cientemente “cool” se agrega el mote de 2.0.
De los principios más socorridos al momento
de hablar de Web 2.0 tenemos:
> Usar la Web como plataforma.
> Datos como una fuerza de negocios
> Tomar los efectos de la red para crear una
arquitectura de participación
> Innovación en los sistemas y sitios web
> Modelo de negocios ligero
> Facilidad de adopción
Flex 2: RIA para Web 2.0
Habiendo dicho todo esto, podemos enfo-
carnos en una tecnología que está creando
bastante eco en la comunidad de desarro-
lladores de aplicaciones web: Adobe Flex. A
grandes rasgos, Flex es un framework para
desarrollar aplicaciones web que son ejecu-
tadas en la plataforma Adobe Flash. Actual-
mente, Flex se encuentra en su versión 2, y
todo lo que mencionamos en este artículo se
refiere a esta versión.
En su comportamiento, las aplicaciones he-
chas con Flex son similares a las aplicaciones
Ajax: permiten actualizaciones dinámicas
hacia la interfaz de usuario UI, y también tie-
nen la habilidad de enviar y recibir datos del
servidor de forma asíncrona. Una ventaja adi-
cional es que las aplicaciones hechas en Flex
pueden ser consideradas multiplataforma
debido a la ubicuidad de su cliente (Flash Pla-
yer). Muchos argumentarán que Ajax también
es multiplataforma, lo cual en teoría es cierto.
Sin embargo, en la práctica nos encontramos
con que los diferentes navegadores tienen
distintos niveles y mecanismos de implemen-
tación de Javascript y CSS, mientras que Flash
Player es una sola máquina virtual estándar
para todos los navegadores y sistemas ope-
rativos. Además, sería incorrecto comparar
directamente ambas tecnologías, ya que en
esencia Flex es un framework y una platafor-
ma de desarrollo, mientras que Ajax es una
serie de técnicas de desarrollo que explotan
el objeto XmlHttpRequest.
Elementos de Flex
La plataforma de Flex está formada por los
siguientes elementos:
> ActionScript 3.0 – Un lenguaje de progra-
mación orientado a objetos basado en la úl-
tima especificación ECMAScript.
> Flash Player 9 – La siguiente generación de
esta popular pieza de software que incluye una
Máquina Virtual (AVM2) que permite ejecutar
el código significantemente más rápido.
> MXML – Un lenguaje basado en XML que
permite manipular los componentes de la
aplicación de una forma eficiente.
> Compilador y Depurador – Un compilador
en línea de comandos así como un modelo
de depuración en tiempo de ejecución.
> Flex Framework – Una librería de compo-
nentes de interfaz de usuario GUI, tales como
botones, data grids, acordeon, paneles, con-
troles de árbol, etc. Fáciles de personalizar
basándose en CSS o mediante Skins.
> LiveCycle Data Services ES Express – Una
plantilla de aplicación Web entregada en
un servidor J2EE para comunicarse con el
cliente Flash Player mediante una serie de
www.sg.com.mx
servicios de comunicación, manejo de datos
y mensajería y con amplias posibilidades de
integración con los sistemas actuales.

Estos elementos están incluidos en un SDK

gratuito que se puede descargar del sitio
de Adobe.

Adicionalmente, están las herramientas de

desarrollo, las cuales tienen un costo.
> Flex Builder 2 – Un IDE construido sobre
Eclipse, que permite un ambiente de trabajo
visual para construir las interfaces enfocán-
dose siempre en el usuario y a la vez una vista
de código muy familiar a los programadores.
> Charting Components – Una serie de compo-
nentes enfocados a la parte de reportes y grá-
ficas, muy socorridos para crear Dashboards,
aplicaciones colaborativas y reportes.
> LiveCycle Data Services ES Departamental
y Enterprise – Versiones de LiveCycle Data
Services ES para 100 usuarios concurrentes Figura 2. Estructura de la plataforma Flex
o sin límite de usuarios en concurrencia res-
pectivamente.

La figura 2 muestra los principales elemen-

tos de la plataforma Flex, y la figura 3 mues-
tra el flujo de trabajo bajo el que funcionan
estas aplicaciones.

Consideraciones sobre Flex 2

Muchas tecnologías se ven ir y venir hoy en
día, pero son pocas las que se vuelven parte
del cajón de herramientas de los programa-
dores. Al crear Flex 2, Adobe tomo en cuenta
diversas consideraciones para maximizar su
adopción y facilitar la curva de aprendizaje.
De hecho, Flex está pensado de forma que
sea muy sencillo para los desarrolladores de
Java dar el salto hacia esta plataforma. Algu-
nas de las características que contribuyen a
esto son:
ActionScript 3.0 es muy similar a Java Figura 3. Flujo de trabajo para aplicaciones Flex
> Flex Builder está construido sobre Eclipse,
uno de los IDEs más populares > Es capaz de “senderear” datos en tiempo mado Adobe Integrated Runtime (AIR) –an-
> La gran mayoría de las tecnologías Java real a la interfaz. teriormente conocido como el nombre clave
(EJB, POJO, Hibernate, JMS, etc.) se integran > Soporta altas tasas de actualización de “Apollo”–, que es un ambiente de ejecución
fácilmente con Flex. imagen (refresh rate) en entidades de da- que permitirá portar al escritorio aplicacio-
tos grandes. nes RIA de forma transparente e indepen-
También existen diversas opciones de inte- > A través de la máquina virtual de Flash Pla- diente del sistema operativo.
gración para aprovechar las características yer 9, soporta compilación just-in-time (JIT).
de Flex desde la plataforma .NET, algunos Así mismo, la próxima versión de Flex se en-
ejemplos son WebOrb y Fluorine. Una visión al futuro de Flex cuentra a la vuelta de la esquina con la im-
Por ahora, solo falta que los desarrolladores portante noticia de que se hará una apuesta
Otras características atractivas de Flex 2 se den cuenta del gran potencial que tiene hacia el mundo del código abierto, lo que
pueden ser: esta tecnología, que ha tenido una evolución permitirá a terceros integrar esta tecnología
> Esta basado sobre un mecanismo de segu- muy rápida. Pensando en un futuro próximo, dentro de sus productos y crear sus propias
ridad sólido pronto veremos un complemento a Flex lla- soluciones basadas en ella. <<

Edgar Parada es un Adobe Certified Instructor, consultor de Adobe, colaborador de diversos centros de capacitación e instructor activo en la DGSCA/UNAM. Actualmente
dirige Activ (www.activ.com.mx), un Adobe Authorized Training Center especializado en tecnologías como Flex, Flash Lite y Flash Media Server. Es parte del equipo del primer
grupo de usuarios en español enfocado en Flex: MadeInFlex ( www.madeinflex.com) y también es manager de Riactive ( www.riactive.com.mx), el grupo de usuarios oficial en
México para Flex. edgarparada@activ.com.mx

www.sg.com.mx JUL-AGO 2007 29

 // COLUMNA
Web 2.0
La Redefinición de la “Caja de Zapatos”
Dr. Raul A. Trejo es Profesor Investigador del Departamento de Sistemas de Información del Tec de Monterrey, campus Estado de México.
Sus áreas de interés incluyen Ingeniería de Software, Negocios Electrónicos e Inteligencia Artificial. El Dr. Trejo participa en proyectos que
involucren de manera activa a sus estudiantes. Es miembro del Sistema Nacional de Investigadores (SNI) y ha presentado sus trabajos de
investigación en diversos foros nacionales e internacionales. El Dr. Trejo es miembro fundador de la Asociación de Sistemas de Información
de América Latina y del Caribe.
C uando alguien decide expresar su opinión
sobre un tema, buscando atraer, al menos
momentáneamente la atención del auditorio,
se dice que: “se sube en su caja de zapatos”; y
desde ahí expone su discurso
Cuando surgió la WWW, la información que se
podía encontrar era de carácter estático, pub-
licada por unas cuantas entidades, y muy es-
pecializada. Se podía encontrar información de
cursos en los sitios de universidades, noticias
en cnn.com y los últimos avances sobre naveg-
adores de red en mosaic.com. Y si uno deseaba
subirse a su caja de zapatos, podía hacerlo
desde los umbrales de usenet: ese primer in-
tento de grupo de discusión global, al que los
geeks llegaban tarde o temprano. En estos ini-
cios de la WWW, lo que podríamos llamar Web
1.0, se tenía una estructura centralizada de in-
formación, con relativamente pocas entidades
publicando, y una gran mayoría leyéndo.
Luego vino el auge de las punto com, con un
descubrimiento fundamental: todo el mundo
podía tener presencia en Internet, con diseños
más atractivos pero estáticos, que se convirti-
eron en un escaparate de publicidad para las
empresas. Sin embargo, estos sitios al estar
generalmente disociados de modelos de ne-
gocios sólidos, sucumbían del mismo modo
meteórico en que habían surgido. Pero quedó
un sobreviviente: la página personal. Ahora cu-
alquier persona podía tener un espacio en In-
ternet para subirse a su caja de zapatos, contar
sobre su vida, actividades, mascotas o cualqui-
er cosa que le interesara. Estas páginas solían
ser el secreto mejor guardado de la red, con
direcciones obtusas que sólo los amigos cerca-
nos visitaban, a menos que uno tropezara con
una de ellas por accidente. Mi primera página
aún está disponible en http://www.cs.utep.
edu/robotics/temporal/ (noten que no hay
referencia a mi nombre, ni al contenido de la
página). Ahora bien, ¿qué hay de la autopista
de la información en estas páginas personales?
Bueno, yo opino que era una autopista muy
rudimentaria, donde las referencias a temas de
interés consistían en hiperligas a otras páginas.
De nuevo, el contenido era en su mayoría es-
30 JUL-AGO 2007
/*CÁTEDRA Y MÁS*/
tático, y el trabajo de mantenimiento consistía
en eliminar y actualizar las ligas muertas.
La penetración de tecnologías como DHTML y
javascript dio lugar a páginas de diseño más
dinámico, en las que el visitante podía inter-
actuar y decidir qué información deseaba ver.
Hasta aquí podemos rastrear la evolución de
Web 1.0: páginas de contenido más dinámico
y visual, pero con información centralizada que
debe ser consumida en el lugar y el formato
que su creador ha decidido. Y la caja de zapatos
todavía sigue siendo un lugar escondido. Como
referencia, el lector puede consultar mi página
académica, en http://webdia.cem.itesm.mx/
ac/rtrejo. Ésta lleva demasiado tiempo sin ac-
tualizar, pero podrán notar que indica mi nom-
bre, y en algunas ocasiones recibe algunos visi-
tantes perdidos que se interesan en un curso
que no enseño hace años.
Llegamos así a Web 2.0. Más que un están-
dar, en realidad es un concepto, un cambio de
paradigma. El más importante es la descentral-
ización de la información. En vez de enlazar a
ligas que contienen grandes bloques de infor-
mación, se puede optar por acceder a servicios
que nos proporcionan un fragmento de infor-
mación específica que puede ser actualizada de
manera dinámica por su dueño y transparente
para la entidad que consume la información.
Aún mejor, ya no existe un formato predeter-
minado para la información, la cual puede in-
cluirse dentro de nuestra página personal en el
formato más apropiado y consumirse por otros
dispositivos, como los teléfonos celulares.
La primera característica de Web 2.0 es la de-
scentralización. Los creadores de información
pueden recopilarla, clasificarla y hacerla dis-
ponible en segmentos significativos. ¿Qué pasa
con la caja de zapatos? Pues que ahora nues-
tra capacidad de expresarnos es mucho más
rica, y se puede incluir en nuestras páginas
personales información creada por terceros de
manera directa. Como resultado, se hará común
que el viajero de Internet acceda a información
desde un sitio distinto a donde ésta fue creada.
Lo que nos lleva a la segunda característica: el
poder para el usuario; el poder de generar in-
formación, publicarla, agregarla o reagruparla.
No en balde los blogs de los reporteros de CNN
fueron en un momento más populares que el si-
tio oficial de la cadena noticiosa. Existe una ter-
cera característica: el concepto de comunidad.
Las páginas personales ya no son más islas soli-
tarias. Los usuarios se congregan: publican sus
videos en YouTube, resuelven los problemas de
otros en foros, o dan a conocer sus datos más
personales en hi5. Herramientas tales como las
etiquetas inteligentes (smart tags) y los nuevos
algoritmos de búsqueda harán que el contenido
agregado en las distintas páginas personales
sea más fácil de encontrar. En todo caso, es
muy seguro que alguien más de la misma co-
munidad encuentre la nuestra.
Consideren mi página actual (rulopotamo.
spaces.live.com). Tiene mi nombre, y pertenece
a una comunidad. En ella encontrarán infor-
mación sobre temas de mi interés, y podrán
notar el video y el pronóstico del tiempo, extraí-
dos de fuentes externas. Subirse a la caja de
zapatos en Internet nunca fue más sencillo.
La adopción del concepto Web 2.0 tiene varias
consecuencias que proveedores y usuarios de-
berán considerar. El concepto de propiedad de
información se está redefiniendo; el problema
del copyright, uno de los puntos sensibles de
Internet, se agudizará más con las tecnologías
emergentes (Paramount Pictures aún libra una
batalla que parece perdida con YouTube). Es
claro que los modelos de negocio deben re-
plantearse. Existe también el problema de cali-
dad de información, y el cómo discernir cuál es
confiable o verídica ante la gran cantidad dis-
ponible, y cómo el sitio donde se encuentre no
será necesariamente el mismo que la genere.
Queda un último detalle. Ya recibo más visitas
en mi página. Pero no estoy seguro si los viaje-
ros de Internet lo hacen por su interesante con-
tenido, o sólo como medio para tener acceso
a las páginas de mis amigas. Y dicho esto, me
bajo de mi caja de zapatos.
—Raul A. Trejo
www.sg.com.mx
www.sg.com.mx JUL-AGO 2007
 // PRÁCTICAS /* MANTENIMIENTO DE SOFTWARE*/
Mantenimiento de Software
Todos lo hacemos, pero nadie se acuerda
Por José M. Esquivel
La industria de desarrollo de software mantiene una evolución cons-
tante. Antes podíamos ver que los ingenieros en sistemas compu-
tacionales, electrónica, o incluso otra especialidad contaban con
todos los conocimientos necesarios para desarrollar y entregar un
software. Sin embargo, la creciente complejidad del software y las
tecnologías y procesos necesarios para su desarrollo y manteni-
miento ha provocado que los profesionistas tengan que especiali-
zarse. Dentro de estas especializaciones encontramos algunas como
la programación, el levantamiento y análisis de requerimientos, el
diseño de aplicaciones, el diseño de base de datos, las pruebas de
software, y recientemente una actividad que es por mucho, una de
las mas importantes y menos valoradas de la industria: el manteni-
miento de software. Según la terminología ANSI-IEEE, el manteni-
miento del software es: “la modificación de un producto software
después de su entrega al cliente o usuario para corregir defectos,
para mejorar el rendimiento u otras propiedades deseables, o para
adaptarlo a un cambio de entorno”. En este artículo exploraremos
los aspectos fundamentales de esta actividad.
Frente a la considerable velocidad con que se ha desarrollado la in-
geniería de hardware, el desarrollo del software ha sufrido un retra-
so histórico en cuanto a la elaboración y disposición de tecnologías
(metodologías y herramientas). Esto evidentemente merma la calidad
de los sistemas liberados y corriendo en ambientes de producción. La
complejidad del proceso de producción de software se intenta abordar
mediante la descomposición en diversas etapas. Esta descomposición
recibe el nombre de “Ciclo de Vida del Software”. Los diversos mode-
los de ciclo de vida típicamente plantean distintas fases derivadas del
modelo de cascada, tales como:
• Análisis y Definición de Requerimientos
• Diseño
• Programación
• Prueba
• Despliegue
• Operación y mantenimiento.
Las tareas de mantenimiento son las últimas en realizarse en el ciclo
de vida clásico del software. Sin embargo, considerando el total de la
duración del ciclo de vida, la etapa de mantenimiento es la que más
tiempo dura, ya que elaborar un sistema mediano típicamente lleva
de 6 meses a 1 año, y posteriormente el sistema en producción po-
Jose M. Esquivel es Ingeniero en sistemas computacionales egresado de la Universidad Autonoma de Guadalajara. Actualmente trabaja para Jabil de
Mexico como Ingeniero de soluciones empresariales dando soporte a los sistemas de la compañia asi como impartiendo la clase de “Pruebas y Manten-
imiento de Software” a nivel licenciatura en la Universidad del Valle de Atemajac. Anteriormente laboró en IBM como ingeniero de pruebas, Ingeniero de
desarrollo, arquitecto de producto para clientes como Motorla y Chrysler, entre otros.
32 JUL-AGO 2007
drá correr durante varios años durante los cuales el sistema debe ser
soportado y mantenido. De la misma forma, aun cuando el manteni-
miento de software es la última etapa del ciclo de vida del software,
las actividades de mantenimiento no son las menos importantes. Muy
al contrario, el mantenimiento del software se ha convertido en el
principal componente en cuanto a costo y recursos invertidos en las
organizaciones de TI. Esta aseveración responde principalmente a la
relación entre el número de sistemas desarrollados anualmente por la
industria, comparado con el número de sistemas en funcionamiento
que hacen trabajar a las empresas.
Dentro de las actividades del mantenimiento de software ocurre un
fenómeno muy interesante, que es algo que denominaremos como la
barrera del mantenimiento de software, y que en pocas palabras es
la incapacidad en la que se ven sumergidas las organizaciones para
poder iniciar nuevos proyectos debido al enorme desvió de recursos
necesarios para soportar sistemas que son parte de la operación dia-
ria. Se estima que esta barrera se alcanza cuando más de un 90 % de
los recursos se encuentran dedicados a soportar aplicaciones.
Prácticamente todos los profesionistas de sistemas hemos escuchado el
comentario de que somos como los bomberos, apagando fuegos. Bue-
no, pues precisamente ésta es la razón de traer este tema a reflexión. El
mantenimiento de software debe ser una actividad planeada por el área
de tecnologías de información de una organización, que debe contar
con recursos dedicados y capacitados para desempeñarla.
Dividiremos entonces nuestra plática en 2 temas importantes: los proble-
mas del mantenimiento de software y las soluciones a estos problemas.
Problemas del Mantenimiento de Software
La problemática del mantenimiento de software se resume en realizar
el mantenimiento de forma tan rigurosa y controlada que no se de-
teriore la calidad del sistema como resultado de este proceso. Por la
naturaleza del software, existen problemas relacionados con el man-
tenimiento de software que están claramente identificados y sobre los
cuales hablaré a continuación:
La existencia de los llamados “legacy code” (código heredado).
Con el paso de los años se ha ido produciendo un volumen muy
grande de software en las empresas. En la actualidad, la mayor par-
www.sg.com.mx
 “El mantenimiento de software debe
ser una actividad planeada... que debe
capacitados para desempeñarla ”.
te de éste software está formado por código antiguo “heredado”; es
decir, código de aplicaciones desarrolladas hace algún tiempo, con
técnicas y herramientas en desuso y probablemente por personas
que ya no pertenecen a la empresa ni al grupo responsable en este
momento del mantenimiento del software. La situación se complica
porque el código heredado ha sido objeto de múltiples actividades
de mantenimiento. La opción de desechar este software y reescri-
birlo para adaptarlo a las nuevas necesidades tecnológicas o a los
cambios en la especificación no es viable en la mayoría de las oca-
siones, debido a la gran carga financiera que supuso el desarrollo
del software original y la necesidad económica de su amortización.
Problemas inherentes al mantenimiento del software.
A pesar de toda la estandarización y modelos de procesos que bus-
quemos adoptar, el desarrollo de software es en el fondo un proceso
creativo. Es así que en el software siempre encontraremos patrones
no uniformes de programación, ya que dependiendo de su habilidad,
creatividad y experiencia, los programadores generan código de ma-
neras innumerables. Asimismo, es muy común encontrarse con apli-
caciones de software desarrolladas sin seguimiento a metodologías,
procesos, ni lineamientos, que se refleja en código mal escrito, mal
documentado, y por lo tanto difícil de mantener.
Efectos secundarios o laterales no previstos ni deseados.
Estos efectos se dan como consecuencias a las modificaciones no
controladas a las aplicaciones de software, que a su vez representan
problemas para el mantenimiento posterior del software. Existen tres
tipos de efectos secundarios y se definen por su impacto en las dife-
rentes áreas de una aplicación de software:
a. Efectos secundarios en el código, en donde el código sufre modi-
ficaciones como rediseños, eliminación de procedimientos o subpro-
gramas, modificación de macros o dll’s, cambios para mejorar el des-
empeño, etc...
b. Efectos secundarios en los datos, esto al impacto de los cambios en
los datos de las aplicaciones, tales como modificaciones en catálogos,
formularios, cambios en los parámetros de los programas, etcétera.
c. Efectos secundarios en la documentación, en donde general-
mente después de un cambio en la aplicación, la documentación
no es actualizada y esto genera problemas en la “mantenibilidad”
del software.
Soluciones a los problemas de mantenimiento
de software
Existen diversas estrategias y acciones que podemos llevar a cabo
para resolver o mitigar los diferentes problemas descritos anterior-
mente, y que pueden servirnos de guía sobre la manera en que las or-
ganizaciones deben de enfrentar el mantenimiento de software. Entre
las principales estrategias están:
www.sg.com.mx
contar con recursos dedicados y
Código mantenible.
Como ya lo mencionamos anteriormente, la manera de estructurar
un programa depende de la creatividad y habilidad de los progra-
madores, sin embargo existen prácticas que contribuyen a mejorar
la facilidad de mantenimiento del código. Estas prácticas se resu-
men a continuación:
• Código documentado: Los diferentes segmentos de código que se
escriben deben contener comentarios objetivos que expliquen de for-
ma adecuada el funcionamiento de éstos. Cada programa, clase y mé-
todo debe incluir documentación sobre su propósito, funcionamiento,
entradas y salidas esperadas
• Banderas de cambio: es una práctica poco utilizada en la industria, y
se refiere a la habilidad de establecer un mecanismo de identificación
de cambios a lo largo de la vida de una aplicación. Es decir, si debido a
una modificación el día de hoy cambiamos un par de líneas de código,
es importante marcar esas líneas con alguna bandera que nos permita
identificar en el futuro la razón por la que se modificó el código. Esto
nos permite tener una visión de las versiones y justificaciones que pu-
dieron haber inyectado un error a la aplicación.
• Documentación actualizada: esta práctica es poco ejercida debido
a que el tiempo y la forma de documentación no es suficiente en los
proyectos de desarrollo. Sin embargo, me refiero primordialmente a
tener las especificaciones de las aplicaciones actualizadas, no al ma-
nual de usuario que si bien es de mucha ayuda, es de más ayuda tener
documentación técnica actualizada, tal como diseños, diagramas, dic-
cionarios de datos, etc…
Equipo dedicado de mantenimiento de software
A pesar de la importancia que ya vimos que tiene el mantenimien-
to de software, muchas organizaciones no justifican la asignación
de un equipo dedicado exclusivamente al mantenimiento de soft-
ware. Sin embargo, es primordial tener identificadas a las perso-
nas que realizarán esta actividad, y no solo identificadas, sino
también capacitadas y calificadas para realizar estas actividades.
La justificación para tener a este equipo es muy sencilla, simple-
mente basta con cuantificar el costo que tiene que un sistema de
producción deje de funcionar, o que genere problemas en su uso
debido a un bug.
Conclusión
El mantenimiento de software es un área que recibe poca
atención, pero no por ello deja de ser sumamente importante,
especialmente cuando se considera la cantidad de recursos que
se le destinan. Existen muchos aspectos sobre el mantenimiento
de software sobre los que vale la pena ahondar, y espero poder
hacerlo en futuras ocasiones.
JUL-AGO 2007 33
 // PRÁCTICAS /* ADMINISTRACIÓN DE PROYECTOS*/
Caso Práctico sobre Análisis de
Puntos de Función
Parte 3. Puntos de Función Ajustados y Uso de los Puntos de Función
Por Aquiles Santana
Bienvenidos a la tercera y última parte de este caso práctico sobre
análisis de puntos de función. Como podrán recordar, el objetivo
de este ejercicio es mostrar cómo se utiliza la técnica de puntos
de función aplicada a un caso real. En nuestro caso, la aplicación
consiste en un sistema para administrar las ventas de automóvi-
les que realiza una empresa de compra-venta de autos usados.
En la parte 1, planteamos los requerimientos iniciales en los que
nos basamos para realizar el análisis. Posteriormente, en la parte
2 llevamos a cabo los pasos necesarios para determinar los puntos
de función no ajustados. Ahora, ya solo nos falta realizar el ajuste
para obtener los puntos de función ajustados. Por último, daremos
un vistazo a los múltiples usos que le podemos dar al resultado de
nuestro análisis de puntos función. Comencemos entonces …
6. Determinar el Valor del Factor de Ajuste
Este paso, ayuda a determinar un factor de ajuste que puede au-
mentar o disminuir el valor de los puntos de función en un +/-
35%. Las características evaluadas se refieren a requerimientos
o restricciones no funcionales, como: comunicaciones de datos,
actualización online, complejidad de procesamiento, facilidad de
instalación, etc.
Si la calificación de estos factores ambientales es el mínimo, el
valor de ajuste será 0.65. Por el contrario, si los factores ambien-
tales son los más complicados, el valor de ajuste será 1.35.
Para obtener la evaluación más precisa y objetiva, se recomienda
que para esta actividad el analista de puntos de función trabaje
en conjunto con el equipo técnico.
Aplicación al caso
Debido a que no fue proporcionado el detalle de las caracterís-
ticas ambientales, y sólo se indicó que los requerimientos y res-
tricciones no funcionales son como el “promedio”. Se asumirá un
valor de ajuste igual a uno.
Cuando se calculan los puntos de función para realizar una es-
timación mediante el uso de una herramienta estadística, se
alimentará únicamente los puntos de función no ajustados. Es
decir, funcionalidad “pura” sin la influencia de características
ambientales o de implementación. Esto es debido a que estas
34 JUL-AGO 2007
herramientas tienen ya sus propias variables ambientales y sus
propios criterios de evaluación. Por ello, alimentar puntos de
función ajustados redundaría el factor ambiental que ya es con-
siderado en la estimación.
7. Determinar los Puntos de Función Ajustados
En este paso, se aplican fórmulas que en esencia consideran los
puntos de función no ajustados y se multiplican por el factor de
ajuste. Las fórmulas a ser aplicadas dependen del tipo de conteo
(desarrollo, mantenimiento o aplicación). Para el caso de un nue-
vo desarrollo, la fórmula es la siguiente:
Puntos de Función Ajustados =
Puntos de Función no Ajustados x Valor de Ajuste
Aplicación al caso
Sumando las funciones de datos (12 puntos de función no ajus-
tados) y las funciones transaccionales (23 puntos de función no
ajustados), esta aplicación mide 35 puntos de función no ajusta-
dos, los cuales multiplicados por el factor de ajuste igual a 1, nos
daría 35 puntos de función ajustados.
Uso de los Puntos de Función
Una vez que hemos obtenido el total de puntos de función, esta-
mos ya en posibilidad de beneficiarnos de esta poderosa técnica.
Algunos de los beneficios que obtenemos directamente son:
• Estimación de Proyectos: El dato de los puntos de función no
ajustados, puede ser introducido en algún modelo de estimación
estadístico, el cual sea calibrado con información histórica de
proyectos ya terminados y también dimensionados en puntos de
función. Los datos históricos de tamaño, esfuerzo, personal, fa-
ses y características ambientales, proveen las tendencias clave
que pueden ser utilizadas para estimar proyectos similares. En
nuestro caso la aplicación mide 35 puntos de función y el cliente
quiere que terminemos el proyecto en 2 meses. Buscaremos en
la BD historia de proyectos en tamaño y características similares,
y con la ayuda de las herramientas estadísticas, identificaremos
tendencias y evaluaremos las probabilidades de éxito en diferen-
tes situaciones, como por ejemplo: ¿Cuál es la probabilidad de
terminar el proyecto en 2 meses?, ¿Cuál es la cantidad adecuada
de personas a ser asignadas al proyecto? ¿Cuál es la cantidad de
www.sg.com.mx
esfuerzo requerido?, ¿Cuál sería el escenario con menor costo? y además, si con la in-
formación histórica se observara una muy baja probabilidad para terminar en 2 meses,
¿Cuántos puntos de función si podríamos comprometer para liberar en 2 meses?. Las he-
rramientas de estimación paramétrica son excelentes para estudios de “¿Qué pasa sí…?”
y en la generación de diferentes escenarios factibles. Siempre, el tener mayor informa-
ción histórica de nuestros propios proyectos, será mejor para incrementar la exactitud
de nuestros estimados.

• Control de Alcance: Una vez aprobado el alcance de 35 Puntos de Función, será ahora
nuestra línea base de tamaño. Debido a que el proyecto se encuentra en fases tempra-
nas, típicamente existirá un crecimiento de tamaño debido a un mayor entendimiento
del negocio y/o aclaración de supuestos. En nuestro caso práctico, hicimos el supuesto
de que la aplicación, no contemplaba funcionalidad para definir usuarios y perfiles de
seguridad. Sin embargo, durante el desarrollo, dicho supuesto podría cambiar cuando
el usuario decidiera que si quiere tal funcionalidad. Como en cualquier administración
de cambios, abriríamos nuestro control de cambios al alcance y en la evaluación del
impacto, incluiríamos el nuevo tamaño funcional para ver si dicho incremento de tama-
ño sobrepasa nuestros límites de capacidad. En caso de ser así, ejecutaríamos alguna
acción de mitigación o contingencia. Por ejemplo, si derivado del análisis, la funcionali-
dad creciera hasta 50 puntos de función, ¿mantendríamos el mismo estimado de dura-
ción/esfuerzo/personal asociado a los 35 puntos de función?, ¿hasta donde podemos
absorber? ¿Sí sólo crece 10 puntos de función, podemos manejar el crecimiento? En este
punto, las opciones típicas para administrar el cambio, podrían ser:
- Priorizar junto con el usuario para acotar de nuevo a los 35 puntos de función y mo-
ver la funcionalidad con menor prioridad a otras fases.
- Incrementar el tamaño del equipo (si es aún factible).
- Incrementar la duración del proyecto.

• Control de producción: Los puntos funcionales nos permiten cuantificar cual es el ta-
maño del proyecto. Es decir, al final del proyecto de nuestro caso práctico esperamos
que se entreguen 35 puntos de función. Ahora bien, durante el ciclo de vida, cada que
es terminado un caso de uso, un diseño, un diagrama de clases, una codificación de un
método o un caso de prueba, etc; nos vamos acercando a estos 35 puntos de función.
Alguna herramienta para el control de producción tomará como entrada estos 35 puntos
de función, y hará visible cuanto se ha construido y cuanto debería tenerse construido
con base a información histórica, y así comparar si el ritmo de producción es similar a las
tendencias esperadas. En caso de que el ritmo de producción fuera menor al esperado,
acciones correctivas o de mitigación sería tomadas. Por ejemplo, quizas, el volumen de
producto es menor debido a que los peer reviews, están siendo sólo de forma y no de
fondo, y los defectos mayores están pasando directamente por el ciclo de vida, sin que
sean tempranamente atendidos. Nuestra acción sería atender esta causa modificando el
proceso de peer reviews para detectar estos defectos tempranamente e incrementar el

www.sg.com.mx JUL-AGO 2007

 // PRÁCTICAS
• Construcción de base de datos histórica para benchmarks y
proyectos de mejora continua: Cuando terminemos nuestro pro-
yecto de 35 puntos de función, como parte de las actividades
de cierre del proyecto obtendremos y registraremos métricas y
lecciones aprendidas. Entre las métricas que deberán ser reco-
piladas están: el tamaño funcional, el esfuerzo (horas-hombre,
meses-hombre), duración (días calendario, días hábiles), núme-
ro de personas, cantidad de defectos, número de cambios, can-
tidad de líneas de código, cantidad de casos de uso, número de
riesgos, número de issues, etc. Estos datos serán almacenados
en nuestra base de datos de proyectos históricos con el propó-
sito de ser analizados y utilizados para realizar benchmarks en
la propia organización y contra el mercado, y derivado de ello,
arrancar proyectos de mejora con el fin de reducir el costo de
nuestros proyectos, incrementar nuestro desempeño y lograr
mejores oportunidades de mercado. Estos proyectos de mejora,
partirían de metas objetivas para disminuir el costo de nuestros
proyectos mediante el incremento de productividad y calidad.
Por ejemplo, si la información de la industria, nos indicara que la
productividad típica de un proyecto es de 15 puntos de función
por persona-mes, y en nuestros proyectos tenemos un promedio
de 10 puntos de función por persona-mes, esto nos daría una
meta clara de que por lo menos debemos incrementar la pro-
ductividad en 5 puntos. De esta forma, los programas de mejora
complementarán sus objetivos y no sólo estarán enfocados a lo-
grar tal o cual certificación, o nivel de madurez. Los programas
de mejora continua, deben tener objetivos claros y medibles
para el negocio, y no sólo el objetivo de obtener un papel o re-
conocimiento. Adicionalmente, el ingreso de más información en
nuestra base de datos de proyectos, incrementará la exactitud
de nuestros estimados y nos dará mayor oportunidad y certeza
para dar estimados agresivos pero factibles.
Potenciales usos del Proceso de Análisis de
Puntos de Función
Obviamente, el objetivo principal del análisis de puntos de fun-
ción es obtener los puntos de función para un sistema. Sin em-
bargo, existen beneficios adicionales derivados de la aplicación
del proceso. Como su nombre lo indica el Análisis de Puntos
de Función, es también una técnica de análisis sistemática que
aporta beneficios tangibles como:
• Rastreabilidad de componentes: Como pudo ser apreciado en
nuestro caso práctico, al momento de realizar el conteo de Puntos
de Función, se identifican componentes funcionales que tienen
una granularidad definida, debido a que seguimos las reglas y
definiciones del estándar del IFPUG. Estos componentes lógicos
Aquiles Santana Álvarez es Certified Function Points Specialist por parte del IFPUG y Project Manager Professional por parte del PMI. Ha sido respon-
sable de la estimación de proyectos de software críticos para EDS de México y Latinoamérica. Ha impartido entrenamiento en la técnica de Puntos de
Función y estimaciones a más de 300 personas en 6 países. Actualmente se desempeña como consultor en Project Management e Ingeniería de Software.
36 JUL-AGO 2007
/* ADMINISTRACIÓN DE PROYECTOS*/
funcionales, pueden ser relacionados contra los componentes
físicos (tablas, pantallas, clases, casos de prueba, etc), lo cual
sienta las bases para la construcción de una matriz de rastreabi-
lidad que sea utilizada para evaluar de manera completa y con-
sistente el impacto de los cambios, y aumentar la productividad
en los mantenimientos debido a curvas de aprendizaje menores.
En nuestro caso, la función de datos: “Vehículo” está implemen-
tado en dos tablas: Tb_Vehículos y Tb_Accesorios_Vehículo. Por
lo tanto cuando funcionalmente se identifique una modificación
a la función de datos “Vehículo”, el equipo técnico sabrá que es-
tados dos tablas podrían ser impactadas.
• Identificación de scope creep o inconsistencias en los reque-
rimientos: Cuando se están contando los puntos de función e
identificando las funciones de datos y transaccionales, el aná-
lisis es realizado de manera sistemática, por lo cual aparecen
preguntas que deben ser resueltas por el equipo de análisis o
el cliente. Por ejemplo, en nuestro caso práctico, al momento de
contar las funciones transaccionales, vemos que tenemos la fun-
ción de “Insertar Compra”, sin embargo, cabe pensar que pueda
existir un “Actualizar Compra”, funcionalidad que no está inclui-
da en los requerimientos, pero que podría presentarse y debe
ser evaluado con el cliente si dicha funcionalidad será parte del
sistema. Así mismo, el análisis de puntos de función ayuda a re-
visar los productos derivados de otras técnicas de análisis. En mi
experiencia, ha sido muy útil para identificar defectos presentes
en especificaciones de casos de uso.
Conclusión
La técnica de análisis de puntos de función es muy valiosa
para nuestra industria, donde la carencia de métricas de
productividad estándar reduce la madurez con la que
nuestros clientes y nosotros mismos podemos evaluarnos.
Una industria madura se fundamenta en métricas y no en
percepción y buenos deseos. Por esto, como consumidores de
productos de ingeniería de software debemos exigir y evaluar
a nuestros proveedores con métricas de productividad y
calidad, y como proveedores debemos empujar e incrementar
nuestro desempeño orientados a la reducción de costos y
aumento en la satisfacción. A fin de cuentas, el objetivo no
es alcanzar un nivel de madurez o una certificación, ese es
sólo el medio. El objetivo real es producir aplicaciones con
oportunidad, mínimo costo y alta satisfacción para nuestros
clientes y nuestros empleados, y en ese camino, los puntos de
función tienen mucho que ofrecer.
www.sg.com.mx
 // PRÁCTICAS /* MEJORA DE PROCESOS*/
Factores Clave
para la Mejora de Procesos
La diferencia para el éxito
Por Rocío García Ocaña
Sin duda alguna, las necesidades y tendencias externas determi-
nan los cambios en las organizaciones, cambios de toda índole
y tamaño. Desde cambiar un poco la forma de hacer las cosas
hasta cambios que implican un programa formal dando pie al
surgimiento de un programa de mejora cuyos objetivos son el
incremento de calidad, disminución de costos, aumento de com-
petitividad, entre otros.
Usualmente, la mejora de procesos se concentra en la definición o
redefinición de procesos, procedimientos, políticas, mediciones,
uso efectivo de herramientas, etcétera. Sin embargo, esto no es
suficiente para lograr la mejora que buscamos, ya sea en el des-
empeño o en la calidad. Pensemos que para conseguir resultados
con impacto, es necesario cambiar cosas no sólo en papel o en
electrónico, sino en hábitos, comportamientos y percepciones,
para conseguir una alineación a los objetivos que perseguimos.
Una de las quejas más frecuentes durante la fase de implemen-
tación de un programa de mejora de procesos, se refiere a la
cooperación limitada o nula de algunos miembros de la organi-
zación, respecto a seguir los procesos definidos, pero ¿qué hay
detrás de ese comportamiento?, ¿y cómo mitigarlo para lograr
que nuestro programa genere verdaderamente los resultados
que buscamos?
Antes de pensar en introducir mejoras de proceso, lo primero que de-
bemos saber es que, hacerlo implica cambios en la forma de traba-
jar, lo cual tiene un impacto directo en esfuerzo y por consiguiente,
en tiempos. Es así como caemos en la cuenta que uno de los ries-
gos más grandes es la aparición y permanencia de la resistencia de
los miembros de la organización, que a la larga, se convierte en un
verdadero dolor de cabeza para una implementación exitosa. ¿Les
suena familiar? Si han implementado y están en la actualidad involu-
crados en el mencionado proceso, comprenderán sin lugar a dudas
a lo que me refiero. La importancia de considerar otros factores que
contrarresten el efecto de los cambios y se conviertan en aliados
para implementar exitosamente nuestro programa, es crítico. Los
factores a los que me refiero son: cultura, comunicación, disciplina,
convencimiento, manejo del cambio, coaching y enfoque.
www.sg.com.mx
Considerar dichos factores nos permitirá tener una estrategia
más robusta y con mayores posibilidades de alcanzar los resul-
tados que esperamos. El objetivo de este artículo es explicar en
qué consisten estos factores y entender su importancia para im-
plementar un programa de mejora.
La cultura
Al igual que un país, las organizaciones son entes únicos, con
una identidad que las diferencia y una serie de valores que las
identifica. A este conjunto de identificadores es a lo que llama-
mos cultura organizacional. Entenderla es fundamental porque
nos ayuda a sensibilizarnos con el ambiente de la organización
y prever un poco su reacción ante la introducción de cambios.
La importancia de conocer y entender la cultura organizacional
radica en el hecho de que existen elementos imperceptibles a
simple vista, como hábitos, sentimientos, motivadores, clima
laboral, estilos, etcétera; que pueden convertirse en poderosos
obstructores durante una implementación. El plan de mejora
busca incrementar la calidad a través de diseño de procesos,
pero dichos procesos son ejecutados por personas con una
identidad individual incrustada en una identidad colectiva, por
eso requerimos hacer un alto, y recapacitar antes en el tipo de
cultura que tenemos. Supongamos por ejemplo, que la ejecu-
ción de los procesos me ayuda en un mediano plazo a hacer
que los integrantes de los equipos de desarrollo trabajen en un
ambiente más controlado, que los trabajos se logren terminar
en tiempo y presupuesto, pero ¿qué hay más allá de eso? Pro-
bablemente parte de la cultura de la empresa, es el valor a los
detalles funcionales del producto que se construye, más aún
hablando de software. Tal vez uno de los valores de la empresa
es propiciar la lealtad de los clientes; y la cultura de atención
en los detalles no es sólo cuestión de calidad sino de valores.
Todos estos pequeños detalles nos darán la pauta para saber
orientar el programa de mejora y hacer que no sólo encajen con
una estrategia de negocio, sino con la cultura de trabajo de las
personas que forman parte de la organización. Lo que nos dará
como resultado: minimizar el shock ocasionado por los cambios,
facilitar la introducción del cambio, así como lograr un cambio
más duradero en la organización.
JUL-AGO 2007 37
 // PRÁCTICAS
“Manejar el cambio significa: subir a
todos al barco del cambio, sin olvidar
que estamos a cargo del timón”.
Comunicación
“La comunicación es la base de todo”, seguramente han escucha-
do en varias ocasiones esta frase, y ahora me permito repetirla
una vez más, pues en los programas de mejora no es la excepción.
De la claridad y efectividad con que los comuniquemos depende-
rá en gran medida la respuesta de las personas de la organización
para asimilar y aceptar los cambios que implican las mejoras.
Para denotar la importancia de una comunicación efectiva, recapi-
tularemos un poco sobre lo que sucede al decidir trabajar con un
programa de mejora: se identifica una necesidad, se conforma al
equipo de trabajo, comienza la planeación; si los patrocinadores
del programa están de acuerdo se autoriza y comienza a ponerse
en marcha. El tiempo pasa, y aunque vemos avance en las activi-
dades de cada fase del plan de mejora, ¡sorpresa!, la implementa-
ción no está arrojando los resultados esperados, o tal vez no con
la rapidez que esperamos; es entonces cuando nos preguntamos:
¿qué falta? Las razones pueden ser varias, pero una de las princi-
pales es la falta de comunicación o la comunicación no efectiva.
Un plan de mejora es generalmente gestionado por un grupo de
personas, pero no hay que perder de vista que es “ejecutado” por
un grupo más grande de personas que, de una u otra forma, ven
alteradas sus actividades como efecto de los cambios introduci-
dos. Es por ello que la comunicación honesta, abierta, oportuna e
integral, es fundamental en todas las fases del programa.
Es importante que desde el inicio consideremos el tiempo sufi-
ciente y los medios adecuados para informar a todos los involu-
crados, a todos los niveles, sobre lo que se busca lograr, en qué
vamos, qué implica y por qué se está haciendo, qué impactos
tiene y qué pasa si no se hace. El no sostener una comunicación
efectiva y constante durante todas las fases del plan de mejora,
provoca desorientación, y cada una de las personas involucradas
en el cambio caminará con su propia visión de las cosas, la cual
puede no coincidir con la visión general del programa, lo que im-
pedirá que el esfuerzo y el trabajo rinda los frutos esperados.
Disciplina
Como todo en la vida, el logro de objetivos requiere disciplina
Rocío García Ocaña labora en Avantare Consultores como Consultora de ingeniería de procesos de software. Su desarrollo profesional la ha llevado a
empresas como Getronics ICT Solutions donde fue Coordinadora de Procesos y Aseguramiento de Calidad del Software, y FORD Motor Company México
donde tuvo a su cargo la definición de procesos de procesos de administración, respaldo y recuperación. Rocío es Licenciada en Sistemas Computacio-
nales Administrativos por el ITESM-CEM, y cuenta además con una Maestría en Administración por la misma institución.
38 JUL-AGO 2007
/* MEJORA DE PROCESOS */
en la ejecución de las acciones que demanda nuestro plan de
mejora, esto con la finalidad de tener un progreso real que nos
garantice el logro de los resultados que buscamos, lo anterior no
es nada nuevo, sin embargo ¿cómo generar disciplina en nuestra
gente?, no es una tarea fácil. Comencemos por definir el térmi-
no. La palabra disciplina tiene un vínculo tanto a áreas de co-
nocimiento como al apego de las reglas. En el contexto de un
programa de mejora, se refiere a conocer y seguir los procesos
como fueron definidos, para lo cual, la autoridad (llámese comité
de mejora) contribuirá para guiar a la organización y verificar el
apego a los procesos. Si esta disciplina no se fomenta a todos los
niveles, difícilmente lograremos los cambios que esperamos. No
obstante, hay que tomar en consideración que la disciplina no es
lo mismo que la imposición. La disciplina se inculca, se enseña
con el ejemplo y se mejora con el tiempo, pero si la intentamos
desarrollar con intimidación puede generar efectos secundarios,
tales como la apatía.
Convencimiento
Para explicar este factor, quisiera que pensaran por unos segun-
dos en la razón por la cual usan el cinturón de seguridad una
vez que suben a su auto, tal vez lo hacen por instinto o por cos-
tumbre, pero a fin de cuentas, probablemente lo usan porque
están convencidos de que puede salvarles la vida en un acciden-
te cuando menos lo esperen. Dichas circunstancias imaginarias
nos provocan cierta disciplina en su uso. El punto al que preten-
do llegar es que, el estar convencido de la utilidad o el valor de
las cosas es algo que buscamos en las personas para generar
disciplina, es decir, que esa comunicación de los nuevos pro-
cesos vayan acompañados de información contundente; lógica
que tenga el poder de convencer y que haga que en las personas
florezca la disciplina para seguir los procesos definidos y lograr
un hábito a largo plazo, haciendo verdaderamente sustentables
las prácticas que se pretenden introducir a través del programa
de mejora.
Manejo del cambio
La mejora de procesos representa sin duda un esfuerzo organi-
zacional con impactos de distintas magnitudes en el ambiente, y
www.sg.com.mx
como tal, estos cambios requieren ser conducidos de la manera correcta, siempre con
el apoyo de la alta gerencia, pero ¿qué significa manejar el cambio? Primeramente en-
tender que cada pequeño o gran cambio que ocurre dentro de la organización provoca
diversas reacciones en las personas, desde la cooperación hasta la resistencia. El ma-
nejo del cambio en todo el proceso del programa es en definitiva una de las claves para
hacer la implementación suave y con efectos duraderos. El manejo del cambio, más
allá de generar un plan, monitorearlo y garantizar que sea apoyado por la alta geren-
cia, implica tener objetivos claros, visión nítida de dónde queremos llegar, dedicación
y atención para guiar a las personas durante toda la iniciativa; de tal manera que en
todo momento podamos percibir y canalizar todos los sentimientos que generan los
cambios en las personas que forman parte de la organización. Es necesario entender
que la mejora conlleva cambio y el cambio, tanto en nuestras vidas personales como
profesionales, genera una serie de mecanismos de defensa, los cuales en ningún mo-
mento deben ser subestimados. Manejar el cambio significa: “subir a todos al barco
del cambio”. Sin olvidar que estamos a cargo del timón y debemos monitorear la di-
rección de dicho barco.

Coaching
El siguiente factor muy íntimamente ligado al manejo del cambio, es el coaching, es
decir, el estar “cerca” de las personas a quienes impactará el cambio. Proporcionar
coaching, significa escuchar y otorgar a las personas que forman parte de la organiza-
ción la oportunidad de expresar las opiniones que soportan sus decisiones; aclarar sus
dudas de manera oportuna y acompañarlos en el proceso de cambio que un programa
de mejora implica. La ausencia del coaching puede provocarnos problemas, desde una
práctica errónea que más tarde puede ser diseminada, una formación inapropiada que
resulta en la generación de resistencia, hasta la pérdida de interés por sentimiento de
ausencia de un guía.

Enfoque
Un elemento más, y no menos importante, es el enfoque, para entender un poco mejor,
imaginemos la nitidez y claridad de la imagen que logramos cuando ajustamos unos
binoculares para ver a cierta distancia. En el contexto de un programa de mejora, el en-
foque se refiere a tener una perspectiva entendible y coherente tanto del mediano como
del largo plazo. Además significa tener claro qué objetivo perseguimos, cuáles son los
pasos definidos y mantenernos avanzando sin perderlo de vista, lo cual nos permitirá
identificar los momentos cuando se requiere hacer un ajuste, que de cualquier modo,
nos permita llegar al objetivo.

Avanzar sin un enfoque, es como caminar en un terreno desconocido, es como decir:

“quiero mejorar, pero no sé en qué”.

Finalmente quisiera recapitular y mencionar que un programa de mejora implica cam-

bios, además de una constante lucha contra el tiempo y los recursos, dado lo cual, vale
la pena tener en cuenta estos siete factores , que sin ser secuenciales, sí se encuentran
estrechamente ligados unos con otros. Nos ayudarán a soportar el proceso de imple-
mentación, y lo más importante, pueden ser los diferenciadores entre una simple im-
plantación de procesos y una implantación efectiva de procesos. ¡Mucho éxito!

www.sg.com.mx JUL-AGO 2007

 // PRÁCTICAS /* DISEÑO */

El Mariachi Orientado a Objetos

Entendiendo el diseño OO
Por Carlos “Fofo” Ordóñez

¿Cómo hacen los diseñadores de automóviles para construir un

auto compacto, que pueda ser conducido por una persona que
mide 1.60 de estatura, y un grandulón de 2.10? La respuesta es
sencilla: considerando al momento de diseñar, y antes de fabri-
car, los potenciales de cambio, tomando así las medidas per-
tinentes para crear una solución “flexible”: la palanquita que
recorre los asientos.

Cuando desarrollamos sistemas, todos nos hemos enfrentado a

esta constante de nuestra profesión: el cambio. Cambio de re- Figura 2. Mariachi con músicos bailarines.
querimientos, cambio de versiones, cambio de plataforma, etcé-
tera. Para combatirlo, tenemos que dedicar una buena parte del Al parecer nuestra solución ha sido suficientemente flexible
tiempo de análisis y diseño a la flexibilidad de nuestra solución, para adaptarse a los cambios, hasta que el cliente nos solicita
con el único objetivo de disminuir el riesgo y el costo que éste un nuevo músico: “hagamos una mezcla cultural, quiero escu-
implica, para tener un cliente satisfecho con menos dinero. char un Mariachi con batería”. Inmediatamente pasa por nuestra
mente agregar una nueva clase: Baterista (véase figura 3).
El Mariachi orientado a objetos es un divertido ejemplo de cómo
lidiar con los cambios de requerimientos al diseñar clases flexi-
bles, utilizando el patrón de estrategias para diseño orientado
a objetos.

Cantemos con Mariachi

Supongamos que tenemos un cliente extranjero cuya pasión
musical es desmesurada, y nos ha pedido desarrollar una apli-
cación que simule la forma de hacer música de un Mariachi, sólo
desea integrar un guitarrista, un violinista y un trompetista a la
simulación, dado que todos tocan música de diferentes formas y Figura 3. Mariachi con Baterista.
tienen un canto característico, la mayoría comenzaríamos plan-
teando un diagrama de clases similar al mostrado en la figura 1. El problema es claro: “Bateristas Bailarines”. Esto lo podemos
resolver de una forma muy sencilla, sobrescribiendo el método
bailar en Baterista de tal forma que no baile:

public void bailar() {

// hacer nada …
}

Evidentemente, después de este cambio, estamos violando el

Figura 1. Primer acercamiento a la solución.
Nuestro cliente quedó satisfecho con la solución, mas sin embargo,
al ver que los integrantes del Mariachi pueden bailar, no esperó mu-
cho para solicitar un cambio de requerimientos: “Ahora quiero Ma-
riachis bailarines”. Nuestro equipo de diseño reacciona rápidamente
y agrega el método bailar a la clase Músico. (Véase figura 2).
principio de sustitución de Liskov, el cual indica que “debe ser
posible utilizar cualquier objeto instancia de una subclase, en el
lugar de cualquier objeto instancia de su superclase sin que la
semántica del programa escrito en los términos de la superclase
se vea afectado”. En nuestro caso, esto significaría que no será
posible reemplazar semánticamente a cualquier Músico por un
Baterista, pues el último limita la funcionalidad del primero.
Días mas tarde y aún sin resolver el problema del Baterista, recibimos

40 JUL-AGO 2007 www.sg.com.mx

una nueva petición de nuestro cliente: “¿Cómo podemos agregar un cantante de Ópera a nues-
tra simulación?”. La figura 4 indica otro “parche” más para satisfacer este requerimiento.

Figura 4. Mariachi con cantante de opera

La solución parece suficiente. No obstante, nos damos cuenta que estamos en un gran
aprieto: Cantantes de Ópera que cantan como Mariachi… ¡Ah, y bailan!

Hasta ahora no hemos tenido éxito entre clases rígidas y malos diseños, lo que defini-
tivamente nos convierte en presa fácil de un exceso de presupuesto. Es entonces que
uno de los diseñadores sugiere: “intentémoslo con interfaces”.

La figura 5 muestra una solución utilizando interfaces.

Figura 5. Mariachi usando interfaces

www.sg.com.mx JUL-AGO 2007

 // PRÁCTICAS /* DISEÑO */

Esta solución parece correcta. Incluso hasta el trompetista ha deja-
do de cantar, para dedicarse únicamente a tocar música y bailar.
Sin embargo, este diseño tiene un problema muy grave: “reutili-
zación de código”. Cuando volteamos y vemos que los métodos
bailar, tocar música y cantar tienen que ser implementados por
las clases concretas, estamos en aprietos.
de estrategias para cada método con alto potencial de cambio. Para
cada una de estas estrategias se construye una interfaz o clase
abstracta que define qué es lo que hacen cada uno de los conjun-
tos de algoritmos, y aplicando el patrón de estrategias obtenemos
el resultado en la figura 7.

Patrón de estrategia
Es en estos momentos, donde el patrón de diseño denominado
“Estrategia” llega a nuestro rescate. Este es uno de los patrones
descritos en el libro “Gang of Four”, que como sabemos, es la
biblia de los patrones de diseño orientado a objetos. De acuerdo
con esto, el patrón estrategia: “Define una familia de algoritmos
encapsulados y los hace intercambiables (…) permite al algorit-
mo cambiar, independientemente del cliente que lo utiliza”

En concreto, el patrón de estrategia nos permite construir una co-

lección de comportamientos intercambiables, independientemente
de quién haga cantar al Mariachi. La figura 6 muestra la estructura
de una solución genérica utilizando el patrón de estrategia.

Figura 7. Mariachi utilizando el patrón de estrategia

Conclusión
Después de darle muchas vueltas a este problema,
llegamos a una solución que cumple los requerimientos, y
además explota las ventajas de la orientación a objetos.

Figura 6. Solución propuesta por el patrón de estrategia
Lo que tenemos que hacer entonces es encontrar cuáles son los po-
tenciales de cambio, es decir, cuáles clases y/o comportamientos
tienen una gran probabilidad de ser modificadas y aislar los cambios
de las demás clases, y al mismo tiempo, explotar el polimorfismo
agregando una clase abstracta o una interfaz para cubrir las diferen-
tes estrategias.
Siguiendo este consejo, se detecta que el comportamiento de los mú-
sicos es el que tiende a cambiar, entonces se decide crear un conjunto
Esta solución es mejor, pues si se desea agregar un nuevo
músico, sólo es necesario heredar de músico y en el con-
structor, enviar como parámetro sus comportamientos. De
esta forma, nuestro diseño queda abierto para extensión,
pero cerrado para modificación y lo mejor de todo, si en un
momento dado, se requiere cambiar el comportamiento de
hacer Música, sólo creamos un nuevo comportamiento: Can-
tar Como Gloria Trevi, y lo asignamos al músico en cuestión,
e incluso lo podemos hacer en tiempo de ejecución, y listo,
ahora tenemos un Mariachi que canta de pelo suelto.

Carlos “Fofo” Ordóñez es Ingeniero en Sistemas Computacionales por el ITESO. Actualmente labora como arquitecto de software en Vision Consulting
Occidente, ubicada en el Centro de Software de Guadalajara. Colabora como profesor de asignatura en el ITESO, donde imparte materias de Progra-
mació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 Vision Consulting o
ITESO. fofo@iteso.mx

42 JUL-AGO 2007 www.sg.com.mx

 /*TENDENCIAS EN SW*/
Web 2.x y Web 3.x
Un nuevo camino por recorrer
Luis Daniel Soto es director de Divulgación Tecnológica para América Latina en Microsoft. Entre sus funciones actuales están la de admi-
nistración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Es jurado del “Gran Orden del
Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Ganó el primer lugar en el concurso
nacional para software de exportación en 1989. blogs.msdn.com/luisdans
En un inicio, el Web 2.0 era sinónimo del “Web semántico”, con
contenido altamente definido. Sin embargo, esto ha ido cam-
biando, y actualmente la etiqueta de “Web 2.0” puede referirse a
una o más de las siguientes características:
• El web de lectura-escritura.
• Sitios que facilitan la colaboración o creación colectiva.
• Sitios con una interfaz de usuario visualmente rica, y altamen-
te interactiva, a través de tecnologías como Silverlight y Flex, o
incluso el web tridimensional (www.web3d.org).
• El web como plataforma para crear aplicaciones. Con esto me re-
fiero a servicios web que permiten crear composición de páginas
y “mashup”. Algunos de los ejemplos para esto son Yahoo Pipes
(pipes.yahoo.com) , Dapper (dapper.net), Teqlo (www.teqlo.com),
y Microsoft Popfly (www.popfly.com), el cual se muestra en la si-
guiente figura.
Figura 1. Usando Popfly para crear un mashup.
Las palabras clave, tecnologías y “buzz words” asociados proli-
feran, incluyendo RSS, Wiki, SaaS, Ajax, Folksonomies y muchas
otras. El proceso por definir “niveles” dentro de Web 2.0 conti-
nua, y ante ello yo me atrevería a llamar estos diferentes niveles
como “Web 2.x”.
www.sg.com.mx
// COLUMNA
El debate de Web 3.x
Hay quienes ya se atreven a hablar sobre un Web 3.x. Las espe-
culaciones de lo que el futuro depara son ya abundantes, pero
hay elementos que parecen ser ineludibles. Entre ellos, destaco
los siguientes:
• La transformación del “web en una base de datos” o la “web
del sentido común”. Hoy, las búsquedas en un altísimo por-
centaje no conducen al usuario a responder preguntas. Aquí
algunas normas del “Web semántico” y otras como SPARQL
(www.w3.org/TR/rdf-sparql-query/) seguramente serán rele-
vantes, en conjunto con inteligencia artificial que permita com-
prender intenciones y agentes en Internet.
• La convergencia de información personal: perfiles de usuario,
historias de navegación realizada, análisis de calendarios y con-
tenido de correo electrónico. Todo esto es explotable para dirigir
y personalizar la publicidad y mercadotecnia en línea.
• La mayor velocidad de acceso a Internet. ¿Qué se podrá hacer
con anchos de banda 10 a 100 veces más veloces que las mejores
conexiones de hoy? Todavía no lo sabemos, pero definitivamente
será mucho más que la composición de videos en tiempo real.
Incluso hay quienes se han atrevido a pronosticar el fin de las
laptops, dado que el 100% de la información personal podrá re-
sidir en Internet.
• La democratización y proliferación del acceso. El porcentaje de la
población mundial que actualmente tiene acceso al Internet es de
tan solo el 17.2% (www.internetworldstats.com/stats.htm). Esto
nos indica que la mayor oportunidad definitivamente está por venir,
así como la definición de mecanismos para alcanzar a más gente.
• Hablando de lo que sucedería hacia el interior de las organiza-
ciones, algo que se espera es el “remix” real entre aplicaciones
y datos de misión crítica. Otro escenario es el de la habilitación
total del auto-servicio, así como el ensamble dinámico y en tiem-
po real de cadenas de suministro.
El Web 3.0 no será solo una plataforma, posiblemente el sistema
operativo mismo del futuro. El camino por recorrer nuevamente
es extenso…
—Luis Daniel Soto
Referencias adicionales:
• dsiegel.blogs.com/thoughts/2007/05/defining_web_30.html
• en.wikipedia.org/wiki/Web_3.0
JUL-AGO 2007 43
 // UML

Procesos Basados en UML

MANTENLO SIMPLE
Por Sergio Orozco

¡Estoy harto de los procesos y estándares de desarrollo! Ese suele
ser el grito desesperado de muchos responsables de organizacio-
nes de software que han intentado formalizar sus procesos con re-
sultados poco eficientes.
Y no es para menos, pues muchas veces la experiencia de los “gu-
rús” que los asesoran en la mejora de sus procesos se reduce a lo
que aprendieron en libros o cursos y no a la realidad de los pro-
yectos. No es un secreto que no necesariamente lo que dicen los
libros es lo que aplica para todas las organizaciones.
El caso de UML entra en esta categoría de estándares incomprendi-
dos. Y es que intentar usar todo UML, simplemente porque apren-
diste cuáles son los diagramas que lo conforman, no es precisa-
mente el camino que te llevará a obtener los mejores resultados.
Recuerda que UML no es el proceso, sino que es una notación que
puedes utilizar parcial o totalmente en tu proceso.
Proceso A. El Más Simple: Requerimientos, el Principio de Todo
Si actualmente tu proceso consiste en entrevistar a tus usuarios
y con base en dicha información comienzas a programar de inme-
diato, entonces mi recomendación es que por lo menos agregues
casos de uso a tu proceso (diagramas y especificaciones de ca-
sos de uso).
Básate en estos para planear, para repartir el trabajo, para cotizar,
para desarrollar, así como para diseñar tus pruebas. Verás que este
simple cambio será un cambio drástico y sumamente beneficioso
en los resultados de tus proyectos.

Selección de Artefactos
La experiencia nos ha demostrado que muchas veces es necesario
seleccionar un mínimo indispensable de artefactos a desarrollar
durante un proyecto. Los clientes quieren calidad, pero también Figura 1. Proceso simplificado al máximo.
necesitan eficiencia. Los recursos son limitados, y sabemos que un
proceso mal utilizado puede traer resultados contraproducentes en Proceso B. El Sencillo: Requerimientos y Diseño.
este sentido. Si estás un poco menos limitado de tiempo (y de motivación) como
El mal uso de UML puede ser una causa para esta frustración por para formalizar un poco más las tareas de tu proyecto entonces
parte de los desarrolladores y un motivo de decepción en el uso aprovecha los beneficios de otro artefacto básico de UML: el
de procesos formales. Así que muchas veces conviene aplicar la diagrama de clases.
filosofía de KISS (“Keep it Simple, Stupid” o “Keep it Short and
Simple”).
Si vas a usar un diagrama de UML asegúrate de obtener un beneficio
en tu proyecto, o mejor no lo uses. Y si tienes una limitante importante
de tiempos y recursos, es mejor que elijas el mínimo indispensable
para poder obtener beneficios de un estándar, pero sin agregarle cos- Figura 2. Proceso sencillo
tos que no puedes absorber por las restricciones del proyecto.
A continuación intentaremos esquematizar diferentes variantes de Si puedes utilizarlo con un enfoque de análisis primero (modelo de
procesos, en cuanto a la selección de artefactos de UML que utili- dominio) y después refinarlo para convertirlo en tu modelo de dise-
zan, desde uno muy simple hasta otro medianamente elaborado. ño, sería ideal. De esta forma obtendrás beneficios al tratar de com-
Imagina que tu forma de desarrollar consiste en entrevistarte con prender los requerimientos y el dominio, así como en las decisiones
el usuario y después programar; actividades elementales que no respecto a cómo construir una aplicación orientada a objetos.
podrían desaparecer. La pregunta que trataré de responder es: Pero, si consideras que no tienes tiempo de usarlo con los dos enfo-
¿qué agrego (de UML) en medio de esas dos actividades? ques mencionados entonces por lo menos úsalo para realizar el di-

Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa
especializada en capacitación práctica y consultoría en UML, CMMI y orientación a objetos. Milestone Consulting es la primer empresa mexicana miem-
bro de la OMG. info@milestone.com.mx www.milestone.com.mx

44 JUL-AGO 2007 www.sg.com.mx

 “El mal uso de UML puede ser una causa
de frustración por parte de los
desarrolladores y un motivo de decepción
en el uso de procesos formales ”.
seño de tu aplicación. Considera que no necesariamente tienes que
desarrollar el diagrama de clases completo antes de comenzar con la
programación, seguramente identificarás nuevas clases al comenzar
con dicha actividad que podrás reflejar posteriormente en tu modelo.
Proceso C. El Intermedio: Requerimientos, Análisis y Diseño
El proceso anterior inicia el camino a la formalización en requerimien-
tos, análisis y diseño. Eso ya es ganancia para la mayoría de los equi-
pos de desarrollo, en los que el valor lo concentran exclusivamente en
la programación y no en el resto de las actividades del proyecto.
La siguiente recomendación para mejorar tu proceso consiste en refi-
nar tus actividades de análisis y diseño. Para lograrlo te recomiendo el
diagrama de secuencia (en su lugar puedes usar el de comunicación).
Una vez identificado tu modelo de dominio, aprovéchalo y basán-
dote en los flujos de tus casos de uso modela las interacciones
entre las clases. Modelar las interacciones te permitirá tomar me-
jores decisiones de diseño. El beneficio será el desarrollo de una
mejor aplicación.
Una advertencia: no intentes desarrollar los diagramas de secuen-
cia para todos y cada uno de tus casos de uso.
En general considero que sólo es indispensable para aquellos ca-
sos de uso más críticos y complejos. Usa la regla del 20-80 y utilí-
zalo para modelar el 20% de tus casos de uso; los más complejos
e importantes. Si modelas las interacciones de todos tus casos de
uso tendrás que invertirle tiempo valioso que podrías estar aprove-
chando en otro tipo de actividades del proyecto.
Figura 3. Proceso intermedio
Casos Especiales: ¿Cómo es tu Sistema?
Los 3 ejemplos anteriores de procesos pueden ser suficientes para
muchos de los proyectos que suelen desarrollarse. Pero, adicional
a estos puedes agregar otro tipo de artefactos, dependiendo de las
características del proyecto.
Hazte preguntas como las siguientes: ¿Tu proyecto va a requerir
control de documentos o productos? ¿Es un sistema distribuído?
¿Estás automatizando un proceso de negocio complejo?
Dependiendo de estas condiciones es recomendable utilizar arte-
factos adicionales de UML que te darán una perspectiva diferente,
pero necesaria, para comprender mejor y tomar decisiones apro-
piadas para la construcción de tu proyecto.
A continuación se mencionan posibles artefactos de UML que po-
dría convenir agregar en condiciones especiales.
www.sg.com.mx
1. Sistemas de Control
Para cierto tipo de sistemas es bastante recomendable agregar el
diagrama de estados. Por ejemplo en aquellos sistemas en los que
tienes que controlar y monitorear el estado por el que va un cierto
documento o producto dentro del proceso de negocio que estás
automatizando o para aquellos sistemas de control que automati-
zan dispositivos electrónicos, como un refrigerador, un elevador o
un despachador automático de refrescos.
2. Sistemas Distribuidos
Si tu sistema va a construirse de manera distribuida, es decir, par-
te de la funcionalidad va a correr en una máquina y parte en otra.
O si estás pensando construir partes reutilizables, entonces te re-
comiendo que utilices el diagrama de componentes y el diagrama
de despliegue estos permitirán especificar dónde repartirás cada
“parte” del sistema. Estos diagramas corresponden a la discipli-
na de diseño.
3. Negocios Complejos
Si tu proyecto va a desarrollarse para automatizar un proceso
complejo de tu usuario, entonces te recomiendo que aproveches
los diagramas de actividades. En un caso muy sofisticado puedes
usar los diagramas de procesos de negocios del estándar BPMN,
pero asegúrate de aprender bien ese nuevo estándar antes de de-
cidir utilizarlo.
Buscando lo Simple en la Complejidad
UML ha ido evolucionando en algo que no necesariamente cumple,
a decir de algunos, con uno de los objetivos originales de dicho
estándar: el de mantener la simplicidad. Por lo tanto, es importante
comprender que no necesariamente aplican todos los artefactos y
elementos para tus proyectos para lograr la simplicidad en tu tra-
bajo al utilizar esta notación.
Este artículo no pretende de ninguna manera ser “La guía defini-
tiva”, pero estoy seguro que a algunas personas les facilitará el
trabajo a la hora de decidir respecto a la formalización de sus pro-
cesos de software, con respecto a la elección de los artefactos de
dicho estándar. De hecho hay otros artefactos de UML que no es-
tán considerados aquí, por corresponder a los menos utilizados.
Vale la pena notar que en este artículo ni siquiera estoy recomendan-
do un ciclo de vida; ya sea de cascada, iterativo, o cualquier otro. En
general, podrías utilizar cualquiera de los subconjuntos de artefactos
mencionados independientemente del ciclo de vida que utilices.
Espero que saques algún provecho de este artículo y recuerda que
“mucho no necesariamente significa mejor”. Hasta la próxima y
suerte con tus modelos.
JUL-AGO 2007 45
 // COLUMNA
Lean Software Development
Libera tus proyectos
por Emilio Osorio
Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde
1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones.
Ferviente entusiasta de la aplicación social de la tecnología, a ultimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estará
encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en oemilio@tecnonirvana.org
En los seminarios sobre métodos ágiles que
realizo, típicamente pregunto lo siguiente a la
audiencia: “Levante la mano por favor, aque-
lla persona a la cual un diagrama de Gantt le
haya sido la diferencia para sacar adelante
un proyecto, o que para darle mantenimien-
to al software de alguien más haya utilizado
documentación separada al mismo código,
o tal vez aquel líder de proyecto que le haya
funcionado asignar y controlar el avance de
microtareas por cada miembro del equipo,
para que así se comprometan más con una
fecha de entrega.
Sorprendentemente (o no tanto), hasta la fe-
cha nadie ha levantado la mano. Si todas es-
tas prácticas que son la quinta esencia de la
administración de proyectos, y para las cuáles
invertimos miles de pesos en herramientas y
cursos no funcionan, entonces ¿por qué lo se-
guimos haciendo?
Al parecer, pensamos que cuando algo no sale
bien lo que necesitamos es una capa más de
“control”, un proceso más definido y detallado
que “obligue” a los programadores rebeldes,
negligentes o apáticos, a tener “conformidad”
con el proceso mágico que resolverá todos
nuestros problemas. Anhelamos recetas se-
cretas, pero en realidad lo que necesitamos
es tan solo un conjunto sólido de principios y
sentido común.
¿Como liberar a nuestros proyectos de balas de
plata que no funcionan? Afortunados somos
de tener Lean Software Development (LSD) a
nuestro alcance; es libre, gratis y simplemente
funciona. LSD fue desarrollado por Mary y Tom
Poppendieck a partir de experiencias en 3M y
Toyota, y se basa en aplicar al desarrollo de
software los principios de “lean” que han he-
cho tan exitosas a estas empresas. Se le con-
sidera parte de los métodos ágiles, pero desde
mi punto de vista está por encima de ellos, ya
que LSD nos obliga a pensar, cuestionarnos y
encontrar nuestras propias respuestas.
46 JUL-AGO 2007
/*TIERRA LIBRE*/
LSD se basa en los siguientes 7 principios:
1. Eliminar el despilfarro. Es decir, evitar todo
lo que no agregue valor al proyecto. ¿Qué es
aquello que no agrega valor al proyecto? Sen-
cillo, todo lo que el cliente no pidió, pero en lo
que invertimos tiempo. En esta categoría entra
funcionalidad adicional a la que pidió el usua-
rio, o especificación de requerimientos dema-
siado detallada en etapas tempranas del ciclo
de vida. Aprendamos a ver éstas cosas como
un despilfarro.
2. Ampliar el aprendizaje. Debemos aceptar
que nunca se sabrá exactamente lo que se
tiene que construir al principio del proyecto.
Así que cualquier tiempo que ocupemos tra-
tando de hacer que el cliente nos “firme” el
requerimiento, rompe con el principio anterior.
Ampliar el aprendizaje significa aceptar que el
desarrollo es un proceso de aprendizaje, por
lo tanto tenemos que repetirlo muchas veces
para aprender. Solución: Muchas iteraciones
cortas, tan cortas como haga sentido.
3. Retrasar los compromisos. Cada vez que
aceptamos trabajar en un proyecto que tiene
fecha de entrega pero no tiene requerimientos
fijos es como si decidiéramos casarnos con
alguien que conocimos hoy mismo. Si no lo
hacemos en la vida real, entonces ¿por qué
hacerlo en nuestro trabajo? Las iteraciones
cortas ayudan a comprometernos con tan solo
lo que podemos estimar bien.
4. Liberar rápido. Todos hacemos desarrollo
por iteraciones, ¿verdad? Bueno, tener itera-
ciones no es lo mismo que liberar rápido. Libe-
rar rápido significa que si te piden un sistema
que facture, liberes “a producción” la funcio-
nalidad para facturar lo antes posible, aunque
no se haya terminado el resto del sistema. Em-
presas como Google o Yahoo entienden esto y
lo aplican en sus desarrollos. Libera funcionali-
dades, no sistemas.
5. Facultar al equipo. ¿Qué es lo mejor que
puede hacer un líder de proyecto? No estorbar.
Tenemos que confiar en que las personas pue-
den ponerse de acuerdo, trabajar en equipo y
en esencia autodirigirse. Si, cometerán erro-
res. Pero si liberan rápido y tienen iteraciones
cortas, entonces sus errores no nos costarán
caro, y sobre todo se ampliará el aprendizaje.
Si no pueden resolverlos por ellos mismos, en-
tonces debemos evaluar si tenemos el equipo
correcto. El trabajo en equipo ES el desarrollo
de software.
6. Construir integridad intrínseca: En Japón,
las mismas máquinas que producen las piezas
para manufactura, prueban las piezas que pro-
ducen, las miden y desechan las que no cum-
plen con los requisitos mínimos. No hay una
inspección o control de calidad separada de la
producción. Nuestros equipos nunca podrán
alcanzar madurez, en un esquema donde el
responsable de la calidad sea otro grupo se-
parado del de desarrollo.
7. Pensar en el todo. “O todos coludos, o todos
rabones” decían nuestros abuelos. Al parecer,
antes se entendía mucho cómo hacer que una
organización o una familia funcionara como un
equipo. Abandonemos el modelo de programa-
dor estrella, lo único que producimos son divas
y gangsters. En un equipo todos ganan y todos
pierden, así que olvidémonos de las mediciones
de desempeño individuales. Lo único que esto
provoca es que los que salgan bien se busquen
un trabajo donde les paguen más, y los que no
salgan tan bien, harán lo mismo. Creemos equi-
pos que compartan logros y fracasos y reducire-
mos la rotación de personal.
¿Por que hablo con tanta seguridad? Sencillo,
yo mismo he pasado de creer en cosas que
no funcionan y sufrir en mi trabajo, a experi-
mentar los frutos de LSD en mi propia prácti-
ca. Finalmente, les recomiendo que busquen
en Internet a Mary Poppiendick y agradecerán
como yo, todo el material gratuito que tiene a
nuestra disposición para ayudarnos a empe-
zar. Regalar sus libros a nuestros directores
de sistemas probablemente serán los pesos
mejor invertidos en mucho tiempo en nues-
tras carreras.
—Emilio Osorio
www.sg.com.mx
www.sg.com.mx JUL-AGO 2007
 // FUNDAMENTOS
Los Estándares de TI
¿Qué ofrecen a la Industria Mexicana de Software?
Por Juan Manuel Hernández Jiménez
Antecedentes
A principios de 1994, al entrar en vigor el TLC
con Estados Unidos y Canadá, México se in-
corporó de manera definitiva al proceso de
globalización de las economías que rigen al
mundo actual, las exigencias en materia de
calidad y productividad se volvieron más im-
portantes y apremiantes.
Siendo la normalización un reflejo del avan-
ce industrial de un país, es imposible basarla
en los principios rígidos establecidos super-
ficialmente que le resten la flexibilidad ne-
cesaria para adaptarse a las condiciones de
una determinada época, al avance tecnológi-
co o a la idiosincrasia de un país, así como a
su propio desarrollo. La experiencia ha per-
mitido establecer una serie de principios ge-
nerales que aplicados con el rigor necesario
no significan un obstáculo, sino una forma
para garantizar el éxito de la aplicación en el
contexto que se esté normalizando.
En este artículo plantearemos la importancia
de contar con estándares, y describiremos los
pasos necesarios para generar una norma.
Importancia de los estándares
La normalización o creación de estándares,
por ejemplo para las Tecnologías de la Infor-
mación, es una disciplina que trata sobre el
establecimiento, aplicación y adecuación de
reglas destinadas a conseguir y mantener un
orden dentro del campo de la producción de
software. El resultado de la normalización
surge de un balance técnico y socioeconó-
mico propio de una etapa, por lo cual no
se considera estático. Es una disciplina con
base técnica y científica que permite formu-
lar normas cuyo ámbito no se limita única-
mente al establecimiento de reglas, sino que
comprende también su aplicación.
De tal suerte que al generarse un nuevo
estándar (norma mexicana- NMX) se dice
que se está “haciendo industria” porque en
ese momento se generan los lineamientos
Ing. Juan Manuel Hernández Jiménez actualmente es el Gerente de la División de Verificación de Software de NYCE. Sus responsabilidades incluyen obte-
ner y mantener la acreditación de NYCE como organismo de verificación de procesos y de certificación de producto de software con base en los estándares
vigentes actuales, administrar las unidades de verificación y certificación, así como participar activamente en los comités técnicos de normalización en los
procesos de desarrollo de nuevos estándares mexicanos de TI.
48 JUL-AGO 2007
mínimos que determinado producto o ser-
vicio deben de cubrir para que se diga que
se esta cumpliendo con lo estipulado por la
misma industria.
Al día de hoy, existen 38 estándares ó normas
mexicanas vigentes en el ámbito de las TI, los
cuales definen las mejores prácticas acepta-
das para la mayoría de las áreas directamen-
te relacionadas con la terminología, produc-
ción, calidad y seguridad del software.
Proceso de generación de
una norma
Una norma es un documento establecido
por consenso y aprobado por un organismo
reconocido, que suministra, para uso común
y repetido, reglas, directrices o caracterís-
ticas para las actividades o sus resultados,
encaminados al logro del grado óptimo de
orden en un contexto dado. Para generar una
norma, se lleva a cabo un proceso basado
en la Ley Federal sobre Metrología y Norma-
lización, que resumiremos en 7 pasos, pero
no por esto se le debe restar importancia y
cierto grado de dificultad en los temas de es-
pecialización que ahí se tratan:
1. El organismo normalizador forma el Comité
Técnico especializado en la materia.
2. Se generan las invitaciones a los posibles
participantes indicándoles los temas a tra-
tar. Es importante mencionar que se busca
la participación de representantes de dife-
rentes entidades como: industria (empresas
privadas), universidades (v.gr. UNAM, IPN),
gobierno (v.gr. DGN, SE, SHCP), cámaras de
la industria (v.gr. CANIETI), y asociaciones
(v.gr. AMITI).
3. Una vez programadas las reuniones con los
diferentes representantes, incluyendo a toda
aquella persona que se considere necesaria
en la elaboración del estándar, se procede a
realizar las reuniones de trabajo necesarias,
hasta que el estándar esté concensuado
entre los sectores involucrados y quede for-
malizado poniendo al margen la rubrica de
todos los participantes. Por ejemplo, para
la generación de la NMX-I-059, se tomaron
como base los modelos MoProSoft y EvalPro-
Soft, se estructuraon en formato de norma, y
se concensuaron con los interesados.
4. El organismo envía el proyecto del están-
dar a publicar en el DOF mediante un “Aviso
de consulta pública” por un período de 60
días naturales.
5. Si dentro de éste período hay algún co-
mentario, se le envía formalmente al organis-
mo, quien lo somete a la consideración del
Comité Técnico para su aprobación.
6. Si no hay comentarios, una vez transcurri-
dos los 60 días naturales, el organismo envía
2 juegos impresos de la norma a la Dirección
General de Normas (DGN), dependiente de la
Secretaría de Economía.
7. La DGN publica entonces la “Declaratoria
de Vigencia” y 60 días naturales posteriores,
entra en vigencia, naciendo formalmente una
nueva norma mexicana.
¿Cómo se eligen los temas de
Normalización?
El organismo normalizador invita a los dife-
rentes sectores (industria, gobierno, etc.)
a proponer temas de normalización, y las
propuestas recibidas son incluidas en el Pro-
grama Nacional de Normalización, el cual se
somete a la consideración de la Comisión Na-
cional de Normalización, a fin de obtener su
aprobación. Una vez aprobado, se publica en
el Diario Oficial de la Federación (DOF) y se
procede a programar las reuniones de traba-
jo del Comité Técnico de Normalización.
Conclusión
Las normas se deben basar en los re-
sultados consolidados de la ciencia,
la tecnología y la experiencia, y sus
objetivos deben ser los beneficios
óptimos de la comunidad. Es funda-
mental para la industria de TI, gene-
rar estándares y seguir normas, que
le permitan “hacer industria”.
www.sg.com.mx
www.sg.com.mx JUL-AGO 2007
 // INFRAESTRUCTURA
Administración de la Capacidad
Planeando la Infraestructura
Por Ariel García
Hoy en día, todas las áreas responsables de la administración de
TI tienen el reto de incrementar su productividad y eficiencia, a la
par de reducir sus costos de operación e inversión. El proceso de
Administración de la Capacidad es uno de varios procesos de ITIL,
que define estándares para lograr la eficiencia y optimización de
costos en la entrega de servicios de TI.
Un poco de teoría
Por definición, el proceso de la administración de la capacidad
tiene como objetivo asegurar el óptimo uso de los recursos de TI,
de tal forma que se cumplan los niveles de rendimiento acordados
con los usuarios a un costo justificado. Además, debe proporcio-
nar información de los recursos actuales y planeados, así como la
utilización de los componentes. La administración de la capacidad
permite a la organización decidir acerca de cuáles componentes
debe actualizar, cuándo hacerlo y el costo involucrado.
Dentro del proceso de la administración de la capacidad podemos
encontrar las siguientes actividades:
• Administración de la demanda: se enfoca en el control y la influen-
cia de la demanda de servicios de TI.
• Dimensionamiento de la solución: generalmente se inicia con un
nuevo requerimiento de negocio, o un cambio considerable en la in-
fraestructura actual. Dura hasta que el nuevo requerimiento o cam-
bio entra en operación.
• Planeación de la capacidad: documenta los niveles reales de uti-
lización de los componentes de la infraestructura y el desempeño
de los servicios de TI.
• Almacenamiento de la base de datos de capacidad: documenta la
información de capacidad del negocio.
• Modelado: se realiza el modelado de la infraestructura de TI para
predecir su comportamiento bajo cambios en su volumen de trabajo.
• Actividades iterativas: análisis, ajuste, implementación y moni-
toreo. El monitoreo se debe establecer en todos los componentes
y para cada uno de los servicios. Los datos deben ser analizados
de tal forma que puedan compararse contra umbrales preestab-
lecidos. El resultado de los análisis generará reportes y ajustes a
ser implementados. Estos cambios después serán monitoreados.
Para ejecutar tales actividades, el proceso de la administración de la
capacidad se subdivide en tres subprocesos:
• Administración de la capacidad del negocio (ACN): tiene un en-
foque estratégico y consiste en asegurar la consideración, plane-
ación e implementación en un tiempo razonable de los futuros re-
50 JUL-AGO 2007
querimientos de servicio por parte del negocio.
• Administración de la capacidad de servicio (ACS): su enfoque
es táctico, y se ocupa de la administración de la operación real de
los servicios de TI acorde a los niveles de servicios acordados con
los usuarios.
• Administración de la capacidad de los recursos (ACR): su enfoque
es operacional y consiste en la administración de los componentes
individuales de la infraestructura de TI.
Las salidas del proceso de administración de la capacidad son: un
plan de capacidad, líneas base, perfiles, reportes de capacidad, um-
brales y alarmas tanto para servicios como componentes. También
se realizan recomendaciones en acuerdos de servicios, cambios pro-
activos, mejoras a servicios y componentes, y reportes de auditoria,
entre otros. El plan de capacidad es posiblemente el más importante
de estos productos de salida. Dentro de su contenido destaca el re-
sumen de los servicios, capacidades y costos de la infraestructura.
El plan debe indicar claramente cualquier suposición efectuada, así
como cualquier recomendación cuantificada en términos de recur-
sos requeridos, costos, beneficios e impacto.
Aterrizándolo un poco
Ya echamos un vistazo teórico a la estructura del proceso de adminis-
tración de capacidad. Ahora vamos a aterrizarlo en ejemplo sencillo de
infraestructura de servidores. Como sabemos, es muy común para el
área de TI administrar el desempeño de sus servicios de forma reaccio-
naria, analizando y resolviendo los problemas conforme los usuarios
los reportan. A través de la ejecución del proceso de administración de
la capacidad, lo que nosotros buscamos es llegar al escenario donde
los administradores del sistema sean capaces de evitar cuellos de
botella en el desempeño de los servicios y, utilizando las herramientas
adecuadas, predecir cómo los servidores deberán configurarse para
soportar cargas adicionales de trabajo en el futuro.
Los pasos que llevaremos a cabo para esto son los siguientes:
1. Determinar los niveles de servicio
El primer paso en el proceso es categorizar el trabajo de los siste-
mas y cuantificar las expectativas de los usuarios en cómo se debe
realizar este trabajo. Para poder realizarlo es necesario entender el
concepto de cargas de trabajo. Con este concepto se busca visualizar
el desempeño de un sistema en términos de negocio, en lugar de
términos técnicos. Antes de definir los niveles de servicio, es necesa-
rio determinar las métricas para medir el trabajo a soportar. Una vez
definidas, se establecen los requerimientos de niveles de servicio,
en otras palabras: el desempeño prometido por el área de TI.
www.sg.com.mx
Cargas de trabajo. Desde la perspectiva de la administración de la
capacidad, un sistema de cómputo procesa cargas de trabajo y en-
trega un servicio a los usuarios. Como primeros pasos del proceso
de planeación de la capacidad, se deben identificar estas cargas de
trabajo y en base a ello, definir un servicio satisfactorio desde la per-
spectiva del usuario.
Unidades de trabajo. A fin de medir las cargas de trabajo, es necesa-
rio establecer unidades de trabajo. Ésta es una métrica de la cantidad
de trabajo realizado, contrario a la cantidad de recursos necesarios
para completar el trabajo. En este ejemplo en específico, los recur-
sos necesarios son procesadores, almacenamiento en disco, memo-
ria, ancho de banda de red, etcétera. La medición de los recursos an-
tes mencionados es importante, pero no sirven para cuantificar las
cargas de trabajo o para definir las unidades de trabajo. Por ejemplo:
para una carga de trabajo en línea, una unidad de trabajo puede ser
una transacción. Para una carga de trabajo interactiva o por batch, la
unidad de trabajo puede llegar a ser un proceso.
Establecimiento de niveles de servicio. Una vez definidas las uni-
dades de trabajo, procedemos a establecer un acuerdo de nivel
de servicio. Dicho acuerdo se da entre el área de TI y el área usu-
aria para definir el nivel aceptable del servicio. El nivel aceptable
se define típicamente desde la perspectiva del usuario, en tér-
minos de tiempo o unidades de trabajo. Idealmente, los niveles
de servicio deberán ser determinados por los requerimientos del
negocio. En la vida real, comúnmente se definen por experiencias
del pasado, por ejemplo: “que el tiempo de respuesta del servicio
sea como mínimo al tiempo registrado actualmente, aun cuando
se llegue a incrementar la carga de trabajo”. En la medida que se
pueda predecir o conocer la carga de trabajo, se podrá mantener
el nivel de servicio requerido. Para poder definir los niveles de
servicio, es necesario conocer la capacidad de respuesta de la
infraestructura actual.
2. Análisis de la capacidad actual
Una vez determinados los niveles de servicio, lo siguiente es analizar
la capacidad actual de los sistemas para determinar si están cum-
pliendo con las expectativas de los usuarios, y en base a esto, hacer
recomendaciones.
Los pasos para realizar el análisis de la capacidad actual son:
• Realizar una comparación de las mediciones de los elementos ref-
erenciados en los acuerdos de niveles de servicio, contra los obje-
tivos especificados. Esto proveerá información básica para definir
www.sg.com.mx
si el sistema es adecuado para soportar la capacidad requerida. Se
establecen líneas base, umbrales y alarmas.
• Ejecutar mediciones en los recursos del sistema (procesadores,
memoria, discos, red, etcétera). El análisis de estas mediciones per-
mitirá detectar recursos sobrecargados que podrían provocar prob-
lemas en el presente o futuro.
• Identificar los recursos demandados para cada una de las cargas
de trabajo existentes. Esto permite detectar y enfocar la atención
en las cargas de trabajo que realizan la mayor demanda de recur-
sos del sistema.
• Una vez identificadas las cargas de trabajo, se debe realizar un
análisis de los tiempos de respuesta de cada uno de sus componen-
tes, a fin de determinar cuáles son los recursos con mayor impacto
en el tiempo de respuesta.
3. Planeación para el futuro
Una pregunta muy común es: ¿cómo asegurar que el próximo año
los sistemas no se encuentren sobrecargados y el presupuesto del
área por los cielos? La mejor forma de mitigar tal riesgo, es con
un plan de capacidad basado en pronósticos de procesamiento re-
querido. Lo que debemos hacer es obtener un pronóstico de los
requerimientos del negocio para con los sistemas de TI en el fu-
turo. Esta información se debe registrar en forma de incrementos
de cargas de trabajo, que a su vez se traducirá en una demanda de
mayores recursos del sistema. En base a modelados o prototipos
de estas nuevas cargas, se definirá la configuración de la infrae-
structura necesaria para soportarlas.
Conclusión
A través de la ejecución de los pasos anteriores, es posible reali-
zar un plan de capacidad para soportar los niveles de servicios
requeridos por el negocio en el presente y el futuro. Se contará
con la información necesaria para realizar un presupuesto funda-
mentado con requerimientos del negocio y garantizar un servicio
adecuado a los usuarios, sin necesidad de aprovisionar de más.
Resultaría imposible poder entregar en este artículo un nivel
más detallado del trabajo, actividades y procesos involucrados
en la administración de la capacidad. El objetivo simplemente es
resaltar la utilidad de la implementación de dichos procesos. En
América Latina existe una enorme área de oportunidad para la
adopción de estas prácticas, que se traduciría en empresas más
competitivas con mayor valor agregado para sus clientes.
JUL-AGO 2007 51
 TECNOLOGÍA
////TECNOLOGÍA /* GADGETS */

SaWestern Digital
Caviar SE16 750GB
Pensado especialmente para computadoras de escritorio que utilizan aplicaciones con
muchos datos, computación de alto desempeño y sistemas multimedia, el Caviar es una uni-
dad de disco duro interno de gran capacidad que ofrece un índice de transferencia de 3GB
por segundo, cache de 16MB y cola de instrucciones nativas. Incluye la tecnología propietar-
ia de Western Digital, SecurePak que estaciona las cabezas grabadoras fuera de la superficie
del disco mientras gira hacia arriba y hacia abajo cuando la unidad no está operando, de tal
manera que se reduce el desgaste. Por otra parte, con StableTrac se minimiza la vibración
inducida por el sistema y estabiliza el plato para un mejor rastreo durante operaciones de
lectura y escritura. Además ahorra en consumo de energía.

Samsung
B-jack i321n
Black Jack es un smartphone lanzado recientemente bajo el concepto de “oficina móvil”, que cuenta con Win-
dows Mobile 5.0 para ofrecer al usuario potentes aplicaciones de negocios, así como acceso a diversas cuen-
tas de correo electrónico a través de Outlook Mobile. Soporta una extensa variedad de formatos multimedia,
funciones de entretenimiento y comunicación instantánea permitiendo reproducir y almacenar fotografías,
música y videos gracias al Windows Media Player. Entre sus características destacan su diseño ultradelagado;
cámara fotográfica de 1.3 megapixeles, puerto infrarrojo, ranura para memoria, visores de archivos adjuntos
de e-mail (.doc, .xls, .ppt, .pdf .wmf ); agenda, alarma, altavoz integrado, aplicaciones Java; conexión inalám-
brica Bluetooth con gran capacidad de transmisión y recepción de datos que permite conectarse con otros dis-
positivos tales como PDA o computadoras portátiles que se encuentren a una distancia máxima de 10 metros;
y memoria interna de 64MB.

Kilo
Taza personalizada
Definitivamente este no es un dispositivo de alta tecnología, pero no por eso es menos útil. Esta
taza está diseñada para que nadie en la oficina te la robe, ya que queda personalizada con tu
nombre, apodo o gráfico de tu preferencia. Solo necesitas pintar con un plumón indeleble sobre
el recuadro blanco. Esta taza es invención de uno de los diseñadores de SG, y puedes adquirir
la tuya en www.kilo.com.mx

Viewsonic
PJ258D
Incorporando la innovadora tecnología ViewDock hacia otra línea de productos,
nace el primer proyector DLP multifuncional de alta definición con base para
iPod: el PJ258D ofrece nuevas opciones de entretenimiento gracias a la opción
de portabilidad de exhibición para llevar contenidos visuales sin necesidad
de una computadora. Pesa alrededor de 2 kilos; su diseño es versátil y fácil de
usar. La estación base conecta al iPod directamente al proyector para disfrutar
de su contenido, mientras recarga la batería. Este equipo además, soporta otros
medios digitales a través de múltiples opciones de conectividad como video VGA,
haciéndolo compatible con PCs, reproductores de DVD y consolas de videojuegos.
Tiene resolución XGA de 1024X768, 2 mil lúmenes y una proporción de contraste 2000:1,
para una reproducción clara de fotografías y video sin importar el ambiente.

52 JUL-AGO 2007 www.sg.com.mx

 SanDisk
MicroSDCH
Las tarjetas de memoria flash no sólo son cada vez más pequeñas, sino también
más poderosas y ahora son perfectas para dispositivos móviles tales como teléfonos
celulares. Con capacidades de 6GB y 8GB las microSDHC son ideales para todos los gad-
gets con innumerables funciones multimedia que integran teléfono, reproductor de música
y video, cámaras digitales, entre otros; ya que permiten almacenar, por ejemplo en la de 8GB
alrededor de 2 mil canciones, 5 mil fotos en alta resolución o hasta cinco horas de video MPEG4.
Son compatibles con cualquier dispositivo que cuente con ranura para tarjeta micro.

IBM Greenpeace
Power6 Green Electronics Guide
IBM lanzó el microprocesa- Greenpeace genera un reporte trimestral donde califica a
dor de doble core POWER los principales proveedores de computadoras y electróni-
6, que con sus 4.7 GHz du- cos en base a sus políticas y prácticas para eliminar quí-
plica la velocidad de su pre- micos dañinos, así como hacerse responsable de sus pro-
decesor, el POWER 5, pero ductos una vez que termina su vida útil. En la edición más
utilizando prácticamente la reciente de este ranking (junio 2007), Nokia fue la compa-
misma cantidad de energía. ñía considerada “más verde”, mientras que Sony tuvo el
deshonroso último lugar.
La nueva línea de servido-
res IBM System p 570 hace
uso de l POWER 6, y hasta
el momento ha logrado con-
seguir 25 diferentes records
de evaluación de desempe-
ño, además de ser el primer sistema que obtiene el primer
lugar en las categorías de: capacidad de procesamiento de
transacciones, tasa de transferencia de cálculo con ente-
ros, tasa de transferencia de cálculos con punto flotante, y
rendimiento de Java en operaciones por segundo

Logitech
X-530
Es común que las bocinas integradas totales, un moderno subwoofer que
de una computadora no brinden la regula automáticamente los sonidos
calidad de sonido que el usuario graves sin distorsión al producir
desea, por tal razón Logitech más movimiento de aire y lograr
ofrece el sistema X-530 que mayor profundidad. Cinco bocinas
se puede conectar, además, a satélite de montaje giratorio para
cualquier reproductor de CD, pared con tecnología FDD2 que
DVD, MP3; PlayStation o Xbox. elimina irregularidades, brindan-
Entre sus características des- do nitidez, uniformidad y balance
tacan sus 70 watts de potencia perfecto de audio.

www.sg.com.mx JUL-AGO 2007 53

 // REFERENCIA
Business Service Management
¿Qué es y cómo llegar?
Por Ricardo Rodríguez Bernal
En su búsqueda por mejorar la calidad de los
servicios que proveen al negocio, las organi-
zaciones de TI están cambiando su enfoque
para poder reflejar un mayor valor al nego-
cio. Una de las estrategias más recurridas
para lograr esto, es la de Business Service
Management (BSM).
Forrester Research define BSM como una
estrategia para “alinear la infraestructura
de TI, con servicios de TI alineados al ne-
gocio”. BSM está basado en el concepto
de una vista compartida a través de todas
las áreas de TI que permita saber cómo los
recursos de TI soportan directamente al
negocio. Existen diversos proveedores de
software y servicios BSM, y ésta es un área
que está mostrando mucho crecimiento en
los últimos meses, ya que a fin de cuentas
está fuertemente relacionada con prácticas
como ITIL y COBIT.
Existe una gran diversidad de proveedores
de software y servicios para BSM, y cada uno
sugiere una estrategia o “roadmap” para
implementarlo. BMC Software sugiere una
implementación de BSM basada en 8 disci-
plinas denominadas “Rutas de Valor”. Eva-
luando la madurez que tiene la organización
en cada una de estas 8 disciplinas, se puede
construir un mapa que ayude a reforzar las
necesidades de TI y del negocio. A continua-
ción explico estas rutas de valor y los proble-
mas con los que lidia cada una.
Gestión y Descubrimiento
de Activos
Los activos de TI representan una fuerte in-
versión, así como costos de operación recu-
rrentes derivados de soporte y renovación
de licencias. Uno de los requerimientos prin-
cipales de la alineación de TI con el negocio
consiste en el rastreo y gestión de los activos
de TI para lograr eficiencias en costos y de-
mostrar que estén generando un retorno de
inversión. La gestión de activos permite eva-
luar y reasignar recursos de TI de forma efi-
ciente en base a cambios en las necesidades
del negocio.
Ricardo Rodríguez Bernal es Arquitecto de Soluciones de Business Service Management en BMC Software México
54 JUL-AGO 2007
Gestión y Aprovisionamiento de
Capacidad
La gestión de la capacidad se encarga de ase-
gurar que las aplicaciones existentes cumplan
con los requerimientos de los usuarios en
términos de tiempos de respuesta y volumen
de transacciones soportadas. El aprovisiona-
miento de capacidad se preocupa por empa-
tar el uso con las necesidades de recursos de
TI de forma que no exista desperdicio.
Gestión de la Configuración y
el Cambio
Los cambios no controlados o no probados
adecuadamente son una de las principales
causas de fallas y “caídas” en sistemas de pro-
ducción. Una buena gestión del cambio y con-
figuración contribuye a reducir los costos de
soporte significativamente, y disminuye la fre-
cuencia de fallas en sistemas de producción.
Gestión de la Identidad
El principal valor de la gestión de identidad
es asegurar el uso autorizado y protegido
de los activos y procesos de negocio. Esta
seguridad se basa en la capacidad de saber
quién es un usuario en particular, a que ac-
tivos de TI tiene acceso, y qué nivel de uso
puede tener.
Gestión de Incidentes y
Problemas
Los incidentes de TI tales como fallas en sis-
temas de misión crítica tienen un fuerte im-
pacto en el negocio. Una gestión efectiva de
los incidentes maneja a estos de forma pre-
ventiva, más que correctiva, implementando
mecanismos para detectar y resolver anor-
malidades, antes de que se conviertan en un
problema que impacte el negocio.
Gestión de Infraestructura y
Aplicaciones
Se preocupa por administrar y controlar
todas las aplicaciones y componentes de
infraestructura de la organización desde
una perspectiva de servicios de negocio.
De esta forma, asegura que los recursos
estén enfocados en la optimización del ren-
dimiento y la disponibilidad de los actuales
servicios de negocio.
Gestión del Impacto en Servicios
Refleja el impacto en los servicios de nego-
cio provocado por las condiciones o cambios
de estatus en la infraestructura de TI. Se
enfoca en conectar el estatus de un servicio
de negocio con el estatus de los recursos de
TI relacionados. Esto permite mostrar clara-
mente el impacto al negocio que tiene algún
evento de TI.
Gestión de los Niveles de Servicio
Un aspecto fundamental de la operación del
negocio es la capacidad de establecer ob-
jetivos de nivel de servicio y cumplir dichos
acuerdos. Desde la perspectiva del negocio,
los objetivos de nivel de servicio son, como
su nombre lo dice, una medida de qué tantas
operaciones de negocio se pueden realizar en
determinado tiempo.
Referencias
• Tim Grieser. “Implementing Business Ser-
vice Management: BMC Software’s Routes to
Value Approach”. IDC, Enero 2005.
• Peter O’Neill. “BSM is Coming of Age: Time
to Define What it is”. Forrester Research, Fe-
brero 2006.
Conclusión
Implementando BSM, las organiza-
ciones de TI pueden entender las
relaciones críticas entre el negocio
y los servicios de TI, así como detec-
tar los cambios y darle prioridad a la
administración de los componentes
de la infraestructura de TI basados
en las métricas y requerimientos
del negocio. Entender estas relacio-
nes, y darle la prioridad adecuada a
distintas situaciones, puede ser de
gran ayuda al negocio para operar
de forma más efectiva, reduciendo
costos e incrementando la satisfac-
ción del cliente.
www.sg.com.mx
 INDEX

DIRECTORIO Anunciante Páginas Sitio

Avantare 13 www.avantare.com
CIAPEM 9 www.ciapem.veracruz.gob.mx
e-Quallity 39 www.e-quallity.net
Gartner 47 www.gartner.com
IDC 49 www.idc-eventos.com
Innevo 35 www.innevo.com
Intersoftware F3 www.intersoftware.com.mx
Itera 41 www.itera.com.mx
Milestone Consulting F4 www.milestone.com.mx
NYCE 31 www.nyce.com.mx
SafeNet 11 www.safenet-inc.com
SG’07 F2-1 www.sg.com.mx/sg07

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

www.sg.com.mx JUL-AGO 2007 55

 TECNOLOGÍA
////BIBLIOTECA

Code Quality: The Open Source Perspective

Diomidis Spinellis

01
Addison Wesley, 2006 quien ha trabajado directa o in-
En un mundo donde la mayoría de las discusio- directamente con los conceptos
nes sobre calidad de software están enfocadas en de este libro desde 1985, escri-
administración y otros temas de alto nivel, Diomidis Spinellis biendo y manteniendo mas de
nos invita a analizar este tema partiendo de una perspectiva 250,000 líneas de código para
diferente, calidad del código. En lugar de explicar cómo resolver numerosos proyectos comercia-
proyectos complejos, este libro describe cómo juzgar la calidad les y de software libre.
de lo que estás viendo: código. Code Quality es la continuación
al libro previo escrito por Spine-
Basado en el estándar de calidad ISO 9126, Spinellis descompo- llis titulado “Code Reader”, que
ne su propuesta en las categorías: confiabilidad, seguridad, des- está enfocado en la importancia
empeño de tiempo, desempeño de espacio, portabilidad, y man- que tiene el saber leer código,
tenimiento. Cada una obtiene un capítulo, pero lo más peculiar para aprender a programar con
de este libro, es que cada capítulo muestra docenas de ejemplos calidad.
basados en código fuente de conocidos proyectos de software
libre, tal como Perl, ACE, y NetBSD, donde cada ejemplo confirma Code Quality debería ser una
su punto de una manera clara e irrefutable. lectura requerida para todos los cursos de programación, y de-
bería ser considerado una biblia no solo para los programado-
El libro está saturado de experiencia y observación detallada. res, sino para todos los involucrados en análisis, mantenimien-
Diomidis es un profesor asociado en la Universidad de Atenas, to y control de cambios del software.

Refactoring Databases: Evolutionary Database Design

Scott W. Ambler y Pramod J. Sadalage

02
Addison Wesley Professional, 2006 la refactorización de datos en el
Refactorizar una base de datos consiste en realizar proceso de desarrollo y mante-
pequeños cambios al esquema de una base de datos nimiento de software. Adicional-
existente (y posiblemente en producción) para mejorar su diseño, mente, también dedica atención
pero manteniendo su semántica. El proceso de refactorización se a analizar aspectos culturales,
enfoca en mejorar de forma evolutiva un esquema de datos de tal que de acuerdo a los autores se-
forma que pueda soportar con mayor facilidad nuevas necesidades rán los más difíciles de superar.
de los clientes, incorporar ajustes realizados a las aplicaciones, y co-
rregir problemas de diseño existentes en bases de datos legadas. La refactorización es un concepto
crucial en la práctica moderna de
Este libro enseña diferentes técnicas para poder realizar cambios a desarrollo exitoso, y las bases de
las base de datos de forma ágil. Refactoring Databases está lleno de datos particularmente necesitan
consejos prácticos sobre cómo mejorar el diseño de la base de da- de “agilidad” y “administración
tos, desde que se está creando, hasta cómo manejar las transiciones evolutiva”, fundamentos de la
y migraciones. El contenido revela la experiencia de los autores en refactorización. Tanto gerentes
el tema de desarrollo ágil, demostrando la premisa fundamental de como administradores de bases
este libro: “los datos y las bases de datos deben evolucionar en la de datos necesitan familiarizarse
misma manera que el código evoluciona - de manera incremental”. con este concepto, y aquí es donde Ambler siempre ha sobresalido:
en su habilidad para comunicar abstracciones arquitectónicas que
Refactoring Databases no solo se enfoca en aspectos técnicos o sean entendidas tanto por los tomadores de decisiones, como por
tecnológicos, sino que también aborda el tema de cómo incorporar los programadores.

56 JUL-AGO 2007 www.softwareguru.com.mx

www.sg.com.mx
Año 03 No. 4 www.sg.com.mx SG SOFTWARE GURU CONOCIMIENTO EN PRÁCTICA Julio-Agosto 2007