•

Aseguramiento de
Calidad
• Casos de Uso
• Arquitectura
Empresarial

Software Guru CONOCIMIENTO EN PRÁCTICA

No.23 • Febrero - Abril 2009 • www.sg.com.mx

[ Especial ]
Premios SG 2008

[ MEXICANOS EN EL EXTRANJERO ]
Miguel Madero
Rodrigo García
Arie Grapa
La Inteligencia de Negocios
México. $65 MXN
como herramienta estratégica

[ Tutorial ]
Noticias • Eventos • Fundamentos • UML • Infraestructura • Tendencias JUnit 4
 // CONTENIDO
Editorial
En estos tiempos de presupuestos
recortados, todas las organizaciones se
ven en la necesidad de hacer “más con
menos”, y la inteligencia de negocios es
una herramienta fundamental para lograr
esto. Es por ello que dedicamos el artículo
principal de esta edición a este tema. Hace
justamente tres años (Enero-Febrero 2006)
ya habíamos dedicado el artículo principal
de SG a este mismo tema. Analizando como
ha cambiado o evolucionado la inteligencia
de negocios en este tiempo, consideramos
que lo más notable es el énfasis que se
está haciendo actualmente para introducir-
lo en las PyMEs. Hasta hace unos años, la
inteligencia de negocios era algo que sola-
mente los grandes corporativos hacían. Sin
embargo, conforme los sistemas de infor-
mación han permeado en las pequeñas y
medianas empresas, también ha llegado la
capacidad (y necesidad) de sacarle jugo a
la información que éstos generan.
Presentamos la segunda edición de los
Premios SG, donde buscamos reconocer
los productos más populares entre nues-
02 FEB-ABR 2009
tros lectores. Agradecemos su asidua
participación y pronta respuesta tanto en
la nominación como en la elección de los
ganadores para las diferentes categorías.
La información recabada nos ayuda a te-
ner una mejor idea de las herramientas
y tecnologías más utilizados por los pro-
fesionales de desarrollo de software en
nuestra región.
En esta ocasión publicamos una pequeña
entrevista con tres profesionistas de soft-
ware de origen mexicano que actualmente
laboran en el extranjero. Más allá de pre-
sumir los logros de estas personas (que
sí merecen presumirse), lo que queremos
hacer notar es que estas son personas
comunes y corrientes, que estudiaron en
nuestro país. Para poder estar en el mismo
lugar que ellos basta con trabajar duro y no
ponernos barreras.
Agradecemos a todos nuestros lectores y
colaboradores por seguir apoyando esta
querida revista con el entusiasmo de siem-
pre. Les deseamos lo mejor para este año.
» Equipo Editorial
directorio
Dirección Editorial
Pedro Galván
Dirección de Operaciones
Mara Ruvalcaba
Coordinación Editorial
Alejandro Escamilla
Arte y Diseño
Grisel Otero
Desarrollo Web
Nathanael Gutiérrez
Consejo Editorial
Jorge Valdés - PMI; Luis Cuellar - Softtek;
Francisco Camargo, Luis D. Soto - Microsoft;
Hanna Oktaba - UNAM; Ralf Eder, Raúl
Trejo, Guillermo Rodríguez - ITESM CEM;
Emilio Osorio - Sistemas Humanos;
Luis Vinicio León - e-Quallity.
Colaboradores
Gunnar Wolf, Francisco Vaca,
Ernestina Ortíz, Dafne Rosso,
Héctor Franco, Erick Frausto,
Rodrigo Corral, Ma. Julia Orozco,
Claudia Alquicira, Oswaldo Gómez,
Alejandro Ramírez, Carlos Ortega,
Charlie Macías, Manik Surtani, Rob Smoot,
Susana Tamayo, Edna Gutiérrez,
Agustín Gutiérrez, Aurora Pérez
Luis Márquez, Miguel Madero,
Rodrigo García, Arie Grapa, Jaime Ruíz
Ariel Jatuff, Guadalupe Bautista.
Ventas
Claudia Perea
Circulación y Administración
Edgar Dorantes
Contacto
info@sg.com.mx
+52 55 5239 5502
SG Software Guru es una publicación trimestral
editada por Brainworx S.A. de C.V., Malinche no. 6,
Col. El Parque, C.P. 53398, Naucalpan, México. Queda
prohibida la reproducción total o parcial del contenido
sin previo aviso por escrito de los editores. Todos
los artículos son responsabilidad de sus propios
autores y no necesariamente reflejan el punto de
vista de la editorial. Reserva de Derechos al Uso
Exclusivo: 04-2004-090212091400-102. Certificado
de licitud de título: 12999. Certificado de licitud de
contenido:10572. ISSN: 1870-0888. Registro Postal:
PP15-5106. Se imprimió en febrero de 2009 en Roma
Color, S.A. de C.V. Distribuido por Sepomex.
www.sg.com.mx
 contenido
feb - abr 2009

26 EN PORTADA
Inteligencia de Negocios 26
La inteligencia de negocios como
herramienta estratégica.

Premios SG 2008 18

Productos
LO QUE VIENE 12
ASP.Net MVC, Spring + BlazeDS,
Python 3 y Drools 5

TUTORIAL 14
JUnit 4.

Columnas Prácticas
Tejiendo Nuestra Red 08 Prueba de Software 52 ARQUITECTURA 38
por Hanna Oktaba por Luis Vinicio León Enteprise Architecture
La arquitectura empresarial se encarga de alinear la
Mejora Continua 10 Tendencias en Software 54 estrategia, los procesos y la tecnología.
por Luis Cuellar por Luis Daniel Soto
REQUERIMIENTOS 40
Programar es un Modo 47 Cátedra y Más 64 Cuando los Casos de Uso no Alcanzan
de Vida por Raúl Trejo Recomendaciones sobre la correcta
por Gunnar Wolf aplicación de los casos de uso.

PROCESOS 42
En Cada Número COMPETISOFT
Mejora de procesos de software en Iberoamérica
Noticias y Eventos 04 INFRAESTRUCTURA 58
ASEGURAMIENTO DE CALIDAD 44
INDUSTRIA 06 TENDENCIAS 60 Implementación de Modelos de
Calidad
FUNDAMENTOS 56 GADGETS 62 Diagnóstico de las empresas en México

UML 48
Las Relaciones son Importantes

22
Aprendamos a detallar relaciones en base a la infor-
mación de diagramas de secuencia.

PM CORNER 50
Perfiles Aplicando Project Management al BI
Miguel Madero Analizamos los puntos clave para administrar
Rodrigo García proyectos de inteligencia de negocios.
Arie Grapa

www.sg.com.mx FEB-ABR 2009 03

 // NOTICIAS

Microsoft PDC 2008

Del 27 al 30 de octubre del 2008 se llevó a cabo en la ciudad de Los
Angeles el Microsoft Professional Developer’s Conference (PDC)
2008. Este evento se realiza cada dos o tres años con el objetivo
de mostrar a los desarrolladores las tecnologías que Microsoft es-
tará liberando en el futuro próximo. Entre los temas que más des-
tacaron estuvieron: Azure, una plataforma para cloud computing;
Windows 7, la próxima versión del sistema operativo para desktop;
Oslo, una nueva plataforma para desarrollo dirigido por modelos
(MDD), y diversos proyectos de Microsoft Research tales como
Microsoft Surface y Worldwide Telescope. Durante este año estare-
mos publicando en SG artículos relacionados con estos temas.

Las sesiones del PDC 2008 están disponibles en:

www.microsoftpdc.com

Gartner “The Future of IT 2008”

Durante la 11ª Conferencia Anual sobre el Futuro de las Tec-
nologías de Información, Gartner presentó una visión de las ten-
dencias más importantes de las TI que tendrán un impacto en
las empresas en los próximos cinco años. Analistas de Gartner
presentaron temas como virtualización, software como servicio,
y seguridad; incluyendo casos de estudio y páneles de discusión.
El evento ofreció a las empresas mexicanas una perspectiva real
de la industria, e información fundamental para alinear las TI con
sus objetivos de negocio.

BajaTech Business Solutions 2.0

El Clúster de Tecnologías de Información de Baja California, A.C.
(IT@baja), realizó por primera vez durante el pasado mes de No-
viembre el evento “BajaTech Business Solutions 2.0”, un punto de
encuentro entre las empresas proveedoras de soluciones tecnológi-
cas con el sector empresarial. La inauguración presidida por el Ing.
Ismael Álvarez Silva, Presidente de IT@baja, fue realizada de manera
simultánea en las ciudades de Tijuana y Mexicali, logrando la partici-
pación de más de 50 empresas de TI y telecomunicaciones, quienes
interactuaron con cerca de 1,000 empresarios de la región. BajaTech
cumplió su misión de impulsar el desarrollo tecnológico y fomentar
el uso de las TI en los sectores productivos y sociales de la región.

Para conocer más visita: www.itbaja.com

04 FEB-ABR 2009 www.sg.com.mx

 // EVENTOs

17 al 19 de Febrero 2009 26 al 28 de Febrero 2009

CompuShow 2009 SISCTI
Cintermex Monterrey, Nuevo León Tecnológico de Monterrey, Campus Monterrey
Info: www.compushow.com.mx Info: www.siscti.com
e-mail: info@compushow.com.mx e-mail: saul.cruz@siscti.com

24 de Febrero 2009 26 y 27 de Marzo 2009

Tendencias 2009 WebSec Conference 2009
Select IDC México
Centro Banamex, México, D.F. Hacienda de los Morales, México, D.F.
Info: www.select.com.mx/tendencias/tendencias09/index.html Info: www.idc-eventos.com
e-mail: liliana.garcia@select.com.mx e-mail: denriquez@idc-eventos.com

25 de Febrero 2009
Information Management & BI 2.0 28 y 29 de Abril 2009
Conference Gartner Enterprise Integration Summit
IDC México Centro Banamex, México, D.F.
Hacienda de los Morales, México, D.F. Info: www.gartner.com/mx/appint
Info: www.idc-eventos.com e-mail: latin.america@gartner.com
e-mail: denriquez@idc-eventos.com

GULEV 2008 Arranca proyecto para desarrollo de

La paradisiaca playa de Cancún fue sede de la edición 2008
del Congreso Internacional de Software Libre GULEV, realiza-
do del 4 al 6 de diciembre. Este año, el invitado de honor fue
Rasmus Lerdorf, creador de PHP, quien impartió un taller sobre
monitoreo y optimización de aplicaciones, además de una plá-
tica sobre el pasado y futuro de PHP.
Las presentaciones del GULEV 2008 están disponibles en
www.gulev.org.mx/eventos/gulev2008
Capital Humano
El proyecto dirigido por IMPULSA “Modelo de Vinculación
Empresa-Academia-Gobierno para el Desarrollo en Capaci-
dades de Capital Humano en TI”, inició sus actividades. Este
proyecto busca resolver una necesidad urgente de México:
contar con profesionistas capacitados y certificados, que
puedan integrarse a la industria.
Cabe mencionar que este proyecto es apoyado por ANIEI y
AMITI, y ha sido financiado por el BID. Pronto conoceremos
más a detalle sus avances e impacto.

Empresas recientemente evaluadas en CMMI:

Empresa Evaluación Fecha Lead Appraiser Apoyado por
SAITO CMMI Nivel 2 marzo 2008 José Enrique Pérez SIE Center
PLENUMSOFT CMMI Nivel 2 julio 2008 Enrique Morey SIE Center
Grupo Mnemo CMMI Nivel 3 agosto 2008 Mariana Pérez-Várgas Avantare
Vicerrectoría de RH y TI, Tec de MTY CMMI Nivel 2 diciembre 2008 José Enrique Pérez SIE Center
Qualysis CMMI Nivel 3 enero 2009 Mariana Pérez-Várgas Avantare

www.sg.com.mx FEB-ABR 2009 05

 // INDUSTRIA
Mejorando la Industria
Adoptando MoProSoft
Como ya hemos visto anteriormente en es-
tas páginas, el Modelo de Procesos para
la Industria de Software (MoProSoft) es un
modelo de calidad que permite a la peque-
ña y mediana empresa de desarrollo de soft-
ware el acceso a las prácticas de Ingeniería
de Software y Administración de Proyectos.
MoProSoft está basado en el modelo SW-
CMM, en el estándar ISO 9000 y el reporte
técnico ISO/IEC TR 15504.   aplicar las mejores prácticas.
El propósito de la norma NMX-I-059/02-NYCE
es proporcionar una guía de implantación
para el modelo MoProSoft, ya que en nues-
tro país 85% de las empresas dedicadas al
Desarrollo y Mantenimiento de Software son
PyMES. Por su estructura, diseño, fácil com-
prensión y aplicación, esta norma es adecua-
da para implantar un programa de mejora.
La adopción de MoProSoft habilita la ob-
tención de un certificado de la norma NMX-
I-059/02-NYCE y/o ISO 9000 y reduce la
brecha para la obtención de una evaluación
CMMI® nivel 2.
En marzo de 2006 se iniciaron las verificacio-
nes formales, y actualmente ya contamos con
más de 100 empresas verificadas en algún ni-
vel de la norma, y continuamente se agregan
más. Para conocer las empresas verificadas
visita: www.nyce.com.mx/dictamenes.htm
Debido al corto periodo que lleva la implan-
tación de MoProSoft, aún no se cuenta con
métricas cuantitativas suficientes que per-
mitan conocer la mejora e impacto en las or-
ganizaciones, pero sí contamos con un dato
muy valioso, lo que sus usuarios opinan:
• La implementación del modelo tardó va-
rios meses, pero bien valió la pena, ya que
cumplió el objetivo de satisfacer las necesi-
dades de los clientes.
• Existe un cambio real en la cultura de la
organización (cuestiones de horarios, com-
promiso de las personas).
• La definición e instrumentación de los
objetivos organizacionales permite deli-
near nuestras actividades.
• Los procesos documentados funcionan
como guías de las actividades que debe-
mos realizar.
16
06 FEB-ABR 2009
• Se establecieron medios de comunicación
que han permitido una mejor relación con
los clientes y satisfacer sus necesidades.
• Las prácticas de administración de proyec-
tos nos han ayudado a optimizar el manejo
de recursos.
• Se establecieron formatos base consen-
suados al interior de la organización que
nos permite concentrar el conocimiento y
• Ya contamos con medios de difusión y co-
municación en la Organización.
• La base de conocimiento concentra el cono-
cimiento y experiencia acumulada que será
útil para futuros proyectos.
• Se formalizaron las funciones del área de
Recursos Humanos.
ASUM
En respuesta a la adopción de MoProSoft
en la industria mexicana, se ha creado
la Asociación de Usuarios de MoProSoft
(ASUM), la cual tiene una misión clara y
concreta: integrar a la comunidad interesa-
da en el modelo MoProSoft para promover
su estudio,  adopción,  mejora y difusión a
nivel nacional e internacional, represen-
tando los intereses de los asociados ante
los organismos e instituciones pertinentes.
De igual manera, busca brindar a sus aso-
ciados, conocimiento y dominio de MoPro-
Soft, información actualizada, bibliografía,
red de contactos, investigación, piloteo de
proyectos, círculos de estudio y colabora-
ción con otros organismos.
La ASUM se enfoca en los siguientes puntos:
• Elevar el nivel de competitividad de la in-
dustria de software mediante la promoción
del modelo MoProSoft y su valor.
• Mejorar el modelo mediante el estudio de
los resultados de sus implementaciones, así
como la investigación de temas relacionados.
• Ser el vínculo coordinador de los usuarios
del modelo para propiciar el intercambio de
mejores prácticas.
• Promover programas que contribuyan a
la misión de la asociación realizando acti-
vidades en conjunto con la industria, go-
bierno y academia.
• Intercambiar experiencias  y colaborar
con organizaciones afines nacionales e in-
ternacionales.
• Contribuir a la identificación, definición y
promoción de los estándares derivados del
modelo MoProSoft. 
• Asesorar a empresas privadas, organis-
mos gubernamentales y académicos sobre
el buen uso del modelo.
• Respaldar la correcta implementación
del modelo mediante el sello de confian-
za para proveedores de servicios. Trabajar
coordinadamente con los organismos veri-
ficadores oficiales.
Actualmente existen varios proyectos eje-
cutándose en la Asociación, todos admi-
nistrados por distintos equipos de trabajo,
como por ejemplo:
• Proyecto  de Vinculación. Estandarizar los
criterios de implementación y verificación del
modelo entre los consultores y organismos
verificadores.
• Proyecto de Promoción. Contribuir con la
identificación, definición y promoción de es-
tándares derivados. Orientar a organismos
sobre el valor del modelo.
• Proyecto de Investigación. Investigar  e
incorporar guías para apoyar  la implanta-
ción del modelo.
• Proyecto de Mejora. Identificar los hallaz-
gos y proponer enmiendas a la norma. Me-
jorar el modelo a partir de las buenas  prác-
ticas identificadas. Recopilar  y publicar las
mejores prácticas. 
MoProSoft ha sido reconocido internacional-
mente, siendo utilizado como base de diferen-
tes normas y modelos. Las empresas mexica-
nas debemos aprovechar que este modelo ha
sido creado en México y tomar ventaja para
lograr una industria más competitiva.
Únete a la ASUM contacta:
asummoprosoft@gmail.com
Los responsables son:
• Coordinador General: Dra. Hanna Oktaba
• Coordinador Suplente: Ariel Jatuff
• Secretario: Karla Fernández
• Coordinación de Mejora: Guadalupe Bautista
• Coordinación de Promoción: Ariel Jatuff
• Coordinación de Vinculación: Jorge Palacios
• Coordinación de Investigación: Blanca Gil
www.sg.com.mx
www.sg.com.mx FEB-ABR 2009 17
07
 // COLUMNA /*TEJIENDO NUESTRA RED*/
Reunión del WG 24 en la Ciudad de México
Orgullosos Anfitriones
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.
D el 10 al 14 de noviembre de 2008 México fue el país anfitrión
de la reunión del grupo de trabajo WG24 del subcomité SC7 del
JTC1 ISO/IEC. En esta ocasión se batió record de asistencia de
32 delegados. Por supuesto, México aprovechó la ocasión de
ser sede y designó a 12 delegados, aún así 20 personas de 10
distintos países no se había visto en ninguna reunión anterior.
Tailandia mandó 8 representantes, lo que muestra un fuerte apoyo
por parte de su gobierno al proyecto de estándar liderado por su
compatriota Tanin Uthayanaka. Llegaron los dos representantes
habituales de Japón y de Estados Unidos, así como uno de Canadá,
Finlandia, Bélgica y Colombia. Faltó solo el representante de Irlanda,
que no pudo conseguir recursos. Las nuevas incorporaciones
fueron dos representantes de Perú, una de Argentina y uno de
Sudáfrica. Los peruanos y la argentina son mis colegas del proyec-
to COMPETISOFT y fervientes promotores de MoProSoft como una
alternativa del modelo de procesos en sus países.
La reunión se desarrolló en las instalaciones de CANIETI, en la
Ciudad de México, organizada y coordinada de manera excelente
por Fernando Solís, con apoyo de Angélica Fonseca. Después de
una breve inauguración nos dividimos en cinco grupos de trabajo,
uno por cada parte de la norma, para analizar los comentarios re-
cibidos. La delegación mexicana se dividió de la siguiente manera:
Juan Manuel Hernández, Arturo Ramírez y Cuauhtémoc Nápoles del
NYCE, junto con Jorge Palacios (JPE) se unieron al grupo que revi-
saba comentarios a la parte tres Assessment Guide, dirigido por el
experto finlandés en la ISO/IEC 15504, Timo Varkoi. Ana Vázquez
(Praxis/UNAM) coordinó los trabajos de la parte 4-1 Specification –
Basic Profile acompañada por japoneses, peruanos y tailandeses.
Mientras que Claudia González (Kernel), Blanca Gil (SIE) y Diana
Guzmán (Avantare), se unieron al grupo de la parte 5-1 Management
and Engineering Guide – Basic Profile coordinado por Perry Deweese
de Estados Unidos y su servidora. Había otras personas de México que
no pudieron estar toda la semana, pero ocasionalmente se reunían a
los grupos de trabajo para observar o participar en las discusiones.
El trabajo fue arduo, de 9:00 a 17:00 horas, con una hora para co-
mer, que gracias al patrocinio de Microsoft se sirvió en una sala
adjunta, lo que ahorraba los traslados, pero no se prestaba mucho
para el descanso. Cada comentario recibido se discutía en grupo
para lograr el consenso, si se aceptaba aceptaba en principio o
rechazaba. En el primer caso, se aceptaba la propuesta del que
08 FEB-ABR 2009
emitió el comentario, en el segundo se tenía que describir qué es
lo que se acepta y qué no se acepta y, en el último caso, había
que redactar una justificación convincente. Todo por supuesto, en
inglés. Aquí quiero reconocer el gran trabajo que realizaron Ana
Vázquez para la parte 4-1, y Claudia González con Blanca Gil para
la parte 5-1. Quienes redactaron lo que se llama “disposition of
comments”, que entregamos al final de la reunión.
Hubo comentarios que afectaban a más de un documento, o to-
dos. Para discutirlos, Tanin nos convocaba a una sesión plenaria
durante la cual teníamos que llegar al consenso. En una de éstas,
acordamos cambiar el nombre de Very Small Enterprises por Very
Small Entieties, lo que mejor refleja la definición de empresas, de-
partamentos o proyectos con menos de 25 personas. Lo bueno de
este acuerdo, es que la abreviatura VSE no cambia, lo malo es que hay
que solicitar permiso de JTC1 SC7 para modificar el nombre del estándar.
Otro de los comentarios que llevó a una discusión plenaria, fue el
tema de si los perfiles van a requerir de un modelo de evaluación
propio, o es suficiente referirse a la ISO/IEC 15504. Es un tema que
surgió hace varias reuniones y todavía sigue sin lograr consenso.
Algunos consideramos que sería bueno tener algo específico, por lo
que no nos quedó mas que aceptar el compromiso como delegación
mexicana, de hacer una propuesta para la siguiente reunión que
será en mayo de 2009 en la India.
En cada reunión también resurge el tema del Perfil Básico que es
todavía demasiado complejo para los grupos realmente pequeños,
de menos de 10 personas. Analizamos la lista propuesta por Canadá
y Bélgica de prácticas mínimas de administración del proyecto y
del propio desarrollo y, después de una acalorada discusión y unas
cuantas modificaciones, delegamos a los dos países que preparen
una propuesta para la siguiente reunión.
Nosotros, como México, esbozamos la posibilidad de crear dos perfi-
les más amplios, el Intermedio (agregando los procesos de Gerencia)
y Avanzado (con Gestión de Negocio) basados en MoProSoft. Nos
comprometimos a presentar el borrador de las partes 4-2 y 5-2 del
Perfil Intermedio para la próxima reunión. Es un compromiso muy
fuerte por lo que invito a todos los que han experimentado con
MoProSoft a nivel 2 y 3, a que me envíen sus sugerencias de prác-
ticas que tengan valor real para las empresas.
www.sg.com.mx
Terminamos la revisión de comentarios, y los demás pendientes, el
jueves por la tarde. Esa misma noche NYCE, nuestro segundo patro-
cinador, nos ofreció una agradable cena en WTC. Las palmas de la
noche las llevó el grupo de mariachi que dejó a todos muy sonrien-
tes y, a algunos, bailando. Todos se llevaron de regalo una botellita
de tequila con dos caballitos, por lo que las clases de tomar tequila
correctamente tuvieron mucho éxito.
Los extranjeros estaban felices porque podían aprovechar el viernes
para hacer turismo. Pero no todos, el finlandés Timo aceptó con gusto
dedicar su mañana a un encuentro con la delegación mexicana para
discutir el tema de evaluaciones basadas en ISO/IEC15504. No asistí a
la reunión, pero sé que fue muy interesante y provechosa.
El viernes 14 de noviembre llevé al canadiense Claude Laporte, la
colombiana Lily Gómez, la argentina Paula Angeleri y los peruanos
Abraham Dávila y Víctor Guevara, a visitar la UNAM. Fue un día de
sol esplendoroso. La Ciudad Universitaria se estaba luciendo con
su Biblioteca y sus murales como Patrimonio de la Humanidad. Los
alumnos, con sus fachas tan particulares, aparecían en cantidades
industriales por el fin del semestre. El Centro Cultural con su espacio
escultórico, el nuevo Museo Universitario del Arte Contemporáneo,
los volcanes que aparecieron en el horizonte y la comida al aire libre
www.sg.com.mx
en Azul y Oro, dieron el toque final. Los invitados quedaron total-
mente embobados y decidieron continuar la aventura en las trajine-
ras de Xochimilco, donde ya no los acompañé.
Los días siguientes, Claudia, Blanca, Ana y yo nos dedicamos a in-
corporar todas las correcciones aprobadas o aprobadas en princi-
pio en las partes 4-1 y 5-1. Fue un trabajo muy complicado porque
las dos partes dependen una de otra, y los cambios tuvieron que
ser sincronizados. Además, con Claudia trabajamos a distancia
desde Monterrey, y con Ana desde Montreal. Al fin lo logramos, y
el 18 de diciembre subimos las nuevas versiones al sitio del WG24.
Ahora nos espera el siguiente turno de revisión y votación, la pre-
paración de los siguientes perfiles y del modelo de evaluación.
El trabajo va para largo. Según los planes, el primer perfil saldrá
como estándar en 2010. Espero que mis colegas, que en esta oca-
sión pudieron ver los trabajos del WG24 de cerca, así como los
organismos gremiales y gubernamentales, se convenzan que el
esfuerzo vale la pena. No hay duda, México ya aparece como país
que está aportando estándar internacional para la industria de
software. Apoyen el esfuerzo.
» Por Hanna Oktaba
FEB-ABR 2009 09
 // COLUMNA
El Diablo no Sólo Está en los Detalles
También Está en los Defectos
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 todas las industrias tanto de produc-
tos como de servicios los defectos son el
principal problema que debemos evitar. No
hay nada que moleste a un cliente más que
no recibir lo que esperaba debido a la falla
de una máquina o un individuo, los defectos
son el enemigo número uno. Pero por alguna
razón esto no parece aplicar a la industria de
sistemas. Tal vez se deba a nuestros orígenes,
donde dos jóvenes crean una industria des-
de la cochera de su casa. Parece ser que en
nuestro caso los defectos son ineludibles, un
efecto secundario que debe esperarse; desde
la liberación de gigantescos sistemas opera-
tivos que salen a la venta bajo la premisa de
que continuamente se liberaran parches para
resolver todos los problemas que surjan, has-
ta el proyecto de mantenimiento, autorizando
que la corrección de un defecto detectado sea
manejado como un nuevo requerimiento para
facilitar el proceso.
En los proyectos de software, la principal pre-
ocupación es la entrega a tiempo: gastamos
una interminable cantidad de horas estiman-
do el esfuerzo, planeando el proyecto, y dan-
do seguimiento a cada paso. En mi experien-
cia, una gran cantidad de proyectos barridos
no se deben a malas estimaciones sino a la
cantidad de cambios en los requerimientos,
la experiencia de la gente que lleva a cabo el
proyecto, y la cantidad de defectos que se ge-
neraran y se tienen que resolver.
El problema de la medición
Puntos funcionales, líneas de código,
números de módulos; existe gran can-
tidad de formas de estimar un proyec-
to, pero extrañamente no parece haber
tantas formas de definir un defecto. No
quiero decir que medir el tamaño no es
importante, ya que no es lo mismo tener
3 defectos en cien líneas de código que
3 defectos en mil líneas de código. Medir
tamaño consistentemente es básico para
medir densidad de defectos. Pero necesita-
10 FEB-ABR 2009
/*MEJORA CONTINUA*/
mos trabajar más en una definición que nos
sirva para medir defectos.
Al igual que en la definición de tamaño, no
podemos tener una sola métrica para toda
la industria, ya que las necesidades son di-
ferentes dependiendo del tipo y característi-
cas de cada organización. Al crear una defi-
nición de defectos para tu organización, son
importantes estas dos características:
1. Que sea consistente. Esto quiere decir
que si seleccionamos una forma de medir
defectos necesitamos poder mantener la de-
finición congruente a través de los diferentes
proyectos, con esto comparamos si estamos
mejorando o no a través del tiempo.
2. Se requiere una métrica con suficiente granu-
laridad como para darnos información útil. Por
ejemplo si contamos un programa defectuoso
como un solo defecto sin importar cuantas lí-
neas tengan error y nuestro sistema tiene una
pequeña cantidad de programas, no tendremos
suficiente información para encontrar y mejorar
nuestra salida de defectos.
Características de los defectos
Los defectos tienen diferentes características,
pero hay dos especialmente importantes:
1. Crecen en forma exponencial debido a un
efecto llamado “la fábrica escondida” (the
hidden factory). Este fenómeno indica que si
tenemos varios pasos en un proceso y cada
paso tiene un porcentaje de defectos, la po-
sibilidad de que el producto final no tenga
defectos es igual a la multiplicación de las
posibilidades de cada paso. Por ejemplo, si
tenemos un proceso con cinco pasos y te-
nemos un 90% del producto bien en cada
paso, al final la posibilidad de terminar sin
defectos es de 90%^5 = 59%. Si conside-
ramos la cantidad de pasos que se llevan al
desarrollar software, entenderemos lo dificil
que es tener un sistema sin defectos.
2. Se ha demostrado que los seres humanos
tendemos a repetir errores. Cuando nos equi-
vocamos haciendo algo, el error es parecido a
errores anteriores. Nuestro cerebro teje redes
que se van formando gracias a la repetición
de nuestras actividades, por lo que si te equi-
vocas en la declaración de variables de un
programa en forma consistente, aumenta la
posibilidad de que en el futuro te equivoques
en lo mismo.
Esto nos lleva a dos estrategias que nos
ayudan a reducir la cantidad de defectos en
nuestros productos:
1. Revisar los productos durante sus dife-
rentes pasos. Está demostrado que no es
suficiente probar el sistema hasta el final
del proyecto, sino que cada fase: análisis,
diseño, programación, etc. debe considerar
actividades de prueba. No sólo es impor-
tante medir la cantidad y tipo de defectos,
sino la eficiencia de las pruebas mismas
a través de métricas de grado de escape
(escape rate) que midan el número de defec-
tos, la fase donde se generó el defecto y la
fase donde finalmente se detectó.
2. Si acostumbramos repetir errores, enton-
ces el utilizar checklists para hacer las revi-
siones es la estrategia con mayor retorno de
inversión y creo que de los menos utiliza-
dos. Algunos checklists internos nos ayudan
a recordar en lo que se ha equivocado otras
personas, pero deben ser personales.
“Los humanos se equivocan, nadie es per-
fecto”, Esto es cierto pero no debería ser
una excusa para no trabajar lo mejor posi-
ble. De alguna manera si queremos crecer
y superarnos como industria es sumamen-
te importante que nos hagamos responsa-
bles de lo que hacemos y aprendamos de
nuestros defectos.
» Por Luis Cuellar
www.sg.com.mx
www.sg.com.mx FEB-ABR 2009 11
 // PRODUCTOS /* LO QUE VIENE*/
ASP.Net MVC
Desarrollo web civilizado
Una tecnología que está teniendo muy buena recepción en-
tre los desarrolladores de aplicaciones web con la plataforma
.Net es ASP.NET MVC. Éste es un framework para desarrollo
web basado en el patrón Modelo-Vista-Controlador. Como tal,
ASP.NET MVC es una alternativa a Web Forms que ofrece los
siguientes beneficios:
• Clara separación de responsabilidades entre componentes
• Soporte para test-driven development
• URLs limpios
En enero se liberó el Release Candidate de ASP .NET MVC y se
espera que la versión 1.0 esté disponible al público en general
durante el primer trimestre del año.
Más información en www.asp.net/mvc
Python 3
Por fin llega
La comunidad de desarrolladores de Python liberó el pasado di-
ciembre la versión 3.0 de este lenguaje de programación. Python ha
cobrado gran popularidad en el último par de años no sólo por su
poder, sino también por su flexibilidad. Otro factor que lo ha impul-
sado es el hecho de que Google lo haya elegido como el lenguaje
default para el Google App Engine.
Esta nueva versión, anteriormente conocida como Python 3000, intro-
duce una gran cantidad de cambios, y lo más significativo es que no
es compatible con la versión anterior (2.6). Lo que significa que para
migrar aplicaciones a Python 3 hay que cambiar código para satisfa-
cer la nueva sintáxis y APIs. Afortunadamente existe una herramienta
que automáticamente traduce el código de una versión a otra.
Más información en www.python.org
12 FEB-ABR 2009
Spring + BlazeDS
Lo mejor de dos mundos
SpringSource y Adobe anunciaron el proyecto Spring
BlazeDS Integration, el cual proveerá una integra-
ción robusta entre Spring y Adobe BlazeDS. Dicha
integración permitirá desarrollar fácilmente aplica-
ciones basadas en el framework Spring que utilicen
Adobe Flex como cliente front-end.
SpringSource también está desarrollando un adap-
tador para Adobe LiveCycle Data Services, logrando
así que las aplicaciones Spring puedan “empujar”
datos para la generación de interfases gráficas en
tiempo real con Flex.
Más información en www.springsource.org/spring-flex
Drools 5
Integración de reglas de negocio, procesos y
manejo de eventos
La próxima versión de Drools (5) promete traer una
oferta bastante atractiva en el área de los sistemas
para manejo de reglas de negocio (BRMS). Esta nueva
versión integra en un solo producto, la capacidad de
modelar procesos, definir reglas, gestionar la ejecu-
ción de procesos con reglas, y procesar eventos de
negocio. La integración de estas capacidades pone a
Drools a la par de los productos líderes en el mercado,
con la ventaja de que Drools es open source.
Drools 5 actualmente está disponible como versión
previa (Milestone release) y se espera que la versión
para producción se libere en febrero.
Más información en www.jboss.org/drools
www.sg.com.mx
www.sg.com.mx FEB-ABR 2009
 // PRODUCTOS /*tutorial*/

JUnit 4 - ¡A Toda Máquina!

Introducción a la Evolución y Nuevas Características de JUnit 4
Por Erick Frausto

En este artículo presentaremos la evolución que ha sufrido el Así haríamos la misma prueba con JUnit 3:
framework para el desarrollo de pruebas unitarias JUnit en su
última versión, así como sus nuevas características. import junit.framework.TestCase;

Objetivos de la versión 4 de JUnit public class CalculatePercentageTest extends TestCase {

JUnit es ya de por sí un framework que facilita en demasía el desa-
private double x = 50.0;
rrollo de prueba unitarias, pero ahora la versión 4 simplifica más el private double y = 20.0;
desarrollo de éstas por medio de la explotación de las anotaciones public void testCalculatePercentage() {
otorgadas por Java 5, eliminando el desarrollo de pruebas basado en double z = x * (y/100);
subclassing, reflection y convenciones de nombrado. assertEquals(10.0, z);
}

La intención de Kent Beck (creador de JUnit junto con Erich Gamma) }

con esta nueva versión, es animar a más desarrolladores a escribir
más pruebas unitarias por medio de la simplificación de JUnit.
Una vez conocidos los objetivos de esta versión, veamos cómo apli-
car las nuevas características de JUnit haciendo comparativas sobre
cómo es que hacíamos la cosas en la versión anterior.
Como podemos ver en la implementación de la prueba con JUnit 4,
no ha sido necesario heredar de la clase TestCase ni poner el prefijo
test a cada uno de los métodos de prueba por lo que podríamos ge-
nerar nuestras propias convenciones de nombrado de pruebas.

Métodos de prueba Evolución de los métodos setUp() y tearDown()

Con JUnit 4 se eliminan las convenciones de nombrado y el uso
de reflection para localizar los métodos de prueba. Ahora, para
señalar un método de prueba lo anotaremos con @Test. No será
necesario heredar de la clase TestCase para hacer uso de los
métodos assertXXX() y podremos hacer uso de ellos mediante
la utilización de importaciones estáticas, característica propor-
cionada por Java 5. Ejemplo:
Los métodos setUp() y tearDown() ya no serán necesarios, los métodos
anotados con @Before y @After toman su lugar. Además de eliminar
las convenciones de nombrado, podremos tener tantos métodos
anotados con @Before y @After como deseemos, donde la ejecución
de estos métodos se hace en el caso de los métodos anotados con
@Before antes de ejecutarse cada uno de los métodos de prueba y la
de los métodos anotados con @After se hará después de la ejecución
de cada una de las pruebas. Ejemplo:

import org.junit.Before;
import org.junit.Test;
import org.junit.Test; import static org.junit.Assert.*;
import static org.junit.Assert.*;
public class CalculatePercentageTest2 {
public class CalculatePercentageTest2 {
private double x;
private double x = 50.0; private double y;
private double y = 20.0;
@Before public void initializeTest() {
@Test x = 50.0;
public void calculatePercentage() { y = 20.0;
double z = x * (y/100); }
assertEquals(10.0, z);
} @After public void finalizeTest() {
}
} …
}

14 FEB-ABR 2009 www.sg.com.mx

 “ La nueva versión de Junit 4 simplifica el
desarrollo de pruebas por medio de explotación
de las anotaciones otorgadas por Java 5”.

En JUnit 4 se introduce una característica sin equivalente en JUnit 3 ¡La claridad de esta prueba en JUnit 4 es excepcional!
con el comportamiento de los métodos anotados con @BeforeClass y
@AfterClass. Sólo puede existir un método anotado con @BeforeClass y Ignorando pruebas
uno con @AfterClass, ambos métodos sólo se ejecutarán una sola vez Ya no será necesario comentar un método de prueba cuando no que-
por todos los métodos de prueba existentes, antes de la ejecución ramos que éste se ejecute, quizá porque aún no desarrollamos la
de éstos en el caso del método anotado con @BeforeClass y después implementación del código a probar o porque sólo queremos probar
de la ejecución de éstos en el caso del método que sea anotado con algún otro método en particular. Los métodos anotados con @Ignore
@AfterClass. Dicha característica sirve bien para apertura y cierre de serán ignorados para su ejecución. Ejemplo:
recursos necesarios para la ejecución de pruebas, pero que son cos-
tosos en cuanto a desempeño al momento de abrir y/o cerrar.
import org.junit.Ignore;
Prueba de excepciones import org.junit.Test;
La forma en que se prueba el lanzamiento de una excepción en JUnit 4
public class ExceptionTest2 {
también cambia en relación con JUnit 3. Ejemplo:
private int[] array = new int[2];
private String str;
import org.junit.Test; …

public class ExceptionTest2 { @Ignore

public void ignoreTest() {
private int[] array = new int[2]; str.contains(“a”);
}
@Test(expected=ArrayIndexOutOfBoundsException.class)
public void testException() { }
int x = array[2];
}

} Ayuda en pruebas de desempeño

JUnit 4 proporciona ayuda para realizar pruebas de desempeño den-
tro de las pruebas unitarias. Y aunque no resuelve de todo el tema
Así haríamos la prueba con JUnit 3: de este tipo de pruebas por no ser su objetivo principal, sí proporcio-
na una ayuda importante. Ejemplo:

import junit.framework.TestCase;
import org.junit.Test;
public class ExceptionTest extends TestCase {
public class PerformanceTest {
private int[] array = new int[2];
@Test(timeout=2000)
public void testException() { public void performanceTest() {
try { for(;;);
int x = array[2]; }
fail(“Exception does not occur”);
} }
catch(ArrayIndexOutOfBoundsException success) {
assertNotNull(success);
}
} En el ejemplo anterior estamos diciendo que si la ejecución de la
prueba pasa los 2000 milisegundos se interrumpirá su ejecución. El
}
mensaje que arrojará será el siguiente:

www.sg.com.mx FEB-ABR 2009 15

 // PRODUCTOS /*tutorial*/

“JUnit 4 proporciona ayuda para

realizar pruebas de desempeño dentro de
las pruebas unitarias”.

PerformanceTest Failed – test timed out after 2000 milliseconds Conclusión

Nuevas aserciones
JUnit ha sido diseñado desde sus inicios, para de manera eficiente
poder capturar las intenciones del desarrollador sobre su código
y rápidamente poder revisar que cubra éstas intenciones. Sin em-
bargo, existen algunas cosas que son difíciles de decir con JUnit 3 y
que con JUnit 4 se hará mas fácil integrando la aserción assertThat().
Nota: Esta nueva aserción se incluye a partir de la versión 4.4 del
framework. Ejemplo:
• JUnit 4 más que una nueva versión de ésta ya de por sí po-
derosa herramienta para pruebas unitarias, es la versión más
significativa desde el surgimiento de este framework.
• Basando su funcionamiento mediante la explotación de las
características de Java 5, permite un desarrollo de pruebas
más flexible sin la rigurosidad de convenciones de nombrado.
• Se aportan nuevas formas para realizar pruebas como lo son
las de desempeño, y una manera mucho más elegante para
probar el lanzamiento de una excepción.

import org.junit.Test; • Con la versión 4.4 se agrega la capacidad de poder decir de

import static org.junit.Assert.assertThat; una manera más fácil a través de nuestro código, aquéllas co-
import static org.junit.matchers.JUnitMatchers.either; sas que antes eran más complejas, esto mediante assertThat().
import static org.junit.matchers.StringContains.containsString;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.CoreMatchers.not; • Con esta nueva versión de JUnit se simplifica la escritura de
pruebas unitarias, por lo que se agiliza su desarrollo, inten-
public class NewAssertionsTest { tando motivar a más desarrolladores a escribir más pruebas
unitarias haciéndolo ¡a toda máquina!
private int x=3;
private String str = “colour”;

@Test public void newAssertions() {

assertThat(x, is(3)); Referencias
assertThat(str, is(not(“color”)));
assertThat(str, either(containsString(“colour”)).and(not(containsString(“color”))));
[ junit.org ]
}
} [ -128.ibm.com/developerworks/java/library/j-junit4.html ]

[ devx.com/Java/Article/31983 ]
La intención de assertThat como mencionamos antes, es poder expresar
mediante el código que escribimos, la prueba que queremos realizar. [ code.google.com/p/hamcrest/ ]

Erick Frausto es egresado de la carrera de Ingeniería en Informática de UPIICSA–IPN, cuenta con certificaciones SUN en tecnología Java y actualmente se des-
empeña como Arquitecto JEE. Erick invita a todos, a nunca dejar de soñar y luchar por hacer sus sueños realidad.

16 FEB-ABR 2009 www.sg.com.mx

www.sg.com.mx FEB-ABR 2009
18 FEB-ABR 2009 www.sg.com.mx
Los Premios SG son un reconocimiento a los productos
y tecnologías para desarrollar software que más des-
tacaron en el año. El objetivo es conocer cuáles son las
herramientas más populares entre los lectores de SG.
Dado que estos son premios “elegidos por
los lectores”, el mecanismo utilizado con-
siste en que a través de un wiki abierto, los
participantes de SG nominaron productos
que consideraron deberían estar en cada
categoría, y posteriormente se realizó una
encuesta donde las personas eligieron sus
productos favoritos de entre los nominados
para cada categoría. Si eres suscriptor del
newsletter de SG, seguramente te llegó una
invitación por correo electrónico tanto para
participar en la definición de nominados,
como en la votación final.
En la votación intervinieron más de 1,200
personas principalmente de México, pero
también de otros países de habla hispana
como Argentina, Chile, Colombia, Perú y Uru-
guay. Resaltó que incluso las empresas pro-
veedoras hicieron promoción de la encuesta,
invitando a sus clientes a participar. Vale la
pena destacar que se utilizaron mecanismos
como captchas y filtrado de direcciones IP
para minimizar la posibilidad de abuso y te-
ner resultados justos y fidedignos.
Para cada categoría solo estamos listando
los tres primeros lugares. Si deseas ver la
lista completa de nominados para cada ca-
tegoría, puedes visitar el wiki de premios SG
en wiki.sg.com.mx
Veamos entonces los resultados ...
www.sg.com.mx
» Administración de datos
1. MySQL Enterprise Monitor
2. IBM Rational Data Architect
3. EMS SQL Management Studio
En esta categoría participaron productos
muy diversos, lo cual se refleja en los pro-
ductos ganadores: MySQL Enterprise Mo-
nitor es para monitorear el desempeño de
bases de datos durante operación, mientras
que IBM Rational Data Architect es para mo-
delar los datos de una aplicación, y SQL Ma-
nagement Studio se enfoca más en la parte
de integración y sincronización de datos.
» Ambiente de programación
(IDE)
1. Microsoft Visual Studio Professional
2. Eclipse
3. NetBeans
Esta es la categoría donde se recibieron más
votos, lo cual es de esperarse porque el IDE
es la herramienta central de cualquier desa-
rrollador. Visual Studio retuvo su cetro del
2007 en esta categoría, y Eclipse se mantuvo
en segundo lugar. La sorpresa este año fue
la popularidad que ha cobrado NetBeans.
Modelado y validación de
arquitectura
1. IBM Rational Software Architect
2. Microsoft Visual Studio Team System
Architecture Edition
3. Sparx Enterprise Architect
Conforme los sistemas de información dis-
tribuidos y las arquitecturas orientadas a
servicios se vuelven más comunes en las or-
ganizaciones, el rol de la arquitectura de sis-
temas se ha convertido en algo crucial, y por
lo tanto han surgido nuevas herramientas
para sustentar las actividades de este rol.
» ETL
1. Oracle Warehouse Builder
2. IBM Information Server
3. Business Objects Data Integrator
Las herramientas ETL se utilizan para ex-
traer información de una o más fuentes de
datos, transformarla y depositarla en otro
repositorio.
» Framework para desarrollo
Web
1. ASP .Net MVC
2. Struts
3. Spring
Llama la atención que el primer lugar lo
haya ganado una tecnología que todavía no
llega siquiera a su versión 1.0. Esto resalta la
alta necesidad de un framework de este tipo
para la plataforma .Net.
» Generador de aplicaciones
1. Genexus
2. PowerBuilder
3. Clarion
Las herramientas para generar aplicaciones
se mantienen vigentes y han evolucionado
significativamente para responder a las nece-
sidades del mercado. Definitivamente distan
mucho de los 4GLs que conocimos hace 20
años. Genexus es posiblemente el producto
de ésta categoría que ha incorporado más
capacidades en el último par de años. Vemos
que esto le ha generado dividendos en su
popularidad, incluso rebasando la de un pro-
ducto tan conocido como PowerBuilder.
FEB-ABR 2009 19
 » Gestión de la configuración
1. Subversion
2. Microsoft Team Foundation Server
3. IBM Rational ClearCase
La categoría de gestión de la configuración es bastante
amplia e involucra productos con funcionalidad muy va-
riada. Aun así, el corazón de estas herramientas es el con-
trol de versiones. Cabe notar que la votación en esta cate-
goría fue muy cerrada, con menos de 10 votos separando
al primero y tercer lugar, así que cualquiera de estos tres
productos pudo haber quedado en primer lugar.
» Gestión de requerimientos
1. IBM Rational RequisitePro
2. Microsoft Team Foundation Server
3. Borland Caliber RM
Las herramientas para gestión de requerimientos ayu-
dan a llevar el control de la asignación y estatus de los
requerimientos de un software durante su construcción.
RequisitePro se mantiene como el rey de esta categoría,
aunque TFS ya se está haciendo presente.
» Librería de componentes
1. Apache Commons
2. NetAdvantage for .Net
3. VCL – Delphi Visual Components
Es común recurrir a componentes previamente desa-
rrollados para resolver problemas como graficación de
datos, manejo de seguridad o manejo de bitácoras, en-
tre otros. Muchas personas y organizaciones recurren a
componentes desarrollados internamente, pero es bue-
no saber que hay muchas opciones allá afuera, tanto de
software libre como comercial.
» Modelado UML
1. IBM Rational Software Modeler
2. Visual Paradigm for UML
3. Sparx Enterprise Architect
En el campo de las herramientas para modelado visual
con UML, Rational Software Modeler, heredero del le-
gendario Rational Rose se mantiene a la cabeza. Visual
Paradigm es un producto que ha cobrado gran popula-
ridad en los últimos años, principalmente debido a que
ofrecer una versión gratuita.
» Gestión de pruebas
1. IBM Rational Quality Manager
2. HP Quality Center
3. Borland SilkCentral Test Manager
Este año decidimos separar las herramientas de prueba
de software en tres categorías diferentes, la primera de
ellas es la de gestión de pruebas. El enfoque de estas he-
rramientas no necesariamente es ejecutar las pruebas,
sino encargarse de llevar el control de los aspectos de
gestión tales como registro de casos de prueba, estatus
20 FEB-ABR 2009
de cobertura de pruebas, bitácora de pruebas aplicadas
a una versión/build de un producto de software, etc.
» Pruebas funcionales
1. IBM Rational Functional Tester
2. Borland SilkTest
3. HP QuickTest Professional
Como su nombre lo indica, las herramientas para prue-
bas funcionales permiten probar la funcionalidad de un
software. Típicamente proveen “robots” para pruebas
automatizadas y grabación de scripts que posteriormen-
te se puedan ejecutar n número de veces con distintos
datos de prueba. Para quienes no reconozcan a HP como
un jugador en este espacio, les recordamos que hace un
par de años HP compró a Mercury Interactive, así que la
oferta de HP en este espacio está basada en los produc-
tos que adquirió de Mercury.
» Pruebas de desempeño
1. IBM Rational Performance Tester
2. Apache JMeter
3. HP LoadRunner
Las herramientas para pruebas de desempeño sirven
para validar los atributos de calidad no funcionales de un
sistema, tales como velocidad de respuesta, utilización
de recursos, confiabilidad y escalabilidad.
» Inteligencia de negocios
1. IBM Cognos 8
2. Oracle Business Intelligence Suite
3. Microsoft Business Intelligence Suite
En esta categoría apareció una gran cantidad de provee-
dores tanto nacionales como internacionales así como
de software libre. Al final, la votación fue dominada por
los sospechosos comunes.
» Portal empresarial
1. IBM WebSphere Portal
2. Microsoft Sharepoint Server
3. Apache JetSpeed
El segmento de portales empresariales está viviendo
un momento interesante, conforme la oferta busca evo-
lucionar del ya añejo mundo del web 1.0 hacia el web
colaborativo (sí, ese que llamamos 2.0). Consideramos
que este segmento en su forma actual ya tiene fecha de
caducidad y que eventualmente será absorbido por las
plataformas de colaboración (ver siguiente categoría).
» Plataforma de colaboración
empresarial
1. Google Apps
2. Microsoft Sharepoint
3. IBM Lotus Connections
La nueva generación de portales empresariales está orien-
tada hacia la colaboración. Capacidades como wikis, mash-
www.sg.com.mx
ups, edición de documentos colaborativa, re-
des sociales intra/extra-empresa, mensajería
instantánea integrada son el común denomina-
dor. Google Apps es gratuito y por lo tanto tiene
una amplia base de usuarios. Por el otro lado,
la oferta de Microsoft e IBM es mucho más fun-
cional y robusta.
» Plataforma BPM
1. IBM WebSphere
2. JBoss jBPM
3. Oracle BPA Suite
Hace un par de años, los BPMS (Business
Process Management System) eran conside-
rados “el futuro” de los sistemas de informa-
ción. Actualmente ya no suenan tanto, pero
no por ello pierden importancia. Simplemen-
te, conforme la oferta ha ido madurando, ha
quedado más claro en qué casos un BPMS
es una buena opción y en que otros casos es
mejor buscar otro tipo de solución.
» Plataforma SOA
1. IBM WebSphere
2. Microsoft SOA
3. Apache ServiceMix
El año pasado vivimos la “fiebre de SOA”,
donde prácticamente todos los proveedo-
res de middleware aseguraban ser los non-
plus-ultra del SOA y trataban de empujar su
visión, generando mucha confusión. Afortu-
nadamente dicha fiebre va de bajada, por lo
que auguramos que conforme avance este
www.sg.com.mx
año será más fácil distinguir el ruido de la
realidad en cuanto la oferta de SOA.
» Sistema para Gestión de
Contenido (CMS)
1. Joomla
2. Lotus Web Content Management
3. Wordpress
Conforme el grueso de los sitios en el web
ahora manejan información dinámica (noti-
cias, comentarios, registro de usuarios, etc),
los sistemas para gestión de contenido se
han convertido en una herramienta esencial.
» Servidor de base de datos
1. Oracle Database
2. Microsoft SQL Server
3. MySQL
Después de los IDEs, ésta es la categoría
que más votos recibió, lo cual es de espe-
rarse ya que prácticamente todas las aplica-
ciones empresariales requieren una base de
datos. A pesar de que este es un segmento
muy maduro, todavía hay mucho espacio
para innovación, lo cual se ha visto con las
versiones más recientes de los productos de
los principales proveedores.
» Plataforma para aplicaciones
móviles
1. Sun Java Mobile Edition
2. iPhone
3. Windows Mobile
El cómputo móvil ha tenido grandes avances
en los últimos años, no sólo lo relacionado al
hardware sino también en cuanto al software.
Java ME se mantiene como la plataforma más
popular, pero vemos que el fenómeno iPhone
ya está presente entre los lectores de SG, que
lo ven como una opción muy atractiva sobre
la cual desarrollar aplicaciones.
» Respaldo y recuperación de
datos
1. IBM Tivoli Storage Manager
2. Symantec NetBackup
3. Sun StorageTek Enterprise Backup Software
Las soluciones para respaldo y recuperación de
datos es una de esas herramientas de las cua-
les no te acuerdas hasta que las necesitas, y si
no la tienes es muy doloroso. Les recomenda-
mos analizar opciones para encontrar una que
se ajuste a sus necesidades y presupuesto.
Conclusión
Con esto terminamos el listado de ga-
nadores de Premios SG. Agradecemos a
todas las personas que participaron en la
definición de nominados, así como en la
votación. Esperamos que hayan quedado
satisfechos con el resultado. El objetivo
de estos premios es que sea un ejercicio
que le sirva a ustedes, los lectores, para
conocer más categorías y productos, y así
tener más opciones a considerar en sus
próximos proyectos.
FEB-ABR 2009 21
 // perfiles
¿Alguna vez has considerado trabajar en otro país? Nuestra profesión tiene la bondad de ser global, y que en prácticamente cualquier
parte del mundo germina. Aquí te presentamos el perfil de tres desarrolladores de software mexicanos que actualmente radican en el
extranjero. Tú podrías ser uno de ellos, sólo es cosa de que lo intentes.
Miguel Madero
Miguel es desarrollador de software para
Readify Consulting, en Sydney, Australia.
Actualmente trabaja con el grupo de medios
más importante de Australia desarrollando
una aplicación en Silverlight. Anteriormente,
Miguel tenía su despacho de desarrollo de
aplicaciones basado en Torreón, Coahuila.
¿Cómo conseguiste ese trabajo?
Desde México estuve trabajando con gen-
te de diversos países en un proyecto open
source para dispositivos móviles. Una de las
personas involucradas en el proyecto era de
Australia y me puso en contacto con Readify.
A partir de esa recomendación empecé un
proceso muy corto de entrevistas para con-
tinuar con uno muy largo de trámite de visa
de trabajo. Creo que la recomendación fue
algo muy importante para agilizar el proce-
so. El estar involucrado en proyectos open
source y participar en comunidades de de-
sarrollo también ayudó mucho.
¿Qué tanto te ha servido estar allá?
Profesionalmente ha sido muy provechoso, ya
que he tenido oportunidad de trabajar en pro-
28
22 FEB-ABR 2009
yectos de gran magnitud. También he podido
conocer a gente muy talentosa, aunque esto
no es muy distinto a otras oportunidades que
existen en México. Trabajando en Torreón y en
las diferentes comunidades de desarrollo de
.NET, encontré siempre gente muy capaz.
Por otro lado, personalmente ha sido una
experiencia muy grata hasta el momento,
ya que el país ofrece de todo, en muchos
aspectos me siento aún como turista, pues
no termino de conocer y disfrutar nuevos
lugares. Algo a destacar es la diversidad de
culturas, debido a la gran cantidad de inmi-
grantes que hay. Por ejemplo, en mi actual
proyecto trabajo con personas de 10 dis-
tintas nacionalidades, sólo uno de ellos es
australiano. Esto se ve reflejado en las tradi-
ciones y especialmente en la comida.
¿Pretendes regresar a México?
A corto plazo será sólo de visita, ya que segui-
ré viviendo en Australia por lo menos otros dos
años. Para regresar a vivir a México no existe
ningún plan, el enfoque en este momento es
disfrutar esta oportunidad que tenemos.
¿Recomendarías a un colega irse a trabajar
a Australia?
Sí, definitivamente. Vivir en otro país siem-
pre te enriquece, y Australia es una gran
opción. Por un lado está el aspecto profe-
sional, económico, y la facilidad que existe
para obtener una visa de trabajo a través de
un patrocinador en el área de IT. Pero más
importante, y algo que yo no consideraba
en un principio es la diversidad cultural que
mencioné antes.
He conocido a algunas personas que vie-
nen sin una visa de trabajo, pensando
conseguir trabajo en IT una vez llegados a
Australia. Hace 20 años pudiera parecer la
única opción, pero aún estando acá, las em-
presas prefieren recibir correos por email o
a través de su website. Si la compañía está
dispuesta a contratar a alguien del extran-
jero, tendrán los procesos adecuados para
realizar todo el trámite de manera remota,
incluyendo entrevistas y evaluaciones téc-
nicas. La recomendación es muy simple: si
quieren venir a vivir acá, arreglen todo des-
de la comodidad de su casa.
A quienes les interese, les recomiendo que
visiten el blog de Toni-anne, gerente de re-
cursos humanos de Readify (mother-toni-
anne.spaces.live.com), tiene algunos posts
respecto a la vida en Australia y buenas re-
comendaciones.
¿Cuál es tu opinión sobre la industria de
software en Australia en términos de los
procesos, tecnologías y personas?
Las empresas y gente que he conocido pue-
den ser una muestra sesgada en este pun-
to, pero es mi percepción que, a diferen-
cia de México, aquí no se habla de CMMI
o procesos de madurez estructurados. En
cambio, las metodologías ágiles en espe-
cial SCRUM, son muy populares, inclusive
en grandes corporaciones. De hecho, en
Readify buena parte del trabajo que reali-
zamos es consultoría y entrenamiento para
implantación de métodos ágiles.
En el aspecto tecnológico, nos enfocamos
en .NET, sin embargo, he tenido la oportuni-
dad de participar en algunos eventos mixtos
y he podido ver que la comunidad de Java y
Ruby tiene una buena presencia en Sydney
que es sede de muchos eventos importan-
tes, como el TechEd, ReMix y JAOO. Existen
tantas comunidades de desarrollo, que aun-
que todas ofrecen algo interesante, hay que
ser muy selectivo para tener tiempo de ir a
los eventos más importantes y aún tener al-
gunas tardes libres.
En cuanto a las personas, en esta industria
tenemos un problema muy similar en Aus-
tralia y en México: es muy difícil encontrar
gente bien capacitada. Existe una brecha
muy grande entre lo que demandan las
empresas y lo que entregan las universi-
dades. La ventaja que existe aquí es que
fácilmente se puede contratar a gente de
otros países, y no necesariamente India o
México, sino también de países como Fran-
cia o Estados Unidos.
www.sg.com.mx
 Rodrigo García
Rodrigo es COO de Softtek China y Director del GDC (Centro de Desarrollo Global)
de Beijing. En enero de 2000 inició su carrera en Softtek dentro del área de desarro-
llo web, en 2005 fue nombrado Gerente de Producto de la oferta de desarrollo de
aplicaciones y en 2007 inició su aventura en China.
¿En qué consiste tu trabajo actual?
Mi trabajo consiste en asegurar que todos
los proyectos que se elaboran tanto para
el mercado doméstico como en el GDC se
entreguen en tiempo, calidad y presupues-
to. Actualmente trabajamos con clientes de
China, Asia, Europa y América.
¿Por qué aceptaste ir a China?
El mercado de servicios en China está cre-
ciendo a pasos agigantados. En agosto de
2007 Softtek compró una empresa aquí y
me preguntaron si quería reubicarme para
ayudar con la integración de procesos y el
arranque de las operaciones en esta región,
inmediatamente dije que sí. Anteriormente
había visitado China durante unas vacacio-
nes y me gustó mucho Beijing. Es una ciu-
dad totalmente cosmopolita, donde encuen-
tras todo tipo de personas, eventos, cultura,
comida y productos.
¿Trabajan localmente o envían trabajo para
México? ¿Cómo funciona su operación?
Las operaciones de China están divididas en
dos grupos, la local y la de Global Nearsho-
re. La operación local da servicio a empresas
dentro de China. Para esto tenemos oficinas
en Beijing, Shangai, Xian y Xiamen ofrecien-
do servicios de desarrollo, mantenimiento
y soporte de aplicaciones. Por otro lado, la
operación de Global Nearshore es la que
provee servicios a nuestros clientes que se
encuentran fuera de China: en Asia, Europa
y América. Para esto, contamos con turnos
de trabajo dinámicos que permite tener una
ventana de interacción con los equipos de
México, España, Estados Unidos y clientes.
De esta forma damos atención las 24 horas
sin tener gente trabajando durante las no-
ches y madrugadas.
www.sg.com.mx
¿La mayoría de los empleados del centro de
desarrollo de Softtek en China son chinos,
mexicanos, o cómo está la mezcla?
Aunque la mayoría de los empleados son
chinos (más del 95%), en la oficina trabajan
personas de Suiza, Australia, Canadá, Reino
Unido y México. Pero todos nos comunica-
mos a través del idioma oficial de la empre-
sa que es el inglés.
¿Cuál es tu opinión sobre la industria de
software en China en términos de procesos,
tecnología y personas?
China espera ser la economía número uno del
mundo para 2025, y requiere una industria
de servicios de TI que soporte esto. Este seg-
mento ha tenido un boom impresionante, y la
demanda por talento ha sido superada por la
oferta. El gobierno central tiene una visión a
largo plazo y comenzó a promover las carre-
ras de TI hace varios años. Según el ministro
de educación, en 2007 China capacitó entre
350 y 400 mil personas en diversas áreas de
TI, mientras que India sólo 200 mil y Estados
Unidos 75 mil. Actualmente, la demanda si-
gue siendo mucho mayor a la oferta, y estos
egresados no son suficientes.
Las empresas chinas comienzan a entender
el valor que le da al servicio el contar con
una certificación ISO, CMMI, ITIL, etcétera.
Desgraciadamente el mercado aún no está
tan maduro para pagar por ellas. La mayor
parte de las empresas buscan staffing den-
tro de sus oficinas, y no están muy interesa-
das en niveles de servicio y métricas, bus-
can el proveedor que les de el mejor precio
por el mejor currículo.
En cuanto a tecnología se refiere, una gran
parte de R&D se hace en diversas empresas.
Muchas de ellas, Microsoft y Cisco son un
caso, tienen fuertes inversiones en centros
cautivos de ingeniería, lo que hace que aho-
ra China no solamente se perciba como un
mercado de manufactura y reproducción de
tecnología, sino que también de innovación
y creatividad. Sólo basta mencionar que en
septiembre de 2008, China logró su primera
caminata espacial con el Shenzhou 7, sien-
do así la tercera nación en lograrlo después
de Rusia y Estados Unidos.
¿Cómo te ha servido estar allá?
La experiencia de trabajar con una cultura que
es tan diferente en algunas cosas y tan simi-
lar en otras es algo invaluable. Como persona
te abre los ojos, te ayuda a entender mejor el
porqué otras culturas y sociedades se desa-
rrollan y comportan de una manera, y otras
de una forma totalmente opuesta. Entiendes
que ambas están haciendo lo correcto desde
su perspectiva de cómo miran al mundo.
¿Le recomiendas a los lectores de SG buscar
oportunidades en China?
Absolutamente, sí. Mi recomendación es
que se decidan a venir. Muchas de las per-
sonas extranjeras que conozco llegaron a
China como maestros de inglés y otros como
maestros de español. Hay empresas Chinas
que están buscando personas de otras na-
cionalidades que quieran venir a intercam-
biar procesos, formas de trabajo y conoci-
miento con la gente de China.
Inmigrar a China no es tan complejo como ir
a otros países, pero sí se necesita llegar con
la mente abierta y entender que lo que para
nosotros está mal aquí no necesariamente
es malo y viceversa. No por ser extranjero lo
van a tratar a uno diferente.
FEB-ABR 2009 23
 // perfiles

Arie Grapa
Arie Grapa es gerente de ingeniería en el corporativo de Yahoo! en
Silicon Valley. Después de cerrar su empresa de ISP en México a fi-
nales de los 90 cuando las telefónicas ingresaron a este mercado,
Arie logró matricularse a un posgrado en la universidad de Stanford,
y posteriormente fue reclutado por Yahoo!

¿En qué consiste tu trabajo actual?
Actualmente soy responsable de dirigir
un grupo de ingenieros que producen un
software llamando “APT Demand UI”. Es
el frente para los ad-networks que quieren
comprar anuncios en Apex, nuestro nuevo
sistema de intercambio de anuncios. Fun-
ciona como una gran red de bolsas de valo-
res donde la gente puede comprar y vender
anuncios en Internet. Anteriormente dirigía
el equipo de ingenieros a cargo del sitio
Yahoo! Personals.
¿Cómo se maneja el ciclo de desarrollo en
una empresa como Yahoo!?
Nuestro trabajo es como parte de la línea
de producción de una fábrica de software:
primero se hace la investigación de mer-
cado, luego se diseña el PRD (Product
Requirements Document), luego UED (User
Experience Design) y Visde (diseño visual),
posteriormente el diseño técnico y desarro-
llo del software, el debugging, lanzamiento
y por último la medición de los resultados.
¿Qué se necesita hacer para que más
empresas de tecnología (como Yahoo!)
establezcan centros de ingeniería en
países como México?
Es una pregunta difícil, ya que el grueso
de los proyectos se realiza en Estados Uni-
dos, y muchos están de camino a China e
India. A ambos se les conoce como países
con muy buenas escuelas que producen
buenos ingenieros, y los salarios son más
accesibles que en Estados Unidos. Yahoo!
por mucho tiempo ha mantenido oficinas
en México, y en varias visitas he conoci-
do a excelentes ingenieros que trabajan
allí. En la mayoría de los casos su trabajo
consiste en personalizar y lanzar produc-
tos para el mercado de habla hispana.
No tengo una fórmula para que las empre-
sas de tecnología establezcan oficinas en
México, pero sé que en otros lugares, los
gobiernos han dado incentivos financieros,
en muchos casos con promesas de des-
cuentos en impuestos o en rentas de in-
muebles. En otros lugares han construido
grandes parques tecnológicos con infraes-
tructura preestablecida y legislación espe-
cial que favorece este tipo de compañías
(www.dubaiinternetcity.com).
¿Crees que deberíamos fomentar que este
tipo de empresas se establezcan en México
o que sería mejor apoyar la creación/desa-
rrollo de empresas locales de tecnología?
Creo que debemos tratar por ambos cami-
nos, crecer la capacidad de desarrollo de
software del país y nuestra participación en
esta importante industria. Otra sugerencia
es que para proyectos de gobierno o para
estatales se le diera preferencia a software
de desarrollo nacional, siempre y cuando
cumpliese con los requisitos del proyecto.
¿Cómo comparas el recurso humano de
México con el de otros países?
En México se producen muy buenos ingenie-
ros, y creo que en habilidades no hay dife-
rencia con los que vienen de otros países.
Sin embargo, en países como India y China
hay mucho mayor población, y por lo tanto
mucho más ingenieros.
Por otro lado, las escuelas en estos países
son más formativas, como es el caso del IIT
(ver en.wikipedia.org/wiki/Indian_Insti-
tutes_of_Technology). Un amigo mexicano
que trabajaba en Cisco me decía que en la
carrera le enseñaron a utilizar y configurar
ruteadores, es decir a ser un “usuario” del
ruteador. Creo que esto es natural ya que
para muchos ingenieros en lugares donde
hay poco R&D, ésta es la información que
van a necesitar durante su vida profesional.
En comparación, en escuelas en Estados
Unidos, India y China enseñan la teoría de
cómo deben funcionar y diseñarse dichos
ruteadores, para que puedan crearlos o me-
jorarlos. Estoy seguro de que hay muchas
excepciones, pero en general creo que en
estos países se hace más énfasis en la for-
mación “ingenieril”.
¿Has encontrado que personas de distintos
países tiendan a tener mayor aptitud para
uno u otro tipo de trabajo?
Yo creo que todos nacemos con ciertas habi-
lidades mentales que se nos facilitan y otras
que se nos dificultan. La educación que recibi-
mos y la práctica nos ayudan a reforzarlas y ser
mejores en ellas. Al igual que con los múscu-
los, las partes del cerebro que no se usan, se
debilitan, y las que sí se usan se fortalecen.
No creo en las aptitudes por país de origen
o por región. Creo que lo que tiene mayor
impacto en las aptitudes es la educación.

24 FEB-ABR 2009 www.sg.com.mx

www.sg.com.mx FEB-ABR 2009 25
 Los Retos de la
Inteligencia de Negocios
Por Héctor Franco Beltrán

M ucho se habla de Inteligencia de Negocios como algo novedoso que involucra

a las organizaciones a través de tecnologías de vanguardia. A lo largo de los años se
ha acuñado una gran cantidad de términos tales como Executive Information Sys-
tems (EIS), Decision Support Systems (DSS), Corporate Performance Management
(CPM), Bi-Predictive Analytics, BI 2.0, etc.; en fin, existen múltiples autores, ana-
listas, proveedores y organizaciones que definen qué es y qué no es, lo que yo prefiero
llamar simplemente: “Inteligencia de Negocios”.

En realidad, los Sistemas de Inteligencia de Negocios no existen como tal. Lo que

existen son arquitecturas de inteligencia de negocios que integran múltiples
componentes tanto técnicos como humanos, que interactúan entre sí.

26 FEB-ABR 2009 www.sg.com.mx

Para ahondar en el tema, lo primero que su-
giero es hacer una diferenciación entre los
términos “inteligencia” y “negocios” e ir a
sus bases, obviamente intentando no vol-
verse loco en el intento.
Tan solo la inteligencia tiene múltiples con-
notaciones que van desde lo semántico
hasta lo divino. Para fines de este artículo
aceptemos que: “la inteligencia es la capa-
cidad evolutiva por la cual el individuo es
capaz de tomar decisiones dependiendo de
su entorno, y mejorar sus condiciones de
supervivencia, como individuo, como gru-
po o como especie”.
En el tema de los negocios también encon-
tramos un sinfín de paradojas, pero me pa-
rece correcto retomar lo que la Wikipedia
dice al respecto:“el término negocio deriva
de las palabras latinas nec y otium, es decir,
lo que no es ocio. Para los romanos otium
era lo que se hacía en el tiempo libre, sin
ninguna recompensa; entonces negocio
para ellos era lo que se hacía por dinero. Es
una ocupación lucrativa que cuando tiene
un cierto volumen, estabilidad y organiza-
ción se llama empresa. También es la conse-
cuencia de la correcta administración de los
recursos con un resultado económicamente
positivo para las partes; es importante se-
ñalar que no solamente puede ser dinero,
sino relaciones de poder”.
Lo que une los dos conceptos como “Inte-
ligencia de Negocios” y le da sentido es la
estrategia, la táctica y la operación de las
organizaciones como herramienta de super-
vivencia. En otras palabras, como decía Lee
A. Iacocca: “Ventaja competitiva es tener 1%
más información con un día de anticipación
y saber qué hacer con ella…”
Aplicaciones de la inteligencia
de negocios
La inteligencia de negocios es un área de co-
nocimiento que nos brinda una gran oportu-
nidad de crecimiento personal y profesional,
no solo en nuestros ámbitos empresariales
sino como nación.
El Ing. Héctor Franco Beltrán, PMP, es socio consultor de Grupo Frabel-Business Intelligence, así como Vicepresidente del Business
Intelligence Institute, y Coordinador del Diplomado en Business Intelligence del ITAM. Cuenta con más de 18 años de experiencia, y sus áreas
de especialidad son data warehouse y business intelligence. Ha publicado artículos y dictado conferencias para SG, ComputerWorld, IDC, ITAM,
ExpoComm, y Conacyt, entre otros. hfranco@tbii.org.mx www.tbii.org.mx
www.sg.com.mx
Es tan amplio el espectro técnico, funcional,
operativo, táctico y estratégico de las disci-
plinas derivadas, que sería imposible entrar
en detalle en cada una de ellas en un solo
artículo, ya que existen metodologías, ha-
bilidades y herramientas específicas para
cada componente. Algunas disciplinas o
aplicaciones, por citar algunas son:
• Definición de Estrategia / Planeación
Dinámica.
• Data Governance & Compliance (SOX,
Basilea II, etcétera).
• Medición y Mejora del Desempeño Cor-
porativo (CPM).
• Análisis y Diseño Dimensional (OLAP).
• Enterprise Content Management (datos
estructurados y no estructurados ).
• Sistemas de Información Geográfica (GIS).
• Balanced Scorecard / Performance
Dashboards.
• Costeo Basado en Actividades (ABC-ABM).
• Análisis Predictivo / Minería de Datos.
• Reconocimiento de Patrones / Detección
de Fraudes.
Claves para un BI efectivo
Lograr instrumentar una iniciativa de inteli-
gencia de negocios requiere de disciplina,
dedicación y una labor de equipo… realmente
actuar como equipo, ya que es tan importante
el responsable de la construcción del sistema
para el VP de finanzas, como el responsable
de limpiar o integrar los datos que éste visua-
lizará para la toma de decisiones. Tan impor-
tante es el portero de un equipo de fútbol,
como el delantero y el director técnico, ¿no?
He aquí algunas recomendaciones generales:
Estrategia: Dominar las estrategias como
si fuera una guerra
• Hoy más que nunca, la estrategia se
vuelve una pasión que cambia de mane-
ra paranoica y desenfrenada. Las organi-
zaciones deben estar seguras de quiénes
son y hacia dónde van.
• Estar conscientes que, a diferencia de los
grandes estrategas, ahora tenemos más
información, más rápido, pero no sabemos
qué hacer con ella.
• Leer el silencio… más que escuchar las pa-
labras… sobre todo de nuestros competido-
res y nuestros clientes.
• La mejor estrategia inicia por la doctrina:
“educación y capacitación de tus guerreros
en la era del conocimiento”.
Información: Entender su valor real y
salvaguardarla
• Entender el valor de los datos, su limpieza
y sus implicaciones en los metadatos (datos
acerca de los datos).
• Entender los efectos de la web 2.0, la nube
y su impacto en la inteligencia de negocios.
• Salvaguardar la información en contextos
seguros, proteger contra ataques, infiltra-
ciones, rotación de personal. Usar técnicas
de Project Management para proyectos
confidenciales, tales como el DoD PMBoK
basado en prácticas del Departamento de
Defensa de Estados Unidos de América.
Integración: El reto y los premios
• Lidiar con la integración de datos, infor-
mación no estructurada, plataformas he-
terogéneas.
• Enfoque en reducir costos, mejorar proce-
sos, incrementar beneficios, predecir analí-
ticamente, mejorar campañas, conocer a los
clientes, evaluar el desempeño.
• Empezar pequeño, generar resultados de
alto impacto y crecer rápido.
Disciplina, experiencia y conocimiento
• Ser conscientes que la tecnología sólo
representa uno de los múltiples compo-
nentes de la solución y que los puntos de
falla más frecuentes radican en factores
metodológicos y humanos.
• El rol de la innovación como apuesta
estratégica en tiempos de recesión. En el
caso de México, el Decreto de Austeridad
Gubernamental puede ser la gran oportu-
nidad de mostrar las bondades de la inteli-
gencia de negocios en el sector Gobierno.
• Es inteligente utilizar y optimizar lo
que ya se tiene para inteligencia de ne-
gocios. ¡He visto milagros en hojas de
cálculo y desastres en plataformas de
millones de dólares!
FEB-ABR 2009 27
 Minería de Datos
Descubriendo y Describiendo Patrones de Datos
Por Dafne Rosso

Actualmente y desde hace un par de décadas, la cantidad de información que se genera en los medios comerciales, educativos
y en general en cualquier sector, se ha incrementado notoriamente. Lo que ha provocado el desarrollo de varias tecnologías
enfocadas a aprovechar los datos que se encuentran escondidos en estos grandes volúmenes de información. Algunas de estas
tecnologías son por ejemplo los OLAP, Data Warehouse y la Inteligencia de Negocio (Fig. 1), éstas han aportado una conside-
rable mejora en el tratamiento de los datos estructurados y en la mejora de la toma de decisiones. Las bases de datos relaciona-
les (BDR), Data Warehouse (DW), Data Mart (DM), OLAP y OLTP son tecnologías que permiten obtener conclusiones en
base a consultas predeterminadas, es decir, son consultas deductivas, realizadas de manera óptima en tiempos cortos y enormes
volúmenes de información, conclusiones que serían imposibles de obtener en un proceso manual.

28 FEB-ABR 2009 www.sg.com.mx


BI
MINERÍA
OLAP / OLTP
Data Warehouse / Data Marts
BDR
Fig. 1 Tecnologías para el tratamiento de información.
Minería de datos
Minería de datos es un concepto que in-
volucra la obtención de conocimiento en
forma práctica, no en el sentido teórico. El
punto de interés principal, es el de descu-
brir y describir patrones encontrados en los
datos. Pretende resolver problemas o pro-
nosticar nuevos datos a partir de los datos
ya presentes que se encuentren en el Data
Warehouse corporativo. Por ejemplo: per-
miten pronosticar la lealtad de un cliente en
función de los patrones encontrados en su
comportamiento, otro tipo de aplicaciones
se encuentran en la predicción de fraudes,
fallas de maquinarias, y múltiples aplicacio-
nes orientadas al servicio.
Cómo detectar y orientar las
BI
MINERÍA
OLAP / OLTP
Data Warehouse / Data Marts
BDR
Fig. 2 Aportación de las tecnologías en el tratamiento de información.
www.sg.com.mx
Para las organizaciones es de vital importancia hacer un
uso eficaz de la información generada en sus procesos,
por medio de esquemas de Inteligencia de Negocios.
Know How
Buscar relaciones ocultas
(conocimiento)
Análisis del pasado
Histórica
OLAP Data Warehouse /
Transaccional / Operacional Data Marts
Preparación
de Datos
Las técnicas de minería de datos al día de
hoy se encuentran plenamente desarro-
lladas, y para algunos tipos de análisis se
encuentran en fase de maduración. Los
métodos de minería de datos operan so-
bre datos altamente estructurados (Fig. 3), Minería
que se encuentran en repositorios como
Data Warehouse o Data Marts, o bien son
resultado de aplicar en ellos algún análisis Figura 3. Minería de datos
OLAP. Para efectuar la minería es necesa-
rio que se realice previamente una prepa- El proceso de descubrimiento de patrones
ración sobre los datos, que les provea de puede ser automático o semiautomático,
la estructura necesaria para la técnica de los patrones identificados deben ser signifi-
minería a emplear. cativos y aportar alguna ventaja, usualmen-
te de tipo económico.
Aplicación de la minería
de datos
tendencias del mercado
Las técnicas empleadas en la minería de da-
tos dependen del tipo de conocimiento que
Cuál podrá ser el comportamiento
de la zona sur este año se desee obtener. Existen dos clasificaciones
que agrupan los algoritmos de minería, estas
Cuál fue el total de ventas
mensual de los últimos 5 años
son: minería dirigida y no dirigida. Para el pri-
con un detalle por estado mer caso se conoce el tipo de decisión (cla-
y punto de venta
se) al que se desea llegar, como por ejemplo:
booleano (si /no), tipo, acción.
Cuál fué el total de ventas
mensual de los últimos 5 años
Las entradas son de tipo numérico o bien de
tipo nominal. Los datos numéricos presen-
tan valores talesvv que las comparaciones
en rangos tengan sentido, mientras que los
FEB-ABR 2009 29
 datos nominales tienen un significado específico. El dato nominal más común es algo El dato que se pretende pronosticar es la
que puede ser clasificado como cierto o falso. marca. Es decir, si se presenta un nuevo in-
dividuo a comprar un vehículo, ¿cuál es la
A continuación vamos a realizar un ejemplo de minería dirigida con una muestra de da- marca que podría escoger?
tos referentes a las preferencias de compra de automóviles. La muestra fue recabada
dentro de una población reducida de clase media, cuyo centro de trabajo se encuentra Realicemos la minería paso a paso, con un
en la zona centro de la ciudad. Los tipos de datos son nominales. pequeño subconjunto de los datos anterio-
res, el método que emplearemos se conoce
La siguiente figura presenta un extracto del conjunto de datos nominales, previamente como ID3, éste es una estrategia que divide
procesados para realizar la minería. y conquista, que opera tratando de maxi-
mizar el nivel de ganancia en cada paso.
La siguiente tabla contiene el cálculo de la
Edad Sexo Delegación Marca Tipo Motivo entropía para el atributo edad, se realiza
el cálculo de la entropía de cada atributo,
41-50 F Azcapotzalco Ford Sedán Marca la cuál es una medida de la incertidumbre
21-30 M Azcapotzalco Mazda Deportivo Gusto
51-60 M Azcapotzalco Pontiac Sedán Precio existente en el conjunto de atributos, de los
41-50 F Gustavo A. Madero Chrysler Sedán Gusto cuales se escoge sólo aquel atributo con
31-40 F Tlalnepantla Chevrolet Sedán Precio mayor ganancia (diferencia entre la entro-
31-41 M Tlalnepantla Chevrolet Camioneta Precio
21-30 M C. Izcalli Chevrolet Sedán Precio
pía del sistema y la entropía del atributo). El
41-50 F Gustavo A. Madero Toyota Camioneta Gusto atributo seleccionado es el nodo del árbol.
41-50 F Gustavo A. Madero Ford Camioneta Tamaño Este cálculo se repite desde la selección de
41-50 F Naucalpan Ford Camioneta Tamaño
41-50 M Naucalpan Mazda Camioneta Gusto
la raíz y para cada nivel del árbol.
51-60 F Naucalpan Toyota Sedán Servicios
41-50 F Naucalpan Toyota Sedán Precio Calculando las entropías de cada atributo
31-40 F Benito Juárez Toyota Sedán Gusto para el primer nivel del árbol tenemos:
31-40 M Benito Juárez Chevrolet Camioneta Marca
51-60 M Atizapán Honda Camioneta Gusto
51-60 F Atizapán Chrysler Sedán Precio Atributo Ganancia
21-30 M Atizapán Susuki Compacto Precio
21-30 F Atizapán Pontiac Sedán Gusto
51-60 M Atizapán Pontiac Sedán Gusto Edad 1.29989551
51-60 M Álvaro Obregón Nissan Deportivo Gusto Sexo .65923654
21-30 F Atizapán Seat Sedán Precio Delegación 1.7532697
21-30 M Atizapán Pontiac Sedán Gusto
51-60 F Atizapán Honda Camioneta Tamaño
Tipo 1.1328787

Figura 6. Preferencias en compra de automóviles.

Esto nos da el primer nodo de nuestro árbol,
el nodo seleccionado es aquel que presen-
ta la mayor ganancia. El proceso continúa
Edad Elementos Chev Chry Ford Honda Mazda Mercedes Nissan Pontiac Seat Susuki Toyota
hasta explorar nuevamente los atributos
21-30 6 1 0 0 0 1 0 0 2 1 1 0
31-40 4 3 0 0 0 0 0 0 0 0 0 1
restantes y obtener los nodos del árbol de
41-50 7 0 1 3 0 1 0 0 0 0 0 1 los niveles inferiores.
51-60 8 0 1 0 2 0 1 1 2 0 0 1
25 4 2 3 2 2 1 1 4 1 1 4 En el mercado existen varias herramientas
Razon de ocurrencias
21-30 6 0.16 0 0 0 0.16 0 0 0.33 0.16 0.16 0 comerciales que realizan el minado de da-
31-40 4 0.75 0 0 0 0 0 0 0 0 0 0.25 tos. Éstas desarrollan técnicas de aprendi-
41-50 7 0 0.14 0.42 0 0.14 0 0 0 0 0 0.14 zaje automatizado y permiten aplicarlas a
51-60 8 0 0.12 0 0.25 0 0.12 0.12 0.25 0 0 0.12
25 0.16 0.08 0.12 0.08 0.08 0.04 0.04 0.16 0.04 0.04 0.16 problemas reales de minería de datos. Tam-
Logaritmo de la razon de ocurrencias bién se encuentran disponibles en el web
21-30 6 -2.58 -2.58 -1.58 -2.58 -2.58 algunas herramientas como Weka y See5,
31-40 4 -0.41 -2
41-50 7 -2.8 -1.22 -2.8 -2.8
ambas contienen diversos algoritmos de
51-60 8 -3 -2 -3 -3 -2 -3 clasificación y asociación.
25 -2.64 -3.64 -3.05 -3.64 -3.64 -4.64 -4.64 -2.64 -4.64 -4.64 -2.64
Entropia
21-30 6 2.25 0.54
La siguiente figura presenta una fracción del
31-40 4 0.81 0.12 árbol de decisión, obtenido de efectuar la mi-
41-50 7 1.72 0.48 nería en el conjunto de datos seleccionados.
51-60 8 2.5 0.8
En el árbol podemos observar que la dele-
25 3.253 Entropia sistema
1.953 Entropia edad gación es el principal atributo que intervie-
1.299 Ganancia ne en la selección de una marca particular
de vehículo, en el caso de las delegaciones,
Tabla 1. Cálculo de entropía primer nivel. en particular los casos de Azcapotzalco y

32
30 FEB-ABR 2009 www.sg.com.mx
 %FMFHBDJwO

Azcapotzalco Gustavo A. Madero Tlalnepantla Naucalpan otros. En general, el proceso de toma de de-
.PUJWP .PUJWP cisiones mejora de manera significativa.
&EBE &EBE 31-40
Servicios
Precio Marca Gusto Precio Tamaño
41-50
5JQP 4FYP &EBE
Las aportaciones que este tipo de tecnología
F
puede hacer en las empresas, son encau-
Sedán Camioneta

.PUJWP Tamaño M
sadas a mantener el nivel competitivo de la
41-50 51-60 21-30 41-50 31-40

Gusto Tamaño
empresa, los beneficios de la minería como
GPSE NB[EB la capacidad de identificar patrones, compor-
DISZTMFS UPZPUB GPSE OJTTBO EPEHF
QPOUJBD
$IFWSPMFU WX NB[EB UPZPUB IPOEB GPSE tamientos, reglas y relaciones en los datos,
permiten realizar previsiones y encontrar
Figura 4. Ejemplo de un árbol de decisión resultante de la minería. nuevas soluciones o rutas de acción.

Gustavo A. Madero, se observa que el siguien- minado descubre esta relación. El analista de Para obtener el valor máximo de las técnicas
te factor determinante es la edad de la perso- datos debe ahora interpretarla. Por ejemplo, de minería en las soluciones de inteligencia de
na, sin embargo, en Naulcalpan se observa es posible que la variable delegación esté ac- negocio, es necesario contar con tecnología
que se tienen motivos particulares que mar- tuando como un indicador del estilo de vida de que pueda llevar a cabo el proceso en tiempos
can la preferencia en la selección del auto, las personas, lo que definitivamente influiría satisfactorios al negocio y pueda permitir a los
por ejemplo: la gente prefiere Toyota si se en la elección del auto a comprar. Esta inter- tomadores de decisiones, en cada nivel de su
guían por los costos y calidad de los servicios. pretación parece apoyada por el hecho de que organización, analizar la información y actuar
Por supuesto mientras más grande y variado las personas más jóvenes prefieran autos de con base a los resultados obtenidos.
sea el conjunto de datos seleccionados, el re- línea más deportiva.
sultado será más aproximado a la realidad. Referencias
Minería de datos en la empresa [ Sholom Weiss, Nitin Indurkhya,Tong
La minería de datos en este ejemplo nos per- Las técnicas de minería de datos, pueden Zhang & Fred J. Damerau. Text Mining.
mitió obtener conclusiones que, a simple vis- ser implementadas en las empresas para Springer, 2005 ]
ta no son aparentes: uno no esperaría que la el descubrimiento de información, apor- [ Ian H. Witten, Eibe Frank. Data Mining:
delegación fuera un factor determinante en la tando valor a los procesos de negocio, por Practical Machine Learning Tools and
selección de un vehículo, esperando que cues- ejemplo, incrementando niveles de venta, Techniques. Second Edition ]
tiones como el precio o los servicios fueran aumentando la diversificación de mercado,
más significativos. Sin embargo, el proceso de y mejorando la satisfacción del cliente, entre

Dafne Rosso ha participado desde 1998 en iniciativas orientadas a la implementación de soluciones basadas en inteligencia de negocio. Actual-
mente cursa el Doctorado en Ciencias Computacionales en el área de Sistemas Inteligentes, que se imparte en ITESM. Cuenta con una maestría
en Ciencias Computacionales del ITESM y una maestría en Tecnologías de Información y Administración del ITAM, así como numerosos cursos de
especialización en tecnología de punta.

www.sg.com.mx FEB-ABR 2009 33

31
 ¿Cómo Surge la Necesidad
de Utilizar BI en las PyMEs?
Explotar los Beneficios de BI
Trabajando en un entorno cada vez más com-
petitivo, las PyMEs ya no sólo interactúan de
forma local, incluso se han aventurado en nue-
vas oportunidades de competencia en áreas
antes totalmente desconocidas. Para lo cual se
necesita explotar los indicadores de gestión,
que se encargan de revisar datos procesados
(históricos) para convertirlos en decisiones ba-
sadas en información clave (presente).
Un sistema de monitoreo basado en indicado-
res de gestión, implica la capacidad de proce-
sar en tiempo real y a una gran velocidad, can-
tidades importantes de datos provenientes de
diferentes fuentes y en diversos formatos para
generar información precisa sobre las áreas
clave de éxito de la empresa. La aplicación de
herramientas BI facilita el flujo de la informa-
ción, reduce el costo de hacer negocios y se
convertirá en una nueva fuente de ingresos.
Sin embargo, las soluciones de TI imple-
mentadas en la mayoría de las PyMEs, co-
rresponden a sistemas transaccionales, en
algunos casos se puede contar con ERP que
soportan procesos administrativos, de ven-
32 FEB-ABR 2009
tas y producción, y que generan reportes de
las operaciones. Pero estas soluciones no
se enfocan en los indicadores de gestión, lo
que provoca que se inviertan días o meses
de análisis de información para tomar deci-
siones de forma inoportuna o incorrecta.
Dificultades detectadas en la
explotación de herramientas BI
en las PyMEs
Mauro González, Director de Inteligencia de
Negocios de AC Group Assembler Consul-
tants, indicó que BI son potentes sistemas
implementados en las empresas más exito-
sas en el mundo, que resultan a veces, in-
accesibles para muchas PyMEs por razones
económicas o de infraestructura.
Dentro de las dificultades en la elección
de herramientas BI, se encuentran que los
usuarios que ya han trabajado con herra-
mientas BI anteriormente, se inclinan por
las que ya conocen o se guían por recomen-
daciones como las que se pudieran tomar de
artículos como los publicados por Gartner;
Por Ma. Ernestina Ortíz
en lugar de evaluar los beneficios y costos
de las mismas, así como los requerimientos
específicos del negocio.
Las dificultades que existen en la explota-
ción adecuada de las herramientas de BI ya
implementadas son:
• Uso nulo o escaso por parte de los usua-
rios, ya sea por dificultad en su uso, por fal-
ta de información requerida, porque no es
confiable o porque al usuario no le gusta.
• Se utiliza únicamente para extraer informa-
ción aunque el análisis se haga manualmente.
• Se utiliza únicamente como generadora de re-
portes y no se aprovechan todos sus beneficios.
• Se adquirió sólo prestigio, no por una
justificación válida de una necesidad de
información.
• Poca adaptabilidad de usuarios que ya
han trabajado con herramientas similares.
• Dar por hecho que todos los usuarios tie-
nen el conocimiento o el tiempo para usar
estas herramientas.
www.sg.com.mx
• Si la herramienta BI está basada en hojas de
cálculo, se corre el riesgo de perder calidad y
consistencia en la información, ya que la fuente
de datos puede ser modificada manualmente.
Consideraciones en la
adquisición de BI
Para adquirir una solución BI se debe:
• Identificar los beneficios que la informa-
ción generará, como acelerar un proceso,
reducir costos o mejorar la productividad en
un área en particular. No se debe enfocar en
un objetivo general.
• Identificar el método de integración de in-
formación más oportuno y menos costoso.
• Incluir a los usuarios del negocio en la
decisión para asegurarse que ésta será
aceptada.
• Realizar un ROI con claridad definido,
donde se identifiquen las necesidades del
negocio abiertamente.
• Debe ser una herramienta capaz de favo-
recer la comunicación e interacción de las
distintas entidades funcionales, para que la
información generada fluya a todos los estra-
tos donde se requiera tomar decisiones de
forma perfectamente coordinada y en base a
una sola fuente consolidada de información.
• La elección adecuada de la herramienta
BI debe considerar comparaciones entre la
plataforma, alcance, funcionalidad, tecno-
logía y arquitectura de cada opción, lo que
definirá criterios técnicos y funcionales
para su adquisición.
Ma. Ernestina Ortíz García es Licenciada en Sistemas Computacionales Administrativos en la Universidad Veracruzana, Maestría en Administra-
ción de Tecnologías de Información por parte de la Universidad Virtual del ITESM. Actualmente es Jefe del Departamento de Sistemas de la Univer-
sidad del Golfo de México, Rectoría Norte. Se interesa en lo que tiene que ver con la aplicación de la tecnología en soluciones al trabajo cotidiano,
o como propuesta de mejora o innovación de procesos.
www.sg.com.mx
Alternativas de BI para PyMEs
Para poder explotar los beneficios de la in-
teligencia de negocios en las PyMEs, la al-
ternativa más común es recurrir a las hojas
de cálculo, que tienen una amplia capacidad
de gestión empresarial. En esta aplicación
se pueden importar datos desde otros siste-
mas de información (minería de datos) y mo-
nitorear los cambios en tiempo real a partir
de las gráficas, con la misma efectividad que
herramientas propias de BI.
Esta alternativa se hace accesible porque
no requiere adquisiciones adicionales como
licencias o mayor infraestructura. Dentro de
algunas soluciones propias de BI, ofrecidas
en el mercado se encuentran:
• Microstrategy Solutions for Microsoft
Excel de Microstrategy.
• Cognos TM1 Midmarket Edition de Cognos
• Productos de Hyperion: Hyperion Strategic
Finance, Hyperion Capital, Expense Planning,
Hyperion Workforce Planning, etcétera.
• Solutions for Mid Size Companies de
Information Builders.
• SAS Desktop Data Mining for Midsize Bu-
siness y SAS Business Intelligence for Small
to Midsize Business de SAS.
Conclusión
En el mundo globalizado en el que se desem-
peña la PYME, donde la competencia es fuerte
y la posibilidad de subsistencia depende de
las decisiones que se tomen por los ejecuti-
vos, se requiere de herramientas que permi-
tan procesar las grandes cantidades de infor-
mación de manera eficiente, para conducir la
adecuada toma de decisiones. Las actividades
empresariales se desarrollan diariamente, lo
que requiere de un concienzudo análisis que
derivará en la elección e implementación de
sistemas adecuados de soporte a la decisión,
como lo es la inteligencia de negocios.
Esta tarea no es sencilla, y en ocasiones re-
quiere de grandes proyectos de reingeniería
para alinear los distintos procesos del nego-
cio. El error de automatizar o incorporar sis-
temas en PyMEs donde aún no se han esta-
blecido claras directrices del negocio, podría
estar condenándolas al fracaso. En cambio, si
se realiza un análisis minucioso de las capa-
cidades de la empresa, sus necesidades, el
presupuesto disponible y los beneficios de la
herramienta, la implementación de una he-
rramienta de BI llegará a ser exitosa.
Referencias
[ Colón S. “Aplique la Inteligencia de Nego-
cios en su Empresa”, El Economista. 28 de
febrero de 2008 ]
[ topmanagement.com.mx ]
[ Rodríguez M.; Sarmiento M. “Monitoreo
competitivo del entorno tecnológico:
Importancia de la aplicación de sistemas
inteligentes”. Revista Transferencia.
Octubre 2002 ]
[ Turban, E.;Aronson, J.; Liang, T.
“Implementing MSS in the E-Business
Era. Decision Support Systems and
Intelligent Systems”. Prentice Hall 2005 ]
FEB-ABR 2009 33
 Business Intelligence y
Cambio Organizacional
Profundizando en la Perspectiva de Análisis
Por Francisco Vaca

Muchos proyectos de BI que se terminan correctamente desde el punto de vista

tecnológico no cumplen sus expectativas de retorno de inversión. Creemos que
uno de los factores que lo impiden es que no se tomaron en cuenta los impactos
en la cultura y en la organización que supone el disponer de una nueva plata-
forma para organizar, hacer disponible y analizar la información.

Hace no mucho tiempo participamos en la

implementación de un proyecto de BI para
una empresa del sector financiero. Desde el Expectativa Situación actual
punto de vista de ejecución del proyecto, los
resultados fueron satisfactorios en tiempo, Mayor oportunidad El reporte se sigue en-
costo y funcionalidad, sin embargo, tras seis en la entrega del tregando en la segunda
reporte. semana de cada mes.
meses de operación, tuvimos que hacer una
revisión del proyecto, dado que existía un
bajo nivel de satisfacción en el principal pa-
Mayor exactitud Los datos finales de ven-
trocinador del proyecto en cuanto al cumpli- en los datos. tas presentados en el
miento de sus expectativas de resultados. reporte no coinciden con
los datos del datamart.
En un principio no se encontró ningún pro-
blema significativo ni en la operación, ni en
el hardware, ni en las herramientas: la infor-
mación estaba al día y “cuadraba”, el perfor- Menores costos El número de personas
mance era adecuado, los usuarios conocían de producción de involucrado se mantuvo
reportes. igual.
las herramientas: ¿Cómo es que tenemos un
solución que “funciona” desde los puntos
de vista técnico y operativo, pero que desde
la perspectiva del usuario principal no cum-
Causas
A pesar de que existe una función para la producción
automática del reporte trimestral, el reporte se pro-
duce bajo el formato antiguo de powerpoint y el pro-
ceso de revisión y ajuste no se modificó.
Algunos datos son “ajustados” durante el proceso de
revisión (en ocasiones hay ventas que “se guardan”
para los meses malos).
En base al reporte se deciden bonos e incentivos por
lo que hay una presión muy grande para que los nú-
meros se “vean bien”.
Aunque el reporte básico está automatizado los
pasos de “revisión” y “ajuste” continúan siendo
los mismos (hay cuatro niveles jerárquicos que
participan en el proceso).
El proceso de elaboración continúa siendo manual en
las etapas finales de producción.

ple con sus expectativas?

Más tiempo dis- El esfuerzo de produc- Este beneficio no se ve con claridad ya que los tiem-
ponible del equi- ción del reporte se redu- pos de entrega no cambiaron.
Analizamos con detalle el caso de un reporte po de análisis jo en un 80% principal-
trimestral de ventas que se consideraba crí- mente por automatizar Otras funcionalidades de la herramienta de análisis
tico, ya que era usado por la alta dirección, el proceso de datos. no han sido explotadas.
y que es un caso representativo de lo que
sucedía. Esto es lo que encontramos:

34 FEB-ABR 2009 www.sg.com.mx

Al estudiar las causas que provocaron que
se lograra un proyecto técnicamente ade-
cuado, pero que presenta dificultades para
cumplir con las expectativas de uso son:
Un enfoque tecnológico del proyecto. El
líder del proyecto tenía una formación y ex-
periencia dentro de las tecnologías de infor-
mación, el presupuesto provenía del área de
sistemas, prácticamente todos los miembros
del equipo tenían la misma orientación técni-
ca que el líder, el proveedor de la tecnología
aportó metodología y expertise de desarrollo.
95% del esfuerzo y de los recursos se dedica-
ron a la tecnología: selección y puesta a pun-
to del hardware, a la selección del proveedor
de la tecnología, a los procesos de ETL.
La capacitación se enfocó exclusivamente al
uso de las herramientas de explotación.
El involucramiento de usuarios se enfocó en
resolver las necesidades y los problemas de
desarrollo del proyecto, por lo que los temas
asociados al uso no fueron evidentes en las
fases de desarrollo.
El enfoque metodológico se basó en deter-
minar y resolver las necesidades de informa-
ción, y se estudió muy poco el contexto de
toma de decisiones.
Expectativas de resultados asociadas a la
calidad y disponibilidad de los datos. Los
usuarios y los miembros del equipo del pro-
yecto pusieron muy poco énfasis en el uso
de los datos, ya que el problema que se de-
finió era la disponibilidad y oportunidad de
los mismos. Se supuso que no habría pro-
blema en el “uso” de los mismos.
No se tomaron en cuenta los cambios or-
ganizacionales que necesariamente pro-
vocaría la implementación del proyecto. El
más importante de todos ellos consiste en
que se trataba de una organización altamen-
te “jerárquica”, y la disponibilidad genera-
lizada de la información, suponía cambios
en la estructura de poder que implicaba una
redefinición de roles y responsabilidades.
Francisco Vaca Gómez es socio director de TEDE de 2006 a la fecha. Ha realizado diseño e implementación de proyectos de educación basados
en competencias, instrucción de programas educativos, investigación y promoción de la educación basada en competencias
www.sg.com.mx
En muchos casos, las personas tenían la in-
formación, y por lo tanto la capacidad para
tomar una decisión, pero al final tenían que
ir “a tocar base con su jefe”, perdiéndose en
el camino la posibilidad de aprovechar la ca-
pacidad plena de las herramientas.
Se dió prioridad a resolver las necesidades
de los analistas. El esfuerzo de análisis y
de definición de requerimientos se realizó
fundamentalmente desde la perspectiva de
analistas y procesadores de información; la
visión del alto directivo quedó únicamente
reflejada en un conjunto de reportes, que si
bien basados en las necesidades declaradas
por los directores, no tomó en cuenta sus
“usos y costumbres” del proceso real para
tomar decisiones.
Para elevar el nivel de uso, y por lo tanto de éxi-
to del proyecto, recomendamos lo siguiente:
Ampliar la perspectiva de análisis al consi-
derar el contexto de toma de decisiones. El
alcance del proyecto debe considerar aspec-
tos de cambio organizacional, de forma que
se puedan hacer ajustes en roles, responsa-
bilidades y procesos de toma de decisiones.
• Definir los cambios en las estructuras for-
males e informales de toma de decisiones
que permitirán aprovechar las ventajas del
proyecto. Algunas de estas ventajas tienen
carácter estratégico.
• Definir quiénes pueden tomar decisiones
y diseñar esquemas de incentivos que alien-
ten la toma de decisiones.
• Demostrar que tomar decisiones basadas
en hechos, reduce la incertidumbre en base
a experiencias exitosas.
Alinear expectativas de los usuarios fina-
les en cuanto al uso de las herramientas.
No es posible tener un Ferrari y manejarlo
como si tuviéramos un “vochito”, debemos
hacer ajustes en los hábitos de conduc-
ción si se desea maximizar la experiencia
de conducir un Ferrari.
• Mejorar las competencias estadísticas y
matemáticas.
• Mejorar la capacidad de hacer preguntas y
plantear hipótesis.
• Mejorar la capacidad para “explorar” en
los datos.
Entrenar a alta dirección en los procesos
de toma de decisiones utilizando las herra-
mientas. Tradicionalmente los resultados se
muestran en “powerpoints”, pero ahora se
puede presentar y analizar mediante la he-
rramienta OLAP.
• Capacitar en el proceso de sesiones de
análisis en tiempo real.
• Capacitar en el uso de las funciones y ca-
pacidades de análisis visual que muchas
herramientas ofrecen (colores, tamaños,
formas, tipos de gráficas).
• Capacitar en procesos formales de análisis
y toma de decisiones.
Buscar pequeños éxitos y difundirlos am-
pliamente. Tenemos que demostrar cómo
las nuevas herramientas agregan valor a
la empresa, y que la “forma tradicional” es
mucho menos efectiva que la “nueva forma”
de tomar decisiones; que no es más comple-
ja sino más simple, que no lleva más tiempo
sino menos. Muchas personas que tengan
una postura de escepticismo frente a la so-
lución, pueden cambiarla al ver a otros tener
éxito. Tratamos de publicar casos que ten-
gan alguna característica de estas:
• Se redujo el tiempo para tomar la decisión
porque fue más simple.
• Se incrementa la satisfacción del cliente
debido a que el método de tomar decisio-
nes es más efectivo (tomó menos tiempo, el
diagnóstico fue más preciso).
• Se optimiza un proceso debido a que se pudo
analizar desde diversos puntos de vista.
Referencias
[ Adelman, Sid. 2003. Impossible Data
Warehouse Situations. Addison-Wesley. ]
[ Biere, Mike. 2003. Business Intelligence
for the enterprise. IBM Press. ]
[ Davenport, Thomas, Jeanne Harris,
David DeLong y Alvin Jacobson. 2001.
Data to knowledge to results. California
Management Review. ]
FEB-ABR 2009 35
 // publireportaje

SEPG LA 2008
Memoria del evento

Del 12 al 14 de noviembre se llevó a cabo la

quinta edición de la conferencia SEPG LA
2008 (Software Engineering Process Group
Latin America) en Mar del Plata, Argentina; a
la cual tuvimos la oportunidad de asistir. Esta
conferencia es organizada anualmente por el
European Software Institute (ESI) en conjun-
to con el Software Engineering Institute (SEI),
y coordinada por el anfitrión local, en este
caso: el ESI Center Cono Sur.
Este año el tema de la conferencia fue “Com-
binando Disciplina con Métodos Ágiles”, te-
niendo como objetivo apoyar a las empresas
para que sean capaces de ofrecer respues-
tas ágiles a las necesidades de sus clientes
y adaptarse rápidamente a las nuevas tec-
nologías. La conferencia se centró en las
lecciones obtenidas de varias experiencias
en el campo de la mejora de procesos de
software, especialmente en América Latina,
pero también en todo el mundo.
La bienvenida del evento contó con la parti-
cipación de Paul D. Nielsen, Director y CEO
del SEI, Manu Prego, Director General del
ESI, Guillermo Leruga, Presidente del ESI
Center Cono Sur, Carlos Gianella, Presidente
de la Comisión de Investigaciones Científi-
cas (CIC), Miguel Ángel Calello, Presidente
de la Cámara de Software y Servicios Infor-
máticos (CESSI), Gerardo Renzetti, Director
de Servicios del ESI Center Cono Sur y Jesús
Salilllas, Chair Comité de Programa.
La audiencia
El SEPG LA es un congreso dirigido a pro-
fesionistas implicados en actividades de
mejora sistemática de personas, procesos
y tecnologías en organizaciones donde el
software es un elemento clave para la con-
secución del éxito empresarial. Durante
esta quinta edición pudimos ver desde reco-
nocidos gurús, hasta profesionistas que se
inician en temas de procesos de software y
sistemas. Una situación peculiar que obser-
vamos, fue que este congreso ha desarro-
llado una comunidad de profesionistas que
año con año asisten a encontrarse con sus
colegas, aportando al evento un ambiente
de amistad y compañerismo.
La agenda
El programa estuvo compuesto por confe-
rencias magistrales, sesiones, paneles de
discusión y seminarios sobre temas adap-
tados a la realidad de América Latina: dis-
ciplina con métodos ágiles, competitividad
en el mercado global de TI, mejora de pro-
cesos en situaciones de estrés, preparación
para evaluaciones, y mejora de procesos en
entornos pequeños, entre otros. Empresas
como Motorola, TATA e IBM, compartieron
sus experiencias; y ponentes del SEI, ESI,
así como de empresas de consultoría y uni-
versidades, nos ofrecieron una agenda va-
riada y de interés para todos los niveles.
La expo
El espacio ideal para lograr un networking
entre los asistentes, es la expo, que en esta
ocasión cumplió su objetivo. Contó con 13
stands; y en medio de un ambiente bastante
agradable, permitió a los asistentes tanto
conocer la oferta de los expositores como
contactar a nuevos colegas.
El evento social
Al término del primer día se ofreció un coc-
tel de apertura en el área de expo, contando
con un performance acompañado de luces y
música, disfrutamos el momento ideal para
“romper el hielo”. Al término del segundo
día y como evento de cierre, asistimos a una
cena de gala, en la que nos dejamos deleitar
por cantantes y bailarines de tango, y sabo-
reamos la excelente comida argentina. Por si

Cabe mencionar que esta edición de SEPG

LA, contó con el apoyo del gobierno de Ar-
gentina, el patrocinio de la CIC y de empresas
como CDA, Apertura - Information Tecnlolo-
gy, Liveware Ingeniería de Software, Grupo
Tekne, BMC Software, Oracle y SITEPRO. Así
como con el apoyo de múltiples organismos
y universidades locales.

36 FEB-ABR 2009 www.sg.com.mx

fuera poco, nos sorprendió el gran entusias-
mo de los asistentes, ya que todos bailamos
y cantamos por un buen rato.
La sede
Durante las fechas de la conferencia, en la
ciudad de Mar del Plata se llevó a cabo una
muestra de cine, así como un evento deporti-
vo estudiantil, dando a la sede un panorama
tecnológico, cultural y deportivo, con vista al
mar. Los anfitriones se lucieron por su gran
hospitalidad, desde los organizadores hasta
los mismos argentinos que asistieron al con-
greso, quienes no se cansaron de atendernos
y apoyarnos en todo lo necesario.
La participación del ESI
El ESI es una organización sin fines de lucro
que se lanzó como una iniciativa de la Comi-
sión Europea, con el apoyo de diversas organi-
zaciones europeas de TI, y desde 2003 forma
parte de Tecnalia, una de las principales cor-
poraciones tecnológicas privadas en Europa.
En 2002 creó la Red ESI Center, con el objetivo
de facilitar el acceso mundial a sus servicios.
Es mediante esta red que llega a América Lati-
na, y como parte de dicho esfuerzo, organiza
anualmente la conferencia SEPG LA.
www.sg.com.mx
“La principal actividad del ESI se centra en
apoyar a las empresas en sus objetivos de
producir software de mayor calidad, con me-
nor esfuerzo y menor costo”, nos comentó
su Director Manu Prego, que además nos
compartió datos muy interesantes sobre la
visión del ESI.
Por ejemplo, mencionó que el ESI asigna
gran porcentaje de sus ingresos a investi-
gación y desarrollo, actividades enfocadas
a desarrollar productos que ayuden a las
empresas a ser más maduras y produc-
tivas. “Ya hay suficientes modelos en el
mercado, el problema real de las empresas
es cómo ponerlos en práctica. En esa área
el Instituto no desarrolla nuevos modelos,
sino proyectos que ayuden a las empre-
sas”, comentó Manu.
Entre sus productos más recientes se en-
cuentra IT Mark, enfocado en mejorar los
procesos de software en las empresas pe-
queñas, cubriendo áreas como mercadotec-
nia, comercialización y finanzas.
Para conocer más sobre esta conferencia vi-
sita: www.esi.es/SEPGLA
FEB-ABR 2009 37
 // PRÁCTICAS /*arquitectura empresarial*/

Enterprise Architecture
Estrategia + Negocio + Tecnología
Por Jaime Ruíz

No es ningún secreto que los proyectos de &TUSBUFHJB

Iniciativa Estratégica 1
le permitirá identificar los servicios reutiliza-
TI comúnmente se retrasan o cuestan más Iniciativa Estratégica 2 bles, diseñar esquemas de orquestación y, lo
de lo planeado. Pero aún peor es cuando di- más importante, definir pautas para implantar

/FHPDJP
Z
"MJOFBDJwO
EF
5FDOPMPHrB
chos proyectos no logran cumplir los objeti- /FHPDJPT
Proceso 1
el esquema de gobernabilidad, del cual depen-
vos de negocio deseados. Esto típicamente Proceso 2
de el éxito de este tipo de iniciativas.
se debe a falta de alineación entre la estra-
Proceso 3

&"

4

#

5
tegia, los procesos de negocio, y las tecno- Una arquitectura empresarial incluye:
*OGPSNBDJwO Reutilización

logías de información. Y justamente ese es Flujo

de Datos
de Objeto
Diccionario
de Datos
• Modelos de procesos de negocio, informa-
el problema que busca resolver la disciplina ción, sistemas y tecnología.
de la Enterprise Architecture (EA), o arqui- • Descripciones de artefactos gráficos y
tectura empresarial. 4JTUFNBT
Sistemas

Servicios Web
textuales.
Aplicaciones
• Trazabilidad total de las metas y objetivos
La arquitectura empresarial es la disciplina Red de
de la organización.
que define y mantiene los modelos e inicia- 3FEFT
Datos
Red de
• Estándares que respaldan el contenido y
tivas para llevar, tanto al área de negocio presentación de la arquitectura.
Voz
Red de
Video

como a la de TI, a trabajar juntas para lograr

la estrategia corporativa. En pocas palabras,
la arquitectura empresarial alínea la tecno-
logía a las necesidades reales del negocio.
La ejecución adecuada de esta disciplina re-
duce de manera significativa la brecha entre el
desempeño deseado y el real porque, a través
de un mapa global, integra y administra todas
las áreas de una organización. Lo que también
le permite analizar el impacto de los cambios,
Figura 1. EA alinea estrategia, negocio y tecnología. Una arquitectura empresarial bien integrada
proporciona capacidad para responder a los
Toda organización que encamine sus esfuerzos cambios; costos reducidos en la gestión de
hacia una arquitectura orientada a servicios infraestructura de TI; mejor comunicación,
(SOA) tendrá que recurrir al EA. Es ahí donde procesos y análisis de negocio; respuestas
encontrará los mapas y documentación de pro- rápidas, eficaces y positivas; mapas de la
cesos de negocio y sus interrelaciones con los organización, indispensables en iniciativas
dominios de estrategia y tecnología. Además, de SOA o reingeniería de procesos.
Marco Preliminar

tomar decisiones clave de negocio y asegurar

mejoras sin afectaciones catastróficas. A
Visión
Arquitectónica

Como se aprecia en la figura 1, la arquitectu-

H B
Gestión de Arquitectura
Cambios de de Negocios
ra empresarial consiste de un repositorio de Arquitectura

modelos y documentos integrados bajo tres G Requerimientos

C
Sistemas de

perspectivas: Estrategia (Strategy), Negocio

Implementación Información
de Gobernabilidad

(Business) y Tecnología (Technology), lo cual

2
se representa por la fórmula EA = S+B+T. F
Planeación de
1
Crear
Considerar
Vistas
Migración
Cada perspectiva describe el estado actual, E
Baseline
3

el estado futuro y la brecha entre ambos. Oportunidades

y Soluciones
8
Análisis de
Crear Modelo
Arquitectónico
Brecha D
Arquitectura

El objetivo de todo esto es tomar decisiones es- 7

Tecnológica 4
Seleccionar
Servicios
tratégicas efectivas para mejorar la calidad, efi- Definir
Arquitectura

cacia y responsabilidad del negocio, así como 6

5
Confirmar
Objetivos de
responder de manera rápida y positiva a las Determinar
Criterios
Negocios

oportunidades y desafíos del mercado, conso-

lidaciones del sector y avances tecnológicos. Figura 2. Architecture Development Method (ADM).

Jaime Arturo Ruiz García es Director General de Matersys Group, consultoría especializada en Tecnologías de la Información y Comunicación. Su éxito:
soluciones de vanguardia y a la medida de sus clientes. jruiz@matersys.com

38 FEB-ABR 2009 www.sg.com.mx

El marco de referencia TOGAF
El marco de referencia TOGAF, desarrollado
por The Open Group, se ha convertido en el
paradigma con mayor aceptación para desa-
rrollar arquitecturas empresariales. A diferen-
cia de otros marcos de referencia como por
ejemplo el de Zachman, TOGAF no sólo es un
marco para categorizar los elementos que hay
que capturar, sino que también define un mé-
todo para hacer las cosas. Dicho método es
el Architecture Development Method (ADM),
el cual define cómo desarrollar, implementar
y mantener una arquitectura empresarial. El
ADM funciona en conjunto con las notaciones
y técnicas de modelado más populares tales
como Unified Modeling Language (UML),
Business Process Modeling Notation (BPMN),
modelado de datos, e IDEF.
La figura 2 ilustra los pasos y flujo del ADM
para desarrollar y mantener una arquitec-
tura empresarial.
www.sg.com.mx
Uso de herramientas
Si vas a desarrollar y mantener la arqui-
tectura empresarial de una organización
no trivial, te recomiendo que utilices una
herramienta especializada para esto. En el
mercado existen herramientas que permi-
ten utilizar métodos y técnicas de modelado
estándar para generar un repositorio de mo-
delos donde se administra la arquitectura
empresarial de una organización.
Figura 3. Modelado de EA con System Architect.
La figura 3 muestra una imágen de Telelogic
System Architect, una de las herramientas
para EA más populares.
Conclusión
Aunque EA no es la panacea de to-
dos los males por los que una orga-
nización puede sufrir, es sin duda el
mejor mecanismo para aglutinar y
alinear los diferentes dominios de la
organización. y ante todo dar un sen-
tido estratégico y de beneficios reales
a iniciativas de mejora de procesos,
reingeniería y apego a estándares y nor-
mas de la industria como son: CMMI,
ITIL, COBIT y SOX entre otros.
Referencias
[ TOGAF. opengroup.org/togaf ]
FEB-ABR 2009 39
 // PRÁCTICAS /*requerimientos*/

Cuando los Casos de Uso no Alcanzan

Antipatrones en la Concepción de CU
Por Carlos Ortega

Mucho se ha escrito sobre los Casos de Uso, ¿qué son?, ¿para qué
sirven?, ¿cómo se pueden identificar?, etcétera. Uno puede encon-
trar en cualquier biblioteca, navegando por Internet o en una tienda
electrónica como Amazon, decenas de artículos y bibliografía espe-
cializada sobre el tema. De hecho, emplear casos de uso se ha vuel-
to la técnica de captura de requerimientos más popular.
La facilidad de concepción y diagramado los ha vuelto algo así
como un sinónimo de “que se tratan de hacer las cosas con cali-
dad” o que se emplea “algo” de ingeniería o procesos de software.
Ahora bien, quienes nos hemos dedicado a desarrollar software
y empleado esta técnica de manera intensiva en algún proyecto
mediano o grande, seguramente nos encontramos con particulari-
dades donde claramente se perciben los beneficios y limitaciones
de los casos de uso. El presente artículo está dedicado a describir
varias de estas situaciones.
Para iniciar esta discusión, permítanme ser claro sobre lo que va-
rios consultores, e incluso personal de nuestros clientes, observa-
mos durante la ejecución de diferentes proyectos en los que hemos
tenido la oportunidad de participar, y en otros que conocemos de
manera indirecta, y esto es: La falta de conocimiento formal que pre-
domina en nuestra industria sobre lo que es un caso de uso, cómo
debe describirse, para qué sirve y para qué no sirve.
Podría parecer aventurada dicha afirmación (personalmente de-
searía que así lo fuera). Sin embargo, la cantidad de sistemas y
proyectos que arrastran tal problema es bastante grande.
Este artículo no pretende explicar estos conceptos, ni tampoco
desea exponer las razones de esta debilidad, sino sólo enumerar
los problemas y antipatrones particulares. Algunos de los cuales
citamos a continuación.
Errores y antipatrones comunes
• Considerar que la interacción/comunicación que se muestra en los
diagramas de CU donde aparece algún CU vinculado a uno o varios
actores es sinónimo de flujo de datos.
• Considerar un subflujo como un caso de uso.
Ejemplo:
· CU Alta de Cliente, CU Baja de Cliente, CU Consulta de Cliente
• Considerar la “regla de oro” para entidades: Un CU debe exhibir forzo-
samente una funcionalidad “ABC” completa (Altas, Bajas, Cambios ).
Ejemplo:
· CU Ventas:
- Subflujo Altas de Órdenes de Compra
- Subflujo Bajas de Órdenes de Compra
- Subflujo Cambios de Órdenes de Compra
• Para considerar qué es incorrecto o no, deben existir líneas con
cabezas de flecha asociando a un Actor con un CU.
• Considerar a la sección de precondiciones dentro de la descripción
del CU como útil para incluir cualquier situación o evento que deba
existir antes para iniciar un CU.
Ejemplo:
· Para que se de el CU “Administrar Órdenes de Compra”, debe
tenerse como precondiciones:
- Que el vendedor esté autenticado en el sistema
- Que exista un catálogo de artículos
- Que exista una interfase con el sistema que maneja el catálo-
go de artículos
- Que exista la comunicación con el sistema que maneja el
catálogo de artículos
• Incluir detalles de diseño o de bajo nivel dentro de la especifi-
cación de CU.
Ejemplos:
· El sistema debe conectarse con el sistema de administración de
inventarios y obtener de la tabla “artículos” el artículo X utilizan-
do el articuloID como llave foránea...
· El usuario da click en el campo “Artículos de Oficina” y selecciona
la categoría del combo “categoría”
· El sistema debe actualizar la tabla tarjetahabiente utilizando
el query “select * from...”

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. Certified Profesional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como el
Banco de México, 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, Cristal).

40 FEB-ABR 2009 www.sg.com.mx

 “La facilidad de concepción y diagramación
han convertido a los CU en sinónimo de
hacer las cosas con calidad”.
• Considerar que el comportamiento de uno o varios de los elemen-
tos de la interfase gráfica asociada son reglas de negocio.
• Considerar como “regla de oro” que no es necesario incluir un do-
cumento de requerimientos no funcionales, si estos se pueden cu-
brir totalmente incluyendo una sección llamada “requerimientos no
funcionales” en la descripción de los CU.
• Creer que los lineamientos que están descritos en un proceso so-
bre algún formato específico son inamovible (aún cuando sea muy
difícil emplearlo, no tenga sentido, o simplemente existan maneras
alternativas que pueden proporcionar mayores beneficios).
• Y finalmente, lo que desde mi punto de vista es uno de los más
grandes errores: Creer que la única forma de capturar requerimien-
tos funcionales es utilizar CU.
Seguramente para muchos lectores estas descripciones (y otras
más) les resultarán familiares, y para otros más les será una sorpre-
sa saber que muchos conceptos o prácticas que aplican tan vehe-
mente en sus proyectos en realidad son errores, fallas o antipatro-
nes comunes de concepción o aplicación.
Como éste artículo no pretende incendiar los ánimos para in-
dicar si algo está bien o no, sino sólo realizar sugerencias para
ampliar y enriquecer el conocimiento de los roles que capturan,
analizan y administran requerimientos, a continuación se hacen
las siguientes recomendaciones.
Sugerencias y recomendaciones
• Estudiar bibliografía de Ingeniería de Requerimientos y no sólo de
casos de uso. Acceder también a bibliografía de diferentes autores.
· Al investigar, el lector podrá constatar que los CU no es la única
técnica para capturar requerimientos, y que en diversas situacio-
nes tales como cuando exista poca interacción actores-sistema o
cuando se trata de interfases de usuarios ricas y complejas ma-
nejadas por una gran cantidad de eventos, el tratar de utilizar CU
resultará en tareas improductivas o muy costosas.
• Asistir a entrenamiento formal.
· Es muy posible que muchos directores, gerentes y líderes, con-
sideren que no es necesario si existe Internet. Hay libros sobre el
tema y quizá con uno o dos recursos que asistan a un curso bá-
www.sg.com.mx
sico son más que suficientes, frente a esto solo hay un 2 puntos
que también se invita a considerar:
1. Ni Internet ni ningún libro poseen todo el conocimiento. Muchas
veces la exposición e intercambio de experiencias e ideas con otros
consultores y asistentes puede proporcionar una mayor variedad,
profundidad o enfoque de los temas y conceptos.
2. Al desear que un solo asistente pretenda dispersar interna-
mente el conocimiento a otros miembros del equipo, puede ser
contraproducente, sobre todo considerando que es posible que
al intentar replicar la capacitación se reproduzcan también du-
das, malas interpretaciones o conceptos aún no entendidos total-
mente, esto es, se desvirtúan los conceptos al pasar de boca en
boca sin un pleno dominio del tema.
• Pensar “out-of-the-box”: Muchas veces queremos, deseamos o
prometemos capturar los requerimientos funcionales utilizando
sólo CU, esto es lo mismo que pensar: porque tengo un coche pue-
do tomarlo e ir de vacaciones a cualquier parte en él. Ciertamente
es posible ir a Cuernavaca, Pachuca, Toluca, Puebla, Querétaro y
Guadalajara, sin embargo, si quiero tomar vacaciones en Tijuana,
San Francisco, Bogotá o Río de Janeiro, quizá ir en coche no resulte
la mejor o más inteligente opción; en términos de los tiempos cos-
tos y esfuerzo asociado.
• Tratar de tocar mas de un dominio, esto es, tratar de intervenir o co-
nocer proyectos en dominios o industrias tradicionales donde existan
diferentes conceptos y procesos que por su naturaleza resulten en un
reto para su conceptualización, tratamiento y comprensión.
• Relacionarse con otros analistas con diverso background y
experiencia.
Referencias
[ Leffingwell, Dean;Widrig, Don. “Managing Software
Requirements A Use Case Approach”. Addison Wesley ]
[ Adolph, Steve; et. al.”Patterns for Effective Use Cases”.
Addison Wesley ]
[ Palmkvist, Övergaard.“Use Case Patterns and Blueprints”.
Addison Wesley Professional]
FEB-ABR 2009 41
 // PRÁCTICAS
COMPETISOFT
Mejora de Procesos de Software en Iberoamérica
Por Ma. Julia Orozco, et. al.
Este artículo resume el proyecto iberoameri-
cano COMPETISOFT que tiene como objetivo
incrementar la competitividad de las PyMEs
en el desarrollo de software.
COMPETISOFT
Es un proyecto financiado por CYTED, pro-
grama internacional de cooperación cien-
tífica y tecnológica multilateral, de ámbito
iberoamericano que tiene como propósito
incrementar el nivel de competitividad de
las PyMEs iberoamericanas productoras de
software mediante la creación y difusión de
un marco metodológico común que, ajusta-
do a sus necesidades específicas, llegue a
ser la base sobre la que se pueda estable-
cer un mecanismo de evaluación y certifica-
ción de la industria del software reconocido
en toda Iberoamérica.
El proyecto fue dirigido por el Dr. Mario Piattini
de España y la Dra. Hanna Oktaba de México.
Se buscó recoger el conocimiento de más de
100 investigadores de países como España,
México, Brasil, Argentina, Uruguay, Colombia,
Ecuador, Costa Rica, Chile, Perú, entre otros.
En el proyecto se plantearon los siguientes
objetivos específicos:
• Generar un marco metodológico común
iberoamericano
• Difundir la cultura de procesos mediante
la formación de investigadores, docentes y
profesionales.
• Incidir en los diferentes organismos de
normalización y certificación de los países
iberoamericanos, para que asuman que los
principios metodológicos, objeto de este
proyecto puedan ser la base para establecer
un mecanismo común y mutuamente reco-
nocido de evaluación y certificación de la
industria del software iberoamericana.
Ma. Julia Orozco es directora Técnica de Ultrasist participante en el proyecto COMPETISOFT como investigadora, instructora de instructores y coautora del
libro: “Competisoft Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos”.
Claudia Alquicira es responsable del Grupo de procesos de Ultrasist participante en el proyecto COMPETISOFT como investigadora, instructora de instructores
y coautora del libro: “Competisoft Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos”.
42 FEB-ABR 2009
/*MEJORA DE PROCESOS*/
Marco metodológico Categoría
COMPETISOFT es una iniciativa integra- Alta Dirección Gestión de Negocio
(DIR)
dora que ha tomado como base a mode-
Categoría
los y mejores prácticas ya existentes, los
Gestión de Procesos
cuales han sido mejorados y adaptados Gestión de Cartera de Proyectos
con las experiencias de los investigado- Gerencia Gestión de Recursos
· Humanos
(GER)
res, PyMEs y unidades gubernamentales. · Bienes, Servicios e Infraestructura
Considera un modelo de referencia de pro- · Conocimiento
cesos, un modelo de mejora de procesos Categoría
y propone usar como marco general para Administración del Proyecto
la evaluación a la norma internacional Operación Desarrollo de Software
(OPE) Mantenimiento de Software
ISO/IEC 15504: Performing an Assessment.
.PEFMP
EF
1SPDFTPT
Experiencia de
las PyMEs
Experiencia de
los investigadores
vos estratégicos. La categoría de Operación,
Experiencia de las
unidades gubernamentales se encarga de llevar a cabo los proyectos de
Modelo de desarrollo y mantenimiento de software esta-
Referencia
MoProSoft
EvalProSoft
blecidos en la categoría de Gerencia.
CMMI
ISO 15504
ISO 12207
Modelo de
Evaluación Gerencia monitorea y retroalimenta a la ca-
Métrica v3
tegoría de Operación, y retroalimenta la de
Modelo de Alta Dirección.
Mejora
Agile SPI mps Br.
MARES
IMPACT
COMPETISOFT enfatiza la diferencia entre la
7JTJwO
(FOFSBM Gestión de Cartera de Proyectos (Gerencia)
que coadyuvará en el cumplimiento del Plan
Modelo de procesos o modelo Estratégico y el Proceso de Administración
de referencia del Proyecto (Operación) que se enfoca en
El modelo de referencia de COMPETISOFT, cumplir con los compromisos establecidos
está basado en MoProSoft que establece con el cliente en tiempo y costo.
tres categorías que agrupan procesos de
acuerdo a la estructura típica de una organi- COMPETISOFT agrega en la capa de operación
zación: Alta Dirección, Gerencia y Operación. el proceso de Mantenimiento de Software, el
La categoría de Alta Dirección, establece la ra- cual tiene como objetivo llevar a cabo de for-
zón de ser, lo que se desea alcanzar y las es- ma ágil los cambios solicitados a un producto
trategias para lograrlo en un plan estratégico. de software de tal forma que no se pierda la
consistencia, y que cumpla con las necesida-
La categoría de Gerencia, se encarga de crear des del cliente. Permite los cambios durante
planes de acción para instrumentar las es- el camino, y considera una retroalimentación
trategias en cuanto a proyectos, procesos y constante con el cliente junto con una entrega
recursos necesarios para alcanzar los objeti- rápida y periódica de atención a las peticio-
www.sg.com.mx
nes de mantenimiento que permita cumplir
con los niveles de servicio solicitados.
El proceso de mantenimiento considera
una fase de preparación en la cual con
base en el plan de proyecto, se asignan los
roles, se definen criterios, formas de tra-
bajo y mecanismos de comunicación. Una
petición de modificación puede ser una
solicitud de cambio (perfectivo, adaptati-
vo y preventivo) o un informe de problema
correctivo urgente, o no urgente.
Considera el mecanismo para recibir, ana-
PmCOMPETISOFT está basado en un enfo-
que iterativo e incremental, de tal forma que
se pueda tener una entrega temprana y con-
tinua de mejoras que den visibilidad de los
resultados a la Alta Dirección.
El proceso de mejora continua considera ci-
clos de mejora en donde cada uno incluye
las actividades de instalación, diagnóstico,
formulación de mejoras, ejecución de mejo-
ras y revisión del ciclo.
Las iteraciones son priorizadas
La guía del consultor
PmCOMPETISOFT
Se generó el perfil base para la categoría
de Operación para las empresas que inician
en un programa de mejora con los procesos
de Desarrollo de Software, Mantenimiento
de Software y Administración de Proyecto.
Incluye PmCompetisoft.
En el perfil base se ajustaron los procesos
de la categoría de Operación para ser im-
plantados en una organización sin necesi-
dad de los demás procesos.

lizar y dar seguimiento a las peticiones de
modificación. Las peticiones se atienden por
grupos en ciclos, los cuales se clasifican en
planificable y no planificable. Cada ciclo es
conocido en COMPETISOFT como SprintM. La
definición está basada en Sprint de SCRUM.
Cada ciclo considera la selección, análisis de
las peticiones, intervención, pruebas y paso
a producción. Incluye actividades para dar
seguimiento al registro de las peticiones,
obtener el estado de avance y posibles pro-
blemas que puedan ocurrir dentro de su eje-
cución, identifica qué se puede mejorar en la
solución del próximo grupo de peticiones.
Modelo de mejora de procesos
El modelo de mejora está basado en Agile SPI.
Define los elementos necesarios para conducir
la mejora de procesos en una pequeña organi-
zación de software de una forma ágil, econó-
mica, con pocos recursos y en poco tiempo.
Incluye un proceso de mejora denomina-
do PmCOMPETISOFT, una metodología
para la evaluación interna de procesos y
una guía para formular y ejecutar mejoras
usando SCRUM.
Iteración de
Mejora 1
Referencias
[ Oktaba, H.; Piattini, M.; Pino, F.; Orozco,
Iteración de
Mejora 2 M.J; Alquicira, E. COMPETISOFT. “Mejora de
Procesos de Software para Pequeñas y
Iteración de Medianas Empresas y Proyectos”. 2008.
Mejora 3
Madrid España, RA-MA Editorial. ]
Iteración de
Mejora n [ Oktaba, H. “MoProSoft: A Software Process
Model for Small Enterprises”. Proceedings
of International Research Workshop for
1SPZFDUP
P
$JDMP
EF
.FKPSB
Process Improvement in Small Settings”. 19-20
de octubre 2005. pp.93-101. Pittsburgh,
Otros componentes EEUU. SPECIAL REPORT CMU/SEI-2006-
Durante el proyecto se generaron plantillas SR-001. ]
de apoyo para el proceso de desarrollo de
software como: [ Oktaba, H.; García, F.; Piattini, M.; Pino, F.;
• Plantilla para Especificación de Requisitos. Alquicira, C.; Ruíz, F. “Software Process
• Lista de chequeo de Casos de Uso (Nivel Improvement: The COMPETISOFT Project”.
conceptual). October, 2007. Vol. 40(10), pp. 21-28. IEEE
• Guía para preparar el documento de Computer]
Requisitos.
• Plantilla para generar el Plan de Pruebas. [ NYCE. “Modelo de Procesos para la Indus-
• Lista de chequeo del Plan de Pruebas. tria de Software - MoproSoft - Versión 1.3”.
Agosto 2005. NMX-059/03-NYCE-2005. Ciudad
• Guía para generar el Plan de Pruebas de
de México, Organismo nacional de norma-
Sistemas.
lización y evaluación de la conformidad
-NYCE. normalizacion-nyce.org.mx/php/
Un cuestionario para el diagnóstico del estado
loader.php?c=interes.php&tema=21 ]
del proceso de Administración del Proyecto.

Oswaldo Gómez consultor de Ultrasist participante en el proyecto COMPETISOFT como autor de capítulo “Mediciones del Software y su implementación en
el Modelo de Procesos de COMPETISOFT”.

Alejandro Ramírez consultor de Ultrasist cuenta con un posgrado en Ciencia e Ingeniería de la Computación, UNAM, México, 2007, que fueron tomadas en
cuenta en el modelo COMPETISOFT.

www.sg.com.mx FEB-ABR 2009 43

 // PRÁCTICAS /*aseguramiento de calidad*/
Implementación de Modelos de Calidad
Diagnóstico de las Empresas Desarrolladoras de Software en México
Por Edna Gutiérrez, et. al.
Este artículo analiza el entorno de los modelos de calidad de soft-
ware para las empresas mexicanas. En el marco del desarrollo de la
tesis de la alumna Edna Gutiérrez Gasca para la Maestría en Ciencias
de la Computación, en el año 2007 se realizó un diagnóstico del co-
nocimiento y uso de modelos de calidad en empresas desarrollado-
ras de software. Este artículo presenta los resultados obtenidos en
dicha investigación.
Acerca del instrumento de medición
El instrumento de medición utilizado fue un cuestionario donde se ob-
tenía información sobre las características de la empresa, el proceso
de desarrollo de software que aplican, la forma en que manejan las en-
tregas, y el proceso que utilizan para evaluar la calidad del producto.
La población objeto fueron empresas desarrolladores de software
con centros de operación en México. La convocatoria para que se
contestara la encuesta se realizó con el apoyo de la revista SG, la hoy
extinta AMCIS, y el Tec de Monterrey Campus Ciudad de México.
En total, 114 empresas respondieron la encuesta, siete fueron des-
cartadas debido a que no contestaron el cuestionario en su tota-
lidad. El nivel de confianza resultó de 96%, con un error máximo
admisible de 10%, considerando una población de 1,243 empre-
sas, según datos proporcionados por el Directorio de Empresas de
Tecnologías de Información (DETI).
Análisis e interpretación de los resultados
• Tipo de empresa. 55% de las empresas que contestaron la encues-
ta, desarrolla software a la medida, mientras que 33% su giro no es
específicamente el software, pero lo desarrollan, y 12% pertenecen
al giro de desarrollo de software empaquetado. En base a esto se
establece que 88% de las empresas de software en México lo de-
sarrolla de acuerdo con las especificaciones del cliente y sólo 12%
restante desarrolla software para un mercado abierto.
• Cantidad de personal involucrado en la elaboración del producto.
Como se aprecia en la tabla 1, el número de personas involucradas
en la elaboración de software es muy pequeño, ya que más de un
tercio de las empresas encuestadas cuentan con menos de cinco
personas para la realización de software.
Número de personas % de empresas
Menos de 5 36%
6 a 10 28%
11 a 20 15%
Más de 20 21%
Tabla 1. Personas involucradas en la elaboración de software.
44 FEB-ABR 2009
El resultado muestra que son pocos los recursos humanos asigna-
dos por las empresas para la ejecución del proceso de desarrollo
y mantenimiento de software. Según la norma NMX-059/03-NYCE-
2005 (MoProSoft), este proceso requiere de al menos nueve roles
diferentes. Esto provoca que las personas desempeñen distintos
roles, lo cual se traduce en documentación incompleta y la concen-
tración en actividades operativas, como la codificación del producto
para cumplir con los requerimientos del cliente.
Proceso de desarrollo de software utilizado
De acuerdo con la investigación, 71% de las empresas utilizan un
proceso o metodología, mientras que el 29% restante considera al
desarrollo de software como un proceso creativo que no puede ajus-
tarse a una metodología.
Al ampliar la respuesta definiendo cuál metodología utilizan,
encontramos que el primer lugar lo ocupan las “metodologías
propias”, seguido de las “metodologías ágiles” entre las que
destacaron XP, SCRUM y metodología en espiral, y en tercer
lugar los “modelos y normas establecidas”, como: CMM, CMMI,
ISO 9000:2000 y PMBOK. Resalta que este último grupo no dis-
tingue entre modelo y metodología. Un modelo es un marco de
referencia que responde a la pregunta: ¿qué se debe hacer?,
mientras que la metodología está asociada a la pregunta ¿cómo
debe implantarse?
Metodología % de empresas
Propia 45.41%
Métodos ágiles 41.25%
Modelos establecidos 13.34%
Tabla 2. Metodología utilizada.
Calidad de la documentación
La investigación arroja que más de la mitad de las empresas que
participaron en la encuesta (53%) consideran que la documentación
generada por ellos no es de calidad.
La determinación de que la documentación no es de calidad está
referida a que sólo se documenta el manual de usuario por falta
de recursos humanos especializados, y por considerar a la do-
cumentación como elemento accesorio y no como la evidencia
de la realización de un proceso, ejecutándose una vez terminado
el producto software. Algunas empresas incluso, carecen de do-
cumentación, por considerar que sus productos son pequeños.
Finalmente, las que sí cuentan con ella argumentan que los do-
cumentos generados en el proceso están desfasados contra la
funcionalidad implantada en el producto.
www.sg.com.mx
En contraparte, existe un porcentaje de empresas que consideran que
su documentación sí es de calidad (47%), principalmente en aquellos
casos en que la documentación técnica se hereda y se reutiliza.
Modelos de calidad utilizados
La tabla 3 refleja los modelos de calidad utilizados por las empresas
encuestadas.
Modelo % de empresas
Ninguno 71%
CMM/CMMI 22%
MoProSoft 6%
ISO 12207 1% El porcentaje que menos productos entrega tiene un promedio de
Tabla 3. Modelo de calidad utilizado.
Resalta el alto porcentaje de empresas que no utiliza ningún modelo. Al
indagar un poco más, averiguamos que 86% de las empresas encuesta-
das ha considerado utilizar un modelo de aseguramiento de calidad de
software, es sólo que en el momento de la encuesta no lo había logrado
implementar. Entre este grupo, 44% se inclina por MoProsoft como op-
ción, 26% por CMMI y el resto no refiere modelos.
Tiempos de entrega del producto
74% de las empresas entrega un producto en un plazo de 3 a 5 me-
ses, el 22% en un periodo de 6 a 12 meses, y finalmente el 4% lo en-
trega en 13 meses ó más. A partir de estos datos, se concluye que la
mayoría de los encuestados se enfocan en proyectos de corto plazo.
Entrega de prototipos
La tabla 4 muestra la cantidad de prototipos que las empresas en-
tregan por proyecto.
Cantidad de Prototipos % de empresas
Ninguno 30%
Uno 34%
De 2 a 4 30%
5 o más 6%
Tabla 4. Entrega de Prototipos.
Edna Gutiérrez Gasca es alumna de la Maestría en Ciencias de la Computación en el Tecnológico de Monterrey, Campus Ciudad de México.
Agustín Francisco Gutiérrez Tornés es profesor de Asignatura en el Tecnológico de Monterrey, Campus Ciudad de México.
www.sg.com.mx
Si partimos del hecho que la condición de terminación de una itera-
ción es la generación de un entregable (prototipo), se concluye que
la mayor parte de las empresas encuestadas requieren afianzar sus
productos con el cliente, a través de entregas parciales (al menos
una). Estas entregas parciales, representan puntos de control para
detectar y corregir desviaciones contra los requerimientos estableci-
dos. Por lo tanto, a través de dicha estrategia, se reducen los defec-
tos en la entrega final del producto de software.
Cantidad de productos que la empresa entrega
De acuerdo con la investigación, 44% de las empresas entregan de uno
a tres productos al año, 30% de cuatro a siete y 26%, ocho o más.
liberación de tres productos al año.
Es por ello que los modelos de calidad propuestos, tanto de proceso
como de producto, deben ser adaptables y fáciles de implantar para
las empresas (en su mayoría micro) que realizan sus entregas en
tiempos cortos (menor o igual a tres meses).
Evaluación de calidad del producto
64% de las empresas encuestadas reportó que sí mide la calidad
del producto final. De dicho porcentaje, 67% realiza principalmente
pruebas unitarias y de funcionalidad, 33% comenta que la miden
a través de una encuesta de satisfacción del cliente que se realiza
posteriormente a la entrega del producto.
Tenemos entonces que, más de la mitad de las empresas que
participaron en la encuesta realiza la evaluación de su producto
utilizando el enfoque del productor; es decir, que la calidad está
determinada por el apego a los requerimientos del cliente (en su
mayoría funcionales) y no desde el punto de vista del producto,
donde la calidad está determinada por el cumplimiento de las
siguientes características: confiabilidad, mantenibilidad, eficien-
cia, portabilidad y usabilidad. Por otra parte, un 36% señala que
desconoce los métodos de evaluación, por lo que no realiza eva-
luación alguna del producto final.
Por otro lado, al considerar el uso de herramientas para evaluar la
calidad del producto de software, 78% de las empresas reportaron
carecer de herramientas, porque las considera muy costosas.
FEB-ABR 2009 45
 // PRÁCTICAS /*aseguramiento de calidad*/

“Según las encuestas, hay interés en contar

con un modelo de procesos para el desarrollo
de software dentro de la industria mexicana”.

En cuanto a los modelos y normas que utilizan para asegurar la ca-

lidad del producto de software, 93% de la muestra reportó que no
utiliza modelos para evaluar la calidad del software, mientras que
6% utiliza la norma ISO/IEC 9126 y 1% utiliza MECA.
Garantía ofertada al cliente
Encontramos que 75% de las empresas encuestadas otorga una ga-
rantía a sus clientes, mientras que 25% no lo hace. La garantía gene-
ralmente se hace válida por errores encontrados en post-producción,
contra especificación de los requerimientos, y el plazo típicamente
va de los 45 días hasta los 3 meses.
Resalta que la mayoría de los encuestados otorgan garantía a partir
de la especificación de requerimientos funcionales, pero no contem-
pla los requerimientos no funcionales.
Tomando en consideración estas afirmaciones, se puntualiza
que los modelos de calidad tanto de proceso como de pro-
ducto para las empresas mexicanas de desarrollo de software,
deben considerar lo siguiente:
• Adaptabilidad a equipos pequeños de desarrollo y a entre-
gas de producto en plazos menores a tres meses.
• Definición de desarrollos iterativos y entregas de proto-
tipos funcionales al cliente con base en su especificación
de requerimientos.
• Aumento de la calidad de la documentación generada en el
proceso de desarrollo de software.

Conclusión
Esta encuesta ha servido para detectar la necesidad de con-
tar con un modelo de calidad para empresas desarrolladoras
de software con equipos pequeños de trabajo: menos de diez
personas, dónde el desarrollo del producto se realiza en tiem-
pos cortos entre 3 y 5 meses, y a la medida del cliente.
Hay interés en contar con un modelo de procesos para el de-
sarrollo de software y dado que los desarrollos son iterativos,
es muy útil contar con prototipos funcionales que en realidad
sirven para reducir el riesgo de inconformidades en el proceso
de desarrollo, y lograr una mayor satisfacción para el cliente
en la entrega del producto final.
Por otra parte, la mayoría de las empresas reportaron no contar
con una herramienta de evaluación del producto de software, y
no utilizan modelos para asegurar la calidad del producto. Adi-
cionalmente, se puede identificar la escasez de las empresas
que conocen modelos de calidad enfocados al producto, por lo
que es necesario capacitar a las empresas en estos rubros.
Referencias
[ Gutiérrez Tornés, Agustín. “Propuesta de un modelo cualimétrico
para la evaluación de la calidad del  software”; Septiembre1999;
CIC-IPN; México. ]
[ MoProSoft. Versión 1.1, Mayo 2003. http://tinyurl.com/a7cnzz ]
[ Mendoza, Luis E; Pérez, María A; Griman, Anna C. “Prototipo de
Modelo Sistémico de Calidad del software”. Revista Computación y
Sistemas. Vol. 8. Num. 3. CIC-IPN. México. pp. 196-217. ]
[ Garvin, David. “What Does Product Quality Really Mean?” Sloan
Management Review. 1984.]
[ PMI. “Guía de los fundamentos de la dirección de proyectos”
(PMBOK.). México. Tercera edición 2004. ]
[ DETI. edigital.economia.gob.mx/deti ]

Aurora Pérez Rojas es profesor Investigador de la Universidad Autónoma del Estado de Hidalgo (UAEH).

Luis Felipe Márquez López es egresado del Instituto Tecnológico Autónomo de México (ITAM).

46 FEB-ABR 2009 www.sg.com.mx

 /*PROGRAMAR ES UN MODO DE VIDA*/
La Seguridad en Cómputo
¿Con qué se Come?
Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del
Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo
de DGSCA-UNAM desde 1999.
L a evolución del rol que cumplen los siste-
mas en las organizaciones ha cambiado por
completo –afortunadamente– el punto de
vista que la mayor parte de los desarrolla-
dores tiene con respecto a la seguridad.
Hace una o dos décadas, el tema de la se-
guridad en cómputo era frecuentemente
evitado. Y hasta era justificable: ¿Intrusos?
¿Integridad? ¿Validaciones? En ese enton-
ces había muy poco software diseñado para
su operación en red, y mucho menos para la
idea de red que tenemos hoy en día. Si bien
es cierto que la mayor parte de los ataques
se origina y siempre se ha originado den-
tro del perímetro de confianza de nuestra
organización, hace 20 años sencillamente
había menos información sensible alojada
en medios electrónicos, menos gente con
el conocimiento necesario para manipular-
la, e incluso la manipulación tenía efectos
menos nocivos, ya que la información en
medios electrónicos era el respaldo de la
copia maestra que estaba en papel. Hoy en
día estamos transitando hacia la situación
opuesta, donde la versión electrónica es la
primaria, por lo que una intrusión en nues-
tros sistemas puede poner en jaque la inte-
gridad de la información primaria.
Mantener la seguridad en los sistemas que
desarrollamos implica un alto costo: los pro-
gramadores deben aprender a evitar errores
comunes; hay que dedicar recursos para
implementar baterías de pruebas; entran en
juego validaciones y conversiones sobre los
datos que manipulamos, con costos en tiem-
pos de procesamiento de cada solicitud...
pero, afortunadamente, ha crecido también
la conciencia de que esto es algo necesario.
El problema sigue siendo, coloquialmente...
“¿con qué se come?” La seguridad en cómputo
sigue siendo un campo difícil de entender, con
muchas aristas ocultas. Es por esto que, en las
www.sg.com.mx
siguientes ediciones de SG, iré abordando en
esta columna algunos temas fundamentales.
Para iniciar, ataquemos lo fundamental: ¿Qué
debemos entender por seguridad en cómputo?
A riesgo de que parezca que me limito a
perogrulladas, un “sistema seguro” es sen-
cillamente un sistema “que responde como
debe”. Claro, hay que ver esto a la luz de va-
rios criterios para que en verdad signifique
algo. Intentemos nuevamente... un sistema
seguro presenta:
• Consistencia. Ante las mismas circunstan-
cias, debe presentar el mismo comportamien-
to. Ante un sistema “seguro”, el tradicional
remedio “¿ya intentaste reiniciarlo?” no surte
efecto. Si nos hemos acostumbrado a que un
reinicio resuelve las cosas, no es sino porque
el ambiente de ejecución se ensucia con ele-
mentos que debería haber descartado.
• Protección y separación. Los datos, instruc-
ciones y espacio de memoria de un programa
o usuario, no deben interferir ni permitir inter-
ferencia de otros. Las condiciones anormales
ocurridas en uno de los componentes (sean ac-
cidentales o expresas) deben tener un impacto
mínimo en el sistema como un conjunto.
• Autenticación. El sistema debe asegurar
que un usuario es realmente quien dice ser.
• Control de acceso. Nuestro sistema debe
ser capaz de controlar el acceso a sus da-
tos, con el nivel de granularidad requerido
–quién tiene acceso a qué recursos, y qué
tipo de acceso tiene.
• Auditoría. El sistema debe ser capaz de regis-
trar, así como de notificar a quien sea necesario
de cualquier anomalía o evento importante.
Todos estos atributos deben ir matizados,
priorizándolos al nivel adecuado a nuestras
necesidades. Ir demasiado lejos en uno de
estos objetivos puede incluso ser perjudi-
cial para los fines de nuestro sistema. Por
ejemplo, en México un usuario de banco por
// columna
Internet se autentifica a través de usuario
y password, en combinación con un dispo-
sitivo que genera cadenas de números que
cambian periódicamente. Esto tiene senti-
do para el manejo de una cuenta de banco,
pero podría ser demasiado para una simple
cuenta de correo electrónico.
Una recomendación es no perderse tratando
de lograr la perfección. Bien dice el refrán que
“lo perfecto es enemigo de lo bueno”. Es im-
portante que, en toda etapa de la planeación,
desarrollo, implantación y tiempo de vida de
un sistema, recordemos que 100% de seguri-
dad es una utopía, un objetivo que sólo puede
servir para guiar nuestro trabajo diario.
Los programas son escritos por humanos, y
son también humanos quienes administran
los sistemas en que corren. Hay una gran can-
tidad de interacciones entre sus elementos; y
un cambio en cualquiera de ellos puede tener
consecuencias inesperadas si no se hace con
cuidado y conciencia. Constantemente apare-
cen nuevas categorías de errores capaces de
llevar a problemas de seguridad. Parte funda-
mental de nuestra actuación como profesiona-
les en nuestro campo, debe ser mantenernos
al día con los últimos desarrollos y amenazas.
Dos de las organizaciones más influyen-
tes en la investigación y respuesta a inci-
dentes de seguridad informática, SANS y
MITRE, acaban de publicar su lista de los
25 errores de seguridad más importantes:
www.sans.org/top25errors.
Este listado incluye muchos temas de fun-
damental relevancia, algunos de los cuales
abordaré en posteriores columnas. Vienen
explicados con un buen nivel de detalle,
puntualizando cómo evitar o mitigar sus
efectos. Les recomiendo ampliamente fami-
liarizarse con ellos.
» Por Gunnar Wolf
FEB-ABR 2009 47
 // UML
Las relaciones son importantes
Obteniendo Diagramas de Clases
Por Charlie Macías
Dicen por ahí que “lo prometido es deuda”,
así que en esta ocasión hablaremos del mo-
delado de las relaciones entre las clases de
diseño. Este compromiso lo adquirimos,
Sergio Orozco y un servidor, en el artículo
publicado en la edición de Marzo-Abril de
2006 de esta revista… también dicen por ahí
que “más vale tarde que nunca”.
En el artículo antes mencionado expusi-
mos las técnicas aplicables para obtener
un diagrama de clases a partir de uno de
secuencia, las cuales podemos resumir en
el cumplimiento de tres reglas:
1. Cualquier línea de vida (objeto) que apa-
rezca como participante en el diagrama de
secuencia, debe ser instancia de una clase.
2. Cualquier mensaje recibido por una línea
de vida (objeto) debe estar soportado por
una operación definida en la clase de la
cual es instancia.
3. Cualquier intercambio de mensajes entre
dos líneas de vida (sobre todo cuando éstas
son instancias de clases distintas) debe ver-
se reflejado mediante algún tipo de relación
(asociación binaria, agregación de tipo sha-
red, agregación de tipo composite o depen-
dencia) en el diagrama de clases.
En este artículo nos enfocaremos en la ter-
cera regla, porque es la que quedó, digamos
“oscura”, en el artículo anterior. Las figuras
1 y 2 nos ayudarán a regresar al contexto del
ejemplo que tomaremos como base para el
resto de la disertación.
Como podemos observar en el diagrama de se-
cuencia (Figura 1), la instancia de la clase TPV
le envía tres mensajes a la instancia de la clase
Venta, y esta última a su vez, le envía un men-
saje a la instancia de la clase RenglonVenta, así
Charlie Macías es arquitecto en jefe e instructor senior en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación
práctica y consultoría en modelado de sistemas y negocios con UML, BPMN y SysML. Puedes contactarnos en info@milestone.com.mx www.milestone.com.mx
48 FEB-ABR 2009
sd Punto de Venta
El asunto es responder a la pregunta ¿por
tpv: TPV
qué entre TPV y Venta se modeló una depen-
dencia, mientras que entre Venta y Renglon-
1.0 Venta(ventaXML)
nuevaVenta: Venta
Venta una composición?
La respuesta o respuestas cortas son: por-
1.1 agregarRenglonVenta(renglonesVentaXML)
que la relación entre TPV y Venta no es es-
tructural, mientras que la relación entre
rv: RenglonVenta Venta y RenglonVenta sí lo es. O también po-
1.2 RenglonVenta(cantidad, idProducto)
dríamos decir que: porque entre TPV y Venta
se forma un enlace transitorio, mientras que
entre Venta y RenglonVenta se establece uno
permanente. La segunda forma de explicar-
1.3 registrarPago(monto)
lo es la que prefiero, y estoy convencido que
es la que resulta más clara, por tanto, es la
que usaré para la respuesta larga.
Figura 1. Diagrama de secuencia para registrar una venta.
La diferencia entre el modelado de una de-
que, si aplicamos la tercera regla, debe existir pendencia o de una asociación (binaria, agre-
algún tipo de relación entre TPV y Venta, así gación shared o agregación composite) radica
como entre Venta y RenglonVenta (Figura 2). en la transitoriedad o permanencia del enlace
entre los objetos que participan en la interac-
cd Diagrama de Clases-Operaciones
ción, es decir, qué tanto dura el enlace.
TPV
Enlace transitorio
Si el enlace entre los objetos tiene el alcance
Venta
de una ocurrencia de ejecución (rectángulo
delgado que se modela sobre la línea de vida,
- fecha: Date
- folio: String
y que en código lo veríamos como el cuerpo
de la operación) entonces en el diagrama de
+ agregarRenglonVenta(String) : void
+ registrarPago(double) : void clases lo modelaríamos como dependencia.
+ Venta(String) Cuando en el código vemos que desde el
cuerpo de una operación (método) podemos
acceder a los servicios de un objeto, ya sea
renglonesVenta 1..x porque recibimos una referencia hacia el mis-
RenglonVenta mo mediante parámetro o porque creamos
- cantidad: int esa referencia localmente al instanciarlo, o
+ RenglonVenta(int, long) : void
porque dicha referencia es consecuencia de
que el objeto sea de acceso global (como en
Figura 2. Diagrama de clases derivado del diagrama el patrón del Singleton) entonces modela-
de secuencia. mos una dependencia. En el caso de nuestro
www.sg.com.mx
ejemplo y apoyándonos en el siguiente frag-
mento de código, podemos observar que en
el método “registrarVenta” se crea una refe-
rencia hacia una instancia de la clase Venta
llamada “nuevaVenta”, pero dicha referencia
se pierde al concluir el método.
public class TPV {
public void registrarVenta(String ventaXML){
…
Venta nuevaVenta = new Venta(ventaXML);
nuevaVenta.agregarRenglonVenta
(renglonesVentaXML);
nuevaVenta.registrarPago(monto);
…
}
} a través de la ejecución de una o más ope-
Enlace permanente
Si el enlace entre los objetos trasciende ocu-
rrencias de ejecución, entonces significa un
enlace permanente y se modelará una aso-
ciación (binaria, agregación shared o agre-
gación composite) en el diagrama de clases.
Para conseguir que un enlace trascienda ocu-
rrencias de ejecución, es necesario alojar la
referencia hacia el objeto en un atributo de
la clase. En nuestro ejemplo podemos obser-
var que los renglones venta son alojados en
la colección “renglonesVenta”, la cual es un
atributo de la clase Venta, esto hace posible
que las referencias hacia los objetos del tipo
ReglonVenta sobrevivan a la conclusión del
método “agregarRenglonVenta”.
public class Venta {
List< RenglonVenta > renglonesVenta =
new ArrayList<RenglonVenta>();
public void agregarRenglonVenta
(String renglonesVentaXML){
… Conclusión
renglonesVenta.add
(new RenglonVenta(cantidad, idProducto));
…
} clases distintas que colaboran para
} alcanzar un objetivo es transitorio, en-
En nuestro ejemplo, la relación entre Venta y
RenglonVenta resulta ser una agregación del
tipo composite, lo que le indica al programa-
dor que el manejo de la colección debe ser
por valor, y que la relación debe ser simétrica.
Pero bien pudimos haber modelado una agre-
gación del tipo shared si nuestra decisión de
diseño hubiera sido que el manejo de la co-
lección fuera por referencia. Una relación de
asociación binaria se modelaría en el caso de
que el enlace entre los objetos estuviera limi-
tado a una sola instancia de sendas clases.
www.sg.com.mx
Las relaciones entre las clases
manifiestan decisiones de diseño
Finalmente, una idea importante es que las
relaciones de los distintos tipos dependen de
las decisiones de diseño que tomen los que
plantean la solución al problema, y cuando
hablamos de problemas para los que aplican
soluciones de ingeniería, son problemas de
solución abierta, es decir, hay muchas posi-
bles soluciones, unas mejores que otras. Al-
gunos criterios podrían ser los siguientes:
• Si un objeto requiere de un enlace hacia
otro objeto una y otra vez, es decir, que pa-
rece permanecer relacionado al otro incluso
raciones, entonces probablemente una rela-
ción de asociación sea lo más conveniente.
• Si un objeto se enlaza con otro para consu-
mir sus servicios, y después lo deshecha, en-
tonces podríamos preferir una dependencia.
• Si en tiempo de ejecución varios objetos
necesitan y comparten de un tercero, una y
otra vez, quizá podíamos decidir compartir al
tercero pasándolo como parámetro. También
podríamos decidir o necesitar que el objeto
compartido fuera único y global en el proceso
(patrón del Singleton), en cualquiera de estos
dos casos, modelaríamos una dependencia.
• Si a fin de mejorar el desempeño y esca-
labilidad del sistema, descubrimos que nos
sale más barato mantener un objeto en me-
moria que creando y destruyendolo podría-
mos decidir alojarlo en una variable de clase
(atributo) y esto nos llevaría a escoger una
asociación.
En términos simples:
• Si el enlace entre dos instancias de
tonces se modela una dependencia.
• Si el enlace entre dos instancias de
clases distintas que colaboran para al-
canzar un objetivo es permanente (so-
brevive a ocurrencias de ejecución),
entonces se modela una asociación
(binaria, agregación de tipo shared,
agregación de tipo composite).
La temporalidad de los enlaces, y por
tanto la naturaleza de las relaciones
entre las clases, obedece a las de-
cisiones de diseño que se tomen al
plantear la solución al problema.
FEB-ABR 2009 49
 // PM CORNER
APlICANDO PROJECT MANAGEMENT AL BI
De las Bases de Datos a la Inteligencia de Negocios
Por Jorge Valdés
Como hemos visto en este número de SG, la Inteligencia de
Negocios se refiere al uso de los datos de una empresa para facili-
tar la toma de decisiones estratégicas; es decir, la comprensión del
funcionamiento actual y la anticipación de acciones para dar una
dirección bien informada a la empresa. Visto de otro modo, podría-
mos decir que este concepto consiste en sacar el máximo provecho
de los recursos de información con que cuenta una organización,
con el fin de tomar las mejores decisiones. Desde decidir el lanza-
miento de nuevos productos o servicios basados en la segmenta-
ción de sus clientes, hasta decisiones de reducción de costos para
mejorar la rentabilidad de una línea de negocio que quizás no está
dando los resultados esperados.
Como Gerentes de Proyecto, debemos conocer y entender las par-
ticularidades de este tipo de proyectos, de tal forma que el día de
mañana que estemos a cargo de un proyecto de implantación de BI,
lo podamos manejar de forma adecuada. A continuación comparto
algunos de los puntos que considero de mayor relevancia.
Etapas
Normalmente en la integración de los repositorios de informa-
ción, a partir de datos de diversas fuentes, se usa un proceso
conocido como ETL (Extraction, Transformation and Load). A con-
tinuación lo describo:
• En la fase de extracción, típicamente se identifican las fuentes de
datos que abastecerán al sistema de información, así como los crite-
rios de normalización de los mismos, para que la información llegue
depurada a los grandes almacenes de datos (Data Warehouses) que
servirán para producir los análisis que requiere la alta dirección de
la empresa para apoyar la toma de decisiones.
• Durante la fase de transformación, se aplican los criterios defini-
dos, de manera que la información es homologada, depurada y nor-
malizada, para poder darle un tratamiento masivo una vez que esté
en los almacenes de datos.
• Finalmente la fase de carga tiene como objetivo la población de los
distintos repositorios que se hayan definido, de acuerdo al análisis
inicial de tipos de datos y fuentes de información.
Estar conscientes del reto y el costo
Un proyecto de esta naturaleza requiere que tanto el Gerente de
Proyecto como su equipo de trabajo, así como el patrocinador del
mismo, hagan un análisis a conciencia del desafío que representa
para la organización. El manejo de los riesgos se vuelve crucial, pues
50 FEB-ABR 2009
en un proyecto de esta naturaleza, son muchas las posibilidades de
que algo no resulte como fue planeado y, si no contamos con los
planes de contingencia para manejar dichas situaciones, el proyecto
sufrirá y la organización aun más.
En mi experiencia, una solución de BI es intensiva en el uso de
recursos tecnológicos, tanto de hardware como de software, así
que antes de iniciar una iniciativa de esta naturaleza es importan-
te tomar en cuenta las capacidades reales de la organización para
considerar el costo completo.
La comunicación es clave
Es también necesario contar con un Plan de Comunicación que plan-
tee la forma en que habrá que interactuar con los distintos actores
del proyecto, los mensajes que habrá que cuidar y la forma en que
serán manejadas las expectativas. Sobra decir la importancia que
reviste el hecho de que los participantes en el proyecto se comuni-
quen de manera activa y proactiva.
Un proyecto de esta naturaleza puede durar varios meses o inclu-
so años. Por lo tanto, se sugiere tomar en cuenta las siguientes
recomendaciones:
• Planificar algunas actividades de integración del equipo de trabajo
en ambientes extra laborales, pues más vale ir creando relaciones de
confianza, sentido de pertenencia y excelente entendimiento entre
nuestro equipo, que nos permita estar unidos para enfrentar el gran
desafío que se nos avecina.
• Identificar actores clave en la organización, y aquí me refiero a per-
sonas que quizás no tengan el rango más alto de sus respectivas
áreas, pero que sean capaces de influir en ella de manera que, lle-
gado el momento los podamos tener como aliados. Uno nunca sabe
cuándo va a necesitar un favor.
• Finalmente, apliquen el principio del destripador; es decir, va-
yan por partes chiquitas y manejables, que les permitan lograr
pequeños éxitos y que en suma logren cumplir los objetivos
planteados originalmente por la organización. Un proyecto así,
difícilmente se puede ver como uno solo, más bien se tiene que
administrar como un programa.
Asegurarse que el usuario sea capaz de
aprovecharlo
El objetivo final de la inteligencia de negocios es poner a disposición
de los usuarios, herramientas de explotación que les permitan analizar
www.sg.com.mx
 “Un proyecto de BI requiere que tanto el
Gerente de Proyecto así como su equipo,
y el patrocinador haga un análisis a
conciencia del desafío que presenta”.

la información relevante desde diversas perspectivas. Por supuesto,
dichas herramientas deben ser de fácil manejo y muy intuitivas, pues
están dirigidas hacia usuarios que no necesariamente tienen conoci-
mientos técnicos y habilidades avanzadas en el uso de la tecnología.
Un esquema de inteligencia de negocios busca abarcar más allá de la
simple generación de reportes estáticos, y llegar hasta los usuarios
y proveerles con poderosas herramientas que les ayuden a manejar
cubos de información dinámicos, que faciliten el establecer varios ti-
pos de relaciones seleccionando los datos que sean de su interés para
llevar a cabo análisis predictivos de acuerdo a sus necesidades. Esto
implica que, por un lado, el sistema debe ser fácil e intuitivo, pero
que también debemos desarrollar entre los usuarios la capacidad de
aprovechar el sistema, lo cual implica capacitarlos.
Principales complicaciones
Como seguramente ya se han dado cuenta, implantar una iniciativa
de BI en una organización no es una tarea trivial. A continuación las
principales razones que complican este tipo de proyectos:
• Son iniciativas transversales. Es decir, que comprenden diversas
áreas de la organización.
Aunque no tengo información fidedigna, intuitivamente y en base
a mi propia experiencia, les puedo decir que muchos de estos
proyectos fracasan por aspectos técnicos, pero son más los que
fracasan por cuestiones humanas.
Compartiendo experiencia
En un proyecto en el que participé hace algún tiempo, se buscaba
integrar un almacén de datos con información de clientes. El proble-
ma principal radicaba en que cada una de las líneas de negocio de
la empresa, contaba con bases de datos independientes, con la in-
formación de sus respectivos clientes. Esto provocaba que existieran
muchos registros duplicados; pero además, que la información entre
las distintas bases de datos no estuviera homologada. Probablemen-
te yo podía aparecer en la base de datos de una organización como
Jorge Valdés Garciatorres, mientras que en otra, podía estar registra-
do como Jorge Valdez García. Como se podrán imaginar, lo anterior
dificultaba enormemente la tarea de consolidación de información. El
simple hecho de definir quién debería participar en la definición de
criterios para depurar y limpiar la información, generó mucha polémi-
ca al interior de la organización, creando grandes luchas de poder y
aspectos políticos que, nada más de recordarlos me pongo a temblar.

• Se requiere involucrar recursos con un profundo conocimiento de
cada uno de los aspectos que integran el negocio.
• Es necesario contar con gran poder de procesamiento y almace-
namiento de información, pues en proyectos de esta naturaleza se
manejan varias copias de los datos de la organización.
• Requiere que los usuarios tengan un entendimiento de cómo
sacar el mayor provecho de los almacenes de datos para benefi-
cio de la corporación.
• El proyecto necesariamente requiere la participación de exper-
tos externos a la organización y la selección de los mismos pue-
de ser tan complicada que en sí misma deba manejarse como un
proyecto preliminar.
Estos puntos que pueden parecer muy sencillos, realmente exigen
que el Gerente del Proyecto aplique sus habilidades al máximo
y por supuesto que tenga varios años de “cicatrices de guerra”.
Por otra parte, ya sobre la marcha, nos dimos cuenta que era nece-
sario nombrar un responsable de administrar la información; en este
caso, de personas. Pues aun y cuando pudiéramos hacer un exce-
lente trabajo de depuración, limpieza y normalización de los datos,
al no existir un único dueño de la información, se provocaría que los
nuevos registros se pudieran contaminar rápidamente, y otra vez,
tener discrepancias. Es decir, teníamos que asegurar que la calidad
de la información mejorara desde que ésta se ingresaba a los sis-
temas de información de la empresa. El contar con un “dueño” de
la información favorecería la creación de políticas y estándares de
trabajo alrededor de los procesos de captura y mantenimiento de
datos, y la vigilancia periódica de su cumplimiento. Esto reduciría la
aparición de incidencias y reduciría el volumen de información con-
taminada haciendo el proceso ETL más eficiente.
Como pueden suponer, no fue fácil encontrar a la persona idónea,
pero es un aspecto en el cual también se tiene que pensar, si se quie-
re implantar un buen marco de inteligencia de negocios que le sirva
a la organización a largo plazo.

Jorge Valdés Garciatorres (PMP, ITIL, CC) es Socio Director de la firma global de consultoría y educación en procesos de negocio y dirección de proyectos TenStep
Latinoamérica. Participa como vicepresidente de Desarrollo Profesional en el PMI Capítulo México en donde además es miembro del consejo editorial. Es miembro
del consejo editorial de SG y es miembro activo de Toastmasters International. jvaldex@tenstep.com.mx

www.sg.com.mx FEB-ABR 2009 51

 // COLUMNA /*PRUEBA DE SOFTWARE*/

Modelos de Calidad para Prueba de Software

Constituyentes Fundamentales de 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 lustros, que incluyeron una estancia de posgrado en prueba de software en
Alemania, en la que abordó aspectos formales de esa disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado
frecuente en eventos relacionados con la prueba de software.

E n la edición agosto-octubre 2008 mencionamos que los modelos

de calidad (MC) deben proporcionar un marco de referencia tanto
5. Personal del área de pruebas
6. Posición en el organigrama del área de prueba
para diagnosticar las capacidades de una organización, como para 7. Comunicación y reportes
diseñar y ejecutar planes de mejora. Dijimos que los MC deben ser 8. Administración de defectos
completos, consistentes y objetivos, y que deben proporcionar una 9. Administración del testware
manera rápida de obtener una evaluación inicial de capacidades. 10. Infraestructura tecnológica para probar

También comentamos que los MC, incluidos los especializados en
prueba de software, suelen tener una estructura matricial como la
figura 1, e hicimos un muy breve análisis de varios de ellos. Ahora
profundizaremos en la estructura de los modelos especializados en
prueba de software (MCEP).
Elementos fundamentales de un MCEP
Haciendo un análisis de nuestra experiencia en consultoría, diag-
nosticando y ayudando a mejorar organizaciones de prueba, y de
lo publicado en la literatura especializada, vemos que las áreas lis-
tadas abajo son de las más relevantes y comunes a una proporción
significativa de (MCEP):
1. Proceso de prueba
2. Estrategia de pruebas
3. Punto de arranque de las pruebas
4. Métricas
CMMI y MoProSoft no incluyen este núcleo, razón por la cual no nos
fue útil en nuestros esfuerzos por mejorar las capacidades de prue-
ba de software, como comentamos en el número antepasado.
Es también común que los MCEP midan los avances en cuatro
ó cinco niveles. Varios de ellos utilizan subniveles, lo que en la
práctica resulta de mucha utilidad, porque los pasos de mejora
pueden ser más pequeños y detallados.
Los MCEP deben tomar en cuenta, tanto el caso de que la organiza-
ción de prueba se encuentre dentro de una empresa de desarrollo
de software, como el de que forme parte de una empresa especia-
lizada en prueba o calidad. Igualmente deben mostrar diferencias
entre los casos en que se prueba software convencional, de aqué-
llos en que lo que se evalúa, si es software crítico (aquél en el que
si falla, alguien se muere).

Figura 1. Estructura matricial.

52 FEB-ABR 2009 www.sg.com.mx

 “Los Modelos de Calidad deben ser
completos, consistentes, y objetivos”.

Aplicación de esos elementos
En nuestra experiencia en los diagnósticos y ayuda a mejorar or-
ganizaciones de pueba hemos encontrado útil comenzar a abordar
las áreas del MCEP antes mencionadas, en el orden que muestra
la siguiente figura, prestando atención primero a áreas de capas
interiores para luego, sin dejar de trabajar en esas, comenzar a
abordar las de la siguiente capa exterior.
.nUSJDBT
Una vez cubiertos los fundamentos anteriores podemos ocuparnos
también de que el equipo de pruebas tenga una posición adecuada
en el organigrama (en particular, buscando que no dependa de un
directivo responsable de entregar en tiempo y forma, desarrollos de
software, para evitar la situación de ser “juez y parte”); de que cuen-
te con el personal suficiente en cantidad (aproximadamente 25% del
total de los recursos asignados al desarrollo de software) y en cali-
dad (selección y entrenamiento apropiados); de que se administre
adecuadamente los insumos y productos de las pruebas (y evitar es-
tar probando una versión no actual del software); y de que se cuente
con un laboratorio de pruebas adecuado.

En una tercera fase podemos trabajar también en recabar y explotar sis-

0SHBOJ[BDJwO *OGSBFTUSVDUVSB temáticamente métricas; en que las pruebas comiencen más temprano
1SPDFTP en el ciclo de desarrollo; y en que las labores y los resultados de las prue-
bas resulten de utilidad a un grupo mayor de roles en la organización.
&TUSBUFHJB %FGFDUPT
Un aspecto muy importante a considerar al diseñar el plan de mejora
3FDVSTPT
)VNBOPT 5FTUXBSF es la recuperación de la inversión, lo que induce la pregunta: ¿cuál
es la secuencia de pasos que más conviene para la organización en
sus circunstancias particulares?
1VOUP
EF
JOJDJP $PNVOJDBDJwO

Continuaremos con estos temas en el próximo número.

Figura 2. Áreas en capas.
Lo vemos así, porque es muy común encontrar organizaciones de
prueba con fuertes carencias en la definición de su proceso, en el
diseño de una estrategia que combine adecuadamente técnicas de
prueba, y en la administración de los defectos que se detectan, lo
que dificulta mucho avanzar con paso firme. Podemos considerar
estas primeras áreas como asépticas.
Invitación
En marzo tendremos como invitado en e-Quallity a un experto in-
ternacional, con quien ofreceremos pláticas sobre temas relacio-
nados con los MCEP en el D.F., Monterrey y Guadalajara. Si tienes
interés en asistir, escribe a contact@e-quallity.net con el encabe-
zado “Plática con Expertos”.
¡Hazlo yá; hay cupo limitado!
» Por Luis Vinicio León / Berenice Ruíz

Berenice Ruíz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. A lo largo de su trayectoria profesional ha actuado
también como tester senior, administradora de proyectos de prueba nacionales e internacionales, y directora de operaciones. Ha sido profesora de la Universidad
Autónoma de Guadalajara, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.

www.sg.com.mx FEB-ABR 2009 53

 // COLUMNA
El Software 2010-2015
Capacidades Avanzadas de TI, Democratización y Especialización
Luis Daniel Soto Director de Divulgación Tecnológica para Microsoft. Responsable de la cuarta área de trece a nivel mundial en atención a
desarrolladores de software. Coordina el esfuerzo de un grupo de 100 personas encargadas de Divulgación Tecnológica en América Latina.
Ingeniero en computación por la Fundación Arturo Rosenblueth, especialista en el tema de liberación al mercado de nuevas tecnologías y
toma electrónica de decisiones. luisdans@microsoft.com luisdans.com\Twitter
H ace tiempo, pasaba varias noches es-
cribiendo software y preguntándome sobre
su alcance; nunca imaginé todo lo que hoy
permitiría hacer. La importancia del futuro
del software ha sido recurrente desde que mi
responsabilidad de tiempo completo es la de
trabajar para los desarrolladores y empresas
creadoras de software. ¿Cuál es el futuro del
software para el entrante quinquenio?
Las nuevas tecnologías generalmente madu-
ran en un periodo mayor a 5 años, es decir que
no tendremos sorpresas hasta 2015. Lo que
podemos esperar son mejoras en diversos
frentes, algunos de los más destacados son:
1. El verdadero Web portátil. Aun cuando
parece maravilloso el acceso total a Internet
desde un dispositivo electrónico portátil, la
realidad no lo es. El soporte a tecnologías
como flash y java es pobre, de tal suerte que
casi ningún portal bancario opera en celular
si éste no fue diseñado de forma especial.
Por una parte, el avance de hardware per-
mitirá emular exploradores más recientes,
pero por otra, los avances en herramientas
hará más fácil construir y acceder sitios des-
de cualquier dispositivo. RIA para las masas,
Internet extendido por sensores.
2. Mayor facilidad de interacción con la PC.
Al avance de la parte portátil, la interacción
con una PC de casa y oficina crecerá y no será
alcanzado por el Web. El tacto, la voz y ele-
mentos altamente interactivos simplificarán
el uso de la computadora derribando las limi-
tantes del teclado. Las aplicaciones deberán
ser multicanal y llegar a gente que no tiene
computadoras. (Ver twurl.nl/tf3mtw ).
3. Software con menos defectos. Desde la
perspectiva de la programación, no hemos lle-
gado al momento en donde el código se escri-
ba libre de defectos. Hay reportes de errores
que han sido resueltos nueve o más años pos-
teriores a su reporte original. Lo que podemos
esperar es la llegada del paradigma colabora-
tivo a identificación de problemas. Una exce-
54 FEB-ABR 2009
/*tendencias en SOFTWARE*/
lente charla es: twurl.nl/5zceki. La gran ambi-
güedad es la privacidad de la información.
4. Desempeño del software. Hoy es fácil se-
ñalar cuando un servicio opera o ha dejado
de funcionar. Pero hay respuestas dudosas al
efectuar la pregunta ¿el administrador de base
de datos está operando de forma eficiente?
Las máquinas virtuales en combinación con
grandes grids trabajan en la nube y permitirán
revertir el estado de equipos no responsivos
por imágenes frescas, pero la instrumenta-
ción será fundamental en las aplicaciones.
Para esto será necesario ampliar los servicios
del sistema operativo definiendo los eventos
importantes a monitorear y permitir dejar de
ejecutar servicios que no estén en uso.
El futuro del software será especialización +
democratización. El rumbo de la tecnología
es resolver los problemas de cada dominio
específico, y al mismo tiempo permitirle a
todo tipo de usuario crear programas fácil-
mente (twurl.nl/eqwn5d ). Este último con-
cepto se denomina democratización de la
creación de software. Incluye ampliar el ac-
ceso a personas que hoy no tienen una PC,
utilizar voz, terminales compartidas y objetos
conectados a la red.
Todos los dominios tendrán elementos en
común como privacidad, administración de
máquinas virtuales, verificación, instrumen-
tación, aprovechamiento de la red social
del usuario, clientes multi-cabeza, aprove-
chamiento del nuevo hardware (OLED, dis-
cos duros de estado sólido, video multiple
simultáneo, microprocesadores con menor
consumo de energía, etcétera).
En el ámbito empresarial, un elemento funda-
mental será el Enterprise mashups, combinan-
do los sistemas internos con el cómputo en la
nube. La arquitectura social: hace transparente
el acceso exterior a una red privada, no sólo
para empleados, sino para colaboración exter-
na. Muchos de estos elementos se agruparán
bajo la categoría: capacidades avanzadas de TI.
La casa y la oficina requieren esas mismas
capacidades entregadas como servicio,
pero aquí la clave continúan siendo las
aplicaciones. Supongamos por un momen-
to que el software es eficiente, está libre
totalmente de defectos y es multi-cabeza.
El mayor obstáculo es el último: hacen falta
las soluciones que sean construidas en la
nueva arquitectura. Deseaba recomendarle
a un amigo próximo a casarse un software
para administrar bodas en donde él y ella
colaboraran en las actividades desde sus
propios dispositivos, pero no lo pude loca-
lizar. (Ver columna ‘Patrones para software
de consumo’ SG Sep-Nov 2008).
¿Cuál es el impacto de las aplicaciones ac-
tuales? ¿El software educativo para escuelas
primarias le da a los alumnos ventajas en el
aprendizaje? Los niños de hoy se han bene-
ficiado por una gran cantidad de medios, in-
cluyendo mucho mejores programas de tele-
visión, juegos educativos no electrónicos y los
contenidos que acceden a través de Internet.
El aprendizaje realmente personalizado no
existe aún (ver twurl.nl/ttk4r6)
Pensemos en las 5 mil fotografías que pronto
tendremos en nuestros discos duros. ¿Es fá-
cil organizar las fotografías para encontrarlas
cuando sea necesario? ¿Cuánto tiempo tardo
en “subir” las imágenes a Internet para po-
derlas compartir en una forma visualmente
rica (pruebe twurl.nl/nxg2pm )?
Conclusión:
El futuro del software tiene que ver
con resolver problemas claramen-
te identificados del modelo actual,
mejorar las herramientas y métodos
para construir aplicaciones. Entender
mejor los problemas que deben ser
resueltos: Aquellos de alto impacto
para las empresas y personas.
» Por Luis Daniel Soto
www.sg.com.mx
www.sg.com.mx FEB-ABR 2009
 // fundamentos
La Fábula del Pastor y el Líder de Proyectos
¿Mito o Realidad?
Por Rodrigo Corral
Paseaba un día un líder de proyectos por el campo tras años de estar
pegado al monitor.
Iba pensando en lo extraordinario del paisaje, la paz que se respira-
ba y lo lejos que estaba ahora de la reunión de “kick off ”, cuando vió
un pastor de ovejas con un pequeño rebaño. No más de cincuenta
recursos eran los que el pastor gestionaba.
En ese preciso instante el modesto pastor vio al líder y tomó un
trago de su botella de mezcal. El pastor levantó la cabeza, miró
a nuestro líder de proyecto y le ofreció un trago. El líder tomó la
botella, le dió un trago que le supo bastante fuerte y se sentó junto
al pastor. Y ya se sabe, un buen mezcal puede tener efectos aluci-
nógenos. Sobre todo si no se ha probado en años… y no sale del
supermercado más próximo.
Así que embriagado por el sabor, el líder de proyecto no pudo evitar
decir: “señor pastor, lo suyo sí que es vida”. El pastor le miró, sin
decir nada. “Todo el día dedicado a usted mismo, con sus fieles re-
cursos que nunca se oponen a su voluntad, que saben lo que deben
hacer sin que nadie se los diga, que no están todo el día exigiendo
y pensando en irse a su hora a casa. Lo que daría yo por estar en su
situación…” continuó el jefe.
El pastor le miró y con la simpleza que sólo da la verdadera sabidu-
ría dijo: “no sabe usted de lo que habla, amigo”. Y tiró un largo tra-
go de la botella. El jefe de proyecto no se iba a amedrentar, así que
repuso: “Usted si que no sabe nada de lo duro que es mi trabajo,
seguro que yo cuidaría mejor de sus ovejas, que usted de mi equi-
po de desarrolladores”. El pastor le miró fijamente y dijo “hecho,
escriba aquí la dirección de su empresa y avise que voy”.
Le tendió la botella al líder de proyectos, en un gesto que decía
claramente que si bebía, el trato estaba cerrado. Y claro, el líder
bebió mientras pensaba, “que diablos, aquí el que tiene las cer-
tificaciones soy yo”.
El pastor silbó a su perro y le dijo, “dentro de una semana vuelvo, mien-
tras, obedece al jefe.”…
Le dió el petate y marchó a conocer a su nuevo rebaño. El líder de
proyecto pensó: “bueno se trata de gestionar recursos ¿no? Llevo
Mr. Rodrigo Corral, MCAD, MCPD. Más de 12 años desarrollando software, como freelance y en varias empresas como Sisteplant, es líder técnico en pro-
yectos realizado en plataforma .NET (C# 3.0 y ASP.NET). Responsable de grupos de desarrollo y analista-programador en Panda Software. Socio fundador de
PlainConcetps donde se deaempeña como arquitecto de software y mentor en diversas materias como gestión de proyectos, Scrum, Team System, patrones de
software, gestión de la configuración, diseño de arquitecturas distribuidas, implantación y desarrollo de Sharepoint, optimización y diseño de SQL Server
56 FEB-ABR 2009
haciendo eso años. Seguro que las ovejas saben hacer mejor su tra-
bajo que los desarrolladores. Tengo claro el objetivo, que den lana,
y sólo necesito crear un plan y exigir su cumplimento”. Con un buen
plan y mano férrea, seguro que lograba cumplir sus objetivos.
El líder respiró tranquilo cuando recordó que llevaba su PDA y que
tenía Project y Excel versión súper mini. Todo estaba solucionado.
Dedicó esa noche a trazar un plan. Todo estaba bajo control, él tenía
“el plan”, 50 recursos de tipo oveja, a 50 kilos de lana por recurso,
2,500 kilos de lana. Un proyecto rentable sin duda…
Al día siguiente reunió al rebaño. “Tengo un plan que nos va a llevar
a completar el proyecto de manera exitosa. Ya me he comprometi-
do con el alcalde y comerciante de lana a entregarle 2500 kilos de
la mejor lana en el plazo de dos meses. El alcalde me ha mostrado
su plena confianza en que conmigo al frente, gestor de recursos ex-
perto, el proyecto va a ser todo un éxito.” Las ovejas no entendían
nada. Ellas sabían que el alcalde solía preocuparse más por la leche
que por la lana, pero quizás las cosas habían cambiado, que sabían
ellas, meros recursos productores de ¿lana? ¿leche?... Las ovejas, no
habían nunca producido tanta lana en tan poco tiempo, pero con un
buen gestor al mando quizás se obrase el milagro.
Pasaron veinte días, y el líder de proyecto reunió de nuevo a las ove-
jas. “Queridas ovejas, vamos retrasados respecto mi plan. No dudo
que harán lo necesario para asegurar la producción al ritmo necesa-
rio. Ya he hablado con el alcalde y le he dicho que no se preocupe,
que incrementaremos nuestro esfuerzo bovino y recuperaremos el
tiempo perdido”. Las ovejas no entendían nada y llegaron a la con-
clusión de que el líder no era un animal muy listo. Al fin y al cabo no
sabían cómo hacer crecer la lana más rápido… y parecía que él tampoco.
Otros veinte días después, el líder de proyecto reunió de nuevo al re-
baño. “Malditas ovejas. Les pedí un esfuerzo y no han hecho nada. Yo
hice el plan y ustedes están haciendo que fracase. Si no se aplican, se
van a ir a la *@#& calle. Y ya saben, la crisis que hay… puedo encon-
trar cincuenta como ustedes’. La ovejas, una vez más, no entendieron
nada. Ya le habían dicho al jefe de proyecto que no las metiera en el
corral por las noches, y que cambiarlas de prado no era bueno para su
lana. Habían pensado que tal vez si se movían por el campo, como ha-
cían con el pastor, la producción de lana mejoraría. También sugerían
que el jefe las ordeñase, sabían que el alcalde siempre quería leche...
www.sg.com.mx
“Estas ovejas, siempre quejándose de tonte-
rías, ya sabía que no eran muy diferentes a
los desarrolladores. Que sigan el plan y dejen
de quejarse y pensar, para eso estoy yo. ¡No
hay manera de hacer que trabajen!” había
pensado el jefe de proyecto.
Veinte días después, el alcalde llegó y pre-
guntó al jefe por su lana… el jefe sólo tenía
1,000 kilos, la ovejas resultaron no ser tan
expertas como ponía en su curriculum, in-
aceptable… que podría haber hecho él… “No
pasa nada jefe”, dijo el alcalde, “tendremos
mucha leche entonces”. El jefe se puso rojo
y dijo ¿leche? si en el contrato no decía nada
de leche… El alcalde dijo, “No me importa lo
que diga el contrato, lo de la leche se da por
hecho, vaya fracaso del proyecto, no vas a
ver un *@#& peso…”.
En eso llegó el pastor… seguro que él tam-
bién se había equivocado… “¿Qué tal pas-
tor? ¿Duro el trabajo?” dijo sarcástico. El
pastor contestó, con su simpleza natural:
“Todo ha ido sobre ruedas. Al fin y al cabo
los desarrolladores son como ovejas, ¿no?
Seguro que a ti también te ha ido bien. Los
desarrolladores incluso me han regalado un
GPS para que marque dónde comen mejor
mis ovejas… ¡y dónde hay setas! Creo que
me han tomado cariño”.
El líder no salía de su asombro. Los recursos
eran agradecidos y todo. ¡Cuéntame que has
hecho! dijo al pastor.
“Ha sido fácil, los desarrolladores son mu-
cho más comunicativos que las ovejas y
cuesta menos reunirlos. Además, pensé, no
pueden ser muy diferentes que las ovejas,
son individualistas y gregarios a la vez. Se-
guro que si cuido de ellos como hago con mis
ovejas, obtendré los resultados esperados y
a eso me he dedicado estas semanas”.
“Me pidieron que les consiguiese un ser-
vidor de 64 bits para no se qué pruebas
www.sg.com.mx
de rendimiento y de compatibilidad. Yo no
tenía ni idea de qué era eso, pero parecía
importante para ellos, así que lo conse-
guí. ¿No busco los mejores pastos para mi
ovejas? No es tan diferente…” El jefe de
proyecto estaba atónito, ¿desde cuándo
se logra algo de los recursos atendiendo a
sus caprichos?…
“Un día, los desarrolladores dijeron que no lo-
graban que el rendimiento fuese el adecuado,
lo mejor era preguntar a un experto, dijeron.
Así que eso hice, busqué un experto que les
ayudara y les formara. ¿No llevo a mis ovejas
al veterinario cuando tienen problemas?”.
Ahora sí que el líder de proyecto no se lo podía
creer, ¡formar a los recursos es caro! Y luego se
van a la competencia en cuanto saben.
“Otro día los desarrolladores me contaron
que no lograban avanzar. Eso me preocu-
pó. ¿Se supone que los desarrolladores
deben avanzar en la funcionalidad, es su
lana y su leche, no? El problema es que
los de ventas estaban continuamente exi-
giendo pequeñas modificaciones, visitas a
clientes, que atendieran llamadas; parece
que los lobos acechan, pensé yo. Así que
puse un poco de orden y dejé claro que a
mi rebaño no se le molesta”.
El pastor concluyo: “la verdad es que no he
hecho mucho ¿no?. Los desarrolladores son
como las ovejas, si dejas que hagan su traba-
jo y pones las condiciones para que lo hagan,
al final puedes recoger los resultados”.
En eso despertó el líder de proyecto y pen-
só: “caramba, cómo pega el mezcal del
pastor, vaya siesta y vaya sueño más raro”,
mientras veía al pastor perderse por el ho-
rizonte con su rebaño.
Ya lo dijeron DeMarco y Lister en Peopleware;
“el trabajo del gestor de proyectos no es ha-
cer que la gente trabaje, sino construir el en-
torno en el que trabajar sea posible”.
FEB-ABR 2009 57
 // TECNOLOGÍA
Almacenamiento en Caché, Paralelismo
y Escalabilidad
La Ley de Moore ha muerto. Ahora rige la Ley de Amdahl
por Manik Surtani
Desde hace unos años, la Ley de Moore dejó
de tener importancia. Hoy en día, es mucho
más aplicable la Ley de Amdahl, acuñada
por Gene Amdahl. Esta ley sostiene que al
añadir más procesadores para trabajar so-
bre un problema, no se logra la producti-
vidad global esperada calculada mediante
la suma de la productividad individual de
cada procesador. Lo que tendrá efecto en
su productividad global será la capacidad
de poder disgregar el problema original en
subproblemas, que puedan distribuirse en-
tre los diversos procesadores.
Esta ley es importante porque la estrategia
actual para desarrollar computadoras más ve-
loces consiste en aumentar los nodos de pro-
cesamiento paralelos, ya sea colocando más
núcleos en chip, más chips en un servidor, y
más servidores en un único cluster. Sin embar-
go, su software requiere ser escrito específica-
mente para aprovechar este paralelismo.
En el caso del software aplicativo del que te-
nemos el código fuente, es posible hacerle
pequeños ajustes y utilizar librerías para eje-
cución paralela, que lo hagan más eficiente
en este contexto. Sin embargo, ¿qué sucede
con las bibliotecas y subsistemas que están
fuera de nuestro control? Más específicamen-
te, ¿qué sucede con las bases de datos que
entran en contacto con discos que inherente-
mente involucran un procesamiento secuen-
cial? Las bases de datos son sólo un ejemplo
común de la serialización de procesos. La se-
rialización sólo permitiría el funcionamiento
de un único núcleo en un momento determi-
nado en un sistema de múltiples núcleos, y
limitaría la potencia de cálculo utilizable. La
serialización es el gran enemigo en esta ins-
tancia porque contrarresta todos los avances
en productividad que ofrece el paralelismo.
Manik Surtani es ingeniero investigador en JBoss, una división de Red Hat corp. Actualmente dirige el proyecto JBossCache en el Centro de Investigación y
Desarrollo de JBoss. Su área de especialidad es la inteligencia artificial y redes neuronales.
58 FEB-ABR 2009
/*INFRAESTRUCTURA*/
Aquí es donde el almacenamiento en caché
cobra importancia. A diferencia de una base
de datos que es inherentemente serial por
naturaleza, una caché vive en la memoria y
es altamente paralela debido a la naturaleza
de los buses de memoria. Una memoria bien
escrita minimizará los bloqueos o el uso de
señalización entre unidades de ejecución, y
utilizará técnicas modernas para garantizar la
integridad de los datos de manera escalable.
Caché en cluster
Las caché en cluster permiten que múltiples
núcleos y servidores en un grid trabajen sobre
los datos dispuestos en paralelo, aprovechan-
do al máximo la potencia de cómputo disponi-
ble. El problema es cómo mantener la integri-
dad de los datos entre los diferentes nodos.
Las caché en cluster utilizan diversos mecanis-
mos para mantener la sincronización entre las
caché y garantizar la validez de los datos:
• Bloqueo pesimista del cluster completo.
Cuando un cache requiere modificar datos,
obtiene un bloqueo para todo el cluster,
hace los cambios que se replican a cada ins-
tancia de caché y luego liberará el bloqueo
del cluster. Este enfoque es seguro y sencillo
pero presenta problemas de escalabilidad.
• Bloqueoo optimista. Es aquél donde los
conjuntos de datos se copian, se trabaja con
ellos y, una vez terminada la tarea, se obtie-
nen los bloqueos y se escribe el estado en las
caché de todo el cluster. Brinda mayor esca-
labilidad pero presenta la necesidad de rein-
tentar una operación en caso de colisión.
Distribución de datos
Hasta ahora hemos hablado de las caché en
cluster en el sentido de que cada caché es
local pero consciente de sus pares y es capaz
de sincronizar cambios con ellos. Si bien este
enfoque funciona bien para la mayoría de las
aplicaciones, aun restringe la memoria accesi-
ble que pueden utilizar. Otro enfoque sería no
reproducir los datos entre las caché, pero su-
mar la memoria utilizable de todas las caché
en un cluster y distribuir los datos entre ellas.
Ubicar dónde se encuentran los datos podría
implicar metadatos duplicados –una especie
de mapa– o una función de búsqueda de re-
gistros compatible que apuntará a la instancia
que contiene el registro que busca. Aunque
distribuir datos de esta forma puede conllevar
búsquedas innecesarias en la red, expone un
espacio de memoria utilizable mayor para que
sea ocupado por el sistema de caché. También
hace que el sistema global sea más escalable.
Conclusión
Las caché constituyen una herramienta
importante para aprovechar el para-
lelismo y eliminar los obstáculos en la
recuperación y cálculo de datos. Anali-
zando la arquitectura de su aplicación y
el volumen y los patrones de acceso de
sus datos, podrá decidir si le conviene
una caché local, en cluster o distribui-
da. Muchas estructuras o productos de
almacenamiento en caché desarrolla-
dos le ofrecerán un abanico de modos
operacionales que se adapten a su uso
en particular. Pero como sucede con
frecuencia, las caché no son soluciones
milagrosas y no deberían utilizarse de
manera indiscriminada. Como citó el
experto en optimización de Java, Kirk
Pepperdine: “Calcule, no adivine”.
Utilice un buen analista de perfiles e
incorpore las caché sólo cuando sea
necesario, cuando los problemas de
recuperación o cálculo de datos estén
frenando la escalabilidad.
www.sg.com.mx
www.sg.com.mx FEB-ABR 2009
 // tecnología
La Virtualización y el Ahorro Sustentable
Las Soluciones de TI Verde
Por Rob Smoot
Mientras más se habla del ahorro de ener-
gía, las soluciones de TI “verde” se vuelven
más populares, el incremento, tanto en el
costo de la energía, como en el consumo de
los Data Center y la importancia que tiene
el ahorro sustentable permite desarrollar
nuevos servicios de TI, que mantenienen co-
rriendo los centros de datos, y con ahorro en
el entorno, se convierten en focos que mar-
can el camino para las empresas y el mundo
en general. La virtualización viene a apoyar
dicha ideología, sin embargo, el cambio y
los beneficios que propone, han sobrepasa-
do la simple consolidación de servidores.
Dinamismo de cargas “Right
Sizing” de la Virtual Infrastructure
Algunas personas sugieren que la virtualiza-
ción sea un beneficio, una vez que se quiten
los servidores. ¿Qué hay después de la con-
solidación inicial?
La virtualización cambia el juego, convir-
tiendo los servidores físicos y su estado
de ejecución, en archivos de software, que
pueden ser copiados y movidos fácilmente,
lo que hace al hardware, infinitamente más
flexible. La creación de la virtualización
para los servidores x86 fue en los años 90,
pero tomó su flexibilidad neta más a futuro,
permitiendo correr las máquinas virtuales
que se emigraran de un servidor a otro sin
la interrupción a las aplicaciones o, a los
usuarios finales. Esta tecnología se llama
VMotion, y desde su introducción al merca-
do en 2003, se ha ampliado, permitiendo a
los clientes reequilibrar dinámicamente los
servidores a través de un pool entero de
servidores sobre una base en curso.
Los rebalanceos de las cargas de trabajo, se
acomodan dinámicamente a través del cen-
tro de datos, y se pueden utilizar para opti-
mizar el uso de la energía. Esta funcionali-
dad se llama Administración Distribuida del
Rob Smoot es el responsable de Marketing de los productos de Administración de Virtualización para Data Center vCenter de VMware. Tiene más de 12 años de
experiencia en marketing de software empresarial, fue Gerente Senior de Veritas Software, Gerente de Procesos de Negocio en Andersen. Cuenta con Posgrado
en Administración de Negocios por la Universidad Brigham Young y Maestría en Administración de Negocios por la Wharton Business School de la Universidad
de Pennsylvania.
60 FEB-ABR 2009
/*TENDENCIAS*/
Poder, y promete transformar el consumo de
energía en el centro de datos. Esta caracte-
rística contrae o expande automáticamente
el pool de los servidores que funcionan en
cualquier hora dada, sin la reducción de por-
centajes de disponibilidad.
Trabaja supervisando la utilización de un
pool de servidores y cuando existe exceso
de la capacidad, mueve las máquinas vir-
tuales corrientes sobre pocos servidores, y
cierra automáticamente los servidores físi-
cos innecesarios. Por lo que “el exceso de
la capacidad consolidada” se controla por el
usuario. Por ejemplo, esto puede incluir un
almacenador intermediario de la capacidad
para el recuperador de desastres automáti-
co, que es también una característica parti-
cular de la infraestructura virtual. Permitien-
do que los clientes optimicen y reduzcan
continuamente el consumo de energía del
pool del hardware sin sacrificar la confiabili-
dad y la disponibilidad de la infraestructura
de TI. El beneficio neto de los clientes es que
pueden tener el correcto tamaño de su infra-
estructura de TI en tiempo real, de tal modo
que maximizan la salida de TI mientras que
consumen la menor energía posible.
Impacto ambiental del
correcto tamaño de TI
En el contexto de efecto y flexibilidad, hay algo
que debe ser dicho sobre el impacto ambien-
tal de la virtualización. Cada servidor que es
virtualizado, ahorra electricidad 7.000 KVH y
4 toneladas de emisiones de CO2 por año. Con
más de un millón de cargas de trabajo que fun-
cionan en las máquinas virtuales, los ahorros
de la energía agregados son hasta cerca de 8
mil millones KVH, que es más que la electrici-
dad de la calefacción y la ventilación consumi-
da en Nueva Inglaterra en un año. 1
Estos ahorros son sólo el comienzo gracias
al exceso de provisión de hardware en la
industria. Para poner en perspectiva de tres
años de exceso de capacidad en términos de
consecuencias para el medio ambiente, con
cuatro toneladas de CO2 producidos por el
servidor, representa anualmente 80 millo-
nes de toneladas de emisiones de CO2, que
es igual a las emisiones de la mitad de to-
dos los países en América Latina. Solamente
5% de servidores físicos se han consolidado
hasta la fecha, pero ahora que la virtualiza-
ción ha llegado a ser de corriente, los pro-
nósticos sugieren que se consolide a una
mayoría de servidores, usando la virtualiza-
ción en los próximos años. La consolidación
del servidor y el volver a clasificar según el
tamaño dinámico de TI tendrán un efecto
económico y ambiental enorme.
Revolución del centro de datos
La virtualización proporciona enormes ven-
tajas de energía, y una línea de vida a los
centros de datos que se están quedando
sin poder, sin refrescarse o sin capacidad
real. Sin embargo, esta ventaja no es ge-
neralmente la razón primaria para lo que
funciona este software. Los ahorros de
costos, la flexibilidad, la confiabilidad y la
disponibilidad crecientes, han convencido
al mercado, que la virtualización de centros
de datos es una manera fundamental para
entregar y administrar la infraestructura de
TI. La virtualización para los servidores x86
y la innovación de virtualización en los úl-
timos 10 años permiten que los centros de
datos sean considerados como la infraes-
tructura física estática. El centro de datos
del futuro será virtualizado y de ambiente
dinámico, el cual podrá constantemente te-
ner el correcto tamaño para reducir al míni-
mo el consumo innecesario, el recuperador
de desastres y la energía.
Referencias
[ 1. eia.doe.gov/emeu/reps/enduse/er01_
new-eng_tab1.html ]
www.sg.com.mx
www.sg.com.mx FEB-ABR 2009 59
 // tecnología /*gadgets*/

Research in Motion / Nextel

BlackBerry Curve 8350i Smartphone
Bautizado como el gurú de los negocios, este pequeño, pero poderoso dispositivo es lo último en
comunicación porque combina la rapidez de los sistemas de conexión directa push to talk de la red
Nextel, con todas las características de un smartphone y capacidad Wi-Fi. Su teclado QWERTY más
el tradicional trackball son prácticas herramientas para acceder de manera rápida al menú con las
funciones típicas como correo electrónico, calendario, libreta de contactos o sistema GPS de nave-
gación. Dentro del listado de cualidades del 8350i destacan una cámara digital de 2MP con zoom
digital de 5x, flash y captura de video; software precargado para editar documentos en Word, Excel
y Power Point, antena interna, altavoz, reproductor de medios para escuchar música, ver video o fo-
tografías; memoria expandible a través de una ranura microSD, Bluetooth versión 2.0, y capacidad
adicional para utilizar mensajeros instantáneos.

Sony
Vaio Serie P
Con la etiqueta de Lifestyle PC, o lo que es lo mismo: “una compu con
estilo”, la nuevísima Vaio Serie P nos recuerda aquel proyecto Origa-
mi y el intento un tanto fallido por lanzar al mercado la UMPC (Ultra-
Mobile PC) que luego de rumores, presentaciones y videos, quedó en
el olvido. Ahora con la moda de las Netbooks, surge esta pequeñísi-
ma, práctica y completamente móvil computadora que ofrece todo lo
que una de escritorio puede dar, pero en la comodidad de nuestros...
¿bolsillos? Con tan solo 1.4 libras de peso (635 gramos), la Vaio Lifes-
tyle PC es tan ligera que se puede llevar en el bolso o incluso en una
chaqueta o bolsillo amplio de un pantalón. Está disponible en cuatro
colores, cuenta con diversos accesorios extra como un mouse láser
Bluetooth, una funda de piel y una batería de alto rendimiento.
Sus características son las siguientes: pantalla de 1600 x 768 pixels,
conectividad tanto por WiFi 802.11n como por red celular de banda
ancha 3G, así como Bluetooth 2.0, procesador Intel de 1.33GHz, 60GB
de disco duro hasta 128GB SSD, GPS, ranura para Memory Stick PRO
(standard / duo), ranura de medios con funcionalidad MagicGate y SD.
Así que estés donde estés y hagas lo que hagas es tiempo de olvidar la
molesta mochila o el portafolio que pesa más que tu lap.
Parrot
Conference
El sistema Parrot Conference permite realizar confe-
rence calls utilizando ya sea la línea de tu teléfono
celular, línea análoga o VoIP. El enlace al teléfono se
realiza por medio de Bluetooth y es bastante sencillo.
Está diseñado para grandes salas de juntas ya que
sus tres micrófonos de alta sensibilidad permiten que
la voz y el sonido abarque 360 grados sin perder niti-
dez. Se puede mover de un lugar a otro gracias a sus
tres baterías recargables de larga duración. La pan-
talla TFT de 160 X 120 pixeles muestra la información
de los números que se marcan y por qué vía se enlaza
la llamada. En general es un sistema de conferencia
bastante amigable.

62 FEB-ABR 2009 www.sg.com.mx

 INDEX

DIRECTORIO Anunciante Páginas Sitio

Brio 57 www.brio.com.mx
e-Quallity 49 www.e-quallity.net
Gartner 61 www.gartner.com/mx/appint
Gelattina 25 www.gelattina.com/alMaximo
IDC 63 www.idc-eventos.com
IT Institute 13 www.it-institute.org
JP Consultores 39 www.jpeconsultores.com
Manpower 7 www.manpowerprofessional.com.mx
Matersys 2F, 1 www.matersys.com.mx
Milestone Consulting 4F www.milestone.com.mx
NYCE 3F www.nyce.org.mx
P&M Consulting 37 www.pmconsulting.com.mx
SafeNet 11 www.safenet-inc.com
SG Campus 17 www.sgcampus.com.mx
SG Revista Digital 55 www.sg.com.mx
Tendencias 59 www.select.com.mx
TENEMOS UN ESPACIO
RESERVADO PARA TI
Si deseas anunciarte contáctanos
en el (55) 5239 5502 o en
publicidad@sg.com.mx

www.sg.com.mx FEB-ABR 2009 63

 // COLUMNA
La Otra Inteligencia de Negocios
+ Capital Intelectual Adecuado
Dr. Raúl A. Trejo es profesor investigador del Instituto Tecnológico y de Estudios Superiores de Monterrey, campus Estado de México. Con
especialidad en inteligencia artificial y apasionado de los lenguajes de programación, el Dr. Trejo ha encontrado en la administración del
conocimiento y el desarrollo de negocios electrónicos un campo fértil para aplicar ambas disciplinas. En sus ratos libres es escritor de ficción.
Sus publicaciones tecnológicas se encuentran en www.tech-o-potamus.blogspot.com
E l año que termina dibujó una situación difícil para la industria
de tecnologías de información. Con presupuestos limitados, los
recursos para innovación tecnológica estarán de seguro restringi-
dos a lo esencial. Para muchas empresas, significa que muy pro-
bablemente la inversión tecnológica estará destinada a apoyar la
operación con resultados de negocio más inmediatos. Y los con-
sultores o directores tecnológicos promoverán sistemas orienta-
dos a dichas tareas.
Pero quizá el lector piense que es precisamente en épocas difí-
ciles cuando se presenta la oportunidad de innovar, mejorar, y
redefinir estrategias de mediano y largo plazo. Que quizá es justo
en estos momentos, que la definición de estrategias fundadas en
datos certeros determinará de manera importante el éxito, o in-
cluso la supervivencia de la empresa.
Ciertamente, es un buen momento para incursionar en una ini-
ciativa de inteligencia de negocios, o cimentar los objetivos de la
iniciativa ya existente en la empresa. Y es que el costo de opor-
tunidad de no realizar inteligencia de negocios resulta particu-
larmente evidente ahora, lo cual, por supuesto, no nos distrae
de lo enorme que resulta emprender una tarea de tal magnitud.
La inteligencia de negocios tiene demasiados componentes, y re-
quiere de una sabia mezcla de directivos informados, expertos
capacitados, consultores con visión; y software de punta.
Pero es también bajo esta situación particular, que debemos men-
cionar un componente fundamental para la consolidación de la ini-
ciativa de inteligencia de negocios: necesitamos capital intelectual
de primera. El ciclo de administración del conocimiento, empieza y
termina con las personas que conforman la organización.
64 FEB-ABR 2009
/*cátedra y más*/
Y entonces, dada la problemática actual, se hacen indispensables
dos actividades de inteligencia de negocios. La primera de ellas
es mantener el capital intelectual. La identificación de mejores
prácticas, la comunicación de modelos de optimización de pro-
cesos y el portal de conocimiento, no son de utilidad si no se
cuenta con miembros de la organización que están al tanto de sus
características corporativas y sus procedimientos, y que poseen
en primera instancia, el conocimiento que da origen al ciclo de
inteligencia de negocios.
En la situación actual, es una realidad que podemos perder ca-
pital intelectual valioso tanto por limitantes económicas como
por simple ceguera de los mandos administrativos. Es ahora, más
que nunca, que debemos cuidar nuestro capital intelectual. El to-
mador de decisiones, al verse ante la posibilidad de dejar ir a una
persona, debería considerar lo siguiente: ¿deseo que lo que esta
persona sabe, sea aprovechado por otra organización?
La segunda actividad concomitante al establecimiento de un es-
quema de inteligencia de negocios es, promover el capital inte-
lectual. Es buen momento para acercarse a las universidades y
explorar en busca de los nuevos talentos que se integrarán con
facilidad a nuestras políticas y metodologías; así como para to-
mar a estos profesionistas y capacitarlos en nuestros procesos y
habilidades, con modelos de negocio que promuevan su perma-
nencia en la empresa.
Interesante reto el de los directores estratégicos y de tecnología;
pero válido y vigente, dados los objetivos estratégicos de las empre-
sas, donde la inteligencia de negocios jugará un rol determinante.
» Por Raúl A. Trejo Ramírez
www.sg.com.mx
No. 23 www.sg.com.mx SG SOFTWARE GURU - CONOCIMIENTO EN PRÁCTICA Febrero-Abril 2009