•

Data Warehouse
Multidimensional
• Ruby on Rails
• Documentación
de Arquitecturas

Software Guru CONOCIMIENTO EN PRÁCTICA

No.20 • Mayo - Julio 2008 • www.sg.com.mx

[ ENTREVISTAS ]
Terry Quatrani
Jon "maddog" Hall
John Crupi
Key speakers SG'08

México. $65 MXN

[ Herramientas ]
Noticias • Eventos • Fundamentos • UML • Infraestructura • Tecnología Visual Studio 2008
 // CONTENIDO
Editorial
Remontarnos a la época del Renacimien-
to sería hablar de la Capilla Sixtina o La
Gioconda pero, ¿qué relación hay entre las
artes con la tecnología?. La respuesta es
sencilla, las nuevas tendencias en lengua-
jes de programación están retomando lo
mejor de aquellos que sirvieron como base
para los lenguajes modernos.
Este movimiento es similar al Renacimien-
to en las Bellas Artes, no solamente porque
marca un estilo, además señala el inicio de
una nueva generación de opciones para
aplicar los conocimientos aprendidos en
las clases de estructuras de datos. Para
los jóvenes estudiantes, se les presenta la
oportunidad de aprender la sintaxis de los
nuevos lenguajes, para los profesionistas
con cierta trayectoria en el medio, el reto
de actualizarse y saber qué es lo que viene
atrás de ellos.
En este número invitamos a nuestros fieles
lectores, a conocer un poco más sobre este
renacimiento tecnológico y sus tendencias.
Sin pasar por alto las columnas que se han
vuelto un clásico en cada edición. Temas
que hablan sobre la documentación de ar-
quitecturas, la locura que pasa un usuario
cuando tiene muchas cuentas de acceso
para diferentes servicios, el framework de
Rails y otros temas que sabemos serán de
su completo agrado.
Tocando otros temas, mediante una encues-
ta realizada en el sitio web, sabemos que la
fecha preferida por la mayoría de los asis-
02 MAY-JUL 2008
tentes al anterior congreso es junio. Dada
esta preferencia, este año SG’08 Conferen-
cia y Expo ya tiene fecha, no solamente eso;
paralelamente a nuestro evento, se realizará
el PMTOUR México 2008, organizado por el
PMI Capítulo México. La agenda de ponen-
cias y talleres ya la pueden consultar en el
sitio web oficial: www.sg.com.mx/sg08
El equipo de SG está con miles de ocupa-
ciones organizando el evento, para que por
tercera vez consecutiva se realice con éxito.
El lugar ya es conocido por ustedes Hotel
Sheraton Centro Histórico, escuchando sus
propuestas, ahora arrancamos con dos días
de tutoriales. Como pueden darse cuenta,
los cambios nacen de sus sugerencias, sin
olvidar mencionarles que fue difícil escoger
las pláticas paralelas, llegaron propuestas
muy interesantes pero lamentablemente el
tiempo es poco. Gracias a todos aquellos
que se tomaron un tiempo para registrar su
propuesta de charla.
En esta ocasión tendremos la grata presen-
cia de Terry Quatrani, Jon “Maddog” Hall y
John Cupri, 3 grandes celebridades dentro
de sus áreas de desarrollo profesional, y
para terminar la noche, relajar los nervios,
descansar la mente y sacar al niño geek que
todos llevan dentro, el evento social estará
encabezado por una sesión de Rock Band.
¡Nos vemos en SG’08 Conferencia y Expo!
» Equipo Editorial
directorio
Dirección Editorial
Pedro Galván
Dirección de Operaciones
Mara Ruvalcaba
Coordinación Editorial
Sonia Sánchez
Arte y Diseño
Grisel Otero
Consejo Editorial
Jorge Valdés - PMI; Francisco Camargo,
Luis Daniel Soto - Microsoft; Ralf Eder, Raúl
Trejo, Guillermo Rodríguez, ITESM-CEM;
Hanna Oktaba, UNAM; Luis Cuellar, Softtek;
Luis Vinicio León, e-Quallity, Emilio Osorio.
Colaboradores
Rigoberto Calleja, Rajah James, Omar Gómez,
Carlos Ortega, Charlie Macías, Elizabeth
Almeraz, José de J. Hernández, Karina Okón,
Ariel García, Tom Mochal, José L. Flores,
Tomás Helou, Ernesto Reyes, Elena Ruelas,
Miguel A. Morán, Ariel Ortiz.
Ventas
Claudia Perea, Natalia Sánchez
Marketing y RP
Dafne Vidal
Circulación y Suscripciones
Daniel Velázquez
Administración
Araceli Torres
Contacto
info@softwareguru.com.mx
+52 55 5239 5502
SG Software Guru es una publicación trimestral
editada por Brainworx S.A. de C.V., Malinche no.
6, Col. El Parque, C.P. 53398, Naucalpan, México.
Queda prohibida la reproducción total o parcial
del contenido sin previo aviso por escrito de los
editores. Todos los artículos son responsabilidad de
sus propios autores y no necesariamente reflejan el
punto de vista de la editorial. Reserva de Derechos
al Uso Exclusivo: 04-2004-090212091400-102.
Certificado de licitud de título: 12999. Certificado
de licitud de contenido:10572. ISSN: 1870-0888.
Registro Postal: PP15-5106. Se imprimió en abril de
2008 en El universal, Compañía Periodística Nacional.
Distribuido por Comercializadora Alieri y Sepomex.
www.sg.com.mx
 contenido
may-jul 2008

EN PORTADA
Lenguajes de Programación
Conozcamos los orígenes de los nuevos
paradigmas dentro de este campo.

Especial 18
Data Warehouse Multidimensional.

Productos
LO QUE VIENE 12
JBuilder 2008, WebSphere sMash,
Mingle 2.0 y Quest para Sharepoint.

Herramientas 14
Visual Studio 2008 Herramientas
de análisis y medición de código.

Columnas Prácticas
Tejiendo Nuestra Red 08 Tierra Libre 61 ARQUITECTURA 38
por Hanna Oktaba por Emilio Osorio Más allá del manual de usuario
Conozcamos los diferentes tipos de
Mejora Continua 10 Columna Invitada 62 documentación que debe considerar
por Luis Cuellar por Tomás Helou un arquitecto de software.

Prueba de Software 36 Cátedra y Más 64 PROGRAMACIÓN 42

por Luis Vinicio León
Tendencias en Software 60
por Luis Daniel Soto
En Cada Número
Noticias y Eventos 04
por Raúl Trejo Aprendiendo Ruby y Rails
En la tercera parte del tutorial, se hablará
sobre el framework de Rails.
PROCESOS 46
CMMI-SVC
Para todas aquellas empresas dedicadas
a los servicios, este nuevo modelo les será
INFRAESTRUCTURA 56 de gran ayuda en su desempeño.

FUNDAMENTOS 54 GADGETS 58 UML 48

SysML
Con esta notación, el modelado de los

24
sistemas se amplía al considerar no
solamente los componentes tipo Software.

PM CORNER 50
Entrevistas El valor de las oficinas de proyectos
Terry Quatrani Notemos el valor del lugar en el que
Jon “maddog“ Hall se desarrolla toda la planeación de un
John Crupi proyecto en curso.

www.sg.com.mx MAY-JUL 2008 03

 // NOTICIAS

IMPACT 2008
La ciudad de Las Vegas fue sede de Impact 2008, la confe-
rencia anual que IBM realiza para usuarios de Websphere
a la cual asistieron más de 6 mil personas de todo el mun-
do. El tema central a lo largo del evento fue SOA, e IBM
dejó claro su liderazgo en este campo no solo en térmi-
nos de tecnología, sino también en cantidad de clientes.
Prueba de ello fueron las más de 250 sesiones impartidas
directamente por clientes de IBM que hablaron sobre su
experiencia con SOA, destacando las pláticas de empre-
sas como Harley Davidson, Aetna y United Airlines.

El slogan del evento fue “Smart SOA”, y el objetivo era

hacer ver que los tiempos del “¿Qué es SOA?” finalmen-
te están quedado atrás, y por fin estamos entrando en el
“¿Cómo aplicar SOA de forma efectiva?”.

Estamos con los Héroes

Bajo el lema “estamos con los héroes” se realizó el lanzamiento
en México de Visual Studio 2008, Windows Server 2008 y SQL
Server 2008. Durante varias semanas se realizó un tour por dis-
tintas ciudades del país, y el 17 de abril fue el evento en Ciudad
de México con más de 2 mil asistentes, así como la participación
del Hijo del Santo.

Las nuevas versiones de estos productos proveen un gran núme-

ro de mejoras y nuevas capacidades, orientadas a hacer realidad
la visión de Microsoft de “Software + Servicios”. En el caso de
Visual Studio, el énfasis está en el desarrollo de aplicaciones dis-
tribuidas, así como el aprovechamiento de nuevas tecnologías
como LINQ. Por su parte, tal parece que la principal fortaleza de
Windows Server 2008 estará en la facilidad que provee para el
manejo de virtualización.

PROSOFT 2.0
La Secretaría de Economía dio a conocer la segunda generación del Programa
para la Industria de Software (PROSOFT) bajo el nombre de PROSOFT 2.0. En-
tre las novedades está la creación de un nuevo programa denominado PRO-
MEDIA, el cual está dirigido a impulsar el sector de los medios interactivos.

De acuerdo con Sergio Carrera, Director General de Comercio Interior y Eco-

nomía Digital en Secretaría de Economía, la principal diferencia con PROSOFT
2.0 es que maneja un enfoque de mayor proactividad, especialmente en el
desarrollo de capital humano. En lugar de esperar a que se presenten las
oportunidades para entonces comenzar a desarrollar la gente, ahora la men-
talidad es primero generar la gente para que así lleguen las oportunidades.

04 MAY-JUL 2008 www.sg.com.mx

 // noticias

Gartner Enterprise Integration Summit

Al igual que cada año, este mes de abril se celebró la Cumbre
de Integración Empresarial de Gartner, en la cual se analizan
las tendencias en cuanto a arquitecturas empresariales e in-
tegración de datos y aplicaciones. Los temas que dominaron
la conferencia fueron SOA, BPM y enterprise mashups.

De acuerdo con los analistas de Gartner, lo que ven en Méxi-

co es que estamos haciendo un gran énfasis en la gestión
de procesos (BPM), pero nos está costando trabajo habilitar
esto en el contexto de arquitecturas orientadas a servicios,
por lo cual estamos obteniendo beneficios marginales.

Mexico First Tendencias 2008 Conferencia Anual de

CANIETI y ANIEI, con el apoyo de Secre-
taría de Economía han creado la iniciati-
va Mexico First. Esta es una asociación
civil operada por CANIETI cuya misión
es aumentar la cantidad de personas
certificadas en nuestro país, de forma
que nuestro recurso humano sea reco-
nocido globalmente como una excelen-
te opción para satisfacer las necesida-
des de la industria de TI.
A grandes rasgos, lo que Mexico First
hará es captar las necesidades de
certificación en TI de los diferentes
estados, y unificar el poder de compra
para mejorar la calidad y el costo. Esto
acelerará los proyectos que solicitan
Fondos PROSOFT para certificación
de personal, ya que los beneficiarios
no tendrán que buscar proveedores y
obtener cotizaciones, sino que Mexico
First se encargará de esto.
El pasado 26 de febrero se llevó a cabo
el evento Tendencias 2008: Arquitectura
para organizaciones de alto desempe-
ño, durante el cual se identificaron las
prácticas que los empresarios deben
adoptar para ser competitivos. Se brin-
dó a los asistentes la oportunidad de
participar en seis talleres de bench-
marking para identificar oportunidades
e impulsar el desempeño de sus
organizaciones.
El cierre del evento estuvo a cargo
del Dr. Ricardo Zermeño González, di-
rector general de Select, quién en su
conferencia magistral señaló las opor-
tunidades para un crecimiento com-
petitivo en México, destacando que
no solo se requieren las conocidas re-
formas estructurales, sino también de
una reforma empresarial llamándola:
la reforma estructural olvidada.
Administración de
Servicios de TI
En el pasado mes de abril, en el WTC
de la Ciudad de México, se realizaron
dos días de conferencias organizados
por Pink Elephant. Los participantes
tuvieron la oportunidad de intercam-
biar ideas, aprender e integrarse en
un medio ejecutivo. Las sesiones se
dividieron en diferentes sectores: Ad-
ministración de TI Ejecutiva y Estraté-
gica, reuniones informativas de ITIL,
Gobernabilidad, ¿Dónde comenzar a
implementar ITIL?, Implementación
de Herramientas y Tecnología. Cabe
destacar que en dicho evento se hizo
la presentación de la primera certifi-
cación en ISO 20000 en Latinoamé-
rica, este honor lo tuvo la empresa
colombiana Compuredes.

Empresas recientemente evaluadas en CMMI:

Empresa Evaluación Fecha Lead Appraiser
Sinersys CMMI Nivel 3 marzo 2008 Alfredo Calvo, Itera
Ventus CMMI Nivel 3 marzo 2008 José Luis Iparraguirre, Itera
IDS CMMI Nivel 3 marzo 2008 Ernesto R. Corona, Liveware

www.sg.com.mx MAY-JUL 2008 05

 // Eventos

14 al 15 de Mayo 2008 22 de Mayo 2008

IDC WebSec Conference 2008 PRONET Heroes Coatzacoalcos
Centro Banamex, Cd. de México Salón de la CANACO de Coatzacoalcos, Veracruz
Info: www.idc-eventos.com Info: www.microsoft.com/latam/estamosconlosheroes

14 al 16 de Mayo 2008
Expo Data Center 2008 18 al 19 de Junio 2008
Salón Olmeca, WTC, Cd. de México Gartner 4ª Annual Outsourcing Summit
Info: www.expodatacenter.com/expo2008 Centro Banamex, Cd. de México
Info: www.gartner.com/mx/outsourcing

17 de Mayo 2008
BugCON Security Conferences
Instituto Politécnico Nacional, Cd. De México 21 al 24 de Junio 2008
Info: www.zonartm.org/BugCON SG’08 Conferencia y Expo /
PMTOUR México 2008
Hotel Sheraton Centro Histórico
20 al 21 de Mayo 2008 Info: www.sg.com.mx/sg08
Information Security
WTC, Cd. de México
Info: www.informationsecurity.com.mx
24 al 25 de Junio 2008
Cutter
21 al 23 de Mayo 2008 Mastering Personal Agility for Executives
Sun Tech Days 2008 Hotel JW Marritott, Cd. de México
Centro Banamex, Cd. de México Info: www.cutter.com.mx
Info: www.suntechdays.com.mx

Infor Day México 2008 Circuito Tecnológico 2008

Infor realizó los pasados 14 y 15 de febrero, en las instalacio-
nes del Hotel Sheraton Centro Histórico, el primer Infor Day
en América Latina. Este evento, como parte de la serie Infor
Day a nivel mundial, celebró el crecimiento de los clientes en
México y norteamérica ofreciendo un foro interactivo para las
compañías interesadas en aprender más sobre la empresa y
sus soluciones.
Las sesiones estuvieron enfocadas en las soluciones de nego-
cios para varias industrias, incluyendo manufactura discreta,
manufactura de proceso, minoristas, servicios y más. Los asis-
tentes tuvieron la oportunidad de aprender las mejores prácti-
cas del medio a través de pláticas sobre la dirección de produc-
tos, casos de estudio de implementaciones innovadoras en voz
directa de los clientes de Infor así como a las sesiones educati-
vas enfocadas en las soluciones que ofrece esta compañía.
El vicepresidente de Infor en México, comentó que estable-
ciendo este evento anualmente en nuestro país, se demues-
tra el compromiso de la empresa para servir a sus clientes de
Latinoamérica resaltando la etapa de crecimiento en este mercado.
Secretaría de Economía, mediante el PROSOFT, dió inicio al Cir-
cuito Tecnológico 2008, programa de capacitación que a través
de la impartición de talleres y conferencias, tiene como objetivo
hacer extensivo el conocimiento que Empresas, Organizaciones
y Gobierno involucrado con las TI, desean dar a conocer.
El 4 de marzo dió inicio con el seminario “Generación de Demanda”,
dirigido a desarrolladores y distribuidores de tecnología, revi-
sando temas como el rol del gerente de marketing y experien-
cias reales en la generación de demanda. Las conferencias
estuvieron a cargo de Christian Zuili de ZUiLi University, Daniel
Hernández de ActionCOACH, y Ernesto Herrera López de HLO.
El 11 de abrilse presentó el seminario “CMMI ACQ - Modelo para
la mejora en las áreas de Adquisiciones”, donde Carlos Pérez y
Mariana Pérez-Vargas, de la empresa Avantare, presentaron el
modelo y su método de evaluación. Como parte del programa,
AMITI presentó una metodología para el apoyo de ventas de TI
a gobierno, y posteriormente se contó con una mesa redonda
sobre la problemática y perspectiva de las adquisiones.
Para conocer la agenda visita: www.software.net.mx/circuito

06 MAY-JUL 2008 www.sg.com.mx

www.sg.com.mx MAY-JUL 2008
 // COLUMNA
50 Años de la Computación en México
Manifiesto de REMIDEC
La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software,
Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International
Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.
E l 8 de junio de 1958, gracias a las gestio-
nes del Ing. Sergio Beltrán, se inauguró el
Centro de Cálculo Electrónico en la Facultad
de Ciencias, UNAM. Su primera computado-
ra fue la IBM-650 de bulbos, con memoria
de tambor magnético y con lectora y perfo-
radora de tarjetas. Los primeros expertos
en manejarla fueron José Luís Otalengo y
Artemio Taboada, mientras que Manuel Or-
tega fue su primer operador. Estos datos
los tomé del artículo: “Primera Década de
la Computación en México: 1958-1968 Pri-
mera y Segunda parte”, escrito por Miguel M.
Soriano L. y Christian Lemaitre, publicado en
Ciencia y Desarrollo, vol. 60 y 61, 1985.
Pasaron 50 años y afortunadamente tene-
mos el programa PROSOFT, que tiene por
objetivo fortalecer la industria de software
en México. Como todos sabemos, para lo-
grar este objetivo se requiere de una cola-
boración muy estrecha entre el gobierno,
la industria y la academia. El papel de la
academia, hasta este momento, se está
viendo principalmente como proveedor de
recursos humanos sin apreciar lo suficien-
te la parte de investigación como la fuente
de innovación.
El año pasado, el Dr. Christian Lemaitre de la
UAM-Cuajimalpa, uno de los Decanos de la
computación en México, empezó a convocar
a la comunidad académica para aprovechar
este aniversario y hablar de la importancia
de fomentar la investigación en computación.
Como resultado, se ha conformado la Red
Mexicana de Investigación y Desarrollo en
Computación (REMIDEC) cuyas primeras
tareas fueron hacer el censo de los docto-
res en computación en México y elaborar
un manifiesto. El censo nos sorprendió a
nosotros mismos, ya somos más de 500
doctores en diversas áreas de computación
en México. Elaborar el manifiesto nos costó
08 MAY-JUL 2008
/*TEJIENDO NUESTRA RED*/
un poco más de trabajo, pero finalmente lo
concretamos.
En esta columna quiero compartir con los
lectores de SG los puntos más importantes
del Manifiesto de la Comunidad Científica
de la Computación que empieza con el si-
guiente preámbulo:
Hoy, México tiene un número importante de
especialistas en Ciencias de la Computación
con alta calificación.
Juzgamos que si se da un esfuerzo concer-
tado y una adecuada inversión por parte de
las autoridades y de las instituciones involu-
cradas, estos especialistas pueden producir
mucha más investigación de primera calidad
con un mayor impacto para el desarrollo de
México.
El documento cuenta con ocho páginas y su
contenido está estructurado de la siguiente
manera:
i. ¿En qué consiste y por qué es importante hacer
investigación en Ciencias de la Computación?
ii. La necesidad de hacer investigación en
Ciencias de la Computación en México.
iii. Barreras para el florecimiento de la inves-
tigación y desarrollo de la computación en
México.
iv. Líneas de acción claves para promover la
investigación en Ciencias de la Computación
en México.
Creo que para los lectores, los primeros dos
puntos no requieren de mayor explicación,
por lo tanto voy a concentrarme en presen-
tar las barreras y las líneas de acción que se
proponen.
Con respecto a las barreras, cito la parte
más importante del manifiesto:
…las Ciencias de la Computación no han lo-
grado un reconocimiento que corresponda a
su importancia y características específicas,
ni entre las autoridades del ramo, ni en el
resto de la comunidad científica. Aun con
el crecimiento importante de profesores in-
vestigadores en computación en los últimos
15 años, su número es insuficiente ante las
necesidades del país. No hay suficientes
grupos con la masa crítica requerida, ni se
dan suficientes apoyos para desarrollar pro-
yectos con la magnitud y plazos adecuados
para lograr el posicionamiento e impactos
convenientes para el país.
En pocas palabras: somos relativamente
muchos, pero pulverizados. El mejor ejemplo
es la UNAM. Somos bastantes, pero rega-
dos entre múltiples instituciones de esta
enorme Universidad. En la propia Facultad
de Ciencias, cuna de la computación en
México, existe la carrera de Ciencias de la
Computación, pero no el departamento con
el mismo nombre, porque nuestros colegas
biólogos, físicos y matemáticos consideran
que todavía estamos “peques”.
Entonces, ¿qué hacer para cambiar esta si-
tuación? Cito a continuación la propuesta de
las principales líneas de acción:
1. Establecer la investigación y desarrollo
en Ciencias de la Computación y las Tecno-
logías de Información como un área priori-
taria para el país. Esto se debe incluir en el
Plan Nacional de Desarrollo, estableciendo
la necesidad de asignar recursos específicos
para promover la investigación a mediano y
largo plazo. También, es necesario recono-
cer a las Ciencias de la Computación como
una especialidad en sí misma en todas las
instancias académicas y gubernamentales,
en particular en el Sistema Nacional de
Investigadores (SNI).
www.sg.com.mx

2. Contar con una masa crítica de investi-
gadores y grupos de investigación de pri-
mera calidad. Para ello, es necesario hacer
un esfuerzo en la formación de nuevos
científicos, así como en la actualización de
maestros, profesionales e investigadores
consolidados. Se deben crear, además, las
condiciones para atraer y retener investi-
gadores de primera calidad y, sobre todo,
instituir las condiciones que les permitan
trabajar de forma productiva. En particular,
se requieren, tanto la apertura de plazas
para los nuevos investigadores que se están
formando, como la existencia de esquemas
atractivos para promover la contratación de
investigadores consolidados con interés en
instalarse en México.
3. Consolidar los grupos de investigación.
No basta con la existencia de numerosos in-
vestigadores en el país, es necesario contar
con grupos suficientemente grandes, com-
puestos por investigadores y estudiantes de
posgrado, que colaboren durante un tiempo
razonable y con adecuada especialización
para alcanzar niveles de continuidad, pro-
ducción y calidad comparables a los de los
mejores grupos del mundo. Estos grupos se
deben formar, por lo general, dentro de las
distintas instituciones pero deberá fomen-
tarse también la formación y consolidación
de grupos multinstitucionales y la incorpo-
ración a éstos de investigadores que se en-
cuentren aislados temática o institucional-
mente. Sin grupos estables y productivos,
las capacidades de formación y transferen-
cia de tecnología son disfuncionales.
4. Reordenar los mecanismos de financia-
miento y estímulo a la investigación. Para
lograr los objetivos anteriores es necesario
contar con recursos previsibles suficientes,
cuya obtención y gestión no supongan una
carga excesiva ni para los grupos de inves-
www.sg.com.mx
“Hoy, México tiene un número importante de
especialistas en Ciencias de la Computación
con alta calificación”.
tigación ni para los propios investigadores.
Es deseable instituir mecanismos de finan-
ciamiento que propicien la conformación de
grupos sólidos orientados a la investigación
y desarrollo en las áreas prioritarias y con
una visión a largo plazo. Asímismo, deben
diseñarse mecanismos de asignación, eva-
luación y seguimiento, así como incentivos
que, en conjunto, impongan exigencias sen-
satas y objetivas a investigadores e institu-
ciones: den pie a una evaluación pertinente
y oportuna y constituyan, en suma, instru-
mentos para hacer eficiente la inversión. Es
indispensable contar con mecanismos de eva-
luación y estímulos adecuados al dinamis-
mo y características particulares del área.
5. Establecer una estrategia de articulación
nacional. Esta articulación debe realizarse
en distintos ámbitos. Hay que prestar aten-
ción a la integración de la investigación en
Ciencias de la Computación con la docencia
por un lado y con la transferencia de tecno-
logía por el otro, además de la integración
de los investigadores en esta área como una
comunidad y su coordinación con las otras
comunidades científicas. Es necesario forta-
lecer la intervención de estos investigadores
en los distintos órganos de evaluación de la
actividad científica del país (como el CONA-
CYT y el SNI), así como en los de política
científica (Academia Mexicana de Ciencias y
el Foro Consultivo). Se deben consolidar los
mecanismos de transferencia de tecnología
y capital de riesgo que permitan transferir
para potenciar el producto de la investiga-
ción y desarrollo en ciencias de la computa-
ción y Tecnologías de Información.
6. Establecer una estrategia de vinculación
internacional. Es necesario fomentar la par-
ticipación en redes internacionales de las
distintas especialidades con la colaboración
de científicos mexicanos en los comités edi-
toriales, los organismos de evaluación, los
órganos de gobierno de las asociaciones, la
organización de eventos. Se debe fomentar
que los grupos de investigación mexicanos
y las instituciones que los abriguen esta-
blezcan relaciones y alianzas que permitan
colaboración en distintos tipos de actividad
con contrapartes de otros países. Estas co-
laboraciones deberán considerar también
aspectos de formación que incluyan becas,
visitas, estancias, dirección compartida de
tesis doctorales, cursos y proyectos bina-
cionales y multinacionales. Será necesario
diseñar estrategias específicas para impul-
sar las relaciones con los países con los que
hay una historia exitosa de colaboración o
con los que es importante tenerla, para for-
talecer los vínculos con los investigadores
mexicanos establecidos en el extranjero,
así como con asociaciones profesionales y
organismos de promoción y coordinación
internacionales.
Como pueden ver tenemos muchas asigna-
turas pendientes, que no se van a resolver
de la noche a la mañana, pero que bueno
que ya se formularon y pueden servirnos de
orientación en los esfuerzos de cada quien.
Hay que tocar muchas puertas de gobier-
no, de industria; medios de comunicación
y las propias instituciones de investigación
y educativas. Hay que difundir, evangelizar
y convencer de que la mejora de la investi-
gación en computación tiene un impacto di-
recto en la formación de recursos humanos,
éstos en la innovación de la industria de
software y, en general, de la Tecnología de
Información. Finalmente, todo esto se tradu-
ce en el mejor bienestar de la sociedad en
su conjunto. Otros países ya lo entendieron
perfectamente desde hace tiempo, ahora le
toca a México.
» Hanna Oktaba
MAY-JUL 2008 09
 // COLUMNA
Calidad
El camino hacia la renovación
Luis R. Cuellar es director de calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality
(ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la
definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.
E n el número pasado hablábamos de generar algunas ideas de
apoyo para crear y darle seguimiento a sus planes para 2008. En esta
ocasión continuaremos con la segunda y última parte del artículo.
Donde manda capitán, no gobierna marinero
Una iniciativa de mejora continua solamente se puede implementar cuan-
do es apoyada por la dirección de la organización, para todos aquellos
que no cuentan con esta ayuda, temo decirles que lo anterior es absolu-
tamente cierto y hasta ahora nunca he visto una excepción a la regla. Sin
los directivos, solamente tenemos dos posibles estrategias:
1) Identificar a la persona o personas que sí crean en la mejora con-
tinua, y apoyarse en ellos para implementaciones. A veces lo mejor es
reducir el alcance de lo que queremos hacer para acelerar la implemen-
tación, es muy probable que cuando otras personas vean lo que se ha
logrado, entiendan mucho mejor por qué ellos también deben hacerlo.
2) Muchas veces no es que las personas no quieran mejorar su tra-
bajo, simplemente no entienden qué es lo que deben hacer o cómo
es qué mejorar les conviene, siempre se debe de vislumbrar el rol de
un agente de cambio como un educador. El trabajo muchas veces no
es sólo ayudar a mejorar, es enseñar cómo hacerlo.
Los Cañones de Navaron
En los años setenta salió en los cines una película llamada Los Caño-
nes de Navaron, la cual habla de un equipo especial en la Segunda
Guerra Mundial con la misión de destruir una barrera de tanques
estratégicamente colocados para que la marina no pudiera entrar y
atacar. Cuando vi esta película me recordó otra historia: una orga-
nización que trataba de hacer un cambio y los participantes, al ser
auditados, mencionaron que necesitaban capacitación para apren-
der; durante el curso mencionaron que requerían de los templates
adecuados, después de eso solicitaron los checklists para llenar los
templates, después requerían ejemplos de cómo llenar los templa-
tes, finalmente al terminarlos, había pasado tanto tiempo que los
ingenieros solicitaron que se les diera un curso para poder aprender.
Suena divertido, ¿no?
Pero este es un problema sumamente común, sobre todo cuando
no se incluye a las personas al definir los procesos, y es una trampa
muy difícil de brincar sin ayuda de la dirección de la compañía. A
fin de cuentas a lo que se tiene que llegar es a un compromiso por
parte de los involucrados, es decir, tenemos que llegar a un punto en
donde se pueda decir: “yo me comprometo a darte esto, a cambio de
que tú te comprometas a hacerlo”.
10 MAY-JUL 2008
/*MEJORA CONTINUA*/
Tautologías y palabras mágicas
Cuántas veces hemos escuchado cosas como “el entrenamiento no
es suficiente, se requiere gente con experiencia”, “somos una com-
pañía que cree en la más alta calidad”. Muchas veces los intentos de
mejorar procesos se detienen cuando se nos colocan palabras de-
masiado grandes para poder hacer algo con ellas. Esto es tan común
que a veces, ni siquiera nos damos cuenta que lo estamos haciendo,
por lo que siempre tenemos que estar al tanto de dichas expresiones
dentro de toda la conversación, buscando aclarar qué es exactamente
lo que se quiere decir. Lo importante es que quede claro qué es lo
que se esta buscando resolver antes de solucionarlo.
Demasiado trabajo para atenderte
Las organizaciones que trabajan con pocos estándares de calidad
siempre están de prisa, atrasadas y nunca tienen tiempo para alguien
fuera del proyecto que les diga cómo hacer las cosas. Normalmente
tienen la idea de que si no estas físicamente con ellos, no entende-
rás los problemas y sólo les quitarás el tiempo. Esta es otra situación
difícil de resolver, muchas veces lo ideal es dejar a un lado nuestros
planes de certificación y enfocarnos en resolver los problemas de los
proyectos. Lograr masa crítica con otros y después regresar a nuestro
objetivo inicial. Debemos tener presente que si solo nos compromete-
mos a un proyecto, los demás quedan desatendidos; hay que buscar
el balance. También debemos tener mucho cuidado de no absorber-
nos por completo en las tareas diarias y perder el objetivo.
Demasiado entrenamiento
Al implementar un plan de calidad, la cantidad de entrenamiento
que se requiere, normalmente es el problema principal. Se espera
que los ingenieros de software y lleguen entrenados para hacer lo
que tienen que hacer. Se entrenen en ratos libres o al no estar asig-
nados en algún proyecto. Y el entrenamiento normalmente se enfoca
en lenguajes de programación o técnicas de ingeniería de software.
Al implementar una serie de procesos en una organización, es im-
portante tomar en cuenta que para todo proceso se debe entrenar
a todos los involucrados, cuando ingresan a la compañía o cuando
cambian su rol de trabajo. Se requiere tener un claro plan de en-
trenamiento por lo que es importante conocer sobre sus técnicas,
modelos y cualquier cosa que nos permite hacerlo más flexible y
efectivo. Adicionalmente, la rotación es el enemigo número uno del
entrenamiento. Es importante mantener la rotación al mínimo.
Espero que todo esto les ayude con su planeación y la ejecución de
sus planes, a trabajar. Hagamos de 2008 el año del cambio.
» Luis R. Cuellar
www.sg.com.mx
www.sg.com.mx MAY-JUL 2008
 // PRODUCTOS /* LO QUE VIENE*/
JBuilder 2008
Llegan los Application Factories
CodeGear anunció la disponibilidad de la versión 2008 de JBuil-
der, la cual incorpora soporte para una estrategia de desarrollo
denominada Application Factories. Este concepto es bastante in-
teresante. Básicamente, parte del entendimiento de que la ma-
yoría de las aplicaciones que desarrollamos actualmente no se
hacen desde cero, sino que partimos de una base de aplicaciones
existentes (ya sean internas, de software libre, o componentes
comerciales). Entonces, lo que se hace a través de los Applica-
tion Factories es capturar estas modificaciones o ajustes a códi-
go existente y describirlas como metadatos independientes de
un lenguaje de programación. Posteriormente se pueden tomar
estos metadatos y aplicarlos a una base de código diferente, e
incluso capturar cambios adicionales. En pocas palabras, lo que
se está haciendo es “civililizar” el proceso de tomar código que
ya tenemos y ajustarlo a nuestras necesidades.
Desde su separación de Borland, CodeGear ha buscado distinguir-
se como una empresa que conoce a los desarrolladores y les da
las herramientas que realmente necesitan. Tal parece que JBuilder
2008 con Application Factories es una excelente prueba de esto.
Más información en www.codegear.com
Quest
Nuevas Herramientas para Sharepoint
Sharepoint ha cobrado gran popularidad en los últimos
años. De acuerdo con Gartner, el 80% de las organiza-
ciones utilizarán Sharepoint para el año 2010. Sin embar-
go, solo el 40% lo utilizarán efectivamente. Con esto en
mente, Quest Software ha desarrollado un conjunto de
herramientas que facilitan y mejoran distintos aspectos
relacionados con Sharepoint, tales como la migración de
información, desarrollo e integración de aplicaciones, y
gestión de la base de datos.
Entre los nuevos productos hay una herramienta para
migración de Notes a Sharepoint, otra para desarrollo de
aplicaciones Sharepoint, y otra para migración de archivos
desde carpetas públicas.
Más información en www.quest.com
12 MAY-JUL 2008
Websphere sMash
IBM le entra a los mashups
IBM anunció el lanzamiento de WebSphere sMash, una
plataforma para el desarrollo y ejecución de mashups.
sMash es la versión comercial del proyecto de incuba-
ción denominado Project Zero, el cual seguirá disponible
de forma gratuita para desarrolladores.
Junto con sMash también se lanzará el IBM Mashup Cen-
ter, que es un repositorio de mashups donde los usua-
rios no técnicos podrán fácilmente escoger y utilizar
widgets por medio de drag and drop para ensamblar sus
propios mashups.
sMash estará disponible en junio de 2008, y se espera
que en el segundo semestre del año, también se ofrezca
un servicio de hosting donde se puedan ejecutar aplica-
ciones de Project Zero. Otra innovación que se espera
próximamente como parte de esta plataforma es un IDE
100% en web para desarrollo de mashups.
Más información en www.projectzero.org y
www-306.ibm.com/software/webservers/smash
Thought Works
Mingle
Mingle es una herramienta web para colaboración y
administración de proyectos. Mingle es un producto de
Thoughtworks, una de las empresas más reconocidas in-
ternacionalmente en el área de consultoría y desarrollo
con metodologías ágiles. Es así que Mingle está dise-
ñado para soportar las características de los proyectos
de software modernos, tales como desarrollo iterativo e
incremental, y equipos con miembros distribuidos geo-
gráficamente.
Recientemente fue liberada la versión 2.0 de Mingle, y
entre sus capacidades más llamativas están el mane-
jo de historias de usuarios, wikis para la colaboración
entre desarrolladores, alertas por RSS y dashboards
para visualizar el estatus del proyecto. Pero lo mejor de
Mingle es que es gratis para equipos con 5 usuarios o
menos. Así que si tienes un proyecto de software donde
el equipo está distribuido y andas buscando una herra-
mienta para colaborar y organizar el proyecto, Mingle es
una excelente opción.
Más información en studios.thoughtworks.com
www.sg.com.mx
www.sg.com.mx publicidad
MAY-JUL 2008
 // PRODUCTOS /*HERRAMIENTAS*/
Análisis y Medición de Código Administrado
con Visual Studio® 2008
Caso Database Commander y SQL Buddy
Por Rigoberto Calleja Cervantes y Rajah James
En este trabajo se presentan los resultados de una prueba rea-
lizada con las herramientas de análisis y medición de código
administrado de Visual Studio® 2008. El análisis se aplicó a
dos piezas de código abierto: Database Commander y SQL
Buddy, que están enfocadas a crear un entorno para acceder a
diversos backends de bases de datos, y se describen los datos
cualitativos obtenidos acerca de qué tan fácil se instalan las
herramientas para analizar los proyectos designados y qué tan
rápido se encuentran errores empleándolas.
Herramientas de análisis de código
Las herramientas de análisis llevan a cabo diversas verificaciones
para determinar la presencia de defectos en el código, analizando
los ensamblados y reportando cierta información acerca de aqué-
llos, tal como violaciones de reglas de programación y diseño, es-
tablecidas en los lineamientos de diseño del .NET Framework. Estas
herramientas representan las verificaciones que se llevan a cabo du-
rante el análisis como advertencias. Los mensajes de advertencias
identifican cualquier problema de diseño o programación relevante
y cuando es posible, dan información acerca de cómo corregirlo.
Las advertencias antes mencionadas indican violaciones de reglas
en bibliotecas de código administrado y están organizadas en una
serie de áreas tales como diseño, desempeño, seguridad, etcétera.
Este tipo de herramientas tienen la capacidad de permitir al usuario
indicar que una determinada advertencia no es aplicable, con lo cual
se informa a los desarrolladores, a quienes revisen el código poste-
riormente que esa advertencia ya fue investigada.
Finalmente, permiten que uno se asegure de que el código que esta
siendo protegido esté limpio, mediante el establecimiento de una
política de protección que requiera que el análisis de código sea eje-
cutado; de esta manera solamente se podrá proteger una pieza de
código. Si ésta pasó exitosamente aquél.
Herramientas de medición de código
Las herramientas de medición son empleadas para generar métri-
cas del código, referentes a su complejidad y la facilidad para darle
mantenimiento, que permiten a los programadores entender mejor
lo que están desarrollando. Al emplear las métricas, los desarrolla-
dores pueden entender qué tipos y/o métodos deben ser escritos
Rigoberto Calleja Cervantes (rcervant@andrew.cmu.edu) tiene cuatro años de experiencia como consultor en ingeniería de software, impartiendo cursos y
participando en proyectos de adopción de herramientas de gestión del ciclo de vida de desarrollo de software. Rigoberto tiene un posgrado en ingeniería de
software de la Universidad Carnegie Mellon.
14 MAY-JUL 2008
nuevamente o probados con mayor profundidad. Asimismo, pueden
identificar riesgos, entender mejor el estado actual del proyecto y
dar seguimiento al progreso del mismo. Sin embargo, estas métricas
no sirven a menos que tengan sentido para la persona que las está
usando, en este caso el desarrollador, por lo que a continuación se
presenta una breve descripción del significado de algunas de las cinco
métricas ofrecidas por las herramientas.
• Acoplamiento de clases. Indica el número total de dependencias
de otros tipos que un determinado nivel tiene. Este número no inclu-
ye tipos primitivos o incorporados, tales como int32, object o string,
y cuando es mayor, aumenta la probabilidad que los cambios reali-
zados en otros tipos se propaguen al elemento que está siendo ana-
lizado. Un valor más bajo de acoplamiento de clases generalmente
indica un candidato para reutilización.
• Complejidad ciclomática. Mide el número total de rutas individuales
a lo largo del código en cada nivel, y se calcula contando el número ra-
mas (tales como switch, foreach y ciclos for) más uno. Esta métrica ge-
neralmente es una buena indicación del número de pruebas unitarias
que se requerirán para obtener una completa cobertura del código.
• Índice de facilidad de mantenimiento. Es un número que va de 0
a 100, se calcula para cada miembro y nivel de tipo, e indica su faci-
lidad de mantenimiento en general. Se calcula en base a otras mé-
tricas incluyendo la complejidad ciclomática y el número de líneas
de código, e incluye un indicador icónico. Un número menor indica
que el código es complejo y difícil de darle mantenimiento. El rango
menor, 0-9, muestra un círculo rojo, mientras que el rango interme-
dio, 10-19, muestra un triángulo amarillo y por último, una caja verde
indica alta facilidad de mantenimiento con valores entre 20 y 100.
Instalación de Visual Studio® 2008 Team Suite
Después de descargar la versión de evaluación por 90 días de la Visual
Studio® 2008 Team Suite, se inicia el proceso de instalación. En vir-
tud de que se quiso hacer el proceso de instalación lo más ligero y
ágil posible, se seleccionaron solamente aquellas opciones que eran
absolutamente necesarias para que las herramientas de análisis y
medición de código funcionaran sobre proyectos de C#. Sin embar-
go, el proceso de instalación tuvo problemas, la instalación del .NET
Framework versión 3.5 falló. La bitácora de instalación no propor-
cionó suficiente información para determinar cuál era el problema,
probablemente hubo un conflicto entre el mencionado componente
y otro no identificado que ya estaba instalado en el equipo. La solu-
www.sg.com.mx
ción fue crear una máquina virtual desde cero instalando únicamente
el sistema operativo y Visual Studio®.
Figura 1. Opciones de instalación de la Visual Studio Team Suite.
El proceso de instalación de la documentación fue sencillo, bastó
con invocar un asistente de instalación por separado.
Database Commander
Después de descargar el código fuente del DBCommander, en-
contramos varios problemas. En virtud de que el código fuente del
DBcommander no fue escrito originalmente con Visual Studio® 2008,
fue necesario invocar el asistente de conversión de soluciones que
viene incluido. Lo anterior produjo algunos errores, ninguno de los
www.sg.com.mx
cuales era crítico. Por ejemplo: la imposibilidad de respaldar archi-
vos con extensión .MDX era un error trivial, ya que esta clase de ar-
chivos constituyen un tipo de base de datos.
Después de la conversión, intentamos compilar el proyecto, para lo cual
fue necesario compilar un proyecto dependiente (que estaba incluido
en el código fuente, pero no en la solución) que proveía un control para
la aplicación. Una vez que concluimos lo anterior, fuimos capaces de
compilar el código fuente en Visual Studio® 2008 por primera vez.
Ya con el proyecto cargado, intentamos invocar el análisis. En base a una
entrada de blog que identificamos, sabíamos que era necesario intentar
obtener primero las métricas de código. A pesar de que en un principio no
entendimos por completo el significado de las métricas, fue gratificante
observar que los resultados se produjeron muy fácil y rápidamente. El
hecho de que todos los proyectos se hayan mostrado en color verde nos
transmitió confianza acerca del estado del código fuente.
Figura 2. Métricas del código del Database Commander.
MAY-JUL 2008
 //PRODUCTOS /*HERRAMIENTAS*/
Cuando miramos las métricas en Visual Studio® 2008, se nos difi-
cultó un poco entender exactamente qué significaban, partiendo del
hecho de que se presentan como un árbol, en donde el nivel del pro-
yecto constituye la raíz, y cada nivel de éste puede representar un
tipo diferente. Es decir, las métricas tienen un significado diferente
en función al tipo de un nivel en particular.
Posteriormente probamos el análisis de código. Esta función está
disponible seleccionando el proyecto de inicio en el explorador de
proyectos y la opción “Ejecutar Análisis de Código” del menú de
análisis. De esta manera se ejecuta el análisis que verifica el código
contra los lineamientos de diseño de Microsoft que mencionamos
anteriormente. ¡Este análisis generó 159 advertencias! Sólo toman-
do en cuenta el proyecto de arranque. Sin embargo, nos tranquilizó
el hecho de que no se encontraron errores. Después de ejecutar el
mismo análisis en cada uno de los otros dos proyectos, obtuvimos
un total de 509 advertencias.
La primera advertencia se debía a que el nombre de un ensambla-
do estaba mal escrito. Al hacer clic derecho sobre el error se nos
permitió seleccionar la opción mostrar Ayuda del Error. Lo anterior
nos proporcionó una descripción acerca de cómo corregir la adver-
tencia, lo que involucró agregar la palabra mal escrita al diccionario
personalizado contra el cual se realizan las verificaciones. El diccio-
nario personalizado es un archivo llamado CustomDictionary.xml. En
el ejemplo de la ayuda, fue interesante ver que el archivo todavía
tiene referencias al sitio anterior de FXCop. Todo este proceso nos
pareció incómodo. Lo que esperábamos era encontrar una opción
que nos permitiera agregar una palabra directamente al diccionario
personalizado.
SQL Buddy
Tal y como ocurre en el caso del DBCommander, el código fuente
de SQL Buddy no fue escrito empleando Visual Studio® 2008, de
modo que fue necesario hacer una conversión. Afortunadamente, el
proceso de conversión se inició automáticamente cuando abrimos la
solución de SQL Buddy la primera vez y concluyó sin errores.
Figura 3. Reporte de conversión del código de SQL Buddy.
Rajah James (rjames@andrew.cmu.edu) es ingeniero senior en Yellowstone Hotel Systems y está trabajando en la última versión de su software principal
OpenBook; antes trabajó durante seis años para Rockwell Software y Rockwell Automation, donde estuvo involucrado con sus soluciones de manufactura e
integración empresarial basadas en .NET. Rajah tiene un posgrado en ingeniería de software de la Universidad Carnegie Mellon.
16 MAY-JUL 2008
La solución está compuesta de dos proyectos: el principal y el de
instalación. Después de realizar la conversión de la solución elimina-
mos el proyecto de instalación ya que no era de interés. Una vez he-
cho lo anterior fuimos capaces de compilar el código fuente en Visual
Studio® 2008 por primera vez.
Para calcular las métricas de código simplemente accedimos al menú
analizar y seleccionamos la opción “Calcular Métricas de Código para
SQL Buddy”. La ventana de métricas de código muestra los datos
que son generados por el análisis. Decidimos enfocarnos exclusiva-
mente en el índice de facilidad de mantenimiento para el proyecto.
Recordemos qué, un icono verde indicia un grado relativamente
alto de facilidad de mantenimiento, mientras un icono amarillo in-
dica un grado moderado de facilidad de mantenimiento, por último,
que un icono rojo indica baja facilidad de mantenimiento y un área
potencialmente problemática. Los resultados del índice de facilidad
de mantenimiento indican que el código fuente del SQL Buddy tie-
ne relativamente un alto grado de facilidad de mantenimiento y no
contiene áreas que puedan ser problemáticas. Antes de analizar el
código del proyecto decidimos activar únicamente la categoría de
reglas de nomenclatura.
Figura 4. Selección de categorías de reglas para el análisis de SQL Buddy.
La ejecución del análisis de código fue una operación muy intuitiva,
desde el menú analizar seleccionamos la opción “Ejecutar el Análisis
de Código en SQL Buddy”. Después de que el análisis fue concluido,
la ventana lista de errores fue desplegada mostrando todas las ad-
vertencias. Esa ventana incluye la descripción de la alerta, el archivo
y el número de línea donde está localizada.
Al dar doble clic sobre ésta, se mostró el archivo y la línea de código
que contiene el problema. El análisis produjo 297 advertencias. Con-
sideramos que este es un número alto de advertencias, tomando en
cuenta el hecho de que la cantidad de código fuente de SQL Buddy es
relativamente pequeña. A partir de estos resultados pudimos concluir
que el código fuente tiene un bajo nivel de apego a las reglas de no-
menclatura de los lineamientos de diseño del .NET Framework.
www.sg.com.mx
Las herramientas de análisis de código inclu-
yen información detallada acerca de cada ad-
vertencia incluyendo: el código específico que
provoca su generación, una descripción de
los problemas detrás de la advertencia, una
explicación de cómo cambiar el código fuente
para satisfacer la regla y prevenir que se ge-
nere además de, una descripción de cuándo
es conveniente suprimir una advertencia.
Para mirar esta información hicimos clic de-
recho en una advertencia y seleccionamos
la opción “Mostrar Ayuda del Error”. Gracias
a esta información, la tarea de entender el
significado de las advertencias fue muy fácil.
Por otro lado notamos que un número peque-
ño de las primeras advertencias en la lista
tenían valores en blanco para el archivo y el
número de línea. Al principio no entendimos
porqué, sin embargo posteriormente descu-
brimos que el problema estaba relacionado
con varios archivos. Las advertencias antes
mencionadas estaban relacionadas con el
uso de letras mayúsculas y minúsculas en el
nombre de algunos espacios de nombres.
Después de analizar las explicaciones deta-
lladas de estas advertencias y el código fuen-
te, llegamos a la conclusión de que estas eran
válidas y decidimos corregirlas, para hacerlo
empleamos la capacidad de refactorización
del entorno. Finalmente, ejecutamos el aná-
lisis de código nuevamente y verificamos que
las advertencias ya no aparecieran. En este
caso encontramos que el proceso fue fácil y
las capacidades del entorno que empleamos
resultaron ser muy intuitivas.
Conclusión
Estas herramientas son intuitivas y fá-
ciles de usar. La realización de la ma-
yoría de las operaciones básicas tales
como iniciar un análisis, mirar sus re-
sultados, encontrar el código que tie-
ne el problema y corregirlo, fue sen-
cilla. La documentación del producto
es muy abundante lo cual facilita el
entendimiento de las advertencias. La
funcionalidad de métricas de código
es muy poderosa, porque permitió te-
ner un panorama claro acerca del nivel
de facilidad de mantenimiento del códi-
go fuente, a pesar de que no estábamos
familiarizados con él. Adicionalmente,
estas herramientas no requieren prác-
ticamente ningún tipo de configura-
ción. Asimismo la conversión de los
www.sg.com.mx
proyectos fue automática. Encontra-
mos y corregimos advertencias sobre
reglas de nomenclatura en los espa-
cios de nombres del código fuente de
SQL Buddy. Por último, éstas pueden
hacer una excelente combinación con
las herramientas de pruebas unitarias,
ya que soportan el establecimiento de
una política de protección de código.
Por otro lado, las herramientas de aná-
lisis y medición de código únicamente
pueden ser aplicadas a ensamblados
administrados, lo cual constituye una
limitación importante ya que no pue-
den procesar código producido en
otros lenguajes predominantes tales
como C++ o Java. Las herramientas de
Visual Studio® 2008 están empotra-
das en el entorno de Visual Studio® la
cual es un producto grande y comple-
jo que en ocasiones puede ser difícil
de instalar. Llevar a cabo la selección
de un subconjunto de alertas relevan-
tes para un proyecto en particular no
es una tarea trivial ya que requiere
conocimiento de los lineamientos de
diseño de la compañía que los produ-
ce. Asimismo, no existe la noción de
severidad dentro de las advertencias
obtenidas que pueda ayudar al desa-
rrollador a decidir por dónde comenzar
a corregir las advertencias.
Por último, las herramientas de aná-
lisis de Visual Studio® 2008 son por
mucho las más fáciles de instalar de
todas las que hemos usado hasta el
momento. De modo que, en depen-
dencia de cuáles atributos de calidad
estés tratando de dar seguimiento y
mejorar en su proyecto, la suite puede
ser de mucha utilidad.
Referencias:
[blogs.msdn.com/fxcop/archive/2007/10/03/
new-for-visual-studio-2008-code-metrics.aspx]
[ dbcommander.sourceforge.net]
[msdn2.microsoft.com/en-us/library/
czefa0ke(VS.71).aspx]
[msdn2.microsoft.com/en-us/vstudio/
products/aa700831.aspx]
[sqlbuddy.sourceforge.net]
MAY-JUL 2008
 Consideraciones Para Migrar un Modelo
de Data Warehouse Multidimensional
El Almacenamiento de Datos en las Empresas
Por Ernesto Ulianov Reyes Romero

E l presente artículo pretende guiar al lector en las consideraciones

que tiene que seguir para migrar de Data Warehouse como una so-
lución para el análisis de la información financiera, el ejemplo esta
referido para una empresa de Telecomunicaciones dedicada a ofre-
cer equipo y servicios de telefonía celular.
~: Antecedentes :~

18 MAY-JUL 2008 www.sg.com.mx

 ~: Antecedentes :~
Las empresas en el mercado de las Telecomunicaciones que
actualmente es un medio muy dinámico y competitivo, deben
considerar mejores estrategias comerciales que estén basa-
das en capturar y retener a los clientes más rentables, siendo
ellos la mayoría de las veces los de mayor consumo. Las es-
trategias tradicionales de ventas y comercialización son desa-
fiadas por estas características del mercado:
• La explosión de tecnología de comunicaciones ha cambiado
rápidamente los tipos de ofertas de servicio disponibles. Hoy
se cuenta con tecnologías de comunicación inalámbricas que
ofrecen capacidades de transmisión suficiente como para
ofrecer servicios tradicionales de voz, TV On Demand, trans-
misión de datos e Internet móvil en un mismo canal.
• La variedad en ofertas y precios ha llevado el poder de compra al
consumidor que cada vez exige mayor valor a un menor precio.
• Las decisiones de lealtad, están volviéndose rápidamente a
ser manejadas por el valor.
• Las empresas están cada vez más enfocadas en la captura y
retención de clientes más rentables lo que implica detectar a
tiempo estas oportunidades.
~: Descripción del problema :~
Se deben exponer la problemática dadas las características
actuales del Data Warehouse y algunas de las razones del por
qué se requiere hacer este proyecto (migración):
1. Se debe visualizar si se requiere migrar tanto de modelo
como la información para tener una mejor integridad de ésta
y que sea más ágil la carga diaria de la información.
2. El modelo debe soportar la estructura actual del Data
Warehouse con la posibilidad de darle un crecimiento a
nuevos nichos de información por la creación de nuevos
servicios que ofrece la compañía.
3. Hacer más eficiente y versátil la extracción de la informa-
ción para su análisis.
4. Se requiere de mejores indicadores que le den infor-
mación puntual a los directivos de cuáles son los productos y
servicios que están funcionando.
5. Este tipo de proyectos requiere de la experiencia de un Lí-
der de Proyecto que conozca de Bases de Datos y que tenga
conocmiento en la elaboración de procesos mediante Proce-
dimientos Almacenados (SP) y la Extracción Transformación y
Carga (ETL). Además requiere de la experiencia en el negocio
de la telefonía celular y el análisis financiero que se hace
de los productos y servicios que ofrecen las compañías de
Telecomunicaciones, así como la obtención de los indica-
dores que evalúan para el análisis financiero.
6. Su crecimiento requiere de un modelo más acorde al vo-
lumen de información que se está manejando, por lo que se
cuestiona si el modelo actual y la plataforma actual sopor-
tarán el crecimiento de toda la información que proporcionan
las diferentes áreas de la compañía.
www.sg.com.mx
Por los motivos anteriores, se deben plantear las siguientes interro-
gantes: ¿El modelo satisface la necesidad creciente del manejo de
información que se tiene actualmente? ¿Se tiene una plataforma acor-
de a las necesidades actuales del Data Warehouse? ¿Se tiene una efi-
ciente extracción de la información para el análisis financiero de forma
que esté disponible para las diferentes áreas de la compañía?
De estos tres cuestionamientos esenciales se determina que se
necesita plantear una solución a las necesidades actuales del
Data Warehouse.
~: Propósito de Desarrollo de un Data Warehouse:~
El propósito en el desarrollo de este tipo de modelos es encontrar
uno que represente una solución al problema y permita hacer la
migración del actual a un modelo multidimensional en una plata-
forma tecnológica que soporte la estructura que se tiene actual-
mente y que pueda crecer, ocupando herramientas orientadas a
la consulta de grandes volúmenes de información histórica, pro-
cesamiento masivo de información, con estructuras dinámicas y
abundantes cambios.
Se debe elaborar un modelo de Data Warehouse acorde al negocio
de las Telecomunicaciones, creando los métodos de carga de infor-
mación diaria así como su extracción para generar niveles de agre-
gación de la información financiera del comportamiento del negocio
que permita al equipo de analistas de la compañía, estudiar todo
aquello que le permita conocer como están las ventas de sus pro-
ductos y servicios, a través del tiempo y visualizar que ocurre con los
movimientos de las terminales, estatus en cuanto a servicios, planes
tarifarios, promociones, etcétera.
~: Particulares del Proyecto de Data Warehouse :~
Para tal fin se deben plantear los siguientes objetivos particulares:
• Implantar un modelo de datos conforme a los requerimientos de in-
formación y análisis definidos por la empresa de la industria de teleco-
municaciones.
• Utilizar una herramienta de extracción y administración de datos,
como puede ser la plataforma de Oracle Warehouse Builder para el
Proceso de Adquisición y Transformación de datos.
• Utilizar herramientas de explotación de datos, para ser empleadas
por los ejecutivos de negocio de la compañía.
• Desarrollar los ambientes de datos significativos para realizar
pruebas de funcionalidad de los procesos de extracción de datos.
• Estudiar los patrones de ingreso por el tipo de tráfico, así como su com-
portamiento en cuanto a saldos y abonos de tiempo aire realizados.
~: Justificación del Data Warehouse :~
Para cualquier compañía, la conveniencia de tener un gran depósito
de información histórica es de suma importancia y sobre todo si esta
información es la financiera, de donde pueden hacer un análisis del
comportamiento de ventas y costos de operación de sus productos
o servicios.Las compañías de Telecomunicaciones no son la excep-
ción, especialmente dada la feroz competencia que se está dando
en este segmento.
MAY-JUL 2008 19
 En primera instancia lo que se pretende es
mejorar el modelo del Data Warehouse para
migrar el contenido de la información utili-
zando uno nuevo que permita tener el cre-
cimiento de los datos que requiere la com-
pañía y acrecentar la información financiera
para saber cómo está operando día con día.
Entre mejor y más oportuno sea el análisis
de la información se podrá encontrar de ma-
nera más oportuna los errores o fallas en los
que se está incurriendo con el fin de mejorar
el ofrecimiento de un bien o servicio que se
le esta brindando al usuario por un costo
más competitivo de lo que ofrece el merca-
do, redundado en mejoras tecnológicas de
comunicación para ofrecer mejores produc-
tos y servicios al alcance de otros sectores
de la población en general.
Poder tener un mejor modelo para el Data
Warehouse resuelve en primera instancia
una problemática de la compañía que im-
pacta de manera mas amplia a la operación
general de ésta y a los beneficios que se le
puede ofrecer al usuario final. El modelo de
Data Warehouse que se vincula con las par-
ticularidades de la información financiera
que es utilizada por la compañía de Teleco-
municaciones, es la aportación tecnológica
que se ofrece para optimizar el análisis fi-
nanciero de la compañía.
Se trabajó en un proyecto donde el Data
Warehouse de una compañía de telefonía
celular se encontraba en una Base de Datos
de SQL Server, donde no había propiamen-
te un modelo y no cumplía con una relación
entre sus entidades, es decir, no existía un
modelo entidad-relación. Aunque existían
algunos catálogos, no se ocupaban para di-
mensionar el detalle de toda la información
financiera que se tenía cargada.
Se pensó en considerar la plataforma tec-
nológica de Oracle 10g para almacenar la
información por tener un motor de bases
de datos más eficaz, su métodos de bús-
queda son más ágiles y por tener la capa-
cidad de hacer modificaciones cuando la
Base de Datos esta operando.
Ernesto Ulianov Reyes Romero, es Maestro en Ciencias de la Computación egresado de la Fundación Arturo Rosenblueth. Profesor de Tiempo Completo de
la Universidad Politécnica de San Luís Potosí y Consultor de Grupo Bizcorp. Por la experiencia como Líder de Proyecto, DBA, Analista y Diseñador se elaboro un
Modelo de Migración de Información a un Data Warehouse Multidimensional para una empresa de Telecomunicaciones. Debido a la relevancia del Proyecto de DW
se desarrollaron habilidades directivas proporcionando información ejecutiva para análisis financieros del negocio, mediante BI.
20 MAY-JUL 2008
En la Base de Datos SQL Server por cada
tipo de información se tiene una base de da-
tos, de la cual no se tiene el control de los
espacios ocupados en disco y no permitía
su fácil acceso a pesar de estar partida en
entidades por mes de información. Además
no se contaba con niveles de agregación y
siempre que se requería obtener informa-
ción se necesitaba obtener del detalle el
nuevo consolidado, que por necesidades de
la empresa, se ocupan y se van almacenan-
do en las diferentes bases de datos.
Para poder instrumentar el modelo, se
plantea que la Meta Data (depósito de gran
volumen de información) se basará en los si-
guientes aspectos:
• Metadata Funcional. Modelo de acceso
de datos, que traduce las definiciones de
la estructura física de la base de datos en
términos del negocio que son entendidos y
empleados fácilmente por los analistas de la
compañía.
• Metadata Técnica. Control y monitoreo de
los procesos de Extracción, Transformación y
Carga (ETL) de la solución (desde el área tem-
poral de archivos o fuentes de información
hasta las estructuras del Data Warehouse de
la compañía), así como el manejo de errores.
Figura 1. Diagrama descriptivo de un modelo de Data Warehouse.
En la figura 1, se muestra un diagrama des-
criptivo del modelo, en donde la zona mar-
cada como la 2, es fundamentalmente la
Meta Data Técnica y la Meta Data Funcional
esta ligada a la zona 1 y 3 que conforman
toda la estructura del modelo en términos
del negocio.
El empleo de una plantilla para la implanta-
ción a partir de un modelo que establece la
relación entre los clientes y el negocio y po-
der realizar el análisis del comportamiento,
permitirá representar y analizar de manera
homogénea a los clientes, cuentas y las ter-
minales de la compañía, ya se traten de Cor-
poraciones, PyME’s o personas físicas.
Aunque pueda definirse de manera concep-
tual la representación de los clientes de los
distintos tipos de servicios ofrecidos, la im-
plantación se debe acotar, por ejemplo a las
terminales del servicio de prepago, donde los
aspectos que pueden ser estudiados son:
- Ingresos por tráfico.
- Activaciones de terminales.
- Movimientos de terminales.
- Abonos de tiempo aire.
- Comportamiento del saldo de terminales.
- Política saldo cero (estatus de una terminal
después de sesenta días de tener saldo cero
y no haber abonado tiempo aire).
www.sg.com.mx
- Churn (estatus de una terminal que esta en
política de saldo cero y que no tiene tráfico
entrante, es decir, no recibe llamadas a su
teléfono del tipo el que llama paga).
- ARPU (ingreso obtenido por el tráfico de lla-
mada entrante y/o saliente a una terminal).
- Financieros.
La solución debe contar con un conjunto
de programas y procesos de manejo de los
datos construidos y validados para altos vo-
lúmenes de información. Estos programas
permitirán la validación, generación de re-
súmenes e indicadores de gestión a partir
del área de interfaz.
~: Acceso a los datos
(aplicación de análisis) ;~
Con el fin de satisfacer las necesidades de
análisis de la información almacenada en el
Data Warehouse, la solución debe contem-
plar la implantación de un portal de análisis
que apoye en los siguientes niveles:
1. Análisis General. Esta área debe permitir
a los analistas conocer la situación general
del negocio a través del empleo de indicado-
res de gestión que les apoyará en responder
preguntas relacionadas a la situación actual,
las tendencias, causas, entre otras.
2. Análisis Detallado. Esta área debe permi-
tir a los analistas conocer la situación detalla-
da de cada uno de las terminales, así podrán
identificarse patrones de comportamiento
de tráfico e ingresos, movimientos, saldos y
tiempo aire de las terminales, identificación
de perfiles de terminales según cierto com-
portamiento, suscriptores a contactar en ini-
ciativas de mercadeo, entre otras.
~: Manejo de Metadata :~
La implantación de la meta data de la solución
se debe basar en los siguientes aspectos:
• Metadata Funcional. Consistirá en la de-
finición de un modelo de acceso a los datos
de la Base de Datos del Data Warehouse que
traduzca las definiciones de las estructuras
físicas de la base de datos en términos del
negocio que puedan ser entendidos y em-
pleados fácilmente por parte de los analis-
tas de la compañía. Además es el modelo de
acceso que será instrumentado empleando
las facilidades ofrecidas por una herramien-
ta que permita tener el acceso más ágil y
eficiente, donde se deberá proveer en forma
oportuna la semántica correspondiente.
www.sg.com.mx
• Metadata Técnica. Apoyará el control y
monitoreo de los procesos de Extracción,
Transformación y Carga (ETL) de la solución
(desde el área temporal de archivos planos
hasta las estructuras del Data Warehouse
de la compañía), así como el manejo de
errores, será implantado una entidad que de
seguimiento de los procesos de carga. Ade-
más se implantarán reportes predefinidos
que permitirán analizar la ejecución de los
programas, con los siguientes datos:
Para Control y monitoreo de carga:
- Identificador del proceso ejecutado.
- Fecha, hora de inicio/ Fecha, hora de fin.
- Cantidad de registros leídos.
- Cantidad de registros procesados.
- Cantidad de registros rechazados.
- Estatus final de ejecución.
Para el manejo de errores:
- Identificador del proceso ejecutado.
- Fecha, hora de inicio.
- Descripción del error.
- Cantidad de registros rechazados.
La arquitectura de referencia se vuelve im-
portante porque aporta:
- Ofrece un diagrama de un anteproyecto común
- Crea una base duradera para implantar la
visión de la empresa.
- Proporciona alternativas en la implantación
- Permite ubicar las ofertas y distribuidores en
el diagrama de la arquitectura de referencia.
- Destaca los componentes de una solución
que son valiosos para la producción.
La arquitectura de referencia describe prime-
ro desde un punto de vista abstracto y simpli-
ficado a alto nivel, del modo siguiente:
- Un conjunto de datos extraídos de la base
de datos operacionales
- Un software que prepara los datos para
que los usuarios accedan
- Un conjunto de aplicaciones y herramien-
tas que ejecutan un conjunto de consultas y
análisis complejos
Una arquitectura que propone Harjnder es
descomponer sistemáticamente en detalles,
partiendo de la Infraestructura, Transporte,
Administración de Meta datos, para ir su-
biendo de nivel, hacia la Fuente de Datos,
Construcción del Data Warehouse, Construc-
ción de los niveles de agregación, Acceso de
Datos y Administración de Datos.
El planteamiento de dicha arquitectura
contempla en su proceso tres fases impor-
tantes: la de Refinamiento, Reingeniería
y después de obtener el modelo de Data
Warehouse otra fase de Refinamiento y Re-
ingeniería, lo que no permite que se haga
un modelo en poco tiempo, ya que requie-
re de varias etapas y fases en cada una de
las etapas, añadiéndole que propone otros
sistemas importantes dentro de la capa de
infraestructura como son: Administradores
de Configuración, Administradores de Alma-
cenamiento, Administradores de Seguridad,
Administración de Distribución, Administra-
ción de Licencias, Vigilantes de desempeño
y Analizadores de la Capacidad.
Todo esto hace que construir el modelo a
implantar se vuelva un proyecto complicado
y largo por lo que sólo se considera el dise-
ño del Data Warehouse y el de las Agrega-
ciones, por tal razón y debido a que el pro-
yecto tiene un tiempo programado de tres
meses se omite los puntos relacionados con
la construcción.
Conclusión
Con lo antes propuesto para iniciar
cualquier proyecto de Data Ware-
house se debe tener bien definido la
problemática, objetivos y alcances del
proyecto, exponiendo los justificantes
que lleven a emprender y satisfacer las
necesidades del proyecto con una me-
todología. Se establecen los principios
en los que se debe elaborar el diseño,
presentando la propuesta a seguir.
Referencias
[ Berthold, M.; Hand, D.J. Intelligent Data Analysis, An In-
troduction. Springer 1999 ]
[ Corey, Michael J., Abbey, Michael. Oracle Data Ware-
housing, Oracle Press. Osborne/Mc Graw-Hill. 1997 ]
[ Edwards, John. Building the Right Data Mart. Oracle Ma-
gazine. U.S. Marzo/Abril 1998 ]
[ Harjner, S. Gil y Prakash C. Rao. La integración de la
información para la mejor toma de decisiones data ware-
housing. Prentice Hall Hispanoamérica, 1996, México ]
[ Inmon, W.H. et al. Managing the data warehouse, John
Wiley, 1997 ]
MAY-JUL 2008 21
MAY-JUL 2008 www.sg.com.mx
www.sg.com.mx MAY-JUL 2008
 // ENTREVISTA

Conoce a los
Key Speakers de SG’08
John es CTO en JackBe Corporation, y es reconocido como una
de las mentes más influyentes en el área de cómputo empre-
sarial distribuido. Durante su carrera ha sido reconocido como
Sun Distinguished Engineer, y seleccionado como miembro del
“Dream Team” de desarrollo de software por la revista Soft-
ware Development. Es co-autor del afamado libro “Core J2EE
John Crupi

Patterns” y es un conferencista frecuente en congresos interna-

cionales tales como JavaOne, AjaxWorld y SOAWorld.

¿Donde se encuentra la industria en cuanto a estándares para

mashups?
El concepto de mashups empresariales todavía es nuevo, y no
hay estándares “oficiales” todavía. Ante esto, lo que nosotros
(JackBe) hemos hecho es crear tecnologías en base a estándares
existentes. Por ejemplo, creamos un metalenguaje para definir
mashups llamado Enterprise Mashup Markup Language (EMML)
el cual está basado en estándares como XML, Xpath y Xquery.

IBM recientemente formalizó su entrada al
espacio de enterprise mashups. ¿Qué sig-
nifica esto para ustedes?
El hecho de que empresas como IBM entren
en este segmento confirma su importancia y
validez. Si ellos están entrando, es porque
ven que hay un valor para sus clientes. Ade-
más de JackBe, IBM es el único proveedor de
software que ha creado su tecnología para
mashups desde cero. Pero el problema que
enfrentan es lograr integrarlas exitosamente
en los universos de Websphere y Lotus, que
son grandes, complejos, y algo viejos.
¿Dónde nos encontramos en términos de
una base de usuarios acostumbrada/dis-
puesta a hacer mashups?
Los usuarios de negocio han estado hacien-
do mashups desde hace más de 15 años; lo
llaman Excel. El problema es que normal-
mente dedican la mayoría de su tiempo a
reunir, copiar, pegar y unir los datos que ne-
cesitan para poder tomar decisiones. ¿Por
qué realizan todo este esfuerzo? Porque no
tienen opción. Los datos se encuentran en-
cerrados en su ERP, aplicaciones internas y
sistemas de información empresarial.
Los departamentos de TI se han enfocado en
generar almacenes de datos y normalizar/
denormalizar grandes cantidades de infor-
mación. Pero esto no es lo que requieren los
usuarios, ellos necesitan pequeñas rebanadas
de información combinada. Pero como cada
uno requiere un pequeño conjunto, TI no les
hace caso porque son cosas muy pequeñas y
no pueden dedicarles tiempo.
Java EE ya no suena tanto como antes. ¿Crees
que esté perdiendo importancia? ¿Qué crees
que suceda con Java EE en el futuro cercano?
Yo creo que Java EE seguirá dominando el
segmento de aplicaciones web transaccio-
nales. Sin embargo, para web services y
mashups que no manejan estado (stateless),
Java EE no tiene mucho sentido. De hecho,
con Tomcat tienes todo lo que necesitas.
¿Crees que los lenguajes y frameworks
como Ruby/Rails, Python/Django, Groovy/
Grails penetrarán el mercado empresarial?
Creo que todos los lenguajes dinámicos ten-
drán una penetración importante en el espacio
empresarial en los próximos años. Es de gran
utilidad no tener que compilar, empaquetar e
instalar algo simplemente para obtener nue-
vos datos. Los lenguajes estáticos están en
recesión, los dinámicos son el siguiente paso.
¿Qué te gusta más, desarrollar tecnologías
o evangelizarlas?
Me apasiona evangelizar sobre lo que mis
colegas y yo desarrollamos. También disfru-
to mucho construir demos para demostrar
posibilidades de solución a un problema.
¿Qué se siente trabajar en una empresa
startup, sobre todo después de haber traba-
jado en una empresa tan grande como Sun?
Es muy divertido, pero debes tener nervios
de acero. Existen muchos factores desco-
nocidos, pero tienes una visión que puede
moldear el futuro. Da una enorme satisfac-
ción cuando funciona.
¿Algunas palabras de sabiduría para nues-
tros lectores?
Empiecen a considerar los enterprise mash-
ups y widgets como la nueva generación de
micro-soluciones. Los mashups le quitan
muchos dolores de cabeza a la integración
y pueden traer grandes beneficios tanto a
desarrolladores como a usuarios.

24 MAY-JUL 2008 www.sg.com.mx

 Terry Quatrani

Terry Quatrani es evangelista en jefe de UML en IBM Corporation.

Como tal, es responsable de entrenar y asistir a los principales
clientes de IBM para adoptar prácticas de modelado visual y
orientación a objetos. Terry es una conferencista frecuente
en eventos como el Rational User Conference, OOPSLA, y SD
West/East. Es autora de la serie de libros “Visual Modeling
with Rational Rose and UML”, y también es colaboradora fre-
cuente en la revista Dr. Dobbs Journal.

¿Qué disciplinas del desarrollo de software se benefician más

del uso de modelado visual?
Creo que el modelado visual trae beneficios a un proyecto de
software a lo largo de todo su ciclo de vida, para: administrar
complejidad, detectar errores y omisiones, comunicar a los in-
volucrados, entender requerimientos, dirigir la implementación,
entender el impacto del cambio, y asegurar que los recursos de
infraestructura sean utilizados adecuadamente.

Qué tanto modelado se haga, y durante qué actividades, ya depen- gación para un front end sencillo de una base de datos. Simplemente
derá del proceso, proyecto y experiencia de los modeladores. aplico la transformación, ¡y la aplicación se genera por completo!

UML 2 ya tiene varios años en el mercado, pero la mayoría de las
organizaciones todavía utilizan UML 1.x ¿A qué se debe esto?
El principal problema que retrasó la adopción de UML 2 en un
principio fue la falta de soporte en las herramientas de modela-
do. De hecho, creo que a la fecha ninguna herramienta soporta
UML 2 por completo.
Aun así, cada vez hay más organizaciones que utilizan UML 2 y le en-
cuentran ventajas. Una de las fortalezas de UML 2 es el soporte para
diagramas de secuencia, que me parece maravilloso. Otra fortaleza
de UML 2 son las clases estructuradas. Sin embargo, la adopción de
estas capacidades no es muy amplia, ya que solo tienen sentido para
aquellos que están modelando arquitecturas orientadas a servicios,
o sistemas de tiempo real. Creo que conforme más organizaciones
se muevan a SOA, aumentará significativamente el uso de UML 2.
¿Qué está sucediendo en el área de MDA (Model Driven Architecture)?
Hace un par de años era un tema muy popular y hoy casi no se
escucha nada al respecto.
La industria está adoptando MDA sin que se haga mucho ruido al res-
pecto. Tengo varios clientes que actualmente realizan transformacio-
nes de MDA bastante sofisticadas. De hecho, en la arquitectura de Ra-
tional Software Architect hacemos uso extensivo de transformaciones.
Ya no “generamos” código, sino que lo “transformamos”. Yo tengo un
demo que doy en algunas pláticas, el cual tiene un modelo de nave-
Llevamos varios años sin llegar a un consenso sobre qué lenguaje/
notación usar para modelar procesos de negocio. ¿Cuál es tu opi-
nión al respecto?
Creo que el estándar que prevalecerá es BPMN. Esta es la notación
con la que la gente de negocio se siente cómoda, ellos no quieren
usar UML. Habiendo dicho eso, creo que aquí es donde MDA pue-
de ser de gran utilidad. Por ejemplo, actualmente existen herra-
mientas que pueden leer un modelo creado por una herramienta
de modelado de negocios en BPMN, y hacer la transformación en
tiempo real hacia UML. De esta forma, se obtiene lo mejor de dos
mundos: BPMN para la gente de negocio y UML para la gente de
software y sistemas.
¿Qué libros le recomiendas a los lectores de SG?
¡Por supuesto que mi libro (Visual Modeling with Rational Rose)!
Jaja. Ya en serio, el libro que más recomiendo sobre UML es “UML
Distilled” de Martin Fowler.
¿Has estado previamente en México?
No, esta será mi primera visita y estoy bastante emocionada por conocer
el país y ver qué están haciendo las organizaciones de software allá.
¿Alguna recomendación final para los lectores?
Sigan modelando, pero solo utilicen lo que necesitan. No modelen
simplemente por modelar.

www.sg.com.mx MAY-JUL 2008 25

 // ENTREVISTA

Jon “maddog” Hall es Director Ejecutivo de Linux Interna-

Jon “maddog” Hall

tional, una asociación dedicada a promover el software

libre, y CTO de Koolu, una empresa canadiense dedicada
a llevar cómputo verde a países en desarrollo. El señor
Hall es un conferencista altamente solicitado, y ha fungido
como asesor en el tema de uso y aprovechamiento de
software libre para los gobiernos de China, Malasia y
Brasil, así como para las Naciones Unidas.

Nos enteramos que estás involucrado con un programa

llamado Hackerteen. ¿Podrías decirnos de que se trata?
Hackerteen es un programa educativo creado por mi buen
amigo Marcelo Marques en Brasil. Lo que sucedió es que la
policia se dio cuenta que una buena parte de las personas que
“craqueaban” los sistemas en realidad eran niños que usaban
scripts de Internet para entrar a sistemas que no estaban de-
bidamente protegidos.

Ellos le pidieron a Marcelo que los ayudara a
resolver esto, así que creó Hackerteen, que
es un programa de educación virtual, don-
de enseña a los adolescentes a aplicar esa
curiosidad y tiempo en Internet hacia algo
de provecho. Se les enseña sobre seguridad
computacional, ética de hacking, y cómo ser
emprendedores. Está diseñado de forma que
es muy atractivo para los adolescentes, ya que
combina elementos de juegos de rol, anime, y
un esquema de progresión como el del Karate
donde los alumnos van subiendo de cinta.
Yo he sido consultor para el programa desde
hace varios años y he visto el cambio positivo
que genera en los jóvenes que participan, ade-
más de que les da una excelente base en caso de
que quieran trabajar en el área de computación.
Sabemos que eres CTO en una empresa
llamada Koolu, ¿puedes hablarnos un poco
sobre ella?
El propósito de Koolu es llevar a los países
en desarrollo sistemas de cómputo amiga-
bles con el ambiente y con el usuario. La tec-
nología de Koolu utiliza clientes delgados
en conjunto con aplicaciones Web 2.0 para
que los usuarios puedan dedicar todo su
tiempo a hacer lo que quieren, y no pierdan
tiempo en cosas como instalar/actualizar
programas, eliminar virus, etcétera. Parte
de la visión de Koolu es generar empleos de
tecnología bien pagados en las economías
locales. Actualmente estamos haciendo un
piloto de esto en Costa Rica, con un cliente
llamado Datatell.
¿Cómo aporta Linux al “cómputo verde”?
Linux tiene varias capacidades que contri-
buyen al cómputo verde, tales como apagar
discos y bancos de memoria cuando no es-
tán en uso. Linux también es bastante fuer-
te en el área de virtualización, y a través de
ésta se puede lograr una mayor eficiencia.
Por otro lado, el software libre es mucho
más que Linux, y aquí la comunidad puede
tener una gran contribución, desarrollando
software más eficiente, que haga mejor uso
de la energía.
¿En qué áreas de TIC dirías que Linux está
liderando el camino?
Creo que la pregunta adecuada sería ¿en qué
áreas no está liderando el camino? Y otra vez,
me gustaría puntualizar que no solo me refie-
ro a Linux, sino al software libre en general.
En el último par de años hemos atestiguado
el surgimiento de tecnologías basadas en
software libre como Asterisk, MythTV, y Li-
nuxMCE que están teniendo un gran impac-
to tanto en las empresas como los hogares.
A pesar de los avances de Linux en otras
áreas, en el desktop sigue con una parti-
cipación pequeña. ¿Consideras que esto
cambiará pronto o seguiremos viendo un
avance lento de Linux en el desktop?
La vida es un río. Hace 15 años, que es
cuando yo me involucré con Linux, el escri-
torio era básicamente un servidor de X Win-
dows y un administrador de ventanas. Ahora
tenemos un desktop completo con muchas
aplicaciones sofisticadas. En ese entonces,
los vendedores de computadoras ni de locu-
ra hubieran vendido máquinas con Linux. En
cambio, hoy muchas empresas venden Linux
preinstalado. De hecho, en algunas compu-
tadoras como la Eee PC es el default.
Lo que quiero decir es que seguimos avan-
zando, y aunque todavía estamos lejos de
ser el sistema dominante en el desktop,
estamos muy cerca de ser un jugador im-
portante (que yo estimo que sería cuando
lleguemos a un 25% del mercado). Cuando
esto suceda, muchas cosas cambiarán.
¿Alguna recomendación para los lectores
de SG?
Sí. Lleven a un usuario de Windows a su
próximo evento de software libre. Mejor
que sean dos. Muéstrenle software libre en
el desktop, servidores, etcétera y denles un
live-CD para que ellos mismos puedan pro-
barlo en sus computadoras.
Únanse a SoftwareFreedomDay.org y prego-
nen sobre el software libre. Recuerden de-
cirles que es “libre como en libertad”, y que
no deberían ser esclavos de los vendedores
de software propietario. Carpe Diem!.

26 MAY-JUL 2008 www.sg.com.mx

16
 agamos un viaje en el tiempo hacia principios
de esta década …

Acabábamos de sobrevivir el año 2000 sin que se

cayera el mundo, y en el campo de la programación la palabra que
más sonaba tenía cuatro letras y su logo era una taza de café. Java
era EL lenguaje de programación y reunía lo mejor de lo mejor ya
que era orientado a objetos, multiplataforma, y abierto (todavía no
era libre, pero había acceso al código fuente). Además, con J2EE y
J2ME se cubría el espectro desde dispositivos móviles hasta sistemas
empresariales distribuidos. Todo parecía indicar que hacia el futuro
Java sería el lenguaje de programación que se utilizaría para todo, y
por lo tanto el único que sería necesario aprender.

Regresamos al presente, y si echamos un vistazo a las noticias, ar-

tículos y foros relacionados con desarrollo de software, nos encon-
tramos con cosas como Ruby (con su framework Rails), Python,
Erlang o Scala. En el frente de Microsoft, resulta que tienen una
plataforma llamada .NET sobre la cual se ejecutan una gran diver-
sidad de lenguajes, desde Cobol hasta algo llamado C#, y continua-
mente se agregan nuevos lenguajes (F#, IronPython) y capacidades
para los lenguajes (LINQ). En el frente de Java, encontramos que
hay un gran debate sobre las características que se deben incluir en
Java 7, y que por un lado hay quienes creen que este debería mante-
nerse como un lenguaje sólido, estable, con poca innovación, y por
otro lado quienes consideran que debe incorporar nuevas caracte-
rísticas que le permitan mantenerse a la vanguardia.

La conclusión es que de pronto los lenguajes de programación son

relevantes otra vez. No es que hubieran dejado de ser importantes,
sino que llegamos a pensar que ya eran un tema resuelto. Es así que
dedicamos las siguientes páginas a estudiar las tendencias que están
marcando este denominado...

28 MAY-JUL 2008 www.sg.com.mx

 de
los

www.sg.com.mx MAY-JUL 2008 29

 ¿Hacia dónde van los lenguajes de programación?
Un Vistazo al Pasado, Presente y Futuro
Por Ariel Ortiz Ramírez
o aprendí a programar usando una micro-
computadora Timex Sinclair 2068 a mediados
de los años ochenta. Esta maquinita tenía 72 KB
de memoria, usaba una grabadora convencional
como dispositivo de almacenamiento secunda-
rio, y venía de fábrica con un intérprete de Sin-
clair BASIC. Este dialecto de Basic usaba núme-
ros de línea frente a cada enunciado. Había que
usar la instrucción GOTO para realizar repeti-
ciones, GOSUB para llamar subrutinas, y todas
las variables eran globales. Comparado con las
herramientas que tenemos disponibles hoy en
día, este era un ambiente muy primitivo, pero
aún así podía pasar largas horas programando
felizmente ese aparatito.
Muchas cosas han cambiado en las últimas dos
décadas. Sin embargo, los avances en el campo
de los lenguajes de programación han sido más
una evolución que una revolución.
En las siguientes secciones describo brevemente
las tendencias más importantes que, desde mi
punto de vista, marcarán las pautas en el diseño
de los lenguajes computacionales que estaremos
utilizando en los años por venir.
~:Programación funcional :~
La programación funcional es un estilo de pro-
gramación basado en la utilización de funciones
matemáticas. El cálculo lambda, desarrolla-
do por el matemático norteamericano Alonzo
Church en la primera mitad del siglo veinte, es
la base teórica de este estilo de programación.
Lisp, Haskell, ML y Erlang son ejemplos de len-
guajes funcionales.
30 MAY-JUL 2008
Las operaciones de cómputo en la programación
funcional se llevan a cabo a través de la evaluación
de expresiones que producen valores y que están
libres de efectos secundarios. Por el contrario,
en el estilo de programación imperativa, al cual
pertenecen la mayoría de los lenguajes conven-
cionales, el énfasis está en ejecutar enunciados
que precisamente producen efectos laterales. En
este caso, el principal efecto lateral es la mutación
explícita de los valores contenidos en memoria.
Las variables en los lenguajes funcionales son
parecidas a las variables de álgebra. Esto es, una
variable representa un valor inicialmente des-
conocido, pero una vez que se conoce, este ya
no cambia. En contraste, en los lenguajes impe-
rativos una variable es simplemente el nombre
de una localidad de memoria cuyo contenido
puede ser arbitrariamente leído y/o modificado.
Gracias a que las variables son asignables una
sola vez, los programas funcionales cuentan con
una propiedad conocida como transparencia
referencial. Se dice que una expresión es refe-
rencialmente transparente si puede ser rempla-
zada por su valor, pero sin alterar los resultados
producidos por el programa. La transparencia
referencial es importante porque permite al pro-
gramador, o al traductor del lenguaje, razonar
sobre el comportamiento del programa. Este
tipo de razonamiento es útil para probar que un
programa es correcto, optimizar código a través
de cachés, eliminar sub-expresiones comunes,
simplificar algoritmos, e incluso parelelizar la
evaluación de sub-expresiones.
Los lenguajes funcionales han introducido im-
portantes conceptos que han sido posterior-
mente incorporados en muchos otros lenguajes.
Uno de los más notables es el referente a la re-
colección de basura, en donde el ambiente de
ejecución, y no el programador, es responsable
de determinar cuando cierto objeto de memoria
ya no es usado por el programa y por lo tanto
puede ser reutilizado en alguna otra parte. Lisp
fue el primer lenguaje que usó esta técnica, ocu-
rriendo esto a finales de los años cincuenta. Sin
embargo, todavía a inicios de la década de los
años noventa había poco respeto por parte de
la industria de software hacia los lenguajes que
hacían uso extensivo de recolección de basura,
debido principalmente al costo de ejecución en
el que se incurre. Gracias a la atención que gene-
ró Java en la última década, hoy en día práctica-
mente todos los lenguajes considerados “moder-
nos” incorporan recolección de basura.
Otros conceptos importantes en que los lengua-
jes funcionales han sido pioneros incluyen: fun-
ciones como objetos de primera clase, cerraduras
léxicas, recursión, tipos dinámicos, inferencia de
tipos, y meta-programación.
~:Lenguajes dinámicos :~
Un lenguaje de programación dinámico es un
lenguaje de alto nivel que lleva a cabo en tiempo
de ejecución muchas acciones que otros lenguajes
típicamente llevan a cabo en tiempo de compila-
ción. Estas acciones incluyen cosas como agregar
y evaluar código, modificar el sistema de tipo de
datos, añadir propiedades a objetos, etcétera. En
esta categoría de lenguajes están Lisp, Smalltalk,
Tcl, JavaScript, Python, Ruby, Perl, PHP y Gro-
ovy. Dada su naturaleza, los lenguajes dinámicos
www.sg.com.mx
son normalmente interpretados, aunque sí exis-
ten compiladores para algunos de ellos.
Recientemente mucha gente ha tomado interés
en los lenguajes dinámicos. Una de las principa-
les razones es el incremento en la productividad
que se logra al usarlos. Por ejemplo, es común
que un programa escrito en Ruby o Python re-
quiera entre 2 a 10 veces menos código que su
equivalente en lenguaje C o Java. Usualmente
un programa que es más pequeño toma menos
tiempo en escribirse, es más fácil de comprender
y modificar, y contiene menos errores que uno
de mayor tamaño. Claro, esto no viene sin algu-
nos inconvenientes. No es inusual que un pro-
grama escrito en un lenguaje dinámico llegue
a ser decenas o incluso hasta centenas de veces
más lento que un programa escrito en un len-
guaje convencional compilado. Para cierto tipo
de aplicaciones esto puede ser irrelevante.
Por ejemplo, imaginemos que tengo un cierto
problema que debo resolver escribiendo un pro-
grama. Supongamos que si lo escribo en Python
me llevaría dos horas, pero si lo hago en lenguaje
C me llevaría diez. Por otro lado, supongamos
que si ejecutara el programa en Python, éste tar-
daría cinco segundos mientras que el que está
escrito en C tardaría 0.01 segundos. Bajo estos
escenarios hipotéticos, tardaría cinco veces más
en escribir mi programa en C en lugar de Python,
pero al momento de ejecución el programa de
C sería 500 veces más rápido. Entonces, ¿qué
escenario me ofrece el mejor beneficio? Cuando
una computadora costaba millones de dólares, el
costo del tiempo de un programador era desde-
ñable. Pero hoy en día es generalmente al revés.
www.sg.com.mx
Si mi programa hipotético sólo va a ser ejecutado
una vez por semana, me conviene más usar un
lenguaje en donde pueda ser más productivo y
donde el tiempo de ejecución es prácticamente
insignificante. Por otro lado, si el programa lo van
a usar miles de usuarios varias veces por día, segu-
ramente debo reconsiderar mis prioridades.
Existen también ocasiones cuando hay factores
externos al programa mismo que constituyen
cuellos de botella que difícilmente se pueden
eliminar con la elección del lenguaje de progra-
mación a usar. Por ejemplo, el desempeño de
una aplicación Web puede estar sujeto al ancho
de banda de los clientes, el tiempo de respuesta
del manejador de base de datos o los servicios
Web que se utilizan, etcétera. Si estos factores
corresponden a la mayor parte del tiempo de
ejecución de la aplicación, y a menudo así ocu-
rre, entonces el beneficio de usar un lenguaje
más rápido es prácticamente imperceptible.
Otra desventaja que algunas personas han seña-
lado con los lenguajes dinámicos es el relativa-
mente limitado soporte que existe para ellos en
las herramientas de desarrollo, particularmente
los IDEs. Esto se debe a que la mayoría de los
lenguajes dinámicos no usan declaraciones ex-
plícitas de tipos, y esto complica significativa-
mente cosas como la facilidad de autocompletar
código y la refactorización.
Muchos de los lenguajes dinámicos son con-
siderados también como lenguajes de script, o
guiones. Un lenguaje de script sirve como pe-
gamento para combinar diversos componentes,
los cuales pueden ser otros programas, utilerías
del sistema operativo, o elementos de una in-
terfaz gráfica de usuario. El término script hace
alusión a los guiones que su usan en el cine o
teatro. En el pasado, los lenguajes de script eran
llamados batch languages (lenguajes de lotes) o
job control languages (lenguajes de control de
trabajos), y probablemente los ejemplos más
representativos de éstos eran JCL en los equi-
pos mainframe, los shell scripts de Unix, y los
archivos .BAT de DOS. Hoy en día,este tipo de
lenguajes se usan extensivamente para realizar
tareas de mantenimiento de un sistema, facili-
tar la adecuación de la funcionalidad de alguna
aplicación, enriquecer la interacción de usuario
desde un browser, o simplificar la programación
de páginas con contenido dinámico generadas
por un servidor de web.
~:Programación paralela :~
La comercialización masiva de los primeros
chips con múltiples núcleos (multi-core) en el
año 2005 dio lugar a lo que se conoce como el
fin del almuerzo gratis. En el pasado no muy lejano,
un desarrollador podía escribir un programa sin
preocuparse mucho sobre su desempeño, pues
sabía que en relativamente poco tiempo el nue-
vo hardware correría su programa, sin modifica-
ción alguna, de manera más rápida (por eso el
término almuerzo gratis). Sin embargo, las ve-
locidades de los microprocesadores ya no se han
estado incrementado como estábamos acostum-
brados. La Ley de Moore establece que el núme-
ro de transistores que se pueden retacar en un
solo chip se duplica aproximadamente cada 18
meses. Esto típicamente se traducía en CPUs co-
rriendo a más megahertz cada año. Sin embargo,
MAY-JUL 2008 31
 este aumento en velocidad de reloj ya no es sostenible
por cuestiones de calentamiento y consumo de energía.
Esto no quiere decir que la Ley de Moore ya no se cum-
pla, pero ahora lo que están haciendo los fabricantes de
microprocesadores es usar esos transistores adicionales
para añadir más núcleos a los CPUs. Un núcleo es bási-
camente una unidad de procesamiento, que incluye re-
gistros, unidades de ejecución y memoria caché. Hoy en
día, muchos servidores, equipos de escritorio y de cómputo
portátil cuentan con CPUs con 2, 4 o más núcleos. Incluso
empresas como Intel, IBM y Sun Microsystems ya están ha-
blando de procesadores many-core, con decenas o centenas
de núcleos para los años venideros.
Ahora bien, hay un problema muy grande: un programa
no se beneficia del nuevo nivel de paralelismo inherente
en los sistemas multi-core, a no ser que haya sido di-
señado explícitamente para ello. Lamentablemente, la
mayoría de los programadores no saben cómo escribir
programas paralelos. Esto se debe probablemente a dos
causas: 1) esta es una habilidad que sólo habían reque-
rido la gente de nichos muy específicos que utilizan su-
percomputadoras, grids y clusters; 2) escribir programas
paralelos correctos es considerablemente más difícil que
escribir programas secuenciales, al menos usando la ma-
yoría de las herramientas disponibles en la actualidad.
Desde hace un par de décadas han existido dos modelos
de programación concurrente:
* Hilos con estado compartido. Se tiene una región de
memoria compartida por dos o más hilos de ejecución.
Para evitar que dos hilos entren en una condición de ca-
rrera (los hilos intentan modificar el mismo contenido
de memoria al mismo tiempo) se debe usar algún meca-
nismo de candados para garantizar una exclusión mutua.
Los candados pueden ser semáforos, monitores, etcétera.
Sin embargo, el uso de candados conlleva a otro tipo de
problemas potenciales como son los candados mortales
(deadlocks) y la inanición.
* Paso de mensajes. Los procesos se comunican entre
sí a través del envío y recepción de mensajes asíncronos.
No hay memoria compartida entre los procesos, por lo
tanto no se requieren candados.
Casi todos los lenguajes usados en la industria usan hilos
con estado compartido. Debido a la complejidad inhe-
Ariel Ortiz Ramírez es profesor de planta del Departamento de Tecnologías de Información y Computación del Tecnológico de Monterrey, Campus Estado de
México. Desde 1988 ha estado impartiendo una gran variedad de cursos relacionados con programación en donde ha utilizado los lenguajes Basic, Pascal, C,
C++, C#, Java, JavaScript, Scheme, Prolog, Python, Ruby, Erlang y diversos ensambladores. Sus principales áreas de interés son los lenguajes de programa-
ción, la educación en ciencia de la computación y el software libre. www.arielortiz.com
32 MAY-JUL
MAY-JUL 2008
2008
rente de este modelo, diversos lenguajes han sido exten-
didos con bibliotecas y/o directivas especiales que simpli-
fican la escritura de programas paralelos. OpenMP, por
ejemplo, es un API para C++ y Fortran que permite de
manera relativamente sencilla paralelizar ciclos. El Task
Parallel Library (TPL), disponible para C# 3.5, ofrece
facilidades similares.
El paso de mensajes, por otro lado, ofrece un mayor nivel
de abstracción ya que el programador no tiene que inte-
ractuar con las primitivas de bajo nivel asociadas normal-
mente con los hilos. El lenguaje Erlang soporta este mode-
lo de programación y ha sido usado de manera extensiva
en el dominio de las telecomunicaciones para alcanzar un
alto grado de paralelismo. Un programa en Erlang que
haga uso de cientos o hasta miles de procesos puede en
principio tener una excelente escalabilidad en cuanto se
ejecute en un sistema con un mayor número de núcleos.
~: Lenguajes multi-paradigmas :~
En los años ochenta Smalltalk era el lenguaje más re-
presentativo de la programación orientada a objetos.
Pero para la mayoría de los programadores de esa época,
Smalltalk era simplemente muy diferente a lo que esta-
ban acostumbrados. La programación orientada a obje-
tos comenzó a tomarse en serio en la industria hasta que
los lenguajes convencionales fueron modificados para so-
portar dicho estilo de programación. Así surgieron C++
y Object Pascal, sólo por nombrar los más populares.
Este esquema de lenguajes que soportan más de un es-
tilo o paradigma de programación sigue siendo la nor-
ma hasta nuestros días. Ruby y Python son lenguajes
dinámicos y orientados a objetos, pero también tienen
elementos que les permiten ser usados como lenguajes
funcionales. Erlang es un lenguaje funcional, concurren-
te y distribuido. El lenguaje Oz soporta programación
lógica, funcional, orientada a objetos, basada en restric-
ciones, distribuida y concurrente.
~: Plataformas de programación :~
Hoy en día, el desarrollo de software tiende a ser algo
más enfocado a programar en una plataforma y no tan
solo en un lenguaje. Es decir, tenemos ahora programa-
dores y/o desarrolladores de web, de JEE y de .NET.
www.sg.com.mx
www.sg.com.mx
Parece que la época del programador mono-lin-
güista está llegando a su fin. Por ejemplo, un de-
sarrollador de web debe conocer varios lenguajes
para hacer su trabajo, incluyendo HTML, CSS,
JavaScript, y algún framework para usar Ajax
como JQuery o Prototype, y todo esto sólo para
la programación del lado del cliente; del lado del
servidor probablemente requiera saber SQL, un
framework para algún lenguaje de programa-
ción en particular, y un lenguaje de plantillas
para la generación de contenido dinámico. ¿Por
qué se requieren tantos lenguajes para desarro-
llar una aplicación de este tipo? Porque cada len-
guaje tiene una función particular que los otros
simplemente no pueden hacer, o sí lo pueden
hacer pero de manera menos conveniente.
JRuby, Jython y Groovy son lenguajes dinámi-
cos diseñados también para simplificar y agilizar
el desarrollo sobre la plataforma Java, sin perder
la facilidad de operación con código de Java. Es
claro ahora más que nunca que lo valioso de la
tecnología Java es su plataforma (la máquina vir-
tual y su extensa biblioteca) y no tanto el lengua-
je de programación en sí. Algunos han afirmado
que Java se ha convertido en el nuevo Cobol. A
mi me parece mas bien que Java es el nuevo C.
Así como en Unix la infraestructura básica (nú-
cleo, utilerías, bibliotecas) está escrita en lengua-
je C, y todo se une con scripts y aplicaciones es-
critas en lenguajes de más alto nivel (tales como
Perl, Tcl o Python), así también podría ocurrir
con Java y los otros lenguajes ya mencionados.

En la actualidad, las plataformas Java y .NET
reflejan también la importancia de poder com-
binar lenguajes, y así ofrecer al desarrollador
la opción de usar la mejor herramienta para el
problema en cuestión. Por ejemplo, Scala es un
lenguaje que corre en la plataforma Java, y que
reúne lo mejor de muchos mundos. Es orien-
tado a objetos y funcional, soporta el modelo
de concurrencia por paso de mensajes. Usa un
sistema de tipos estáticos pero con inferencia au-
tomática. Puede usarse como lenguaje de script
e interactuar con código de Java existente.
Algo similar ocurre en la plataforma .NET. De
hecho, a diferencia de la máquina virtual de
Java, que fue diseñada específicamente para ese
lenguaje de programación, la máquina virtual
de .NET, conocida como el Common Language
Infrastructure (CLI), fue diseñada desde el prin-
cipio para soportar múltiples lenguajes y sus in-
teracciones. Aunque C# es el caballito de batalla
del CLI, existen decenas de lenguajes diseñados
para esta plataforma. Por ejemplo, F# es un len-
guaje funcional y orientado a objetos, derivado
principalmente del lenguaje ML. También hay
implementaciones de Python y Ruby para el CLI,
llamadas respectivamente IronPython e IronRuby.

Conclusión

En la actualidad hay muchas cosas interesantes ocurriendo en el área de lenguajes de progra-

mación. Después de años de estar estudiando diferentes lenguajes, me resulta claro que difí-
cilmente encontraremos un lenguaje único y perfecto. Lo mejor que podemos hacer es sacarle
el mayor provecho a lo que tenemos disponible hoy en día, y estar en la mejor disposición de
aprender las nuevas herramientas que vayan apareciendo.

Sólo hay dos tipos de lenguajes de programación:

los que son el objeto de las quejas de todo mundo
y los que nadie usa.
/ Bjarne Stroustrup, autor de C++

www.sg.com.mx
www.sg.com.mx MAY-JUL
MAY-JUL 2008
2008 33
 Más allá de los Objetos
C# Desde un Punto de Vista Funcional
Por Miguel Ángel Morán
urante muchos años los científicos de la
computación han buscado diferentes paradig-
mas que permitan una mejor y más efectiva
comunicación entre el programador y la com-
putadora. De hecho, los principios que rigen la
programación actual fueron diseñados aún antes
de que existieran físicamente las computadoras.
Por ejemplo, en la década de los treinta Alan Tu-
ring formalizó matemáticamente el concepto de
algoritmo, que es la base de la resolución de pro-
blemas mediante máquinas y antecedente directo
de la programación imperativa, y Alonzo Church
presentó el cálculo lambda que proporciona el
fundamento de la programación funcional.
El paradigma de la programación orientada a
objetos (POO) básicamente consiste en que pri-
mero se describe el mundo (dominio) mediante
la definición de ciertos tipos (clases), y luego se
resuelve el problema deseado mediante la in-
teracción entre los objetos (que son instancias
de las clases). Es evidente que la programación
POO se ha convertido en un estándar de facto
para muchas de las plataformas de programación
comerciales y esto no es casualidad, debido a su
marcada analogía con el mundo real. Aun así, es
necesario que nos hagamos la pregunta:
… ¿y qué hay más allá de los objetos?
La figura 1, muestra una clasificación de lengua-
jes de programación, de acuerdo a su paradigma.
Figura 1. Clasificación de los lenguajes.
Miguel Ángel Morán B. es Microsoft Most Valuable Professional (MVP) en C# y Microsoft Certified Trainer (MCT). Es Licenciado en Informática por la UNITEC y cuenta con 11 años
de experiencia desarrollando profesionalmente. Es socio fundador de DevWorx, empresa de alta innovación tecnológica, y participa en la comunidad DevelopersDotNet.com donde frecuente-
mente escribe y organiza eventos sobre tecnología. miguel.moran@devworx.com.mx
34
28 MAY-JUL 2008
Haciendo una analogía con los lenguajes huma-
nos, sabemos que la lengua española tiene fuer-
tes similitudes con aquellas de origen común al
latín. Algo similar sucede con los lenguajes de
programación, ya que 2 lenguajes provenientes
de la misma familia comparten muchas caracterís-
ticas en común, mientras que lenguajes de distintas
familias funcionan de forma muy diferente y por
lo tanto es más difícil poder dominar ambos.
A pesar de esta gran diferencia, en los últimos años
los lenguajes de una familia están incorporando ca-
pacidades de otra, generando lo que podríamos lla-
mar lenguajes híbridos (o multi-paradigma). Tal es
el caso de C#, el cual conforme su evolución, ha ido
incorporando capacidades de lenguajes funcionales.
Entonces, para contestar la pregunta original, al
parecer lo que está más allá de los objetos es la
programación multiparadigma, especialmente
la incorporación de capacidades funcionales en
lenguajes orientados a objetos.
¿Y a qué se debe tanto interés? El motivo prin-
cipal sin duda es aumentar la productividad del
programador dotándolo de diferentes armas para
resolver problemas de una manera más efectiva. Es-
tos conceptos existen desde hace muchos años, pero
actualmente toman gran importancia al reencarnar
en plataformas de programación comerciales.
~: Programación funcional :~
Los lenguajes funcionales son aquellos en los
que en lugar de proporcionar instrucciones
imperativas (diciendo como se deben hacer las
cosas), se especifican condiciones y criterios que
deben cumplirse para lograr un objetivo (otros
ejemplos de lenguajes declarativos son HTML,
XML, ASP.NET, SQL etccétera).
La programación funcional, propone que los
programas deben componerse exclusivamente
de funciones, y este concepto va más allá de la
idea general que tenemos de un subconjunto de
código (procedimiento o método.) Al referirnos
de que todo es una función debemos entender
que los lenguajes funcionales puros eliminan las
asignaciones, y todos los valores y resultados se
encuentran en función de otros. Es por esta ra-
zón que cuando a una variable se le asigna un va-
lor, éste jamás se modifica, de forma que se pueda
asegurar la llamada transparencia referencial.
Uno de los lenguajes funcionales más conocidos
es Haskell, y muchos de sus elementos han sido
retomados en C#.
~: Expresiones lambda :~
En la programación funcional se hace uso ex-
tensivo de las expresiones lambda, que no son
más que funciones declaradas anónimamente
(es decir sin un nombre explícito) y cuyo uso
disminuye la verbosidad del lenguaje (menos
líneas de código) y la potencia del mismo, al po-
www.sg.com.mx
www.sg.com.mx
der incrustar en cualquier parte del código una
función que resuelva determinada tarea.
Ejemplo en Haskell
(\pintNum -> pintNum * pintNum)
Ejemplo en C#
Func<int,int> lintResultado = (pintNum) => { return
pintNum * pintNum; };
En ambos casos si invocamos la función nos
regresará el cuadrado del parámetro invocado.
En el caso de Haskell, la indicación de la expre-
sión lambda se obtiene mediante la partícula \
mientras que en C# se indica mediante => que
se puede leer como va a.
~: Funciones de orden superior (FOS) :~
Las funciones de orden superior básicamente se
refieren a aquellas funciones que reciben como
argumentos otras funciones, o bien regresan otra
función como resultado.
En el siguiente listado podemos ver la definición
de una FOS, donde la función ConvertirMone-
da regresará una función (específicamente un
delegado) que a su vez será invocada para calcu-
lar el tipo de cambio.
public static Func<int,int> ConvertirMoneda(string
pstrMoneda) {
return (int pintCantidad) => {
return pstrMoneda == “EURO” ? pintCantidad * 15 :
pintCantidad * 10;}
};
Invocación
var lobjConvertidor = ConvertirMoneda(“PESO”);
Console.WriteLine(lobjConvertidor(20));
// Regresará 200
var lobjConvertidor = ConvertirMoneda(“EURO”);
Console.WriteLine(lobjConvertidor(20));
//Regresará 300
~:Inferencia de tipos :~
Como pudimos ver, en el listado anterior se hace
uso de la palabra clave var, esta palabra reservada
no implica late binding sino inferencia. El com-
pilador asigna automáticamente el tipo de dato
correcto al resultado de una función sin necesi-
dad de que se especifique explícitamente.
www.sg.com.mx
Haskell C#
:t “Hola” var lobjMsg= “Hola”;
lobjMsg.GetType().ToString();
Resultado:
“Hola” :: String Resultado:
System.String
Los lenguajes fuertemente tipificados son impor-
tantes por la seguridad al disminuir errores en tiem-
po de ejecución. Así, la inferencia de tipos conserva
la fuerte tipificación del dato pero aumenta la flexi-
bilidad y capacidad para generar polimorfismo.
~:Recursión como manejador
de control de flujo :~
En los lenguajes imperativos tenemos instrucciones
como if, for, while para manejar el control de flujo.
En la programación funcional el control de flujo
se da mediante el uso exhaustivo de listas, tuplas,
etcétera y el manejo efectivo de la recursividad.
El siguiente código Haskell devuelve la sumato-
ria de los números del 1 al 100.
sum[1..100]
En C# podríamos implementar nuestro clási-
co arreglo y/o contador, además de un ciclo de
repetición para lograr lo mismo. Sin embargo,
usando las nuevas características del lenguaje
podemos hacer esto:
Enumerable.Range(1, 100).Sum();
En ambos casos obtengo 5050.
~: Limitaciones de C# como
lenguaje funcional :~
Existen otros conceptos de la programación fun-
cional que no se cumplen al pie de la letra en C#,
dado que es un lenguaje híbrido. Sin embargo,
hay soluciones funcionales por si se desea seguir
estrictamente un paradigma. Un ejemplo de esto
es el de la evaluación perezosa. Ésta se refiere a la
capacidad de un lenguaje de programación en la
cual las expresiones de determinada sentencia no
se evalúan hasta que es exclusivamente necesario.
En el caso de la programación funcional esto es
útil toda vez de que es posible asignar listas infi-
nitas sin provocar un desbordamiento. Con C#
podemos usar evaluación perezosa mediante el
uso de listas, sin embargo el CLR por naturaleza
evalúa las expresiones al momento de asignarlas.
Por otro lado, tenemos el caso de la transparen-
cia referencial, la cual se refiere a que una fun-
ción dados determinados parámetros (firmas)
siempre regresará el mismo resultado. Esto no
se puede asegurar en C# toda vez que tenemos
operadores de asignación y manejo de estado,
por lo que un estado específico (en una variable
o propiedad) podría modificar el resultado de
una función aun con la misma firma.
Conclusión
Los paradigmas alternos de programación
representan una oportunidad para acercar-
nos a formas de trabajo que aumentarán
nuestra productividad. La tendencia va
hacia los lenguajes híbridos que incorporen
capacidades de distintos paradigmas. El
objetivo debe ser lograr patrones y prácticas
que permitan un mejor software y un menor
tiempo de desarrollo mediante el uso orde-
nado de las herramientas y tecnologías.
Por ejemplo, en el caso de .NET, estas nue-
vas características del lenguaje son el meca-
nismo habilitador de la tecnología LINQ.
Es necesario aprender a detalle lo que existe
detrás de esta implementación para poder
explotar la plataforma de la mejor manera.
Para los maestros y estudiantes de las ca-
rreras de sistemas, la oportunidad que nos
brindan estos lenguajes es doble ya que es
posible cumplir con los objetivos académicos
y además al aprender estas técnicas también
es posible salir preparado con un lenguaje
extensivamente utilizado en el ámbito laboral.
Referencias
[msdn2.microsoft.com/es-es/library/bb943915.aspx]
[haskell.org]
[squad.devworx.com.mx/blogs/miguel]
MAY-JUL 2008 35
29
 // COLUMNA /*PRUEBA DE SOFTWARE*/

La Calidad del Proceso de Prueba de Software

Los Modelos de Calidad especializados en Prueba de Software

Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es co-
fundador. Fue profesor-investigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en
Alemania, en la que abordó aspectos formales de dicha disciplina. Fue co-fundador del Capítulo Jalisco de la AMCIS.

S e puede percibir que en los últimos años

la industria de software mexicana ha estado
invirtiendo en el trabajo de mejora de proce-
sos, en la mayoría de los casos con los mo-
delos de calidad CMMI y MoProSoft.

Podemos ver dos motivaciones importantes

para esa inversión: por un lado mejorar las
capacidades de la empresa, bajo el supues-
to implícito de que la calidad del proceso
determina en buena medida la calidad del
software que se construye con ese proceso
(supuesto un tanto débil, como lo comenta-
mos en otro número); y por otro, tener más
credenciales que faciliten el vender más.

De manera general, los modelos de calidad

(MC) deben proporcionar un marco de refe-
rencia para:
a) Medir las capacidades de una organización  y
b) Diseñar y llevar a cabo mejoras de esas
capacidades.
Los MC deben mostrar al menos las siguien-
tes características:
• Completitud: el MC incluye todos los as-
pectos relevantes al medir capacidades.
• Consistencia: el MC no contiene contradic-
ciones internas.
• Objetividad: el MC tiene la precisión necesa-
ria para que cuando lo apliquen dos personas
diferentes para medir las capacidades de una
misma organización en un mismo periodo, los
resultados sean prácticamente los mismos.
Figura 1. Estructura de los modelos de calidad.
Además, los MC debieran mostrar validez es-
tadística y proveer una manera rápida para ob-
tener una evaluación inicial de capacidades.
Una estructura común de los MC (ver figu-
ra 1) es la de una matriz que considera por
una parte áreas a medir y por otra niveles
de madurez para cada una, lo que en con-
junto debiera facilitar la mejora de capaci-
dades con saltos manejables (retadores,
pero alcanzables en un tiempo y con una
inversión razonables).
Aquí haremos un breve análisis de varios
MC especializados en prueba de software
que han mostrado su utilidad en varios pro-
yectos de mejora de capacidades en los que
hemos participado en los últimos años.
Algunos modelos de calidad
especializados en prueba
Los MC que hemos utilizado en proyectos de
mejora de capacidades de prueba (incluidas
las nuestras) son: Test Process Improve-
ment (TPI), de la empresa holandesa Polteq;
Testing Maturity Model (TMM), del Illinois
Institute of Technology (EEUU); y Test Apti-
tude Model (TAM), de la empresa mexicana
e-Quallity.
La tabla siguiente muestra algunas caracte-
rísticas relevantes de cada uno de ellos:

36 MAY-JUL 2008 www.sg.com.mx

 “Los MC deben mostrar validez estadística y proveer
una manera rápida para obtener una evaluación
inicial de capacidades”.

TMM TPI TAM

Se ha constituido como un estándar Utilizado en la industria de prueba

Busca subsanar carencias de CMM en el internacional de facto mexicana
área de pruebas

Muy orientado a entidades de prueba den- Considera la entidad de pruebas, indepen- Como TPI, pero haciendo énfasis en los
tro de organizaciones desarrolladoras de dientemente de su inclusión o no dentro primeros pasos de mejora (usualmente
software de una organización desarrolladora los más difíciles)

Mediano: 13 metas, 5 niveles Pesado: 20 áreas, 4 niveles Ligero: 13 áreas, 3 niveles

Difícil de localizar proveedor Inversión considerable en euros Inversión razonable en pesos

Calificación de la organización evaluada Calificación de la organización evaluada Calificación entre 1 y 100 representando
en términos del nivel en cada meta en términos de (sub) nivel por cada área la cobertura en cada área y la global

En la siguiente tabla mostramos la relación aproximada entre

las distintas calificaciones que se emiten con estos MC. Cabe re-
Conclusión
saltar que no se trata de una equivalencia estricta, pero brinda Aunque nosotros vemos con claridad
una idea aproximada. que en el desarrollo de software la re-
lación entre la calidad del proceso y la
calidad de producto no es tan fuerte
como en la manufactura, también lo
estamos de que el trabajo en la mejo-
ra de los procesos de prueba es una
labor que no debe dejar de hacerse.
En nuestra experiencia, hemos visto
que resulta útil iniciar con un mo-
delo ligero como el TAM, que con
costos moderados permite mejorar
significativamente las capacidades y
luego, si lo que se busca es una cer-
tificación internacional, brincar a un
modelo como TPI, aprovechando los
ahorros económicos obtenidos de la
» Luis Vinicio León Carrillo / Elena Ruelas Minor mejora anterior.

Referencias:
Elena Ruelas Minor es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. En [ tmmifoundation.org ]
su trayectoria ha actuado como tester senior y administradora de proyectos de prueba; como consultora, [ e-quallity.net ]
ha aplicado el modelo de calidad TAM, y fue la champion del proyecto de certificación en los modelos de [ polteq.com ]
calidad TPI y TMM de e-Quallity.

www.sg.com.mx MAY-JUL 2008 37

 // PRÁCTICAS /*ARQUITECTURA*/
Más Allá del Manual de Usuario
Parte 1. Documentando la Arquitectura de Software
Por Omar Gómez
Principios básicos
En la actualidad, uno de los temas candentes del que se habla den-
tro de la comunidad de desarrollo de software es el referente a las
arquitecturas. Una arquitectura de software describe cómo un sis-
tema se desglosa en componentes, cómo son interconectados y la
manera en que se comunican e interactúan entre sí. Tras la defini-
ción anterior se pueden formular un par de preguntas: ¿en qué gra-
do cumplimos con ésta definición durante el rol que desempeñamos
como arquitecto o diseñador?, o mejor dicho: ¿Qué tan bien docu-
mentamos una arquitectura de software?
La finalidad de este artículo es contar con un punto de referencia
sobre esta práctica, abordando dos de los enfoques más relevantes
que han sido usados para realizar la tarea; también se describe su
tendencia actual, y por último se menciona una serie de considera-
ciones que se deben tener en cuenta al momento de documentar.
Comúnmente una arquitectura de software se documenta a través
de un conjunto de vistas, en donde cada una de ellas representa un
aspecto o comportamiento particular del sistema. Dos de los artícu-
los de mayor relevancia que abordan el tema del uso de vistas son
los de Philippe B. Kruchten y el de Robert L. Nord y compañía. El pri-
mero es el más conocido porque la propuesta es parte fundamental
de la metodología del Proceso Unificado, que en la actualidad es una
de las metodologías que goza de cierto grado de popularidad.
Kruchten propone el uso de cinco vistas:
• Vista lógica. Apoya principalmente los requisitos funcionales, es
decir, lo que el sistema debe brindar en términos de servicios a sus
usuarios, desglozado en una serie de abstracciones primarias, toma-
das principalmente del dominio del problema en la forma de objetos
o clases de objetos. Aquí se aplican los principios de abstracción,
encapsulación y herencia. Esta descomposición no sólo enfatiza el
análisis funcional, también sirve para identificar mecanismos y ele-
mentos de diseño comunes a diversas partes del sistema.
• Vista de procesos. Trata los aspectos de concurrencia y distribu-
ción, integridad del sistema, y tolerancia a fallas. También especifica
en cuál hilo de control se ejecuta efectivamente una operación de
una clase identificada en la vista lógica. Esta vista puede ser descrita
como un conjunto de redes lógicas de procesos que son ejecutados
de forma independiente, y distribuidos a lo largo de varios recursos
de hardware conectados mediante un bus o a una red de datos.
• Vista de desarrollo. Se centra en la organización real de los módu-
los de software en el ambiente de desarrollo. El software se empa-
queta en partes pequeñas que pueden ser bibliotecas o subsistemas
38 MAY-JUL 2008
creados por un desarrollador o un grupo de ellos, y se organizan en
una jerarquía de capas, cada una brinda una interfaz estrecha y bien
definida hacia las capas superiores.
• Vista física. Se toma en cuenta los requisitos no funcionales del
sistema tales como: disponibilidad, confiabilidad y desempeño, en-
tre otras más; y es ejecutado sobre varios nodos de procesamiento
(hardware). Estos nodos son relacionados con los elementos identi-
ficados de las vistas anteriores. Aquí se especifican varias configu-
raciones físicas, por ejemplo: una para el desarrollo y las pruebas, o
para el despliegue del sistema en plataformas distintas.
Kruchten define una última vista en la que propone el uso de un pe-
queño subconjunto de escenarios que son instancias de casos de
uso. Su función es relacionar las cuatro vistas entre sí, de esta forma
se cuenta con una perspectiva general del sistema, que ayuda a des-
cubrir nuevos elementos o validar la arquitectura.
Por su parte, Nord y compañía realizaron un estudio para conocer
en una arquitectura las estructuras que son de mayor importancia,
y el uso de éstas. El estudio se efectuó sobre varios sistemas de
software de ámbito industrial. Tras el estudio realizado propusieron
cuatro categorías o vistas para agrupar las estructuras principales
de una arquitectura, estas son:
• Vista conceptual. Se describe el sistema en términos de sus ele-
mentos principales de diseño y las relaciones entre ellos dentro de
un dominio determinado. Esta vista es independiente de las decisio-
nes de implementación y enfatiza en los protocolos de interacción
entre los elementos de diseño.
• Vista de módulos. El sistema se descompone lógicamente en sub-
sistemas, módulos, y unidades abstractas. Cada capa representa las
distintas interfaces de comunicación permitidas entre los módulos.
• Vista de ejecución. Se describe la estructura dinámica del sistema
en términos de sus elementos en tiempo de ejecución. Por ejemplo,
se modela las tareas operativas del sistema, procesos, mecanismos
de comunicación y asignación de recursos. Algunos de los aspectos
que se consideran en esta vista son: el desempeño y el entorno de
ejecución.
• Vista de código. Se organiza el código fuente en directorios, archivos
y bibliotecas. Algunos de los aspectos que se incluyen son: los lengua-
jes de programación a utilizar, herramientas de desarrollo, la adminis-
tración de la configuración y la estructura y organización del proyecto.
www.sg.com.mx
 “Comúnmente una arquitectura
de software se documenta a través
de un conjunto de vistas”.
Es común que en la actualidad se utilice alguno de los 2 enfoques
antes descritos. Sin embargo, la forma de documentar una arquitec-
tura ha evolucionado significativamente. Ahora la tendencia sobre
esta práctica se centra en dos aspectos principales:
• Los arquitectos deben documentar las vistas que sean de mayor utili-
dad y no ajustarse a un número fijo como lo muestran las propuestas.
• Documentar la arquitectura tomando en cuenta los intereses y nece-
sidades de las personas involucradas en el proyecto, estos intereses se
traducen como las cualidades que el sistema resultante debe poseer.
Esta nueva tendencia está respaldada por dos grandes institutos,
uno de ellos es el Instituto de Ingeniería del Software (SEI) y el otro
es el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) elabora-
do por el comité de estándares del IEEE Software. A continuación se
describen los dos enfoques.
El SEI en su propuesta define tres categorías denominadas tipos de
vista, en las que prácticamente cualquier vista, dependiendo del
tipo de información que contenga, puede pertenecer a una de estas
categorías. Los tipos de vista pueden ser:
• Vista de módulo. Describe cómo el sistema es estructurado en un
conjunto de unidades de código.
• Vista de conectores y componentes. Describe cómo el sistema es
estructurado en un conjunto de elementos que están en tiempo de
ejecución así como su interacción.
• Vista de asignación. Describe la relación entre las unidades de
software y los elementos del entorno como hardware, sistemas de
archivos o la organización de los equipos de desarrollo de software.
Es importante señalar que cada tipo de vista viene acompañado de un
conjunto predefinido de estilos, de así los arquitectos pueden hacer
uso de éstos para documentarlas. De acuerdo a Shaw y Garlan, un
estilo arquitectónico es una descripción de los elementos, conectores,
topología, y un conjunto de restricciones sobre la interacción de los
elementos. El uso de estilos promueve la satisfacción de los intereses
definidos por parte del personal involucrado en el proyecto.
El SEI recomienda contar con una guía de estilos que contenga entre
otros aspectos: la descripción relevante del estilo, elementos, re-
laciones, propiedades, situaciones en las que no es recomendable
aplicarlo, circunstancias en las que se recomienda usarlo, y posibles
www.sg.com.mx
enfoques analíticos que el arquitecto puede utilizar. Para la elabora-
ción de la guía de estilos se puede tomar como referencia el informe
técnico realizado por Mark Klein y Rick Kazman, en el que los autores
proponen un marco de trabajo para llevar acabo un razonamiento
cualitativo o cuantitativo de los atributos de calidad presentes en un
estilo arquitectónico, a través de una serie de ejemplos que descri-
ben el uso del marco de trabajo con los atributos de calidad: desem-
peño, facilidad de modificación y disponibilidad.
La documentación de las vistas se realiza a través de lo que se deno-
mina paquetes de vista. Los paquetes de vista contienen un número
reducido de elementos, logrando así una mejor comprensión ya que
sólo se muestra un fragmento particular del sistema. De esta mane-
ra, una vista se descompone en uno o más paquetes de vista.
Para seleccionar las vistas a documentar, se sigue un procedimiento
basado con respecto a las estructuras que se encuentran presen-
tes de manera inherente en el sistema a construir, y en los intereses
primarios del personal involucrado. El procedimiento consta de los
siguientes pasos:
1) Elaborar una lista de vistas candidatas. En este paso se elabora
una tabla con la siguiente información: en las columnas se enumera
el conjunto de posibles vistas a documentar, mientras que en las fi-
las se hace con el personal involucrado. En cada una de las celdas se
especifica el grado de información que requiere cada una de los par-
ticipantes en el proyecto, los valores posibles para las celdas pueden
ser: requerido a detalle, de manera general o ninguno. Este paso con-
cluye una vez que se han seleccionado las vistas de mayor interés.
2) Combinar las vistas. Posiblemente las vistas elegidas en el paso
anterior sean imprácticas de documentar debido al número de vistas
seleccionadas, en este paso se reduce la lista de vistas de una mane-
ra que pueda ser manejable por el arquitecto. La reducción se lleva
acabo combinando varias vistas, de este modo una vista combinada
muestra la información nativa de dos o más vistas separadas.
3) Priorizar las vistas. Aquí, el arquitecto debe tener el conjunto mí-
nimo de vistas que satisfacen los intereses del personal involucrado.
Después, en conjunto con el administrador del proyecto se procede
a priorizar cada una de las vistas resultantes.
Una vez que las vistas se han seleccionado y priorizado, se inicia su
documentación. El SEI cuenta con una plantilla que se puede utilizar de
referencia para dicho propósito. De acuerdo al SEI, la documentación
de una arquitectura debe contener los siguientes apartados:
MAY-JUL 2008 39
 // PRÁCTICAS /*ARQUITECTURA*/

Figura 1. Relación de conceptos de la propuesta “vistas y más allá de éstas” del SEI.

• Presentación primaria. Muestra los elementos y sus relaciones en-

tre sí, usualmente se representa de manera gráfica. En el siguiente número continuaremos con la propuesta del
IEEE, así como las propuestas a considerar en la documentación
• Catálogo de elementos. Contiene los detalles de éstos, sus propie- de arquitecturas.
dades e interfaces.

• Diagrama de contexto. Muestra la relación entre el sistema o por- Referencias:

ción de éste y su entorno.
• Guía de variabilidad. Muestra los posibles puntos de variación en
caso de que las vistas sean modificadas.
• Antecedentes de la arquitectura. Explica la justificación de la arquitec-
tura así como los supuestos, y los resultados de los análisis realizados.
• Otra información. En esta sección se incluyen prácticas y políticas
de la organización.
• Paquetes de vista relacionados. Básicamente, en esta sección se
definen las relaciones entre los distintos paquetes de vista.
Para concluir con la propuesta del SEI, en la figura 1 se muestra los
principales conceptos de este enfoque.
[ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE Soft-
ware, Los Alamitos, CA, USA. Vol. 12, No. 6, págs. 42-50. IEEE Computer
Society Press. 1995. ]
[ Dilip Soni; Robert L. Nord & Christine Hofmeister. “Software Archi-
tecture in Industrial Applications”. ICSE ‘95: Proceedings of the 17th
international conference on Software Engineering, New York, NY, USA.
págs. 196-207. ACM. 1995. ]
[ Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed
Little; Robert Nord & Judith Stafford. “Documenting Software Architectures:
Views and Beyond”. Addison Wesley Professional. 2002. ]
[ Software Engineering Institute, SEI. “Views and Beyond Architecture
Documentation Template”.Template 05 febrero 2006. ]
[ sei.cmu.edu/architecture/rcgh_doc.html ]

[ Omar Gómez. “Evaluando la Arquitectura de Software, Métodos de

Evaluación”. Revista Software Gurú. Año 03 No. 02. 2007. ]

Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software, en el Centro de Investigación en Matemáticas (CIMAT). Actualmente se
encuentra trabajando como estudiante de postgrado en el área de Ingeniería del Software Empírica en la Facultad de Informática de la Universidad Politécnica
de Madrid. Es miembro del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org

40 MAY-JUL 2008 www.sg.com.mx

www.sg.com.mx MAY-JUL 2008 39
 // PRÁCTICAS /*PROGRAMACIÓN*/
Aprendiendo Ruby y Rails
Parte 3. El Framework Rails
Por Carlos Ortega
En esta ocasión se hablará del framework Ruby on Rails. Recomen-
damos al lector revisar la siguiente referencia para que realice la
instalación adecuada a su plataforma favorita: rubyonrails.org.
También, es importante señalar que se requiere de un RDBMS ins-
talado, en este caso se utilizó MySQL, por lo tanto, la sintaxis refe-
rente a la Base de Datos es propia de esta última. Los comandos
que se indican toman como base el ambiente Windows; para Linux
se sugiere observar el cambio de sintaxis en las líneas de comandos
correspondientes y el web server a utilizar es WEBrick.
Arquitectura de Rails
Como ya se mencionó, Rails es un framework para desarrollo web con
base en el patrón arquitectónico MVC 2, es decir, la capa del frente
(presentación) es totalmente independiente de la capa de lógica de
negocio, la cual es representada por un controlador que manipula al
modelo (capa de datos). Los elementos arquitectónicos más impor-
tantes de una aplicación Rails se presentan en el siguiente esquema:
La arquitectura funciona de la siguiente manera: se genera una pe-
tición desde el navegador, el web server al recibirla la redirecciona a
un recurso específico a traves de la librería CGI, posteriormente, éste
manda la petición a un controlador que vive dentro de la capa de
ActionPack; el controlador por su parte no conoce a la capa de pre-
sentación, definida por las vistas/Action View, sin embargo puede
manipular y administrar los objetos de negocio, los cuales a su vez son
representados por objetos que derivan de la clase Active Record, que es
la capa que une los datos contenidos en el RDBMS.
Una vez que dichos objetos de negocio son manipulados por el con-
trolador, pueden ser compartidos de manera automática con las vis-
tas. ERb es un paquete que permite la manipulación de código Ruby
42 MAY-JUL 2008
intercalado con HTML, de tal manera que aun cuando las vistas con-
tienen código híbrido (HTML y Ruby), ERb toma dicha combinación,
interpreta los resultados y valores del lenguaje generando al final
sólo HTML, así, éste puede ser reenviado por el web server para su
interpretación limpia dentro del browser.
Arrancando con Rails
El procedimiento que se describire a continuación es el proceso simple
recomendado para la creación de cualquier aplicación basada en Rails:
1) Creación del modelo de datos. En esta etapa se generan las bases de
datos de desarrollo, prueba y producción, adicionalmente se crean los
objetos de negocio que representan al dominio que estemos tratando.
2) Creación de la lógica de negocio. Aquí se desarrolla toda la lógica
de negocio de la aplicación.
3) Creación de la presentación. En esta etapa se generarán todos los
elementos que permitirán interactuar al usuario con el sistema.
Es posible que uno pueda preguntarse que, no necesariamente to-
dos los actores de un sistema son humanos. En este caso Ruby y
Rails proporcionan una gran variedad de recursos y librerías que
permiten interactuar con otros elementos externos, tales como el
correo electrónico o el uso de web services. La forma de cómo se
puede interactuar con este tipo de elementos queda fuera del alcan-
ce de este artículo.
Asumiendo que Rails y el manejador relacional se han instalado
correctamente, iniciaremos la generación del modelo creando las
bases de datos correpondientes, siguiendo las convenciones que
los diseñadores de Rails pensaron al contemplar un ciclo de vida de
desarrollo completo (desarrollo, pruebas, distribución). Crearemos
tres bases de datos con características y nombres similares que per-
mitirán realizar cada una de estas fases.
Pasos
1. Definimos un directorio de desarrollo llamado trabajo, dentro de
él creamos la aplicación base en Rails (en nuestro caso la denomi-
naremos railsass):
>cd trabajo
>rails railsass
Al ejecutar este comando se crea la infraestructura base de la apli-
cación, que es la estándar para cualquier aplicación formada de la
siguiente manera:
www.sg.com.mx
 “ERb es un paquete que permite
la manipulación de código Ruby
intercalado con HTML”.

2. Se crean en MySQL 3 bases de datos:

railsass_development,
railsass_test y
railsass_deployment

3 - Una vez creadas las bases, se genera el

modelo en Rails. En una sesión de consola
Ruby, nos cambiamos al directorio recien
creado railsass e invocamos el generador de
modelos estándar utilizando como nombre
del modelo Usuario:

path/trabajo>cd railsass
path/trabajo/railsass>ruby script/generate model Usuario

www.sg.com.mx MAY-JUL 2008

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

Una vez creado el modelo es necesario realizar su integración con
la infrastructura de la base de datos. Para ello, Rails proporciona un
mecanismo que permite definir las conexiones para dar persitencia a
los objetos del modelo. Este mecanismo es un archivo de tipo YAML
denominado database.yml, que reside en el subdirectorio config
dentro del directorio railsass.
4. Editamos el archivo database.yml e incorporamos los parámetros del
nombre host, los nombres de las bases de datos, los usuarios y los
passwords de acceso. Para nuestro caso emplearemos los siguientes:
Al inspeccionar 001_create_usuarios.rb podemos corroborar que contie-
ne la definición de una clase que sigue la siguiente convención:
class Create<NombreEnPluralDelModelo>
Normalmente esta clase posee 2 metodos: self.up y self.down. El obje-
tivo de self.up es realizar las acciones correspondientes al ejecutar
la migración. Por su parte self.down es un método pensado para realizar
ajustes de reversa, es decir, deshacer acciones sobre la tabla en
cuestión, en caso de tener que regresar a esa versión en particular.

development: Editamos 001_create_usuarios.rb asegurando que tenga las siguientes

adapter: mysql
definiciones:
database: railsass_development
username: root
password: class CreateUsuarios < ActiveRecord::Migration
host: localhost def self.up
create_table :usuarios do |t|
test: t.column :nombre, :string
adapter: mysql t.column :apellido, :string
database: railsass_test t.column :tipo, :integer
username: root t.column :permisos, :string
password: end
host: localhost end

production:
adapter: mysql def self.down
database: railsass_production drop_table :usuarios
username: root end
password: end
host: localhost
6. Ejecutamos la migración a través del manejador de tareas rake:
5. El acoplamiento entre los objetos de negocio y la base de datos se
realiza a través de una migración, la cual se realiza por medio de un cd path/trabajo/railsass
path/trabajo/railsass>rake db:migrate
archivo con código Ruby (extensión .rb) que se encuentra localizado
dentro del subdirectorio db/migrate. Típicamente el nombre de este
archivo sigue la convención: Como parte de la comprobación del correcto funcionamiento de la
migración, generaremos un objeto de negocio de tipo Usuario, califi-
<numeroVersión>_create_<nombreEnPluralDelModelo>.rb
cando sus atributos, y guardando todo el objeto en la base de datos.
Esto lo realizaremos a través de una consola interactiva irb Ruby y el
Así entonces el nombre del archivo de migración es 001_create_usuarios.rb propio manejador MySQL.

Como este archivo contiene la sintaxis de Ruby que describe la es-
tructura de la tabla asociada al modelo en la base de datos, permite
manipular código SQL a través de Ruby, resultando más cómodo,
sencillo y elegante. Adicionalmente una migración permite modificar
la estructura de las tablas conforme evolucione el desarrollo, de ahí
el número de versión como parte del nombre del archivo.
7. Arranquemos la consola interactiva irb Ruby para cargar el am-
biente y la base de datos en memoria:
path/trabajo/railsass>ruby script/console
8. Creamos un objeto Usuario y cambiamos el valor a sus atributos
(a continuación la sesión correspondiente).

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

44 MAY-JUL 2008 www.sg.com.mx

 “A través de Ruby se puede manipular
código SQL resultando más cómodo,
sencillo y elegante”.

>> tipo_usuario = 0
=> 0
>>tipo_admin = 1 En este artículo exponemos brevemente la arquitectura gene-
=> 1 ral de Rails, además de explicar cómo generar el modelo de
>>tipo_auditor = 2 negocios aplicando el concepto de migraciones. En la próxima
=> 2
>>unUsuario = Usuario.new
de nuestras entregas terminaremos el tutorial con el uso de
=> #<Usuario:0x4932e94 @attributes={“permisos”=>nil, “apellido”=>nil, “nombre”=> nil, controladores y vistas.
“tipo”=>nil}, @new_record=true>
>>unUsuario.nombre = “David”
=> “David”
>>unUsuario.apellido = “HeineMeier”
Referencias
=> “HeineMeier” [ Thomas David, Fowler Chad, Hunt Andy. “Programming Ruby” 2nd
>>unUsuario.tipo = tipo_admin Edition. The Pragmatic Bookshelf. 2005. ]
=> 1 [ Thomas David, Heinemeier Hanson David, et al. “Agile Web Develop-
>>unUsuario.permisos = “rwx rwx rwx” ment with Rails”. 2nd Edition. The Pragmatic Bookshelf, 2006. ]
=> “rwx rwx rwx”
[ Black, David A. “Ruby for Rails”. Manning Publications Co. 2006 ]
>>unUsuario.save
=>true [ ruby-lang.org/en ]
[ rubyonrails.org ]
9. Podemos corroborar a través de MySQL que después del último [ mysql.com ]
comando, el objeto unUsuario ha quedado registrado en la base.

www.sg.com.mx MAY-JUL 2008

 // PRÁCTICAS
CMMI-SVC®
¿Qué hay de Nuevo Bajo el Sol de los Servicios?
Por Elizabeth Almeraz
La industria de servicios abarca una porción
muy amplia del mercado mundial, sin embargo
el modelo de CMMI-DEV (Capability Maturity
Model Integrated for Development), no pro-
porciona un marco de referencia adecuado
para aquellas compañías que han expandido
su visión más allá del desarrollo de sistemas y
han incursionado en el mercado de los servicios.
Para ellas, así como para empresas enfo-
cadas principalmente al área de servicios,
cualquiera que éstos sean, el SEI (Software
Engineering Institute) se ha dado a la tarea
de formular un modelo de capacidad que
ofrezca el marco de referencia adecuado
para administrar y entregar los servicios
ofertados, al cual ha denominado: CMMI-
SVC (Capability Maturity Model Integrated
for Services), actualmente éste se encuentra
todavía en su etapa de pruebas piloto, el
SEI espera liberar el nuevo modelo durante
la primera mitad de 2008.
Recientemente el grupo de trabajo había dete-
nido su labor porque presentó un caso de es-
tudio al comité que coordina la realización del
modelo, como respuesta a varias inquietudes
que fueron expresadas por el Departmento de
Defensa de Estados Unidos a mitad de año, re-
solviéndose a través del voto por la inclusión
del modelo a la Suite de Productos de CMMI;
por lo que se está trabajando actualmente en
incorporar los cambios sugeridos por la comu-
nidad experta; así como las recomendaciones
realizadas en respuesta a las inquietudes del
Departamento de Defensa.
Este modelo está pensado para ayudar a las
organizaciones —que usen o no actualmen-
te el marco de referencia de CMMI-DEV— a
transformar el desempeño de sus servicios
en ofrecimientos maduros y exitosos. Preten-
Elizabeth Almeraz cursó estudios de MBA en Theseus Institute en Francia, es Lic. en Ciencias de la Informática en el IPN. Pionera en temas de aseguramiento
de calidad y mejora continua, iniciando grupo de SQA de Tecnosys-IBM para alcanzar el nivel 3 de madurez de CMM. Ha realizado diagnósticos, planes de
mejora, revisiones, evaluaciones, capacitaciones, verificaciones y asesorías sobre la implantación del programa de mejora con clientes. Actualmente es socia y
se desempeña como Coordinadora Técnica de Consultoría en Avantare.
46 MAY-JUL 2008
/*PROcesos*/
diendo acrecentar la inversión realizada en
los proyectos de mejora de procesos, am-
pliando su aplicación a otras áreas de la
organización; de tal forma que permita que
la operación de los diferentes modelos ope-
ren de manera síncrona con otras iniciativas
existentes. En pocas palabras, el modelo es
una nueva constelación dentro de la suite de
CMMI que pretende cubrir las necesidades de
la industria de servicios y reconoce que éstos
son un catalizador en el crecimiento econó-
mico mundial, y la necesidad de establecer
un marco de referencia, que proporcione guía
para desarrollar y mejorar las prácticas de
provisión de servicios de las organizaciones
como un medio para mejorar la satisfacción
del cliente, el desempeño y la rentabilidad de
las organizaciones que proveen servicios.
En el contexto de esta nueva constelación
de CMMI, un servicio es simplemente un
producto intangible, que no puede ser al-
macenado, y por tanto, el modelo puede ser
aplicado a cualquier organización que ofrez-
ca servicios, lo cual incluye compañías de
los más diversos sectores, desde las entida-
des militares, pasando por las de tecnología
de información, hasta las dedicadas al cui-
dado de la salud, finanzas y transportes. De
ahí que, la aplicabilidad de este modelo, sea
un complemento más que una competencia
para el ITIL, ya que resumen las mejores
prácticas de este último en un conjunto de
prácticas específicas; al mismo tiempo que
reutiliza aproximadamente el 77% de las
tareas contenidas en los modelos CMMI li-
berados y en uso (CMMI-DEV y CMMI-ACQ);
y se planea que el mismo método de evalua-
ción SCAMPI sea utilizado, lo que permitirá
a las empresas trabajar con un método de
evaluación estándar, independientemente
de las constelaciones de CMMI que cual-
quiera de ellas adopte.
El modelo de CMMI-SVC, contiene prácticas
que cubren los procesos de: administración
de proyectos, administración de procesos,
establecimiento de servicios, entrega de ser-
vicios; así como otros procesos de soporte.
Todos estos procesos están representados
en 22 PA’s (áreas de proceso) obligatorias
más tres PA’s opcionales, las cuales están
conformadas de la siguiente manera:
• Se utilizan 16 PA’s que están incluidas den-
tro de las áreas de proceso base del modelo
de CMMI (CMMI Model Foundation); las cua-
les se comparten por los modelos de CMMI-
DEV y CMMI-ACQ.
• Se definieron cinco PA’s para servicios.
• Se tiene una PA compartida con el modelo
de CMMI-DEV (que es el área de Administra-
ción de Proveedores) y...
• Para la adición de servicios tres PA’s.
El modelo comprende cuatro categorías de
áreas de proceso:
• Administración de Procesos. Incluye seis
áreas de proceso, de las cuales sólo se adi-
ciona Organizational Service Management
(OSM) de las ya incluidas en esta categoría
para el CMMI-DEV; y la cual es una de las
PA’s opcionales a ser aplicadas.
• Soporte de Servicio. Con seis áreas de proce-
so. Esta categoría incluye las áreas de proceso
de soporte dentro de CMMI-DEV, y adiciona
solamente el área de Problem Management.
• Establecimiento y entrega de servicios.
Con sólo cuatro áreas de proceso. Esta ca-
tegoría realmente representa el fundamento
del modelo; ya que todas las áreas de proceso
de la misma están enfocadas a los servicios.
Dentro de esta categoría se incluyen las si-
guientes áreas de proceso:
www.sg.com.mx
- Incident and Request Management (IRM).
- Service Delivery (SD).
- Service System Development (SSD) -opcional.
- Service Transition (ST).
• Administración de Proyectos. Abarca nue-
ve áreas de proceso. Esta categoría incluye
todas las áreas de proceso de administra-
ción dentro de CMMI-DEV, considernado
la correspondiente a la Administración de
Proveedores (SAM), así como la de Adminis-
tración de Requerimientos (REQM, la cual se
encuentra modificada para la aplicación en
el área de servicios). Sin embargo, dentro
de esta categoría se incluyen dos áreas de
proceso específicas para servicios:
- Capacity and Availabiltiy Management
(CAM).
- Service Continuity (SCON),
la cual es opcional.
www.sg.com.mx
El CMMI-SVC es un modelo que se distingue
del CMMI-DEV debido a que permite direc-
cionar la administración de punta a punta en
servicios complejos o sistemas complejos
de desarrollo; y en dónde el uso de los pro-
cesos de ingeniería puede ser aplicable; por
lo cual, el primero puede ser utilizado para
robustecer el uso de CMMI-DEV.
Otras ventajas de CMMI-SVC es que el modelo
direcciona los problemas comunes en los ser-
vicios tales como la entrega repetible a través
del tiempo, y los cambios constantes de clien-
tes y requerimientos. Adicionando mejores
prácticas enfocadas a servicios, con lo cual se
pretende reducir el número de fallas en ellos,
mientras se mantiene la disponibilidad de los
mismos. Así como mejorar la continuidad del
servicio y reducir los costos e incidentes de
manera efectiva y eficiente; mientras se incre-
menta la consistencia y la calidad de los servi-
cios proporcionados.
Conclusiones
Como se ve, el CMMI-SVC es un mode-
lo que bien puede ser el complemento
perfecto para otras iniciativas de me-
jora continua; sin importar que se ten-
ga ya en marcha una iniciativa basada
en algún otro modelo de CMMI, ITIL u
otro modelo enfocado a la mejora de
servicios. Habrá que esperar a tener
los resultados en el siguiente año. Por
lo pronto, se ha mostrado un gran in-
terés por el nuevo concepto que aún
se encuentra en gestación; aunque
sin duda se espera que será una op-
ción que puede romper algunos para-
digmas ya establecidos… en fin, sólo
el tiempo lo dirá.
Referencias
[ sei.cmu.edu/cmmi ]
MAY-JUL 2008
 // UML
Sysml
Modelando Sistemas y Sistemas de Sistemas
Por Charlie Macías
En esta ocasión hablaremos de un estándar regulado por la OMG,
recién salido del horno (septiembre de 2007) que quizá por mi for-
mación en ingeniería mecánica ha venido llamando de manera cre-
ciente mi atención y la de muchas empresas desde hace algunos
años: SysML (omgsysml.org).
El mundo de los sistemas
Día a día interactuamos con un sinnúmero de artefactos que están
conformados por un conglomerado de sistemas compuestos por
otros sistemas. Nuestro automóvil por ejemplo: está compuesto
por un motor que es un sistema complejo de piezas mecánicas,
hidráulicas, electrónicas y de software, que hacen posible su fun-
cionamiento como unidad. Todas estas piezas obedecen a distintos
modelos en el ámbito de la termodinámica, la mecánica de fluidos,
la cinemática, la dinámica, la tecnología de materiales, etcéctera. Si
ampliamos aún más la frontera de control, el automóvil puede ubi-
carse dentro de otro sistema más grande conformado por las vías de
comunicación sobre las que transita, lo cual impacta sobre el siste-
ma ambiental y sobre la sociedad.
La especialización de UML
SysML (System Modeling Language) es un lenguaje de modelado de
dominio específico para aplicaciones de sistemas de ingeniería. So-
porta la especificación, análisis, diseño, verificación y validación de
un amplio rango de sistemas y sistemas de sistemas. Estos sistemas
pueden incluir hardware, software, información, procesos, personal
e instalaciones.
¿Qué es la ingeniería de sistemas?
INCONSE (International Council on Systems Engineering) define a la
ingeniería de sistemas como una rama de la ingeniería cuya respon-
sabilidad es crear y ejecutar un proceso interdisciplinario que tiene
como objetivo asegurar que las necesidades de los clientes y grupos
de interés sean satisfechas con alta calidad, de manera confiable,
rentable y apegada a calendario a lo largo de todo el ciclo de vida
del sistema, que va desde su desarrollo, pasando por su operación
y hasta su eliminación. Este proceso está conformado normalmente
por las siguientes siete actividades: delimitar el problema, investi-
gar alternativas, modelar el sistema, integrar, implantar el sistema,
evaluar el desempeño y volver a evaluar. El proceso de ingeniería
de sistemas no es secuencial: las actividades son desarrolladas de
forma paralela e iterativa.
48 MAY-JUL 2008
Mientras que UML es un lenguaje de modelado de propósito general
(GPML), SysML es un lenguaje de modelado de dominio específico
(DSML) definido como un perfil (adaptación) de UML 2.0. Esto es
una ventaja, ya que le permite reutilizar la notación y semántica re-
lativamente madura (diez años) de UML 2.0.
¿No es suficiente con UML?
Si SysML está basado en UML, entonces, ¿para qué otro lenguaje? El
problema con UML es que está fuertemente enfocado al software y
los ingenieros de sistemas están buscando un lenguaje de modela-
do que permita especificar sistemas complejos que incluyan no sólo
componentes de software (por ejemplo: hardware, información, pro-
cesos, personal e instalaciones). SysML reduce el tamaño e inclina-
ción hacia el software que caracteriza a UML al tiempo que amplía
su aplicación para modelar requerimientos y restricciones paramé-
tricas a fin de soportar la ingeniería de requerimientos y el análisis
de desempeño, que son esenciales en la ingeniería de sistemas. Un
ejemplo emblemático lo conforman los llamados sistemas embebi-
dos para los que desde 1998 existe una adaptación de UML conocida
como Real Time UML, la cual no ha sido suficiente.
Ventajas sobre UML
Entre las principales ventajas que SysML ofrece, sobre UML, a los
ingenieros de sistemas para especificar sistemas o sistemas de sis-
temas se encuentran:
1. SysML expresa mejor que UML la semántica de la ingeniería de sis-
temas. SysML reduce la predilección por el software propia de UML,
y agrega dos diagramas para la administración de requerimientos y
análisis de desempeño: diagramas de Requerimientos y diagramas
Paramétricos, respectivamente.
2. SysML es más pequeño y sencillo de aprender que UML. SysML
remueve varias construcciones centradas en el software, si lo medi-
mos en diagramas todo el lenguaje es más pequeño: nueve diagra-
mas, de SysML vs. 13 diagramas de UML.
3. Las tablas de asignación de SysML soportan varios tipos de asig-
naciones (por ejemplo: asignación de requerimientos, asignación
funcional, asignación estructural) facilitando, de esta manera, la ve-
rificación y validación (V&V) automatizada y el análisis GAP.
www.sg.com.mx
 “Los diagramas de estructura,
comportamiento, requerimientos y
parámetros son la base de la especificación”.

Figura 1. Estructura de SySML.

4. Las construcciones de administración del enfrentar: la superposición lingüística y la

modelo de SysML soportan la especificación
de modelos, vistas y puntos de vista; y es-
tán arquitectónicamente alineadas con las
IEEE-Std-1471-2000 (Practicas Recomenda-
das por el IEEE para la Descripción Arquitec-
tónica de Sistemas Intensivos en Software).
UML + SysML
En un proyecto grande, por supuesto se
pueden utilizar ambos lenguajes, de hecho,
esta fue la intención de los diseñadores del
lenguaje SysML. Sin embargo, es importan-
te señalar que en este ámbito se han iden-
tificado dos problemas típicos que hay que
divergencia lingüística. El primer problema
se deriva de que varios diagramas de SysML
extienden el significado o se derivan de los
definidos en UML (por ejemplo: los diagra-
mas de Actividad o los de Bloques/Bloques
Internos en SysML vs. los de Clases/Estruc-
tura Compuesta/Componentes en UML). El
segundo es el cambio de enfoque necesario
para adaptarse al ámbito de la ingeniería de
sistemas, por ejemplo: los diagramas Pa-
ramétricos inyectan un modelo restricción-
lógica en el modelo objeto-componente de
UML. Al final del día, como siempre, la prác-
tica está en la experiencia.

Charlie Macías es consultor e instructor senior, especializado en temas relacionados con UML en
Milestone Consulting, empresa especializada en capacitación práctica-intensiva y consultoría en UML,
BPMN, SysML, Arquitectura de SW y PM. Milestone Consulting fue la primera empresa mexicana
miembro de la OMG, y actualmente es REP del PMI. info@milestone.com.mx
www.milestone.com.mx

www.sg.com.mx MAY-JUL 2008

 // PM CORNER
EL VALOR DE LAS OFICINAS DE PROYECTOS
Apalancar la PMO para Consolidar el Estatus y las Métricas del Proyecto
Por Tom Mochal
Traducción y Adaptación: José Luis Flores
La PMO (Project Management Office) dentro
de la organización es la única capaz de vi-
sualizar todos los proyectos en curso. Por lo
tanto, es la entidad lógica para definir y reco-
lectar un conjunto de indicadores comunes:
y es el lugar lógico para recolectar informa-
ción del estado de los proyectos para gene-
rar reportes consolidados. Esas actividades
pueden ser triviales si todos los proyectos
recolectan indicadores e información de
estatus con apego a los requerimientos. Lo
cual provoca que estos valiosos servicios se
conviertan en los que potencialmente con-
sumen mayor tiempo y sean los menos pre-
feridos de los que la PMO desempeña.
Un servicio que típicamente está asociado
con una PMO en el mercado, es la presen-
tación de reportes del estado de todos los
proyectos que se están ejecutando en la or-
ganización. Dicho concepto puede extender-
se de tal forma que la PMO dé seguimiento
completo a una vista global del portafolio de
proyectos activos, así como a los pendientes
de iniciar y a la historia de los terminados.
Desde un punto de vista muy simple, esto
podría parecer un ejercicio superficial, pero
puede consumir bastante tiempo. Primero,
la PMO debe trabajar con la gerencia que pa-
trocina el proyecto para definir qué es lo que
formará parte del reporte de estatus consoli-
dado. Algunas organizaciones gustan de man-
tener cada proyecto en una línea, con algún
indicador tipo semáforo del estatus global,
por ejemplo: verde (O.K.), amarillo (precau-
ción) o rojo (problemático). Si es necesaria
más información, se puede dar seguimiento
en conjunto con el gerente del proyecto. Otras
organizaciones gustan más de ver un repor-
te completo con el estatus detallado de cada
uno; si se presentan preguntas o inquietudes,
el reporte de estatus puede contener las res-
José Luis Flores es Director Editorial de TenStep Latinoamérica y tiene más de 25 años de experiencia en Dirección de Proyectos de TI, cuenta con una Maestría
en Desarrollo Organizacional y actualmente es Doctorando en Ciencias de la Administración. Puede ser contactado en: jflores@tenstep.com.mx
50 MAY-JUL 2008
puestas que se están buscando, entonces no
será necesario dar seguimiento adicional con
el gerente del proyecto.
Problemas para la obtención del
estatus
La PMO necesita recolectar información del
estatus de cada proyecto, desarrollar un re-
porte consolidado y exponerlo. Sin embargo,
como todas las actividades que recaen en las
personas, esto puede ser más fácil de decir
que de lograrse. Su PMO probablemente se
encontrará con los siguientes retos:
•Puntualidad. Primero, la posibilidad de
que todos los gerentes de proyecto no envíen
la información del estatus dentro del tiempo
establecido que se necesita.
•Precisión. En muchos casos, la información
no será exacta. Por ejemplo: el gerente del
proyecto puede hacer parecer que su trabajo
se encuentra dentro del plan, aún cuando
no todas las actividades esquemadas están
concluidas. Esto se pude identificar si los
logros a completar en el periodo previo, no
reflejan la misma actividad que se suponía
debería estar terminada de acuerdo con el
reporte de estatus anterior.
•Compleción o completitud. En muchos ca-
sos, la información en el reporte de estatus
es precisa, y puede inclusive estar en tiempo.
Sin embargo, puede encontrarse incompleta.
Por ejemplo: la información proporcionada
puede ser demasiado breve y no representar
el estatus real del proyecto.
Superar los problemas del reporte
de estatus
Desde luego, dichos problemas necesitan
superarse. La PMO puede atacar este tipo
de problemas crónicos a través de las si-
guientes actividades:
•Explicar quién está solicitando la informa-
ción y para qué será utilizada. Este es un
aspecto clave para la presentación de reportes
de estatus consolidado. A las personas no
les gusta invertir tiempo para proporcionar
información, si no sienten que ésta será uti-
lizada. Si las personas entienden quién está
solicitando la información, se puede convertir
en una alta prioridad para ellos.
•Ser claro cuando solicitemos información
que necesitaremos y utilizaremos. Asegúrarse
de no solicitar información que no sea necesaria
para crear el reporte de estatus consolidado.
•Comunicar claramente cuándo deberán
entregarse o presentarse los reportes de
estatus. La PMO tendrá dificultad en el le-
vantamiento de información del estatus en
algún porcentaje de los equipos de proyecto,
por lo tanto, debemos asegurarnos de no propi-
ciar la excusa de que no saben cuándo era el com-
promiso de entrega de los reportes de estatus.
•Dar seguimiento con los gerentes de pro-
yecto a los temas que necesitan mayor
explicación o clarificación. Al recibir infor-
mación de estatus que no contenga el con-
tenido o el formato requerido, se le debe dar
seguimiento con el gerente del proyecto.
Este seguimiento está diseñado para asegu-
rar que los usuarios saben qué se requiere,
para evitar las reuniones continuas con ellos.
•Usar el proceso de gobierno en caso de
ser necesario. Si la PMO está invirtiendo
mucho tiempo para obtener la información
cada mes, se tiene que solicitar ayuda al pa-
trocinador del programa, respaldándose en
el proceso de gobierno de la organización.
Las gerencia Senior debe mantener la res-
ponsabilidad en caso de que los gerentes
de proyecto no puedan generar los reportes
de estatus en tiempo y forma.
www.sg.com.mx
Indicadores consolidados
Existen diferentes lugares donde las organiza-
ciones obtienen valor con la implantación de
un proceso formal de Dirección de Proyectos.
Si no se intenta dar seguimiento y cuantificar
algunos de esos beneficios, la organización no
tendrá idea del valor que se le está proporcio-
nando. Los indicadores asociados con el valor
de la dirección de proyectos, son también in-
dicadores indirectos del valor de la PMO. Por
ejemplo: si hay más proyectos que se finalizan
dentro de las expectativas de la organización,
esto sería un indicador del valor asociado con
la Dirección de Proyectos, y de la misma for-
ma, mostrarían el valor que ésta proporciona.
Indicadores organizacionales
Uno de los temas más difíciles a los que
se enfrenta la PMO, es el determinar el va-
lor de la dirección de proyectos. Es una de
las preguntas fundamentales que deben
hacerse los patrocinadores y la alta direc-
ción en la ejecución de los proyectos de la
organización, y es una de las más difíciles de
contestar exitosamente. Esto parece ser un
valor intuitivo al implantar una metodología
estándar de Dirección de Proyectos, pero se
www.sg.com.mx
intenta cuantificar el valor, se encontrará rá-
pidamente bloqueado. Es un poco parecido
a tomar una nube. Desde otra perspectiva,
parece como si debiese existir algo sólido
que pudiera tomarse con las manos. Sin
embargo, en cuanto más cerca o más de-
talle se consiga, todo se vuelve más vago
y confuso. Existen un par de enfoques para
estos indicadores organizacionales. Uno es
dejarlo a la investigación de la industria, y
buscar compañías y casos de estudio que
son similares a los de su organización para
establecer comparativos adecuados. La idea
resultante de este proceso es que, si alguien
más fue capaz de medir el valor y estamos
inmersos en un proceso similar de desplie-
gue (ya sea de una PMO o de un proceso for-
mal de Dirección de Proyectos), se tendría la
capacidad de obtener un valor similar.
El segundo es intentar calcular el valor asocia-
do con el uso de la metodología. Por ejemplo:
trabajar con los gerentes de proyecto en dife-
rentes tipos de proyectos para determinar los
ahorros asociados al mantener buenos pro-
cedimientos de cambio de alcance, gestión
de riesgos proactivo y gestión efectiva de las
expectativas del cliente. Al realizar la práctica
continua de entrevistar un subconjunto de
gerentes, se comienzan a ver algunas ten-
dencias que puede aplicarse al resto de los
proyectos dentro de su organización.
Y como tercer tema, buscar la reutilización del
valor asociado haciendo uso de un proceso
común de la gestión de proyectos. De nuevo,
este enfoque requiere el solicitar a los geren-
tes de proyecto la estimación de los ahorros
asociados con el uso de procesos similares
en múltiples proyectos y obteniendo así los
beneficios estimados en tiempo y costo por la
reutilización continua de procesos comunes,
obtenidos en diferentes proyectos.
Hay algunas áreas de servicio donde la PMO
no tiene suficiente nivel de experiencia. Los
indicadores podrían ser una de esas áreas.
Muchas compañías no conocen lo suficien-
te acerca de la definición y la captura de un
buen conjunto de métricas. En este sentido,
algunas firmas de consultoría tienen una
gran experiencia en esta área con la cuál po-
drían apalancarse para asegurar un comien-
zo con el pie derecho en este tema.
MAY-JUL 2008
 // PUBLIRREPORTAJE
IDS, Una Empresa Orientada a Procesos
Experiencia en Acreditación CMMI3
Por José de J. Hernández
Ser una empresa orientada a procesos, implica
ser fieles creyentes del beneficio de los proce-
sos, anticiparse en la calidad de los productos
que desarrolla y promover una filosofía de tra-
bajo con prácticas estándar. IDS es una organi-
zación que ha trabajado y trabajará fuertemente
en ello. Este ha sido el espíritu que lo llevó a
alcanzar su siguiente eslabón en la mejora de
procesos: ser una empresa CMMI® nivel 3.
Antecedentes
IDS Comercial es una empresa 100% mexicana
fundada en 1982 que ofrece servicios de
consultoría, desarrollo y capacitación en Tec-
nologías de Información. Tiene participación
en un gran número de proyectos dentro de los
sectores financiero, de seguros, comercial, manu-
factura, telecomunicaciones, servicios y gobierno.
Uno de los principales factores que IDS ha consi-
derado como importante desde sus inicios para
lograr el éxito, es fomentar una cultura orienta-
da a procesos para la ingeniería de software,
apegados a las mejores prácticas, estándares
internacionales y modelos de la industria.
Después de alcanzar el nivel 3 de SW-CMM®
en el año 2004, IDS comenzó un importante
ciclo de mejora en el año 2006 para alinear
su metodología de desarrollo de software al
modelo CMMI® versión 1.2 en su nivel 3.
Como resultado de este esfuerzo, en marzo
de 2008 IDS realizó su evaluación formal,
obteniendo la acreditación como una em-
presa CMMI® con nivel de madurez 3.
¿Cuál ha sido la experiencia de IDS al traba-
jar un programa de mejora continua? A conti-
nuación, describiremos a grandes rasgos algunos
de los factores, consideraciones importantes y
lecciones aprendidas que IDS ha obtenido al im-
plementar un programa de mejora continua.
José de J. Hernández Suárez es Lic. en Informática por la UNAM y Maestro en Ingeniería de Software por el Centro de Investigación en Matemáticas (CIMAT).
Desde 1998 ha trabajado en el campo de la ingeniería de software asumiendo diferentes roles como: desarrollador, analista, líder de proyecto y gerencia de
proyectos, mismos que desempeñó en la Dirección General de Servicios de Cómputo Académico de la UNAM. En los últimos 2 años y medio desempeñó
el puesto de gerente de procesos y calidad de software, estando a cargo de la implementación de CMMI®3 en IDS. Actualmente es director de tecnología y
calidad de IDS Comercial. jjhernandez@ids.com.mx
52 MAY-JUL 2008
Elementos importantes
Para establecer un programa de mejora con-
tinua y trabajar con orientación a procesos,
primeramente debemos instaurar un en-
foque de calidad que nos permita trabajar
con una filosofía de desarrollo de productos
libre de defectos; así como comprender el
costo del re-trabajo asociado al no hacer-
lo de esta manera (costo de la no calidad).
Posteriormente implantar procesos y técni-
cas definidas que nos guíen en la manera
como desarrollaremos nuestros productos;
y finalmente emplear herramientas de apo-
yo a los procesos.
No debemos olvidar que los elementos ver-
daderamente importantes para trabajar
con una orientación a procesos son: gente,
procesos y tecnología. El proceso en sí, es
la mezcla de gente capacitada, procedimien-
tos establecidos y herramientas de apoyo.
Solamente combinando estos elementos
podremos desarrollar productos de calidad.
Estrategia para la Alineación al
modelo de referencia
Para describir las diferentes aristas en las
que debemos trabajar en un programa de
mejora continua, expondremos brevemente
en qué consistió el proyecto que culminó
con la evaluación CMMI de IDS.
Las grandes etapas que consideró el proyecto
fueron:
• Mini Appraisal tipo C. Su objetivo fue eje-
cutar una evaluación informal tipo C que per-
mitiera conocer la brecha entre la definición
vigente de la metodología alineada a SW-
CMM® nivel 3 con respecto a CMMI® nivel 3;
así como identificar oportunidades de mejora.
•Planeación. Con base en lo anterior, defi-
nimos la estrategia y las etapas en las que
se dividiría el proyecto, realizando una pla-
neación detallada al inicio de cada una. Es
importante resaltar que un programa de me-
jora continua debe ejecutarse con las buenas
prácticas de administración de proyectos.
•Definición. Su propósito fue desarrollar to-
das y cada una de las prácticas que hacían
falta incorporar a la metodología de IDS, así
como las mejoras detectadas conforme a las
áreas de proceso de CMMI®. Las definiciones
y mejoras realizadas fueron guiadas, revisadas,
retroalimentadas y validadas por un comité que
para IDS es sumamente importante: el SEPG
(Software Engineering Process Group).
•Implantación. Esta etapa comenzó con
fuertes trenes de capacitación a los inte-
grantes de los equipos de trabajo, conti-
nuando en forma permanente con un mode-
lo de mentoría hacia los proyectos, lo cual
tiene como objetivo apoyarlos en el correcto
uso de los elementos metodológicos.
•Mini Appraisal tipo B. Después de haber
ejecutado durante cierto tiempo la nueva
versión de nuestra metodología, realizamos
una evaluación informal tipo B para deter-
minar qué tan lejos nos encontrábamos del
cumplimiento de las prácticas que marca
CMMI® 1.2 para el nivel 3, y así observar nue-
vamente posibles oportunidades de mejora.
•Ajustes y preparación para la evaluación.
Su enfoque fue realizar ajustes a nuestra
metodología de acuerdo a la etapa anterior,
así como una fase de preparación para llevar
a cabo toda la logística que conlleva una
evaluación formal.
•SCAMPI A. Finalmente, ejecutamos nuestra
evaluación formal, teniendo como objetivo
evaluar nuestro nivel de madurez, detectar
nuevas oportunidades de mejora, así como
obtener nuestra acreditación CMMI® nivel 3.
www.sg.com.mx
Cabe resaltar que como parte de la estrate-
gia, se definió el apoyo de entrenamiento in-
formal y formal en el modelo CMMI, evalua-
ciones informales (mini appraisal), así como
consultoría de un externo, que permitiera
aportarnos enfoques, revisiones técnicas
a las definiciones (peer reviews), retroali-
mentación y soporte en la preparación de la
logística de la evaluación formal con la in-
tención de que IDS no actuara como juez y
parte en su implementación. Este apoyo fue
dado por la empresa Innevo.
Consideraciones importantes y
lecciones aprendidas
Resulta importante comprender que para
trabajar dentro de un programa de mejora
continua deben conocerse, contemplarse y
trabajar los siguientes aspectos:
• Definición e involucramiento correcto de
los roles participantes en el programa de
mejora continua: sponsor, quien patrocina
el proyecto. SEPG, quien analiza, propone,
define, implementa, revisa, retroalimenta y
valida las mejoras; mentores, quienes actúan
como coach de los equipos de trabajo en la
implantación de las mejoras. QA, quienes
aseguran la calidad de los procesos y los
productos de trabajo; champion de la mejo-
ra continua, quién tiene la visión de la mejo-
ra, difunde la filosofía establecida y es res-
ponsable del programa de mejora continua;
agentes de cambio, actores en la operación
de los proyectos, convencidos de la mejora y
que contribuyen a permear lo establecido.
• En la definición de las mejoras es impor-
tante: involucrar a la gente con más expe-
riencia en el campo; tratar de hacer lo más
sencillos y útiles los procesos; utilizar la tec-
nología disponible; hacer partícipes de la
definición a los integrantes de los equipos
de trabajo; realizar talleres para revisar, re-
troalimentar y validar los procesos; conside-
rar en los procesos las bases de definición
de los siguientes niveles de madurez del
modelo; definir las políticas que regirán a
los procesos de la organización acorde a la
misma; capacitación constante en donde se
www.sg.com.mx
sensibilice y palpe la utilidad y beneficio de
un nuevo proceso; realizar workshops para
reforzar el conocimiento; dividir el aprendi-
zaje en módulos, y reconocer a la gente ca-
pacitada y acreditada en los procesos.
• Es necesario trabajar en una sólida estrategia
de administración del cambio que considere:
una campaña de difusión que busque ge-
nerar identidad con la metodología y sensi-
bilización sobre la aplicación de la misma;
distribuir estratégicamente en el tiempo la
comunicación; mantener informada a toda
la organización sobre el trabajo del SEPG;
comunicar cómo va el proyecto; medir y re-
munerar (no de manera monetaria); reforzar el
reconocimiento a través de tips y elementos
adicionales para el uso de los procesos; hacer
el beneficio tangible, motivacional; evidenciar
el beneficio individual derivado del cambio.
• En la ejecución de los procesos en los pro-
yectos, es importante considerar: un proceso
definido para el proyecto, que el equipo
identifique los procesos que va a ejecutar;
asignar un mentor que apoye al proyecto en
todo momento; instaurar diferentes canales
para las propuestas de mejora de procesos;
reconocer a los proyectos que mantengan el pa-
rámetro (umbral) más alto de apego a la meto-
dología; fomentar un espíritu de competencia;
e implementar un QA orientado a servicio.
• Los proyectos deben contar con una infra-
estructura de procesos: repositorio de la defi-
nición de procesos de donde puedan obtener
los elementos metodológicos; mostrar ejem-
plos de la elaboración de los artefactos; publi-
car material de capacitación; difundir leccio-
nes aprendidas; recolectar activos de proceso
(artefactos reales de proyectos finalizados).
Con todos los elementos anteriores debemos
comprender que durante una transición
del cambio, lo viejo y lo nuevo coexiste y la
gente pasa por un momento complicado al
tratar de atravesar del pasado al presente.
Este conflicto puede producir baja producti-
vidad, lo cual hasta cierto grado es normal,
sin embargo, si el período de transición es
sumamente largo, el cambio y el esfuerzo se
abandonan, se pierde la motivación y falla
el proceso de mejora. El secreto consiste en
delimitar y administrar bien esa transición,
buscando construir el compromiso de todos.
El obtener una acreditación en el modelo,
no significa haber finalizado y que podemos
bajar la guardia en los elementos que aquí
exponemos. Tampoco es bueno pensar en pla-
near de inmediato la implantación del siguiente
nivel. Primeramente debemos comprender las
oportunidades de mejora detectadas, y planear
un nuevo ciclo para atacarlas; trabajar en una
estabilización de la utilización de la metodo-
logía, dando el tiempo adecuado para forta-
lecer el nivel de madurez. Una vez logrado
esto, será entonces cuando podremos vol-
tear a un nuevo ciclo de mejora que tenga
como meta el siguiente nivel del modelo.
Basado en: Boria, Jorge, “Change does not Happen”, febrero, 2002.
1
Conclusiones
Implementar un programa de mejora
continua no depende del modelo de re-
ferencia adoptado para desarrollar una
metodología de trabajo. Es importante
buscar y combinar de manera asertiva,
un enfoque de orientación a procesos.
Debemos planear ciclos de mejora
que nos permitan alcanzar a corto y
mediano plazo las metas propuestas,
al lado de una clara y robusta estrategia
de administración del cambio.
Como su nombre lo indica, un programa
de mejora continua nunca termina, pues
siempre existen posibilidades de mejo-
rar: alinearnos a un modelo, optimizar
algo, buscar un siguiente nivel, definir
nuevos productos o servicios para nues-
tros clientes, etcétera. Lo importante es
saber qué queremos mejorar, por qué lo
queremos mejorar y entonces mejorar-
lo, utilizarlo, estabilizarlo y hacer de ello
una filosofía de trabajo.
MAY-JUL 2008 53
 // fundamentos

¿Cuál es mi Password?
La Epidemia de Cuentas
Por Karina Okón

¿Cuántos nombres de usuario manejas para

acceder a las distintas aplicaciones que uti-
lizas en tu trabajo diario? Dependiendo del
tamaño y características de tu empresa, la
respuesta puede variar, pero en general en
organizaciones medianas o grandes, el nú-
mero tiende a ser elevado; pero ¿alguna vez
has pensado en las aplicaciones que resi-
den fuera del área laboral, pero con las que
tienes una relación de negocio?

Casi todos nosotros hemos experimentado

la frustración que supone olvidar una de las
muchas contraseñas necesarias para acce-
der a una determinada aplicación web, y
la pérdida de tiempo (y dinero) mandando
correos electrónicos o hablando por teléfo-
no con el personal de soporte técnico para
cambiar la contraseña olvidada. Aunque los
repositorios únicos de identidades han dado
a los propietarios y gestores de los recursos
control sobre los mismos, han aparecido pro-
blemas graves de seguridad y acceso, al cre-
cer el número de aplicaciones y recursos tanto
dentro como fuera de las organizaciones.
Los usuarios finales tienen demasiadas
cuentas y contraseñas para mantener ade-
cuadamente. Meta Group estima que duran-
te el tiempo de estancia en una empresa, a
un empleado se le asigna una media de 16
contraseñas para acceder a aplicaciones
críticas. Para ser capaces de recordar estas
contraseñas, los usuarios las guardan en si-
tios poco seguros (como un archivo llamado
contraseñas en su PC, post-its debajo del
teclado, etcétera), utilizan la misma clave
en varios sistemas o simplemente esperan
hasta necesitar una determinada cuenta/
contraseña para llamar a soporte técnico.
Todo lo anterior supone una gran pérdida
de tiempo y dinero además de los evidentes
riesgos en la seguridad de la organización.
Figura 1. Arquitectura de autoridad única.
Los propietarios y gestores de los recursos,
se dan cuenta a menudo que el manteni-
miento de las cuentas de los usuarios es un
difícil desafío. La gente cambia regularmen-
te de jefe y/o puesto de trabajo dentro de
la organización, muy frecuentemente sus
accesos a cuentas y aplicaciones no son
deshabilitados con los cambios de funcio-
nes, creándose las llamadas cuentas fantas-
ma que pueden suponer un back door para
que ex-empleados, por ejemplo, accedan a
datos confidenciales de la compañía. Enton-
ces, ¿cuál es la solución?
La agrupación de identidades
La solución al problema de la epidemia de
cuentas viene de la mano de la agrupación
de identidades, que es esencialmente la uni-
ficación de datos dispares de identidades o
cuentas de usuario. Este modelo unificado
permite que los datos, a través de diferen-
tes aplicaciones, estén disponibles dónde y
cuándo se necesiten. Para los usuarios, esto
supone la capacidad de acceder a múltiples
sistemas con una única acción de login, ali-
viando la carga que supone recordar un gran
número de cuentas y contraseñas.
Pasos para el tratamiento
¿Qué debemos hacer para llegar a la agru-
pación de identidades?
Primero, examinar la cultura de la empresa.
Recordemos que hasta ahora los propieta-
rios y gestores de recursos se sienten bien
con el control autónomo sobre los mismos.
Ahora deben estar dispuestos a renunciar a
algún grado de autonomía para conseguir
mejorar el servicio a los usuarios.
Segundo, debe haber una confianza entre los
propietarios de los recursos y los propietarios
de los sistemas de identidades. Esta confian-
za debe ser formalizada en acuerdos legales
y de negocio, que marquen claramente las
responsabilidades de cada uno a la hora de
proporcionar, aceptar y gestionar la informa-
ción de identidades. Este paso es a menudo

Karina Okon. IdM Specialist en BMC Software de México. Especialista en seguridad, ha coordinado y desarrollado proyectos para el aprovisionamiento e integra-
ción de los recursos de seguridad de las corporaciones a las diferentes unidades del negocio; responsable de dar soporte e información al área comercial, socios
de negocio y área técnica acerca de la estrategia del área de seguridad en BMC Software. Ha apoyado al área de ventas a través de capacitación para asegurar
una penetración de mercado más rápida, manteniendo la calidad del servicio a clientes.

54 MAY-JUL 2008 www.sg.com.mx

el mayor reto. Evidentemente, las primeras
relaciones de agrupación de identidades, se-
rán más sencillas en aquellas organizaciones
con las que exista ya una buena relación.
Tercero, son necesarios componentes tecno-
lógicos. Detrás de la agrupación está la ne-
cesidad básica de comunicación entre cada
sistema. Los sistemas están hechos por dis-
tintos fabricantes, utilizando diferentes herra-
mientas sobre plataformas heterogéneas, todo
lo cual conduce a barreras de comunicación al
implementar la agrupación de identidades.
La buena noticia es que hay un número de
estándares de la industria, que permiten in-
ter-operar a una gran variedad de productos
independientes. Estos estándares incluyen:
•SAML (Security Assertions Markup Lan-
guage), estándar definido por OASIS ( Orga-
nization for the Advancement of Structured
Information Standards).
•WS-Federation, especificación promulga-
da por Microsoft, IBM y otros.
•ID-FF (Liberty Federated Identity Manage-
ment Framework). Especificación de Liberty
Figura 2. Arquitectura en estrella.
www.sg.com.mx
Alliance, consorcio de la industria dedicado
a la gestión de entidades federadas.
•Shibbolet, iniciativa de código abierto ba-
sada en SAML.
La implementación de la agrupación de iden-
tidades no es trivial, pero el beneficio supera
con creces los desafíos que tendremos que
vencer. A las mejoras de la seguridad y los
ahorros de costos citados anteriormente, se
une la posibilidad de hacer nuevos negocios
mediante el establecimiento de alianzas en-
tre empresas de distintos sectores. Cuanto
antes se empiecen a examinar los procesos
de negocio, los procesos de TI asociados y
la cultura interna de la compañía, estaremos
en disposición de abordar nuevos retos y sa-
car partido de la agrupación de identidades
para servir mejor a nuestros usuarios, pro-
veedores, socios y clientes.
Ejemplos prácticos
En las gráficas podemos ver dos ejemplos
de agrupación de identidades. En la figura 1
se trata de diversas compañías públicas (un
organismo, una agencia, una delegación y
un patronato) pertenecientes a una misma
tarea. La arquitectura elegida (denominada
autoridad única de gestión de identidades)
está basada en un hub central que actúa
como proveedor de identidades, a excepción
del patronato, el resto de las organizaciones
actúan como proveedoras de datos.
Asimismo, el hub actúa como suministrador de
servicios para todas ellas, menos para el patro-
nato, mientras que las cuatro entidades actúan
como proveedores de servicios hacia el hub.
En la figura 2, podemos observar las distin-
tas identidades del usuario en los diferentes
puntos y las relaciones de confianza entre
ellas. Gracias a estas relaciones una perso-
na puede validarse en el organismo dónde
trabaja, y acceder a una aplicación web de la
agencia con la misma sesión. La arquitectura
en estrella hace posible que no se almace-
ne en ninguna entidad (solamente en el hub
central) las relaciones entre los identificado-
res de cuentas del usuario en las distintas
entidades.
MAY-JUL 2008
 // TECNOLOGÍA
Software Appliances
Los Mejores Amigos de las Empresas en Crecimiento
Por Ariel García
Quienes hemos administrado sistemas co-
nocemos la gran carga de trabajo que esto
conlleva. La administración de licencias, servi-
dores y equipos; contratos de mantenimiento,
control de cambios e incidentes y garantías,
son actividades típicas del día a día. Adicional-
mente, cualquier actualización a la infraestruc-
tura puede implicar días o incluso semanas
trabajando a marchas forzadas para dejar los
sistemas trabajando adecuadamente.
Hace unos años surgió el modelo de Applica-
tion Service Provider (ASP) como una opción
para minimizar la carga de trabajo ligada con
la administración de TI. Aunque este modelo
se mantiene válido, tiene sentido que veamos
más allá, y es aquí donde nos encontramos
con las software appliances. Veamos enton-
ces en que consiste esta tendencia y como se
compara con el modelo de ASP.
Application Service Provider:
la primera alternativa
Bajo el modelo de ASP, una empresa contrata un
servicio –como puede ser el correo electrónico,
o el uso de alguna aplicación– a un tercero,
el cual se encarga de toda la parte de ad-
ministración del servicio de cómputo. Típica-
mente se paga una renta mensual, posiblemente
ajustada al número de usuarios del servicio.
Los distintos servicios ofertados por el
proveedor típicamente son modulares, per-
mitiéndole al cliente final contratar única-
mente la funcionalidad que necesita para
su trabajo. Por ejemplo: el departamento de
contabilidad podría adquirir un servicio de
ERP únicamente con el módulo para la ad-
ministración de activo. El resto de la funcio-
nalidad del ERP no es habilitada y el cliente
solamente pagará por el servicio que utiliza
y no por un producto completo.
La ventaja para el cliente es evidente: se
ahorra costos de administración en los
servicios de cómputo, invierte únicamente
en la funcionalidad que necesita y tiene la
capacidad de activar nueva funcionalidad
conforme la requiera.
56 MAY-JUL 2008
/*INFRAESTRUCTURA*/
Desafortunadamente, la implementación de
servicios de cómputo con un ASP tiene un
inconveniente, este modelo obliga al cliente
a tener información crítica y/o confidencial
del negocio, socios de negocio y/o clientes
fuera de la empresa en manos de compañías
que posiblemente no cuenten con los recur-
sos y/o políticas necesarias para la pro-
tección y seguridad de dicha información.
Negocios con altos requerimientos de segu-
ridad y privacidad pueden implementar una
solución basada en Software Appliance.
Software Appliance: servicios
de cómputo a la medida
Una solución basada en Software Appliance
combina lo mejor del modelo ASP con la ro-
bustez de una solución empresarial tradicional.
El modelo del Software Appliance sigue el
mismo principio de ofrecer módulos de fun-
cionalidad independiente, accesibles a través
de un navegador de Internet, habilitados
acorde a las necesidades del cliente final.
La principal característica del Software
Appliance que lo diferencia de un modelo
ASP es su diseño, el cual consiste en una
capa de software proveedora de la aplica-
ción para el usuario final, corriendo bajo un
sistema operativo modificado y configurado
específicamente para esta aplicación. Este
diseño de alta integración permite que los
componentes de la capa de software y el
sistema operativo puedan configurarse con
mayor seguridad dado que soportan única-
mente las funciones necesarias de la apli-
cación, eliminando servicios innecesarios.
No obstante, ambos componentes (capa de
software y sistema operativo) pueden correr
en cualquier servidor estándar de la industria
(Wintel, RISC, etcétera) o una maquina vir-
tual. (Un Software Appliance que se ejecuta
en una maquina virtual se le conoce como Vir-
tual Appliance). Empresas con altos reque-
rimientos de seguridad pueden utilizar este
modelo para obtener los beneficios de una
baja administración y contar con la seguridad
de tener la aplicación dentro de su infraes-
tructura de cómputo.
Características principales de
un Software Appliance
Compila, corre y ejecuta lo que tenía que ha-
cer a la primera. La instalación y configuración
de los componentes de la capa de software se
ejecutan sin errores en la primera y única co-
rrida. Esto se debe a que no sólo el sistema
operativo está parametrizado de forma es-
pecifica a la aplicación, también lo están el
servidor web y las bases de datos. Además se
utilizan servicios estándar web XML API para
la carga y descarga de datos. Esta caracterís-
tica elimina tareas típicas que complican la
implementación de un esquema tradicional
como: configuraciones especiales para sis-
tema operativo, configuración de seguridad
servidores de web, tunning de bases de datos,
compatibilidades entre versiones de software,
instalación de parches, etcétera.
Lo sentimos mucho, no habrá capacitación
en este proyecto. Su operación y adminis-
tración se ejecuta en un único grupo de
herramientas que eliminan la capa de admi-
nistración del sistema operativo e integran
la administración de la base de datos, ser-
vidor web y la aplicación. Un administrador
de sistemas no necesitará capacitarse para
administrar un Software Appliance corriendo
en una versión de Linux, con Apache y MySQL,
dado que las configuraciones del sistema ope-
rativo y demás aplicaciones, son realizadas a
través de las herramientas de administración
del Software Appliance.
Un solo culpable con habilidades de rege-
neración ... ¡Wow!. Existe una sola cara al
cliente en la detección y solución de pro-
blemas. El proveedor de servicio es el único
responsable de identificar, aislar y resol-
ver cualquier problema dentro de algunos
de los módulos de la aplicación, la capa de
software o el sistema operativo (usualmente
estas actualizaciones no requieren de una mo-
dificación en el hardware). Adicionalmente,
el appliance tiene la capacidad de detectar y
corregir problemas en su operación sin la in-
tervención de un administrador. Debido a que
los componentes de software están altamente
www.sg.com.mx
integrados y son administrados de forma cen-
tralizada, permitiendo que tenga la capacidad
de ser auto-administrable y auto-corregible.
Esto se traduce en la eliminación de las
eternas batallas entre consultores de soft-
ware, administradores de bases de datos y
administradores de sistemas operativos. El
cliente final sabe que la única persona con
la que tendría que trabajar es el proveedor
de servicio, esto en caso de que el Software
Appliance no haya podido corregir por sí
mismo un error en su operación.
Ahora sí es en serio, habrá un control de
cambios documentado. La administración
de cambios se vuelve más sencilla. El pro-
veedor de servicios es el único responsable
del mantenimiento, instalación y configura-
ción de parches, y la actualización a nuevas
versiones en cualquiera de sus componen-
tes del Software Appliance. De hecho, estas
tareas se ejecutarían de forma remota a tra-
vés de las herramientas de administración.
En resumen, los beneficios de una solu-
ción de servicios de cómputo basada en
Software Appliance es clara. Es una solución
con un costo total de propiedad bajo, dado
los bajos costos de mantenimiento y admi-
nistración. No obstante, esta solución tiene
un mercado específico.
A continuación enumeramos algunos indi-
cadores que nos permiten entender si una
solución basada en Software Appliance es
adecuada para nuestro negocio.
1. Infraestructura de sistemas. Es claro que
un software appliance es la solución perfec-
ta para pequeñas empresas que carecen de
un área de sistemas como tal. El mercado de
estas soluciones está orientado típicamente
a compañías de cinco a 500 empleados.
2. Política de compras de la empresa. Esta
solución se comercializa ya sea a través de
una renta por uso o modo prepago. Es claro
que el cliente delega el servicio y manteni-
www.sg.com.mx
miento al proveedor del Software Appliance
con los beneficios ya mencionados.
3. Desempeño. Servicios con un alto grado
de desempeño no son recomendables para
una solución con Software Appliance. En tal
caso es preferible un Hardware Appliance
donde el proveedor entrega el servicio en
una caja negra que integra la capa de soft-
ware, el sistema operativo y el hardware.
4. Estrategia de compras. Para compañías
que acostumbran adquirir equipos con una
expectativa de uso de largo plazo, una solu-
ción basada en Software Appliance es ideal,
dado que es posible ubicar la aplicación en
cualquier servidor estándar.
5. Seguridad. Un software Appliance tiende
a ser más seguro que su contraparte en un
esquema tradicional ya que las capas de
software y sistema operativo son protegidas
de forma más sencilla dado que cuenta con
menos servicios o elementos a ser atacados.
Una vez definiendo si nuestra empresa ca-
lifica para el uso de soluciones basadas en
Software Appliance, podemos analizar las
soluciones existentes en el mercado para
iniciar nuestro análisis y selección de pro-
veedores. Hoy por hoy, podemos encontrar
servicios de Software Appliance con Google,
Wikipedia, Zimbra, entre otros. SAP e IBM
están trabajando conjuntamente en ser-
vicios que podrían ser accesibles en corto
plazo. El mensaje clave de este artículo es
no perder de vista esta tecnología, que con
sus múltiples beneficios, puede ser de gran
valor para la pequeña o mediana empresa
que busca cumplir con el credo de todos los
días: la entrega de mayores y mejores resul-
tados con menos recursos.
Referencias:
[en.wikipedia.org/wiki/Software_appliance ]
[networkworld.com/buzz/2005/092605-
softapp.html ]
[files.zimbra.com/website/docs/Zimbra%
20rPath%20Installation.pdf ]
MAY-JUL 2008
 // TECNOLOGÍA /*gadgets*/

Van Der Led

WM2 Watchphone
Al parecer los diseñadores industriales quieren sorprender el mercado geek con sus
nuevas aportaciones. Remontándonos a la época de los ochenta con Michael Knight y
a la era de los noventa con Dick Tracy (la película). Y es que para usar este reloj, pare-
ciera que el atuendo adecuado es una chamarra de piel o una gabardina amarilla.

Y no es para menos si vemos sus características: GSM, 1.3 pulgadas de tamaño,

260k TFT touchscreen, radio FM, capacidad de almacenamiento de 1GB, Bluetooth
y si eso no es suficiente, un USB para la transmisión de datos. Además cuenta con
una cámara a 1.3 megapixeles y como plus se puede ver la hora.

Así que no hay que sorprenderse si un día con solo doblar la muñeca, llamamos a
Kitt para que nos recoja en la puerta de la oficina.

Solar Technology
Supercharger
De la mano con la ecología y para aprove-
char la energía solar, aparece este nuevo
cargador. Con celdas cristalinas de 1.5 watts
y un peso de 200 gramos se puede llevar en
la mochila, la bicicleta o cualquier otro lugar
porque sus bandas de velcro permiten ajus-
tarlo en algún soporte. Tampoco hay que
preocuparse por la lluvia, viene con una pro-
tección para todo tipo de clima, permitiéndo
su uso constante.

Olympus Sólo cuatro horas de exposición al sol, bas-

tan para tenerlo listo y darle vida extra al
Cámara Stylus 850 SW teléfono, iPod o cualquier otro dispositivo
que sabemos en algún momento necesitará
Para no perder detalle de los eventos, el equipo de SG tuvo la oportu- energía para seguir funcio-
nidad de realizar pruebas con esta nueva cámara de 8.0 megapixeles. nando.
Viene con cable USB, cable de audio/video, batería recargable de litio y
cargador a prueba de congelación. Cuenta con detección de rostros.
Ahora sí, no
Ya no tenemos pretexto de salir de vacaciones y perdernos todos esos hay excusa
paisajes que la naturaleza nos regala. Con este modelo, podremos sacar para no tener
fotografías debajo del agua hasta 3m, además es a prueba de golpes, energía.
caídas y otras eventualidades. Sin importar cuál sea tu estilo de vida,
esta cámara por su tamaño la puedes traer en cualquier momento.

58 MAY-JUL 2008 www.sg.com.mx

 INDEX
DIRECTORIO
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
Anunciante Páginas Sitio
Alpha 55 www.alpha-consultoria.com
Avantare 17 www.avantare.com
CA 7 www.ca.com/mx
Compusoluciones 57 www.compusoluciones.com
Cutter 59 www.cutter.com.mx
e-Quallity 27 www.e-quallity.net
Fone 45 www.juegodetalento.com
Gartner 11 www.gartner.com
IDC 51 www.idc-eventos.com
Information Secutity 47 www.informationsecurity.com.mx
Itera 15 www.itera.com.mx
Kernel 63 www.kernel.com.mx
Manpower 49 www.manpowerprofessional.com.mx
Microsoft 2F, 1 www.microsoft.com/mexico
Milestone Consulting 4F www.milestone.com.mx
Safe Net 3F www.safenet-inc.com
SIE Center 41 ciisa.gda.itesm.mx
SG’08 22, 23 www.sg.com.mx/sg08
SUN 43 www.sun.com.mx
MAY-JUL 2008 31
59
 // COLUMNA
¿Hacia Dónde Vamos?
Reflexiones de la Industria de Software en América Latina
Luis Daniel Soto es director regional de desarrolladores y difusión de pvlataforma en Microsoft para América Latina. Es miembro de la
orden nacional al mérito de México (ministro de educación). Luis Daniel obtuvo el primer lugar en el Concurso Nacional para Software de
Exportación en 1989. blogs.msdn.com/luisdans
H ace doce meses acepté la oportunidad
de dirigir la cuarta área del mundo para Microsoft
relacionada a construcción de software en
América Latina. Por este conducto deseo resumir
y compartir con ustedes mis observaciones rela-
cionadas al desarrollo de la industria de software.
Perfil
Aun cuando América Latina cuenta con el
15% de estudiantes del mundo, representa
el 7% de desarrolladores de software a nivel
mundial y el 1% en cuanto a empresas de
software empaquetado. Nuestra actividad
en la región de inicio usuario de integración
de software internacional, desarrollo a la
medida, educación y mínimamente software
empaquetado.
De acuerdo a Mauricio Santillán de Visionaria,
la utilidad anual de estas empresas es del 10%
en promedio (muestra de 200), los tres clien-
tes principales representan 64% del total de
sus ventas y las áreas que requieren más for-
talecimiento son ventas (74%), mercadotecnia
(54%), servicio a cliente (32%), operaciones
(27%) y perfeccionamiento directivo (17%).
Incluso cuando la parte técnica se considera
robusta y no aparece en la lista, el 85% aún no
incorpora elementos de calidad en construcción
de software, ni el cliente final los demanda.
Muy pocos países tienen programas reales
de apoyo a la industria de software. Hay
diversas asociaciones regionales, por ejemplo
en Costa Rica existe un club de investigación
tecnológica (desde hace 20 años). Los orga-
nismos internacionales se enfocan en empren-
dedores (YABT) y nuevas empresas (RELAPI).
Las oportunidades
Lo más importante es tener el recurso humano.
Diversos estudios muestran que los me-
jores desarrolladores inician a los 13 años.
Los programas académicos deben interesar
desde esa edad a los jóvenes y llevarlos de
la mano desde ahí hasta la culminación de
la carrera. Se deben crear modelos a seguir
que impulsen a otros adolescentes. La mer-
60 MAY-JUL 2008
/*tendencias en SOFTWARE*/
cadotecnia de los exitosos es un ingrediente
que ha faltado en los esfuerzos recientes.
Debemos incorporar mucho más educación
basada por proyecto desarrollado, siempre en
equipo y olvidarnos de tantos exámenes.
Vinculación academia-industria. Es triste,
pero el sector académico está convencido
de que está enseñando lo correcto cuando
más del 80% de egresados requieren entre-
namiento para incorporarse a la realidad.
El tiempo dedicado a decidir qué les ense-
ñaré a los muchachos, ahoga realizar inter-
cambios en los centros de oportunidades
apoyados por el gobierno. La industria y la
academia, requieren hablar mucho más para
identificar las grandes áreas de desarrollo.
El rol del gobierno. Éste, debe favorecer el de-
sarrollo y exportación de software con un gran
enfoque en normatividad que realmente bene-
ficie a la mayoría. En mi opinión personal, debe
alentar la neutralidad tecnológica, evitando te-
mas que reduzcan el ámbito de opciones.
El rol de la mujer. Menos del 9% de desa-
rrolladores profesionales de software son
mujeres. Basta decir que estamos limitando
el 50% de los recursos humanos existentes.
Ellas continúan discriminadas sin ser con-
sideradas para su rápido desarrollo. Este
tema ha cobrado auge mundial. El paradig-
ma errado de muchos gobiernos es fomentar
que las mujeres hagan negocio en bisutería.
Para la industria existente. Hay que tomar
en serio el negocio. En Israel, las empresas
más pequeñas de software con frecuencia
contratan a un doctor en mercadotecnia y
cuentan con procesos formales de venta. En
este sentido, se están creando programas
apropiados para el perfeccionamiento di-
rectivo, hay que continuar a la búsqueda de
los recursos externos que puede darle alto
valor a la empresa.
Montar las grandes oleadas. El cambio más
grande al que nos enfrentamos es a la trans-
formación a una era de software como servi-
cios, pero sin duda la habilitación de la nueva
mercadotecnia o mercadotecnia cercana a costo
cero, es un tema que tiene que ser digerido
por las empresas de todo tipo.
Recursos humanos
• Crear “iconos” para atraer talento
• Incorporar a las mujeres
• Educación por proyecto
• La academia debe producir recursos útiles
y quitarse la falsa ilusión de que hoy lo hace
Industria
• Dejar de creer que el gobierno debe resolver todo
• Reforzar ventas y mercadotecnia
• Eliminar la rivalidad entre los nacionales
Oportunidades a ganar
• Infraestructura y capacidades para el
Software más servicios (TI)
• Ser habilitadores de la “nueva mercadotecnia”
Conclusión
En México, el PROSOFT apunta en la
dirección correcta, debemos permitirle
avanzar rápido. Aunque cada región
tenga vocaciones particulares, deben
ser construidas sobre una base común.
El futuro de las tecnologías es muy
brillante en cuanto a novedades, pero
sobre todo en cuanto a aplicaciones
para mejorar nuestras vidas diarias y
la misión de nuestras empresas.
¡Participa como agente de cambio!
» Luis Daniel Soto
Referencias:
[ visionaria.com ]
[ clubdeinvestigacion.com ]
[ relapi.org ]
[ myybiz.net ]
www.sg.com.mx

Software en la Comunidad
Simulación Participativa para la Sustentabilidad Ambiental
Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde
1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones.
Ferviente entusiasta de la aplicación social de la tecnología, a últimas fechas está 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
E n cuanto conocí el trabajo de simulación
participativa para enseñar sustentabilidad
ambiental del Dr. Luis García Barrios, inves-
tigador en El Colegio de la Frontera Sur en
San Cristóbal de las Casas, Chiapas; consi-
deré imprescindible hablar de él. Luis y un
equipo de voluntarios llevan varios años tra-
tando de resolver el problema ambiental de
raíz, capacitando, con ayuda de software, a
las personas de las comunidades más apar-
tadas de Chiapas para que utilicen los recursos
de sus tierras sin daño al ambiente.
El ejemplo más interesante de estos trabajos,
es el realizado con el Marco de Evaluación de
Sistemas de Manejo Incorporando Indicado-
res de Sustentabilidad (MESMIS). Este es un
esfuerzo por crear una metodología de evalua-
ción de prácticas de sustentabilidad para los
recursos naturales, que permita indicar qué
tan abastecidas o no son las prácticas de ex-
plotación de los recursos naturales de un lugar
determinado. Este trabajo ha sido reconocido
a nivel mundial y es producto de varios inves-
tigadores mexicanos agrupados en el Grupo
Interdisciplinario de Tecnología Rural Aplicada
(GIRA). El trabajo de Luis en este equipo ha
sido introducir un elemento dinámico y sisté-
mico con la finalidad de enriquecer a MESMIS
logrando extenderlo más allá de un marco de
evaluación hacia una herramienta de educa-
ción para la sustentabilidad rural.
El MESMIS interactivo cuenta con 4 capítu-
los de los cuales 2 son simuladores de sus-
tentabilidad. La idea es lograr que las perso-
nas participen de una forma activa a través
de un drama en tres actos que les muestre
los problemas reales en la toma de decisio-
nes de sustentabilidad combinando simula-
ciones de software, elementos teatrales y
de juegos de rol.
En el primer acto, se muestra una cuenca don-
de todo era bosque, luego diez familias lle-
gan y desmontan 100 hectáreas con siembra.
www.sg.com.mx
/*tierra libre*/
Al cabo de décadas con el crecimiento de la
comunidad y los diversos apoyos guberna-
mentales para el campo, la mayoría de ellos
implementados sin tener en cuenta los prin-
cipios de sustentabilidad, las ahora 1000 fa-
milias deforestan 4000 hectáreas. El gobier-
no en respuesta, crea una área protegida y
reduce la superficie para las familias, por lo
que los campesinos ahora tendrán que recu-
rrir al uso de fertilizantes para poder sobrevi-
vir con el terreno reducido. En el software, los
usuarios van viendo simulaciones a través de
series de tiempo, dinámicas, puntos de equi-
librios y diversos umbrales para ver de que
forma este sistema simulado reacciona ante
estas estrategias de explotación.
En el segundo acto, aparecen nuevos per-
sonajes, los pescadores del lago al final de
la cuenca y los dueños comunitarios de una
villa eco turista. En esta etapa, se aprende
que el uso de fertilizantes para lograr ma-
yor productividad afecta de forma muy clara
la ecología del lago, que además es mucho
mas difícil restaurar que un sistema terres-
tre. Mostrando el escenario de la cuenca,
los participantes pronto descubren que es
imposible encontrar una combinación del
manejo de recursos que deje satisfechos a
todos los actores. El drama de la utilización
de los recursos naturales que tanto nos esta
afectado de forma global se manifiesta.
La resolución se obtiene en el tercer acto,
donde los participantes aprenden que los
diferentes actores deben de ayudar a crear
un sistema equilibrado. En el caso particu-
lar de la cuenca, la solución del problema
proviene de apoyos que las comunidades
del lago y la villa eco turista proveen a los
productores del campo cuenca arriba, para
utilizar combinaciones de árboles que per-
miten reducir los fertilizantes.
Una de las historias más inspiradoras es la
del programador que ayudó a realizarla, un
// columna
voluntario llamado Max Pimm; matemático
inglés, residente en Barcelona desde hace 5
años, quien se entera del proyecto MESMIS
y viaja a México para trabajar como volunta-
rio con el grupo de investigadores de GIRA.
Posteriormente se entera del trabajo de Luis
con la propuesta de generar modelos inte-
ractivos de MESMIS . Inspirado por el poten-
cial del proyecto trabajó por 3 meses en los
cuales logró generar todo el sistema. Según
sus propias palabras, lo mas importante fue
la posibilidad de ver su conocimiento aplicado
en un trabajo participativo con gran significado.
Actualmente, el equipo con nuevos volunta-
rios trabaja en el futuro de MESMIS Interac-
tivo. Las próximas versiones incorporarán
desde el diseño del sistema a todos los ac-
tores sociales en una plataforma donde se
puedan modelar los problemas en un terri-
torio específico, y la gente pueda explorar
las consecuencias y entender sus decisio-
nes sobre sus ambientes a través de simu-
laciones interconectadas en red. Se prevee
usen tecnología de vanguardia en la simu-
lación de agentes autónomos y motores de
inferencia para las reglas del sistema.
De mi parte, un agradecimiento sincero a
Luis García Barrios por su trabajo y ser fuen-
te de inspiración para quien escribe. Para
ustedes, amigos lectores, la invitación a co-
nocer, en sus entornos locales, qué trabajos
de investigación se están haciendo, para
que además de que haya voluntarios que
cruzan de otro continente a colaborar, existan
también voluntarios mexicanos aportando
en tan valiosos esfuerzos.
Si desean obtener datos de como contactar
al Dr. Luis Garcia Barrios o dejarnos sus co-
mentarios, pueden checar mas información y
fotos del proyecto en tecnonirvana.org
» Emilio Osorio
MAY-JUL 2008 61
31
 // columna INVITADA

Del Buzón de Sugerencias

a la Colaboración Empresarial
Enterprise 2.0
Por Tomás Helou

El término Web 2.0 cada día se encuentra más El uso de Web 1.0 a nivel empresarial, inició tal como la conocemos con la creación de páginas
arraigado en el vocabulario tecnológico de para las empresas, donde detallaban servicios y contenidos; esto lo realizaba un programador
nuestros días, pero ¿nos hemos cuestionado de la misma empresa, es decir, la generación de los contenidos recaía en unas cuantas manos
qué significa realmente? ¿Cuál es la diferen- y eran esas manos las que decidían lo que debía incluirse en sus sitios, ya sea empresariales o
cia entre Web 2.0 y Web 1.0? ¿Qué ventajas personales. Esto ha ido cambiando, y en la actualidad sitios como You Tube o MySpace, propi-
ofrece a nivel corporativo? La mayoría de los cian la colaboración de los usuarios comunes y corrientes.
CEOs de las grandes empresas han escucha-
do hablar sobre las tecnologías Web 2.0. ¿Qué es Web 2.0 y Enterprise 2.0?
Diferencias y similitudes
Hace algunos meses se dieron a conocer los
resultados de una investigación realizada
por Forrest Research, dicho sondeo se reali-
zó con 275 compradores de TI, de los cuales
16% de los encuestados dicen que han escu-
chado acerca del tema, ya que los fabrican-
tes hablan mucho sobre él. En ocasiones el
50% escucha hablar a los proveedores, 20%
esporádicamente o casi nulo ha sido su con-
tacto con la Web 2.0: y 11% restante jamás
ha recibido comentarios acerca de esta tec-
nología por parte de sus distribuidores.

Cuando lo social genera

ganancias
Antes de continuar, debemos de dar un vis-
tazo a lo que realmente significa Web 2.0, el
término se refiere a la segunda generación
de servicios de Internet, donde la colabo-
ración a los contenidos y las redes sociales
son la innovación fundamental. Las princi-
pales diferencias entre Web 1.0 y Web 2.0
las enmarcamos de la siguiente manera:

La Web Empresarial 2.0 se puede dividir en
dos, una cuya finalidad es el uso interno y
otra que va hacia el exterior. Ambas tienen
mucho que ver con el aspecto comunicacio-
nal de la empresa, ya que una se dirige a los
clientes y otra a los empleados.
Las características externas o de relaciones
públicas de Enterprise 2.0 son aplicables a
marketing, relaciones públicas, servicio al
cliente, entre otras. Por lo que tiene un alto
impacto en la relación con clientes y socios es-
tratégicos, pues dentro de las funciones que
se realizan en el área externa, se abarcan des-
de investigación de mercados, lanzamiento y
promoción de nuevos productos y la más im-
portante: la retroalimentación con los clientes,
así como la visión y opinión corporativa ante
los temas que evitan información tergiversada
dentro de los medios de comunicación.

Tomás Helou es actualmente Director Regional BID de BEA Systems, graduado de la Universidad de Ciencias Empresariales y Sociales (UCES) de Buenos Aires,
Argentina con una maestría en Marketing. Anteriormente fue Vicepresidente Internacional de Operaciones de Fuego, Inc. Vicepresidente para Latinoamérica de
Business Objects SA, Vicepresidente para Latinoamérica de MRO Software Inc. entre algunos otros cargos, siempre destacando por sus conocimientos sobre
Business Process Management BPM, dictando conferencias y participando en diferentes eventos referentes a este tema.

62 MAY-JUL 2008 www.sg.com.mx

Las características internas se enfocan más a
lo que se refiere a Gestión del Conocimiento,
es decir, está enfocado a las comunicaciones
dentro de la empresa, ya sea en toda ella o
por células, donde pasan su prueba y pos-
teriormente son usadas en toda la organiza-
ción. Sus áreas de mayor uso son gestión y
planificación estratégica, desarrollo e innova-
ción tecnológica y gestión de proyectos.
Para poder implementar los servicios de
Web 2.0 y transformar nuestra compañía en
una Enterprise 2.0, debemos tener conoci-
miento de la manera en cómo se construyen
las aplicaciones, ya que usan códigos abier-
tos a través de API’s (Interfase de Programa-
ción de Aplicaciones) y servicios web.
No solamente la integración de clientes, so-
cios y empleados es una ventaja de este tipo
de herramientas, pues las aplicaciones son
reutilizables y combinables. Las interfaces
usadas deben de funcionar como una apli-
cación tradicional que otorgue al usuario un
manejo sencillo y por consecuencia otorgue
mayor productividad, haciéndola rentable
para las empresas. La arquitectura de estas
aplicaciones, debe permitir la utilización de
estándares que faciliten el manejo de datos
y la comunicación, para que permita la reuti-
lización de módulos, por ejemplo: para la
creación de mashups.
Comunitario, pero no inseguro
La seguridad tiene un papel decisivo para
que las empresas pasen a engrosar las filas
de Web 2.0 y sean Enterprise 2.0, ya que
piensan que estas herramientas son vulne-
rables y propician la propagación de virus y
troyanos; nada lejos de la realidad, estas son
igual de vulnerables que las usadas dentro
de la web tradicional, y la solución o pre-
vención para dichos ataques no es algo que
salga de lo convencional; un buen sistema
preventivo soluciona en gran parte estos ata-
ques, de tal manera que las empresas deben
de implementar soluciones de productos de
seguridad tradicionales como anti-spyware,
anti-phishing, filtrado de URLs y contenido;
antivirus, anti-spam y políticas de limpieza
centralizadas (para ayudar a reducir el daño).
Seguir una protección de múltiples capas y
múltiples vertientes permite la protección
total contra las amenazas virtuales.
Beneficios de Enterprise 2.0
Ya que facilita la descentralización de tecno-
logías, Enterprise 2.0 entrega beneficios a
las empresas que la implantan, como:
www.sg.com.mx
• Aceleración en el desarrollo del mercado
de las empresas que la implementan.
• Reduce costos en infraestructura, ya que
su arquitectura es escalable.
• Su intercambio de información es eficien-
te, lo que se traduce en un mejor enlace con
el cliente y mejor producción.
• El ROI se consigue en menor tiempo.
No siempre es bueno cambiar
el papel por Bases de Datos
Ya que se entendió qué es Enterprise 2.0,
debemos cuestionarnos y analizar si es apli-
cable para nuestra empresa o no, ya que hay
ciertos factores antes, los cuales no es re-
comendable a migrar a este tipo de tipo de
tecnologías:
•Cuando encontremos a los empleados rea-
cios al uso de estas innovaciones, ya que no
se logrará sacarle jugo como es debido.
•Cuando se desconoce lo que es un email o
una página web.
•Y quizás los factores más importantes:
cuando una sola persona se encarga de
tomar las decisiones, sin tomar en cuenta
opiniones de gente de menor rango en la
empresa y no acepta opiniones del personal
a su cargo.
Cuando encontramos alguna de estas tra-
bas, debemos pensar mejor en seguir al-
macenando nuestra información en papel, y
continuar con la estrategia de negocios que
se tenía, sin buscar la innovación. Ya que si
no conocemos el uso de las nuevas herra-
mientas, éstas por sí solas no solucionarán
nada, y por el contrario, no sabemos qué
consecuencias negativas puede tener su
mal uso o desconocimiento.
Conclusiones
Podríamos decir que las organizaciones
que adoptan las tecnologías Web 2.0
fortalecen su red interna, de manera
que la colaboración se hace similar a un
clúster (lugares físicos donde se concen-
tran industrias que unen fuerzas para
colaborar entre sí). Así que cualquier
empresa que adopte los principios de
esta tecnología, da un peso específico
a la relación que debe de tener con sus
clientes, empleados, socios, etcétera.
Ya que al permitirles colaborar, se des-
conocen jerarquías con el afán de seguir
todos una misma dirección que resulte
benéfica para todos los involucrados en
el proceso de negocio.
MAY-JUL 2008
 // columna
Scheme
El Mundo entre Paréntesis
Dr. Raúl A. Trejo es profesor investigador del Instituto Tecnológico y de Estudios Superiores de Monterrey, campus Estado de México. Su
área de especialidad es la inteligencia artificial, con una particular pasión por la programación. Conoció el paradigma funcional con Basic
y Pascal, se graduó en objetos con Eiffel, Ada y Java, y probó la lógica de Prolog. Pero siempre admiró la elegancia de Scheme: (define
infinito (λ ( ) ((λ (f) (f f)) (λ (f) (f f))))). El significado de esta expresión se encuentra en: tech-o-potamus.blogspot.com
Imagina que no hay ciclos
en tu programación
no existen for ni while
tan sólo recursión.
Imagina a la gente
entre paréntesis…
Este es un fragmento de una canción que
me encontré en un foro de discusión para el
lenguaje Scheme (en Usenet), junto con la
instrucción de que debía cantarse con la me-
lodía de la canción Imagine de John Lennon.
Era mediados de los noventa. Me encontra-
ba aprendiendo y recolectando información
sobre lenguajes funcionales en general, y
de Scheme en particular para un proyecto
educativo de mi campus en el Tec de Mon-
terrey. Esa canción, junto con el contenido
exaltado y a veces autocomplaciente de al-
gunas entradas en el foro, formó mi primera
impresión del lenguaje, la cual no difería
mucho de la opinión de la mayoría de los
programadores de los paradigmas clásicos:
parecía un lenguaje académico, orientado
a estudiantes de posgrado en inteligencia
artificial. Sólo que en mi institución estába-
mos pensando adoptarlo, no como un len-
guaje para materias avanzadas, sino para
los cursos de computación básica, en lugar
de C o el cada vez más popular Java. Las dis-
cusiones no se hicieron esperar. Recibimos
una gran cantidad de cejas levantadas, pero
en mi departamento éramos un pequeño
grupo con espíritu visionario y mucha cu-
riosidad; de modo que le dimos luz verde al
proyecto. Scheme era un lenguaje definiti-
vamente extraño. Su estructura sintáctica se
basaba en expresiones funcionales escritas
en notación prefija, rodeada por paréntesis.
De modo que para expresar, por ejemplo: la
suma entre dos números, se debía escribir
la siguiente sentencia: (+ 5 7)
La construcción de expresiones más com-
plejas generaba entonces una cantidad de
paréntesis que de inmediato se convirtió en
el blanco de las bromas entre profesores y
64 MAY-JUL 2008
/*cátedra y más*/
alumnos. Sin embargo, descubrí que, enun-
ciando las expresiones de manera funcional,
la sintaxis resultaba intuitiva. Así,
(raizCuadrada (+ (cuadrado a) (cuadrado b)))
se leía como “la raíz cuadrada de la suma del
cuadrado de a con el cuadrado de b”, con
los paréntesis definiendo de manera exacta el
significado de la expresión. El corazón del len-
guaje era la definición de nuevas funciones por
medio del operador lambda. De este modo, la
función cuadrado se declaraba como:
(define cuadrado (λ(x) (* x x))) 1
Fue aquí que decidí que me agradaba el len-
guaje. No había tipos de datos (o más bien,
para los puristas, sólo hay tipos débiles), lo
que permitía escribir funciones interesantes
a tan solo horas de conocer el lenguaje. Los
números eran verdaderamente polimórficos,
permitiendo operaciones entre enteros y
reales sin distinción, sin riesgo de overflow.
Existía una única estructura de datos: la lis-
ta. Y como estructura de control, se utilizaba
la recursividad. Comenzamos a utilizar Scheme
en los cursos de computación básica, y para
mitad del semestre los alumnos podían re-
solver problemas típicos de un curso de
estructuras de datos. Inventé ejercicios in-
teresantes para ellos, fascinado por la liber-
tad que el lenguaje me daba para enseñar
algoritmos y lógica de programación.
Sin embargo, resultó que estábamos adelan-
tados a nuestro tiempo. Algoritmos elegantes
o no, los estudiantes extrañaban la deslum-
brante interfaz visual de Java. Se preguntaban
el por qué aprendían un lenguaje que no exis-
tía en la industria. Y definitivamente, odiaban
los paréntesis. El escepticismo ganó, dimos
por terminado el proyecto y Java ocupó su
lugar como el lenguaje reinante en el aula.
Para entonces yo estaba fascinado con el
lenguaje. La razón era que, desde su dise-
ño, incorporaba características que facilita-
ban la labor del programador. Por ejemplo,
los lenguajes funcionales ya incluían el uso
de algoritmos de recolección de basura y la
pre-compilación de funciones (el antecedente
de la máquina virtual) desde antes de que
Java popularizara los conceptos. Además, es-
taba la alta capacidad de abstracción de estos
lenguajes: aprendí, por ejemplo, que podía
definir funciones que operaban sobre listas de
tamaño infinito, que las funciones mismas no
eran diferentes de los tipos de datos básicos, y
que podían utilizarse como entradas o salidas
de otra función. De modo que lo utilicé en mis
proyectos durante mis estudios de doctorado,
creando soluciones elegantes que sorpren-
dían a mis compañeros por su simplicidad y
corto tiempo de desarrollo. Esto era un triunfo
pequeño dado que, mi uso del lenguaje había
regresado al ambiente académico.
Diez años después, la industria de desarro-
llo ha pasado por la programación orientada
a objetos, la programación por eventos y la
programación orientada a servicios. ¿Cuál
es el siguiente paso en la evolución de los
lenguajes? Al parecer, es la aparición de
lenguajes multi-paradigma, que incorporan
finalmente el paradigma funcional, el orien-
tado a objetos y el imperativo. Me parece in-
teresante que la comunidad en general esté
adoptando estos lenguajes, y que finalmente
el paradigma funcional pudiera salir del ámbito
académico. Python es uno de estos lenguajes,
con una popularidad en aumento. La plata-
forma .NET contará con F#, y para el desarrollo
web se tiene Perl 6. Todos estos lenguajes están
basados en Haskell, un sucesor de Scheme.
Me siento optimista de que puedo volver a
programar en un lenguaje funcional. Y esta
vez, con una sintaxis menos extraña: Haskell
no tiene paréntesis.
» Dr. Raúl A. Trejo
1
Para el lector curioso, esta expresión se lee como “define
cuadrado como la función que recibe el parámetro x, y
regresa la multiplicación de x por x”.
www.sg.com.mx
No. 20 www.sg.com.mx SG SOFTWARE GURU - CONOCIMIENTO EN PRÁCTICA Mayo-Julio 2008